先说结论
乱码分两大类。第一类是编码不匹配：内容本身是好好的中文，只是读取时用错了字符集，典型特征是「方块」「问号」或 ä¸æ–‡ 这类西文变体；这一类网页工具帮不上忙，得靠系统工具按正确编码重新读一遍（Windows 上是记事本或编辑器的「另存为」编码选择）。第二类是内容被编码过：原文其实是正常的，但被套了一层 Base64、URL 编码、Unicode 转义或十六进制，特征是 %E4%B8%AD、aHR0cHM6Ly、\u4e2d、E4B8AD 这类整齐的编码痕迹；这一类用浏览器里的编码工具一行就能还原。最快的判断方法是先看有没有百分号或反斜杠转义：有就是第二类，没有就是第一类。中间还有一类边界情况：GBK 与 UTF-8 之间的双向误解（GBK 当 UTF-8 读会得到 ä¸æ–‡，UTF-8 当 GBK 读会得到 涓枃），这是纯转码问题，浏览器页面帮不上忙，第五节说清怎么办。
认特征：看到什么就是哪一类
按现象对号入座最快。%E4%B8%AD 开头的一串是 URL 编码，中文的 UTF-8 字节被写成了 %XX 形式，常见于链接参数和表单提交，解码回中文就行。aHR0cHM6Ly9 这种字母数字加少量符号是 Base64，末尾常有 = 或 == 补位，解出来往往是网址或 JSON。\u4e2d\u6587 形式是 Unicode 转义，常见于 JSON 里为了绕过转义而写的字符串。E4B8AD E69687 这样的成对十六进制是字节的 Hex 表示。eyJ... 开头、分三段用点隔开的是 JWT。中文变成 ä¸æ–‡ 或 ×ÖÖ¿Ö 是 GBK/UTF-8 误解，属于第一类。中文变成 ??? 或空方块 多半是目标环境没有中文字体或用纯 ASCII 方式硬转，属于第一类的更严重情形。这七种里，前五种可以交给工具一次性识别并预览结果——把整段粘进去，工具会同时试几种常见编码并显示哪一路解出了可读文字，这比逐个猜快得多。
浏览器工具能解决哪一类
明确划清边界，避免白折腾。网页工具能做的是：识别一段可疑字符串属于哪种编码，并并排显示所有候选的解码结果让你挑；以及在 Base64、URL 编码、Unicode 转义、HTML 实体、十六进制之间互相转换。这类工具对排查接口返回值、URL 里被转义过的中文、日志里的 Base64 片段特别好用，因为这些场景里内容本身没坏，只是需要「脱掉那层壳」。网页工具不能做的是 GBK 与 UTF-8 之间的字符集转码——那是把字节按另一套字符集重新解释，属于完整的转码操作，页面里这几个工具没有实现，也不该假装能。所以如果你的乱码是 ä¸æ–‡ 这种形态，别在工具里反复试，直接看下一节。
编码不匹配：按正确字符集重读一遍
这一类的解法都是同一个思路：明确告诉系统「这份内容的编码是什么」，而不是让系统猜。Windows 上最直接的路径是：用记事本打开文件，如果显示乱码，依次在「文件 → 另存为」的「编码」下拉里试 ANSI、UTF-8、GB2312、GBK，看哪个下显示正常——中文 Windows 上的 ANSI 实际就是 GBK 系列。重文件多的场景建议直接用 VS Code 或 Notepad++，状态栏右下角可以一键切换当前文件的编码，切换后立刻生效，比反复另存方便得多。命令行里处理文本文件时加 -Encoding 参数指定读取编码；数据库里则是查连接字符集配置，比如 MySQL 里把连接的字符集设为 utf8mb4、查询时给字段补 CONVERT(x USING utf8mb4) 这类转换。共同的排查动作只有一个：先用一段已知正确的中文内容去验证，确认「用这个编码读出来是正常的」，再回头处理真正的文件，避免在错误的方向上试三遍。
GBK 与 UTF-8 互串：两种形态、两种方向
中文 Windows 时代留下的数据大量是 GBK，后来系统逐步转成 UTF-8，于是同一份文件在两种环境下会互相读错。方向一：GBK 的字节被当 UTF-8 读，中文变成 ä¸æ–‡ 这种带重音符号的西文串——因为 GBK 的双字节高位字节恰好落在 UTF-8 的多字节起始区间，看起来像拉丁字母。方向二：UTF-8 的字节被当 GBK 读，中文变成 涓枃、鏂囨湰 这种看似汉字的东西——每个三字节序列被拆成 GBK 的一个汉字加一个残字。这两种都不是加密，纯转码。处理办法就是明确指定目标编码重读：文件类用上一节的编辑器切换；数据库导出导入时在导出和导入两端用同一套字符集（先统一导成 UTF-8 再入库，比直接导 GBK 更不容易反复出错）。这里有一类例外要提醒：像 涓枃 这种「乱码后看着像中文」的结果，如果原始数据确实经历过 UTF-8→GBK→UTF-8 两次错误转换，是可以还原回原文的，但还原必须靠专门的乱码修复工具按规则反推，浏览器里的编码转换工具做不了这步。
一套能复用的排查顺序
按这个顺序走能省掉大量试错。第一步，看有没有编码痕迹：有百分号、反斜杠 \u、点号分三段、或整齐的 Hex 对，就是「被编码过」，粘进识别工具，让它把所有候选结果并排显示，一眼挑出可读的那个。第二步，没有痕迹但中文变形：属于字符集问题，切编辑器按 UTF-8 / GBK 各读一遍，看哪个正常，就用哪个。第三步，能读出来但方向不对：确认了字符集后仍需要转码（比如文件确实是 GBK，但目标系统只接受 UTF-8），这时该用编辑器的「转换为 UTF-8 并保存」，而不是每次读取都指定编码——落盘就转好，后续所有环节都不用再操心。最后一个习惯：处理文本文件时始终明确指定编码，包括脚本里读文件、导入导出、以及复制粘贴到不同编辑器之间，因为「让程序自己猜」是乱码问题最主要的来源。
想马上动手：先拿可疑字符串试 编码自动识别 看它属于哪一类，需要手工转换用 编码转换，处理接口报错时对照 JSON 报错怎么查，正则相关的转义问题看 正则表达式入门。Try it now: paste the suspect string into encoding detection to see which family it belongs to, use encoding conversion to transform it by hand, and pair it with the JSON error guide when the problem shows up in an API response.
常见问题
中文变成了 ??? 或者一串问号，还能救回来吗？
这种情况要分两种：如果问号是在数据传输或存储的环节产生的，通常是目标环境按纯 ASCII 方式转换的，字符信息在被替换成问号的那一刻就已经丢了，属于不可逆——只能从源文件重新导出一次。如果问号只是显示时出现的（文件本身完好，只是打开的程序用了不匹配的编码或字体缺失），那原文件没坏，换一个支持中文的编辑器、用正确编码打开即可，文件不用动。
网址里的中文变成了 %E4%B8%AD 这样的，能直接打开吗？
能，浏览器会自动解码，这本身就是 URL 的正常形态——URL 规范只允许 ASCII 字符，中文必须先转成 %XX 形式才能放进地址栏。你在地址栏里看到中文显示正常，说明解码已经发生了，不用手动改。真正会出问题的是把这个转义后的字符串拿去做文件名、数据库值或者接口参数时，忘记在合适的位置解码，导致存进去的是转义串而不是原文。
同一份文件在同事电脑上乱码，在我电脑正常，怎么定位？
几乎总是两台机器的默认编码或编辑器设置不一致，而不是文件有问题。核对三处：编辑器的默认打开编码（VS Code 有 files.encoding 选项，默认现在通常是 UTF-8）、系统区域设置里「使用 Unicode UTF-8 提供全球语言支持」这个选项、以及命令行工具读文件时的默认编码。统一成 UTF-8 并把文件实际转码保存一次，这类问题就不会再出现——这也是把转码落盘而不是每次读取指定的理由。