我目前正在开发一个应该在Windows和Linux上工作的业余爱好项目（C / C ++），全面支持Unicode。 可悲的是，Windows和Linux使用不同的编码，使我们的生活更加困难。
在我的代码中，我试图尽可能地使用数据，使Windows和Linux都变得简单。 在Windows中，默认情况下，wchar_t被编码为UTF-16，在Linux中被编码为UCS-4（如果我错了，请纠正我的错误）。
我的软件打开（{_wfopen，UTF-16，Windows}，{fopen，UTF-8，Linux}）并将数据写入UTF-8文件。 到目前为止，这都是可行的。 直到我决定使用SQLite。
SQLite的C / C ++接口允许一个或两个字节的编码string（ 单击 ）。 当然这在Linux中不适用于wchar_t，因为Linux中的wchar_t默认是4字节。 因此，从sqlite的写入和读取需要转换为Linux。
目前，代码在Windows / Linux的例外情况下正在混乱。 我希望坚持在wchar_t中存储数据的标准思想：
读完（ 在这里 ）我确信我应该坚持在Windows中的wchar_t。 但是在完成所有工作之后，麻烦就从移植到Linux开始了。
目前我正在考虑重做这一切，以坚持简单的字符（UTF-8），因为它适用于Windows和Linux，记住，我需要'WideCharToMultiByte'在Windows中的每个string来实现UTF-8。 使用简单的基于char *的string将大大减lessLinux / Windows的例外数量。
你有任何跨平台unicode的经验吗？ 任何关于简单地将数据存储在UTF-8而不是使用wchar_t的想法？
所有平台上的UTF-8，即时转换为适用于Windows的UTF-16是跨平台Unicode的常用策略。
我们的软件也是跨平台的，而且我们面临类似的问题。 我们决定，我们的目标是尽可能少的转换。 这意味着我们在Windows上使用wchar_t ，在Unix / Mac上使用char 。
我们通过在Unix上支持_T和LPCTSTR以及类似的方法来实现这一点，并且通过具有在std::string和std::wstring之间转换的泛型函数。 我们也有一个通用的std::basic_string<TCHAR> （ tstring ），我们在大多数情况下使用它。
到目前为止，这工作得很好。 基本上大多数函数都带有一个tstring或一个LPCTSTR而那些不会从tstring转换它们的参数的函数。 这意味着大部分时间我们不会转换我们的字符串并通过大部分参数。