Am 18.10.2012 16:04, schrieb Xueming Shen:
On 10/18/2012 6:19 AM, Ulf Zibis wrote:
Oops, you are working at 6 in the morning?
Hi Sherman,
you could create the code table by help of a String constant, which would speed up the loading
and save a little footprint on the class file. (you have forgotten those tricks from sun.nio.cs
coders? ;-) )
The implementation probably needs more tuning.
Hopefully, some day we have arrays of primitive types in the class file's
constant pool.
But my main question:
Why don't you enqueue those coders in the well known sun.nio.cs.ext provider?
Base64 encoding is not a charset. Mainly it is supposed to be byte[]<->byte[]
coding.
Even for byte[]<=>char[]/String, Base64 "encode" byte[] to char[]/String and
"decode"
from char[]/String to byte[]. The "wrong" direction compared to charset
en/decoder.
1:0 for you.
I only had the ASCII/Unicode characters -> Base64 "en"coding in mind, which seems in fact a
Java-String to byte[] to char[]/String 2-step-encoding.
At least, I think, class Base64 should be hosted in java.nio.charset rather
than common java.util.
As I believe, that the usage of this encoding is far from common
you might be surprised how "common" it might be:-)
or surprised, why it wasn't part of the JDK before.
-Ulf
