库的字符串编码应该符合 Unicode 还是灵活的？答案

【问题标题】：Should string encoding for library conform to Unicode or flexible?库的字符串编码应该符合 Unicode 还是灵活的？
【发布时间】：2014-03-27 19:28:42
【问题描述】：

我用 C++ 创建了一个库，它公开了 c 风格的接口 API。一些参数是字符串，所以它们是char *。现在我知道它们应该都是 Unicode，但因为它是一个库，我不认为我想强迫用户使用决定与否。理想情况下，我认为最好使用TCHAR，这样我就可以为 unicode 代码和 ASCII 用户构建它。比我读到的this 它总体上反对这个想法。

作为 API 的示例，字符串是文件名或错误消息，如下所示。

void LoadSomeFile(char * fileName );
const char * GetErrorMsg();

我正在使用 c++ 和 STL。还有std::string vs std::wstring 的辩论。就我个人而言，我真的很喜欢 MFC 的 CString 类，它很好地处理了这一切，但这意味着我必须将 MFC 仅用于它的字符串类。

现在我认为 TCHAR 对我来说可能是最好的解决方案，但我必须使用 CString（内部）才能使其工作吗？我可以将它与 STL 字符串一起使用吗？据我所见，它要么是字符串，要么是 wstring。

【问题讨论】：

标签： c++ unicode stl mfc static-libraries

【解决方案1】：

TCHAR 类型是一个不幸的设计选择，幸好被我们遗忘了。谢天谢地，没有人必须再使用TCHAR。我们也选择了 Unicode：Unicode 是未来唯一明智的选择。

问题是，您的库是否仅适用于 Windows？还是便携？

如果您的库是可移植的，那么典型的选择是带有 UTF-8 编码字符串的 char * 或 std::string。有关详细信息，请参阅UTF-8 Everywhere。总结是 wchar_t 在 Windows 上是 UTF-16，但在其他地方是 UTF-32，这使得它对于跨平台编程几乎没有用处。
如果您的库仅在 Win32 上运行，那么您可以随意使用 wchar_t。在 Windows 上，wchar_t 是 UTF-16。

不要同时使用这两种方法，这会使您的代码和 API 臃肿且难以阅读。 TCHAR 是支持 Win32 API 和迁移到 Unicode 的 hack。

【讨论】：

但如果我使用char *，我的库将不再与 unicode 应用程序兼容，反之亦然。这只会在 Windows 中使用，所以我不必担心交叉兼容性，但我确实想让它适用于 unicode 和非 unicode 应用程序。
@zadane：告诉您的用户通过将 Unicode 字符串转换为 UTF-8 来传递它们。很多库已经这样工作了，我用过几个。
@zadane：我想你可能误以为char * 不是Unicode。这是不准确的，char * 实际上只是一种数据类型，而“Unicode”是一种表示字符的方式。您可以使用 UTF-8 将 Unicode 字符串存储在 char *、使用 UTF-16 的 short * 或使用 UTF-32 的 int * 中。 wchar_t 类型基本上是 short 或 int（或其未签名版本），具体取决于您是在 Windows 上还是在其他地方，但 char * 在所有设备上都可用并且一致通用平台。（此注释假定整数类型的典型宽度。）
@Deitrich 那么你是说我可以通过 char * 并且仍然是 unicode 吗？理论上应该没问题，但我想要我也可以轻松操作的字符串。 TCHAR 会根据项目/编码设置相应地转换为 char * 或 wchar_t。
是的，你可以通过 char * 并且仍然是 Unicode。它比TCHAR 更容易操作。使用TCHAR，你不知道你使用的是什么编码，你根本不知道它是否是Unicode——非常难以使用，非常令人沮丧。使用wchar_t，您不知道它是什么编码，但您知道它是Unicode——仍然令人沮丧。如果您将 UTF-8 放在 char * 中，这在 C 和 C++ 中非常常见，那么您就确切地知道您使用的是什么编码——因此很容易操作字符串。（请注意，该标准实际上并不要求 wchar_t 是 Unicode，但实际上是这样。）