Re: [Jsoncpp-devel] jsoncpp unicode

[Baptiste L. <bap...@gm...>]

2010/4/19 <ma...@al...>

>  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*
>