摘要：免费的乱码诊断器：粘贴乱码自动识别错码模式（UTF-8 被 GBK 解释/双重编码/Latin-1 误读/百分号或 \u 转义残留），给出成因解读与修复路径——诊断而不是盲目转换，本地运行。
此工具完全在您的浏览器中运行。打开 DevTools → Network 面板，搜索您的输入内容——它不会出现在任何请求中。
使用指南
打开数据库导出的 CSV 一片「ä½ å¥½」、日志文件里全是「©」、接口返回值带满 %E4%B8%AD——乱码的本质是「字节流被用错误的编码解释了」，而市面上的工具几乎全是「转换器」：你猜对源编码它才能救。本工具做的是诊断：粘贴乱码，它识别字节特征模式，告诉你「发生了什么」和「怎么修」。
1. 六种可识别的错码模式
UTF-8 被 GBK 解释（ä½ å¥½ 形态：连续的 Latin 扩展字符对）；UTF-8 被 Latin-1 误读（ + 符号，如 ©）；双重编码 UTF-8（é 形态：修过一次但方向反了）；替换符连续（����，信息已丢失不可逆，这是唯一救不回来的模式）；百分号编码残留（%E4%B8%AD，解一次 URL decode 即好）；\u 转义或 HTML 实体残留（中 / 中，属于序列化没解开）。每种模式的修复路径不同——先诊断再动手，比挨个编码试快得多。
2. 为什么会乱码（一页原理）
文本在存储和传输时都是字节。「你好」按 UTF-8 编码是 6 个字节，按 GBK 读就是把每 2 个字节当一个汉字——于是变成 3 个奇怪的字。反过来 GBK 的字节按 UTF-8 读，UTF-8 的多字节结构对不上就落成替换符。核心规律：**UTF-8 被错读成单字节系编码（GBK/Latin-1）信息还在可救；单字节系被错读成 UTF-8 出现替换符（U+FFFD）即信息已丢，谁也救不回**。这也是本工具区分「可修复」与「不可逆」的依据。
相关工具
相关文章
Hydration failed / Text content does not match 报错怎么解决？
Next.js/React SSR 最常见的水合报错完整指南：为什么服务端和客户端渲染不一致、时间戳/随机值/localStorage 三大来源、suppressHydrationWarning 的正确用法，配本站工具定位差异。
Base64 解码后中文变成乱码 / 问号（�）怎么办？
Base64 解码后中文变成乱码或黑色问号方块怎么办？讲清"编码的是字节不是字符"这一根因，并给出命令行、代码和在线工具三种正确解法，全程本地处理。
文本提取工具：从杂乱文本中快速提取有用信息
教你如何从大段文本中快速提取邮箱、手机号、URL、IP 地址等关键信息，提升数据处理效率