使用多个可选模式时订单的重要性 [英] Importance of order when using multiple optional patterns

问题描述

DateTimeFormatter 中可选模式的顺序如何影响解析操作？

How does the order of optional patterns in a DateTimeFormatter affect the parsing operation?

我运行了这个程序，并想知道为什么最后一行抛出异常而不是前三个。

I was running this program and wondered why the last line throws an exception but not the first three.

public static void main(String[] args) {
  String p1 = "[EEEE][E] dd-MM-yyyy";
  String p2 = "[E][EEEE] dd-MM-yyyy";
  String date1 = "Thu 07-01-2016";
  String date2 = "Thursday 07-01-2016";
  parse(date1, p1); //OK
  parse(date1, p2); //OK
  parse(date2, p1); //OK
  parse(date2, p2); //Exception
}

private static void parse(String date, String pattern) {
  DateTimeFormatter fmt = DateTimeFormatter.ofPattern(pattern, Locale.ENGLISH);
  System.out.println(fmt.parse(date));
}

最后一行的例外是：

java.time.format.DateTimeParseException：文本'星期四07-01-2016'无法在索引3解析

java.time.format.DateTimeParseException: Text 'Thursday 07-01-2016' could not be parsed at index 3

推荐答案

文档没有提到任何优先级，我认为你得到的结果是正常的。它是从左到右读取String格式的结果。

The documentation does not mention any precedence and I'll argue that the result you are getting is normal. It is the result of reading the String format from left to right.

• 让我们考虑第一种格式 [EEEE] [E] dd-MM-yyyy。

• 星期四07-01-2016：API会尝试查找是否可以匹配第一个可选部分[EEEE]。引用 DateTimeFormatter 关于文本标记的Javadoc

• "Thu 07-01-2016": the API tries to find if the first optional section "[EEEE]" can be matched. Quoting from DateTimeFormatter Javadoc about text token

正好4个模式字母将使用完整格式。

Exactly 4 pattern letters will use the full form.

在这种情况下，它是一周中某一天的完整形式。这与Thu不匹配，因此将跳过可选部分。但是，第二个可选部分是[E]，仍然引用

which in this case is the full form of the day of the week. This doesn't match for "Thu" so that optional section will be skipped. The second optional section, however, is "[E]", and still quoting

少于4个模式字母将使用缩写形式。

Less than 4 pattern letters will use the short form.

所以这将匹配Thu。因此，可以正确理解要解析的字符串

so this will match "Thu". Thus the String to parse can be understood correctly

• 星期四07-01-2016：API尝试查找是否第一个可选部分[E]可以匹配，它适用于Thu。如上所述，API现在将尝试找到[EEEE]的匹配项，但它不会找到任何匹配项，因此会跳过可选部分。


• 2016年7月1日星期四：API尝试匹配[E]再次，这就是事情发生的地方：它确实匹配。 Thursday以Thu开头，因此格式化程序能够找到匹配项。但是，它试图解析其余的rsday 07-01-2016。 [EEEE] 可选部分不匹配，因此将跳过。然后它失败了空间，因为左边没有空格（而是有一个r。）

• "Thu 07-01-2016": the API tries to find if the first optional section "[E]" can be matched and it does work for "Thu". As above, the API will now try to find a match for "[EEEE]" but it won't find any so the optional section is skipped.
• "Thursday 07-01-2016": the API tries to match "[E]" again and that's where the thing happens: it does match. "Thursday" starts with "Thu" so the formatter was able to find a match. But then, it tries to parse the rest which is "rsday 07-01-2016". [EEEE] optional section won't be matched so it will be skipped. Then it fails with the space because there is no space on what's left (there's a "r" instead).

因此，如果您运行代码

parse("ThuThursday 07-01-2016", "[E][EEEE] dd-MM-yyyy");

你会发现它有效：[E]匹配星期四和[EEEE]匹配星期四。

you'll see that it works: "[E]" matched "Thu" and "[EEEE]" matched "Thursday".

注意异常消息如何暗示这一点（强调我的）：

Notice how the exception message also hints at this (emphasis mine):

java.time.format.DateTimeParseException：文本'星期四07-01-2016'无法解析在索引3

索引3对应r rsday所以这意味着它能够解析，直到这一点。

Index 3 corresponds to the "r" of "rsday" so it means it was able to parse, right up to this point.

这篇关于使用多个可选模式时订单的重要性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！