i18n question.

[Alexander Bokovoy]

On Wed, Mar 10, 2004 at 04:03:34AM +0900, TAKAHASHI Motonobu wrote:
> |However, provided the CP932 mappings were "corrected" (e.g. using libiconv-1.9.1 pluglin) then
> |the utility would correctly convert ??? to U+FFE0. Then you have Unicode on the wire
> |(UCS-2LE/UTF-16LE), Unicode internally (UTF-8), and Unicode on Disk (UTF-8). So at least in
> |this case there would be no mapping problems. It's only when you want to use a legacy encoding
> |on disk for filenames that the internal string handling results in problems (e.g. 2nd byte
> |ASCII violates one of The Sanity Rules).
> 
> Yes, so if we want to use Samba 3.0 with Japanese, first we should fix
> (modify?) the conversion table of iconv(). Unfortunately only glibc
> 2.3.3 or later, or patched GNU libiconv are satisfied with Samba 3.0.
> 
> This means currently I have to say "Samba 3.0 cannot work correctly in
> Japanese environment for business use".
Note that it is not a fault of Samba but rather iconv(3) long standing
problem which bites every other application which utilizes it as well.
Of course, we might add specific CP932 table as charset module to bypass
relation on system iconv support and you are welcome to introduce it to
Samba CVS HEAD.

> And another problem is that U+FFF0 exists in "Restricted area" where 
> Unicode consosium does not recommend use of this area. As long
> as we keep compatibility, we could not waste "restricted area", that
> means, I think, that we do not completely migrate to Unicode world...
Yes, unfortunately...

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/