… | |
… | |
245 | "encode" or "decode" to their minimum size possible. This can save |
245 | "encode" or "decode" to their minimum size possible. This can save |
246 | memory when your JSON texts are either very very long or you have |
246 | memory when your JSON texts are either very very long or you have |
247 | many short strings. It will also try to downgrade any strings to |
247 | many short strings. It will also try to downgrade any strings to |
248 | octet-form if possible: perl stores strings internally either in an |
248 | octet-form if possible: perl stores strings internally either in an |
249 | encoding called UTF-X or in octet-form. The latter cannot store |
249 | encoding called UTF-X or in octet-form. The latter cannot store |
250 | everything but uses less space in general. |
250 | everything but uses less space in general (and some buggy Perl or C |
|
|
251 | code might even rely on that internal representation being used). |
|
|
252 | |
|
|
253 | The actual definition of what shrink does might change in future |
|
|
254 | versions, but it will always try to save space at the expense of |
|
|
255 | time. |
251 | |
256 | |
252 | If $enable is true (or missing), the string returned by "encode" |
257 | If $enable is true (or missing), the string returned by "encode" |
253 | will be shrunk-to-fit, while all strings generated by "decode" will |
258 | will be shrunk-to-fit, while all strings generated by "decode" will |
254 | also be shrunk-to-fit. |
259 | also be shrunk-to-fit. |
255 | |
260 | |
… | |
… | |
260 | converting strings that look like integers or floats into integers |
265 | converting strings that look like integers or floats into integers |
261 | or floats internally (there is no difference on the Perl level), |
266 | or floats internally (there is no difference on the Perl level), |
262 | saving space. |
267 | saving space. |
263 | |
268 | |
264 | $json = $json->max_depth ([$maximum_nesting_depth]) |
269 | $json = $json->max_depth ([$maximum_nesting_depth]) |
265 | Sets the maximum nesting level (default 8192) accepted while |
270 | Sets the maximum nesting level (default 4096) accepted while |
266 | encoding or decoding. If the JSON text or Perl data structure has an |
271 | encoding or decoding. If the JSON text or Perl data structure has an |
267 | equal or higher nesting level then this limit, then the encoder and |
272 | equal or higher nesting level then this limit, then the encoder and |
268 | decoder will stop and croak at that point. |
273 | decoder will stop and croak at that point. |
269 | |
274 | |
270 | Nesting level is defined by number of hash- or arrayrefs that the |
275 | Nesting level is defined by number of hash- or arrayrefs that the |
… | |
… | |
344 | truly typeless language, so we can only guess which JSON type is meant |
349 | truly typeless language, so we can only guess which JSON type is meant |
345 | by a Perl value. |
350 | by a Perl value. |
346 | |
351 | |
347 | hash references |
352 | hash references |
348 | Perl hash references become JSON objects. As there is no inherent |
353 | Perl hash references become JSON objects. As there is no inherent |
349 | ordering in hash keys, they will usually be encoded in a |
354 | ordering in hash keys (or JSON objects), they will usually be |
350 | pseudo-random order that can change between runs of the same program |
355 | encoded in a pseudo-random order that can change between runs of the |
351 | but stays generally the same within a single run of a program. |
356 | same program but stays generally the same within a single run of a |
352 | JSON::XS can optionally sort the hash keys (determined by the |
357 | program. JSON::XS can optionally sort the hash keys (determined by |
353 | *canonical* flag), so the same datastructure will serialise to the |
358 | the *canonical* flag), so the same datastructure will serialise to |
354 | same JSON text (given same settings and version of JSON::XS), but |
359 | the same JSON text (given same settings and version of JSON::XS), |
355 | this incurs a runtime overhead. |
360 | but this incurs a runtime overhead and is only rarely useful, e.g. |
|
|
361 | when you want to compare some JSON text against another for |
|
|
362 | equality. |
356 | |
363 | |
357 | array references |
364 | array references |
358 | Perl array references become JSON arrays. |
365 | Perl array references become JSON arrays. |
|
|
366 | |
|
|
367 | other references |
|
|
368 | Other unblessed references are generally not allowed and will cause |
|
|
369 | an exception to be thrown, except for references to the integers 0 |
|
|
370 | and 1, which get turned into "false" and "true" atoms in JSON. You |
|
|
371 | can also use "JSON::XS::false" and "JSON::XS::true" to improve |
|
|
372 | readability. |
|
|
373 | |
|
|
374 | to_json [\0,JSON::XS::true] # yields [false,true] |
359 | |
375 | |
360 | blessed objects |
376 | blessed objects |
361 | Blessed objects are not allowed. JSON::XS currently tries to encode |
377 | Blessed objects are not allowed. JSON::XS currently tries to encode |
362 | their underlying representation (hash- or arrayref), but this |
378 | their underlying representation (hash- or arrayref), but this |
363 | behaviour might change in future versions. |
379 | behaviour might change in future versions. |
… | |
… | |
546 | |
562 | |
547 | Third, JSON::XS recurses using the C stack when decoding objects and |
563 | Third, JSON::XS recurses using the C stack when decoding objects and |
548 | arrays. The C stack is a limited resource: for instance, on my amd64 |
564 | arrays. The C stack is a limited resource: for instance, on my amd64 |
549 | machine with 8MB of stack size I can decode around 180k nested arrays |
565 | machine with 8MB of stack size I can decode around 180k nested arrays |
550 | but only 14k nested JSON objects. If that is exceeded, the program |
566 | but only 14k nested JSON objects. If that is exceeded, the program |
551 | crashes. Thats why the default nesting limit is set to 8192. If your |
567 | crashes. Thats why the default nesting limit is set to 4096. If your |
552 | process has a smaller stack, you should adjust this setting accordingly |
568 | process has a smaller stack, you should adjust this setting accordingly |
553 | with the "max_depth" method. |
569 | with the "max_depth" method. |
554 | |
570 | |
555 | And last but least, something else could bomb you that I forgot to think |
571 | And last but least, something else could bomb you that I forgot to think |
556 | of. In that case, you get to keep the pieces. I am alway sopen for |
572 | of. In that case, you get to keep the pieces. I am alway sopen for |