字符集转换与乱码诊断

编码转换

正在载入

正在加载工具

正在准备工具，暂时无法估算剩余时间。

本工具的全部运算都发生在你的浏览器中，输入内容不会发送到任何服务器。

关于这个工具

保留原有 UTF-8、UTF-16LE、UTF-16BE 文本、十六进制及 Base64 转换功能。独立的乱码诊断面板检查粘贴的 Unicode 文本或本地文件原始字节，完整保留来源并列出有界、可解释的候选。它不能可靠检测编码，也不能证明作者原本想表达什么。

常见用途

将已知文本编码为 UTF-8 或指定字节序的 UTF-16，或用原转换器解码已知格式的十六进制与 Base64。
调查一次错误解码，例如 UTF-8 字节曾被当作 Windows-1252 读取，同时保留粘贴的原文。
在复制、替换字符或编辑器保存丢失字节之前，对原始本地文件比较明确的解码路线。
审阅转义控制字符、BOM 证据及路线假设，再主动选择一个候选，以 UTF-8 复制或下载。

使用方法

1.普通转换：选择编码或解码、UTF-8/UTF-16LE/UTF-16BE 以及 Hex/Base64，输入内容并运行原转换器。
2.乱码诊断：选择粘贴文本或原始本地文件并运行诊断。文本恢复反向验证一次假设的错误解码；文件诊断则按明确路线解码实际字节。审阅未改动的来源与各项证据。
3.候选按固定路线顺序显示，不给置信百分比，也不按语言排序。选择候选并确认已审阅后，才可复制或下载完整 UTF-8 文本。编辑、取消或更换来源会使旧结果失效。

可执行的编码与恢复示例

保留的 UTF-8 / Hex 转换

request (ASCII JSON): {"mode":"converter","operation":"encode","encoding":"utf-8","format":"hex","input":"\u4f60\u597d"}

{"output":"E4BDA0E5A5BD"}

原转换器仍输出这两个字符的六个 UTF-8 字节。

保留的 UTF-16BE / Base64 转换

request (ASCII JSON): {"mode":"converter","operation":"encode","encoding":"utf-16be","format":"base64","input":"A\ud83d\ude00"}

{"output":"AEHYPd4A"}

字节 00 41 D8 3D DE 00 包含完整代理对；字节序明确选择为大端。

保留的 UTF-16LE / Hex 解码

request (ASCII JSON): {"mode":"converter","operation":"decode","encoding":"utf-16le","format":"hex","input":"41003DD800DE"}

{"output":"A\ud83d\ude00"}

原有解码模式按明确选择的小端字节还原同一文本。

两条路线得到同一候选文本

request (ASCII JSON): {"mode":"text","text":"caf\u00c3\u00a9"}

