字符串处理实战：多语言逆序、分割与转换陷阱解析

字符串大概是编程里最“不起眼”却又最能暴露水平的部分。我写了十几年代码，从C语言的char[]一路折腾到 Java、Python、C#、JavaScript 和各类SQL方言，发现一个很现实的问题：越基础的操作越容易翻车。逆序一个字符串人人都会，但遇到UTF-8中文就乱码；split一个字符串三行写完，可正则元字符、尾部空元素能让你立刻怀疑人生；字符串转数字更是重灾区，parseInt、atoi、int() 在不同语言里各有一套“失败时怎么办”的哲学。这一篇是“字符串 | part02”，我不打算重复教科书上的定义，直接进实战：把逆序、分割拼接、类型转换、包含判断、比较排序、数组互转这些高频场景，在不同语言里过一遍。该给的代码给代码，该讲的坑讲清楚。适合看这篇的，是写过一点代码但总觉得自己对字符串处理还不够扎实的同学，以及日常在多种语言和数据库之间来回切换的搬砖选手。

1. 逆序：从C语言指针到Unicode，最简单也最容易被绕晕的操作

1.1 先过一遍C语言的原地逆序

先说最经典的C语言版本。绝大多数教材里教的是这样：

void reverse(char s[]) { int len = strlen(s); for (int i = 0, j = len - 1; i < j; i++, j--) { char tmp = s[i]; s[i] = s[j]; s[j] = tmp; } }

这段代码逻辑上没有大问题，但你必须意识到两点。第一，它只能处理可修改的字符数组；如果你把字符串字面量直接传进来，比如reverse("hello")，在C标准里就是未定义行为，现代编译器通常会警告，但如果你写的是指针数组存放字符串，再把数组里的某个元素传进来，运行时不一定会提示你，而是直接给你一个段错误。第二，strlen每次都会从头扫到尾找\0，如果你只逆序一次无所谓，但在需要反复逆序字符串的代码里，它会成为性能瓶颈。

所以更实际的写法是用指针，把长度也算进来：

void reverse(char *s) { int len = strlen(s); char *p = s, *q = s + len - 1; while (p < q) { char tmp = *p; *p++ = *q; *q-- = tmp; } }

这个版本里p从头往中间走，q从尾往中间走，交换后各自收拢一格。本质上字符串逆序就是双指针交换，别用额外数组，也别写递归——递归版本虽然看起来优雅，长字符串的栈开销是实打实的风险。Python里这题一行s[::-1]就完事，Java里用new StringBuilder(s).reverse().toString()，C#里常见的是把字符数组Array.Reverse之后再new string，但三种写法背后的内存模型完全不同，直接照抄不可取。

1.2 按字节逆序为什么会让中文乱码

很多教材不会告诉你一个事实：C语言的char和strlen处理的是字节，不是字符。在UTF-8编码下，一个汉字占3字节，你按字节去逆序，等于把一个完好的汉字编码拆开再倒着拼回去——结果必然乱码。

处理办法有三个方向。第一，如果确认字符串是UTF-8，先把字节流解码成码点数组，逆序数组后再重新编码，这样每个汉字都作为一个整体移动；第二，在Windows下用wchar_t和L宽字符串，但注意wchar_t在不同平台宽度不一致，Windows下是2字节（UTF-16），Linux/GCC下是4字节（UTF-32），想跨平台就得小心；第三，直接用高级语言的字符串类型——Python的字符串按Unicode码点存储、Java的String内部是UTF-16数组、C#的string也是UTF-16，这些语言帮你处理了字符边界，除非你特意去操作byte数组，否则不会出现半个汉字的问题。

顺带说一个和小票、短信计费相关的需求：“汉字算一个字符，英文字母和数字两个算一个字符”。这种描述通常意味着按显示宽度截断字符串。朴素的实现是遍历字符串，给每个字符计算显示宽度：落在CJK范围（简单判断可以看 U+4E00 到 U+9FFF）的按2计，西文字符和数字按1计，累计到上限再截断。这个逻辑在高级语言里用码点遍历即可，但如果你在C语言里按字节去截，就极可能在两个汉字中间切断，形成半个汉字——这是生产环境中常见的乱码原因。

