如何在Java中解析两种自定义日期格式（不受模式顺序影响）

我明白你遇到的问题了——用DateTimeFormatterBuilder的appendOptional时，格式顺序直接决定了能否解析成功，这确实很头疼。本质上是因为你之前的用法误解了appendOptional的作用：它是追加一段可选的格式片段，而不是提供多个完整的备选格式。比如场景1里，你的格式相当于[yyMMdd'h'HH][yyMMdd]，解析短日期时虽然第二个可选片段能匹配，但LocalDateTime需要时间字段，所以会报错；场景2的格式是[yyMMdd][yyMMdd'h'HH]，解析长日期时第一个片段先匹配了前6位，剩下的h05就无法处理了。

下面给你两种无需外部依赖、不受格式顺序影响的解决方案：

方案一：用可选段+默认时间补全（推荐） #

这种方式通过定义一个包含可选时间部分的统一格式，同时为LocalDateTime所需的时间字段设置默认值，不管输入是长格式还是短格式都能完美解析：

DateTimeFormatter formatter = new DateTimeFormatterBuilder()
    // 基础日期格式（必须匹配）
    .appendPattern("yyMMdd")
    // 开始可选的时间部分：只有当输入包含'h'HH时才会匹配
    .optionalStart()
    .appendPattern("'h'HH")
    .optionalEnd()
    // 为LocalDateTime补全默认的时间字段（因为短格式没有时间）
    .parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
    .parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0)
    .parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0)
    .toFormatter();

// 测试两种格式
LocalDateTime date1 = LocalDateTime.parse("201028h05", formatter); // 成功
LocalDateTime date2 = LocalDateTime.parse("201028", formatter);     // 成功

这种方案的优势是只用一个DateTimeFormatter，解析逻辑更简洁，而且完全不受格式顺序影响——因为基础日期是必须匹配的，时间部分是可选的后缀。

方案二：尝试两种格式（兼容老逻辑） #

如果更倾向于明确区分两种格式，可以用try-catch依次尝试解析，这种方式也能做到不受顺序影响（其实是按顺序尝试，但两种格式互不干扰）：

public static LocalDateTime parseCustomDate(String dateStr) {
    // 定义两种格式，短格式需要补全时间默认值
    DateTimeFormatter longFormatter = DateTimeFormatter.ofPattern("yyMMdd'h'HH");
    DateTimeFormatter shortFormatter = new DateTimeFormatterBuilder()
            .appendPattern("yyMMdd")
            .parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
            .parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0)
            .parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0)
            .toFormatter();

    try {
        // 先尝试长格式
        return LocalDateTime.parse(dateStr, longFormatter);
    } catch (DateTimeParseException e) {
        // 失败则尝试短格式
        return LocalDateTime.parse(dateStr, shortFormatter);
    }
}

// 测试
LocalDateTime date1 = parseCustomDate("201028h05"); // 成功
LocalDateTime date2 = parseCustomDate("201028");     // 成功

这种方案的好处是逻辑直观，适合需要对不同格式做特殊处理的场景，但相比方案一多了一次异常捕获的开销（不过日常使用中可以忽略）。

关键注意点 #

• 解析成LocalDateTime时，必须保证所有时间字段（时、分、秒）都有值，所以短格式必须通过parseDefaulting补全默认值；
• optionalStart()和optionalEnd()是用来包裹一段可选的格式片段，和appendOptional()的区别是：前者是在当前格式基础上添加可选后缀，后者是追加一个独立的可选格式段（这也是你之前写法出错的核心原因）。

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