如何用JavaScript处理跨语言编码字符串转换

JavaScript 字符串：跨系统编码转换的五个实战要点

在进行跨语言、跨平台的字符串编码转换时，许多开发者都常遇到乱码问题。例如，使用 UTF-8 格式传输一个“中文”字符串，对方却用 GBK 解读——结果屏幕上出现一片乱码。JavaScript 的字符串默认采用 UTF-16 存储，但现实中的文件、后端 API、旧系统或浏览器 URL，往往使用 UTF-8、GBK、Shift_JIS 或 Base64 组织数据。

乱码的本质是什么？核心在于字节与字符串之间的边界没有理清。因此，基本原则很简单：明确来源编码，再转换到目标编码。不能想当然地认为“传进来的就是 UTF-8”，也不能直接对中文调用 btoa()——它只支持 Latin-1 单字节，中文字符一传入就会报错。

处理 UTF-8 字节流：TextEncoder / TextDecoder 是首选

在较新的运行环境中（Chrome、Firefox、Safari、Node.js ≥ 11），这套方案零依赖且轻量。

• 字符串转 UTF-8 字节数组：new TextEncoder().encode("你好") 会返回 Uint8Array，例如 [228, 189, 160, 229, 165, 189]。
• UTF-8 字节数组还原成字符串：new TextDecoder("utf-8").decode(uint8Array) 会自动处理 BOM 标记和非法字节。如果需要容错，添加 { fatal: false } 即可跳过错误。
• 需注意：TextEncoder 仅支持 UTF-8；遇到 GBK、Big5、Shift_JIS 等老编码，则需要借助 encoding.js 或 iconv-lite。

安全进行 Base64 编解码（含中文和 emoji）

许多开发者曾踩过同一个坑：直接使用 btoa() 编码中文会抛出异常。其底层限制是只接受单字节字符串（Latin-1）。那么该如何操作？

• 编码（字符串 → Base64）：先通过 new TextEncoder().encode(str) 获取 Uint8Array，再使用 btoa(String.fromCharCode(...这个数组) 完成。
• 解码（Base64 → 字符串）：反向操作，用 atob(base64) 得到二进制字符串，然后 Uint8Array.from(atob(base64), c => c.charCodeAt(0)) 转为字节数组，最后 new TextDecoder().decode(字节数组)。
• 在老旧环境中没有 TextEncoder？可以用 encodeURIComponent 加正则替换来兜底，但效率较低，且不适用于二进制数据。

识别与转换未知多字节编码（GBK、SJIS、EUC-JP）

当读取本地文件、用户上传的文本或接收旧系统的响应时，经常面临一个问题：原始编码未知。此时需要分两步处理。

• 先用 encoding.js 的 Encoding.detect(bytes) 判断来源编码，它支持 UTF-8、GBK、SJIS、EUC-JP、ISO-2022-JP 等常见格式。
• 再用 Encoding.convert(bytes, { from: 'GBK', to: 'UTF8' }) 转换为目标编码。
• 如果使用 Node.js，iconv-lite 更成熟且常用：iconv.decode(buffer, 'gbk') 一步到位，直接得到字符串。

URL 编码：不同位置使用不同方法

开发中常有人混用 encodeURIComponent 和 encodeURI，导致参数解析失败。规则其实很清晰：

• encodeURIComponent() 是“泛用型”：它会对整个值进行 UTF-8 编码并百分号转义，最适合处理 query 参数。例如 "搜索=前端开发" 会变为 "%E6%90%9C%E7%B4%A2=%E5%89%8D%E7%AB%AF%E5%BC%80%E5%8F%91"。
• encodeURI() 是“结构保留型”：它不转义 / : @ & = + $ # 等 URI 结构字符，适合编码一个完整的 URL。
• 至于已废弃的 escape() 和 unescape()——请不要再使用，它们不遵循 URI 标准，处理 Unicode 时容易出现各种问题。