🪄

乱码转换器在线修复 Pro

「锟斤拷」「�」「涓枃」「😀」——乱码不是玄学,是字节被用错了编码表读出来。本工具在你浏览器本地用 14 种编码 + 28 条双重错码修复链逐一试解,按可读性自动打分排序,最可能的原文自动高亮;AI 负责讲清楚「它为什么会乱」。

🔍 14 种编码智能检测 🔁 双重乱码修复链 🏆 可读性自动评分 📄 文件拖入 · BOM 识别 🧬 十六进制字节检查 🔒 全程本地不上传

📥乱码来源

0 字符
📄
点此选择 或把文件拖到这里
文件只在本机读取,不会上传

🧬字节检查前 96 字节十六进制


                        

看字节特征可快速判断编码:EF BB BF=UTF-8 BOM;FF FE=UTF-16LE;FE FF=UTF-16BE;连续的 E4~E9 三字节组通常是 UTF-8 中文。

🏆候选还原结果按可读性评分降序,点一行采用

✅还原结果

0
还原后字符
0
源字节数
0
替换字符 �
–
可读性评分
🤖 AI 编码诊断师
AI 不改动任何字符,只根据你采用的还原路径解释乱码成因,并给出以后如何避免的建议。
🪬

粘贴乱码或拖入文件,点「开始智能检测」

💡
「锟斤拷」为什么修不回原文?当原始字节里有 UTF-8 字节被按 GBK 解读、又替换成 � 再存成 UTF-8(典型的 EF BF BD 连发)时,信息已经被永久销毁,任何工具都无法还原,只能找原始文件重新导出。本工具会明确标出这种情况,绝不用 AI「编造」一个看似通顺的结果骗你。

乱码是怎么产生的

计算机里没有「文字」,只有字节。同一个汉字,UTF-8 用 3 个字节、GBK 用 2 个字节、Big5 又是另一套 2 字节。当软件用编码 A 写入的字节被用编码 B 解读,就出现乱码:

  • 单层错读:文件本身字节完好,只是打开方式选错——直接换正确编码即可 100% 还原;
  • 双重错码:字节先被错读成了另一串字符并保存(如 UTF-8 字节被当 Latin-1 读成 你好),需要按「错读路径」反向拼回字节,再用正确编码读;
  • 信息损毁:一旦出现 �(U+FFFD 替换字符)并存盘,原始字节往往已丢失,数学上不可恢复。

Pro 版怎么做(保证结果可核对)

  • 确定性解码:全部还原结果由浏览器原生 TextDecoder 按 WHATWG 编码标准解码产生,AI 不生成、不修改任何一个字符,只解释成因;
  • 14 种编码:UTF-8、GB18030(兼容 GBK/GB2312)、Big5、UTF-16LE/BE、Shift-JIS、EUC-JP、EUC-KR、ISO-8859-1、Windows-1252/1251、KOI8-R、ISO-8859-2;
  • 双重修复链:粘贴的文字会分别按 UTF-8、Latin-1 重新拼回字节(覆盖「UTF-8↔Latin-1」「GBK→UTF-8」等最常见事故),再 × 14 种解码尝试,共约 42 条候选链;
  • 可读性评分:按中日韩常用汉字 / 正常 ASCII 比例加分,替换字符、控制字符、CJK 兼容区垃圾字(锟斤拷常驻地)重罚,自动把最像原文的结果排到第一并高亮;
  • 全程本地:文字与文件不离开你的电脑;点 AI 诊断时仅发送当前采用的短片段用于解释成因。

使用方法

  1. 选「粘贴文字」直接贴乱码,或选「上传文件」拖入原始文本文件(文件检测最准,因为能拿到原始字节);
  2. 点「🔍 开始智能检测」,候选结果按评分从高到低排列,第一行已自动采用;
  3. 如果第一行不像,逐行点击其它候选——简繁日韩都可能命中,相信你的眼睛;
  4. 满意后复制,或下载为 UTF-8 / 带 BOM 的 UTF-8(老版记事本可正确识别 BOM);
  5. 点「🩺 诊断这次乱码」让 AI 解释这条还原链对应的事故原因与防范方法。

更新记录

  • Pro 1.02026-10-13全新界面上线:14 编码 × 双重错码修复链候选检测;可读性评分自动排序高亮;文件拖入、BOM 检测、十六进制字节检查;复制与带 BOM 下载;接入 AI 编码诊断师(只解释、不改正文,数据正确性由确定性解码保证)。

常见问题

为什么候选里有好几条都「像中文」?
GB18030、GBK 对简中环境的字节序列高度重合(GB18030 是 GBK 的超集),所以同一字节用两者解码经常完全一样——选哪条结果都相同。Big5 命中则通常是港台繁体内容;出现日韩汉字假名时说明文件可能来自日文系统。评分只负责排序,最终请以语义通顺为准。
所有候选都带 � / 锟斤拷,怎么办?
说明字节在你拿到文件之前就已被不可逆替换(最常见是 UTF-8 中文被按 GBK 读再存盘)。世界上没有工具能恢复已删除的信息,请回到产生文件的系统重新导出,并在导出/连接串/编辑器里统一指定 UTF-8;数据库场景检查连接编码(如 MySQL 的 SET NAMES utf8mb4)。
AI 会不会「猜」出我的原文?
不会,也不允许。还原文本全部来自原生 TextDecoder 的确定性字节解码;AI 仅接收你采用结果的短片段与还原路径,输出成因解释和避坑建议。它看不到你的完整文件,也无法把结果写回页面文本框。
以后怎么避免乱码?
一条原则:全链路统一 UTF-8。源代码文件、HTML 的 charset、数据库与连接、接口 Content-Type、文本编辑器保存格式全部使用 UTF-8(需要兼容老记事本就存 UTF-8 with BOM)。与老系统交换 GBK 数据时,在边界处显式转码,不要依赖系统默认代码页。

💬 留言板 0

全部留言需审核通过后展示
💬

还没有留言,来抢沙发吧!

✍️ 说点什么
0 / 500
图形验证码