通过JS处理跨语言编码字符串转换

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

在处理跨语言、跨平台的字符串转换时，许多开发者都曾因字符乱码而困扰。例如，使用 UTF-8 格式传输了一个“中文”字符串，但接收方用 GBK 解读——结果屏幕上显示的全是乱码字符。JavaScript 的字符串默认以 UTF-16 存储，但实际场景中的文件、后端 API、旧系统或浏览器 URL，却常常采用 UTF-8、GBK、Shift_JIS 或 Base64 编码。

乱码的根本原因在于字节序列与字符串编码之间的映射关系不匹配。因此，核心原则是：首先确认原始数据的编码格式，再将其转换为所需的目标编码。切勿假定所有输入都是 UTF-8，也不可直接对中文字符使用 btoa()——该函数仅支持 Latin-1 单字节范围，中文字符会直接抛出异常。

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

在现代浏览器和 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() 对中文进行编码时遭遇异常，原因在于 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 时容易出错。