WChars、编码、标准和可移植性

Question

以下问题可能不属于 SO 问题；如果超出范围，请随时告诉我离开。这里的问题基本上是：“我是否正确理解了 C 标准，这是处理问题的正确方法吗？”

我想请求澄清、确认和更正我对 C（以及 C++ 和 C++0x）中字符处理的理解。首先，一个重要的观察：

可移植性和序列化是正交的概念。

可移植的东西是像 C、unsigned int、wchar_t 之类的东西。可序列化的东西是像uint32_t或UTF-8这样的东西。 “可移植”意味着您可以重新编译相同的源代码并在每个支持的平台上获得工作结果，但二进制表示可能完全不同（或者甚至不存在，例如 TCP-over-Carrier Pig）。另一方面，可序列化的东西总是具有相同的表示形式，例如我可以在 Windows 桌面、手机或牙刷上读取的 PNG 文件。可移植的东西是内部的，可序列化的东西处理 I/O。可移植的东西是类型安全的，可序列化的东西需要类型双关。

当谈到 C 中的字符处理时，有两组分别与可移植性和序列化相关的事物：

• wchar_t、setlocale()、mbsrtowcs( )/wcsrtombs()：C 标准没有提及“编码”；事实上，它与任何文本或编码属性完全无关。它只说“你的入口点是 main(int, char**)；你得到一个类型 wchar_t ，它可以保存所有系统的字符；你得到读取输入的函数char-sequences 并将它们转换为可用的 wstring，反之亦然。

• iconv() 和 UTF-8,16,32：在明确定义的、明确的、固定的编码之间进行转码的函数/库。 iconv 处理的所有编码都被普遍理解和认可，但有一个例外。

具有 wchar_t 可移植字符类型的可移植、与编码无关的 C 世界与确定性外部世界之间的桥梁是 WCHAR-T 和 UTF 之间的 iconv 转换。

那么，我是否应该始终将字符串存储在与编码无关的 wstring 中，通过 wcsrtombs() 与 CRT 交互，并使用 iconv() 进行序列化？从概念上讲：

                        my program
    <-- wcstombs ---  /==============\   --- iconv(UTF8, WCHAR_T) -->
CRT                   |   wchar_t[]  |                                <Disk>
    --- mbstowcs -->  \==============/   <-- iconv(WCHAR_T, UTF8) ---
                            |
                            +-- iconv(WCHAR_T, UCS-4) --+
                                                        |
       ... <--- (adv. Unicode malarkey) ----- libicu ---+

实际上，这意味着我会为程序入口点编写两个样板包装器，例如 C++：

// Portable wmain()-wrapper
#include <clocale>
#include <cwchar>
#include <string>
#include <vector>

std::vector<std::wstring> parse(int argc, char * argv[]); // use mbsrtowcs etc

int wmain(const std::vector<std::wstring> args); // user starts here

#if defined(_WIN32) || defined(WIN32)
#include <windows.h>
extern "C" int main()
{
  setlocale(LC_CTYPE, "");
  int argc;
  wchar_t * const * const argv = CommandLineToArgvW(GetCommandLineW(), &argc);
  return wmain(std::vector<std::wstring>(argv, argv + argc));
}
#else
extern "C" int main(int argc, char * argv[])
{
  setlocale(LC_CTYPE, "");
  return wmain(parse(argc, argv));
}
#endif
// Serialization utilities

#include <iconv.h>

typedef std::basic_string<uint16_t> U16String;
typedef std::basic_string<uint32_t> U32String;

U16String toUTF16(std::wstring s);
U32String toUTF32(std::wstring s);

/* ... */

这是仅使用纯标准 C 编写惯用的、可移植的、通用的、与编码无关的程序核心的正确方法吗？ /C++，以及使用 iconv 的明确定义的 UTF I/O 接口？ （请注意，诸如 Unicode 规范化或变音符号替换之类的问题超出了范围；只有在您决定真正需要 Unicode（而不是您可能喜欢的任何其他编码系统）之后，才需要处理这些问题具体细节，例如使用像 libicu 这样的专用库。）

更新

在许多非常好的评论之后，我想添加一些观察结果：

• 如果您的应用程序明确想要处理 Unicode 文本，您应该使iconv - 核心的转换部分，并在 UCS-4 内部使用 uint32_t/char32_t - 字符串。

• Windows：虽然使用宽字符串通常没问题，但与控制台（就此而言，任何控制台）的交互似乎受到限制，因为似乎不支持任何合理的多字节控制台编码和 mbstowcs 本质上是无用的（除了微不足道的扩大）。例如，从 Explorer-drop 与 GetCommandLineW+CommandLineToArgvW 一起接收宽字符串参数是可行的（也许应该有一个单独的 Windows 包装器）。

• 文件系统：文件系统似乎没有任何编码的概念，只是将任何以空结尾的字符串作为文件名。大多数系统采用字节字符串，但 Windows/NTFS 采用 16 位字符串。在发现哪些文件存在以及处理该数据时（例如，不构成有效UTF16 的char16_t 序列（例如裸代理）是有效的NTFS 文件名），您必须小心。标准 C fopen 无法打开所有 NTFS 文件，因为没有可能的转换来映射到所有可能的 16 位字符串。可能需要使用特定于 Windows 的 _wfopen。作为推论，通常没有明确定义的概念来表示给定的文件名包含“多少个字符”，因为首先没有“字符”的概念。买者自负。

Answer 1

这是仅使用纯标准 C/C++ 编写惯用的、可移植的、通用的、与编码无关的程序核心的正确方法

不，并且根本没有办法满足所有这些属性，至少如果您希望程序运行的话在 Windows 上。在 Windows 上，您几乎在任何地方都必须忽略 C 和 C++ 标准，而只使用 wchar_t（不一定是内部的，而是在系统的所有接口上）。例如，如果您开始使用，则

