[Bug] A number format ending in a comma scales the value by an extra power of ten

[nkuprins]

Search before asking

• I searched in the issues and found nothing similar.

Fesod version

main

JDK version

any

Operating system

Linux

Steps To Reproduce

File file = new File("thousands.xlsx");

DataFormatData dataFormat = new DataFormatData();
dataFormat.setFormat("#,##0,");

WriteCellData<BigDecimal> cell = new WriteCellData<>(new BigDecimal("1234567"));
cell.getOrCreateStyle().setDataFormatData(dataFormat);

FesodSheet.write(file)
        .head(Collections.singletonList(Collections.singletonList("thousands")))
        .sheet()
        .doWrite(Collections.singletonList(Collections.singletonList(cell)));

System.out.println(FesodSheet.read(file).sheet().doReadSync());

Current Behavior

[{0=124}]

Expected Behavior

[{0=1,235}]

A trailing comma in a number format scales the value down by a thousand, so 1234567 should read as
1,235. It is divided by ten thousand instead, and the digits the format asks for are dropped on top
of that.

Anything else?

format	value	current	expected
#,##0,	1234567	124	1,235
0,	1234567	124	1235
#,##0.00,,	1234567	1.20	1.23
0\.00,,	1234567	0.00	0.01

Two separate causes, both in InternalDecimalFormatWithScale.

1. int cnt = index_comma - index_point - 1 (DataFormatter.java:540) - #,##0, has no decimal point, so indexOf(".") is -1 and the grouping comma yields a bogus extra power of ten. POI has no such loop, but it can't just be deleted: it was added in fastexcel #156 for alibaba/easyexcel #2319, where the point in 0\.0, is escaped, hence literal, and cleanFormatForNumber strips the escaping before DecimalFormat sees it.
2. divide(divider, RoundingMode.HALF_UP) (DataFormatter.java:558) rounds to the dividend's scale, dropping the decimals the format asks for.

Found while writing the tests in #1110.

Are you willing to submit a PR?

• I'm willing to submit a PR!