Loading ...
Sorry, an error occurred while loading the content.

JSON.parse

Expand Messages
  • Douglas Crockford
    I have a a new version of JSON.parse in JavaScript. It is vastly faster and smaller than the previous version. It uses a single call to eval to do the
    Message 1 of 7 , Dec 26, 2005
    • 0 Attachment
      I have a a new version of JSON.parse in JavaScript. It is vastly
      faster and smaller than the previous version. It uses a single call to
      eval to do the conversion, guarded by a single regExp test to assure
      that it is safe.

      parse: function (text) {
      return
      (/^(\s|[,:{}\[\]]|"(\\["\\bfnrtu]|[^\x00-\x1f"\\])*"|-?\d+(\.\d*)?([eE][+-]?\d+)?|true|false|null)+$/.test(text))
      &&
      eval('(' + text + ')');
      }

      It is ugly, but it is really efficient. I will be posting it on
      JSON.org in a few days.
    • Andrew Durdin
      ... To be more robust, shouldn t it catch errors thrown due to malformed JSON that still passes the regex, like the following (fairly minimal case): ] Andrew
      Message 2 of 7 , Dec 27, 2005
      • 0 Attachment
        On 12/27/05, Douglas Crockford <douglas@...> wrote:
        > I have a a new version of JSON.parse in JavaScript. It is vastly
        > faster and smaller than the previous version. It uses a single call to
        > eval to do the conversion, guarded by a single regExp test to assure
        > that it is safe.

        To be more robust, shouldn't it catch errors thrown due to malformed
        JSON that still passes the regex, like the following (fairly minimal
        case):

        ]

        Andrew
      • Douglas Crockford
        ... The issue is Is it safe? The eval function is inherently unsafe. It allows a chunk of script to run with full authority. Some people have been relunctant
        Message 3 of 7 , Dec 28, 2005
        • 0 Attachment
          > > I have a a new version of JSON.parse in JavaScript. It is vastly
          > > faster and smaller than the previous version. It uses a single call
          > > to eval to do the conversion, guarded by a single regExp test to
          > > assure that it is safe.

          > To be more robust, shouldn't it catch errors thrown due to malformed
          > JSON that still passes the regex?

          The issue is "Is it safe?" The eval function is inherently unsafe. It
          allows a chunk of script to run with full authority. Some people have
          been relunctant to use eval to parsing JSON text, and properly so.

          The regExp will reject text containing non-JSON tokens. I belive that
          it is safe to eval a text containing only non-JSON tokens, even if the
          text itself is not syntactically correct. It is safe because the set
          of JSON tokens does not include parens or equal sign. The eval
          function will detect the syntax errors.

          For example, the text

          ]

          will pass the regExp but be rejected by eval. That is good.
        • f3l
          ... but you still have the bookmarklets issue, right? anyone (ok, maybe not anyone, but some ppl) can type javascript:foobar() on the address bar and crap all
          Message 4 of 7 , Dec 28, 2005
          • 0 Attachment
            On 12/28/05, Douglas Crockford <douglas@...> wrote:
            >
            > > > I have a a new version of JSON.parse in JavaScript. It is vastly
            > > > faster and smaller than the previous version. It uses a single call
            > > > to eval to do the conversion, guarded by a single regExp test to
            > > > assure that it is safe.
            >
            > > To be more robust, shouldn't it catch errors thrown due to malformed
            > > JSON that still passes the regex?
            >
            > The issue is "Is it safe?" The eval function is inherently unsafe. It
            > allows a chunk of script to run with full authority. Some people have
            > been relunctant to use eval to parsing JSON text, and properly so.


            but you still have the bookmarklets issue, right?
            anyone (ok, maybe not anyone, but some ppl) can type javascript:foobar() on
            the address bar and crap all over your web page, right?
            so if it can be eval'd, the user can input it too, so whats the point?

            why not use eval?
            users can eval too!


            also, XML can be very unsafe too, depending on your implementation.

            as time passes by, and more and more ppl use xhr, more and more ppl will
            have fun with not-so-safe implementations, and SQL attacks *will* be the
            order of the day.

            every day.


            but then again, perhaps thats happening right now, so never mind me.
            --
            //f3l
            http://www.geocities.com/kyoosho/


            [Non-text portions of this message have been removed]
          • Douglas Crockford
            ... javascript:foobar() on ... The specific problem is that you do not want to give a text from a 3rd party data server the same authority as your own scripts.
            Message 5 of 7 , Dec 28, 2005
            • 0 Attachment
              > but you still have the bookmarklets issue, right?
              > anyone (ok, maybe not anyone, but some ppl) can type
              javascript:foobar() on
              > the address bar and crap all over your web page, right?
              > so if it can be eval'd, the user can input it too, so whats the point?
              >
              > why not use eval?
              > users can eval too!
              >
              >
              > also, XML can be very unsafe too, depending on your implementation.

              The specific problem is that you do not want to give a text from a 3rd
              party data server the same authority as your own scripts. The eval
              function unfortunately gives the visiting script too much authority.
              The regExp in JSON.parse makes that harmless.

              Ultimately, the user has (or should have) the ultimate authority over
              what happens on their own equipment.
            • ingliss
              ... (/^( s|[,:{} [ ]]| ( [ bfnrtu]|[^ x00- x1f ])* |-? d+( . d*)?([eE][+-]? d+)?|true|false|null)+$/.test(text)) ... I m seeing some fairly crippling
              Message 6 of 7 , Jan 5, 2006
              • 0 Attachment
                --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...> wrote:
                >
                > I have a a new version of JSON.parse in JavaScript. It is vastly
                > faster and smaller than the previous version. It uses a single call to
                > eval to do the conversion, guarded by a single regExp test to assure
                > that it is safe.
                >
                > parse: function (text) {
                > return
                >
                (/^(\s|[,:{}\[\]]|"(\\["\\bfnrtu]|[^\x00-\x1f"\\])*"|-?\d+(\.\d*)?([eE][+-]?\d+)?|true|false|null)+$/.test(text))
                > &&
                > eval('(' + text + ')');
                > }
                >
                > It is ugly, but it is really efficient. I will be posting it on
                > JSON.org in a few days.
                >

                I'm seeing some fairly crippling performance issues here. The
                circumstances are that I'm parsing data in a test html screen, hosted
                in IE 6.0.2800.1106.xpsp2.050301-1526.

                A test string of about 11,000 bytes brings my 3.2GHz P4 to it's knees,
                for longer than I'm prepared to wait (> 5mins).

                After a bit of investigation, the problem seems to rest solely with
                the RegExp check; if this is removed, and the function sublty rejigged
                accordingly, the parse phase executes instantly and the resultant
                object is exactly what I would expect.

                Not every string of a simlar size and complexity has the same effect:
                other very similar strings, parse and return the correct value instantly.

                Testing under Firefox 1.5 generates a different error: the value
                returned from the parse method is the boolean "false", rather than the
                expected object.

                The test data is a bit too large to post here, I can email it if required.
              • Douglas Crockford
                ... There was an n**2 problem with the regexp. The latest version of json.js should be much happier with large texts.
                Message 7 of 7 , Jan 21, 2006
                • 0 Attachment
                  > A test string of about 11,000 bytes brings my 3.2GHz P4 to it's knees,
                  > for longer than I'm prepared to wait (> 5mins).
                  >
                  > After a bit of investigation, the problem seems to rest solely with
                  > the RegExp check; if this is removed, and the function sublty rejigged
                  > accordingly, the parse phase executes instantly and the resultant
                  > object is exactly what I would expect.

                  There was an n**2 problem with the regexp. The latest version of
                  json.js should be much happier with large texts.
                Your message has been successfully submitted and would be delivered to recipients shortly.