i18n question.

[Andrew Bartlett]

On Sun, 2004-03-07 at 16:11, TAKAHASHI Motonobu wrote:
> > Are you saying that UTF-8 does not encode all the Japanese glyphs that 
> > Japanese people want to use?
> 
> |Does the failure to encode that Japanese glyph in UTF8 matter?  Ie, even
> |if we chose different internal and unix charsets, would we be able to
> |deal with that character on the wire, where UTF16 is the only available
> |encoding?
> 
> *want* is ambigious...
> 
> Directly UTF-8 can encode all the Japanese scripts that is
> currently available on Windows platform.
> 
> Also Samba can support all Japanese scripts with UTF-8.
> 
> My point is that even if Samba can  support all Japanese scripts with
> UTF-8, we cannot migrate to UTF-8 soon because of lots of legacy
> application and systems that can recognize only legacy charsets.

OK, so it is the unix application problem (aka 'I have to fix all my NFS
clients too').

I have *no problem* with Samba supporting other character sets, that fit
in tridge's rules, and it looks like jra has the special cases required
in hand.

What I am glad to now understand it a bit of the problem space.  I would
still like to see a few more of my questions answered, and I still
strongly advocate the use of UTF8 as the single character for future
systems.  

However this all got lost in the noise about 'unicode is not enough',
'we should use USC4 for our internal interfaces' and 'have a different
FS character set'....

Anybody who suggests we should a character set with embedded nulls for
our internal character set, or who thinks we should have a different
character set for FS access compared to internally, has never programmed
a file-server in C, with reasonable C library requirements.

I realise we already have a 'hex' vfs module, but this only complicates
matters, as now filenames are in a different character set to usernames,
smb.conf paths, logfiles...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040307/0f771f68/attachment.bin