1.3 逆序的实战伪装：回文判断与拼数问题

逆序在业务里最常出现的形态其实不是“把字符串倒过来”，而是回文判断和拼数问题。回文判断两种思路，一种是逆序后比较原串和逆序串，另一种是双指针从两头往中间扫，遇到不等就提前退出。后者在长字符串上更省内存，也更适合在循环里做批量判断。

拼数问题则把逆序和排序搅在一起。比如给你一组数字字符串，要求拼出一个最大数。核心原则是：定义两个串 a 和 b 之间的比较规则——如果a + b大于b + a，那么 a 应该排在 b 前面。很多人第一次做这题会直接按字典序排序，结果拼出来的数和期望差很远。代码层面：

Arrays.sort(arr, (a, b) -> (b + a).compareTo(a + b));

from functools import cmp_to_key arr.sort(key=cmp_to_key(lambda a, b: (b + a) > (a + b)))

这里有个细节要强调：如果字符串很长，把a + b转成整数再比较会溢出，正确做法是直接按字符串字典序比较拼接结果，别转数字。而“逆序输出 c 语言”这类题目，本质上就是回文判断的前置步骤，练的是指针移动和边界控制，练熟了对理解很多字符串算法都有好处。

2. split与拼接：业务代码里最高频也最容易翻车的两个方向

2.1 同一个split，三个语言三个脾气

字符串分割，Java里写s.split(",")，Python里写s.split(",")，C#里写s.Split(',')，JS里写s.split(",")——同一个拼写，行为可能完全不一样。我踩过的坑主要是三个。

第一个是尾部空字符串丢失。Java的String.split默认会丢弃尾部空字符串："a,b,,".split(",")返回["a","b"]，不是["a","b","",""]。如果业务需要保留每一列，必须用split(",", -1)。Python则相反，"a,b,,".split(",")保留空串，返回['a','b','','']；但"".split(",")返回['']而不是[]，解析空消息时这个细节容易让人意外。同样是split，一个丢弃一个保留，写之前先确认目标语言行为，比写完之后再补测试要省时间。

第二个是正则元字符。Java和JS的split接收的是正则表达式，"a.b.c".split(".")会把每个字符都当成分隔符，结果切得稀碎，正确写法是split("\\.")；C#的Split接收的是字面量字符或字符串，传"."就是按点切，完全不用转义。假如你要按竖线|切，Java里直接写split("|")，正则引擎会把每个字符都切一遍，得到一堆碎片而不是两段——必须split("\\|")。跨语言用split之前，先搞清楚第一个参数到底是字面量还是正则，这是最大的坑。

第三个是业务数据里的全角逗号。产品给了一个Excel导出的列，用户填的是中文逗号“，”，程序用英文逗号切，结果整列都是脏数据。这种问题的标准解法是在切分前先做字符归一化：把全角逗号、全角空格替换成半角再走split。替换的时候注意，JavaScript的str.replace(',', ',')默认只替换第一个匹配，要全局替换得写str.replaceAll(',', ',')或/，/g；Python、Java、C#的replace默认都是全量替换。全角转半角属于字符串清洗的基础功，但几乎每个项目里都会遇到。

2.2 拼接的性能账与SQL聚合场景

字符串拼接，Java里String是不可变的，循环里写s += item，每执行一次都会new一个String对象，几万次循环之后GC压力肉眼可见，正确姿势是StringBuilder，最好在构造时传入初始容量避免扩容。C#里StringBuilder和string.Join都行，日志和提示语用$插值可读性更好。Python里推荐"".join(parts)，CPython对+=做过一些优化，但把这种优化当成语言保证，在长文本拼接时还是会踩到性能问题。JS里arr.join("")也稳定一些。

