Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2005 17:10:20 GMT
From:      David Yu <davidyu@ucsd.edu>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/76520: Add new kernel-side libiconv converter for mounting NTFS under UTF-8
Message-ID:  <200501211710.j0LHAKKa044027@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/76520; it has been noted by GNATS.

From: David Yu <davidyu@ucsd.edu>
To: Andrey Chernov <ache@nagual.pp.ru>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/76520: Add new kernel-side libiconv converter for mounting
 NTFS under UTF-8
Date: Fri, 21 Jan 2005 09:07:51 -0800

 The encodings this converter intended to support are just general 
 encodings, i.e., encodings that can be directly computed from/to unicode 
 without mapping tables. Please don't confuse them with other encodings. 
 The current situation is that we still use translation table even with 
 encodings that can be efficiently (in terms of space) computed.
 
 Besides, those patches from R. Imura for UTF-8 just increased the 
 character size from 2 to 4 bytes. However, a character in UTF-8 can be 
 as long as 6 bytes.
 
 Andrey Chernov wrote:
 > On Fri, Jan 21, 2005 at 01:40:45AM +0000, David Yu wrote:
 > 
 >>>Description:
 >>
 >>The kernel-side libiconv currently used cannot convert unicode characters to UTF-8 which are longer than 2 bytes due to the lack of general encoding
 >>converter. This patch adds a new converter for encoding UCS-2 and UTF-8, but can easily extend to cover all general encodings.
 > 
 > 
 > There is no needs to adds something into kernel or we ends up in tons of 
 > unneded encodings embedded, encoding modules must be made as klds. I 
 > even remember I saw some code in the freebsd-i18n archive.
 > 
 
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501211710.j0LHAKKa044027>