Java源文件编码必须与javac编译器指定编码一致，否则报非法字符错误；需显式用-encoding UTF-8、pom.xml配置、IDE编码设置等分别控制编译、运行、资源加载和终端输出四环节。
Java源文件编码必须和编译器一致，否则javac会乱码报错
Java源码本身是文本文件，javac默认按系统平台编码（Windows通常是GBK，Linux/macOS通常是UTF-8）读取。如果.java文件实际保存为UTF-8但系统是Windows且未显式指定编码，javac就会把中文字符解析成乱码，报类似非法字符: '\ufffd'的错误。
解决方式始终是显式声明编码：
- 命令行编译时加
-encoding UTF-8：javac -encoding UTF-8 src/com/example/Main.java
- Maven项目在
pom.xml中配置：
UTF-8 - IDE（如IntelliJ）需同步设置两处：
• File → Settings → Editor → File Encodings → “Project Encoding” 设为
UTF-8• 同页面勾选 “Transparent native-to-ascii conversion”（避免.properties文件乱码）
file.encoding JVM参数只影响运行时I/O，不改变源码编译行为
很多人误以为加-Dfile.encoding=UTF-8就能解决编译乱码，其实它只作用于JVM启动后：new Scanner(System.in)、Files.readAllLines()、String.getBytes()等API的默认字符集。它对javac完全无效。
常见陷阱：
立即学习“Java免费学习笔记（深入）”；
- Spring Boot应用读取
application.properties含中文时乱码 → 必须确保该文件本身是UTF-8无BOM，并启用IDE的“transparent conversion”或改用application.yml（YAML规范强制UTF-8） -
new String(bytes)没指定字符集 → 永远依赖file.encoding，生产环境不可靠，应写成new String(bytes, StandardCharsets.UTF_8) - Tomcat 9+默认
URIEncoding是UTF-8，但老版本需在server.xml里显式配置：
跨平台打包时jar内资源文件编码需单独处理
JAR包本质是ZIP，不记录文件编码信息。如果项目里有src/main/resources/messages_zh_CN.properties，即使源码是UTF-8，JDK的ResourceBundle默认仍按ISO-8859-1加载——这是Java历史包袱。
正确做法：
- 把中文属性值转义为Unicode：用
native2ascii -encoding UTF-8 messages_zh_CN.properties messages_zh_CN_jar.properties - 或改用
java.util.Properties.load(Reader)配合InputStreamReader指定编码（需自己管理资源流） - Maven插件可自动化：使用
properties-maven-plugin在build时转义 - 更现代的替代：直接用
src/main/resources/i18n/messages_zh_CN.json，JSON天然UTF-8，无编码歧义
终端和日志输出乱码本质是stdout/stderr编码不匹配
即使Java程序内部全用StandardCharsets.UTF-8，最终打印到Windows命令行仍可能显示方块——因为cmd默认代码页是GBK（chcp 936），而Java进程的System.out按JVM的file.encoding写入字节，终端用自身编码解释，错位就乱码。
验证与修复：
- 查当前终端编码：Windows下运行
chcp，Linux/macOS看$LANG - 临时修复：Windows启动cmd前执行
chcp 65001（UTF-8），但部分旧工具不兼容 - 根本解法：日志不依赖
System.out，改用Logback/Log4j2，并在appender中指定charset="UTF-8" - IDE运行配置里添加JVM参数
-Dconsole.encoding=UTF-8（部分IDE支持，非JDK标准参数）
-Dfile.encoding一劳永逸。每个环节都要按需显式指定，尤其注意Properties加载和Windows终端默认代码页这两个经典坑。 
