abartlet at samba.org
Sun Mar 7 08:15:02 GMT 2004
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
> *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
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
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
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 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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040307/0f771f68/attachment.bin
More information about the samba-technical