Java IO.pdf - Nguyen Dang Binh

Java I/O
encoding into a new file called isodata.txt encoded with ISO Latin-1 with Unicode escapes,
you would type:
% native2ascii -encoding MacRoman macdata.txt isodata.txt
You can convert it back with the -reverse option:
% native2ascii -encoding MacRoman -reverse isodata.txt macdata.txt
If you don't specify a particular encoding, native2ascii makes its best guess as to the
platform's native encoding. This best guess is read from the system property file.encoding.
On American Macs, the default is MacRoman. On American Solaris, the default is 8859_1
(ISO Latin-1). On American Windows, the default is also 8859_1. However, you shouldn't
rely on these values. Instead, check the property directly. Systems configured for other
countries are likely to have different default encodings. Table B.4 lists the many encodings
that Java, javac, and native2ascii understand. As extensive as this list is, there are a few
missing pieces. In particular, ISO 8859-10, a.k.a. Latin-6, includes ASCII plus various
characters used for Lappish, Nordic, and Inuit languages in the upper 128 places. Java cannot
currently convert characters in this set to Unicode.
Work is continuing on both Unicode and other character sets. ISO 8859-11 will provide a
standard encoding for Thai. ISO 8859-12, also known as Latin-7, will use the upper 128
characters past ASCII for Celtic. ISO 8859-13, also known as Latin-8, will use them for the
Baltic Rim languages. ISO 8859-14, also known as Latin-9, will encode ASCII plus Sami.
Eventually, converters will be needed for these encodings as well.
14.7 Converting Between Byte Arrays and Strings
The java.lang.String class has several constructors that form strings from byte arrays and
several methods that return a byte array corresponding to a given string. Anytime a Unicode
string is converted to bytes or vice versa, that conversion happens according to one of the
encodings listed in Table B.4. The same string can produce different byte arrays if different
encodings are used. Six constructors form a new String object from a byte array:
public String(byte[] ascii, int highByte)
public String(byte[] ascii, int highByte, int offset, int length)
public String(byte[] data, String encoding)
throws UnsupportedEncodingException
public String(byte[] data, int offset, int length, String encoding)
throws UnsupportedEncodingException
public String(byte[] data)
public String(byte[] data, int offset, int length)
The first two constructors, the ones with the highByte argument, are leftovers from Java 1.0
that are deprecated in Java 1.1. These two constructors do not accurately translate non-Latin-1
character sets into Unicode. Instead, they read each byte in the ascii array as the low-order
byte of a two-byte character, then fill in the high-order byte with the highByte argument. For
example:
byte[] isoLatin1 = new byte[256];
for (int i = 0; i < 256; i++) isoLatin1[i] = (byte) i;
String s = new String(isoLatin1, 0);
357