HEX ↔ 文本 把十六进制字节序列与人类可读字符串在浏览器本地双向互转，零依赖、纯静态——所有编解码都走浏览器原生 TextDecoder / TextEncoder。任何一边输入都会实时触发同向转换，无需点按钮。
如果你需要整个文件的 hex 视图（含魔数识别、PNG/ZIP 等结构解析），那是 Hex 二进制查看 的活儿；如果只是处理一小段字节流的字符内容，用本工具更直接。
| 编码 | 何时用 |
|---|---|
| UTF-8 | 默认。现代系统、HTTP/JSON/HTML、网络协议绝大部分都是它 |
| Latin-1 | 字节直显。看二进制 dump 里嵌的 ASCII 字符串、调试未知协议 |
| ASCII | 严格 7-bit 校验。验证一段字节是不是”纯英文” |
| UTF-16LE / BE | Windows 文件、Java/.NET 字符串导出，多带 BOM |
| GBK | 老 Windows 中文系统、SQL Server 默认配置导出的中文 |
| GB18030 | GBK 的国标超集，能编码所有 Unicode（含 emoji） |
看不出来用哪个就挨个切——切错不会损坏数据，状态栏会标注”该编码下大概率有问题”。
切到某个编码后，工具会扫描解码结果里三类可疑信号并在状态栏给一行总结：
� —— 编码不匹配的明确证据（最强信号）\t\n\r 外的 < 0x20 字符数量超过文本 1/4Latin-1 不做这个诊断（它本质就是字节直显，永远不会”乱码”）。
HEX 输入 → parseHexInput → Uint8Array → TextDecoder.decode(encoding) → 文本
文本输入 → TextEncoder / 手写编码器 → Uint8Array → formatBytes(case/sep) → HEXGBK/GB18030 编码方向通过反扫 TextDecoder("gbk") 在 0x00-0xFE 字节范围内生成 Unicode → 字节反查表（首次调用 ~10ms，缓存复用），GB18030 补充平面 4 字节序列用算法生成。
输入侧的最后一次编辑（hex 还是 text）决定切换编码时往哪个方向重算，确保你正在编辑的内容不会被覆盖。
hex 只是字节的十六进制写法，字节到字符的映射由编码决定。同一段字节 c4 e3 在 GBK 下是"你"，在 UTF-8 下是无效序列（替换为 �），在 UTF-16LE 下是另一个字符。所以解码时必须明确编码，否则就是乱码。
Latin-1（ISO-8859-1）把每个字节 1:1 映射到 U+0000–U+00FF——0xAA → U+00AA "ª"，0xFF → U+00FF "ÿ"。任何字节序列都不会乱码，因为它本质就是"字节直显"。ASCII 严格只认 0x00–0x7F，高位字节（≥ 0x80）一律变 �。用 Latin-1 的场景：处理 EVM calldata、二进制 dump、未知协议字节流——你只想看里面藏没藏 ASCII 字符串（比如 "TSL"、"PNG"），不关心非 ASCII 部分的"语义"。CyberChef 的 "To Latin1"、Wireshark 的 raw bytes 视图都是这个语义。
经验：BOM 命中（EF BB BF / FF FE / FE FF）直接对应 UTF-8 / UTF-16LE / UTF-16BE；中文系统老数据先试 GBK，看不出再试 GB18030；不知道是什么的二进制 dump 切 Latin-1 看里面有没有藏 ASCII 标记。挨个 chip 切一下试就行——切错了不会损坏数据，状态栏会提示替换字符 / 控制字符等"该编码下大概率有问题"的迹象。
当前 7 种：UTF-8、Latin-1、ASCII、UTF-16LE、UTF-16BE、GBK、GB18030。覆盖国内开发 + 二进制 dump 直显 99% 场景。Big5 / Shift-JIS / EUC-KR 等可以加，但需要打表。底层未引入任何编码库：解码全部走浏览器原生 TextDecoder（GBK/GB18030 在 Chrome/Firefox/Safari 都内建支持），编码方向 UTF-8/ASCII/UTF-16/Latin-1 手写实现，GBK/GB18030 通过反扫 TextDecoder("gbk") 字节范围生成反查表（首次 ~10ms 缓存复用）。
宽容。支持 48 65 6c、48,65,6c、486c6c、0x48 0x65、混合大小写，空格 / 换行 / 逗号都算分隔符，每个 token 可带或不带 0x 前缀。唯一硬性约束：清洗后总字符数必须是偶数，且不能含非 hex 字符。
解码后扫描三类"可疑信号"：① 替换字符 �——编码不匹配的明确证据；② 控制字符（除 \t\n\r 外的 < 0x20 字符）数量超过文本 1/4；③ 私有区码点（U+E000–U+F8FF 等）出现在 UTF-16 解码结果中——这是把 GBK/UTF-8 误当成 UTF-16 的强信号。状态栏会一行总结，告诉你"这个编码下大概率有问题"。Latin-1 不做诊断（它永远不会"乱码"，只会原样字节直显）。
会用 ?（0x3F）替代，状态栏标黄"含无法表示的字符，已用替代符"。典型场景：用 ASCII 编码 emoji、用 Latin-1 编码中文（码点 > 0xFF）、用 GBK 编码生僻 emoji。需要无损就换 UTF-8——它能表示所有 Unicode 字符。
编码方向（文本 → HEX）不会主动加 BOM——UTF-16LE/BE 编码器不写 BOM 头。解码方向（HEX → 文本）如果检测到匹配的 BOM 会自动剥离，状态栏标注"已剥离 X BOM"，避免文本开头多一个不可见的 U+FEFF。需要保留 BOM 自己看的话，把开头的 EF BB BF / FF FE / FE FF 几个字节单独留着不送进解码就行。
不会。所有编解码都通过浏览器原生 TextDecoder / TextEncoder 在本地完成，零网络请求。localStorage 仅保存最近一次输入和编码选择作为草稿，可在浏览器设置里清除。