int main(int argc, char** argv)

您已经失去了对命令行参数的 Unicode 支持。您必须

int wmain(int argc, wchar_t** argv)

改为编写或使用 GetCommandLineW 函数，而 C 标准中没有指定这些函数。

更具体地说，

• Windows 上任何支持 Unicode 的程序都必须主动忽略 C 和 C++ 标准，例如命令行参数、文件和控制台 I/O，或者文件和目录操作。这当然不是惯用的做法。请改用 Microsoft 扩展或包装器，例如 Boost.Filesystem 或 Qt。
• 可移植性是极难实现的，特别是对于 Unicode 支持。你真的必须做好准备，你认为你所知道的一切都可能是错误的。例如，您必须考虑用于打开文件的文件名可能与实际使用的文件名不同，并且两个看似不同的文件名可能代表同一个文件。创建两个文件 a 和 b 后，您最终可能会得到一个文件 c 或两个文件 d > 和 e，其文件名与您传递给操作系统的文件名不同。您要么需要一个外部包装器库，要么需要大量的#ifdef。
• 编码不可知性通常在实践中行不通，特别是如果您想要可移植的话。您必须知道，wchar_t 在 Windows 上是 UTF-16 代码单元，而 char 在 Linux 上通常（并非总是）是 UTF-8 代码单元。编码意识通常是更理想的目标：确保您始终知道您使用哪种编码，或者使用将它们抽象出来的包装器库。

我想我必须得出这样的结论：除非您愿意使用额外的库和特定于系统的扩展，并在其中投入大量精力，否则完全不可能用 C 或 C++ 构建可移植的支持 Unicode 的应用程序。不幸的是，大多数应用程序已经无法完成相对简单的任务，例如“将希腊字符写入控制台”或“以正确的方式支持系统允许的任何文件名”，而此类任务只是实现真正的 Unicode 支持的第一步。

Answer 2

我会避免使用 wchar_t 类型，因为它依赖于平台（根据您的定义不是“可序列化”）：Windows 上的 UTF-16 和大多数类 Unix 系统上的 UTF-32。相反，请使用 C++0x/C1x 中的 char16_t 和/或 char32_t 类型。 （如果您没有新的编译器，暂时将它们键入为 uint16_t 和 uint32_t。）

DO 定义在 UTF-8 之间进行转换的函数。 8、UTF-16 和 UTF-32 功能。

不要编写每个字符串函数的重载窄/宽版本，就像 Windows API 使用 -A 和 -W 所做的那样。选择一个内部使用的首选编码，并坚持使用。对于需要不同编码的内容，请根据需要进行转换。

Answer 3

wchar_t 的问题是与编码无关的文本处理太困难，应该避免。如果您坚持使用“纯 C”，如您所说，您可以使用所有 w* 函数，例如 wcscat 和朋友，但如果您想做任何更复杂的事情，那么你必须潜入深渊。

下面是一些使用 wchar_t 比您只选择一种 UTF 编码要困难得多的事情：

• 解析 Javascript：标识符可以包含 BMP 之外的某些字符（并且假设您关心 。

• HTML：如何将 𐀀 转为 wchar_t 字符串？

• 文本编辑器：如何在 wchar_t 字符串中查找字素簇边界？

如果我知道字符串的编码，我可以直接检查字符。如果我不知道编码，我必须希望我想对字符串执行的任何操作都是由某个库函数实现的。因此，wchar_t 的可移植性有些无关紧要，因为我不认为它是特别有用的数据类型。

您的程序要求可能有所不同，wchar_t 可能适合您。

Answer 4

鉴于 iconv 不是“纯标准 C/C++”，我认为您不满足自己的规范。

char32_t 和 char16_t 附带了新的 codecvt 方面，因此只要您保持一致并选择，我不认为您会出错如果分面在这里，则为一种字符类型+编码。

这些方面在 22.5 [locale.stdcvt]（来自 n3242）中进行了描述。

---

我不明白这至少不能满足您的一些要求：

namespace ns {

typedef char32_t char_t;
using std::u32string;

// or use user-defined literal
#define LIT u32

// Communicate with interface0, which wants utf-8

// This type doesn't need to be public at all; I just refactored it.
typedef std::wstring_convert<std::codecvt_utf8<char_T>, char_T> converter0;

inline std::string
to_interface0(string const& s)
{
    return converter0().to_bytes(s);
}

inline string
from_interface0(std::string const& s)
{
    return converter0().from_bytes(s);
}

// Communitate with interface1, which wants utf-16

// Doesn't have to be public either
typedef std::wstring_convert<std::codecvt_utf16<char_T>, char_T> converter1;

inline std::wstring
to_interface0(string const& s)
{
    return converter1().to_bytes(s);
}

inline string
from_interface0(std::wstring const& s)
{
    return converter1().from_bytes(s);
}

} // ns

那么您的代码可以使用 ns::string, ns::char_t, LIT'A' & LIT“Hello, World!” 鲁莽地放弃，不知道底层的表示是什么。然后在需要时使用 from_interfaceX(some_string) 。它也不影响全局区域设置或流。帮助器可以根据需要变得聪明，例如 codecvt_utf8 可以处理“标头”，我认为这是来自 BOM 等棘手内容的标准语言（同上 codecvt_utf16）。

事实上，我将上面的内容写得尽可能短，但您确实需要这样的帮助程序：

template<typename... T>
inline ns::string
ns::from_interface0(T&&... t)
{
    return converter0().from_bytes(std::forward<T>(t)...);
}

它使您可以访问每个 [from|to]_bytes 成员的 3 个重载，接受诸如例如 const char* 或范围。