Boost C++ Libraries: Ticket #2021: Multibyte conversion on wide strings fails on systems with incorrect locale https://svn.boost.org/trac10/ticket/2021 <p> When saving std::wstring with Japanese chars on an English system, std::wctomb fails (due to incorrect locale). The conversion should be done to UTF-8 instead which is locale-independent. For workaround I now store std::string with UTF-8 encoding. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2021 Trac 1.4.3 Robert Ramey Thu, 19 Jun 2008 22:34:12 GMT <link>https://svn.boost.org/trac10/ticket/2021#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/2021#comment:1</guid> <description> <p> which archive class do you use. Have you tried archive_wtext ? </p> <p> Robert Ramey </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Robert Ramey</dc:creator> <pubDate>Sat, 21 Jun 2008 18:36:02 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/2021#comment:2 https://svn.boost.org/trac10/ticket/2021#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> Hmmm - seems to me that this is trapping a user error. If the currently set locale can't handle the particular wstring - change the locale before you serialize. Maybe what you want is a "utf8 locale" if such a thing makes sense. </p> <p> Trying to fix this within the library would be in sync with the current popular style of making "smart" software, but leads to software with surprising behavior. </p> <p> No change planned for this. </p> <p> Robert Ramey </p> Ticket robert.bielik@… Mon, 23 Jun 2008 05:48:44 GMT <link>https://svn.boost.org/trac10/ticket/2021#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/2021#comment:3</guid> <description> <p> I cannot see how a standard locale independent UTF-8 encoding would lead to "surprising behavior"? Instead it would be consistent and expected behaviour on all locales and platforms with no surprises like this. </p> </description> <category>Ticket</category> </item> </channel> </rss>