调试时最让人心慌的瞬间：控制台吐出一串 \u4e2d\u6587、一长串 SGVsbG8、或者 0xFF 0x00。它们不是乱码，只是穿了"衣服"的数据。这篇把三种最常见的编码讲成人话。
JSON：数据交换的通用语法
JSON 不是编码，是数据格式——一套用文本表示结构化数据的语法，只有六种值：对象、数组、字符串、数字、布尔、null。解析失败的原因高度集中：
- 用了单引号（JSON 只认双引号）；
- 键没加引号；
- 最后一个元素后面多了逗号；
- 字符串里有未转义的双引号或换行；
- 加了注释（JSON 标准不允许，JSON5 才允许）。
遇到报错先把内容丢进 JSON 格式化，它会指出出错位置。格式化（加缩进）和压缩（去空白）都不改变数据语义，接口两种都收，调试用前者、传输用后者。
Base64：不是加密，是"二进制的安全运输包装"
Base64 把任意二进制数据用 64 个可打印字符表示：每 3 字节切成 4 组各 6 位，映射到 A-Z、a-z、0-9、+、/，体积膨胀 4/3，末尾用 = 补位。它的存在理由只有一个：让二进制数据安全通过只认文本的通道（邮件、JSON 字段、URL 参数）。
必须刻在脑子里的认知：Base64 不是加密。任何人拿到串都能瞬间还原，用它"藏"密码等于明文裸奔。另外两个高频细节：
- URL 里传 Base64 会因 + 和 / 出错，要用 URL-safe 变体（+→−，/→_）；
- 接口返回的 \u4e2d\u6587 不是乱码，是 Unicode 转义，解析后就是"中文"两个字——数据没坏，只是显示形式不同。
验证和转换用 Base64 编解码，支持中文，本地完成。
进制：0x、0b 前缀与"为什么 0.1+0.2 ≠ 0.3"
程序员世界里的数字常带前缀：0x 是十六进制（0xFF = 255）、0b 二进制、0o 八进制。十六进制是底层调试的宠儿，因为 2⁴=16，每 4 个二进制位恰好对应 1 个十六进制字符（1111 → F），内存、颜色、MAC 地址全用它。互转、验算用 进制转换。
顺带解开那个经典谜题：二进制只能精确表示分母为 2 的幂的分数，0.1 在二进制里是无限循环小数，所以浮点运算 0.1 + 0.2 = 0.30000000000000004。这是 IEEE 754 的固有特性，不是 bug——涉及金额的计算永远用整数（分）或十进制库，别用浮点数。
编码 vs 加密 vs 哈希，一句话分清
- 编码（Base64、URL 编码）：为了传输兼容，无密钥，人人可逆；
- 加密（AES、RSA）：为了保密，需要密钥，无钥不可逆；
- 哈希（SHA-256）：为了完整性校验，单向，不可逆。
把这三者混为一谈，最典型的后果就是把 Base64 当加密用——面试和实际事故里都屡见不鲜。
结论
看到"乱码"先别慌：\u 开头是 Unicode 转义，SGVsbG8 式长串大概率 Base64，0x 开头是十六进制。三个工具（JSON 格式化、Base64 编解码、进制转换）全在浏览器本地跑，粘贴敏感数据也安全。