[ViewVC] Diff of: cvs/JSON-XS/README

Comparing JSON-XS/README (file contents):
Revision 1.26 by root, Tue Jun 3 06:43:45 2008 UTC vs.
Revision 1.31 by root, Sat Aug 8 10:06:02 2009 UTC

      $perl_scalar = $coder->decode ($unicode_json_text);
      # Note that JSON version 2.0 and above will automatically use JSON::XS
      # if available, at virtually no speed overhead either, so you should
      # be able to just:
- use JSON;
+     use JSON;
      # and do the same things, except that you have a pure-perl fallback now.
 DESCRIPTION
     This module converts Perl data structures to JSON and vice versa. Its
     As this is the n-th-something JSON module on CPAN, what was the reason
     to write yet another JSON module? While it seems there are many JSON
     modules, none of them correctly handle all corner cases, and in most
     cases their maintainers are unresponsive, gone missing, or not listening
     to bug reports for other reasons.
-    See COMPARISON, below, for a comparison to some other JSON modules.
     See MAPPING, below, on how JSON::XS maps perl values to JSON values and
     vice versa.
   FEATURES
         it is disabled, the same hash might be encoded differently even if
         contains the same data, as key-value pairs have no inherent ordering
         in Perl.
         This setting has no effect when decoding JSON texts.
+        This setting has currently no effect on tied hashes.
     $json = $json->allow_nonref ([$enable])
     $enabled = $json->get_allow_nonref
         If $enable is true (or missing), then the "encode" method can
         convert a non-reference into its corresponding string, number or
     While this module always has to keep both JSON text and resulting Perl
     data structure in memory at one time, it does allow you to parse a JSON
     stream incrementally. It does so by accumulating text until it has a
     full JSON object, which it then can decode. This process is similar to
     using "decode_prefix" to see if a full JSON object is available, but is
-    much more efficient (JSON::XS will only attempt to parse the JSON text
+    much more efficient (and can be implemented with a minimum of method
-    once it is sure it has enough text to get a decisive result, using a
+    calls).
-    very simple but truly incremental parser).
-    The following two methods deal with this.
+    JSON::XS will only attempt to parse the JSON text once it is sure it has
+    enough text to get a decisive result, using a very simple but truly
+    incremental parser. This means that it sometimes won't stop as early as
+    the full parser, for example, it doesn't detect parenthese mismatches.
+    The only thing it guarantees is that it starts decoding as soon as a
+    syntactically valid JSON text has been seen. This means you need to set
+    resource limits (e.g. "max_size") to ensure the parser will stop parsing
+    in the presence if syntax errors.
+    The following methods implement this incremental parser.
     [void, scalar or list context] = $json->incr_parse ([$string])
         This is the central parsing function. It can both append new text
         and extract objects from the stream accumulated so far (both of
         these functions are optional).
         after a JSON object or b) parsing multiple JSON objects separated by
         non-JSON text (such as commas).
     $json->incr_skip
         This will reset the state of the incremental parser and will remove
-        the parsed text from the input buffer. This is useful after
+        the parsed text from the input buffer so far. This is useful after
         "incr_parse" died, in which case the input buffer and incremental
         parser state is left unchanged, to skip the text parsed so far and
         to reset the parse state.
+        The difference to "incr_reset" is that only text until the parse
+        error occured is removed.
     $json->incr_reset
         This completely resets the incremental parser, that is, after this
         call, it will be as if the parser had never parsed anything.
-        This is useful if you want ot repeatedly parse JSON objects and want
+        This is useful if you want to repeatedly parse JSON objects and want
         to ignore any trailing data, which means you have to reset the
         parser after each successful decode.
   LIMITATIONS
     All options that affect decoding are supported, except "allow_nonref".
         any character set and 8-bit-encoding, and still get the same data
         structure back. This is useful when your channel for JSON transfer
         is not 8-bit clean or the encoding might be mangled in between (e.g.
         in mail), and works because ASCII is a proper subset of most 8-bit
         and multibyte encodings in use in the world.
+  JSON and ECMAscript
+    JSON syntax is based on how literals are represented in javascript (the
+    not-standardised predecessor of ECMAscript) which is presumably why it
+    is called "JavaScript Object Notation".
+    However, JSON is not a subset (and also not a superset of course) of
+    ECMAscript (the standard) or javascript (whatever browsers actually
+    implement).
+    If you want to use javascript's "eval" function to "parse" JSON, you
+    might run into parse errors for valid JSON texts, or the resulting data
+    structure might not be queryable:
+    One of the problems is that U+2028 and U+2029 are valid characters
+    inside JSON strings, but are not allowed in ECMAscript string literals,
+    so the following Perl fragment will not output something that can be
+    guaranteed to be parsable by javascript's "eval":
+       use JSON::XS;
+       print encode_json [chr 0x2028];
+    The right fix for this is to use a proper JSON parser in your javascript
+    programs, and not rely on "eval" (see for example Douglas Crockford's
+    json2.js parser).
+    If this is not an option, you can, as a stop-gap measure, simply encode
+    to ASCII-only JSON:
+       use JSON::XS;
+       print JSON::XS->new->ascii->encode ([chr 0x2028]);
+    Note that this will enlarge the resulting JSON text quite a bit if you
+    have many non-ASCII characters. You might be tempted to run some regexes
+    to only escape U+2028 and U+2029, e.g.:
+       # DO NOT USE THIS!
+       my $json = JSON::XS->new->utf8->encode ([chr 0x2028]);
+       $json =~ s/\xe2\x80\xa8/\\u2028/g; # escape U+2028
+       $json =~ s/\xe2\x80\xa9/\\u2029/g; # escape U+2029
+       print $json;
+    Note that *this is a bad idea*: the above only works for U+2028 and
+    U+2029 and thus only for fully ECMAscript-compliant parsers. Many
+    existing javascript implementations, however, have issues with other
+    characters as well - using "eval" naively simply *will* cause problems.
+    Another problem is that some javascript implementations reserve some
+    property names for their own purposes (which probably makes them
+    non-ECMAscript-compliant). For example, Iceweasel reserves the
+    "__proto__" property name for it's own purposes.
+    If that is a problem, you could parse try to filter the resulting JSON
+    output for these property strings, e.g.:
+       $json =~ s/"__proto__"\s*:/"__proto__renamed":/g;
+    This works because "__proto__" is not valid outside of strings, so every
+    occurence of ""__proto__"\s*:" must be a string used as property name.
+    If you know of other incompatibilities, please let me know.
   JSON and YAML
     You often hear that JSON is a subset of YAML. This is, however, a mass
     hysteria(*) and very far from the truth (as of the time of this
     writing), so let me state it clearly: *in general, there is no way to

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing JSON-XS/README (file contents): Revision 1.26 by root, Tue Jun 3 06:43:45 2008 UTC vs. Revision 1.31 by root, Sat Aug 8 10:06:02 2009 UTC

Diff Legend

Comparing JSON-XS/README (file contents):
Revision 1.26 by root, Tue Jun 3 06:43:45 2008 UTC vs.
Revision 1.31 by root, Sat Aug 8 10:06:02 2009 UTC