9 ms·

Yeah, well, Unicode is hard. If it looks simple, it's only because you haven't looked carefully enough: http://www.unicode.org/versions/Unicode6.1.0/ http://w

by timr 14y ago

Yeah, well, Unicode is hard. If it looks simple, it's only because you haven't looked carefully enough: http://www.unicode.org/versions/Unicode6.1.0/ http://www.unicode.org/versions/Unicode6.1.0/ The latest published version of the standard (5.0) runs to almost 1500 pages: http://www.unicode.org/book/aboutbook.html http://www.unicode.org/book/aboutbook.html (Best quote from that page: “Hard copy versions of the Unicode Standard have been among the most crucial and most heavily used reference books in my personal library for years.” -- Donald Knuth) People think that Unicode support is just a matter of implementing multi-byte characters, but it's so much more: you've got collation rules, ligatures, rendering, line-breaking, punctuation, reading direction, and so on. Any technical standard that aims to cover all known human languages is going to be a little bit complex.

koenigdavidmj 14y ago
> People think that Unicode support is just a matter of implementing multi-byte characters, but it's so much more: you've got collation rules, ligatures, rendering, line-breaking, punctuation, reading direction, and so on. Any technical standard that aims to cover all known human languages is going to be a little bit complex. Half of those are irrelevant to MySQL or any other database. Those are front end problems. Even reading punctuation, text direction, and the like will only be important in more advanced collation orders (as opposed to just binary ordering, which he was using).
- timr 14y ago
  It's true that glyph rendering won't matter to a database store, and that binary collation is "good enough" for most people (but then again, "good enough" is how you get to a UTF-8 implementation that doesn't support 4-byte characters). That said, it's also true that Unicode characters outside of the BMP are still pretty exotic/specialized: http://stackoverflow.com/questions/5567249/what-are-the-most-common-non-bmp-unicode-characters-in-actual-use http://stackoverflow.com/questions/5567249/what-are-the-most... Is it "excusable" that MySQLs implementation of UTF-8 isn't standard? That's a judgment call (they are up-front about it in the docs). But given that most unicode characters "in the wild" lie in the BMP, I can see how they'd make that trade-off. There might well be a technical limitation lurking somewhere in the database internals that made 4-byte characters a problem.
  - aidenn0 14y ago
    Then call it utf8-bmp, not utf8!
  - sedev 14y ago
    No, it's not excusable - the MySQL project had a trivial alternative: don't call it UTF8! The options are simple: implement UTF-8 correctly and call your implementation UTF-8, or implement just the BMP and name accordingly. They did neither: effectively, they lied to end-users. That's deeply, deeply problematic.
    - timr 14y ago
      "they lied to end-users, effectively" Yeah, that's not exaggeration at all. Because it's not as if they very clearly document exactly what they support: http://dev.mysql.com/doc/refman/5.1/en/charset-unicode.html http://dev.mysql.com/doc/refman/5.1/en/charset-unicode.html
      - pepve 14y ago
        Sure, so let's call this button that erases your data "list files", and just very clearly document it. It's not lying if we change the definition.
        sedev 14y ago
        Bingo. That's why I used the "effectively" qualifier - if my toolchain says "oh this is UTF-8," then I should be able to trust that it's for-real, honest-to-goodness, spec-compliant UTF-8. If it's "oh this is the part of UTF-8 that was easy to implement " instead, then that tool has lied to me. I shouldn't have to read the documentation to find out that something is not what it claims to be. Bonus points for the documentation brazenly ignoring that they're implementing something that's not spec-compliant and naming it like it is.
        deafbybeheading 14y ago
        Well, to be fair, MySQL has a storied history of implementing 95% of a feature, calling it good enough, and shipping it. And while, as a Postgres user, my tone here may be a little snide, I also say this with grudging respect: I think there is a point at which implementing n% of a feature X and calling it X (rather than MaybeX or MostlyX) does give you some momentum and practical compatibility that you wouldn't have otherwise. Is it dishonest to hide the limitations regarding the edge cases in some documentation no one will read? Maybe. But will providing the feature solve more problems than it causes? Quite possibly. I don't agree with MySQL's decision with respect to UTF-8, but I do understand it.
est 14y ago
The one thing boggles my mind is that Unicode is, as a matter of fact, not a universal coding. It's a cluster fuck of multiple encodings (from a same code point). We really should call it multicode, it only solves problems by introducing more. You got problems with Unicode? You are not using the right unicode. Try another unicode.
gioele 14y ago
> The latest published version of the standard (5.0) runs to almost 1500 pages: Most of those pages are the just repertoire: a printout of a long uneventful table that lists all the available code-points. For each code-point is gives you a reference pre-rendered glyph, the languages where you can find it, the kind of character it is (numeric, alphabetic, symbol) and so on. From an implementer point of view there are about 200 pages of interesting and extremely detailed stuff. The rest of the pages can be downloaded as text tables from the Unicode site and its companion sites.
lambda 14y ago
The thing is, the vast majority of this isn't needed by most applications. For instance, in a database, all they need is to encode and decode strings properly when going to or coming from external sources. That's all that is being asked for here; that when MySQL says "UTF-8", they really mean "UTF-8", not some broken subset of it.

by timr 14y ago

koenigdavidmj 14y ago

> People think that Unicode support is just a matter of implementing multi-byte characters, but it's so much more: you've got collation rules, ligatures, rendering, line-breaking, punctuation, reading direction, and so on. Any technical standard that aims to cover all known human languages is going to be a little bit complex. Half of those are irrelevant to MySQL or any other database. Those are front end problems. Even reading punctuation, text direction, and the like will only be important in more advanced collation orders (as opposed to just binary ordering, which he was using).

timr 14y ago
It's true that glyph rendering won't matter to a database store, and that binary collation is "good enough" for most people (but then again, "good enough" is how you get to a UTF-8 implementation that doesn't support 4-byte characters). That said, it's also true that Unicode characters outside of the BMP are still pretty exotic/specialized: http://stackoverflow.com/questions/5567249/what-are-the-most-common-non-bmp-unicode-characters-in-actual-use http://stackoverflow.com/questions/5567249/what-are-the-most... Is it "excusable" that MySQLs implementation of UTF-8 isn't standard? That's a judgment call (they are up-front about it in the docs). But given that most unicode characters "in the wild" lie in the BMP, I can see how they'd make that trade-off. There might well be a technical limitation lurking somewhere in the database internals that made 4-byte characters a problem.
- aidenn0 14y ago
  Then call it utf8-bmp, not utf8!
- sedev 14y ago
  No, it's not excusable - the MySQL project had a trivial alternative: don't call it UTF8! The options are simple: implement UTF-8 correctly and call your implementation UTF-8, or implement just the BMP and name accordingly. They did neither: effectively, they lied to end-users. That's deeply, deeply problematic.
  - timr 14y ago
    "they lied to end-users, effectively" Yeah, that's not exaggeration at all. Because it's not as if they very clearly document exactly what they support: http://dev.mysql.com/doc/refman/5.1/en/charset-unicode.html http://dev.mysql.com/doc/refman/5.1/en/charset-unicode.html
    - pepve 14y ago
      Sure, so let's call this button that erases your data "list files", and just very clearly document it. It's not lying if we change the definition.
      - sedev 14y ago
        Bingo. That's why I used the "effectively" qualifier - if my toolchain says "oh this is UTF-8," then I should be able to trust that it's for-real, honest-to-goodness, spec-compliant UTF-8. If it's "oh this is the part of UTF-8 that was easy to implement " instead, then that tool has lied to me. I shouldn't have to read the documentation to find out that something is not what it claims to be. Bonus points for the documentation brazenly ignoring that they're implementing something that's not spec-compliant and naming it like it is.
      - deafbybeheading 14y ago
        Well, to be fair, MySQL has a storied history of implementing 95% of a feature, calling it good enough, and shipping it. And while, as a Postgres user, my tone here may be a little snide, I also say this with grudging respect: I think there is a point at which implementing n% of a feature X and calling it X (rather than MaybeX or MostlyX) does give you some momentum and practical compatibility that you wouldn't have otherwise. Is it dishonest to hide the limitations regarding the edge cases in some documentation no one will read? Maybe. But will providing the feature solve more problems than it causes? Quite possibly. I don't agree with MySQL's decision with respect to UTF-8, but I do understand it.

est 14y ago

The one thing boggles my mind is that Unicode is, as a matter of fact, not a universal coding. It's a cluster fuck of multiple encodings (from a same code point). We really should call it multicode, it only solves problems by introducing more. You got problems with Unicode? You are not using the right unicode. Try another unicode.

gioele 14y ago

> The latest published version of the standard (5.0) runs to almost 1500 pages: Most of those pages are the just repertoire: a printout of a long uneventful table that lists all the available code-points. For each code-point is gives you a reference pre-rendered glyph, the languages where you can find it, the kind of character it is (numeric, alphabetic, symbol) and so on. From an implementer point of view there are about 200 pages of interesting and extremely detailed stuff. The rest of the pages can be downloaded as text tables from the Unicode site and its companion sites.

lambda 14y ago

The thing is, the vast majority of this isn't needed by most applications. For instance, in a database, all they need is to encode and decode strings properly when going to or coming from external sources. That's all that is being asked for here; that when MySQL says "UTF-8", they really mean "UTF-8", not some broken subset of it.