为什么「GBK中文」总让人犯嘀咕？我琢磨过一阵，发现根子在于大多数人没分清"口径"和"算法"，混在一起自然算不对。
很多人默认选这个
简繁转换不只是字对字替换，要考虑一简多繁(发→發/髮)、用词差异(软件/軟體、计算机/電腦)、地域习惯。专业转换用OpenCC库支持词级转换和异体字处理，比简单字对字准确得多。字符串操作要考虑多字节字符，中文一个字不等于一个字节。哈希和加密是两码事，前者不可逆后者可逆，别混着用。
再看看另一个
编码方面：简体常用GBK/GB2312，繁体常用BIG5，统一用UTF-8最省心。纯字对字转换会出错(比如"皇后"的"后"和"后面"的"後"在简体都是"后"，转繁体要区分)，这就是为什么需要词库。处理文本统一用UTF-8，能避免90%的乱码和编码冲突问题。数据格式(JSON/XML/CSV)要先确认再解析，猜格式必出错。
到底怎么选
先搞清概念。GBK中文这类文本操作，本质是对字符串按某种规则转换或分析。搞懂规则(编码标准、正则语法、格式规范)，操作就有章法；规则没吃透，照着抄都会出错。中文用mb_系列函数处理，旧函数容易截断半个汉字出乱码。编码问题九成是UTF-8和GBK没统一，全链路统一UTF-8能解决一大半乱码。
几个要注意的地方
我踩过的坑，你尽量绕开：
- 不能字对字：简体"后"对应繁体"後"(后面)和"后"(皇后)
- "发"对应"發"(发展)和"髮"(头发)，字对字会出错
- 两岸用语差异：软件/軟體、计算机/電腦、网络/網路、打印/列印
- 统一用UTF-8能同时表示简繁，避免GBK/BIG5编码冲突
这一篇信息量不小，建议收藏起来，用到的时候翻出来对着算。比临时百度靠谱多了。
编码转换先确认源编码，盲目转只会越转越乱。大文件别一次性读进内存，用流式处理或逐行读取，否则容易OOM。特殊字符在该转义的地方一定要转义，否则解析失败或被注入。写完正则或解析逻辑，一定用边界案例测：空串、超长、特殊字符、Unicode。处理用户输入一定过滤特殊字符，防XSS和注入是基本功。处理文本统一用UTF-8，能避免90%的乱码和编码冲突问题。数据格式(JSON/XML/CSV)要先确认再解析，猜格式必出错。能用成熟库就别自己造轮子，特别是编码、加密、解析这种容易出错的领域。编码问题九成是UTF-8和GBK没统一，全链路统一UTF-8能解决一大半乱码。字符串操作要考虑多字节字符，中文一个字不等于一个字节。
常见问题
【GBK中文是什么意思？】属于文本处理范畴，是对字符串按特定规则转换或分析的操作。具体含义要看场景，但核心都是让文本数据能在不同环境正确表示和使用。
【简繁转换还要注意什么？】用词差异：软件/軟體、计算机/電腦、网络/網路、打印/列印。不只是字形，是两岸用语习惯不同。专业转换库(OpenCC)会处理这些词汇层面的差异。
【简繁转换为什么不能字对字？】因为一简多繁：简体"后"对应繁体"後"(后面)和"后"(皇后)，"发"对应"發"(发展)和"髮"(头发)。字对字会出错，要用OpenCC等支持词级转换的库。
【简体和繁体用什么编码？】简体常用GBK/GB2312，繁体常用BIG5，但现在统一用UTF-8最省心，能同时表示简繁甚至多国语言。乱码多半是编码不一致，统一UTF-8能解决大部分问题。