这里补充一个容易混淆的点：Python的字符串同样是不可变的，a = "abc"之后执行a[0] = "x"会直接抛TypeError。热搜词里“python字符串直接赋值更改”，说的其实是重新给变量绑定一个新字符串是允许的，但原地修改字符是不行的。C语言则相反，能原地修改的必须是可修改的字符数组，字符串字面量本身的修改行为是未定义。三句话总结：Python的变量可以重新赋值，内容不可变；Java的引用可以重新指向，String内容不可变；C的字符数组可以改内容，但字面量千万别碰。

再聊SQL里的字符串拼接。同一组多行字符串拼成一列，SQL Server 2017+ 直接STRING_AGG(col, ',')；老版本用STUFF + FOR XML PATH，注意XML会把&转义成&，拼接结果里如果包含特殊字符就会被坑。Oracle用LISTAGG，但返回结果超过4000字节会报ORA-01489，长文本场景要换别的方式。这类需求在报表、标签打印里非常常见，选对版本对应的方案能省很多事。

2.3 按显示宽度截断与换行符的统一处理

按显示宽度截断，在小票打印、短信接口、表格对齐里是刚需。核心就是给每个字符算宽度：中文按2，西文字母数字按1。实现时注意用码点遍历而不是字节遍历，不然会切出半个汉字。在Java里String的length是UTF-16 code unit数量，一个emoji占2个，一个汉字占1个，这跟你肉眼看到的字符数不一样，处理时要用codePoint来遍历。这段不算复杂，但落地的坑基本都是“用错计数单位”。

换行符是另一个容易忽略的隐形地雷。Windows下换行是\r\n，Linux/macOS是\n，一份文本在Windows记事本编辑过，拿到Linux解析经常在行尾多一个\r。bash里写多行字符串也容易翻车：

msg="第一行 第二行" echo "$msg"

如果漏掉双引号，直接echo $msg，换行会被吞掉。跨平台文本处理，建议先统一换行符：s.replace("\r\n", "\n")。C#的逐字字符串@"..."会保留换行，但里面要用""表示一个双引号，这个转义规则刚接触时容易写错。工业组态屏的脚本里（比如昆仑通态那类环境），字符串换行通常也不是直接敲回车，要通过拼接CHR(13)+CHR(10)或者对应环境指定的转义方式实现，这属于小众但真实存在的需求，遇到时先查该脚本引擎的字符串转义文档，别按通用语言的习惯硬套。

3. 字符串与数字互转：从SQL到C语言，失败策略决定代码质量

3.1 SQL里的数字判断：ISNUMERIC为什么靠不住

“判断字符串是不是数字”在数据库里是高频需求。SQL Server里新手喜欢用ISNUMERIC，但它是出了名的宽松：ISNUMERIC('1e5')返回1，ISNUMERIC('$100')返回1，ISNUMERIC('-1.5')返回1，这些值直接CAST成INT时要么报转换错误，要么语义跟业务预期完全不同。新代码建议直接用TRY_CAST：

SELECT TRY_CAST('123' AS INT); -- 123 SELECT TRY_CAST('abc' AS INT); -- NULL

TRY_CAST('abc' AS INT)返回NULL，不会抛错。判断能否转换，看CAST结果是否NULL就行了，比ISNUMERIC可靠得多。

Oracle里判断纯数字，常用正则：REGEXP_LIKE(col, '^[0-9]+$')，然后用TO_NUMBER转换。还经常遇到LONG类型转字符串的场景——LONG是老语法，不能随便TO_CHAR，也不能直接放进GROUP BY或ORDER BY，常规做法是SUBSTR(long_col, 1, 4000)截成VARCHAR2处理，或者用TO_LOB()转成CLOB。DB2里判断数字字符串，除了REGEXP_LIKE，还有一个老派的TRANSLATE技巧：TRANSLATE(column, '', '0123456789')把数字字符删掉，剩下的内容为空（等于''）就说明原串全部由数字组成。这句判断写法比较绕，但胜在不依赖正则引擎，老版本DB2也能用。

