Hi eske,
We felt it was important to have UTF-16 available as an easy option on Windows, however I do see the merits in having UTF-8 working regardless of the platform. This is tracked in the following issue.
We can't break all existing programs and realistically we won't be going and adding overloads supporting both UTF-8 and UTF-16 for each API in the library. However for some areas of the library this would be possible. Particularly APIs that deal with unbounded user data are good candidates, to avoid additional conversions/copies. A little bit of progress has been made in this area. In the 2.3.0 release we added http_client::request overloads to work with UTF-8 on Windows. In the development branch I've added http_response::extract_utf8string and http_response::extract_utf16string for handling response bodies, this will be in release 2.5.0.
If you have made changes to improve any of the APIs for UTF-8 on Windows let me know, it would be good to have them contributed back into the library.
Thanks,
Steve
We felt it was important to have UTF-16 available as an easy option on Windows, however I do see the merits in having UTF-8 working regardless of the platform. This is tracked in the following issue.
We can't break all existing programs and realistically we won't be going and adding overloads supporting both UTF-8 and UTF-16 for each API in the library. However for some areas of the library this would be possible. Particularly APIs that deal with unbounded user data are good candidates, to avoid additional conversions/copies. A little bit of progress has been made in this area. In the 2.3.0 release we added http_client::request overloads to work with UTF-8 on Windows. In the development branch I've added http_response::extract_utf8string and http_response::extract_utf16string for handling response bodies, this will be in release 2.5.0.
If you have made changes to improve any of the APIs for UTF-8 on Windows let me know, it would be good to have them contributed back into the library.
Thanks,
Steve