A bug in filesystem bootstrap (unix/ linux) prevents
xueming.shen at oracle.com
Thu Jul 5 18:02:11 UTC 2012
On 07/05/2012 01:40 AM, Dawid Weiss wrote:
>> export LC_ALL=en_US.UTF-8; java Foo
> Not really, the shell won't let you use a multibyte locale (because of
> issues with null-terminated strings). And multibyte (with BOM) is most
> fun when you're trying to find buggy code ;)
Encodings for those Chinese, Japnese, Korean locales are all "multibyte"
is a multibyte encoding, most recent unix/linux platform should have no
to work with "multibyte" locale. In fact UTF-16 is normally not
multibye (mb), but wide char, as "wc". There are reason(s) why you
only see utf-8 locale but no utf-16 locale on Unix/Linux based platforms
you have "W" version of APIs and "A" version of APIs (and even "T"
some APIs) on Windows platfrom.
I agree it might be helpful if there is mechanism that you can change
charset" used by various Java APIs, similar to what you do with
With the introduction of sun.jnu.encoding (which takes over the
the encoding jvm used to talk to the underlying OS APIs) it might be
reduce the scope of system property file.encoding to only for the
of the "file content" and do something here, but it is not on the
priority list for now.
Btw, I need to make it clear here that sun.jnu.encoding is purely an
detail, app is not supposed to use it for whatever purpose.
>> I would assume there is no en_US.UTF-16 locale there :-)
> I wish there were. It'd make people care more ;)
More information about the core-libs-dev