第15章：跨平台注意事项

正则表达式这东西，写的时候挺爽，一换平台就翻车。我这些年没少在这上面栽跟头。今天聊聊跨平台的那些坑，以及怎么填坑。

15.1 Linux与Windows的差异

先说说最基础的。Linux和Windows在正则表达式上的差异，说白了就是两套标准打架。

差异点	Linux (glibc)	Windows (MSVC)
头文件	<regex.h>	<regex.h> 或 <regex>
函数名	regcomp, regexec	regcomp, regexec (POSIX兼容)
宽字符支持	需要额外处理	原生支持wchar_t
换行符	\n	\r\n

我记得有一次在Linux上写好的正则，放到Windows上一跑，全崩了。查了半天，原来是换行符的问题。Windows用\r\n，Linux用\n，你写个$匹配行尾，两边行为完全不一样。

15.2 宽字符与多字节字符

嗯，这里要注意。C语言里的字符处理，其实是个大坑。宽字符(wchar_t)和多字节字符(MBCS)是两回事。

宽字符每个字符固定占2字节（Windows）或4字节（Linux）。多字节字符呢？一个字符可能占1个字节，也可能占2个。你想想看，用正则去匹配这种变长字符，不出问题才怪。

// 宽字符正则示例（Windows）
#include <regex.h>

// 注意：Windows下wchar_t是2字节
// Linux下wchar_t是4字节
// 这会导致正则引擎行为不一致

// 多字节字符处理
// 建议先转成UTF-8再处理
char *mbstr = "你好世界";
wchar_t wstr[100];
mbstowcs(wstr, mbstr, 100);  // 转成宽字符

15.3 Unicode支持

Unicode支持这块，说实话，C标准库做得不太好。POSIX正则表达式对Unicode的支持很有限。我个人的经验是，如果你要处理中文、日文这些非ASCII字符，最好别指望标准库。

为什么会这样？因为POSIX正则表达式设计的时候，压根没考虑Unicode。它只认识单字节字符。你写个[a-z]匹配小写字母，没问题。但你写个[\u4e00-\u9fff]匹配中文？对不起，标准库不认识。

我在项目中遇到过最离谱的事：用正则匹配中文邮箱地址，Linux上跑得好好的，Windows上直接崩溃。后来发现是宽字符长度计算不一致导致的缓冲区溢出。

15.4 使用PCRE作为替代

说了这么多问题，那怎么办？我的答案是：用PCRE。

PCRE（Perl Compatible Regular Expressions）是个跨平台的正则库。它解决了上面提到的所有问题：

• 统一的API，Linux和Windows行为一致
• 原生支持Unicode
• 支持Perl风格的正则语法
• 性能比标准库好

// PCRE示例
#include <pcre.h>

// 编译正则
const char *pattern = "\\p{Han}+";  // 匹配中文字符
const char *error;
int erroffset;
pcre *re = pcre_compile(pattern, 0, &error, &erroffset, NULL);

// 执行匹配
const char *subject = "Hello 世界";
int ovector[30];
int rc = pcre_exec(re, NULL, subject, strlen(subject), 0, 0, ovector, 30);

if (rc > 0) {
    printf("匹配成功！位置：%d-%d\n", ovector[0], ovector[1]);
}

pcre_free(re);

说实话，PCRE也不是完美的。它增加了项目依赖，编译配置稍微复杂点。但比起在标准库的坑里挣扎，这点代价完全值得。

知识体系总览

下面这张图，是我整理的跨平台正则处理的核心逻辑。你看一眼就能明白整个体系：

你看，左边是标准库的路，坑多路窄。右边是PCRE的路，平坦宽敞。怎么选，不用我多说了吧？

好了，跨平台这块就聊这么多。记住一句话：别跟平台特性较劲，选对工具才是正道。