… | |
… | |
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]) |
… | |
… | |
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 |