Package it.could.util.encoding

This package contains a number of utility classes dealing with generic encoding of Strings.

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..
 

Package it.could.util.encoding Description

This package contains a number of utility classes dealing with generic encoding of Strings.

Although this might sound useless at first (as Strings do support encoding internally already), this class deals with a very subtle problem encountered when merging Java Strings 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 Strings 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.