爬虫数据入库前校验
爬虫工程师小王每天从几十个不同网站抓取文章，入库前发现部分网页乱码。手动打开每个网页看响应头太慢，直接用本工具批量传入URL，秒级返回每个页面的Content-Type和charset（如text/html;charset=gbk）。小王据此在代码里给每个来源补上对应的编码参数，入库乱码率从15%降到0.3%，省去逐条排查的重复劳动。
示例
正在抓取网页并检测编码…
读取响应头与首字节，请稍候
!
识别失败
DETECTED ENCODING
source
声明 (Content-Type)
→
实际检测
BOM 与首字节byte order mark · first bytes
编码说明about this charset
输入网址后点击「识别」检测网页编码
就绪 · 同源 API 抓取响应头与首字节判定 charset
第一节
关于本工具
About打开一个网页，发现乱码，是 GB2312 还是 UTF-8？手动切编码像猜谜。输入 URL，它直接返回服务端声明的 Content-Type 与 charset，不下载整个页面，仅读取 HTTP 响应头。后端请求一次，结果秒出，适合爬虫调试、抓取策略配置、或批量检查站点编码声明是否缺失——后者在旧站迁移时尤其容易翻车。
使用场景
邮件模板编码排查
市场部小陈发送EDM邮件后，部分用户反馈正文显示为乱码。技术支持怀疑是邮件模板中HTML声明的charset与实际编码不一致。小陈把模板URL输入本工具，工具返回实际编码为UTF-8，但模板meta标签写的是gb2312。小陈修正声明后重发，乱码投诉清零。
跨平台API对接调试
后端开发小张对接某第三方支付接口，对方返回的XML响应在本地解析时报编码错误。小张用本工具检测对方接口URL，发现响应Content-Type为text/xml，但未携带charset字段，实际内容为GBK编码。他据此在代码中指定编码解析，调试时间从2天缩短到2小时。
老旧网站迁移编码确认
运维老李负责把公司2008年建的论坛从Windows服务器迁移到Linux。老论坛页面全部未声明charset，迁移后浏览器显示乱码。老李用本工具扫描首页URL，工具检测到实际编码为gb2312。他在新服务器Nginx配置中统一添加charset gb2312，全站恢复显示，避免逐页修改HTML源码。
RSS订阅源编码适配
博客博主小赵用RSS阅读器订阅了十几个技术博客，其中一个博客的RSS源在阅读器中始终显示乱码。小赵用本工具检测该RSS源URL，返回Content-Type为application/rss+xml，charset为ISO-8859-1。他确认是该博客服务器默认输出编码错误，于是在阅读器里手动为该源指定UTF-8解码，恢复正常阅读。
第二节
使用指南
Getting Started使用步骤
- 1在输入框粘贴目标网页的完整 URL（含 http:// 或 https://），点击「检测」按钮
- 2结果区第一行显示服务器返回的 Content-Type 头（如 text/html; charset=utf-8）
- 3第二行单独列出 charset 字段（如 utf-8、gbk），若缺失则标注「未声明」
- 4点击「查看原始响应头」可展开完整 HTTP 头信息，用于核对服务器实际返回的编码声明
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| https://www.example.com | Content-Type: text/html; charset=utf-8 | 常规：最常见的 HTML 页面，验证基本探测能力 |
| https://httpbin.org/encoding/utf8 | Content-Type: text/plain; charset=utf-8 | 常规：明确声明 UTF-8 的纯文本，验证 charset 字段解析 |
| https://httpbin.org/response-headers?Content-Type=text/html%3B%20charset%3Dshift_jis | Content-Type: text/html; charset=shift_jis | 边界：服务端返回的 charset 为 Shift_JIS（日文编码），验证非 UTF-8 编码的识别 |
| https://httpbin.org/status/404 | Content-Type: text/html; charset=utf-8 | 边界：404 页面仍返回有效 Content-Type，验证工具对错误状态码的兼容性 |
| https://httpbin.org/redirect/3 | Content-Type: text/html; charset=utf-8（最终响应） | 边界：经过多次重定向后获取最终页面的编码，验证工具是否跟随重定向 |
| https://httpbin.org/response-headers?Content-Type= | Content-Type: 空（无 charset 声明） | 易错：服务端未返回 Content-Type 头，工具应返回空或默认值，避免误判 |
| https://httpbin.org/encoding/gb2312 | Content-Type: text/html; charset=gb2312 | 易错：GB2312 是中文常见编码但现代浏览器支持有限，验证工具对老旧编码的兼容性 |
| https://httpbin.org/deny | 状态码 403，无 Content-Type 返回 | 易错：被拒绝访问的 URL 可能无响应头，工具应明确提示无法获取 |
常见错误对照
1.直接输入文件路径而非 URL
✗ 错误
C:\Users\test.html✓ 修复
https://example.com/page.html工具只接受 HTTP/HTTPS 协议的完整 URL，本地文件路径无法被服务器请求，会直接返回 400 错误。
2.URL 未包含协议头导致解析失败
✗ 错误
example.com/page✓ 修复
https://example.com/page缺少 http:// 或 https:// 时，Go 的 http.Get 无法识别协议，会抛出 URL scheme missing 错误。
3.误以为 Content-Type 一定准确
✗ 错误
Content-Type: text/html → 认为编码就是 UTF-8✓ 修复
同时检查 Content-Type 的 charset 字段和 HTML 中 <meta charset> 声明许多服务器默认 Content-Type 不带 charset 或写错（如老系统写 ISO-8859-1 实际是 GBK），必须结合页面内声明和 BOM 头综合判断。
4.忽略 URL 中的中文字符未编码
✗ 错误
https://example.com/中文.html✓ 修复
https://example.com/%E4%B8%AD%E6%96%87.htmlURL 标准（RFC 3986）规定非 ASCII 字符必须百分号编码，否则服务器可能返回 400 或错误响应，工具无法正常获取页面。
5.输入带查询参数的 URL 时忘记编码特殊符号
✗ 错误
https://example.com/?q=hello world✓ 修复
https://example.com/?q=hello%20world空格在 URL 中必须编码为 %20，否则请求会截断在空格处，导致工具只请求到 ?q=hello 部分。
6.认为返回的 charset 一定是页面实际编码
✗ 错误
工具显示 charset=GB2312 → 直接认定页面是 GB2312✓ 修复
确认页面内容是否包含 GB2312 不支持的字符（如生僻字），若存在则实际编码可能是 GBK 或 UTF-8GB2312 只覆盖 6763 个汉字，许多现代网站实际用 GBK（扩展集），但服务器仍声明 GB2312。工具返回的是声明值，不保证内容完全兼容。
7.混淆 HTTP 响应编码与 HTML 文档编码
✗ 错误
只依赖 HTTP 头 Content-Type: text/html; charset=utf-8✓ 修复
同时检查 <meta http-equiv="Content-Type" content="text/html; charset=gbk">HTTP 头与 HTML 内部声明可能冲突（如 CDN 强制改头但页面内写的是 gbk），工具会优先采用 HTML 内部的 <meta> 声明。
8.输入 HTTPS 站点但证书无效时无处理
✗ 错误
https://self-signed.badssl.com/✓ 修复
使用 HTTP 版本或确认证书信任Go 默认拒绝无效证书连接，工具会返回 x509 错误。用户需确认站点是否可信任，或改用 HTTP 测试。
第三节
工作原理
How It Works核心公式
charset = argmax_{c ∈ C} [ P(c | B) ]
变量说明
C候选字符集集合，如 UTF-8、GBKB网页内容的前 N 字节（字节序列）P(c | B)给定字节序列 B 时字符集 c 的后验概率
示例
对某网页前 512 字节（B = 0xE4 0xB8 0xAD 0xE5 0x9B 0xBD...），工具依次计算各候选字符集的后验概率：UTF-8 得分 0.92，GBK 得分 0.05，ISO-8859-1 得分 0.03。取 argmax 得 charset = UTF-8，最终输出 Content-Type: text/html; charset=utf-8。
用户输入
网络请求
解析与输出
查表匹配
第五节
常见问题
Q & A问我输入一个网址，它说编码是 GB2312，但我用 UTF-8 打开也正常，到底哪个准？＋
答
两个都可能准，取决于你看的“正常”是什么。网页编码声明（Content-Type 或 meta charset）和实际字节流编码可能不一致。本工具优先读取服务器返回的 HTTP 头 Content-Type 中的 charset 字段，同时也会扫描 HTML 源码中的 <meta charset> 声明；如果两者都缺失，则用算法（如 chardet）根据字节特征推测。你看到的“UTF-8 打开正常”可能是因为浏览器做了自动检测，或页面内容恰好是 ASCII 子集（如纯英文/数字）。建议以工具显示的 HTTP 头声明为准，若没有声明则以算法推测结果为准。
问为什么我测一个中文网站，它显示 charset 是空？＋
答
空结果通常意味着服务器响应头里没有 charset 字段，并且 HTML 页面里也没有 <meta charset> 或 <meta http-equiv="Content-Type"> 声明。这种情况在老网站或动态生成页面中常见。本工具会额外尝试用字节流自动检测编码（如 UTF-8、GBK、Shift-JIS 等），如果检测成功会在结果里标注“推测编码”。如果推测也失败（比如页面过短或纯二进制内容），则 charset 字段为空。你可以检查一下该网址是否返回了完整的 HTML 文档，而非重定向或错误页。
问这个工具能识别 PDF 或图片里的文字编码吗？＋
答
不能。本工具只分析 HTTP 响应头的 Content-Type 和 HTML 源码的编码声明，不解析文件内容。对于 PDF 或图片这类二进制文件，服务器返回的 Content-Type 通常是 application/pdf 或 image/jpeg，不会携带 charset 字段。工具会显示 charset 为“无”或“推测为空”。如果你想识别 PDF/图片中的文字编码，需要先用 OCR 工具提取文本，再对提取出的文本做编码检测。
问我测了同一个网址两次，为什么显示的编码不一样？＋
答
可能是以下三种情况：1）服务器根据请求头 Accept-Language 或 User-Agent 返回了不同版本的页面（多语言站点常见），编码也随之变化。2）页面内容动态更新，比如 CMS 在不同时间生成的新页面使用了不同的 meta 声明。3）本工具在首次请求时跟随了重定向，而第二次请求可能因为缓存或网络差异走到了不同的最终 URL。建议在两次测试间清空浏览器缓存，并确认请求头一致（本工具默认不带自定义头）。如果仍不一致，可以联系网站管理员确认其编码策略。
问它说编码是 UTF-8，但我用记事本打开保存的网页全是乱码，怎么回事？＋
答
乱码通常是因为保存环节出了问题。本工具只探测网页的原始编码，不负责保存。如果你用浏览器“另存为”时选择了错误的编码（比如浏览器自动选了 GBK 但实际是 UTF-8），或者用了某些下载工具对内容做了转码，都会导致本地文件乱码。正确做法：在本工具结果页复制 URL，然后在浏览器地址栏直接打开，确认页面显示正常后，再用浏览器菜单“另存为”（通常默认编码正确）。如果还乱码，检查本地系统区域设置是否强制覆盖了文件编码。
问这个工具和浏览器自带的查看编码功能有什么区别？＋
答
浏览器查看编码（如 Chrome 的“更多工具→编码”）依赖浏览器内置的检测逻辑，且通常只显示浏览器当前使用的解码编码，不显示服务器原始声明。而本工具直接展示 HTTP 响应头的 Content-Type charset 和 HTML meta 声明，让你看到服务器“认为”它是什么编码。当浏览器自动检测与服务器声明不一致时，本工具能帮你定位问题源头——是服务器配置错了，还是浏览器自动检测出了偏差。另外，本工具不依赖浏览器环境，适合在命令行或自动化脚本中调用。
问我输入了一个内网 IP 地址，它一直显示“请求超时”或“无法连接”，怎么办？＋
答
本工具运行在后端服务器上，它发起的是从服务器到目标 URL 的网络请求。内网 IP（如 192.168.x.x、10.x.x.x）或 localhost 默认无法从公网服务器访问，因此会超时。如果你需要检测内网站点的编码，建议在本地搭建类似工具，或者用浏览器的开发者工具（F12→网络→点击请求→查看响应头）手动查看 charset。本工具目前只支持公网可访问的 HTTP/HTTPS 网址。
问为什么它显示 Content-Type 是 text/html，但 charset 是空的？＋
答
这是常见情况：服务器正确声明了资源类型（text/html），但没有声明字符编码。HTTP 协议允许 charset 字段缺失，此时浏览器或客户端需要靠其他方式（如 HTML meta 声明或字节检测）来确定编码。本工具会如实显示 charset 为空，同时尝试从 HTML 中提取 meta 声明。如果 meta 里也没有，则显示“未声明”。这种情况下，页面可能默认使用 ISO-8859-1 或 UTF-8（取决于服务器配置），但无法从协议层面确定。建议联系网站管理员在 HTTP 头或 HTML 中显式添加 charset。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。