3.2 各语言转换失败时到底会怎样

编程语言里，字符串转数字的失败策略差异比数据库还大。Java的Integer.parseInt("abc")直接抛NumberFormatException；C#的int.Parse也抛异常，但int.TryParse(s, out var n)用bool返回值表达成功与否，不抛异常，这是我在这个场景里比较认可的设计；Python的int(s)同样抛ValueError，需要用try/except包住，或者先做其他校验。

Python里判断字符串是不是数字，不能只靠str.isdigit()——它认为'²'（上标2）是数字，isdigit()对'1.5'返回False，对负数也返回False，真正能进int()的字符串判断还得看业务场景，用正则或isdecimal配合处理。JavaScript则是另一个极端：parseInt("123abc")返回123，不报错也不警告，这种宽松行为容易把脏数据悄悄放过去；Number("123abc")返回NaN，+("123")也是数字转换的常用写法。用之前想清楚业务到底要严格模式还是宽松模式，别把语言默认行为当成真理。

C语言里atoi("abc")返回0，你分不清是成功转换还是真值为0，有经验的代码会用strtol：

char *end; long v = strtol(s, &end, 10); if (end == s) { // 第一个字符就解析不了 } else if (*end != '\0') { // 后面还有尾巴，不是完整数字 }

end == s说明没有可转换的数字，*end != '\0'说明后面还有多余字符，这两个判断能精细控制解析范围。ABAP那种偏业务的环境里，判断字符串是否是数字常用CO/CN比较运算符，比如IF lv_str CO '0123456789'.。每个语言都有自己的惯用手法，核心思路都一样：先判断再转换，或者转换后严格检查失败信号。

3.3 字节层转换：getBytes、ASCII码与gzip解压后的还原

字符串转数字之外，字符串与字节数组之间的转换也很容易出事。C#里想拿字符串的ASCII码：

byte[] bytes = Encoding.ASCII.GetBytes("ABC"); // [65, 66, 67]

但如果字符串里有中文，ASCII编码表里压根没有对应项，会被全部替换成0x3F（问号）。只要内容可能包含中文，就一定要用Encoding.UTF8.GetBytes。Java同理，s.getBytes()不指定字符集时用JVM默认，换个部署环境就可能乱码，Java 18+ 默认UTF-8了，但老项目里还是建议养成getBytes(StandardCharsets.UTF_8)的习惯。

Byte数组还原成字符串也是同样逻辑：先确定字节流的编码，再决定用哪个Charset去decode。GzipInputStream解压一组字节，拿到byte[]之后如果直接new String(bytes)而不指定UTF-8，在Windows默认GBK的环境下十有八九是乱码。热搜词里同时出现“gzipinputstream 转字符串”和“json转字符串”，说明很多人做HTTP接口对接时，先压缩、再解压、再转字符串、再解析JSON，这一整条链路上任何一环编码不一致都会出问题。

提示：字符串转字节数组、字节数组转字符串，永远显式指定编码，不要依赖运行环境的默认值。宁可多敲几个字符，别赌环境的默认行为。

4. 包含、相等、大小写与排序：比较规则里的暗礁

4.1 判断包含子串的跨语言差异

判断一个字符串是否包含某个子串，每个语言都有自己的API和坑。Python用"abc" in s最自然，Java用s.contains("abc")，C#用s.Contains("abc")，JS是s.includes("abc")。这里面有几件事需要特别留意。

第一，大小写敏感。Java的contains和C#的Contains默认区分大小写，需要忽略大小写时，C#可以直接s.Contains("abc", StringComparison.OrdinalIgnoreCase)，Java没有这个重载，常见做法是s.toLowerCase().contains("abc".toLowerCase())或正则。第二，空字符串的包含判断，"abc".contains("")返回true，这在解析协议字段时会让人措手不及：如果字段允许为空，你以为是“包含”，其实条件永远成立。第三，数据库里的包含判断：Oracle常用INSTR(col, 'abc') > 0或LIKE '%abc%'；SQL Server用CHARINDEX('abc', col) > 0。注意LIKE '%abc%'因为前导通配符通常没法走普通索引，表大时性能会很难看，能用INSTR或CHARINDEX反而更好分析。

4.2 字符串相等：比内容还是比地址

字符串相等比较的坑，核心就一句话：这个语言里==比的是内容还是引用。

C语言里strcmp("abc", "abc") == 0才是内容比较，直接用==比的是指针地址；虽然编译器偶尔会把相同字面量合并到同一块内存，让你的测试碰巧通过，但一个来自字面量、一个来自运行时缓冲区的字符串，用==比较永远是false。Java里==比引用，equals比内容——小字符串因为常量池缓存可能碰巧相等，但new出来的对象就必须用equals。C#的==被重载成了内容比较，ReferenceEquals才是比引用，和Java正好相反。JavaScript里==会做类型转换，"5" == 5是true，写===才能挡掉这种坑。Python里==已经是内容比较，is才是身份比较，但CPython对小字符串有intern机制，"hello" is "hello"在某些环境为True，这种依赖实现细节的写法不应该出现在正式代码里。

为了更直观，我习惯用一张小表记住差异：

遇到新语言，第一步先查清楚相等运算符的语义，比什么都重要。

4.3 大小写转换与字符串排序的Locale/Collation问题

大小写转换看似没有技术含量，坑全在Locale。Java的s.toLowerCase()不传Locale时跟着系统默认走，知名例子是土耳其语环境下"I".toLowerCase()得到的是不带点的ı而不是i，导致代码在土耳其语系统上行为异常。对枚举名、协议字段、编程语言关键字做归一化时，建议显式传Locale.ROOT或Locale.ENGLISH。C#的ToLower同样有culture概念，处理文件名、URL时用ToLowerInvariant()更稳。

字符串排序分两种：纯编码序和自然排序。JavaScript的默认sort()按UTF-16码元比较，['10', '2', '1'].sort()得到['1', '10', '2']，10排在2前面，这在文件列表、版本号排序里很反直觉；要按自然语义排序得传比较函数，比如(a, b) => a.localeCompare(b, { numeric: true })。C语言里strcmp永远是编码序。数据库排序则看collation：SQL Server的Chinese_PRC_CI_AS下，中文列按拼音排序；换一个排序规则，顺序可能完全变样。排序规则是字符串比较的底层基调，调整它比在代码里写各种分支都来得彻底。

4.4 顺带一提：判断驼峰字符串的朴素写法

热搜词里有“python 字符串是否驼峰”，这类需求通常出现在变量命名规范检查工具里。朴素的思路是遍历字符串，统计大写字母个数，小驼峰要求首字符小写且后续单词首字母大写，大驼峰（PascalCase）要求首字符大写。Python没有内置的isCamelCase方法，自己写个遍历比引正则更好调试，正则写个^[a-z][a-zA-Z]*$只能判断形状，判断单词边界还得靠大小写切换点。这类应用不复杂，核心是别把“大小写转换”和“命名规范校验”混为一谈——前者改大小写，后者读结构。

5. 字符串与数组互转、枚举名、JSON与连接字符串

5.1 字符串与数组互转的一张速查表

字符串按分隔符转数组、数组按分隔符拼字符串，这两个操作看起来互逆，各语言却叫法各异。直接给张表：

补充几点。C语言的strtok会修改原字符串，并且用静态缓冲区保存状态，多线程里会串数据，生产代码尽量用strtok_r或自己手写分割。JS想把字符串拆成单个字符，用[...s]而不是s.split('')，因为[...s]按码点拆，对'𠮷'这种增补平面字符不会拆成两个代理项，split('')会。Java里s.toCharArray()返回char[]，后面对char[]做任何修改都不影响原String，因为它是拷贝。数组转字符串最朴素的是join，但如果要保留结构化信息，JSON才是正式方案。

5.2 C语言指针数组与宽字符串字面量的坑

C语言里“指针数组存放字符串”是经典考点。char *arr[] = {"hello", "world"};这种写法，数组本身是可变的，但数组元素指向的字符串字面量存储在只读区域，arr[0][0]='H'属于未定义行为。很多新手在本机测试时没崩，换编译器或开优化选项就崩，原因就在这。如果需要修改字符串内容，用char arr[][10]二维数组拷贝一份，或者堆上分配内存自己管理。C++里更推荐std::array<std::string, N>或std::vector<std::string>，基本绕开这类问题。

CodeBlocks里常见的“宽字符L表示出错”也是字符串字面量前缀使用不当。L"你好"是宽字符串字面量，要用wchar_t接收，但wchar_t在不同平台宽度不同：Windows下通常是UTF-16，Linux/GCC下是UTF-32，同样的L字符串想跨平台共享，行为完全不可控。C11/C++17之后更推荐明确编码后缀：u8"你好"表示UTF-8，u"你好"表示UTF-16，U"你好"表示UTF-32，代码里写得越明确，跨平台越省心。现代C++项目处理中文字符串，我一般建议直接用std::string存UTF-8，不要再穿wchar_t的鞋。

5.3 模板字符串、枚举转字符串与JSON序列化

模板字符串如今已是标配。JS的反引号模板字符串能嵌入表达式、保留换行：

const name = "小明"; const message = `你好，${name}！`;

C# 6.0后的$插值、Python的f-string也是同一思路。生成动态SQL、日志模板、错误提示时，可读性比+拼接好太多。

枚举转字符串多用于日志和接口输出。C#里Enum.GetName(typeof(Status), Status.Active)，Java里Status.ACTIVE.name()，Python的Color.RED.name拿名字、Color.RED.value拿值。需要注意，C#直接Status.Active.ToString()默认输出枚举名，但Java的toString如果没重写，默认输出不是枚举名，行为有差异。

JSON转字符串是字符串处理绕不开的一环。Python里json.dumps(data, ensure_ascii=False)才能让中文保持可读，而不是一堆\u转义；Java的Jackson需要注册JavaTimeModule才能序列化LocalDateTime；C#的System.Text.Json默认情况下对某些类型也有限制。JSON本质是字符串承载结构化数据，序列化和转义规则决定了跨系统传输的兼容性。使用任何序列化库时，先看它的默认编码和失败策略，能避免大量线上问题。

5.4 ODBC连接字符串：另一种字符串语法

最后讲一个容易被忽略的字符串场景：连接字符串。ODBC的连接串长这样：

Driver={ODBC Driver 17 for SQL Server};Server=myServer;Database=myDb;Uid=myUser;Pwd=myPass;

它有自己的语法规则：键值对用分号分隔，值如果包含花括号或特殊字符需要转义，不能简单套用JSON解析或普通配置文件读法。比如密码里包含右花括号}，通常要写成}}表示一个字面量花括号。很多老系统把连接字符串放在ini文件或环境变量里，一旦密码包含特殊字符，整个程序连不上，查半天才发现是字符串语法问题。遇到这类“看起来像配置，实际上是字符串”的场景，先找驱动文档确认转义规则，比自己试错高效得多。

我自己有个习惯：接触一个新语言或新数据库，先建一张字符串行为对照表，记录split时空字符串怎么处理、==比较内容还是引用、转换失败抛异常还是返回0、中文按字节还是按字符。这张表不用很完整，但能省掉大量排查时间。字符串之所以坑多，是因为每门语言的历史包袱和默认行为各不相同，表面API相近，底下语义差着十万八千里。这篇part02把高频操作过了一遍，下次再遇到字符串相关的问题，希望能帮你少走几步弯路。