1. 字符编码的前世今生从ASCII到EBCDIC第一次在Windows记事本里保存文件时看到ANSI这个选项我就懵了——这玩意儿和ASCII有什么关系后来在跨国项目里处理日文数据时更被SJIS和EUC-JP搞得焦头烂额。字符编码就像数字世界的巴别塔不同系统说着不同的方言而我们开发者就是要在这些方言之间当翻译。ASCII码诞生于1963年用7位二进制数0x00-0x7F表示了128个字符包括英文大小写字母、数字和基础符号。这个设计在当时够用但很快就遇到了瓶颈——它连欧洲的带重音字母都装不下。于是各国家和地区开始制定自己的扩展方案中文的GB2312、日文的JIS X 0201、韩文的KS X 1001相继出现形成了诸侯割据的局面。有趣的是在ASCII成为主流之前IBM早在1963年就推出了EBCDIC编码。这个编码体系有多个变种如EBCDIC 500、EBCDIC 1140至今仍运行在IBM大型机上。有次我调试银行系统时就遇到过EBCDIC编码的报文用hexdump查看时发现字母A的编码居然是0xC1和ASCII的0x41完全不同当时排查了整整一天才找到编码转换的问题。2. 中文编码的进化之路从GB2312到GB18030在国内做开发GBK编码就像空气一样无处不在。但很多人不知道的是GBK其实是GB2312的扩展版本。GB2312发布于1980年采用双字节编码高字节范围0xA1-0xF7低字节范围0xA1-0xFE共收录6763个汉字。我在处理老旧系统数据时经常遇到GB2312编码的文件最头疼的就是有些生僻字比如镕在GB2312里根本找不到。GBK于1993年推出最大的改进是取消了低字节必须大于127的限制。只要第一个字节大于127就自动识别为中文字符。这使得GBK能表示21886个字符包括了繁体字和日韩汉字。记得有次处理香港客户的资料GB2312打开全是问号换成GBK就正常显示了。Windows系统中GBK对应的代码页是CP936这也是为什么在中文Windows下ANSI实际指的是GBK编码。GB18030则是我国现行国家标准支持70244个字符。它采用变长编码1/2/4字节完全兼容GBK。有趣的是GB18030-2005版强制要求支持汉字镕这导致很多老系统升级时出现兼容性问题。我在金融行业就遇到过这样的案例旧系统用GBK存储数据升级后新系统用GB18030结果报表生成时某些字符显示异常。3. 日文编码的战国时代SJIS与EUC-JP的较量处理日文数据就像走进编码的迷宫。Shift_JISSJIS是日本最常用的编码由微软和日本电气NEC共同制定。它的特点是混合使用单字节半角字符和双字节全角字符在Windows系统下的代码页是CP932。我有个项目需要处理日本客户的CSV文件用默认UTF-8读取全是乱码换成SJIS才正常显示。EUC-JP则是Unix/Linux世界的日文编码标准全称是Extended Unix Code for Japanese。与SJIS不同EUC-JP使用固定的双字节表示日文字符。有次我在Solaris服务器上处理日志发现用SJIS解码失败换成EUC-JP就成功了。这两种编码最明显的区别在于半角片假名在SJIS中占1字节0xA1-0xDF在EUC-JP中占2字节。更复杂的是Windows-31J编码这是微软对SJIS的扩展版本增加了NEC特殊字符和IBM扩展字符。IANA互联网号码分配局将其注册为windows-31J。实际开发中我建议优先使用Windows-31J而非原始SJIS因为前者能处理更多特殊符号比如①这样的带圈数字。4. 编码转换实战乱码问题的终极解决方案处理多语言系统时编码转换是必修课。Linux下的iconv命令是我的救命稻草基本用法如下# 将EUC-JP文件转换为UTF-8 iconv -f EUC-JP -t UTF-8 input.txt output.txt # 检查文件实际编码 file -i filename.txt在Java项目中我总结了一套编码处理的最佳实践始终明确指定字符编码String content new String(bytes, GB18030); byte[] output content.getBytes(UTF-8);使用CharsetDecoder进行严格验证CharsetDecoder decoder Charset.forName(SJIS).newDecoder(); decoder.onMalformedInput(CodingErrorAction.REPORT); decoder.onUnmappableCharacter(CodingErrorAction.REPORT);处理BOM头问题// 检测并去除UTF-8 BOM if (bytes.length 3 bytes[0] (byte)0xEF bytes[1] (byte)0xBB bytes[2] (byte)0xBF) { return new String(bytes, 3, bytes.length - 3, UTF-8); }最棘手的要数EBCDIC编码转换。有次对接银行主机系统我写了个转换工具// EBCDIC 500转ASCII public static String ebcdicToAscii(byte[] ebcdicBytes) { Charset ebcdicCharset Charset.forName(IBM500); return new String(ebcdicBytes, ebcdicCharset); }记住一个黄金法则在内存中统一使用UTF-8仅在输入输出时进行编码转换。这样可以避免99%的乱码问题。对于遗留系统建议建立编码转换中间层而不是直接修改原有代码。