使用带locale和format参数的toInteger转换欧洲格式数值列异常咨询

• 核心根因为数字格式模式串的使用不符合规范：主流数据处理产品的dataflow中，带locale参数的toInteger函数均遵循ICU数字格式规范，格式串里的逗号,是千位分隔符的固定占位符，点.是小数分隔符的固定占位符，两个占位符的含义不会随locale参数变化。
• 当你传入locale为de时，系统会自动把占位符映射为德语区的实际数字符号：千位分隔符占位符,对应实际字符.，小数分隔符占位符.对应实际字符,。
• 你当前使用的#.###格式串，会被系统识别为「整数部分+小数部分（共3位）」的结构，对应德语区的实际分隔符为逗号，而你要解析的1.019里没有逗号，系统只会解析到匹配整数规则的1就截断，因此仅返回1。
• 常量测试返回1019属于对应产品的常量解析模块的兼容bug，列处理走的是标准解析逻辑，因此出现两者结果不一致的情况。

通用规则 #

1. 先确认目标locale的数字书写规则，明确实际使用的千位分隔符、小数分隔符
2. 编写格式串时，始终用,代表千位分隔符的位置，.代表小数分隔符的位置，不需要替换为对应locale的实际符号
3. 传入locale参数后，系统会自动完成占位符到实际符号的映射

你的场景适配写法 #

要解析德语区格式的整数字符串（千位分隔符为.，无小数位），可以用以下任意一种写法：

• 固定4位整数的场景：toInteger(NewPositive, '#,###', 'de')
• 不确定数值长度的场景（支持任意位数的千位分隔整数）：toInteger(NewPositive, '#', 'de')
• 千万级以上长整数场景：toInteger(NewPositive, '#,###,###,###', 'de')

以上写法对1.019的转换结果均为1019，符合预期。

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