Re: utf-8 filenames in phar files.

Hi Lester, On Tue, Apr 22, 2014 at 4:42 PM, Lester Caine <lester@lsces.co.uk> wrote: > Yasuo Ohgaki wrote: > >> BTW, without NFC normalization, I sure there will be unhappy users if >> users use >> it with >> OSX and Linux/Windows. OSX decomposes Unicode and there will be the same >> name >> path with different unicode string that appears the same on their >> terminal/etc >> on Linux/Windows. >> > > I don't think this problem is any different to the simple conflict between > upper and lower case 'normalizing' that happens currently? Each OS has it's > own standards and quirks which we have to put up with. It is a simple fact > that UTF-8 does NOT have a preferred standard, and everything that is valid > has to be handled. This is back to the question on case insensitive > comparisons, and if even that can be supported going forward. If different > OS's 'normalise' a string for their own purposes can we be expected to > provide different comparison rules for each? Or is it something that has to > be passed back up the chain for a library to handle more generically? > > Phar should not 'translate' anything ... it is where these strings are > used that should handle any additional processing? Phar could be extracted. Path name composition is mandatory for compatibility between OSX and Linux/Windows, since OSX decomposes path name intentionally. If you are curious, research how git works with OSX. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net