| … | |
… | |
| 102 | package JSON::XS; |
102 | package JSON::XS; |
| 103 | |
103 | |
| 104 | no warnings; |
104 | no warnings; |
| 105 | use strict; |
105 | use strict; |
| 106 | |
106 | |
| 107 | our $VERSION = '2.231'; |
107 | our $VERSION = '2.232'; |
| 108 | our @ISA = qw(Exporter); |
108 | our @ISA = qw(Exporter); |
| 109 | |
109 | |
| 110 | our @EXPORT = qw(encode_json decode_json to_json from_json); |
110 | our @EXPORT = qw(encode_json decode_json to_json from_json); |
| 111 | |
111 | |
| 112 | sub to_json($) { |
112 | sub to_json($) { |
| … | |
… | |
| 1183 | when your channel for JSON transfer is not 8-bit clean or the encoding |
1183 | when your channel for JSON transfer is not 8-bit clean or the encoding |
| 1184 | might be mangled in between (e.g. in mail), and works because ASCII is a |
1184 | might be mangled in between (e.g. in mail), and works because ASCII is a |
| 1185 | proper subset of most 8-bit and multibyte encodings in use in the world. |
1185 | proper subset of most 8-bit and multibyte encodings in use in the world. |
| 1186 | |
1186 | |
| 1187 | =back |
1187 | =back |
|
|
1188 | |
|
|
1189 | |
|
|
1190 | =head2 JSON and ECMAscript |
|
|
1191 | |
|
|
1192 | JSON syntax is based on how literals are represented in javascript (the |
|
|
1193 | not-standardised predecessor of ECMAscript) which is presumably why it is |
|
|
1194 | called "JavaScript Object Notation". |
|
|
1195 | |
|
|
1196 | However, JSON is not a subset (and also not a superset of course) of |
|
|
1197 | ECMAscript (the standard) or javascript (whatever browsers actually |
|
|
1198 | implement). |
|
|
1199 | |
|
|
1200 | If you want to use javascript's C<eval> function to "parse" JSON, you |
|
|
1201 | might run into parse errors for valid JSON texts, or the resulting data |
|
|
1202 | structure might not be queryable: |
|
|
1203 | |
|
|
1204 | One of the problems is that U+2028 and U+2029 are valid characters inside |
|
|
1205 | JSON strings, but are not allowed in ECMAscript string literals, so the |
|
|
1206 | following Perl fragment will not output something that can be guaranteed |
|
|
1207 | to be parsable by javascript's C<eval>: |
|
|
1208 | |
|
|
1209 | use JSON::XS; |
|
|
1210 | |
|
|
1211 | print encode_json [chr 0x2028]; |
|
|
1212 | |
|
|
1213 | The right fix for this is to use a proper JSON parser in your javascript |
|
|
1214 | programs, and not rely on C<eval>. |
|
|
1215 | |
|
|
1216 | If this is not an option, you can, as a stop-gap measure, simply encode to |
|
|
1217 | ASCII-only JSON: |
|
|
1218 | |
|
|
1219 | use JSON::XS; |
|
|
1220 | |
|
|
1221 | print JSON::XS->new->ascii->encode ([chr 0x2028]); |
|
|
1222 | |
|
|
1223 | And if you are concerned about the size of the resulting JSON text, you |
|
|
1224 | can run some regexes to only escape U+2028 and U+2029: |
|
|
1225 | |
|
|
1226 | use JSON::XS; |
|
|
1227 | |
|
|
1228 | my $json = JSON::XS->new->utf8->encode ([chr 0x2028]); |
|
|
1229 | $json =~ s/\xe2\x80\xa8/\\u2028/g; # escape U+2028 |
|
|
1230 | $json =~ s/\xe2\x80\xa9/\\u2029/g; # escape U+2029 |
|
|
1231 | print $json; |
|
|
1232 | |
|
|
1233 | This works because U+2028/U+2029 are not allowed outside of strings and |
|
|
1234 | are not used for syntax, so replacing them unconditionally just works. |
|
|
1235 | |
|
|
1236 | Note, however, that fixing the broken JSON parser is better than working |
|
|
1237 | around it in every other generator. The above regexes should work well in |
|
|
1238 | other languages, as long as they operate on UTF-8. It is equally valid to |
|
|
1239 | replace all occurences of U+2028/2029 directly by their \\u-escaped forms |
|
|
1240 | in unicode texts, so they can simply be used to fix any parsers relying on |
|
|
1241 | C<eval> by first applying the regexes on the encoded texts. |
|
|
1242 | |
|
|
1243 | Another problem is that some javascript implementations reserve |
|
|
1244 | some property names for their own purposes (which probably makes |
|
|
1245 | them non-ECMAscript-compliant). For example, Iceweasel reserves the |
|
|
1246 | C<__proto__> property name for it's own purposes. |
|
|
1247 | |
|
|
1248 | If that is a problem, you could parse try to filter the resulting JSON |
|
|
1249 | output for these property strings, e.g.: |
|
|
1250 | |
|
|
1251 | $json =~ s/"__proto__"\s*:/"__proto__renamed":/g; |
|
|
1252 | |
|
|
1253 | This works because C<__proto__> is not valid outside of strings, so every |
|
|
1254 | occurence of C<"__proto__"\s*:> must be a string used as property name. |
|
|
1255 | |
|
|
1256 | If you know of other incompatibilities, please let me know. |
| 1188 | |
1257 | |
| 1189 | |
1258 | |
| 1190 | =head2 JSON and YAML |
1259 | =head2 JSON and YAML |
| 1191 | |
1260 | |
| 1192 | You often hear that JSON is a subset of YAML. This is, however, a mass |
1261 | You often hear that JSON is a subset of YAML. This is, however, a mass |
