I gonna to write a program like Telnet in java. It comes two problems first..
1. of course we got use socket to receive/post data. but how to trans ascii code/unicode to ANSI code?
2. If use Swing to draw the "termial screen", what object should I use? Jtext? JLable?
It must allow users to input text and receive text instantly.
In the simplest terms Java only understands unicode. However UTF-8 is unicode's encoding for ASCII. In order to use encodings bind a java.io.OutputStreamWriter to the java.io.OutputStream acquired by the socket. Set the OutputStreamWriter's encoding to UTF-8.
Socket connection = new Socket( "1.1.1.1", 100 );
OutputStream stream = connection.getOutputStream();
OutputStreamWriter writer = new OutputStreamWriter( stream, "UTF-8" );
writer.write( "testing", 0, "testing".length() );
writer.flush();
writer.close();
//etc...
Personally I would use a JTextArea for the terminal screen. Simply add a listener that listens for text changes. Buffer all the text the user enters until "\n" is received. At that point send all the buffered text to the connected device and block, waiting for a response (blocking isn't strictly necessary, but it will keep the user from thinking nothing has been returned).
If a GUI isn't required I wouldn't waste the effort. Java's System.in and System.out were made for just this sort of thing.
> In the simplest terms Java only understands unicode.
> However UTF-8 is unicode's encoding for ASCII.
No.
Java characters are UTF16. A String instance in java is UTF16 (an array of characters.)
UTF8 is a multibyte character set which represents unicode. A single character might be represent by one byte while another character might be represented by up to 4 bytes.
Both UTF8 and UTF16 have character representations for ASCII. And for UTF8 there is a straight bit map between the two. But that is also true for almost every character set including japanese, chinese, etc. One notable category of characters sets where this is not true is the EBCDIC sets, but they map as well (just not directly.)
The ASCII character set is a 7 bit character set with values from 0 to 127. The UTF8 characters in the range of 0 to 127 exactly match the ASCII character set (because that is how unicode works.) For UTF16 the ASCII character set exactly matches x0000 to x007f.
Using the proper methods of String along with specifically specifying UTF8 you can extract UTF8 byte arrays and create strings.
Normally String extracts/imports using the default char set of the OS (which is unlikely to be any variation of unicode.)
This works for ASCII however, because in all likelyhood the charset on the OS is not an EBCDIC set and as such the charset already maps directly for ASCII.
You are close. UTF-8 is an encoding, ASCII is a character set. The fact that UTF-8 is solely for use with Unicodes encoding for ASCII might have lead to the confusion. However you are right that Java can support any character set that uses up to 16bits.
Thanks for the clarification.
>> From the terminology section of the Charset class.
A coded character set is a mapping between a set of abstract characters and a set of integers. US-ASCII, ISO?859-1, JIS齒?201, and full Unicode, which is the same as ISO?0646-1, are examples of coded character sets.
A character-encoding scheme is a mapping between a coded character set and a set of octet (eight-bit byte) sequences. UTF-8, UCS-2, UTF-16, ISO?022, and EUC are examples of character-encoding schemes. Encoding schemes are often associated with a particular coded character set; UTF-8, for example, is used only to encode Unicode. Some schemes, however, are associated with multiple character sets; EUC, for example, can be used to encode characters in a variety of Asian character sets.
> You are close. UTF-8 is an encoding, ASCII is a
> character set. The fact that UTF-8 is solely for use
> with Unicodes encoding for ASCII might have lead to
> the confusion. However you are right that Java can
> support any character set that uses up to 16bits.
>
> Thanks for the clarification.
I believe I am exact. Java doesn't have 'encodings' it has 'charsets' (which isn't to surprising given that it has a Charset class.)
UTF8 in terms of java is a character set. You can use String to get and push a charset called UTF8
And the documentation that you posted specifically lists UTF8 as a char set.
Java does not, so far as I know have a char set called 'ASCII'. However such char sets do exist because I have worked on a machine whose charset was exactly that (yes it used ONLY 7 bits.)
And I didn't say that java could only use a char set that had up to 16 bits. That is not exact and it is not what I said. What I said was that strings in java use chars that are UTF16. Java can support and charset that can provide a mapping to UTF16. Conceptually that could include UTF32 because just as with current conversions it could simply mask out the ones that it cannot map.
> I believe I am exact.
Depends on which set of definitions you use. The unicode spec defines UTF-8 as both a Unicode encoding form and a Unicode encoding scheme. Personally I'd object to calling UTF-8 a "charset" since the set of characters it encodes is Unicode, and the Unicode character set has several encoding schemes besides UTF-8, but never mind.
> Java does not, so far as I know have a char set called 'ASCII'.
No, it's called "US-ASCII" instead, probably so that it would not be confused with the several regional "extended ASCII" character sets/encodings.
> > I believe I am exact.
>
> Depends on which set of definitions you use. The
> unicode spec defines UTF-8 as both a Unicode encoding
> form and a Unicode encoding scheme. Personally I'd
> object to calling UTF-8 a "charset" since the set of
> characters it encodes is Unicode, and the Unicode
> character set has several encoding schemes besides
> UTF-8, but never mind.
>
> > Java does not, so far as I know have a char set
> called 'ASCII'.
>
> No, it's called "US-ASCII" instead, probably so that
> it would not be confused with the several regional
> "extended ASCII" character sets/encodings.
And it is only 7 bits?
> >
> > > Java does not, so far as I know have a char set
> > called 'ASCII'.
> >
> > No, it's called "US-ASCII" instead, probably so that
> > it would not be confused with the several regional
> > "extended ASCII" character sets/encodings.
>
> And it is only 7 bits?
(Of course I mean that it only returns values from 0-127, where the 8th bit is always zero.)
