From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: [PATCH] Full NLS support for HFS (classic) filesystem Date: Thu, 02 Jun 2005 10:24:25 +0100 Message-ID: <1117704266.11696.5.camel@imp.csi.cam.ac.uk> References: <429B1E35.2040905@rambler.ru> <429C68A0.20003@rambler.ru> <429CBC75.2030605@rambler.ru> <429CD545.1070308@rambler.ru> <1117550958.8073.30.camel@imp.csi.cam.ac.uk> <429F0AF1.5060705@rambler.ru> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Roman Zippel , linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:32646 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S261295AbVFBJYb (ORCPT ); Thu, 2 Jun 2005 05:24:31 -0400 To: Pavel Fedin In-Reply-To: <429F0AF1.5060705@rambler.ru> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-06-02 at 09:34 -0400, Pavel Fedin wrote: > Anton Altaparmakov wrote: > > NLS is fundamentally broken so there is no point in trying to use clever > > dynamic tables to do it. Just ignore it is IMO the correct way. > > > > btw. not having mappings is not even the biggest problem. It gets much > > worse and even Pavel's dynamic mappings are not actually going to work. > > For example there are some characters in asian languages which when > > translated will give a character but when you then reverse translate > > this character you end up with something that is not the same as the > > starting character. > > Did you verify this or just suggest? My dynamic mapping should work > because reverse translation table is created by reversing "direct" > translation dynamic table, which is built from two NLSes. No, I have not verified it. I do not use HFS at all. But your direct translation dynamic table will already be ambiguous if the "right" NLS pages were used to create it. Or what do you do when two different characters in on NLS page are translated to the _sam_ character in the other NLS page? > > a lot of asian people have complained > > to me about ntfs when used with codepages. All of them went away happy > > when I told them to tell the ntfs driver to use utf8... > > Yes, with utf8 everything really works because every character is > reverse-translatable in this case. With HFS too - look at my > implementation, it handles iocharset=utf8 as a special case where direct > and reverse translation is done directly via NLS module and there's no > need for dynamic tables. > But in Russia UTF-8 is not widely used because of no need to. We > prefer direct compatibility with ASCII files from other systems. Where is the problem with compatibility? Any sane application will translate files on the fly. On my SUSE 9.3 box (uses UTF8) when I open a text file in vim (my editor of choice) and the text file contained characters in a codepage, vim translates it to the corresponding UTF8 character and then translates it back into the original codepage when I save the file. (It shows a "[translated]" message at the bottom of the screen after I open such a file so I know this has happened.) Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/