Scrambled umlauts since upgrade from JSON1 to JSON2 in Perl

Question

I wondered why some german umlauts were scrambled on our page. Then i found out that the recent version of JSON (i use 2.07) does convert strings in an other manner than JSON 1.5.

Problem here is that i have a hash with strings like

use Data::Dumper;
my $test = {
  'fields' => 'überrascht'
};

print Dumper(to_json($test)); gives me

$VAR1 = "{ \"fields\" : \"\x{fc}berrascht\" } "; 

Using the old module using

$json = JSON->new();
print Dumper ($json->to_json($test));

gives me (the correct result)

$VAR1 = '{"fields":[{"title":"überrascht"}]}'; 

So umlauts are scrammbled using the new JSON 2 module.

What do i need to get them correct?

Update: It might be bad to use Data::Dumper to show output, because Dumper uses its own encoding. Well, a difference in the result from Dumper shows that anything is treated differently here. It might be better to describe the backend as Brad mentioned: The json string gets printed using Template-Toolkit and then gets assigned to a javascript variable for further use. The correct javascript shows something like this

{
    "title" : "Geändert",
},

using the new module i get

{
    "title" : "Geändert",
},

The target page is in 8859-1 (latin1). Any suggestions?

Answer 1

\x{fc} is ü, at least in Latin-1, Latin-9 etc. Also, ü is codepoint U+00FC in Unicode. However, we want UTF-8 (I suppose). The easiest solution to get UTF-8 string literals is to save your Perl source code with this encoding, and put a use utf8; at the top of your script.

Then, encoding the string as JSON yields correct output:

use strict; use warnings; use utf8;
use Data::Dumper; use JSON;
print Dumper encode_json {fields => "nicht überrascht"};

The encode_json assumes UTF-8. Read the documentation for more info.

Output:

$VAR1 = '{"fields":"nicht überrascht"}';

(JSON module version: 2.53)

Answer 2

my $json_text = to_json($data);

is short for

my $json_text = JSON->new->encode($data);

This returns a string of Unicode Code Points. U+00FC is indeed the correct Unicode code point for "ü", so the output is correct. (As proof, the HTML source for that is actually "ü".)

It's hard to tell what your original output actually contained (since you showed non-ASCII characters), so it's hard to determine what your problem is actually.

But one thing you must do before outputing the string is to convert it from a string of code points into bytes, say, by using Encode's encode or encode_utf8.

my $json_cp1252 = encode('cp1252', to_json($data));

my $json_utf8 = encode_utf8(to_json($data));

If the appropriate encoding is UTF-8, you can also use any of the following:

my $json_utf8 = to_json($data, { utf8 => 1 });

my $json_utf8 = encode_json($data);

my $json_utf8 = JSON->new->utf8->encode($data);

Answer 3

Use encode_json instead. According to the manual it converts the given Perl data structure to a UTF-8 encoded, binary string.

Regarding your update: If you actually want to produce JSON in Latin1 (ISO-8859-1), you can try:

to_json($test, { latin1 => 1 })

Or

JSON->new->latin1->encode($test)

Note that if you dump the result, getting \x{fc} for ü is correct in this case. I guess that the root of your problem is that you receive text in Perl's UTF-8 format from somewhere. In this case, the latin1 option of the JSON module is needed.

You can also try to use ascii instead of latin1 as the safest option.

Another solution might be to specify an output encoding for Template-Toolkit. I don't know if that's possible. Or, you could encode your result as Latin1 in the final step before sending it to the client.

Answer 4

Strictly-speaking, Latin-1-encoded JSON is not valid JSON. The JSON spec allows UTF-8, UTF-16 or UTF-32 encodings.

If you want to be standards-compliant or you want to ensure your JSON will be compatible with both your current pages and future UTF-8-based pages, you need to use JSON->new->utf8->encode($str). Being strict about generated valid JSON could save you lots of headaches in the future.

You can translate UTF-8 JSON to Latin-1 using client-side Javascript if you need to, using this trick.

The ascii option also produces valid JSON, by escaping any non-ASCII characters using valid JSON unicode escapes. But the latin1 option does not, and therefore should be avoided IMHO. The utf8(0) option should be avoided too unless you specify an encoding when writing the data out to clients: utf8(0) is subtly different from the utf8 option in that it generates Perl character strings instead of byte strings. If you do any I/O using character strings without specifying an encoding, Perl will translate it on-the-fly back to Latin-1. The utf8 option generates raw UTF-8 bytes, which are perfect for doing raw I/O.