Property tree json reader and writer aren't standards-compliant

[Leon Mergen <leon@…>]

According to the json standard, the "/" character should be escaped to "\/". The boost property tree Json parser generates an error when such an escape sequence is encountered on input, and doesn't properly escape it on output.

Here is a patch for the two files based on the 1.43 tree:

--- ./json_parser_read.hpp      2010-06-09 15:20:17.000000000 +0000
+++ ./json_parser_read.hpp.old  2010-06-09 15:24:43.000000000 +0000
@@ -128,7 +128,6 @@
                 {
                     case Ch('\"'): c.string += Ch('\"'); break;
                     case Ch('\\'): c.string += Ch('\\'); break;
-                    case Ch('/'): c.string += Ch('/'); break;
                     case Ch('0'): c.string += Ch('\0'); break;
                     case Ch('b'): c.string += Ch('\b'); break;
                     case Ch('f'): c.string += Ch('\f'); break;
@@ -247,7 +246,7 @@
                         ;

                 escape
-                    =   chset_p(detail::widen<Ch>("\"\\/0bfnrt").c_str())[typename Context::a_escape(self.c)]
+                    =   chset_p(detail::widen<Ch>("\"\\0bfnrt").c_str())[typename Context::a_escape(self.c)]
                         | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)]
                         ;


--- ./json_parser_write.hpp     2010-06-09 15:15:47.000000000 +0000
+++ ./json_parser_write.hpp.old 2010-06-09 15:24:51.000000000 +0000
@@ -36,7 +36,6 @@
             else if (*b == Ch('\r')) result += Ch('\\'), result += Ch('r');
             else if (*b == Ch('"')) result += Ch('\\'), result += Ch('"');
             else if (*b == Ch('\\')) result += Ch('\\'), result += Ch('\\');
-            else if (*b == Ch('/')) result += Ch('\\'), result += Ch('/');
             else
             {
                 if (std::isprint(*b, loc))

[Leon Mergen <leon@…>]

I'm sorry, the patches were backwards:

--- ./json_parser_write.hpp.old 2010-06-09 15:24:51.000000000 +0000
+++ ./json_parser_write.hpp     2010-06-09 15:15:47.000000000 +0000
@@ -36,6 +36,7 @@
             else if (*b == Ch('\r')) result += Ch('\\'), result += Ch('r');
             else if (*b == Ch('"')) result += Ch('\\'), result += Ch('"');
             else if (*b == Ch('\\')) result += Ch('\\'), result += Ch('\\');
+            else if (*b == Ch('/')) result += Ch('\\'), result += Ch('/');
             else
             {
                 if (std::isprint(*b, loc))



--- ./json_parser_read.hpp.old  2010-06-09 15:24:43.000000000 +0000
+++ ./json_parser_read.hpp      2010-06-09 15:20:17.000000000 +0000
@@ -128,6 +128,7 @@
                 {
                     case Ch('\"'): c.string += Ch('\"'); break;
                     case Ch('\\'): c.string += Ch('\\'); break;
+                    case Ch('/'): c.string += Ch('/'); break;
                     case Ch('0'): c.string += Ch('\0'); break;
                     case Ch('b'): c.string += Ch('\b'); break;
                     case Ch('f'): c.string += Ch('\f'); break;
@@ -246,7 +247,7 @@
                         ;

                 escape
-                    =   chset_p(detail::widen<Ch>("\"\\0bfnrt").c_str())[typename Context::a_escape(self.c)]
+                    =   chset_p(detail::widen<Ch>("\"\\/0bfnrt").c_str())[typename Context::a_escape(self.c)]
                         | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)]
                         ;

[anonymous]

Nothing requires forward slashes to be escaped (they're not '"', '\' or control characters), but I'll adopt the part that accepts them on parsing.

[Leon Mergen <leon@…>]

Well, when you go to ​http://json.org/ and look at the grammar at the right, it specifically says under "char" that / should be escaped to \/.

[Leon Mergen <leon@…>]

​http://www.ietf.org/rfc/rfc4627.txt

That standard also says that the solidus "/" should be escaped. Apparently, it is to allow embedding of JSON inside a HTML document.

This seems to be a reasonable explanation why: ​http://groups.google.com/group/opensocial-and-gadgets-spec/msg/f05cbf2cac48134b

[anonymous]

Hmm ... makes sense.

[Sebastian Redl]

Fixed in trunk and release.