做C/C开发这些年我越来越有个感受字符函数和字符串函数这玩意大学考试时觉得简单真正上手项目时才知道坑都在后头。上一篇把strlen、strcpy、strcat、strcmp这些最基础的过了一遍这篇继续往下挖——查找、分割、数值转换、字符分类、内存级拷贝一直到C和C两种字符串体系互相切换的正确姿势。适用面很广嵌入式串口协议解析、网络报文拆包、日志文本清洗、配置文件读取、自研SDK的对外接口都会碰到。如果你正处于“函数都会用但项目里老出莫名其妙bug”的阶段这篇就是给你排雷的。1. 查找函数的方向直觉strchr、strrchr 与 strstr 的用法边界1.1 strchr 返回的是指针不是下标更不是布尔值strchr在字符串里找某个字符第一次出现的位置找不到返回NULL。大多数人的用法没问题真正容易踩坑的是它的返回值语义。比如检查“有没有找到点”#include stdio.h #include string.h int main(void) { const char *path /home/user/my.app; char *dot strchr(path, .); if (dot NULL) { puts(没找到点); } else { printf(第一个点在第 %ld 个字符\n, dot - path); } return 0; }这段代码里dot - path用指针减法拿到下标是正确且高效的没有任何问题。但很多人会犯一个相反的错误写if (dot path)判断“没找到”。你要知道如果查找的字符恰好出现在字符串开头strchr返回的指针就等于path这时候拿“是否等于原指针”来判断失败逻辑就反了。判断是否找到只有一条标准返回值是否为NULL。另一个容易被忽视的是strchr对const char*的“背叛”。看这段代码const char *s hello; char *p strchr(s, l); *p x; // 编译器不报错运行时可能段错误标准库给出的函数签名是char *strchr(const char *s, int c)历史遗留问题导致它把一个const字符串的内部指针以char*形式还给你。如果源字符串本身只读比如字符串字面量你往里写就是未定义行为轻则静默失败重则直接段错误。我见过不少刚接触指针的同事在这个地方栽跟头最后排查出来的原因都是“函数声明里没看出来它会写”。还有一个隐藏知识点strchr(s, \0)永远会返回字符串末尾那个空字符的位置所以你不能用strchr去找“字符串是不是空了”——它找空字符一直是成功的。有人拿它当strlen用返回减掉s得到长度能跑但没必要老老实实用strlen更好。1.2 strrchr 是从后往前的直觉文件路径处理首选strrchr返回字符在字符串中最后一次出现的位置。这函数在文件路径处理里简直是标配。比如你要从完整路径里拆出文件名和扩展名const char *full /usr/share/doc/example.tar.gz; const char *slash strrchr(full, /); const char *name slash ? slash 1 : full; const char *ext strrchr(name, .); if (ext) { printf(文件名: %s\n, name); // example.tar.gz printf(扩展名: %s\n, ext 1); // gz } else { printf(文件无扩展名: %s\n, name); }注意这里example.tar.gz取到的扩展名是gz而不是tar.gz因为strrchr找的是最后一个点。如果你要的是第一个点之后的完整内容那就该用strchr。这类细节在高版本协议解析、日志路径提取中经常决定下游逻辑是否正确。有人好奇strrchr到底是不是真的从尾部往前扫。标准没规定实现方式但为了达到“最后一次出现”的语义常见实现要么先用strlen定位到末尾再往前扫要么从头扫一遍但只记住最后一次命中的位置。时间复杂度都是 O(n)所以别觉得“从后往前找”会更快。它的真正价值是语义清楚代码可读性远高于你手写循环。1.3 strstr 查找子串第一次找到就停strstr在字符串里找子串第一次出现的位置。多数场景下你只需要判断“在不在”char *pos strstr(text, error); if (pos) { // 找到了 }但如果你需要“找出所有出现位置”就要自己控制指针前进的步长。这里有一个细节直接决定结果对不对重叠匹配怎么处理。比如在aaaa里找aa如果每次查找后把游标1能得到3个匹配位置0、1、2如果strlen(aa)只能得到2个匹配位置0、2。两种语义没有谁对谁错看你业务需要什么。一般做关键词抽取时用不重叠步进做恶意识别或文本标注时可能要用重叠步进。const char *text error: foo; warning: bar; error again; const char *cursor text; while ((cursor strstr(cursor, error)) ! NULL) { printf(在偏移 %td 处\n, cursor - text); cursor strlen(error); // 改成 1 就是重叠匹配 }还有个冷知识strstr(s, )会返回s因为空字符串被认为在任意位置都匹配。这符合标准但确实容易让不熟悉的人愣一下。如果你在写字符串包含判断工具建议提前把边界条件写清楚别让调用者传空子串进来。2. strtok 分割字符串你必须接受的三个副作用2.1 副作用一源字符串会被改写strtok是C语言里最常用的分词函数但它有个让新手百思不得其解的设计它会修改你传入的源字符串把分隔符位置全部替换成\0。很多人第一次用就遇到段错误通常是因为对字符串字面量调用了strtokchar *s a,b,c; // 字符串字面量存放在只读区 strtok(s, ,); // 尝试写入 \0直接崩标准用法是先把数据拷进可写缓冲区char buf[] a,b,c; char *tok strtok(buf, ,); while (tok) { printf(%s\n, tok); tok strtok(NULL, ,); }我第一次用strtok时也以为a,b,c这种写法没问题毕竟strlen什么的都能接收它。但strtok不是只读函数它需要把分隔符覆盖成字符串结束符这是写入操作。从那以后我养成的习惯是只要一个C函数的名字看起来像“分析/分割”先查它是否修改参数。这类函数的另一个典型是gets不存在的时代但strtok至今仍然活跃。2.2 副作用二内部静态指针导致线程不安全strtok必须在多次调用之间记住“上次分割到哪了”标准库用一个静态变量保存这份状态。结果就是多线程下调用strtok会互相串台。设想线程A在分割自己的字符串刚拿到一个token线程B也调了一次strtokA的静态状态被覆盖下一次A再调用strtok(NULL, ...)就直接乱套了。解决方法是使用可重入版本。POSIX 平台提供strtok_r需要多传一个char **saveptr参数由调用者自己保存状态char buf[] a,b,c; char *saveptr NULL; char *tok strtok_r(buf, ,, saveptr); while (tok) { printf(%s\n, tok); tok strtok_r(NULL, ,, saveptr); }Windows 上情况微妙一点MSVC 提供的是strtok_s参数顺序和C11标准里的那个strtok_s不一样签名是char *strtok_s(char *strToken, const char *strDelimit, char **context)。如果你写跨平台代码最好包一层自己的函数不要把这两种接口的差异暴露给业务调用方char *my_strtok_r(char *str, const char *delim, char **ctx) { #ifdef _MSC_VER return strtok_s(str, delim, ctx); #else return strtok_r(str, delim, ctx); #endif }2.3 副作用三分隔符集合和空字段处理先澄清一个常见误解strtok的第二个参数不是“单个分隔符”而是分隔符集合。strtok(buf, \t\n)可以一次把空格、Tab、换行全部跳过去这个设计在处理配置文件时非常省事。但集合式处理带来另一个问题连续分隔符之间的空字段会被静默跳过。比如a,,b,c用逗号分割你得到的 token 是a、b、c中间那个空字符串直接不见了。如果你的数据模型要求空字段也保留比如CSV解析、按分隔符拼接的协议字段strtok家族就满足不了了。这种场景下我一般用strchr手工扫描或者用一个按字段序号输出空字符串的工具函数。手工扫描的思路是这样void split_with_empty(const char *s, char sep) { if (!s) return; while (*s) { const char *next strchr(s, sep); if (!next) next s strlen(s); printf([%.*s]\n, (int)(next - s), s); s next 1; } }这样写能把a,,b,c拆出a、空串、b、c。代价是你要自己处理换行、制表符等追加条件但至少逻辑可控不会因为“标准函数做不到”就被困住。3. 把字符串变成数字atoi 省心但坑深strtol 才是亲爹3.1 atoi 为什么不能信atoi是入门时最早认识的转换函数一行代码把字符串变整数看起来完美。但它有三个致命问题无法区分非法输入和合法“0”atoi(abc)返回0atoi(0)也返回0你根本不知道转换到底成没成功。溢出时行为未定义极端情况下atoi(99999999999999999999999)可能返回一个随机值不报错、不设标志程序就带着垃圾值继续跑了。只支持十进制想解析0x1F这种带前缀的十六进制atoi直接罢工。结论是atoi只适合“我确定这里一定是合法数字只是图省事转一下”的场景。但凡数据来源不可控网络输入、用户配置、文件内容就别用它。我见过太多线上事故是atoi吞掉异常值后返回0然后系统拿“0”去做业务判断最后数据错得很隐蔽。3.2 strtol 的正规用法endptr 三态判断strtol是atoi的正规替代品它用一个endptr输出参数告诉你“到底消费了多少字符”。完整写法如下#include errno.h #include limits.h #include stdlib.h int parse_long_safe(const char *s, long *out) { if (s NULL || out NULL) return -1; char *endptr NULL; errno 0; long value strtol(s, endptr, 10); if (errno ERANGE) return -1; // 溢出 if (endptr s) return -1; // 一个数字都没吃到 if (*endptr ! \0) return -1; // 后面还有乱字符 *out value; return 0; }逐条解释三个判断条件errno ERANGE数字超出了long能表示的范围返回值已经变成LONG_MAX或LONG_MIN不能信。endptr sstrtol一个合法字符都没匹配上说明字符串开头就不是数字典型如空字符串、abc。*endptr ! \0转换停在中间后面还有没消费掉的字符典型如12abc、12.5。如果你期望整串输入都是数字这就要报错。第三个条件最容易被忽略。很多人以为strtol(12abc, ...)会像某些语言那样报错或者干脆返回12但C语言不是这么设计的它会把12解析出来把endptr指向a。你要不要放过这种情况取决于业务配置文件里某个字段允许“数字单位”混合如12ms、64MB那*endptr非空反而是合法的你还得继续解析单位。还有一个细节值得说当base传0时strtol会自动根据前缀判断进制0x开头按十六进制0开头按八进制。想同时支持用户输入十进制和十六进制用base0最方便。但注意base10时它不会去解析0x1F会在x那里停下很多人在这里踩过坑。3.3 连续解析数据流endptr 就是下一次的起点strtol另一个高频场景是解析一堆用符号分隔的数字比如从网络或配置里读到的10,20,30,40。这时候endptr不只是错误指示器它还告诉你下次从哪继续const char *p 10,20,30,40; char *endptr NULL; long sum 0; while (*p) { long v strtol(p, endptr, 10); if (endptr p) break; // 卡住了不要再死循环 sum v; p endptr; if (*p ,) p; // 手动跳过逗号 } printf(sum%ld\n, sum);这其实就是手写一个最简CSV字段解析器。strtol会把逗号当作“非法字符”停下来我们把endptr指向的位置1跳过逗号继续下一轮。注意循环里的if (endptr p) break;必须保留否则遇到非数字输入时p永远不前进直接无限循环。解析浮点数时换成strtod套路完全一样。4. 字符分类函数的 unsigned char 魔咒与大小写转换细节4.1 经典未定义行为把 signed char 直接传进去isalpha、isdigit、isspace、toupper、tolower这些字符分类和转换函数参数类型都是int但标准规定这个int必须是EOF或能由 unsigned char 表示的字符值。直白点说如果你把一个char变量直接传进去而这个char又是signed类型且值为负数比如存放了0x80在某些平台上char解析为-128那就是未定义行为。为什么这么严重因为 glibc 的实现基本走查表路线内部大概是(ctype_b[c] _ISalpha)这种形式。c一旦是负数索引直接变成负数表外访问轻则返回错误结果重则直接访问到不可映射页程序崩得莫名其妙。解决方式一句话char c 0x80; if (isalpha((unsigned char)c)) { // 先转成 unsigned char // ... }这个坑在嵌入式平台特别常见串口收到的字节可能是任何值你遍历缓冲区做字符分类遇到0x80就开始抽风。排查到后面一查标准才知道是“传参前没转unsigned char”闯的祸。我建议把它写成固定习惯不要等到代码里真的混入非ASCII字节才想起来。4.2 toupper/tolower 只对单字节 ASCII 生效大小写转换同样遵循上面的传参规则。正确的循环写法const char *msg Hello World; for (const char *p msg; *p; p) { putchar(toupper((unsigned char)*p)); }但有两点要认清。第一toupper不会把中文字符或其他多字节字符“变大写”多数实现里遇到非字母字符直接原样返回。所以你想靠它处理 UTF-8 中文文本里的“全角英文字母”或者德语ä、法语é在默认 C locale 下都是不可能的。真要处理多语言文本要么引入专门的 Unicode 库要么自己维护映射表。第二toupper传入EOF时会返回EOF可以在循环里用来检测流结束但如果你拿一个char变量保存返回值它跟EOF比较时可能会出现二次转型问题。处理方式就是上面的写法——输入前转unsigned char返回值直接用int或者转回char再赋值别拿它跟EOF做无谓的比较。4.3 C 里也躲不开的“转型”麻烦在 C 里用cctype的函数同样要遵守这个规则。C 的std::isalpha等函数还有模板重载配合std::string遍历时如果直接写isalpha(c)其中c是char一旦实现把char作为索引隐患和C语言完全一样。正确做法是显式转#include cctype #include string std::string uppercase(const std::string s) { std::string out; out.reserve(s.size()); for (char c : s) { out.push_back(static_castchar( std::toupper(static_castunsigned char(c)) )); } return out; }这段代码顺带演示了C里返回std::string的常态——直接构造返回值就行不用担心拷贝开销后面第6节还会细说。现在你只需要记住C/C 字符串处理里字符分类函数之前一定要过一道unsigned char。5. 内存级操作 memcpy、memmove 与 memset重叠、方向和字节秩序5.1 重叠区是 memcpy 的天敌memcpy和memmove表面都是“拷贝一块内存”区别只有一个源内存和目标内存能否重叠。C标准明确要求memcpy的源和目标不能重叠而memmove允许重叠。重叠时对memcpy来说就是未定义行为意味着“结果可能对可能错也可能崩”。看这个例子int arr[] {1, 2, 3, 4, 5, 6, 7, 8}; // 目标从 arr[1] 开始源从 arr[0] 开始重叠了 memcpy(arr 1, arr, 7 * sizeof(int)); // 未定义行为 memmove(arr 1, arr, 7 * sizeof(int)); // 安全结果是 1,1,2,3,4,5,6,7我知道有人在自己的机器上测memcpy重叠拷贝结果看起来也“正常”于是觉得标准吹毛求疵。这不是标准保守而是memcpy实现可以做正向拷贝、向量化预取等优化这些优化在重叠时恰好“碰巧没坏”完全可能。但换一个平台、换一套编译器、换一个优化级别同样的代码可能就坏了。我项目里就出过这样的事一个环形缓冲区处理模块用了memcpy搬数据低负载没事高负载时数据错乱最后定位到重叠拷贝换成memmove后彻底稳定。哪些业务会碰到重叠数组左移/右移删除元素、环形缓冲区读写指针追赶、内存池内的数据搬移、动态数组扩容时元素迁移。凡是不能拍胸脯保证“源和目标完全不相交”的地方一律用memmove。5.2 memcpy 为什么快memmove 为什么稳很多人纠结性能是不是用了memmove就会变慢我说下底层逻辑。memcpy没有重叠约束编译器可以把它内联成一组高效的向量指令一次性读入大块数据再整体写回性能确实好。memmove需要在内部判断源和目标的相对位置决定从前往后还是从后往前复制或者使用临时缓冲区多了一层控制逻辑和一次分支判断所以通常略慢一点点。但这点性能差异在绝大多数业务场景里可以忽略不计。大数据块的高频拷贝图像帧、网络包缓冲确实值得抠一抠此时你先确定没有重叠用memcpy。其余时候稳健第一。我的习惯是不确定就memmove让正确性成为默认选项。5.3 memset 按字节填充不是“按元素填充”memset的作用是把一块内存的每个字节都填成同一个值所以它天然是按字节操作的。大多数人的第一个误区是int arr[100]; memset(arr, 1, sizeof(arr)); // 结果不是1而是 0x01010101每个int的4个字节都被填成0x01最终值是16843009。你想把int数组初始化成1用memset是做不到的直接循环或C的std::fill才对。memset真正可靠的用法是填0int arr[100]; memset(arr, 0, sizeof(arr)); // 正确所有字节都是0还有一类常用技巧来自算法竞赛memset(dist, 0x3F, sizeof(dist))会把每个字节填成0x3F于是每个int变成0x3F3F3F3F大约是10.6亿适合当图论里的“不可达距离”——比INT_MAX小很多做加法不容易溢出又比正常路径权重大得多。想得到-1的初始化效果用memset(arr, 0xFF, sizeof(arr))。记住这些只是特殊场景常规业务代码里别拿memset去填任意整数值。6. C 与 C 返回字符串的三种活法从堆缓冲区到 std::string6.1 C 函数返回字符串的老三样C语言函数想返回一个字符串绕不开三种方案每种都有代价。第一种返回静态缓冲区指针。函数内部定义一个static char buf[]填充后返回。好处是调用者不用释放坏处有两个——第二次调用会覆盖第一次的内容而且静态缓冲区是全局共享的多线程下数据会互相污染。只适合返回编译期就确定的常量表或者单线程小工具。第二种动态分配堆内存。把结果malloc出来返回指针调用者用完必须freechar *join(const char *a, const char *b) { char *r malloc(strlen(a) strlen(b) 1); if (!r) return NULL; strcpy(r, a); strcat(r, b); return r; }风格很直接但责任划分要非常清楚谁分配谁释放什么时候释放。项目如果缺少明确的约定很容易变成泄漏或double free的来源。第三种调用者自己提供输出缓冲区和长度上限。这是我认为最适合公开接口的写法int build_path(char *out, size_t cap, const char *dir, const char *name) { return snprintf(out, cap, %s/%s, dir, name); }调用者可以在栈上放一个数组不需要关心释放问题snprintf返回值还能告诉你“如果空间足够会写多少个字符”用于检测截断。缺点是要预估缓冲大小复杂场景可能需要先算一下但相比之下安全收益远大于这点麻烦。6.2 C 的 std::string 返回值别再为拷贝焦虑到了C,返回字符串最自然的写法就是直接返回std::stringstd::string build_label(int level, const std::string text) { std::string result; result.reserve(8 text.size()); result [; result std::to_string(level); result ] ; result text; return result; }有些从C转过来的老手会本能地皱眉这不是把字符串拷来拷去吗性能会不会很差C11之后这个担心基本可以放下。函数返回局部std::string时编译器优先做返回值优化RVO/NRVO直接构造到调用方的内存里就算优化没生效也有移动构造兜底底层堆指针直接转移所有权不会产生深拷贝。真正要避免的是返回裸指针去指向一个已析构的对象。传参时也提一句字符串内容不可变时优先const std::string如果只是临时看一下内容C17 的std::string_view更合适它不拥有数据、零拷贝但也不保证\0结尾拿到data()后切记用长度而不是strlen配合。6.3 c_str() 悬垂指针最容易迟到的段错误std::string用起来顺手但它有一个指针陷阱c_str()返回的指针只保证在string对象不改变内容、不析构的期间有效。只要后续调用了修改字符串的成员函数追加、替换、改变容量底层缓冲区可能重新分配原来的c_str()指针立刻变成悬垂指针。std::string s hello; const char *p s.c_str(); s , world; // 可能导致底层重新分配 printf(%s\n, p); // 悬垂访问输出什么全靠运气更隐蔽的版本是把c_str()保存起来用于后续调用const char *p std::string(hello).c_str(); // 临时对象已析构p悬垂这也是“C 函数返回字符串”相关热搜里最容易被忽略的点。正确做法是c_str()用完即用比如fopen(s.c_str(), r)这种临时场景没问题如果需要长期保存一定要把内容复制到另一个std::string或自己管理的缓冲区里。与其保存c_str()再提心吊胆不如直接保存那个std::string对象。最后补一个我们项目组真实踩过的坑有个同事为了让接口省一次拷贝返回一个成员std::string的c_str()给外部使用结果对象在别处被修改后这边拿到的指针就失效了数据错乱排查了好几天。这类问题在字符函数和字符串函数里很典型——每个看似方便的捷径背后都藏着一份被暂时隐藏的代价。我的习惯是C接口就用“输出缓冲区长度上限”C内部安心用std::string字符分类前强制转unsigned char要移动大块内存而不敢确定重叠时就选memmove。写代码之前多问一句“这个函数真的允许这么用吗”比出问题之后查一天文档划算得多。