| … | |
… | |
| 1622 | $json =~ s/\[\s*"XU1peReLzT4ggEllLanBYq4G9VzliwKF"\s*,\s*("([^\\":,]+|\\.|::)*")\s*,/($1)[/g; |
1622 | $json =~ s/\[\s*"XU1peReLzT4ggEllLanBYq4G9VzliwKF"\s*,\s*("([^\\":,]+|\\.|::)*")\s*,/($1)[/g; |
| 1623 | |
1623 | |
| 1624 | Again, this has some limitations - the magic string must not be encoded |
1624 | Again, this has some limitations - the magic string must not be encoded |
| 1625 | with character escapes, and the constructor arguments must be non-empty. |
1625 | with character escapes, and the constructor arguments must be non-empty. |
| 1626 | |
1626 | |
|
|
1627 | |
|
|
1628 | =head1 RFC7158 |
|
|
1629 | |
|
|
1630 | Since this module was written, Google has written a new JSON RFC, RFC |
|
|
1631 | 7158. Unfortunately, this RFC breaks compatibility with both the original |
|
|
1632 | JSON specification on www.json.org and RFC4627. |
|
|
1633 | |
|
|
1634 | As far as I can see, you can get partial compatibility when parsing by |
|
|
1635 | using C<< ->allow_nonref >>. However, consider thew security implications |
|
|
1636 | of doing so. |
|
|
1637 | |
|
|
1638 | I haven't decided yet whether to break compatibility with RFC4627 by |
|
|
1639 | default (and potentially leave applications insecure), or change the |
|
|
1640 | default to follow RFC7158. |
|
|
1641 | |
|
|
1642 | |
| 1627 | =head1 THREADS |
1643 | =head1 THREADS |
| 1628 | |
1644 | |
| 1629 | This module is I<not> guaranteed to be thread safe and there are no |
1645 | This module is I<not> guaranteed to be thread safe and there are no |
| 1630 | plans to change this until Perl gets thread support (as opposed to the |
1646 | plans to change this until Perl gets thread support (as opposed to the |
| 1631 | horribly slow so-called "threads" which are simply slow and bloated |
1647 | horribly slow so-called "threads" which are simply slow and bloated |
