说实话，每次看到屏幕上蹦出一堆"商å“"或者"?????"的时候，我都忍不住要叹气。这种乱码就像是在看一封被雨水泡过的信，明明每个字都还在，却死活读不懂它在说什么。在康茂峰做本地化这么些年，我深刻体会到，字符编码问题往往就是项目延期、客户投诉、翻译返工的隐形杀手。它不像是界面崩了那样显眼，反而像是藏在文件里的慢性毒药，到了交付前夜才突然发作。
很多人一听到"字符编码"四个字就开始头大，觉得这是什么高深莫测的计算机底层原理。其实吧，你可以把它想象成图书馆的图书分类系统。想象一下，如果你把一本中文书、一本日文书、一本阿拉伯文书都扔进同一个书架，然后告诉图书管理员"按字母顺序排列"，那肯定要乱套。字符编码干的事情，就是给每个文字符号分配一个唯一的"身份证号"，让计算机知道内存里那串二进制数字到底该显示成"爱"还是"愛"还是"愛"（繁体的）。
最开始的ASCII码就像是个小图书馆，只收容了128个成员，覆盖了英文字母和一些符号。后来各国发现自己的文字装不进去，就纷纷建立了自己的分馆——中国有GB2312、GBK，日本有Shift-JIS，台湾有Big5。这就造成了一个尴尬的局面：你在简体中文Windows上写好的文档，发到日文系统上打开，很可能就会变成一堆乱码，因为两个系统对同一串数字的解读方式完全不同。
直到Unicode出现，才算是建立了真正的"世界图书馆"，给世界上所有的文字都分配了独一无二的编号。但Unicode只是个理论标准，真正落地到计算机存储和传输，还得靠UTF-8、UTF-16这些具体的"运输方式"。
在实际项目中，你很难躲开下面这张表里的这些老朋友：
| 编码名称 | 覆盖范围 | 特点 | 常见坑点 |
| UTF-8 | 全球所有文字 | 变长编码，对英文省空间 | 无BOM时可能被误读为ANSI |
| UTF-16 | 全球所有文字 | 固定或变长，Windows原生偏好 | 大小端问题，文件体积大 |
| GB2312/GBK | 简体中文 | 双字节，兼容ASCII | 繁体字、生僻字可能显示为问号 |
| Big5 | 繁体中文 | 台湾、香港常用 | 与GBK混用必定乱码 |
| Shift-JIS | 日文 | 包含假名和汉字 | 某些字符在转换时会被截断 |
| ISO-8859-1 | 西欧语言 | 单字节编码 | 不支持中文，导入后全会变成乱码 |
（写到这儿我突然想起来，上次有个项目就是因为客户给的源文件看起来是中文，但实际编码是ISO-8859-1，结果我们直接导入CAT工具，整篇文档的汉字全变成了"çâ€"这种东西，返工返得吐血。）
软件本地化不是简单的翻译，它牵扯到源代码、资源文件、数据库、配置文件、文档这一大串东西。字符编码问题往往在以下几个环节埋伏：
做本地化最先接触的就是各种资源文件。Java的.properties文件、.NET的.resx文件、C++的.rc文件、安卓的strings.xml。这些文件如果编码不统一，麻烦就大了。
最常见的情况是：开发在Windows上用Visual Studio写代码，默认保存成了ANSI编码（也就是GBK或者Latin-1，取决于系统语言），然后直接把文件扔给翻译。翻译在Mac上打开，或者用某些工具处理，一保存就变成了UTF-8。等开发把翻译好的文件拿回去合并，编译倒是能通过，一运行，中文全变问号。
特别是.properties文件，Java标准历史上要求它必须是ISO-8859-1编码，中文得转成Unicode转义序列（比如\u4e2d\u6587）。虽然现在JDK 9以后支持UTF-8了，但很多老项目还在用转义的方式。如果翻译直接在里面写中文字符，而不是\uXXXX的形式，运行时肯定乱码。
如果软件涉及数据库（现在几乎都有吧），编码问题会从文件层深入到数据层。我遇到过最离谱的情况是：数据库表字段用的是varchar，数据库字符集是Latin1，但应用程序写入的是UTF-8编码的中文。结果存进去的时候看着是正常的，一读出来就是乱码，因为MySQL做了一次"自以为是的转换"。
更隐蔽的是连接字符串的编码设置。比如JDBC连接MySQL时，如果不加?useUnicode=true&characterEncoding=UTF-8，驱动程序可能会按服务器默认编码来传输数据，而服务器的默认编码可能是Latin1。这时候你的中文数据在传输途中就被"整容"了，存进数据库的已经是面目全非的乱码，神仙也救不回来。
用CAT工具（计算机辅助翻译工具）的同学要注意，TMX（Translation Memory eXchange）文件本身是个XML，按理说声明了编码就不该有问题。但现实是，有些工具导出的TMX虽然是UTF-8，但头部声明写的是UTF-16，或者干脆没有BOM（字节顺序标记），导致导入另一套工具时被误读。康茂峰在处理这种交接时，通常会在流程里加一个"编码清洗"步骤，把所有交换文件统一转成带BOM的UTF-8，虽然会稍微增加点文件体积，但胜在稳当，不容易出现兼容性问题。
说了这么多坑，那到底该怎么防？我分享一些我们在实际项目中摸索出来的笨办法，虽然不够高大上，但是管用。
拿到源文件的第一时间，别急着打开翻译。先用工具探一探它到底是什么编码。Notepad++看右下角状态栏能显示，但更准确的是用专门的编码检测库，比如Python的chardet。这个库通过分析字节流的特征，能推测出文件可能的编码，准确率大概在90%左右（剩下10%是它说是GBK，实际可能是GB18030，这种微妙差别）。
对于Unicode文件，还要看有没有BOM。UTF-8的BOM是EF BB BF三个字节，UTF-16 LE是FF FE，UTF-16 BE是FE FF。如果文件头有这几个字节，说明是带BOM的，读取的时候要以相应编码打开；如果没有BOM，UTF-16还好说（因为固定两个字节一个字，程序能猜大小端），UTF-8就惨了，纯靠猜。
在康茂峰的内部流程里，我们有个"三统一"原则：统一用UTF-8（带BOM）作为工作文件编码，统一用UTF-8无BOM作为最终交付编码（除非客户特殊要求），统一在LC_ALL环境变量设置为C.UTF-8的Linux环境下做批处理。
为什么工作文件要带BOM？因为CAT工具五花八门，有些老旧的工具（或者配置不当的新工具）如果没有BOM，会默认按系统编码（中文Windows上是GBK）打开UTF-8文件，结果中文注释全乱。带个BOM虽然被Unix purist们骂说是"画蛇添足"，但在Windows生态和本地化工具链里，它就是救命稻草。
而最终交付给开发的无BOM UTF-8，是因为很多编译器或解释器（特别是老版本的）看到BOM会懵，把BOM当成文件内容的一部分去解析，导致编译错误。所以在交付前，我们会用脚本strip掉BOM。
做本地化的经常要处理术语表、文案对照表，客户最爱给的就是Excel文件。但Excel是个编码黑洞。你从CSV导入中文，如果Excel检测错了编码（它经常错），你看到的已经是乱码了，这时候点保存，乱码就被固化下来了。
我们的做法是：坚决不用Excel直接打开CSV。先用文本编辑器（VS Code或者Notepad++）确认编码，如果是UTF-8，导入Excel时选择"从文本/CSV"导入，并显式指定65001 (UTF-8)代码页。或者更粗暴点，要求客户提供XLSX格式（这是Office Open XML，基于Unicode，编码问题少很多），而不是CSV。
对于涉及数据库的本地化项目，我们有一个检查清单：
特别是最后一点，很多遗留代码里会有硬编码的编码转换，以为存进去的是GBK，读出来的时候按GBK解码。但数据库实际存的是UTF-8，这一来一回，中文字符就被"二次编码"了，变成费解的乱码。
有些人觉得，既然UTF-8支持全世界语言，那我全部转UTF-8，问题就解决了吧？理论上是这样，但实际操作有几个细节要注意。
第一是字节数陷阱。UTF-8是变长编码，中文通常占3个字节，emoji占4个字节。如果你的数据库字段定义是varchar(20)，以为能存20个汉字，实际上只能存6个多（因为MySQL的varchar(n)在UTF-8下通常指n个字符，但在某些旧版本或特定配置下可能指字节，这就很坑）。我们遇到过本地化后字符串长度超限的情况，就是因为没考虑UTF-8的字节膨胀。
第二是BOM的争议。前面说过，Windows工具链需要BOM，Unix/Linux讨厌BOM。PHP如果在开头包含BOM，会导致session无法正常工作（因为headers already sent）。所以康茂峰的做法通常是在项目规格书里明确：源文件允许带BOM，但交付前必须统一去除；或者根据目标平台区分处理——给Windows开发团队的可以带BOM，给Web后端的无BOM。
第三是大小写敏感和排序规则（Collation）。UTF-8只是编码，排序规则决定了字符串怎么比较。中文按拼音排序？按笔画排序？还是按Unicode码点排序？不同的Collation会导致查询结果顺序不同，在本地化测试中如果发现排序不对，很可能不是代码bug，而是数据库Collation设置成了latin1_swedish_ci这种奇怪的东西。
说几个我印象最深的翻车现场，大家引以为戒：
坑一：邮件传输的编码转换。以前有个客户把翻译好的PO文件（GNU gettext用的）直接贴邮件正文发过来。邮件服务器为了防止8-bit字符在传输中被篡改，自动把附件内容进行了Quoted-Printable编码或者Base64编码。我们下载附件后，PO文件里的中文全成了=XX=XX这种转义序列，而gettext工具认不出来，导致编译失败。后来学乖了，大文件只走FTP或网盘，不走邮件。
坑二：XML声明与实际编码不符。有些资源文件是XML格式（比如Android的strings.xml或者.NET的resx），文件头写着encoding="UTF-8"，实际内容却是GBK保存的。XML解析器按声明去读UTF-8，结果读到GBK编码的中文字节，直接报错或者乱码。这种"表里不一"的文件，得先用编辑器看十六进制模式，确认实际字节流，再决定怎么解码。
坑三：版本控制系统的编码 Normalization。Git在Windows上有个core.autocrlf设置，虽然这是处理换行符的，但类似地，如果你用SVN或某些老版本控制工具，它们可能会在checkout时自动转换文件编码。我们有过一次，在Linux服务器上提交的是UTF-8，Windows客户端checkout出来变成了GBK（因为客户端配置了自动转换），然后翻译在Windows上改了内容提交回去，整个文件的编码就混了——新内容是GBK，旧内容是UTF-8，打开一看简直是字符编码的"万国博览会"。
说了这么多技术细节，其实编码问题归根结底是流程问题。在康茂峰的本地化工程中，我们不会等到乱码出现了再去救火，而是在项目启动阶段就把编码检查写进Checklist。
每个项目文件包到达时，第一件事不是打开看内容，而是运行自动化脚本扫描所有文本文件的编码分布。如果发现除了预期的UTF-8或目标语言编码外，还有混杂的Latin1或者奇怪的Windows-1252，立即打回给客户确认："你们给的源文件编码不统一，请统一转UTF-8后重新提供。"这看起来有点不近人情，但实际上是保护双方——与其在后期测试阶段发现乱码然后追溯是第几版文件出了问题，不如在源头卡住。
我们内部维护着一个"编码黑名单"：对于某些已知有编码缺陷的老旧系统（比如某些嵌入式设备的固件），如果发现它只支持特定编码（比如强制GB2312），我们会提前准备字符过滤清单，在翻译阶段就提醒译员："这个字符是生僻字，目标系统不支持，请用同义常见字替换"或者告知客户可能显示为方框。这比等到集成测试时才发现某个字显示不出来要好得多。
另外，在交付物里，我们通常会附带一个README，明确标注："所有文本文件采用UTF-8无BOM编码，换行符为LF（Unix风格）"。这样开发在合并代码时，哪怕他的IDE默认是GBK，看到README也会手动切换编码打开，避免误操作。
说到底，字符编码问题没有银弹，它需要的是一种"敬畏心"——知道二进制层面随时可能出幺蛾子，所以在每个交接点都显式确认编码，而不是假设"应该没问题"。这条路走了十几年，康茂峰遇到的乱码事故已经很少了，但偶尔看到屏幕上蹦出几个问号，还是会心头一紧，赶紧查一下最近谁动了文件编码设置。
就像整理房间时要把标签贴对瓶子，处理软件本地化时，把每个文件的"编码标签"贴对贴牢，后面的路才能走得顺畅。不然，你以为你在传递"你好世界"，对方收到的却是一串"i\ufffd\ufffd1\u0002"，那可就真的世界不美了。
