第14章字符串处理的重构

课程目录第14章字符串处理的重构

字符串处理的重构：从strcpy到strncpy_s、动态字符串库（sds）、Unicode支持

字符串处理，是C语言里最古老也最危险的话题之一。我入行那会儿，前辈们常说一句话：「C语言程序员，不是在处理字符串，就是在处理字符串的路上。」这话一点不夸张。你想想看，一个简单的strcpy，就能让整个系统崩溃——缓冲区溢出、内存越界、安全漏洞，全是从这根「线头」扯出来的。

今天咱们就聊聊，怎么把那些老旧的字符串代码，一步步改造成安全、高效、支持多语言的新形态。

一、从strcpy到strncpy_s：安全的第一步

先看一个经典场景。我早年接手过一个嵌入式项目，代码里到处都是这样的写法：

char buf[64];
strcpy(buf, user_input);  // 危险！

用户输入稍微长一点，栈就被踩烂了。更可怕的是，这种漏洞在安全审计里属于「高危」，一旦被利用，攻击者可以直接控制程序流程。

后来C11标准引入了strncpy_s，算是给这个老大难问题打了个补丁。它的签名是这样的：

errno_t strncpy_s(
    char *dest,
    rsize_t destsz,
    const char *src,
    rsize_t count
);

关键区别在于：它强制你指定目标缓冲区的大小。如果源字符串太长，它不会溢出，而是返回错误码。

核心原则：永远不要用strcpy，除非你能100%保证源字符串长度可控。但说实话，这种保证在现实项目中几乎不存在。

我个人的习惯是，所有新代码一律使用strncpy_s。对于遗留代码，我会写一个简单的封装宏，逐步替换：

#ifdef __STDC_LIB_EXT1__
    #define SAFE_STRCPY(dest, destsz, src) \
        strncpy_s((dest), (destsz), (src), (destsz) - 1)
#else
    // 回退到手动检查
    #define SAFE_STRCPY(dest, destsz, src) do { \
        size_t srclen = strlen(src); \
        if (srclen < (destsz)) { \
            memcpy((dest), (src), srclen + 1); \
        } else { \
            /* 记录错误，截断或返回 */ \
            memcpy((dest), (src), (destsz) - 1); \
            (dest)[(destsz) - 1] = '\0'; \
        } \
    } while(0)
#endif

注意：strncpy_s不是所有平台都支持。Windows上默认就有，但Linux下需要定义__STDC_WANT_LIB_EXT1__。跨平台项目要小心。

二、动态字符串库（sds）：告别固定缓冲区

说实话，strncpy_s只是「止血」，不是「根治」。你想想看，每次都要猜缓冲区该多大，猜小了截断数据，猜大了浪费内存。我在一个日志系统里就吃过这个亏——日志行长度变化极大，固定缓冲区要么不够用，要么空着大半。

后来我发现了sds（Simple Dynamic Strings），这是Redis作者antirez写的一个C字符串库。它的设计思路很巧妙：

自动扩容：追加字符串时，如果空间不够，自动重新分配内存
O(1)长度获取：长度信息存储在头部，不用遍历
二进制安全：可以存储'\0'字符，不依赖结尾标记

用法也很直观：

#include "sds.h"

sds my_str = sdsnew("Hello");
my_str = sdscat(my_str, ", World!");  // 自动扩容
printf("Length: %zu\n", sdslen(my_str));
sdsfree(my_str);

我在项目中用sds重写了一个配置解析模块，代码量减少了40%，而且再也没出现过缓冲区溢出。你想想看，这多省心。

小技巧：sds的字符串可以直接传给标准C函数，因为它内部也是以'\0'结尾的。但反过来不行——不要用strlen去量sds的长度，要用sdslen。

三、Unicode支持：让程序说人话

这是个大坑。我当年做一个国际化项目，产品要支持中文、日文、阿拉伯文。一开始用char数组存UTF-8，结果发现strlen返回的是字节数，不是字符数。用户输入一个「你好」，长度显示6，用户一脸懵。

更麻烦的是，strncpy_s这类函数是按字节截断的。万一截断点落在多字节字符中间，就会产生「乱码尾巴」。

我的建议是：

内部统一用UTF-8：这是事实标准，兼容性好
不要用strlen处理Unicode字符串：用专门的库，比如ICU或libunistring
截断时注意字符边界：不能从多字节字符中间断开

这里给一个简单的UTF-8字符边界检查函数：

// 检查字节是否为UTF-8多字节序列的起始字节
int is_utf8_start_byte(unsigned char c) {
    return (c & 0xC0) != 0x80;
}

// 安全截断：保证截断点不在多字节字符中间
size_t utf8_truncate(const char *str, size_t max_bytes) {
    if (max_bytes == 0) return 0;
    size_t pos = max_bytes;
    while (pos > 0 && !is_utf8_start_byte((unsigned char)str[pos])) {
        pos--;
    }
    return pos;
}

经验之谈：如果你要处理大量Unicode文本，别自己造轮子。ICU库虽然大，但功能全面。轻量级场景可以考虑utf8proc，它只有几个文件，集成方便。

四、知识体系总览

下面这张图，把字符串处理重构的脉络梳理清楚了：

五、避坑指南

最后，分享几个我踩过的坑：

不要混用sds和栈上缓冲区：sds返回的指针指向堆内存，不能直接赋值给栈数组。我曾经这么干过，结果内存泄漏查了两天。
UTF-8的BOM头：有些编辑器会在文件开头加三个字节的BOM（EF BB BF）。读取文件时记得跳过，否则字符串比较会出问题。
strncpy_s的截断行为：它会在目标缓冲区末尾补'\0'，但不会填充剩余空间。如果你依赖全零初始化，要自己处理。

我的建议：重构字符串代码时，先写测试用例。把边界情况（空字符串、超长字符串、含'\0'的二进制数据）都覆盖到。这样改起来心里有底。

字符串处理的重构，说白了就是三个字：安全、动态、国际化。从strcpy到strncpy_s是安全底线，sds是效率提升，Unicode支持是面向未来的能力。这三步走完，你的代码才算真正「现代化」了。

📚 课程目录

字符串处理的重构：从strcpy到strncpy_s、动态字符串库（sds）、Unicode支持

一、从strcpy到strncpy_s：安全的第一步

二、动态字符串库（sds）：告别固定缓冲区

三、Unicode支持：让程序说人话

四、知识体系总览

五、避坑指南