字符编码检测器
检测粘贴的文本或上传文件的字符编码 — BOM 嗅探（UTF-8/UTF-16/UTF-32）、真正的 UTF-8 连续字节验证器、ASCII 检测，以及当没有 BOM 且字节不是有效 UTF-8 时，Windows-1252 和 ISO-8859-1（Latin-1）等单字节遗留字符集的字节频率启发式。
输入
或上传文件
Drop a file or browse
One file · any type
任何文件类型。在浏览器中本地读取。仅当文本框为空时使用。
输出
结果
| Property | Value |
|---|---|
| No data yet | |
考虑的所有候选项
结果
| Encoding | Confidence | Signals |
|---|---|---|
| No data yet | ||
这对您有帮助吗？
使用此工具的更多方式
REST API
curl -X POST https://api.iotools.cloud/v1/tool/character-encoding-detector \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"inputText": "Hello, World!",
"file": ""
}'替换成您账户中的密钥。工具的字段即为请求体——没有额外包装。
让 AI 代理执行
Use the IOTools `character-encoding-detector` tool (Character Encoding Detector) on this input:
YOUR_INPUT_HERE将此粘贴给任何已连接 IOTools MCP 服务器的代理,再加上您的输入内容。
嵌入式小组件
<iframe
src="https://iotools.cloud/embed/character-encoding-detector/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="字符编码检测器 — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>把它放到您自己的页面上——免费,无需密钥,只需保留一个反向链接。
| 每次 API/MCP 调用费用 | 5 积分起 |
|---|
也可通过
使用指南
乱码文本 — 应该是带重音字母的地方出现问号，或者 é 被替换为 é 之类的字符串 — 几乎总是意味着文件用一种字符编码写入，又用另一种编码读回。字符编码检测器检查粘贴的文本或上传文件的原始字节，并报告其最可能的编码，以及该猜测背后的字节级证据。
使用方法
将文本粘贴到 输入文本 中，或将文件拖放到上传器中以检查其原始字节。结果会自动更新，并显示 检测到的编码、置信度 百分比、找到的任何 BOM、字节计数和 推理 行（用简洁的语言）。下面的 考虑的所有候选项 表格列出了检测器考虑的每种编码，各自带有自己的置信度和推理，以便您可以看到次要选择及其得分较低的原因。
检测的工作方式
检测通过一系列固定的检查，从最确定到最不确定：
- 字节顺序标记（BOM）。 某些编码会向文件添加固定字节序列 — UTF-8 为
EF BB BF，UTF-16 为FF FE/FE FF，UTF-32 为 4 字节变体。找到一个几乎是确定的：99% 的置信度。 - 纯 ASCII。 如果每个字节都在
0x00–0x7F范围内，则它是有效的 ASCII — 并且由于 ASCII 是 UTF-8 的严格子集，同时也是有效的 UTF-8。以 100% 的置信度报告。 - 有效的 UTF-8。 没有 BOM 时，真正的 UTF-8 验证器会遍历字节流：检查连续字节是否设置了正确的高位，拒绝"超长"编码（比代码点需要的字节数更多），并拒绝范围外的代码点或孤立的 UTF-16 代理一半。这是真正的语法检查，而不仅仅是"解码是否抛出错误" — 因此它捕捉一个宽松的解码器会无声接受的畸形序列。顺利通过的文本以 97% 的置信度报告为 UTF-8。
- 单字节遗留字符集猜测。 如果字节未通过 UTF-8 验证，检测器会回到 Windows-1252 和 ISO-8859-1（Latin-1）之间的字节频率启发式，这是两个最常见的单字节西方编码。
0x80–0x9F范围内的字节在 Latin-1 中是未定义的控制码，但在 Windows-1252 中是可打印的标点符号（弯引号、破折号），所以它们的存在指向 Windows-1252。这个分支被限制在 70% 的置信度之下，因为它是一个统计猜测，而不是确定性 — 相同的字节在多个字符集中经常是有效的。
我的数据会上传到任何地方吗？
不会。检测完全在您的浏览器中运行（或通过 API 在请求处理程序中运行） — 没有任何东西被发送到第三方服务。
为什么我的文件未被检测为 Shift_JIS、Big5 或其他 CJK 编码？
这些遗留的多字节亚洲编码不在范围内 — 仅从字节范围猜测它们会产生很多误报，不像 BOM 检查或 UTF-8 语法检查。如果您知道文件是 Shift_JIS 或 GBK，请使用该标签直接解码，而不是依赖检测。
encodingcharacter-encodingutf-8bomcharsetlatin-1windows-1252detector