Java “为什么是模式？”；33333.##”；当我们使用DecimalFormat方法时，行为非常奇怪。format（）？

昨天，我试图亲自探索DecimalFormat method.format（）及其占位符的行为以及它们的作用。
所以我写了两个数字，并尝试了不同的模式。使用“#.##”时，所有非有效零被截断，使用“0000.00”时，该方法在数字前面添加前导零。没关系，但后来我尝试了一些奇怪的模式，只是想看看会发生什么。
对于“33333.###”模式，最终输出非常奇怪。您可以在下面看到我的代码：

DecimalFormat df = new DecimalFormat("33332.##");
double a= 222.46705219;
double b=-102.000;

System.out.println(df.format(a));
System.out.println(df.format(b));

其产出为：

 33332222,47
-33332102,0   

与数字输入相同，但使用的模式为“33033”。##给出的结果为：

33222,4732
33102

我知道程序在0的位置添加了格式化的数字，但是为什么当0没有显示为占位符时，该方法仍然对第一个数字和（显然）第二个数字进行四舍五入？
为什么我的第一个数字被四舍五入为第二个数字，而不是第二个数字（b）为什么在0？33033位的中间出现0位占位符，程序在它的位置插入格式化的数字A，但在B的末尾不打印“33”？ 我真的不知道如何解释这种行为。

突出显示了您应该设置的模式的清晰语法。这两种格式都违反了所需的语法，因此您的发现不应被视为可靠的，并且可能会在将来的版本中发生变化。坦率地说，我很惊讶构造函数没有对这些格式抛出异常

33332.##

：将

33332

视为前缀，其余的

##

无效，因为在小数点之前需要

0

或

33033.##

：将

33

视为前缀，留下

033.#

。鉴于

0

，

或

#

不能是任何前缀或后缀的一部分，并且

3

只能是前缀或后缀的一部分，此模式无效。

突出显示了应设置的模式的清晰语法。这两种格式都违反了所需的语法，因此您的发现不应被视为可靠的，并且可能会在将来的版本中发生变化。坦率地说，我很惊讶构造函数没有对这些格式抛出异常

33332.##

：将

33332

视为前缀，其余的

##

无效，因为在小数点之前需要

0

或

---

33033.##

：将

33

视为前缀，留下

033.#

。考虑到

0

，

或

#

不能是任何前缀或后缀的一部分，

3

只能是前缀或后缀的一部分，这种模式是无效的。

是的，我知道它们是无效的，但这并不能解释为什么每个模式对待数字a的方式都与对待数字b的方式不同。请看示例-为什么模式“33332.##”将“a”格式化为十进制分隔符后的第二位数字，而将“b”格式化为第一位数字？我想说的是，因为它无效，所以结果是不可预测的。它可能有很多原因，没有理由相信它不会在没有警告的情况下改变。是的，我知道它们是无效的，但这并不能解释为什么每个模式对待数字a的方式都不同于数字b。请看示例-为什么模式“33332.##”将“a”格式化为十进制分隔符后的第二位数字，而将“b”格式化为第一位数字？我想说的是，因为它无效，所以结果是不可预测的。它可能有很多原因，没有理由相信它不会在没有警告的情况下改变。