C++ 和 UTF8 - 为什么不直接替换 ASCII？

Question

在我的应用程序中，由于不同的 API(boost、win32、ffmpeg 等)，我必须不断地在 std::string 和 std::wstring 之间转换字符串。特别是对于 ffmpeg，字符串以 utf8->utf16->utf8->utf16 结束，只是为了打开一个文件。

由于 UTF8 向后兼容 ASCII，我认为我始终将所有字符串存储为 UTF-8 std::string 并且仅在我转换为 std::wstring 时转换为 std::wstring必须调用某些不寻常的函数。

这工作得很好，我为 utf8 实现了 to_lower、to_upper、iequals。但是后来我遇到了几个死胡同 std::regex 和常规字符串比较。为了使其可用，我需要实现一个基于 std::string 的自定义 ustring 类，并重新实现所有相应的算法(包括正则表达式)。

基本上我的结论是 utf8 不太适合一般用途。而当前的 std::string/std::wstring 是一团糟。

但是，我的问题是为什么默认的 std::string 和 "" 不简单地更改为使用 UTF8？特别是因为 UTF8 是向后兼容的？是否可能有一些编译器标志可以做到这一点？当然，STL 实现需要自动调整。

我看过 ICU，但它与假设 basic_string 的 api 不太兼容，例如没有开始/结束/c_str 等...

Answer 1

主要问题是内存中表示和编码的混淆。

没有一种 Unicode 编码真正适用于文本处理。用户通常会关心字素(屏幕上的内容)，而编码是根据代码点定义的……并且一些字素由多个代码点组成。

因此，当有人问:"Hélène"(法语名字)的第 5 个字符是什么时，这个问题非常令人困惑:

• 就字素而言，答案是n。
• 在代码点方面...它取决于 é 和 è 的表示(它们可以表示为单个代码点或成对使用变音符号...)

根据问题的来源(屏幕前的最终用户或编码例程)，响应完全不同。

因此，我认为真正的问题是我们为什么要在这里谈论编码？

今天它没有意义，我们需要两个“ View ”:Graphemes 和 Code Points。

不幸的是，std::string 和 std::wstring 接口(interface)是从人们认为 ASCII 就足够的时代继承下来的，而取得的进展并没有真正解决问题。

我什至不明白为什么要指定内存中的表示形式，这是一个实现细节。用户应该想要的是:

• 能够以 UTF-* 和 ASCII 读/写
• 能够处理字素
• 能够编辑字素(管理变音符号)

...谁在乎它是如何表示的？我以为好的软件是建立在封装之上的？

好吧，C 关心，我们想要互操作性......所以我想 C 会解决它。