A charset is a named mapping between Unicode characters and byte sequences. Every
Charset can decode, converting a byte sequence into a sequence of characters,
and some can also encode, converting a sequence of characters into a byte sequence.
Use the method
canEncode() to find out whether a charset supports both.
In the context of this class, character always refers to a Java character: a Unicode
code point in the range U+0000 to U+FFFF. (Java represents supplementary characters using surrogates.)
Not all byte sequences will represent a character, and not
all characters can necessarily be represented by a given charset. The method
can be used to determine whether every character representable by one charset can also be
represented by another (meaning that a lossless transformation is possible from the contained
to the container).
There are many possible ways to represent Unicode characters as byte sequences. See UTR#17: Unicode Character Encoding Model for detailed discussion.
The most important mappings capable of representing every character are the Unicode Transformation Format (UTF) charsets. Of those, UTF-8 and the UTF-16 family are the most common. UTF-8 (described in RFC 3629) encodes a character using 1 to 4 bytes. UTF-16 uses exactly 2 bytes per character (potentially wasting space, but allowing efficient random access into BMP text), and UTF-32 uses exactly 4 bytes per character (trading off even more space for efficient random access into text that includes supplementary characters).
UTF-16 and UTF-32 encode characters directly, using their code point as a two- or four-byte
integer. This means that any given UTF-16 or UTF-32 byte sequence is either big- or
little-endian. To assist decoders, Unicode includes a special byte order mark (BOM)
character U+FEFF used to determine the endianness of a sequence. The corresponding byte-swapped
code point U+FFFE is guaranteed never to be assigned. If a UTF-16 decoder sees
0xfe, 0xff, for example, it knows it's reading a big-endian byte sequence, while
0xff, 0xfe, would indicate a little-endian byte sequence.
UTF-8 can contain a BOM, but since the UTF-8 encoding of a character always uses the same
byte sequence, there is no information about endianness to convey. Seeing the bytes
corresponding to the UTF-8 encoding of U+FEFF (
0xef, 0xbb, 0xbf) would only serve to
suggest that you're reading UTF-8. Note that BOMs are decoded as the U+FEFF character, and
will appear in the output character sequence. This means that a disadvantage to including a BOM
in UTF-8 is that most applications that use UTF-8 do not expect to see a BOM. (This is also a
reason to prefer UTF-8: it's one less complication to worry about.)
Because a BOM indicates how the data that follows should be interpreted, a BOM should occur as the first character in a character sequence.
See the Byte Order Mark (BOM) FAQ for more about dealing with BOMs.
Endianness and BOM behavior
The following tables show the endianness and BOM behavior of the UTF-16 variants.
This table shows what the encoder writes. "BE" means that the byte sequence is big-endian,
"LE" means little-endian. "BE BOM" means a big-endian BOM (that is,
|UTF-16BE||BE, no BOM|
|UTF-16LE||LE, no BOM|
|UTF-16||BE, with BE BOM|
The next table shows how each variant's decoder behaves when reading a byte sequence.
The phrase "includes BOM" means that the output includes the U+FEFF byte order mark character.
|Charset||BE BOM||LE BOM||No BOM|
|UTF-16BE||BE, includes BOM||BE, failure||BE|
|UTF-16LE||LE, failure||LE, includes BOM||LE|
A charset has a canonical name, returned by
name(). Most charsets will
also have one or more aliases, returned by
aliases(). A charset can be looked up
by canonical name or any of its aliases using
The following charsets are available on every Java implementation:
All of these charsets support both decoding and encoding. The charsets whose names begin "UTF" can represent all characters, as mentioned above. The "ISO-8859-1" and "US-ASCII" charsets can only represent small subsets of these characters. Except when required to do otherwise for compatibility, new code should use one of the UTF charsets listed above. The platform's default charset is UTF-8. (This is in contrast to some older implementations, where the default charset depended on the user's locale.)
Most implementations will support hundreds of charsets. Use
isSupported(String) to see what's available. If you intend to use the charset if it's
available, just call
forName(String) and catch the exceptions it throws if the charset isn't
Additional charsets can be made available by configuring one or more charset
providers through provider configuration files. Such files are always named
as "java.nio.charset.spi.CharsetProvider" and located in the
"META-INF/services" directory of one or more classpaths. The files should be
encoded in "UTF-8". Each line of their content specifies the class name of a
charset provider which extends
A line should end with '\r', '\n' or '\r\n'. Leading and trailing whitespace
is trimmed. Blank lines, and lines (after trimming) starting with "#" whic