Linus Torvalds:

quoted text
> But that's exactly the case he gave - 'ä' vs 'a¨' are exactly that: 
> different strings (not even characters: the second is actually a 
> multi-character) that just look the same.

But they are not different strings, they are canonically equivalent as
far as Unicode is concerned. They're even supposed to map to the same
glyph (if the font has an "ä", it should display it in both cases, if
it has an "a" and a combining diaeresis, it should make up one).

You cannot do a binary comparison of text to see if two strings are
equivalent.

quoted text
> You try to twist the argument by just claiming that they are the same
> "character". They aren't, unless you *define* character to be the
> same as "glyph".

Whereas you are confusing characters and code points.

"ä" and "a¨" use different code points, but they encode the same
character, and from the user's perspective it is the *character* that
is interesting (although he might confuse it with the glyph).


quoted text
> I don't know how NTFS works (I know it is Unicode-aware, and I think
> it encodes filenames in UCS-2 or possibly UTF-16,

Actually, NTFS is a bit broken. It sees file names as a string of
16-bit words. It doesn't check that it is valid UTF-16, or even valid
UCS-2, it allows almost anything.


Apple made Mac OS X handle filenames properly, by seeing that file
names are a string of characters, not code points, so they use a
canonical form for all characters (personally, I would have preferred
the pre-composed form, though).

-- 
\\// Peter - http://www.softwolves.pp.se/
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html