The following program passes its tests for me, side-stepping the source code encoding:

    use utf8;
    use 5.16.0;
    use Test::More;
    use Test::utf8;
    use JSON::XS;

    BEGIN {
        # damn it
        my $builder = Test::Builder->new;
        foreach (qw/output failure_output todo_output/) {
            binmode $builder->$_, ':encoding(UTF-8)';
        }
    }

    foreach my $string ( 'Deliver \N{LEFT-POINTING DOUBLE ANGLE QUOTAT
+ION MARK}French Bread\N{RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK}',
+ '日本国' ) {
        my $hashref = { value => $string };
        is_sane_utf8 $string, "String: $string";
        my $json = encode_json($hashref);
        is_sane_utf8 $json, "JSON: $json";
        say STDERR $json;
    }
    diag ord('»');

    done_testing;
[download]

On the Windows command line, I get ord('»') also as 187 for perl -wle "print ord('»')"... I'm not sure what to make of this, but I feel confirmed in my intention to have no characters above code 127 in my source code...

Thanks for introducing me to Test::utf8 - this feels useful when diagnosing mojibake issues.

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.

"...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»

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.

The provided test sample on my Perl v5.20.1 / Linux passes.

So the string containing guillemets («») is valid UTF-8, but the resulting JSON is not. What am I missing? The `utf8` pragma is correctly marking my source.

(encode_json) Converts the given Perl data structure to a UTF-8 encoded, binary string (that is, the string contains octets only). Croaks on error.

(is_sane_utf8) This test fails if the string contains something that looks like it might be dodgy utf8, i.e. containing something that looks like the multi-byte sequence for a latin-1 character but perl hasn't been instructed to treat as such... This test fails when... The string contains utf8 byte sequences and the string hasn't been flagged as utf8 (this normally means that you got it from an external source like a C library;

Ha! What would you say now, ikegami?

That Ovid used a function without reading what it does first. My exact words are here.

Ha! What would you say now, ikegami? When people like James Keenan and Ovid don't understand how this stuff works... can less experienced programmers even hope to ever get this right?

So Ovid got confused about the basics, when dealing with some Test::: extas, so what? Its ok to get confused

It's not the basics, this is the problem. I'm certainly NOT blaming people for becoming confused... It's Perl's problem (ikegami disagrees).

Looking at the source of the test in question, is_sane_utf8 tests whether the string was improperly 'upgraded' (the so-called 'double encoding')... rejecting the JSON is more or less a side effect. Quickly, tell me, what that actually means?