Unicode and non-unicode support?

[kevmeister68]

Can someone please clarify how jwt-cpp supports Unicode or non-unicode (ANSI) implementations, in terms of:

(I am specifically referring to using this on Windows).

• Which builds (Unicode or Non-Unicode) of OpenSSL are required to use jwt-cpp, or will it work with either?
• Will jwt-cpp compile equally well in Unicode vs non-Unicode environments? I notice no specific dependencies on the UNICODE defines and minimal reference to wstring/wchar etc.
• Obviously the JWT itself is encoded as Base64Url, but once the token is decoded into a JSON object, are the individual traits represented only as UTF-8? Or is this a function of the JSON library used (we'll probably stick with picojson initially).

Thanks

[Thalhammer]

Hi, jwt-cpp doesn't support Unicode, because JWT's are defined to use UTF-8. UTF-8 is generally useful for these kinds of tasks because it is equivalent to ASCII for most of the letters which are usually found in a token and has the nice property of not containing 0 bytes (meaning ascii functions like strlen work as expected). Most json libraries should be binary safe (meaning if your string contains 0 bytes they should be preserved) but they return a std string. Basically you have two options:

• Provide a json_trait with a string type that implicitly converts between utf8 and unicode.
• Use utf8 for the jwt and convert to/from it on your api, c++ provides wstring_convert for this.

I'd recommend going with the second approach because it's easier to maintain and probably more performant.

[prince-chrismc]

The original reason I added the traits was for cpprestsdk, which on Windows uses a wstring... There are still parts of the API the are locked to std::string and I know of other implementations which went with approach two.

If you are looking to contribute, wide string support would be amazing ❤️

EDIT:

I forgot to mention it's also important to pick a good JSON library, for example nlohmann's library does handle content with unicode characters which might be an alternative (if you can always work with std::string).