虚拟机参数encoding（如-Dfile.encoding）决定JVM在未显式指定编码时的默认字符集，直接影响文件读写、HTTP参数传递和数据库连接的数据解码方式，设置错位会在数据传输链路上产生乱码。 这个问题在跨平台部署时尤其突出，因为Windows和Linux的默认编码机制完全不同，而大多数线上服务器跑的是Linux。
jvm参数encoding设置方法：三个入口和两条生效链路
启动命令直接传参
最常见的方式是在java命令后面加参数：
java -Dfile.encoding=UTF-8 -jar your-app.jar
这个参数在JVM启动时写入系统属性file.encoding，然后被Charset.defaultCharset()读取，成为后续未指定编码的IO操作的默认值，需要注意，-D参数必须放在-jar之前，否则不生效。
另一个容易被忽略的参数是-Dsun.jnu.encoding，它管的是文件名和文件路径的转换，举个例子，你在Linux上解压一个Windows压缩包，文件名里的中文乱码，多半是sun.jnu.encoding的问题，而不是file.encoding的问题。
修改方式：
java -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -jar your-app.jar
环境变量和代码运行时读取
有些框架允许通过环境变量覆盖编码设置,比如Spring Boot的SERVER_TOMCAT_URI_ENCODING，代码层面，你可以通过System.getProperty("file.encoding")确认当前值，也可以临时修改该属性，但业界共识认为，运行时修改file.encoding极不可靠，因为JVM内部的很多缓存（如Charset默认实例）在首次使用后就不会再变。
两条链路：file.encoding与sun.jnu.encoding各管一段
在实际传输链路中,这两个参数的分工是：
file.encoding：负责字符数据与字节数据之间的转换，比如FileReader、FileWriter、String.getBytes()的默认编码行为。sun.jnu.encoding：负责文件名、路径字符串与操作系统文件系统之间的转换，比如File类的构造与解析。
如果你只改了file.encoding而没管sun.jnu.encoding不乱码了，但文件名可能还是歪的。
file.encoding utf-8还是gbk：部署前先想清楚
Windows和Linux环境下的默认值差异
在Java 18之前，JVM不会自动探测操作系统的编码，Windows中文版默认字符集是GBK，Linux服务器多数是UTF-8，同一个jar包，本地测试用Windows跑得好好的，编码默认走GBK；推到Linux服务器上，如果代码里没显式指定编码，JVM会尝试根据系统区域设置获取默认字符集，结果大概率变成UTF-8。
两边解析同一份GBK编码的文件,读取结果完全不一致，这类问题在开发环境极少暴露，因为开发机的locale设置通常和IDE一致，而生产环境往往没有配套调整。
判断当前jvm默认字符集的方法：
java -XshowSettings:properties -version 2>&1 | grep encoding
或者直接写一行代码输出：
System.out.println(Charset.defaultCharset());
怎么选：看数据来源，不看个人喜好
选择file.encoding的核心依据是你的数据从哪里来。
| 环境 | 默认编码 | 典型乱码场景 |
|---|---|---|
| Windows中文版 | GBK | 读取UTF-8的properties文件，中文键全变问号 |
| Linux（多数发行版） | UTF-8 | 读取GBK编码的CSV导出文件，内容显示为菱形乱码 |
| Docker容器（未配置locale） | 受宿主机影响，不稳定 | 日志文件中文乱码，进程启动时编码切换异常 |
| Java 18+（JEP 400） | 强制UTF-8 | 旧代码依赖默认编码的行为与升级前不一致 |
业内专家指出,file.encoding只影响那些没有显式指定编码的API调用路径，也就是说，你在代码里写new InputStreamReader(inputStream)，它会用默认编码；但如果你写new InputStreamReader(inputStream, StandardCharsets.UTF_8)，file.encoding再乱也影响不到你。
数据传输链路上的编码断裂：从文件到HTTP再到数据库
乱码不只是“显示问题”，更准确地说，是数据在传输的某个节点上被错误解码，jvm参数encoding设置了正确的值，不等于整条链路都正确，因为传输链路的每一段都可能发生独立的编解码操作。
文件读写：FileReader无参构造的隐性编码
很多老代码直接new FileReader(file)，这个构造方法在Java 11之前硬编码为平台默认编码，压根不看file.encoding参数，Java 11之后提供了带Charset参数的构造器，但你要是没指定，它仍然走Charset.defaultCharset()。
实操层面的建议是：所有文件读写操作，务必显式传编码：
Files.newBufferedReader(path, StandardCharsets.UTF_8)
不要依赖任何全局参数兜底,因为兜底逻辑在不同JDK版本间的行为存在差异。
HTTP传输：tomcat uriencoding和file.encoding区别
这两个参数被混淆的频率极高,Tomcat的URIEncoding控制的是HTTP请求行中URL参数的解码，作用于Tomcat容器层面；
file.encoding控制的是JVM内部字符字节转换，作用于应用代码层面。
一条典型的乱码路径是：
- 浏览器发送
GET /search?keyword=中文 - Tomcat使用
URIEncoding解码URL参数 - 你的代码用
request.getParameter("keyword")拿到字符串 - 后续将该字符串写入文件时,又涉及
file.encoding
这三段中任何一段的编码不一致,结果都是乱码，Tomcat 8及以上版本默认URIEncoding=UTF-8，但如果你还在用Tomcat 7或更早版本，默认是ISO-8859-1，这是很多历史项目的乱码根源。
排查顺序建议：先看请求日志，确认Tomcat收到的原始字节；再看代码里是否对参数做了二次编解码；最后才怀疑jvm参数encoding设置。
数据库连接：JDBC URL里少写一个参数
MySQL驱动在客户端和服务器之间传输数据时,也有自己的一套编码机制，在JDBC连接串中，characterEncoding参数告诉驱动用哪种编码处理字符数据：
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=UTF-8
在实践中,useUnicode=true&characterEncoding=UTF-8这个组合能覆盖大多数场景，但如果你的file.encoding是GBK，而characterEncoding设成UTF-8，部分驱动版本会以file.encoding为准做隐式转换，导致数据入库后变成乱码。
多数情况下,统一全链路编码（文件、HTTP、数据库、JVM默认值）为UTF-8，能省掉90%以上的乱码排查时间。
linux下jvm默认字符集和windows为什么不一样
根本原因：JVM依赖系统locale决定默认字符集（Java 18之前）
JVM在启动时读取操作系统的locale设置,Windows中文版的默认locale是zh_CN.GBK，Linux服务器根据LANG和LC_ALL环境变量决定，多为en_US.UTF-8或zh_CN.UTF-8。
这就导致同一个jar包在两种操作系统下,Charset.defaultCharset()的返回值不同。
查看Linux系统当前locale：
echo $LANG locale
Windows开发，Linux部署
典型的翻车现场是这样的：你在Windows上用IDE跑通了所有测试，导出的CSV文件用Excel打开完全正常，部署到Linux服务器后，导出的CSV文件用Excel打开，中文全部变成乱码。
原因拆解：Windows下file.encoding为GBK，导出时writer.write()走了GBK编码；Linux下默认UTF-8，如果代码里没有显式指定导出编码，生成的文件编码和Excel预期的GBK对不上。
解法很简单：导出代码里写死OutputStreamWriter
的编码为UTF-8并添加BOM头，或者直接和前端约定好统一用UTF-8。
Docker容器里漏配locale
Docker容器通常使用最小化基础镜像,很多镜像压根没装locales包，也没有设置LANG环境变量，在这种环境下，JVM获得到的系统信息不完整，就可能用POSIX或C作为默认locale，整个编码行为变得非常怪异。
规避方法是在Dockerfile里显式声明：
ENV LANG=C.UTF-8 ENV LC_ALL=C.UTF-8
同时启动Java进程时加上-Dfile.encoding=UTF-8，双保险。
日志文件中的中文变问号
日志框架（Logback、Log4j2）通常会指定日志文件的编码，常见配置<charset>UTF-8</charset>，如果没指定，部分框架会使用系统默认编码，即file.encoding，线上排查日志乱码时，先确认日志框架的Encoder配置，再检查JVM启动参数，优先级是配置文件高于启动参数。
常见疑问：虚拟机参数encoding与乱码排查的高频问题
Q1：jvm参数encoding设置方法改完后，程序为什么还是乱码？
先排查三件事：第一，确认-Dfile.encoding确实传进去了，用java -XshowSettings:properties或JMX查看系统属性；第二，确认代码里是否存在显式指定编码的IO操作覆盖了全局参数，比如用new OutputStreamWriter(out, "GBK")强制输出；第三，确认sun.jnu.encoding是否需要同步调整，如果涉及文件名的读写，只改file.encoding不够。
Q2：file.encoding设置为UTF-8后，在Windows上会不会影响其他软件？
不会。-Dfile.encoding只作用于当前启动的JVM进程，不会修改操作系统级别的区域设置，也不影响其他进程，如果你把Windows下生成的文件传给其他系统，文件本身的字节流是什么编码，取决于你写文件时指定的编码，和JVM参数没有必然关系，建议所有跨系统传输的文件统一按UTF-8写出，据OpenJDK官方提案JEP 400，Java 18已将平台默认字符集固定为UTF-8，但明确指定编码的代码不受影响。
Q3：tomcat uriencoding和file.encoding需要保持一致吗？
两者作用链路不同：URIEncoding管HTTP请求行的URL解码，file.encoding管JVM内字符流和字节流的转换，但建议保持两者一致并统一为UTF-8，因为在请求参数被读取后，你会把这些字符串写入缓存、数据库或文件，只要后续环节的编码解码和Tomcat的解码结果不一致，数据就存在被二次转码的风险，经验做法是Tomcat连接器配置URIEncoding="UTF-8"，JVM启动参数加-Dfile.encoding=UTF-8，JDBC连接串指定characterEncoding=UTF-8，三处对齐。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e8%99%9a%e6%8b%9f%e6%9c%baencoding%e5%8f%82%e6%95%b0%e8%ae%be%e7%bd%ae%e9%94%99%e8%af%af%e4%bc%9a%e6%80%8e%e6%a0%b7%e5%ad%97%e7%ac%a6%e7%bc%96%e7%a0%81%e6%80%8e%e4%b9%88%e9%80%89/
