Opened 5 years ago

Last modified 7 months ago

#9721 reopened Bugs

ptree write_json does not conform to JSON standard

Reported by: Mark Pfeifer <Mark_Pfeifer@…> Owned by: Sebastian Redl
Milestone: To Be Determined Component: property_tree
Version: Boost 1.67.0 Severity: Problem
Keywords: Cc:


According to the JSON standard documented at, only string values should have quotes around them. The Boost write_json method puts quotes around all values, not just strings.

For example, the following program:

#include <cstdlib> #include <string> #include <iostream> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/json_parser.hpp>

using boost::property_tree::ptree; using boost::property_tree::read_json; using boost::property_tree::write_json;

int main() {

ptree pt;

pt.put ("string", "string value"); pt.put ("integer", 1); pt.put ("float", 3.14159);

std::ostringstream buf; write_json (buf, pt);

std::cout << buf.str(); return 0;


produces this output:


"string": "string value", "integer": "1", "float": "3.14159"


According to the JSON standard, the output should be:


"string": "string value", "integer": 1, "float": 3.14159


(no quotes around the numeric values)

Change History (17)

comment:1 Changed 5 years ago by Sebastian Redl

Resolution: invalid
Status: newclosed

ptree internally only has strings. put converts from the values you put in to strings, as get converts back. However, the tree itself only contains strings, and therefore so does the output JSON.

Making a ptree variant that preserves JSON types is a future plan, but far off.

comment:2 Changed 3 years ago by anonymous

Yet no update after years..

comment:3 Changed 3 years ago by anonymous

there should be some updates about this problem, or the boost json can only be used as reader not writer

comment:4 Changed 23 months ago by anonymous

Still nothing???

comment:5 Changed 22 months ago by anonymous

A conformant JSON writer should be in Boost since long ago. This ticket has been resolved as invalid, I can't believe it!

comment:6 Changed 21 months ago by anonymous

rapidjson seems to do the job.

comment:6 Changed 21 months ago by anonymous

rapidjson seems to do the job.

comment:7 Changed 15 months ago by anonymous

No way this is invalid! Proper JSON parsing is absolutely necessary.

comment:8 Changed 15 months ago by rnistuk@…

Here's my fix for numbers:

#include <string>
#include <boost/regex.hpp>

  std::string fix_json_numbers(const std::string &json_str)
        boost::regex re("\\\"([0-9]+\\.{0,1}[0-9]*)\\\"");
        return  boost::regex_replace(json_str, re, "$1");

And here's a unit test:

        std::string json_str_in ="{\"cmd\":\"test\",\"data\":{\"integer\":\"283\",\"float\":\"34.433\"}";
        std::string json_str_accepted ="{\"cmd\":\"test\",\"data\":{\"integer\":283,\"float\":34.433}";
        std::string json_str_actual = fix_json_numbers(json_str_in);
        BOOST_CHECK_EQUAL(json_str_accepted, json_str_actual);

NOTE: I've modified the unit test a bit to call the fix_json_numbers function directly, I have not compiled the unit test.

comment:9 Changed 14 months ago by anonymous

Resolution: invalid
Status: closedreopened

This looks like a valid problem and still seen in 1.64. PLs look into this issue.

comment:10 Changed 14 months ago by anonymous

Write value Str data = create_escapes(pt.template get_value<Str>()); stream << Ch('"') << data << Ch('"');

This might be the code to be examined.

comment:11 Changed 14 months ago by anonymous

Yep, i just wanted to use it for with JSON, issue still exist in 1.65

comment:12 Changed 13 months ago by anonymous

What a shame! This ticket is 4 years old!

comment:13 Changed 12 months ago by anonymous

Ok, rapidjson it is.

comment:14 Changed 11 months ago by anonymous

yup i was doing research today to pick a json parser and i stumbled upon this thing... indeed rapidjson it is!

comment:15 Changed 8 months ago by anonymous

Version: Boost 1.55.0Boost 1.67.0

This is still an issue for 1.67. Odd that for such a trivial requirement, boost has a long-pending issue.

comment:16 Changed 7 months ago by anonymous

This is huge shortcoming! This should at the very least be documented using a proper disclaimer in the JSON section...

Note: See TracTickets for help on using tickets.