in reply to JSON::XS (and JSON::PP) appear to generate invalid UTF-8 for character in range 127 to 255

This post, and threads like it, make me wonder when programmers will wake up to the fact that unicode is one monumental cockup; and that until programmers collectively start rejecting it, rather than suffering it, they are enabling its continuance rather than promoting the search for a cure.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: JSON::XS (and JSON::PP) appear to generate invalid UTF-8 for character in range 127 to 255

Replies are listed 'Best First'.
Re^2: JSON::XS (and JSON::PP) appear to generate invalid UTF-8 for character in range 127 to 255
by karlgoethebier (Abbot) on Dec 07, 2014 at 10:50 UTC
    "...unicode is a one monumental cockup...start rejecting it...search for a cure."

    Dear BrowserUk,

    i'm d’accord with you when i remember how often i bothered myself with unicode related stuff.

    But what would be the cure?

    Best regard, Karl

    P.S.: And i really assume that your post isn't a very sophisticated joke that i didn't catch.

    «The Crux of the Biscuit is the Apostrophe»

[reply]
      But what would be the cure?
      1. Stop pretending that unicode is 'forwards compatible' from ASCII.

        The least useful property of unicode is that a trivial subset of it can appear to be 'simple text'.

      2. Stop pretending that unicode isn't a binary format.

        Every other binary format in common use, self-identifies through the use of 'signatures'. Eg. "GIF87a" & "GIF89a".

      3. Recognise that unicode isn't a single format, but many formats all lumped together in a confused and confusing mess.

        Some parts have several names, some of which are deprecated. Other associated terms have meant, and in some cases still do mean, two or more different things.

      4. Recognise that there is no need and no real benefit to the "clever" variable length encoding used by some of the formats.

        It creates far more problems than it fixes; and is the archetypal 'premature optimisation' that has long since outlived its benefit or purpose.

      5. Keep the good stuff -- the identification and standardisation of glyphs, graphemes and code points -- and rationalise the formats to a single, fixed-width, self-identifying format.

        Just imagine how much simpler, safer, and more efficient it would be if you could read the first few bytes of a file and *know* what it contains.

        Imagine how much more efficient it would be if to read the 10 characters starting at the 1073741823th character of a file, you simply did (say):

        seek FH, 1073741823 * 3 + SIG_SIZE, 0;
read( FH, $in, 10 * 3 );

        [download]

        Instead of having to a) guess the encoding; b) read all the bytes from the beginning counting characters as you go.

        Imagine all the other examples of stupid guesswork and inefficiency that I could have used.

        Imagine not having to deal with any of them.

      Imagine that programmers said "enough is enough"; give us a simple, single, sane, self-describing format for encoding the world's data.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

        You've confounded unicode with an encoding scheme (UTF-8). Some other encodings, say UCS-2, allow you to seek and read as in above example.

        ASCII is a binary encoding, too. Being the simplest and a common default, there's rarely any problem with it.

        Unicode is trouble, that's true. Its implementation almost invariably brings layers of abstraction, lasagna code, new levels of slow, new glitches, and sometimes, design changes that require extensive refactoring.

        As an example, take the notion of double-width glyphs. Very useful, to be sure, but also quite disruptive. Fixed-width terminal is no more; cell addressing is no longer character addressing; text area layout re-flows as you edit it. Why stop there, in the limbo between character-cell and full GUI, why not assign a point width to every char?

[reply]

        Thank you BrowserUk.

        Best regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

[reply]

        The least useful property of unicode is that a trivial subset of it can appear to be 'simple text'.

        I fully agree. It fails hard instead of failing safe.

        Perl could mitigate that problem by keeping track of whether a string is decoded or not.

        Recognise that unicode isn't a single format, but many formats all lumped together in a confused and confusing mess.

        I don't follow. Who thinks UTF-8 and UTF-16le are the same format?

        rationalise the formats to a single, fixed-width, self-identifying format.

        Not sure "self-identifying" makes sense. length($a) + length($b) == length($a . $b) is a nice property. It's possible to cause hard failures on misuse without self-identification.

[reply]
[d/l]

In Section Seekers of Perl Wisdom