支持和反对仅在跨平台库中支持 std::wstring 的论据答案

【问题标题】：Arguments for and against supporting std::wstring exclusively in cross-platform library支持和反对仅在跨平台库中支持 std::wstring 的论据
【发布时间】：2011-04-08 18:14:57
【问题描述】：

我目前正在开发一个跨平台的 C++ 库，我打算了解 Unicode。我目前通过 typedef 和宏对 std::string 或 std::wstring 提供编译时支持。这种方法的缺点是它迫使您使用像L("string") 这样的宏，并大量使用基于字符类型的模板。

支持和反对仅支持 std::wstring 的论据是什么？

使用 std::wstring 会完全阻碍 GNU/Linux 用户群，而 UTF-8 编码是首选？

【问题讨论】：

我非常喜欢 Python 3 的方法 - 新的 str 类是 unicode，并且有一个新的 bytes 类来保存字节序列，并提供类似字符串的操作（子字符串搜索等） )。但它们只能通过编码转换来解释为文本。因此，如果有人计划“只包含 7 位值的数据”，他们可以通过使用“字节”来节省内存，但他们的对象与正确的字符串不兼容。我在 C++ 中看到的这个尴尬问题与 wstring 已经存在的问题相同，你必须转换文字，以及调用像 fopen 这样的函数。

标签： c++ unicode cross-platform wstring

【解决方案1】：

支持和反对仅支持 std::wstring 的论据是什么？

支持使用宽字符的理由是它可以做所有窄字符可以做的事情，甚至更多。

我知道的反对理由是：

宽字符需要更多空间（这几乎无关紧要，原则上中国人不会比美国人更头痛）
使用宽字符让一些西方人头疼)

至于灵活：我维护了一个库（几个 kLoC），可以处理窄字符和宽字符。大部分是通过字符类型作为模板参数，我不记得有任何宏（除了UNICODE）。但是，并非所有这些都是灵活的，其中有一些代码最终需要char 或wchar_t 字符串。（使用宽字符使内部键字符串变宽没有意义。）
用户可以决定是只需要窄字符支持（在这种情况下"string" 很好）还是只需要宽字符支持（这需要他们使用L"string"），或者他们是否也想要同时支持两者（这需要@ 987654326@)。

【讨论】：

您是否在同一个编译中同时支持两者，例如 Boost 及其格式和 wformat？或者您是否要求用户编译一个或另一个版本的库？
我不知道 boost 的 format/wformat，但我们在该库中拥有的用户可能需要的系统编码或 Unicode 的所有内容都在字符类型上进行了模板化。

【解决方案2】：

为：

Joel Spolsky 写了The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets。如果滚动到底部，您会发现他的工作人员专门使用宽字符串。如果它对他们来说足够好，那么对你来说就足够了。 ;-)

反对：

您可能必须与不支持 i18n 的代码交互。但就像任何优秀的库编写者一样，您只需将混乱隐藏在易于使用的界面后面，对吗？对吗？

【讨论】：

似乎是一篇很棒的文章。我稍后会阅读它。它是否提到了在 GNU/Linux 平台上使用 std::wstring 的任何内容？
不幸的是，Joel 主要是 Windows 专家，因此他的观点相当...短视...在跨平台方面。在页面上快速搜索“linux”和“unix”，只提到了一个：在历史部分。

【解决方案3】：

很多人希望将 unicode 与 UTF-8 (std::string) 而不是 UCS-2 (std::wstring) 一起使用。 UTF-8 是许多 linux 发行版和数据库的标准编码 - 所以不支持它将是一个巨大的劣势。在 Linux 上，每次以字符串为参数调用库中的函数都需要用户将（本机）UTF-8 字符串转换为 std::wstring。

在 gcc/linux 上 std::wstring 的每个字符将有 4 个字节，而在 Windows 上将有 2 个字节。这在读取或写入文件（以及将它们从/复制到不同平台）时可能会导致奇怪的效果。我宁愿为跨平台项目推荐 UTF-8/std::string。

【讨论】：

好点。此外，似乎 GCC 在 std::string 和 std::wstring 混合的环境中表现不佳。
@Oskar N. 什么样的问题？我在使用 gcc 时从来没有遇到过任何问题。
例如不同大小的 wchar_t 与 gcc（4 字节）和 Visual Studio（2 字节）
Microsoft Windows 上的 UTF-8/std::string 怎么样？ Windows 在内部使用 UTF-16。是支持两者的唯一可行选择，还是即使在 Windows 上我也能真正跨平台使用 UTF-8/std::string？
我认为将 UTF-8 存储在 std::string 中是个坏主意，因为我已经了解到这是有问题的。如果这样做，您无法通过查看字符串的类型来判断它是包含系统编码字符还是 UTF-8 编码字符。（即使在 Unicode 应用程序中，您仍然需要大量 ASCII 字符串。）在一个相当大的应用程序中，由于 GUI 中出现 UTF-8 字符串，我看到了大量的错误。这只有在 std::basic_string<> 的特殊实例用于 UTF-8 后才发生变化，因此编译器将直接赋值标记为错误。

【解决方案4】：

缺点：

因为 wstring 是真正的 UCS-2 而不是 UTF-16。总有一天我会踢你的小腿。而且会很猛。

【讨论】：

【解决方案5】：

我会说使用std::string 或std::wstring 是无关紧要的。

无论如何都没有提供适当的 Unicode 支持。

如果您需要国际化，那么您需要适当的 Unicode 支持，并且应该开始调查 ICU 等库。

之后，就是使用哪种编码的问题，这取决于您所使用的平台：将依赖于操作系统的设施封装在抽象层后面，并在适用时在实现层中进行转换。

不要担心您使用的 Unicode 库内部使用的编码（或构建？哼），这是性能问题，不应影响库本身的使用。

【讨论】：