★ FEATURED ARTICLE 半夜两点被线上告警吵醒查了半天才发现是某个接口返回的中文变成了锟斤拷这一类场景应该是不少后端开发者的共同记忆。不管是锟斤拷还是烫烫烫归根结底都是编码问题——一个字符从写入到读出的链路中某个环节用错了字符编码或者数值在跨系统传递时位宽被截断。在这个信息时代编码问题无处不在你敲下的每个中文字符、浏览器地址栏里的%E7%BC%96%E7%A0%81、数据库里存的小数、甚至磁条卡刷出来的数据背后都有一套编码规则在运转。这篇内容想做的事很简单把「编码」这个词从字符层面一路拆到数值表示层面把 ASCII、Unicode、UTF-8、URL 编码、Base64、原码反码补码、IEEE 754 浮点数这套东西串成一条线。适合刚接触计算机基础的新人也适合写过几年业务代码、遇到乱码和小数精度问题时能更快定位的老手。看完你至少能搞清楚编码的本质到底是什么为什么同一段字节在不同环境下会解释出完全不同的含义以及遇到这些问题时该从哪一步开始查。1. 字符编码的底层逻辑从一块铁皮到一套查表约定1.1 先搞清楚一件事编码的本质是「约定」如果把计算机看成一座仓库编码就是仓库里每个货架上的编号规则。字符编码做的事是把人类能看懂的符号A、中、你映射成计算机能存的数字反过来把数字映射回符号的过程叫解码。就这么简单——编码和解码必须使用同一套映射表否则就会出现鸡同鸭讲。举一个日常场景停车场每个车位有一个编号你把车停在B12号位拍张照记下编号回来时按编号找车。这里B12就是你的车这个物体的编码。如果管理者换了一套编号规则比如把 B12 改成了 3F·2而你手里的纸条还写着 B12那你就找不到自己的车。计算机里的乱码本质上就是这种号码本不一致造成的A系统用 GBK 把中编成了D6 D0B系统用 UTF-8 去解码D6 D0解出来就变成了或者更匪夷所思的字符。明白了这一点后面所有内容都是顺水推舟。不同的字符编码方案就是不同版本的号码本它们的覆盖范围、编号规则各不相同。1.2 ASCII 时代128 个符号就把计算机送上天ASCIIAmerican Standard Code for Information Interchange是最早的字符编码标准之一把所有英文字母、数字、标点和控制字符编进了 7 个 bit 里总共 128 个位置0-127。0–31控制字符。比如\n是 10\t是 9\0是 0这些不可见字符负责指挥终端设备。32–126可打印字符。空格是 32A是 65a是 970是 48~是 126。127DEL 删除。这里有一个值得记住的细节数字字符0ASCII 码 48和数值 0 的二进制00000000完全是两回事。前者是字符0要显示成字形后者是整数零用于算术运算。很多初学者混淆这两个概念做字符串转数字时就会踩坑。因为早期计算机只需要处理英文128 个码位绰绰有余。但欧洲人首先发现不够用——法语的重音字母、德语变元音、北欧文字放不下了。于是 ISO 8859 系列把第 8 位也用上扩展成 256 个码位比如 Latin-1 支持西欧语言。可这依然解决不了全世界的文字需求。亚洲这边中文常用汉字就有六千多一个字节根本装不下。1.3 多字节时代的群雄混战GBK 和它的兄弟们中文计算机化始于 1980 年代大陆这边先后出现了 GB2312、GBK、GB18030 三套主要字符集。GB2312 收录了 6763 个常用汉字采用区位码的设计每个字符由两个字节表示。这里的原理很简单一个字节 256 种组合两个字节就是 65536 种足够覆盖常用汉字。GBK 在 GB2312 基础上扩充增加了繁体字、生僻字总码位超过两万。GB18030 更是用了变长编码1/2/4 字节理论上能覆盖整个 Unicode 字符集。麻烦在于这套号码本和其他国家的号码本互相冲突。同一个字节序列C4 E3在 GBK 里解码是你在 Big5繁体中文里可能是另一个字在东欧的编码里可能就是两个重音字母。于是形成了著名的乱码三兄弟用 UTF-8 解 GBK 的字节出现用 GBK 解 UTF-8 的字节出现涓嬭浇这类奇奇怪怪的汉字组合如果编码转换时字符在中途被截断再组合就可能出现锟斤拷。所谓锟斤拷是 GBK 字符集里三个不常用汉字锟、斤、拷它们的字节序列恰好和某些无法映射的替代字符UFFFD显示为在 GBK 下的编码相同。网络热词里锚的解答编码经络不克制隐值以外帖子这种词条本质上就是搜索引擎把乱了码的文本又当成了正常文本去抓取属于编码事故的次生灾害。1.4 Unicode 出世给全世界的字符一个统一编号各个国家各自搞一套编码跨国软件维护起来非常痛苦。Unicode 联盟推出了一套宇宙统一号码本给全世界所有字符分配一个唯一的码点Code Point从 U0000 一直排到 U10FFFF总共一百多万个位置目前真正分配出去的在十几万左右。Unicode 把码点划分为 17 个平面Plane每个平面 65536 个码位第 0 平面BMP基本多文种平面U0000 到 UFFFF覆盖绝大多数现代文字。第 1–16 平面补充平面放古文字、数学符号、Emoji 等。比如编字的码点是 U7F16码字的码点是 U7801。这些都只是一个数字编号和具体怎么存储无关。这里必须强调一个很多人都会误解的点Unicode 不是一种存储编码方案它只是一个字符编号表。就像每个公民有身份证号但身份证号的载体可以是身份证、护照、电子证照。码点要变成字节存进内存还需要传输/存储编码方案来负责这就是 UTF-8、UTF-16 这类东西的工作。1.5 UTF-8/UTF-16 的落地怎么把码点装进字节UTF-8 是目前互联网的事实标准它的核心思想是变长编码根据码点大小使用 1 到 4 个字节。Unicode 码点范围二进制格式x 表示有效数据位U0000 ~ U007F0xxxxxxxU0080 ~ U07FF110xxxxx 10xxxxxxU0800 ~ UFFFF1110xxxx 10xxxxxx 10xxxxxxU10000 ~ U10FFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx为什么 UTF-8 这么设计它巧妙地用引导字节的高位标记一个字符占多长0开头表示单字节兼容 ASCII110表示 2 字节1110表示 3 字节11110表示 4 字节后续字节一律以10开头。这使得解码器可以自同步——即使从一个字符的中间开始读也能很快找到下一个合法的字符边界。以编字为例码点 U7F16 落在 U0800~UFFFF 区间需要 3 字节。把0x7F16展开成二进制0111 1111 0001 0110塞进1110xxxx 10xxxxxx 10xxxxxx模板得到11100111 10111100 10010110十六进制就是E7 BC 96。你在 Chrome 地址栏输入中文时浏览器做的正是这个转换。UTF-16 则是另一个思路BMP 内的码点直接用 2 字节存超出 BMP 的用 4 字节代理对表示。它的问题在于字节序——0x7F16是存成7F 16大端还是16 7F小端所以 UTF-16 文本通常带一个 BOMByte Order MarkUFEFF来声明字节序开头是FE FF说明大端FF FE说明小端。UTF-8 由于按字节序列解码不存在字节序问题这也成了它最终胜出的原因之一。2. 实战中的编码连环坑从 URL 里的 % 到 Java 里的默认编码2.1 URL 编码百分号后面到底藏了什么网络热词里赫然列着url编码可见它确实是日常开发中出现频率最高的编码问题。URL 编码的学名叫百分号编码Percent-encoding规则其实很机械保留字符RFC 3986 中的保留集需要被编码。非 ASCII 字符先按 UTF-8 转成字节再对每个字节写为%XXXX 是字节的十六进制大写。空格在表单提交的application/x-www-form-urlencoded里会变成但在 URL 路径部分应该编码为%20。比如中文编码两个字UTF-8 字节是E7 BC 96 E7 A0 81URL 编码后就变成%E7%BC%96%E7%A0%81。这就是你看到浏览器地址栏里那一长串%的由来。实际排查时我发现很多人的问题出在重复编码或重复解码后端拿到的参数已经是解码后的中文又被调用方手动做了一次URLEncoder.encode导致中文字符自身的 UTF-8 字节里恰好有%字节0x25时再解一次就出错。经验法则在入口统一解码一次在出口统一编码一次不要在业务代码里反复转。2.2 Base64明明能直接读为什么还要编码Base64 这个编码在热词里和隐藏两个字关联——base64编码隐藏不少人在网上看到过类似用 Base64 藏一段文字的玩法。但 Base64 本身并不是加密它只是把二进制数据表示成 64 个可打印 ASCII 字符外加填充符一种简单的数据转义手段。它的编码规则是每 3 个原始字节24 bit切分成 4 组 6 bit每组 6 bit 按索引表映射成一个字符如果原始数据长度不是 3 的倍数用 1 到 2 个补齐。比如字符串Man编码成TWFu单独一个字母A则编码成QQ。Base64 在开发中的正经用途包括在 URL 里传输二进制数据配合 URL 安全字符集-和_、在 JSON/XML 里嵌入图片或文件内容、HTTP Basic 认证里传用户名密码。至于隐藏信息它起的只是看起来不那么像乱码的作用别人用atob()或base64 -d一秒就能还原不要把它当安全机制用。真要藏东西至少叠加一层加密否则等于在门口贴了一张写着密码的便签。2.3 Java 编码混乱之源defaultCharset、file.encoding 和 Content-TypeJava 是跨平台语言但跨平台跨来的编码问题能让任何老手头疼。核心变量是Charset.defaultCharset()——它由 JVM 启动参数-Dfile.encoding决定没指定时就取操作系统区域设置。在同一台 Linux 容器里环境变量LANGC和LANGzh_CN.UTF-8跑出的默认字符集可能完全不同。实际踩过的坑包括String.getBytes()不传参数用的是 JVM 默认字符集。在本地 WindowsGBK正常部署到 LinuxUTF-8就乱码。读取外部文件时没指定编码FileReader默认按平台编码读读写不一致直接锟斤拷。HTTP 响应的Content-Type头里没写charsetUTF-8客户端只能按自己默认的 ISO-8859-1 去解中文全变??。我的建议是Java 项目在启动脚本里显式加上-Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8所有文件 IO 显式传StandardCharsets.UTF_8HTTP 接口统一在响应头声明字符集数据库连接串里加characterEncodingutf8。虽然啰嗦但能免掉后续所有猜谜环节。2.4 Python 的 encode/decode 和 UnicodeEncodeError 处理Python 3 相比 Java 简单一些str内部统一是 Unicode只有在输入输出边界才需要 encode/decode。最常见的报错是UnicodeEncodeError: gbk codec cant encode character \u2026 in position 0: illegal multibyte sequence这是 Windows 下控制台输出时Python 试图用 GBK 输出一个 GBK 不支持的字符比如…触发的。解法是强制 stdout 使用 UTF-8import sys sys.stdout.reconfigure(encodingutf-8)排查这类问题有一个好习惯用repr()看字符串原始内容它会把不可见字符转义显示出来。比如看到\ue769这种码点再对照 Unicode 表就能确认数据从哪一步开始变的。还有errors参数errorsreplace会把无法解码的字节换成errorsignore则直接丢弃——这两种方式在生产日志里都只是权宜之计真正的根因治理还是在边界统一字符集。2.5 排查乱码的一线方法论乱码问题千变万化但排查路径完全可以标准化。我一般按四步走定位乱码发生的节点数据在哪个环节开始变前端→后端→数据库→展示每跳一层都可能是转换点。把字节 dump 出来看十六进制这是最狠也最有效的一步。把出问题的字符串转成字节数组Python 的abc.encode(utf-8)或 Java 的str.getBytes(StandardCharsets.ISO_8859_1)看字节到底长什么样。用不同的字符集去解码这些字节GBK 解不开就试 UTF-8、Latin-1通常一两次就能认出原始编码。修复源头不是去治乱码而是把出错链路里缺失的字符集声明补上。这个方法能解决九成以上的乱码问题。剩下那一成基本都是多层转换叠加、根本无法还原的情况此时最好的做法是回到上游重新取数而不是在残缺字节上做逆向。3. 数值表示的本质原码反码补码不是套路是一种数学选择3.1 为什么需要把数字编码进二进制如果说字符编码解决的是符号怎么变成数字那数值表示解决的是数字本身怎么变成 0 和 1。这是两个层面的事。计算机的存储单元只有两个状态所以任何数字都必须编码成二进制串。对一个无符号整数来说这个编码过程就是简单的进制转换十进制 13 变成1101。但计算机不可能只处理正数。负数怎么表示浮点数怎么表示这就要讨论具体的编码方案了。需要提醒的是很多教材把原码、反码、补码当成规定来背其实它们是数学推演的自然结果。理解了为什么要这样设计自然就记住了怎么算。3.2 原码和反码的致命缺陷关于0和-0原码是最直观的方案用一个 bit 表示符号0 正 1 负其余位表示绝对值。以 8 位为例5是0000 0101-5是1000 0101。问题在哪首先0 有了两种表示0000 0000和1000 0000分别表示0和-0这在很多逻辑判断里会造成明明相等却不相等的困扰。其次做算术运算还要单独处理符号位电路设计非常麻烦。反码在原码基础上把负数的数值位逐位取反符号位不动。-5变成1111 1010。但它依然有双 0 问题和进位处理上的缺陷。直接拿反码做加法结果还要修正并不省心。3.3 补码模运算思想带来的自然结果补码的设计动机非常巧妙把减法变成加法并且消灭-0。理解它的钥匙是模的概念。想象一个 8 位的计数器它能表示 0~255超过 255 就溢出归零。在这个世界里加上 256 和什么都不加等效。那么-1就完全可以表示成255——因为x 255等价于x - 1溢出正好把 256 吞掉。用 8 位二进制表示-1就是1111 1111-2是1111 1110-5是1111 1011。接下来的问题就变成了给定一个正数 x怎么很方便地求出256 - x的二进制答案是x 的各位取反再加一。因为把一个数的所有位取反相当于得到255 - x再加一就是256 - x。这就是负数的补码 反码 1的由来它不是人为规定的魔法而是模运算的自然推论。验证一下 8 位补码的算术5 (-5) 0000 0101 1111 1011 1 0000 0000溢出丢失最高位后归零结果正确。8 位补码能表示的范围也顺理成章正数从 1 到 127负数从 -1 到 -128。1000 0000之前在原码里是 -0现在专门表示 -128多出来一个负数这也解释了为什么 Java 里byte的取值是 -128 到 127而不是 -127 到 128。3.4 溢出、位宽与有符号无符号的转换补码真正强大之处在于加法器根本不管操作数是有符号还是无符号它只管位运算符号解释由程序来定。同一个字节1111 1111按无符号数解释是 255按有符号补码解释是 -1。C 语言里可以靠类型转换轻易切换这两种视角Java 里则是Byte.toUnsignedInt()这类方法做转换。溢出的问题也很典型Java 的int是 32 位补码最大值是21474836470x7FFFFFFF一旦加一会变成-21474836480x80000000这在很多计数、金额累加业务里是致命的。实际项目中我见过不少因为 int 溢出导致的库存数变成负数、排名出现负数成绩的 bug。解决方案是提前用更大类型long/BigInteger、或者对安全边界做好检查。网络传输时还有一个大小端问题一个 16 位整数0x1234网络字节序大端传12 34小端传34 12。HTTP/2、TCP 头里到处都有这个坑抓包时如果不搞清楚字节序读出来的端口号、长度字段全是错的。3.5 数值编码在真实语言里的体现不同语言对数值编码的封装程度不同但底层都是那套补码机制C/Cuint8_t 和 int8_t 的转换本质是同一个字节的不同解释存在-Wsign-conversion这类编译告警提醒开发者注意。Java所有整数类型都是有符号补码无符号操作要靠Integer.toUnsignedString()等 API 绕路。Python整数无限精度但struct.pack(i, -1)照样按 32 位大端补码输出ff ff ff ff。4. 浮点数的编码IEEE 754 里的特点和小数的秘密4.1 小数为什么没法精确表示很多人以为浮点数不精确是精度不够其实从表示原理上就有问题。二进制小数的表示形式是[ 0.1_{10} 0.000110011001100110011..._2 ]0.1 这个简单的十进制小数在二进制里是无限循环小数任何有限的 bit 都装不下。这就像用十进制小数 0.333... 无法精确表示 1/3 一样不是位数多少的问题而是基底不同导致的表达局限。所以浮点数编码本质上是一种近似方案用固定位数存一个足够接近的值。你能做的就是知道它约在哪里然后通过算法处理误差而不是期待它完全精确。4.2 IEEE 754 结构符号位、指数位、尾数位IEEE 754 是当前所有主流 CPU 和高级语言共同遵守的浮点数标准。单精度 float 用 32 位双精度 double 用 64 位布局如下类型符号位指数位尾数位偏置量float1 bit8 bit23 bit127double1 bit11 bit52 bit1023数值的实际公式是[ value (-1)^{sign} \times 1.mantissa \times 2^{(exponent - bias)} ]其中尾数部分默认隐藏一个前导 1规格化数所以 23 bit 尾数实际可以解释为 24 bit 精度。指数位存的是真实指数 偏置量。以 float 为例真实指数 -126 到 127存储值就是 1 到 2540 和 255 有特殊用途0 表示零和次正规数255 表示无穷大和 NaN。手算一个例子0.5的二进制是0.1规范化为1.0 × 2^(-1)所以符号位 0指数存储值为 -1127126尾数为全 0。字节表示就是0x3F000000。而1.5规范化为1.1 × 2^0尾数第一位小数部分是 1所以 23 位尾数最高位是 1其余为 0得到0x3FC00000。4.3 为什么 0.10.2 不等于 0.3任何一个前端、后端开发者都应该亲眼见过这个0.1 0.2 // 0.30000000000000004原因很简单0.1 和 0.2 在二进制里都是近似值两者相加的结果自然也是近似值而这个近似值恰好比 0.3 的近似值大了一点点。Java 和 Python 里做同样运算结果本质相同只是默认打印位数不同。更隐性的坑是直接比较if 0.1 0.2 0.3: print(相等) else: print(不相等) # 实际走这里解决方案没有魔法只有策略比较时用阈值epsilon比如abs(a - b) 1e-9。金额、数量等十进制敏感数据用整数分或 decimal/BigDecimal。对外展示时按需要的精度格式化不要拿原始二进制近似值拼字符串。4.4 double 的极端值与工程取舍double 虽然精度高很多但也不能精确表示大多数十进制小数。在一些科学计算、物理引擎里误差累积是必须处理的话题。实际开发中我常用的检查手段是把浮点数转成字符串看具体值比如 Java 里用BigDecimal.valueOf(double)而不是new BigDecimal(double)——前者能取到人类认知中的十进制形式后者会把二进制里的真实值抖出来比如 0.1 变成 0.1000000000000000055511151231257827021181583404541015625。IEEE 754 还规定了一堆边界值Float.MIN_VALUE是最小正规格化数还是最小正数次正规数subnormal能表示更小的数但精度大幅下降Infinity 参与算术、NaN 不等于自身这些细节在协议解析、数值计算里都可能成为隐雷。5. 从字符与数值出发编码在其他领域的表现5.1 压缩编码霍夫曼编码与 LZW编码不仅在字符↔数字和数字↔二进制这两层。热词里的霍夫曼编码压缩比怎么算lzw编码ldpc编码都指向另一块广阔版图。霍夫曼编码Huffman Coding是数据压缩的基础算法之一核心思想是出现频率高的符号用更短的码字频率低的用更长的码字使得平均码长最短。做法是先统计每个符号的出现频率然后反复合并两个最小频率节点构建一棵二叉树树左分支为 0、右分支为 1叶子节点的路径就是它的编码。压缩比的计算方法是[ 压缩比 \frac{原始总位数}{霍夫曼编码总位数} ]比如一段文本有 4 个字符 A、B、C、D分别出现 50、30、10、10 次。固定 2 位编码需要100×2200 bit霍夫曼给 A 分配 1 位、B 2 位、C 3 位、D 3 位总位数是50×130×210×310×3170 bit压缩比约 1.18。关键点霍夫曼编码表依赖输入数据的统计特征所以压缩文件必须把编码表也存下来否则无法解码。LZWLempel-Ziv-Welch是另一种思路动态建立字典把重复出现的字符串片段映射成较短的数字索引。GIF 图像格式用的就是 LZW 的变体。它的厉害之处是不需要预先知道频率一边扫描一边构建字典解码端也能同步恢复字典所以压缩包里不用带表。5.2 纠错编码LDPC 码的工作原理热词里的ldpc编码属于信道编码范畴负责解决数据在传输过程中被噪声干扰的问题。LDPC低密度奇偶校验码的核心思想是给原始数据附加一些冗余校验位让接收端不仅能发现错误还能根据校验关系推断出正确数据。它之所以叫低密度是因为校验矩阵里 1 的个数非常少。解码过程通过迭代消息传递算法逼近最大似然解。今天的高速无线通信5G、卫星通信、存储系统里都有它的身影。这类编码和字符编码的区别在于字符编码关注语义映射压缩编码关注去冗余纠错编码关注抗干扰它们解决的问题域完全不同。5.3 冷门编码串讲Booth、磁编码、地理编码与各种业务编码网络热词里的booth编码出现时很多人的第一反应是这也能编码。Booth 编码Booths algorithm是计算机组成原理里的补码乘法优化算法通过把连续的 1 序列转化成移位和加减法操作减少乘法器里部分积的数量。它不是一种格式更像一种乘法的加速技巧。磁编码则完全是另一世界磁条卡背面那层磁条上存的数据通过改变磁通翻转的位置来记录二进制信息银行磁条卡、门禁卡都是这套原理。而地理编码是指把地址/地名转换成经纬度坐标反地理编码则是把坐标转回地址导航和配送业务里天天在用。至于pep8编码风格——这里的编码已经不是技术概念了说的是 Python 代码的格式规范PEP 8 定义了缩进、命名、空行等风格约定。工作流编码skill编码 193surface编码这类热词其实来自不同领域的业务术语比如工业上的物料编码、游戏动画里的状态机编码。可见编码这个词在不同上下文里指代的东西天差地别讨论问题前先对齐概念本身就是避免踩坑的第一步。5.4 回顾与实操习惯养成把字符编码、数值表示、压缩编码、纠错编码放在一起看共同点都是用一套双方约定好的规则在信息的不同形态之间建立映射。字符编码映射的是文字符号和字节数值编码映射的是数学概念和二进制位压缩/纠错编码映射的是数据冗余和信道特性。搞清楚这个抽象层次遇到新概念时你第一个问题应该是这里的编码是格式约定还是算法是存储问题还是传输问题我在实际排查编码问题时最后都会把数据拿到十六进制层面看一遍。不管你用的是 Python 的bytes.hex()、Java 的DatatypeConverter.printHexBinary还是命令行里的xxd十六进制就像编码世界的通用语言无论你用 UTF-8 还是 GBK 解释E7 BC 96它首先就是三个字节。从字节出发顺着字符集表去反推大多数谜题都能在几分钟内解开。另一个习惯是任何项目开工第一天就把全链路的字符集约定写进文档——前端页面、HTTP 头、后端框架、数据库连接、文件读写、消息队列逐个写明 UTF-8然后让这些默认值自动为你挡住绝大多数编码事故。如果你后续还想继续深入这个方向建议亲手实现一个小型的 UTF-8 编解码器、或者写一个霍夫曼编码压缩工具这类小项目能把今天聊的抽象概念全部变成肌肉记忆。编码没有想象中可怕它只是一张张精心设计的表而你要做的是保证表的两边永远一致。
阅读完成 · 觉得有帮助？
