我偶然发现了Firefox，Chrome和 ASP.NET MVC Core Web应用程序之间"km-KH"区域设置的数字格式不一致。
在Chrome和 ASP.NET MVC Core网络应用程序中，数字使用点表示小数点分隔符，逗号表示千位分隔符。但在 Firefox 中，情况正好相反，这显然会导致不满意。
如果要在浏览器控制台中粘贴以下代码片段：
(1234.56).toLocaleString('km-KH')
// or
new Intl.NumberFormat('km-KH').format(1234.56)
Chrome 将呈现：
"1,234.56"
Firefox 会渲染：
"1.234,56"
我的主要问题很简单：如何解决这种不一致？
据我所知，Firefox行为不端，而Chrome和 ASP.NET MVC Core正在按预期工作。
有趣的事实：CLDR对"km"数字格式的定义也不一致：https://github.com/unicode-cldr/cldr-numbers-full/blob/master/main/km/numbers.json
定义的符号是：逗号作为小数分隔符，点作为分组分隔符
"symbols-numberSystem-latn": {
"decimal": ",",
"group": ".",
// ...
}
但是当他们指定十进制格式时，他们会以相反的方式使用它：
"decimalFormats-numberSystem-latn": {
"standard": "#,##0.###",
// ...
}
这是本地化定义中的实际错误吗？
由于这个话题相当复杂，我不坚持我的答案指向确切的原因，但其中一个原因可能是以下原因。
众所周知，.toLocaleString浏览器之间的工作不一致。发生这种情况是因为此功能没有特别严格的规范。看看这个答案。
正如@T.J. Crowder在他的评论中正确指出的那样，规范在ECMA脚本规范的较新版本中已经发生了很大的变化。
尽管如此，由于历史或其他原因，.toLocaleString输出仍然非常依赖于浏览器。虽然它在某些语言中非常一致地工作(例如，在我的情况下，语言环境的输出fr，ru和en-AU在Firefox，Chrome甚至Safari上完全相同(，但在其他语言的情况下可能会有很大不同(在我的情况下，语言环境jp，km-KH&sq-AL在3个不同的浏览器中输出了3个不同的东西(。
我现在找不到参考，但在某些时候我发现，除了其他事情之外，不同之处在于 Firefox 尝试使用操作系统的语言首选项，而 Chrome 使用专门在 Chrome 中设置(或自动检测(的语言首选项。
如果您使用(或可能计划使用(SSR，这可能会带来另一个挑战，因为根据您的工具集，格式可能会从服务器环境中选取，就像在 Node.js 中一样。
如果您想控制输出的确切格式，那么，在SO moment上非常喜欢和赞赏.js可能会对您有所帮助。