GBK 与 UTF-8 字节
用 TextDecoder 解 GBK/Big5 乱码，文本可导成字节串。
乱码的成因几乎总是同一件事：字节是一套编码，读取时用了另一套。这个工具先把输入按十六进制、Base64 或百分号形式还原成字节，再用浏览器的 TextDecoder 按你选的字符集解成文本。解码走严格模式：字节序列不合法就换非致命解码重试，并把结果里的替换字符 U+FFFD 数出来，据此判断是字符集选错了还是数据本身被截断。如果十六进制读不通、而整段字符的码位都落在 0–255 内且解出来确实超出了 Latin-1，会自动改走「逐字符取码位重组字节」的乱码还原路径，并在提示里说明走了哪条路。
反方向的「文本 → 字节」只能产出 UTF-8 字节：解码支持的字符集再多，TextEncoder 却只提供 UTF-8，要得到真正的 GBK 字节需要整套 GBK 码表，浏览器没有内置。需要时提示里给出了记事本另存为、PowerShell、Python 和 iconv 四种替代做法。全部计算在本机完成，文本不会发送到服务器。
GBK 与 UTF-8 字节怎么用
- 还原乱码：选「字节 → 文本」，把 C4E3BAC3 这类十六进制（可带空格换行）、Base64 或 %C4%E3 形式粘进来，再切换字符集，解出中文的那个就是正确编码。
- 粘贴屏幕上看到的乱码：「ä½ å¥½」这种带奇怪变音符号的文本，直接选 UTF-8 或 GBK 粘贴进去即可：十六进制读不通时工具会自动按 Latin-1 形态还原字节再解。
- 导出字节串：选「文本 → 字节」，用十六进制/Base64/百分号三种形式之一输出 UTF-8 字节，用于写测试数据、比对文件或调试协议。
- 解码支持的字符集：字节 → 文本这一向由浏览器的 TextDecoder 解成文本，支持的字符集是 GBK、GB18030、Big5、Shift_JIS、EUC-KR 与 UTF-8。
- 两种典型乱码：GBK 的「你好」是 C4 E3 BA C3 四个字节，用 UTF-8 去读就成了别的字符；反过来 UTF-8 的六个字节 E4 BD A0 E5 A5 BD 被按 Latin-1 读过，屏幕上会留下「ä½ å¥½」这种带变音符号的痕迹（中间那个看不见的空格其实是 U+00A0）。
常见问题
为什么 GBK 乱码在浏览器里能解，却不能编？
Web 规范只要求 TextDecoder 实现一组遗留字符集（GBK、GB18030、Big5、Shift_JIS、EUC-KR 等），解码是把「字节 → 字符」的映射表拿来查；而 TextEncoder 按规范只支持 UTF-8。要输出 GBK 字节需要完整的「字符 → 字节」反向码表（上万条，GBK 还含大量死位和变体），浏览器不携带这张表，所以这个工具不会假装能编码：它只会给出 UTF-8 字节并说明原因。真需要 GBK 字节请用本机的记事本另存为 ANSI、PowerShell 的 GetEncoding(936)、Python 的 encode("gbk") 或 iconv。
解出来一堆 U+FFFD 替换字符，是数据坏了还是选错编码？
先看提示里的替换字符数量。严格解码失败说明字节序列在该字符集下不成立：数量很多通常是字符集选错，换个字符集再试；只有零星一两个且都在末尾，更可能是文件被截断或只丢了一半的多字节序列。UTF-8 解出 而切到 GBK 一切正常，就是最常见的「UTF-8 内容当 GBK 存过」场景。
输入开头就带 BOM 会怎样？
字节层面是 EF BB BF。解码时 TextDecoder 默认会把 UTF-8 的 BOM 吃掉，所以结果文本里没有 U+FEFF，提示条会明确说明这一点；如果你要的是「带 BOM 的字节串」，请用「文本 → 字节」方向配合「BOM 与不可见字符」工具先加上 U+FEFF，再导成字节验证 EF BB BF。
对应功能编号 #18无需安装，手机端同样可用按 Ctrl + K 换工具