{"candidates":[{"id":"windows-1252-to-utf-8","text":"caf\u00e9","byteRoundTrip":true,"stringRoundTrip":true},{"id":"iso-8859-1-to-utf-8","text":"caf\u00e9","byteRoundTrip":true,"stringRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

两种单字节假设都重建 63 61 66 C3 A9；输出相同不能证明过去使用了哪种解码。原生 Windows-1252 解码器不可用或不一致时会明确标为不支持；字面路线保持独立。

C1 控制字符需要字面路线

request (ASCII JSON): {"mode":"text","text":"\u00e2\u0080\u0099"}

{"candidates":[{"id":"iso-8859-1-to-utf-8","text":"\u2019","byteRoundTrip":true,"stringRoundTrip":true}],"missing":["windows-1252-to-utf-8"]}

字面码点 E2 80 99 重建 UTF-8 弯引号字节。Windows-1252 的 80 映射到 U+20AC，不能将 U+0080 逆映射为该字节。

中文的一步恢复假设

request (ASCII JSON): {"mode":"text","text":"\u00e4\u00bd\u00a0\u00e5\u00a5\u00bd"}

{"candidates":[{"id":"windows-1252-to-utf-8","text":"\u4f60\u597d","byteRoundTrip":true,"stringRoundTrip":true},{"id":"iso-8859-1-to-utf-8","text":"\u4f60\u597d","byteRoundTrip":true,"stringRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

精确字节变换得到这些字符，不参考语言频率。来源中的 U+00A0 以转义形式显示。原生 Windows-1252 解码器不可用或不一致时会明确标为不支持；字面路线保持独立。

问号不提供可恢复历史

request (ASCII JSON): {"mode":"text","text":"Order?"}

{"candidates":[{"id":"original-text","text":"Order?","unchanged":true}],"warnings":["question-mark-may-be-original"]}

来源保持不变。问号可能有意输入，也可能来自先前替换；工具无法区分这两种历史。

已有 U+FFFD 保留为转义预览

request (ASCII JSON): {"mode":"text","text":"bad\ufffd"}

{"candidates":[{"id":"original-text","text":"bad\ufffd","unchanged":true}],"missing":["windows-1252-to-utf-8","iso-8859-1-to-utf-8"],"warnings":["replacement-may-be-original"]}

不会编造缺失字母。两种单字节逆向路线都无法编码 U+FFFD，因此保留原文。

拒绝不成对代理项

request (ASCII JSON): {"mode":"text","text":"\ud800"}

{"error":"unpaired-surrogate"}

ASCII JSON 能安全描述该无效 UTF-16 值。诊断会先拒绝它，避免 UTF-8 导出时静默替换。

预览转义双向字符、换行与 NUL

request (ASCII JSON): {"mode":"text","text":"A\u202eB\n\u0000"}

{"candidates":[{"id":"original-text","text":"A\u202eB\n\u0000","unchanged":true}],"preview":"A\\u202EB\\n\\u0000"}

预览仅含可打印 ASCII，不会重排周围标签。手动选择的 UTF-8 导出仍含原始字符，不是安全净化。

保留 UTF-8 BOM 码点

request (ASCII JSON): {"mode":"bytes","hex":"EF BB BF 41"}

{"candidates":[{"id":"decode-utf-8","text":"\ufeffA","byteRoundTrip":true}],"bom":"utf-8"}

诊断解码保留开头 U+FEFF；UTF-8 导出得到 EF BB BF 41，不添加或删除字符。

包含代理对的明确 UTF-16LE

request (ASCII JSON): {"mode":"bytes","hex":"FF FE 41 00 3D D8 00 DE"}

{"candidates":[{"id":"decode-utf-16le","text":"\ufeffA\ud83d\ude00","byteRoundTrip":true}],"bom":"utf-16le"}

小端路线还原 Unicode 文本并保留 U+FEFF。诊断下载是 UTF-8，不是原始 UTF-16 字节。

相同文本的明确 UTF-16BE

request (ASCII JSON): {"mode":"bytes","hex":"FE FF 00 41 D8 3D DE 00"}

{"candidates":[{"id":"decode-utf-16be","text":"\ufeffA\ud83d\ude00","byteRoundTrip":true}],"bom":"utf-16be"}

大端与小端是独立路线；解码成功仅说明该路线成立，不证明文件历史。

无效 UTF-8 路线失败

request (ASCII JSON): {"mode":"bytes","hex":"C3 28"}

{"missing":["decode-utf-8"],"invalidAttempts":["decode-utf-8"]}

C3 后的 28 不是续字节。不会生成带替换字符的 UTF-8 候选；其他编码仍只是独立假设。

拒绝奇数字节 UTF-16

request (ASCII JSON): {"mode":"bytes","hex":"41"}

{"missing":["decode-utf-16le","decode-utf-16be"],"invalidAttempts":["decode-utf-16le","decode-utf-16be"]}

一个字节不足以组成 UTF-16 代码单元，两种字节序都失败；它仍可能是合法单字节或 UTF-8 文本。

字节 80：网页别名与字面映射

request (ASCII JSON): {"mode":"bytes","hex":"80"}

{"candidates":[{"id":"decode-windows-1252","text":"\u20ac","byteRoundTrip":true},{"id":"decode-iso-8859-1-literal","text":"\u0080","byteRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

Windows-1252 得到 U+20AC，字面 ISO-8859-1 得到 C1 控制字符 U+0080。WHATWG 的 ISO-8859-1 别名属于 Windows-1252 解释。原生 Windows-1252 解码器不可用或不一致时会明确标为不支持；字面路线保持独立。

明确的 WHATWG Shift_JIS 解码

request (ASCII JSON): {"mode":"bytes","hex":"82 A0"}

{"candidates":[{"id":"decode-shift_jis","text":"\u3042","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

原生 Shift_JIS 路线解码这些字节。未提供传统编码器，因此字节往返证据为 null，而不是真。如果原生解码器不可用或未通过一致性检查，该路线会明确标为不支持。

明确的 GB18030 解码

request (ASCII JSON): {"mode":"bytes","hex":"D6 D0 CE C4"}

{"candidates":[{"id":"decode-gb18030","text":"\u4e2d\u6587","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

该常见映射由宿主运行时解码。未固定 GB18030 修订版，不声称字节往返证明，也不进行语言排序。如果原生解码器不可用或未通过一致性检查，该路线会明确标为不支持。

明确的 WHATWG Big5 解码

request (ASCII JSON): {"mode":"bytes","hex":"A4 A4 A4 E5"}

{"candidates":[{"id":"decode-big5","text":"\u4e2d\u6587","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

在支持时使用浏览器 Big5 映射，不保证与所有历史 Big5 实现相同；往返证据仍为未测试。如果原生解码器不可用或未通过一致性检查，该路线会明确标为不支持。

UTF-32 签名是证据，不代表支持

request (ASCII JSON): {"mode":"bytes","hex":"FF FE 00 00 41 00 00 00"}

{"bom":"utf-32le","warnings":["utf32-not-supported"]}

此前缀被记录为 UTF-32LE 证据，但不提供 UTF-32 解码器。不要把其他合法解释误认为自动 UTF-32 恢复。

安全理解诊断结果

不要把第一个候选当作正确答案。固定路线顺序不是置信度排名。
不要把十六进制粘贴到文本恢复输入框并期待按字节处理。请使用原有 Hex/Base64 转换器，或在诊断文件模式提供原始文件。
不要混淆浏览器 ISO-8859-1 别名与明确标明的字面 ISO-8859-1 路线，两者对 C1 范围字节的解释不同。
UTF-8 或 UTF-16 路线失败只说明该假设不成立；另一传统编码路线成功也不能证明真实编码。
文件开头的 EF BB BF、FF FE、FE FF 可提供 BOM 证据，但明确字节序路线仍互相独立，诊断文本会保留 U+FEFF。
不成对代理项无法无损导出为 UTF-8，应取得格式正确的源数据，不接受静默替换。
下面的转义示例采用 ASCII JSON，显示的 \uXXXX 与 \n 描述字符，不是在页面中嵌入会生效的控制字符。

限制与说明

诊断只提供假设，不是可靠编码检测。严格解码成功或精确往返仅说明该路线自洽；多条路线都可能产生合法文本，不能据此证明原始编码或含义。文本逆向恢复要求粘贴的每个字符都能映射回假设的传统编码字节，再进行严格 UTF-8 解码。仅尝试支持的一步路线，不递归修复、不纠正拼写、不翻译，也不自动覆盖。
WHATWG TextDecoder 中的 ISO-8859-1、latin1 和 ascii 标签实际指向 Windows-1252。单独标明的字面 ISO-8859-1 路线则把 00–FF 字节直接映射到 U+0000–U+00FF，包含 C1 控制字符，与浏览器别名明确区分。文件路线包括 UTF-8、UTF-16LE、UTF-16BE、Windows-1252、字面 ISO-8859-1、Shift_JIS、GB18030、Big5。后三者使用可用的原生 WHATWG 解码器，没有传统编码器，字节往返证据标为未测试。Shift_JIS 采用网页兼容映射；GB18030 版本取决于运行时，Big5 可能不同于历史实现。不解码 UTF-32，识别到的前缀仅作警告。原生路线还需通过代表性一致性检查；未通过时标为不支持，不输出误导性候选。
诊断的 Unicode 路线拒绝无效 UTF-8、奇数字节 UTF-16 与不成对代理项。UTF-16LE、UTF-16BE 是明确假设，不是自动字节序检测。解码后的开头 U+FEFF 会保留；EF BB BF、FF FE、FE FF 仅作证据，不代表可以删掉数据。 U+FFFD 或问号可能已替代丢失的信息，但它们也可能是作者有意输入的字符，单凭出现无法证明损坏或找回原字节。工具不会编造丢失历史；尽量取得原文件或备份。
诊断最多接受 64 KiB（65,536）原始文件字节；粘贴文本必须同时不超过 65,536 个 UTF-16 代码单元和 64 KiB 的 UTF-8。最多 12 个候选，每个最多 65,536 代码单元与 262,144 UTF-8 字节。可取消工作线程 5 秒超时，本地文件读取 15 秒超时。超限输入被拒绝，不静默截断。
诊断预览对非 ASCII、控制及双向文本字符转义；预览可能缩短，但显式选择的导出包含完整候选，包括控制字符与 U+FEFF。这不是安全净化，不会自动应用候选，也不会覆盖原始文件。处理在本地完成，不上传输入、不持久存储。诊断仅复制或下载 UTF-8，不写出传统编码。独立的原转换器仍保留 4 MiB 编码后文本、8 MiB 解码字节、16 MiB 编码字符上限及原有二进制下载。

常见问题

粘贴文本恢复与解码文件有什么区别？

粘贴文本已在某处被解码过。逆向路线假设之前发生了特定错误，从字符重建字节，再严格按 UTF-8 解码。原始文件仍提供实际字节，可以直接按路线解码而无需猜测这一步历史。尽量保留原始字节副本。

候选或往返成功能证明原始编码吗？

不能。ASCII 在多种编码中通用，其他字节也可能被多条路线合法解码。往返只检查声明的变换是否自洽。候选顺序固定，没有概率评分、语言猜测或自动最佳项。

Windows-1252 与字面 ISO-8859-1 为什么不同？

兼容网页的 ISO-8859-1 标签是 Windows-1252 别名，其中字节 80 对应 U+20AC。单独命名的字面路线把 80 对应到 U+0080。逆向恢复使用错误映射可能失败或得到不同候选，应检查转义码点及来源。

能找回丢失字符吗，下载又会保留什么？

仅凭这些字符无法恢复。多个原始输入可以变成同一个替换字符，因此这里无法知道丢失的历史。已有 U+FFFD 与问号提示你检查原文件，并不意味着工具能重建缺失内容。诊断解码会保留开头的 U+FEFF，不会悄悄删除。转义预览避免双向文本和控制字符改变周围显示。手动选择并审阅后，复制或下载得到包含这些保留字符的 UTF-8 候选本身；用于其他应用之前应再次检查。