坑爹的 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 了，不知道它是如何存活到现在的...

mikewang

124 天前

@geelaw #5
@yk000123 #29

抱歉，其实是因为完整的代码逻辑很长，这里是我随手举的例子，没有完全说明清楚。传入的路径是标准化后的绝对路径（如 realpath() 处理后的字符串），所以不考虑 ./ ../ // 等情况了。移植到 Windows 上是做了 #ifdef _WIN32 处理的, Linux 上不做反斜杠判断。

@geelaw #6
Linux 上确实可以不是 UTF-8 ，正如中文 Windows 上也不一定是 GBK （可以手动改成实验状态的 UTF-8 ），但可以认为已经成为了事实上的标准。绝大多数用户使用默认配置就是这种情况了。

@w568w #12
在 UTF-8 上应该是可靠的（只要不是去数字符数的话）。这里的困境是：我也知道有问题，但是似乎没有办法简单解决。正如需求就是简单的数斜杠，那么真的需要引入一个 Unicode 库吗，其实我自己也是怀疑的（？）
另外 mbtowc()，wc 是 widechar 吧，不是 NULL 空终止。

@minami #22
其实是说我的代码有 BUG 啦，这个代码确实学艺不精，其实我也想知道 *应该* 怎么写，或许你也可以举个例子 hhh 这是很多人都会犯的错误。但在 UTF-8 ，它是允许你这么遍历的。一个是方便我这种懒人，二是让那些欧美地区人写的这类代码也能正常跑在中文上。
比如说 strstr() 找子串，GBK 是用不得的。utf-8 在不引入第三方库下就能这么找，是不是挺省事？；）