DragonFly BSD
DragonFly kernel List (threaded) for 2004-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: UTF-8 and local charsets in the VFS layer


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 12 Mar 2004 10:39:32 -0800 (PST)

:
:Hi all,
:what is the attitude of the DragonFly community towards choosing UTF-8
:as output character set for all those filesystems which can support
:multiple?
:
:We are currently in a situation, where the kernel doesn't care
:for the local filesystem, has/could have some conversion hooks for 
:removable and remote filesystems. E.g. ISO-9660 with Joliet or RR extension
:...

    Well, I guess the question is: what exactly would need to be done?  E.G.
    our normal UFS filesystem can use any character from 0x01-0xFF, other then
    '/', in filenames, so it should have no problem storing UTF-8.  It kinda sounds
    like this is a userland issue rather then a kernel issue for the most part.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:can be the classical ISO-8859-1/15 most of us supposedly are using,
:UTF-8 / UCS-2 or even other character sets. The situation is even somewhat
:different for UDF which I have a working version of. UDF natively provides
:UCS2 (16 bit Unicode) which needs to be converting anyway.
:
:For the normal English speaking community, nothing will change. Having
:a _semantically_ default for UTF-8 doesn't increase the work for the
:kernel in the near feature, but it can make decisions for filesystems
:much more coherent. Choosing UTF-8 over other representations of Unicode
:has the advantage of being 100% API compatible, the which situation that
:can happen is an application showing garbage filenames. But that can
:happen now too :)
:
:To give some hints about the others, Windows NT+ has natively Unicode
:support, MacOS X has and Plan 9 (hehe) has it too.
:
:Joerg



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]