坑爹的 GBK：大家都应该去用 UTF-8

最近在把我用 C 写的一批 Linux 工具移植到 Windows 上，在字符编码上遇到了大坑。

举个简单的例子：数文件层级。

在 Linux 上，我们数斜杠数量就好。

在 Windows 上，再加上反斜杠，应该就好了。——我是这样想的。

#include <stdio.h>

int main(int argc, char *argv[]) {
    int level;
    const char *p;

    if (argc < 2) {
        return 1;
    }

    for (level = 0, p = argv[1]; *p; p++) {
        if (*p == '/' || *p == '\\') {
            level++;
        }
    }

    printf("%d\n", level);

    return 0;
}

用 MinGW 的 GCC 编译一下，然后跑几个用例：

gcc -o getlevel.exe getlevel.c

C:\>getlevel C:\浙江省\宁波市\北仑区\小港街道.txt
4

C:\>getlevel C:\浙江省\宁波市\北仑区\大碶街道.txt
5

天塌了，这么简单的代码竟然出了 bug 。

原来 碶 的编码是 {0xb4, 0x5c}，其中 0x5c 和反斜杠的 ASCII 编码一模一样。

GBK 的第一字节兼容 ASCII ，但第二字节的范围是 0x40 ~ 0xfe，与 ASCII 的 0x00 ~ 0x7f 重叠。BUG 就这么诞生了。

UTF-8 没有这个问题的原因是：只要字节范围在 0x00 ~ 0x7f，那么就一定是 ASCII ，因为后续字节都避开了这个范围。虽然中文编码比 GB 系列长了，但是这个设计确实省了很多事。包括 strstr() strcmp() 之类的都不会出现奇奇怪怪的 bug 。

或许我应该使用 wmain() 然后获取 wchar_t，但是 wmain() 是 Windows 特有的东西，这样做就没法和 Linux 公用同一套代码了。目前加上了 mbtowc() 作为修复。原本简洁的代码变得十分复杂：（

说到这又不得不吐槽下 Windows 的各种奇怪 API 了，不知道它是如何存活到现在的...

w568w

124 天前

> for (level = 0, p = argv[1]; *p; p++)

这个处理方法是不对的，一个 char 代表「 UTF-8 编码序列中的一个字节」，不存在任何和文本相关的含义。尽管 UTF-8 有一些和 ASCII 兼容的假设，但存在很多 corner case （就像主帖提到的），所以不可靠。

如果是高级语言，要枚举字符应当先枚举 Unicode 码点（ runes ）。

用 mbtowc 转换其实也有问题。wc 指的是「空终止宽字符串」，它不等于 runes 。例如，Windows 上它代指的是经过 UTF-16LE [1] 编码的字符串，对高位字符也需要用多字节的 surrogate pairs 来占位。Linux 上可能是 UTF-32 ，但也不一定。总之，一般建议避免使用 wchar_t 。

言而总之，如果你想枚举 UTF-8 字符串中的字符，最合规的做法是要么依赖 ICU 、utf-8 这样的字符处理库，要么用 C11 里的 mbrtoc32 （ mb -> UTF-32 ）。

[1] https://learn.microsoft.com/en-us/cpp/cpp/char-wchar-t-char16-t-char32-t