2010/4/19 <maga@alliedtesting.com>

Hello Baptiste !

I decided to use jsoncpp in my application, but faced an issue !

The application uses std:wstring for JSON message values due to unicode maintenance,

but I donít see how I can form JSON message through Json::Value.

So, why it doesnít support std::wstring and how it could be solved ?

Unicode awarness in JsonCpp is fairly recent (e.g. handling of unicode escape sequence). And IMHO we still need more tests (such as testing if we correctly handle surrogate escape sequences).

You are the first to ask this features. Though, on Windows it is fairly common to represent utf_16 encoded string as wstring, as it is the native encoding of the O.S.. But as Stephan pointed out, the C++ standard specify neither the size of wchar_t (and reality show varying implementation: typically 2 bytes on MSVC, and 4 bytes with gcc). Side note: the next C++ standard introduces utf16_t and utf32_t types to make this explicit, but those are not yet widely available in the industry, so I'd rather we do not rely on this yet.

We could fairly easily adds support to set a Json::Value from a std::wstring, since utf-16 and utf-32 encoding are not conflicting (please correct me if I'm wrong).† This raises a few questions:
- should we store the wstring as a sequence of char after conversion to utf-8, or should it be stored "as this".
- What asString() and asCString() should return when initialized with an std::wstring? The string converted in utf-8?
- Should we add asWString() and asCWString() ? If so should they return the string encoded in utf-16 or utf-32 on platforms where wchar_t is 32 bits? The string that was passed at initialization? Or should we makes encoding explicit: asUTF16WString(), asUTF32WString()? Concerning the last options, as UTF32 would not be possible on platforms where wchar_t is 2 bytes, this would introduce portability issues...

Baptiste.

Regards.

Maxim Aga