… | |
… | |
402 | character, after which more white-space and comments are allowed. |
402 | character, after which more white-space and comments are allowed. |
403 | |
403 | |
404 | [ |
404 | [ |
405 | 1, # this comment not allowed in JSON |
405 | 1, # this comment not allowed in JSON |
406 | # neither this one... |
406 | # neither this one... |
|
|
407 | ] |
|
|
408 | |
|
|
409 | =item * literal ASCII TAB characters in strings |
|
|
410 | |
|
|
411 | Literal ASCII TAB characters are now allowed in strings (and treated as |
|
|
412 | C<\t>). |
|
|
413 | |
|
|
414 | [ |
|
|
415 | "Hello\tWorld", |
|
|
416 | "Hello<TAB>World", # literal <TAB> would not normally be allowed |
407 | ] |
417 | ] |
408 | |
418 | |
409 | =back |
419 | =back |
410 | |
420 | |
411 | =item $json = $json->canonical ([$enable]) |
421 | =item $json = $json->canonical ([$enable]) |
… | |
… | |
687 | |
697 | |
688 | This is useful if your JSON texts are not delimited by an outer protocol |
698 | This is useful if your JSON texts are not delimited by an outer protocol |
689 | and you need to know where the JSON text ends. |
699 | and you need to know where the JSON text ends. |
690 | |
700 | |
691 | JSON::XS->new->decode_prefix ("[1] the tail") |
701 | JSON::XS->new->decode_prefix ("[1] the tail") |
692 | => ([], 3) |
702 | => ([1], 3) |
693 | |
703 | |
694 | =back |
704 | =back |
695 | |
705 | |
696 | |
706 | |
697 | =head1 INCREMENTAL PARSING |
707 | =head1 INCREMENTAL PARSING |
… | |
… | |
1612 | |
1622 | |
1613 | And after decoding the JSON text, you could walk the data |
1623 | And after decoding the JSON text, you could walk the data |
1614 | structure looking for arrays with a first element of |
1624 | structure looking for arrays with a first element of |
1615 | C<XU1peReLzT4ggEllLanBYq4G9VzliwKF>. |
1625 | C<XU1peReLzT4ggEllLanBYq4G9VzliwKF>. |
1616 | |
1626 | |
1617 | The same approach cna be used to create the tagged format with another |
1627 | The same approach can be used to create the tagged format with another |
1618 | encoder. First, you create an array with the magic string as first member, |
1628 | encoder. First, you create an array with the magic string as first member, |
1619 | the classname as second, and constructor arguments last, encode it as part |
1629 | the classname as second, and constructor arguments last, encode it as part |
1620 | of your JSON structure, and then: |
1630 | of your JSON structure, and then: |
1621 | |
1631 | |
1622 | $json =~ s/\[\s*"XU1peReLzT4ggEllLanBYq4G9VzliwKF"\s*,\s*("([^\\":,]+|\\.|::)*")\s*,/($1)[/g; |
1632 | $json =~ s/\[\s*"XU1peReLzT4ggEllLanBYq4G9VzliwKF"\s*,\s*("([^\\":,]+|\\.|::)*")\s*,/($1)[/g; |
1623 | |
1633 | |
1624 | Again, this has some limitations - the magic string must not be encoded |
1634 | Again, this has some limitations - the magic string must not be encoded |
1625 | with character escapes, and the constructor arguments must be non-empty. |
1635 | with character escapes, and the constructor arguments must be non-empty. |
1626 | |
1636 | |
1627 | |
1637 | |
1628 | =head1 RFC7158 |
1638 | =head1 RFC7159 |
1629 | |
1639 | |
1630 | Since this module was written, Google has written a new JSON RFC, RFC |
1640 | Since this module was written, Google has written a new JSON RFC, RFC 7159 |
1631 | 7158. Unfortunately, this RFC breaks compatibility with both the original |
1641 | (and RFC7158). Unfortunately, this RFC breaks compatibility with both the |
1632 | JSON specification on www.json.org and RFC4627. |
1642 | original JSON specification on www.json.org and RFC4627. |
1633 | |
1643 | |
1634 | As far as I can see, you can get partial compatibility when parsing by |
1644 | As far as I can see, you can get partial compatibility when parsing by |
1635 | using C<< ->allow_nonref >>. However, consider thew security implications |
1645 | using C<< ->allow_nonref >>. However, consider thew security implications |
1636 | of doing so. |
1646 | of doing so. |
1637 | |
1647 | |
1638 | I haven't decided yet whether to break compatibility with RFC4627 by |
1648 | I haven't decided yet when to break compatibility with RFC4627 by default |
1639 | default (and potentially leave applications insecure), or change the |
1649 | (and potentially leave applications insecure) and change the default to |
1640 | default to follow RFC7158. |
1650 | follow RFC7159, but application authors are well advised to call C<< |
|
|
1651 | ->allow_nonref(0) >> even if this is the current default, if they cannot |
|
|
1652 | handle non-reference values, in preparation for the day when the4 default |
|
|
1653 | will change. |
1641 | |
1654 | |
1642 | |
1655 | |
1643 | =head1 THREADS |
1656 | =head1 THREADS |
1644 | |
1657 | |
1645 | This module is I<not> guaranteed to be thread safe and there are no |
1658 | This module is I<not> guaranteed to be thread safe and there are no |