Java 8与Java 10+中德语Locale的SimpleDateFormat兼容问题求解

这个问题的核心确实是JDK 9启用CLDR locale数据后，德语系Locale的星期缩写默认要求带点（比如Mo.），但你的旧数据是不带点的Mo。既然不想依赖系统属性或修改旧数据，这里有两个可靠的代码层面解决方案：

方案1：自定义DateFormatSymbols（兼容旧的SimpleDateFormat） #

如果你想继续使用原有的SimpleDateFormat代码结构，最直接的方式是手动替换星期缩写符号，让它忽略CLDR的默认规则：

@Test
public void testParseDate() throws ParseException {
    String toParse = "Mo Aug 18 11:25:26 MESZ +0200 2014";
    String pattern = "EEE MMM dd HH:mm:ss z Z yyyy";
    
    // 创建德语Locale的DateFormatSymbols实例
    DateFormatSymbols symbols = new DateFormatSymbols(Locale.GERMANY);
    // 替换短星期名称为不带点的版本（索引0留空，对应一周的第0天，实际从1开始）
    String[] shortWeekdays = {"", "Mo", "Di", "Mi", "Do", "Fr", "Sa", "So"};
    symbols.setShortWeekdays(shortWeekdays);
    
    // 用自定义的符号初始化SimpleDateFormat
    DateFormat dateFormatter = new SimpleDateFormat(pattern, symbols);
    Date date = dateFormatter.parse(toParse);
    
    // 你的断言逻辑
}

这种方式完全绕过了系统默认的locale数据提供者，直接控制日期格式化的符号规则，不管JDK版本是8还是10+，都能稳定解析旧数据，也不需要任何系统属性配置。

方案2：迁移到DateTimeFormatter（推荐长期维护） #

如果你的项目已经在使用Java 8+，更推荐迁移到线程安全、功能更强大的DateTimeFormatter，通过自定义解析规则同时兼容带点和不带点的星期缩写：

@Test
public void testParseDateWithDateTimeFormatter() {
    String toParse = "Mo Aug 18 11:25:26 MESZ +0200 2014";
    
    // 构建自定义格式化器，为每个星期几同时配置带点和不带点的匹配值
    DateTimeFormatter formatter = new DateTimeFormatterBuilder()
            .appendText(ChronoField.DAY_OF_WEEK, Map.of(
                    1L, "Mo", 1L, "Mo.",
                    2L, "Di", 2L, "Di.",
                    3L, "Mi", 3L, "Mi.",
                    4L, "Do", 4L, "Do.",
                    5L, "Fr", 5L, "Fr.",
                    6L, "Sa", 6L, "Sa.",
                    7L, "So", 7L, "So."
            ))
            .appendPattern(" MMM dd HH:mm:ss z Z yyyy")
            .toFormatter(Locale.GERMANY);
    
    // 解析为LocalDateTime，如需Date对象可进一步转换
    LocalDateTime dateTime = LocalDateTime.parse(toParse, formatter);
    Date date = Date.from(dateTime.atZone(ZoneId.systemDefault()).toInstant());
    
    // 你的断言逻辑
}

这个方案不仅解决了兼容性问题，还避免了SimpleDateFormat的线程安全隐患，是Java 8+官方推荐的日期处理方式，适合长期维护的代码库。

总结 #

• 方案1适合最小化代码改动，保留原有SimpleDateFormat的使用场景；
• 方案2是更健壮的长期解决方案，推荐逐步迁移；
• 两种方案都不需要修改旧序列化数据，也不依赖系统属性，完全在代码层面实现跨JDK版本的兼容性。

内容的提问来源于stack exchange，提问作者rzo1