十六进制文本转换
免费在线十六进制与文本双向转换：按 UTF-8 逐字节处理，可选大小写、0x 前缀与分隔方式，解码严格校验非法字节，全部在浏览器内完成。
等待输入
使用步骤
- 把文本或十六进制粘贴进输入框
- 选择方向：文本转十六进制，或把十六进制还原成文本
- 按需选择字母大小写、要不要 0x 前缀、分隔用空格、逗号、换行还是紧凑一串
- 点击结果框右上角的复制按钮取走结果
工具说明
十六进制文本转换做两件对称的事：把文本按 UTF-8 编成字节，再把每个字节写成两位十六进制；或者反过来，把一串十六进制还原成文字。例子很直白：字母 A 是一个字节 41，汉字 明 是三个字节 E6 98 8E，所以「A明」转出来是 41 E6 98 8E。
这类转换的用场基本都是在读机器留下的痕迹：用 hexdump 看文件头（PNG 的前八个字节 89 50 4E 47 0D 0A 1A 0A 就能认出图片类型）、检查 UTF-8 开头的 BOM（EF BB BF）、照着协议文档核对某个字段的字节、或者把一小段二进制写成源码里的字节数组。还有一个你可能见过但没这么想过的情形：URL 百分号编码本质就是十六进制，中文「中」在查询串里是 %E4%B8%AD，那三位正是它的 UTF-8 字节。
三点最容易被忽略的：第一，这里转的是字节，不是码点。A 的码点 U+0041 恰好与它的 UTF-8 字节相同，所以只处理英文时两种做法看不出差别；但 中 的码点是 U+4E2D，它的 UTF-8 字节却是 E4 B8 AD，两种写法差得很远。需要 \uXXXX 那种形式请用 Unicode 转义工具，别拿这里的结果当码点用。第二，同一串十六进制在不同编码下是不同的文字：D6 D0 C4 E4 在 GBK 里是「中文」，在 UTF-8 里却是非法序列。本工具只按 UTF-8 还原，遇到非法字节会直接报错，不会替换成占位符再给你一个「成功」的结果 —— 因为那样你拿走的是错数据，而且毫不知情。
第三，读入很宽松，输出严格按你选的格式：0x 或 0X 前缀、大小写混写、空格、逗号、换行混在一起都认得；输出则可以选择小写或大写、要不要前缀、用什么分隔，方便你贴回 C 数组或者 JS 字面量。
常见问题
- 为什么我的十六进制解不出文字？
- 三种情况，页面上的提示会把它们分开说：位数是单数（多半复制时漏了一位）；里面混了非十六进制字符（本工具只认 0-9 与 a-f、A-F，可以带 0x 前缀，分隔符认空格、逗号、换行）；或者字节成对但不是合法的 UTF-8 序列（GBK 编码的字节流，或者本来就是二进制）。最后一种没法「尽力解」，因为任何将就的解法都会给你看着像成功的错数据。
- 十六进制和 Base64 都能表示二进制，该用哪个？
- 看是给机器存还是给人读。十六进制每个字节固定占两位字符，体积恒定膨胀到两倍，但它与字节一一对应，校验和、哈希值、密钥指纹、hexdump 都用它，逐段核对时谁在第几位一目了然。Base64 约 1.33 倍体积，同样能安全承载任意字节，邮件附件、内嵌图片、MIME 这类要穿过文本通道的场景用它更省。
- 这里输出的是字节还是 Unicode 码点？
- 字节。字母 A 的码点是 U+0041，它的 UTF-8 字节也是 41，两种理解结果相同；汉字 中 的码点是 U+4E2D，而 UTF-8 字节是 E4 B8 AD，本工具输出后者。需要 \u4E2D 这种码点写法的应该用 Unicode 转义工具，两者结果不能互相替代。
- 字节顺序（大端小端）在这里有影响吗？
- 没有。本工具逐个字节输出，不把连续字节解释成一个多字节整数，所以不存在字节序问题。字节序只在把 hex 当数值读的时候才需要决定，比如把 12 34 AB CD 拼成一个 uint32 得到 0x1234ABCD 还是 0xCDAB3412 —— 那是进制与字节序工具的活，这里输出的顺序就是数据在文件里的顺序。
- 怎么把一段 hex dump 还原成文件？
- 先问一句：这些字节能不能表示成文本。本工具的产出是文本，遇到非 UTF-8 的字节会直接报错而不是猜。要把任意字节落回文件，正确路径是用 Base64 承载（它能无损穿过文本通道），再用系统命令或浏览器写回文件。hex 也能做到，但体积恒定是两倍，而且每行必须保持字节对齐，多复制或少复制一位就整体错位。