4 ms·
Indeed not: there is an almost infinite number of things that Latin-1 did not have; e.g. any characters beyond Western Europe. While keeping the 128-256 block c
by Piskvorrr 9y ago
Indeed not: there is an almost infinite number of things that Latin-1 did not have; e.g. any characters beyond Western Europe. While keeping the 128-256 block compatible was a part of early Unicode (hence the "one-glyph" é), having composed characters was a Unicode primary design goal (hence e and the composing accent). A pure Unicode implementation would have been better, maybe; what we have instead is one that has gained mass adoption.
https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block) https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_bl...
- nottorp 9y agoWell, composed characters may or may not have been a good idea, although they're a pain for text search if you ask me. But why oh why did they have to specify FOUR normalization forms? Ref: http://www.unicode.org/reports/tr15/#Norm_Forms http://www.unicode.org/reports/tr15/#Norm_Forms
- Piskvorrr 9y ago¯\_(ツ)_/¯
- TazeTSchnitzel 9y agoBecause you need a normalisation form fit for your particular purpose.
- the_mitsuhiko 9y ago> But why oh why did they have to specify FOUR normalization forms? Ignoring compatibility normalizations there are really only two and neither of those two you can remove. So that's a bit of an odd question. If you want to remove the compatibility forms that's fair but nobody is force to use them. You can consider them "partially normalized" or "not normalized at all" for all intents and purposes
- cryptonector 9y agoPre-composed characters were needed to make transcoding to ISO-8859-* fast. Also, for Hangul, though decomposition is the better form to use normally (since it's phonetic, not syllabic), conversion to pre-composed syllabic form is very useful sometimes. Even without pre-composition there would have been multiple equivalent forms of writing any character that requires more than one combining codepoint. The only way to have avoided normalization altogether would have been to have no combining codepoints, and only a complete set of pre-compositions. This would have been less flexible, and very obnoxious for Hangul and possibly others. I believe the need for normalization was simply unavoidable. It's not the fault of Unicode but the fault of humans' script designs. And it's OK.
- cryptonector 9y agoYou can ignore the K forms. So that's two forms, really, NFC and NFD.
- rurban 9y agoThe biggest actual problem is Greek vs Cyrillic. They appear the same, but use different encodings. Any filename (directory entry as identifier) must forbid mixed scripts. See TR31 http://www.unicode.org/reports/tr31/ http://www.unicode.org/reports/tr31/ Combining marks or RTL switching tricks are the other popular spoofs.
- cryptonector 9y agoConfusables are a real problem. Some Cyrillic and Greek letters even look like Latin letters. And in some fonts '1' (one) and 'l' (ell) look the same even in Latin. Dealing with these is much harder than with normalization forms. And confusables are a source of serious security headaches.
- Piskvorrr 9y ago1Il|!
- kps 9y ago> Any filename (directory entry as identifier) must forbid mixed scripts. So I'm not allowed to name my files “A=πr²” or “10kΩ Резисторы”?
- rurban 9y agoAccording to me not if you mixed Greek with Cyrillic, and not Math with Cyrillic. Unfortunately nobody cares about Unicode identifier security models. Garbage out is the most popular ideology.
- kps 9y agoI take the view that modern file names are human readable labels, not access keys. “10kΩ Резисторы” is Cyrillic, Latin, and Greek (U+2126 canonically maps to U+03A9). A proposal that disallows that but allows “10kΩ Resistors” is a political non-starter.