windows 下 java 通过 system.in 读取 utf-8 编码的重音字符（如法语、德语字母）时，即使已设置 -dfile.encoding=utf-8 和 scanner(system.in, utf_8)，仍会返回全零字节数组——这是因 windows 控制台底层未对齐“主机原生编码”与 jvm 默认编码所致，属 jdk 长期未修复的平台限制问题。
windows 下 java 通过 system.in 读取 utf-8 编码的重音字符（如法语、德语字母）时，即使已设置 -dfile.encoding=utf-8 和 scanner(system.in, utf_8)，仍会返回全零字节数组——这是因 windows 控制台底层未对齐“主机原生编码”与 jvm 默认编码所致，属 jdk 长期未修复的平台限制问题。
在 Windows 平台开发国际化 Java 应用时，一个看似简单却极易踩坑的问题是：控制台无法正确读取带重音的 Unicode 字符（如 è, ü, ñ, ç）。你可能已做了所有“标准操作”——启用 UTF-8 代码页（chcp 65001）、添加 JVM 参数 -Dfile.encoding=UTF-8、显式为 Scanner 指定 StandardCharsets.UTF_8，甚至验证了 echo ü 在 PowerShell 中显示正常，但 input.nextLine() 返回的字符串字节仍是 [0, 0, 0, 0]。这不是你的代码错误，而是 Windows 控制台 I/O 与 Java 运行时之间深层不兼容的体现。
? 根本原因：JDK 的“主机编码隔离”机制
根据 OpenJDK 官方 Bug 报告 JDK-8295672，该问题已被明确认定为 Windows 平台特有缺陷，且至今（截至 JDK 21）仍未修复。核心症结在于：
System.in 是一个原始字节流，其解码行为由 Windows 控制台子系统（conhost.exe）决定，而非 JVM。即使你将 JVM 默认编码设为 UTF-8，Windows 控制台在将键盘输入传递给 stdin 时，仍按其当前活动代码页（ACP）或 OEM 代码页进行预解码（例如 CP1252 或 CP850），再以“已损坏”的字节序列交给 Java。JVM 无法逆转这一过程——它拿到的是错乱字节，不是 UTF-8 编码流。
这一点被 JEP 400（Java 18 引入的 “UTF-8 by Default”）明确排除在外：
立即学习“Java免费学习笔记（深入）”；
“Standardize on UTF-8 throughout the standard Java APIs, except for console I/O.”
—— 控制台 I/O 被刻意豁免，正是因为 Windows 主机编码不可控。
因此，你在 IntelliJ 中能正常读取 ü，并非 IDE “绕过了问题”，而是 JetBrains 主动规避了系统控制台：其内置终端使用 JNA（Java Native Access）直接调用 Windows API（如 ReadConsoleW）获取宽字符（wchar_t），再安全转换为 Java String，完全绕开了 System.in 字节流陷阱。
✅ 可行解决方案（按推荐度排序）
✅ 方案一：改用 System.console().readLine()（仅限非重定向场景）
Console console = System.console();
if (console != null) {
String input = console.readLine("请输入带重音的文本: ");
System.out.println("读取成功: " + input);
System.out.println("UTF-8 字节: " + Arrays.toString(input.getBytes(StandardCharsets.UTF_8)));
} else {
System.err.println("警告：System.console() 为 null（可能因重定向或 IDE 环境）");
}⚠️ 注意：System.console() 在命令行直接运行（java -jar app.jar）时有效；但在重定向（java -jar app.jar
✅ 方案二：使用 JNA 直接调用 Windows 原生 API（最可靠）
添加 Maven 依赖：
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<version>5.14.0</version>
</dependency>示例代码（安全读取 Unicode 输入）：
import com.sun.jna.Native;
import com.sun.jna.platform.win32.Kernel32;
import com.sun.jna.platform.win32.WinDef.DWORD;
import com.sun.jna.platform.win32.WinNT.HANDLE;
import com.sun.jna.ptr.IntByReference;
public class WinConsoleReader {
private static final HANDLE STD_INPUT_HANDLE = Kernel32.INSTANCE.GetStdHandle(-10);
public static String readLine() throws Exception {
char[] buffer = new char[1024];
IntByReference charsRead = new IntByReference();
boolean success = Kernel32.INSTANCE.ReadConsoleW(
STD_INPUT_HANDLE,
buffer,
buffer.length,
charsRead,
null
);
if (!success) throw new RuntimeException("ReadConsoleW failed");
int len = charsRead.getValue();
// 移除换行符（\r\n 或 \n）
return new String(buffer, 0, Math.max(0, len - (len > 0 && buffer[len-1] == '\n' ? 1 : 0)))
.replace("\r", "");
}
public static void main(String[] args) throws Exception {
System.out.print("请输入: ");
String s = readLine();
System.out.println("结果: [" + s + "]");
System.out.println("UTF-8 字节: " + Arrays.toString(s.getBytes(StandardCharsets.UTF_8)));
}
}✅ 优势：直接读取 Unicode 宽字符，彻底规避代码页转换；兼容 CMD、PowerShell、Windows Terminal。
❌ 劣势：仅限 Windows；需额外依赖；需处理异常与缓冲区边界。
⚠️ 方案三：临时降级为 ISO-8859-1 / CP1252（仅限西欧语言）
若仅需支持法语、德语等西欧语言（不含中文、俄文等），可尝试：
Scanner input = new Scanner(System.in, "Cp1252"); // Windows ANSI code page // 或 Scanner input = new Scanner(System.in, "ISO-8859-1");
⚠️ 风险：无法处理中文、日文、阿拉伯文等；属于妥协方案，不推荐用于全球化应用。
❌ 无效操作（请勿浪费时间）
- 单独执行 chcp 65001：PowerShell/CMD 会切换输出编码，但 stdin 解码仍受宿主限制；
- 仅加 -Dfile.encoding=UTF-8：影响 Files.read* 等 API，对 System.in 无效；
- 在代码中 new String(bytes, "UTF-8") 二次解码：输入字节已是损坏状态，无法挽救；
- 修改 IDE 控制台字体或编码设置：IntelliJ 内置终端有效，但不影响外部 java -jar 行为。
? 总结与建议
| 场景 | 推荐方案 |
|---|---|
| 跨平台部署（含 Linux/macOS） | 使用 System.console() + 回退到 Scanner(System.in, "UTF-8")（Linux/macOS 原生支持） |
| Windows 生产环境（必须稳定读取 Unicode） | 采用 JNA ReadConsoleW 方案——这是目前唯一能 100% 可靠解决该问题的工程实践 |
| 快速原型/内部工具（仅 Windows） | 直接使用 IntelliJ 运行（其 JNA 实现已验证可靠），避免命令行启动 |
| Web/服务端应用 | 避免依赖控制台输入，改用 HTTP API、配置文件或数据库交互 |
? 最后提醒：该问题本质是操作系统层与 JVM 层的契约断裂，非 Java 语言缺陷。与其长期调试 System.in，不如尽早将用户输入迁移至更可控的渠道（如 Swing GUI、JavaFX 或轻量 Web 界面）。对于必须坚守控制台的场景，请坚定选择 JNA 路径——它已在数百万 Windows Java 工具（如 Gradle、Maven 插件）中得到验证。
