c++ - 跨平台 C++ : Use the native string encoding or standardise across platforms?

Question

我们特别关注 Windows 和 Linux 的开发，并提出了两种不同的方法，它们似乎都有其优点。 Windows 中自然的 unicode 字符串类型是 UTF-16，Linux 中是 UTF-8。

我们无法确定最佳方法是否:

在我们所有的应用程序逻辑(和持久数据)中对两者之一进行标准化，并使其他平台进行适当的转换

将操作系统的自然格式用于应用程序逻辑(从而调用操作系统)，并且仅在 IPC 和持久性点进行转换。

对我来说，他们似乎彼此一样好。

Answer 1

and UTF-8 in linux.

对于现代 Linux 来说，这几乎是正确的。实际上编码取决于使用的 API 或库。一些硬编码以使用 UTF-8。但是有些读取 LC_ALL、LC_CTYPE 或 LANG 环境变量来检测要使用的编码(如 Qt 库)。所以要小心。

We can't decide whether the best approach

像往常一样，这取决于。

如果 90% 的代码是以平台特定的方式处理平台特定的 API，显然使用特定于平台的字符串会更好。例如 - 设备驱动程序或 native iOS 应用程序。

如果 90% 的代码是跨平台共享的复杂业务逻辑，显然最好在所有平台上使用相同的编码。例如 - 聊天客户端或浏览器。

在第二种情况下，您有一个选择:

使用提供字符串支持的跨平台库(例如 Qt、ICU)

使用裸指针(我也认为 std::string 是“裸指针”)

如果处理字符串是应用程序的重要组成部分，那么为字符串选择一个好的库是一个不错的选择。例如，Qt 有一组非常可靠的类，涵盖了 99% 的常见任务。不幸的是，我没有ICU经验，但它看起来也很不错。

当使用某些字符串库时，您只需要在使用外部库、平台 API 或通过网络(或磁盘)发送字符串时才需要关心编码。例如，很多 Cocoa、C# 或 Qt(都有可靠的字符串支持)程序员对编码细节知之甚少(这很好，因为他们可以专注于他们的主要任务)。

我使用字符串的经验有点特殊，所以我个人更喜欢裸指针。使用它们的代码非常便携(从某种意义上说，它可以很容易地在其他项目和平台中重用)，因为外部依赖较少。它也非常简单和快速(但可能需要一些经验和 Unicode 背景才能感受到这一点)。

我同意裸指针方法并不适合所有人。在以下情况下很好:

您处理整个字符串并且拆分、搜索、比较是一项罕见的任务

您可以在所有组件中使用相同的编码，并且仅在使用平台 API 时才需要转换

您支持的所有平台都有 API 以:

从您的编码转换为 API 中使用的编码

从 API 编码转换为您的代码中使用的编码

指针在您的团队中不是问题

从我的一些具体经验来看，这实际上是一个非常普遍的案例。

使用裸指针时，最好选择将在整个项目(或所有项目)中使用的编码。

在我看来，UTF-8 是最终的赢家。如果您不能使用 UTF-8 - 使用字符串库或平台 API 来处理字符串 - 它将为您节省大量时间。

UTF-8 的优点:

完全兼容 ASCII。任何 ASCII 字符串都是有效的 UTF-8 字符串。

C std 库适用于 UTF-8 字符串。 (*)

C++ std 库与 UTF-8(std::string 和 friend )配合得很好。 (*)

旧代码非常适合 UTF-8。

几乎所有平台都支持 UTF-8。

使用 UTF-8 调试要容易得多(因为它与 ASCII 兼容)。

没有小端/大端困惑。

您不会发现经典错误“哦，UTF-16 并不总是 2 个字节？”。

(*) 直到您需要对它们进行词法比较、转换大小写(toUpper/toLower)、更改规范化形式或类似的东西 - 如果您这样做 - 使用字符串库或平台 API。

缺点是值得怀疑的:

与 UTF-16 相比，中文(和其他具有大代码点数的符号)更不紧凑。

更难(实际上有点)迭代符号。

因此，我建议使用 UTF-8 作为不使用任何字符串库的项目的通用编码。

但是编码并不是您需要回答的唯一问题。

有这样的东西 normalization .简单地说，一些字母可以用多种方式表示——比如一个字形或不同字形的组合。与此有关的常见问题是大多数字符串比较函数将它们视为不同的符号。如果您从事跨平台项目，选择其中一种规范化形式作为标准是正确的做法。这将节省您的时间。

例如，如果用户密码包含“йёжиг”，则在 Mac(主要使用规范化表格 D)和 Windows(主要使用规范化表格 C)上输入时，它将以不同的方式表示(在 UTF-8 和 UTF-16 中)。所以如果用户在 Windows 下使用这样的密码注册，他在 Mac 下登录将是一个问题。

此外，我不建议使用 wchar_t (或仅在 Windows 代码中将其用作 UCS-2/UTF-16 字符类型)。 wchar_t 的问题在于没有与之关联的编码。它只是一个比普通字符大的抽象宽字符(Windows 上为 16 位，大多数 *nix 上为 32 位)。