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 时容易出错。
