From owner-FreeBSD-tech-jp@jp.freebsd.org  Wed Dec 27 21:49:47 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id VAA77334;
	Wed, 27 Dec 2000 21:49:47 +0900 (JST)
	(envelope-from owner-FreeBSD-tech-jp@jp.FreeBSD.org)
Received: from mfo01.iij.ad.jp (mfo01.iij.ad.jp [202.232.2.118])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id VAA77329
	for <FreeBSD-tech-jp@jp.freebsd.org>; Wed, 27 Dec 2000 21:49:47 +0900 (JST)
	(envelope-from okuyamak@dd.iij4u.or.jp)
Received: from dd.iij4u.or.jp (dd.iij4u.or.jp [210.130.0.14])
	by mfo01.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id VAA21569;
	Wed, 27 Dec 2000 21:49:44 +0900 (JST)
Received: from localhost (washington.yamato.ibm.com [203.141.89.170])
	by dd.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with ESMTP id VAA15189;
	Wed, 27 Dec 2000 21:49:42 +0900 (JST)
Date: Wed, 27 Dec 2000 21:48:52 +0900 (JST)
Message-Id: <20001227.214852.92571718.okuyamak@dd.iij4u.or.jp>
To: sobomax@FreeBSD.org, FreeBSD-tech-jp@jp.freebsd.org
Cc: current@FreeBSD.org, bp@FreeBSD.org, audit@FreeBSD.org
From: Kenichi Okuyama <okuyamak@dd.iij4u.or.jp>
In-Reply-To: <86wvcmm4kc.wl@tkc.att.ne.jp>
References: <3A49BF05.9098A5D8@FreeBSD.org>
	<86wvcmm4kc.wl@tkc.att.ne.jp>
X-Mailer: Mew version 1.95b91 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: FreeBSD-tech-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: FreeBSD-tech-jp 2990
Subject: [FreeBSD-tech-jp 2990] Re: Unicode support in cd9660 [patch
 for review]
Errors-To: owner-FreeBSD-tech-jp@jp.freebsd.org
Sender: owner-FreeBSD-tech-jp@jp.freebsd.org
X-Originator: okuyamak@dd.iij4u.or.jp

I don't know why this mail came to me, but since I was given a
chance....(^^;)


>>>>> "MM" == Motomichi Matsuzaki <mzaki@e-mail.ne.jp> writes:
MM> * filenames recorded on Unix filesystems (e.g. FFS, MFS) use
MM>   an arbitrary codeset, for example Unicode.

Rather, let's use "codepage + codeset" information, so that we can
find the difference between Chinese "BONE" and Japanese "BONE".
WE NEED THEM TO BE DIFFERENT, YOU KNOW.

For example, save filename using 64bit per character, containing
codepage with 32bit, and codeset using UCS-4.

# We have enough diskspace and Memory to handle them, don't worry.
# And even if we didn't now, we will, within 2 years.

Do normalization for codepage against those characters that will not
be effected by codepage, so that comparison will be easier.


Many might say it's rediculous to have filename encoding different
from system call interface coding systems. But this is so only
because BUGGY UNICODE is current trend.

If we could have codeset that does not need codepage, the problem
did not occur. And the very reason why we happend to have this BUGGY
UNICODE, is because they stint bits. We should not do the same
mistakes.

So, there's only two selection.

1) Let's use Unicode for interface, and let's have large enough
   bits per characeter internally... like 256bits/character.

2) Let's create Truely Unified coding system, which not only allow
   us to describe the "currently used language", but also,
   exterminated languages like Cuneiform Characters as well.
   And use it for internally, and interface.
   ( This, also requres lot larger coding space than current.
     I think we do need 256bits anyway ).

best regards,
---- 
Kenichi Okuyama@Tokyo Research Lab, IBM-Japan, Co.
