4 ms·

For a dissenting view on Unicode, see: https://news.ycombinator.com/item?id=6863824 https://news.ycombinator.com/item?id=6863824 https://news.ycombinator.com/

For a dissenting view on Unicode, see: https://news.ycombinator.com/item?id=6863824 https://news.ycombinator.com/item?id=6863824 https://news.ycombinator.com/item?id=5362200 https://news.ycombinator.com/item?id=5362200 (warning: this page may crash some browsers) Anything is better than the old mess of unpredictable, ad-hoc encodings, but Unicode is so academic and impractical that it isn't really all that much better. We don't know if it's safe; we do know it can crash browsers with plaintext (have fun with that second link!); and we _definitely_ know that Unicode isn't "the solution to conflict and corruption" like the article says. For a case of corruption that could only be done with Unicode, see the first comment to this: https://news.ycombinator.com/item?id=10437619 https://news.ycombinator.com/item?id=10437619 Unicode is better than nothing, where "nothing" is "webpages that can only display 256 characters" or thereabouts; but it has a lot of mistakes and clumsy characteristics. "I � Unicode" ("I Entity Unicode", using the Unicode glyph for "unrecognized character") is about as far as affection for Unicode should go; I used to have that on a bumper sticker.

nikdaheratik 11y ago
The first and third dissents are dumb. Basically the attack is that, because the glyphs used to represent the character look the same but are actually different code-points they have potential to be abused. But there's no reason why this would only be limited to Unicode. Any other encoding system that keeps a cyrillic alphabet in a separate code range from the latin one would have this problem. And it's much less efficient for your text chomping program that reads cyrillic to check all of a character range except for the 2-3 that also have existing latin characters that look the same as the cyrillic ones. And I really don't understand why "I Entity Unicode" is even a valid complaint. Or what it's even complaining about If your font doesn't have a glyph that matches your character, it's not going to show up no matter which encoding scheme you use. Unicode got alot of buy-in from publishers as it met all of their needs. The tech companies followed suit, eventually, which is a heck of alot better than the dark ages when each computer company had their own custom platform for these encodings in the U.S. alone. And then there's individual solutions to the problem overseas where the wheel was reinvented for each language there.
- clock_tower 11y ago
  "Any other encoding system that keeps a cyrillic alphabet in a separate code range from the latin one would have this problem." Then isn't the solution to put the Cyrillic alphabet in the same space as the Latin one when the glyphs are identical? In general, Unicode should merge code points a lot more readily than it does; it shouldn't have some of the strange things it does have, which hog space that would be better used putting semi-common Chinese characters in the Basic Multilingual Pane; and the way it handles hangul is just embarrassing. It's better than nothing (and better than the Codepage-<Insert Number> variety of solutions), but that doesn't mean it's good; that's what I mean by "I Entity Unicode".

nikdaheratik 11y ago

The first and third dissents are dumb. Basically the attack is that, because the glyphs used to represent the character look the same but are actually different code-points they have potential to be abused. But there's no reason why this would only be limited to Unicode. Any other encoding system that keeps a cyrillic alphabet in a separate code range from the latin one would have this problem. And it's much less efficient for your text chomping program that reads cyrillic to check all of a character range except for the 2-3 that also have existing latin characters that look the same as the cyrillic ones. And I really don't understand why "I Entity Unicode" is even a valid complaint. Or what it's even complaining about If your font doesn't have a glyph that matches your character, it's not going to show up no matter which encoding scheme you use. Unicode got alot of buy-in from publishers as it met all of their needs. The tech companies followed suit, eventually, which is a heck of alot better than the dark ages when each computer company had their own custom platform for these encodings in the U.S. alone. And then there's individual solutions to the problem overseas where the wheel was reinvented for each language there.

clock_tower 11y ago
"Any other encoding system that keeps a cyrillic alphabet in a separate code range from the latin one would have this problem." Then isn't the solution to put the Cyrillic alphabet in the same space as the Latin one when the glyphs are identical? In general, Unicode should merge code points a lot more readily than it does; it shouldn't have some of the strange things it does have, which hog space that would be better used putting semi-common Chinese characters in the Basic Multilingual Pane; and the way it handles hangul is just embarrassing. It's better than nothing (and better than the Codepage-<Insert Number> variety of solutions), but that doesn't mean it's good; that's what I mean by "I Entity Unicode".