干了几年的 Android 开发，Windows 上打开 Android Studio 看到满屏乱码，简直是家常便饭。控制台里一个好好的println输出，中文全变成了看不懂的符号；打开同事发来的项目文件，代码注释一片狼藉；更气人的是 Gradle 构建日志里的中文提示，错得让人怀疑自己写错了代码。这篇文章就把我这些年和乱码打交道攒下来的经验一次说清楚，从原理到操作，从控制台到文件，全都给你捋明白，照着做基本能解决你手头 99% 的乱码问题。
本文适合所有用 Windows 系统做 Android 开发的同行，无论是刚接触 AS 的新手，还是被乱码折磨了很久的老手，都能在这里找到对应的解法。
1. 乱码根源：编码不统一才是真正的敌人
1.1 字符是怎么变成“乱码”的
很多人在遇到乱码时第一反应是“文件坏了”，其实大多数时候文件一点没坏，只是解读的方式错了。打个比方，一份用中文写好的合同，你非要拿英文发音去读，自然满嘴胡话。计算机里的字符也是这样，字节序列本身没变，变的是“解码规则”。
要理解这个，得先分清常见的几种编码规则。ASCII 是最早的英文编码方案，一个字节表示一个英文字符，简单直接。但中文数量太大，一个字节根本装不下，于是国内发展了 GBK，用两个字节表示一个汉字，兼容 ASCII。而国际上更通用的 UTF-8 是一种可变长度编码，ASCII 字符一个字节，中文通常三个字节，它容纳了全球几乎所有语言的字符，是如今跨平台项目的首选。
乱码的本质就这么简单：同一串字节，编码时用的是规则 A，读取时用的是规则 B，两边对不上，就出现了各种奇奇怪怪的符号。比如经典的现象“锟斤拷”，就是 GBK 编码的汉字被错误地按 UTF-8 解码后又转回 GBK 产生的替代字符。你看到这几个字，基本可以断定文件原始编码是 GBK，当前被按 UTF-8 处理了。
1.2 梳理 Android Studio 里三条关键编码链路
Android Studio 基于 IntelliJ IDEA，本身是一个 Java 进程，一套中文输出要经过好几道关卡，才最终显示到屏幕上。我把它们拆成三条链路来理解，排查时就有了方向。
第一条是“文件保存链路”。你在编辑器里写中文注释，按下 Ctrl+S，IDE 会用某个编码规则把文字写入磁盘。这个编码默认是 UTF-8，但如果项目是从旧环境带过来的，也可能是 GBK。文件在磁盘上躺着的形态，决定了后面所有环节的起点。
第二条是“进程读取链路”。Gradle 编译、Java 进程运行时，需要从磁盘读文件、通过 System.out 输出内容，这个过程中 JVM 使用什么字符集去解码，又是另一套规则。JVM 的默认字符集通常跟操作系统区域设置有关，Windows 中文版默认是 GBK，于是经常出现“文件是 UTF-8、JVM 却当 GBK 读”的错位。
第三条是“终端显示链路”。控制台窗口、Logcat、Terminal 最终显示字节时，要按某种编码渲染到屏幕上。IDE 内置控制台的显示编码可以单独设置，Windows 上的 cmd 和 PowerShell 则有各自的代码页。
这三条链路里任何一环不一致，你看到的就是乱码。所以解决乱码的思路也很清晰：统一所有环节的编码为 UTF-8，让字节从写入到显示全程用同一种规则。
2. 控制台乱码：先解决最影响心情的那个
2.1 第一步：统一 IDE 文件编码设置
控制台乱码虽然看着是输出环节的问题，但很多情况下源头在文件编码，所以第一步永远是打开 File → Settings → Editor → File Encodings（Mac 上是 Preferences），看看界面上的 Global Encoding、Project Encoding、Properties Files 三处设置。这三处强烈建议全部改成 UTF-8，同时勾选底部的 Transparent native-to-ascii conversion。
这个设置的意义在于，它决定了你新建文件时默认使用什么编码。很多老项目的文件是 GBK，新文件却是 UTF-8，混着混着就出事了。全局统一成 UTF-8 后，新建的文件都是 UTF-8，源头上先消灭一半问题。如果你打开设置时发现 Project Encoding 被设置成了系统默认（System Default），那基本就可以确定项目里的中文编码状态是混乱的，需要立刻改掉。
改完这个设置后，记得顺手检查一下是不是同时又有某个文件右下角的编码指示器显示的是 GBK。只要有文件显示 GBK，它就会成为后续乱码的定时炸弹。这个文件的处理方式我会在第三章细讲，这里先把全局统一了。
2.2 第二步：给 Android Studio/JVM 强制指定 UTF-8
IDE 内置控制台里跑 Java 程序或者跑 Gradle，中文输出乱码的一个核心原因，是 JVM 的file.encoding参数沿用了系统默认值（Windows 中文系统是 GBK）。Android Studio 本身是 JVM 进程，通过 Help → Edit Custom VM Options 可以给它加一个强制参数。
打开这个菜单后，AI Studio 会自动定位到一个.vmoptions文件，在里面加一行：
-Dfile.encoding=UTF-8保存后重启 Android Studio，控制台的中文输出基本立刻就正常了。我实测下来这个参数对 AS 内置的运行窗口、Build 窗口都有立竿见影的效果。另外可以顺手加一行-Dsun.jnu.encoding=UTF-8，这个参数影响文件名的解码，对处理文件名相关的乱码也有帮助。
注意，如果你用的是新版 Android Studio，它自带的 JetBrains Runtime 版本较新，JDK 18 以上的默认字符集已经是 UTF-8 了，理论上不容易乱码。但 Gradle 守护进程用的是你配置的 JDK，不一定是同一个版本，所以这个 vmoptions 参数依然值得加。改完之后，建议用 Help → About 看下 Runtime 信息，确认参数生效。
2.3 第三步：Windows 控制台代码页与区域设置
有些场景下，乱码发生在 IDE 之外的 Windows 控制台。比如你在 Terminal 里直接跑adb logcat，输出中文全是乱码。这是因为 Windows 的命令行工具默认使用代码页 936（GBK），而 adb 的输出是 UTF-8，两边不一致。
临时验证的办法是运行chcp 65001，把当前控制台代码页切到 UTF-8，再执行adb logcat，通常乱码会消失。但 chcp 只对当前窗口有效，关掉就没了，所以这只能用来验证方向。想一劳永逸，可以在 Windows 的“设置 → 时间和语言 → 语言 → 管理语言设置 → 更改系统区域设置”里，勾选“Beta: 使用 Unicode UTF-8 提供全球语言支持”，这样整个系统的非 Unicode 程序默认编码都会变成 UTF-8。
我个人对修改系统区域设置的态度是：慎用。这个选项会影响很多老程序，某些国产软件和旧版游戏会因此出现界面错乱，得不偿失。如果你只是开发 Android，优先保证 Android Studio 内部的编码链路统一就够了。只有在你在 Windows Terminal 里频繁处理中文输出，而且完全确认没有旧软件依赖 GBK 时，才建议改系统设置。
2.4 第四步：Gradle 构建日志乱码整治
Gradle 是另一类高频乱码现场，而且不太容易靠前面的设置解决，因为 Gradle 守护进程是一个独立的 JVM 进程，它自己的编码同样默认跟随系统。处理方式是在项目根目录的gradle.properties里，给 Gradle 的 JVM 指定 UTF-8 参数：
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8加完之后，关键一步是执行./gradlew --stop停掉所有 Gradle daemon，然后重新构建，否则老守护进程还会用旧的编码工作，你改了配置也不生效。这一步我踩过坑，改完参数没重启 daemon，白折腾了半小时，直到用--stop重启才看到效果。
除了构建日志，编译报错信息里的中文乱码也常见。比如代码里写了一个中文字符串，javac 编译时报“错误: 编码GBK的不可映射字符”，这就是源码文件是 UTF-8，而 javac 按 GBK 去读导致的。解决办法是在app/build.gradle里显式声明所有的 Java 编译任务的编码：
tasks.withType(JavaCompile).configureEach { options.encoding = 'UTF-8' }Kotlin 编译器同理，如果遇到 Kotlin 文件里的中文乱码报错，可以在kotlinOptions.freeCompilerArgs里加-encoding参数，或者干脆保证源码文件全部是 UTF-8。多数情况下，把 JVM 编码和编译编码同时设为 UTF-8，Gradle 相关的乱码就能全部压下去。
3. 文件乱码：源码、配置、资源文件逐个击破
3.1 乱码文件伤前必做的侦查工作
打开一个文件发现乱码，先别急着转码，更不要直接删了重写。第一步要做的是明确这个文件原本是什么编码。方法很简单，观察 IDEA 编辑器右下角的状态栏，那里会显示当前文件的编码名称，比如 UTF-8、GBK。如果显示是 UTF-8 但内容是乱码，那说明文件实际可能是 GBK，只是被 IDE 错误地识别成了 UTF-8。
另一个可靠的办法是用支持编码检测的文本工具打开它，比如 VS Code 或 Notepad++。Notepad++ 右下角有编码显示，点击后还能看到“使用 UTF-8 编码”、“使用 ANSI 编码”等选项，通过逐个切换，哪个编码下文字显示正常，它就是文件原本的编码。VS Code 的右下角也有类似功能，点击编码按钮可以“重新打开”为其他编码，实测效果很好。
看字节更准确的做法是查看文件开头的 BOM 头。UTF-8 with BOM 的文件开头有三个字节EF BB BF，UTF-16 LE 是FF FE，UTF-16 BE 是FE FF。用十六进制工具或者hexdump看一眼文件头，基本能定调。不过大多数项目文件是 UTF-8 without BOM，开头没有特殊标记，这时就得靠内容反推。比如乱码中出现大量“�”，说明解码时遇到了无法映射的字符，原始编码和当前显示编码必定有一个不是正解。
3.2 用 IDE 自带能力正确转码
确定文件原始编码后，真正的转码操作在 IDEA 里其实非常顺手。打开乱码文件，点击右下角编码指示器，会出现两个关键选项：Reload in（以指定编码重新加载）和 Convert to（转换文件编码并保存）。
两者的区别要搞清楚。Reload in 只是改变 IDE 当前读取这个文件时用的解码规则，文件在磁盘上仍然是原编码；Convert to 才是真正把文件内容重写为另一种编码。正确的转码流程，是把一个 GBK 文件转成 UTF-8。先点击右下角编码，选择 Reload in → GBK，此时 IDE 会用 GBK 规则重新读文件，乱码消失，中文正常显示了。然后再次点击右下角编码，选择 Convert to → UTF-8，这样文件就被真正保存为 UTF-8 格式。检查一下右下角编码显示已经变成 UTF-8，再重新加载还能正常显示，那就转换成功了。
批量文件转码，我个人的做法是写个 Python 脚本，因为 IDE 插件市场里那些批量转码插件，有的多年不维护，有的只支持部分文件类型，不如自己写脚本可控。最简单的脚本思路是这样：
import os from pathlib import Path root = Path(r'D:\your_project\src') count = 0 for p in root.rglob('*.java'): raw = p.read_bytes() try: text = raw.decode('gbk') except UnicodeDecodeError: continue p.write_bytes(text.encode('utf-8')) count += 1 print(f'converted {count} files')这个脚本把指定目录下所有能用 GBK 成功解码的 Java 文件转成 UTF-8，解码失败的文件会跳过，因为如果是 UTF-8 文件，用 GBK 解码大概率会报错。动手跑脚本前一定记得先给项目做个备份或者提交一次 Git，转码是不可逆的，万一某个文件被误判，还能有后悔药吃。
3.3 properties、XML、Gradle 文件的特殊处理
Java 项目里有一类特别容易出乱码的文件，就是strings.xml和gradle相关文件。strings.xml本身是 XML，正常情况顶部<?xml version="1.0" encoding="utf-8"?>已经声明了编码，IDE 会按 UTF-8 处理，但如果文件本身是 GBK 又没更新声明，那就会出现乱码。处理方式同上一节，先确认原始编码，再转成 UTF-8，并保留 XML 声明中的 encoding="utf-8"。
properties文件则是个特例。Java 的 properties 文件规范默认是 ISO 8859-1 编码，中文必须写成\u4e2d\u6587这样的 Unicode 转义序列，直接写中文在很多环境下会乱码。IDEA 提供了省心方案：回到 File → Settings → Editor → File Encodings，在 Properties Files 区域，把默认编码改成 UTF-8，并勾选 Transparent native-to-ascii conversion。勾选后，你在 IDE 里可以直接阅读和编写中文，保存到磁盘时 IDE 会自动转成\uXXXX转义形式，别人打开也不会乱码。如果项目里 properties 文件已经乱码了，用转码工具把它先恢复成正常中文，再重新保存即可。
build.gradle文件里的中文注释乱码，多数原因是文件本身编码不是 UTF-8，直接用转码流程处理即可。但有一点要特别注意：如果文件里有中文字符串字面量，转成 UTF-8 后一定要回到 Gradle 编译那块再确认下编译参数，否则很可能出现“转码后原本显示正常，编译又报错”的怪事。根因还是编译进程读取文件时的编码没指定，配合 2.4 小节的options.encoding = 'UTF-8'一起搞定。
3.4 Git 仓库引起的乱码问题
从 Git 仓库拉下来的代码出现乱码，有可能是同事提交的时候文件编码就没统一，也有可能是 Git 本身的设置问题。最常见的情况是：远程仓库里的文件是 GBK，你本地 IDEA 按 UTF-8 打开，自然乱码。这种问题的解法是先把文件转成 UTF-8，然后让仓库里所有文件都统一成 UTF-8 后再提交一次。
Git 还有两个和中文乱码相关的配置值得记住。第一个是git config --global core.quotepath false。默认情况下 Git 会把中文文件名转义成八进制字符显示，设置了这条之后，git status里就能看到正常的中文文件名了，不然每次提交查看变更记录的时候，文件名全是一串\346\265\213这样的转义字符，非常影响判断。第二个是提交信息里的中文乱码，这个主要是看提交时使用的环境，如果在 Windows 的 cmd 里执行 git 命令，注意chcp 65001或者设置i18n.commitEncoding为 UTF-8。
从团队协作的角度讲，最稳妥的方案是在项目根目录放一个.gitattributes文件，明确声明文本文件的编码和换行符规则，例如：
*.java text eol=lf eol=lf *.xml text eol=lf *.properties text eol=lf这样至少在 Git 层面减少编码混乱的概率。但说到底，Git 本身不产生乱码，它只是忠实地保存和传输字节，文件用什么编码写进去，就原样存下来。要真正根治，还得靠整个团队约定统一的文件编码。
4. 实操流程与常见问题排查实录
4.1 快速定位乱码的检查清单
被乱码问题缠住的时候，最容易犯的错是四处瞎改设置，改完也不知道哪里生效了。我自己后来养成了一个习惯，按场景套检查清单，几分钟就能定位问题。
如果你遇到的是控制台输出乱码，先检查这四处：打开 File → Settings → Editor → File Encodings，确认三处编码都是 UTF-8；打开 Help → Edit Custom VM Options，确认有-Dfile.encoding=UTF-8；检查 Gradle 的gradle.properties，确认有org.gradle.jvmargs=-Dfile.encoding=UTF-8；执行./gradlew --stop重启 daemon。这三四处都做对了，控制台乱码还解决不了的情况，我基本没遇见过。
如果你遇到的是文件打开乱码，先看文件右下角的编码显示，再尝试用不同的编码重新加载。一个一个切换，总有一种编码下中文是正常的，找到后转成 UTF-8 保存。如果你遇到的是编译报错乱码，优先检查 javac 和 Kotlin compiler 的 encoding 参数，其次是检查报错的源文件编码是什么。能用清单解决的事，就不要靠玄学。
4.2 我实际踩过的一些坑
踩坑经验比顺手的教程更值钱，说说那几次折磨我最久的案例。
第一次，我在Help → Edit Custom VM Options里加了-Dfile.encoding=UTF-8之后，启动 Android Studio 居然报错了，提示找不到 vmoptions 文件。查了半天发现是我在 mac 和 Windows 两套环境之间切换项目时，配置文件放错了位置。事实上 Edit Custom VM Options 菜单会自动帮你在正确的位置创建和定位文件，不需要手动去找，我偏偏手动创建了一个没用的文件，导致配置没生效。正确做法是直接用菜单打开，如果文件里有重复的参数，记得去重，不然后写的参数会覆盖先写的。
第二次，是一个老项目里的build.gradle，中文注释在 AS 里显示正常，编译也正常，但跑完测试后控制台里的中文测试描述全部乱码。一开始我以为是控制台编码问题，折腾了很久，最后才发现是测试任务的输出通过println打到了 Gradle 的 StandardOut，daemon 进程的编码是旧的。跑到gradle.properties里加上 jvmargs 参数后，还必须跑./gradlew --stop，问题立刻消失。
第三次，一个同事发来的文件，我这边打开是一堆“锟斤拷”和“?"。我用 3.1 节的方法检查，发现这文件是被多次转码污染过的：原始 GBK 被当作 UTF-8 读了一遍，产生了一堆不可识别的字符，又被保存成了 GBK。这个状态的文件已经完全丢失了原始字节信息，只能恢复到乱码前的内容，没法百分百还原。那次我只能手动改回所有注释里的中文。这个经验让我养成了一个习惯：每次拿到外部代码，先全局扫描一遍文件编码，发现 GBK 文件立刻统一转码，而不是等出了问题再处理。
4.3 几个提高排查效率的小习惯
在乱码这件事上，花 10 分钟统一规划，好过每次遇到都花 2 小时临时救火。我建议每个 Android 项目都做三件小事，成本极低，收益极高。
第一，在项目 README 或内部的规范文档里写清楚：“所有文件统一使用 UTF-8 without BOM 编码”。团队里编码混乱的根源，往往是没有人正式约定过这件事，每个人各用各的默认设置。第二，在gradle.properties和app/build.gradle里提前写好编码参数，不要等出问题了再加。我上面提到的参数组配合新项目模板，可以省掉后面大部分麻烦。第三，拿到一个项目的第一天，就用脚本扫一遍源码目录里有没有非 UTF-8 文件。这个习惯看起来有点“洁癖”，但实际能帮团队省不少沟通成本。
另外一个小技巧，处理文件乱码时尽量用“识别 → 重新加载 → 转换”的顺序，而不是直接“转换 → 保存”。IDEA 的 Reload in 功能不会立刻覆盖磁盘文件，你可以先在只读状态下确认乱码是不是真的恢复了，再决定要不要真正写入。这就像做外科手术前先做影像检查，看过结果再动刀，安全性高很多。
我个人这几年的体会是，乱码并不是什么高深的技术难题，它就是编码规则不统一引发的信息误读，只要掌握“识别原始编码、统一为目标编码”的思路，绝大多数问题都能迎刃而解。真正的难点并不在于命令和参数，而在于耐心对待每一处看似凌乱的字节。每次在评论区看到有人因为乱码而重装 IDE 甚至重做系统，我都会觉得可惜——那几个参数和设置就能搞定的事，真犯不上大动干戈。
