在 CentOS 上从事 Java 开发时，编码问题几乎每位开发者都会遇到。尤其是从 Windows 或 Mac 将项目迁移过来后，编译时出现大量“锟斤拷”乱码，令人十分头疼。问题本身并不复杂，但解决方法较多，容易混淆。今天我们就此彻底梳理清楚，从最紧急的处理到一劳永逸的方案，一次讲透。
CentOS 下 Java 编译时文件编码问题解决方案
1. 检查并设置系统默认编码
这是最基础的排查步骤。系统默认编码最好与 Java 编译和运行时使用的编码保持一致，UTF-8 是首选。你可先执行以下命令查看当前状态：
- 输入
echo $LANG观察输出结果。若不是类似en_US.UTF-8这样的 UTF-8 编码，则很可能是问题的根源。 - 若仅需在当前终端临时解决，可执行：
export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8 - 若要永久生效并对所有用户适用，需修改系统配置。编辑
/etc/locale.conf文件，添加LANG=en_US.UTF-8。保存后重启系统或执行source /etc/locale.conf使其立即生效。
2. 编译时显式指定编码
这是最直接、最常用的“救火”方式，强烈推荐。无论系统编码如何，你只需在 javac 命令中使用 -encoding 参数，强制告知编译器：“听我的，就用 UTF-8 来解释这份代码！”
javac -encoding UTF-8 YourJavaFile.java如需编译多个文件，同样简单：
javac -encoding UTF-8 File1.java File2.java File3.java该参数直接解决了编译器解读文件时的编码“语言不通”问题，是实际项目中最常用的一招。
3. 设置 JVM 默认编码（可选）
有时编译通过，但程序运行时输出的中文仍是乱码。这通常是 Java 运行时环境（JVM）的编码与系统未对齐。此时可借助 -Dfile.encoding 参数：
java -Dfile.encoding=UTF-8 YourMainClass甚至可在编译阶段使用 -J 参数将该设置传递给 JVM，影响整个编译过程：
javac -J-Dfile.encoding=UTF-8 YourJavaFile.java这种方法适用于需要统一 JVM 运行时编码，或遇到编译与运行时行为不一致的异常情况。
4. 配置全局默认编码（可选）
若每次编译都需添加 -encoding 参数感到繁琐，可配置“全局设置”。在用户主目录下创建 ~/.javacrc 文件，或在 /etc/javacrc 下创建系统级配置文件，并写入如下内容：
-J-Dfile.encoding=UTF-8配置完成后，以后使用 javac 命令时默认即携带 UTF-8 编码，省心不少。不过请注意，该设置会影响所有 javac 命令，有时可能带来意外副作用，使用时需心中有数。
5. 检查并转换源文件编码
以上方法都是让环境适配文件，但若文件本身编码不正确（比如从网上复制的代码是 GBK 编码），则无论如何设置环境参数都无效。需要检查并转换源文件本身：
- 使用
vim打开文件：vim YourJavaFile.java，然后输入:set fileencoding查看当前编码。 - 若发现不是 UTF-8，直接在 vim 中执行
:set fileencoding=utf-8，然后保存退出（:wq）即可完成转换。 - 当然，使用 VS Code、Notepad++ 等图形化编辑器，直接“另存为”并选择 UTF-8 编码，是最直观稳妥的方法。
6. 验证环境变量设置
最后，别忘了检查“大环境”。确保 JAVA_HOME 变量指向正确的 JDK 路径，例如 /usr/lib/jvm/java-11-openjdk-amd64，并将 $JAVA_HOME/bin 添加到 PATH 中。这些基础操作不再赘述。一个实用技巧是，通过设置 JAVA_TOOL_OPTIONS 环境变量，自动为所有 Java 程序传递编码参数：
export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"该设置会影响系统上运行的所有 Java 程序，是一个强大的“后门”。建议将其添加到 ~/.bashrc 或 ~/.bash_profile 文件中，然后执行 source ~/.bashrc 使其永久生效。
总而言之，解决 CentOS 下的 Java 编码问题，最优先的方法是编译时指定编码（方法2）和设置系统默认编码（方法1），这两招能搞定 90% 的情况。若问题依旧，则多半是 IDE（如 Eclipse、IntelliJ IDEA）或构建工具（Maven、Gradle）中的编码配置与项目未统一，需进一步检查其设置。
