|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
String
s.
See:
Description
Interface Summary | |
Encodable | The Encodable interface describes an Object whose
String representation can vary depending on the encoding used. |
EncodingAware | The EncodingAware interface describes an Object aware
of multiple encodings existing withing the platform. |
Class Summary | |
EncodingTools | An utility class providing various static methods dealing with
encodings and Encodable objects.. |
This package contains a number of utility classes dealing with generic
encoding of String
s.
Although this might sound useless at first (as String
s
do support encoding internally already), this class deals with a very
subtle problem encountered when merging Java String
s
and old byte-based (non internationalized) transports, such as
Base 64 and URL encoding.
Let's consider (as an example) the URL encoded String
%C2%A3 100
can be easily decomposed in a byte array using
URL decoding techniques: we would end up with the following byte array:
0x0C2 0x0A3 0x20 0x31 0x30 0x30
.
This byte-array, though, doesn't tell us anything about how to represent
this as a readable and usable String
in Java. To be
able to convert this we have to decode it again using a charset (or an
encoding).
So, for example, if we were to decode the above mentioned byte array using
the ISO-8859-1 encoding, we would obtain the string
"£ 100
", or in details:
If we were to decode the same byte sequence using UTF-8, on the
other hand, we would obtain the (quite different) string
"£ 100
", or in details:
Therefore, as a conclusion, when Java String
s are
encoded using Base 64, URL encoding, or similar techiques, one always
have to remember that encoding (or decoding) must be done twice, and
this package provides a way to deal with this mechanism.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |