Javascript Firefox数字本地化不一致

我偶然发现Firefox、Chrome和ASP.NETMVC核心web应用程序之间的“km-KH”区域设置的数字格式不一致

在Chrome和ASP.NET MVC核心web应用程序中，数字使用点作为十进制分隔符，逗号作为千位分隔符。但在Firefox中，情况正好相反，这显然会导致年久失修

如果要在浏览器控制台中粘贴以下代码段：

(1234.56).toLocaleString('km-KH')
// or
new Intl.NumberFormat('km-KH').format(1234.56)

Chrome将呈现：

"1,234.56"

"1.234,56"

Firefox将呈现：

"1,234.56"

"1.234,56"

我的主要问题很简单：如何解决这种不一致性

据我所知，Firefox的行为不端，而Chrome和ASP.NETMVC内核的工作却如期进行

---

有趣的事实：CLDR对“km”编号格式的定义也不一致：

定义的符号有：逗号作为小数分隔符，点作为分组分隔符

"symbols-numberSystem-latn": {
  "decimal": ",",
  "group": ".",
  // ...
}

但当他们指定十进制格式时，他们会反过来使用：

"decimalFormats-numberSystem-latn": {
  "standard": "#,##0.###",
  // ...
}

---

这是本地化定义中的一个实际错误吗？

由于这个主题相当复杂，我不坚持我的答案指向确切的原因，但是，其中一个原因可能来自以下内容

.toLocaleString

已知在浏览器之间工作不一致。这是因为没有针对该函数的特别严格的规范。退房

正如@T.J.Crowder在中正确指出的，规范在ECMA脚本规范的较新版本中有了很大的发展

然而，由于历史或其他原因，

.toLocalString

的输出仍然非常依赖于浏览器。虽然它对某些语言的效果非常一致（例如，在我的例子中，locales

fr

，

ru

&

en-AU

的输出在Firefox、Chrome甚至Safari中都是完全相同的），但在其他语言中可能会有很大的不同（在我的例子中，locales

jp

，

kmkh

&

sqal

在3种不同的浏览器中输出了3种不同的东西）

我现在找不到参考资料，但在某一点上我发现，除了其他事情，不同之处在于Firefox尝试使用操作系统的语言首选项，而Chrome则使用Chrome中专门设置的语言首选项（或自动检测）

如果您使用（或可能计划使用）SSR，这可能会带来另一个挑战，因为根据您的工具集，格式可能会从服务器环境中获取，就像在中一样

---

如果你想控制输出的确切格式，那么，这里非常受欢迎和赞赏，因此可能会帮助你。

Hmm，这似乎是Firefox中的一个实际错误。也许你需要向他们提交一份错误报告，然后在同一时间在你的终端上做一些补丁。为了让事情更糟，Internet Explorer 11输出

”១,២៣៤.៥៦"

。显然，无论它是从哪个数据库工作的，它都不同意拉丁语是默认的数字系统，它更喜欢使用“本地”数字系统——但使用

，

进行分组，使用

，

进行小数，就像Chrome一样。但是，Edge同意…Firefox！拉丁数字（好吧，源自阿拉伯语，但是…）和

表示分组，而

，

表示小数。真是一团糟。在线查找其他参考资料时，似乎在分隔符上。sigh@T.J.Crowder：IE默认情况下不对

km KH

使用拉丁编号系统。您可以使用：

（1234.56）。ToLocalString（'km-KH-u-nu-latn'）覆盖此系统

，这也将与Chrome保持一致。在我的例子中，另一点是Firefox不一致。@alesc-也许，但由于其他不一致的来源，人们开始怀疑在北高棉询问多个人是否会得到多个答案。：-”这种情况之所以发生，是因为该功能没有特别严格的规范。”这已经多年没有发生过了，至少从ES2015（2015年）开始.ES5规范没有提到ECMA-402，这就是为什么我说至少从ES2015开始，确实如此，但在这种情况下，ES2015规范只是编纂了一个已经达成一致的立场。ES2015只是花了很长时间才完成。即使我使用了“适当的“通过本地化，我得到了同样的不一致性。例如：

new Intl.NumberFormat（'km-KH'）.format（1234.56）

。此外，自动检测在这里不适用，因为我清楚地指定了实际的区域设置。@alesc即使指定了实际的区域设置，您签入的浏览器也可能不支持它。在这种情况下，默认为浏览器中支持的区域设置时，它将自动失败&这似乎是浏览器的一个不错的选择。即使支持locale，其格式也将依赖于浏览器&不能保证它的工作方式完全相同。IRL仅仅假设一些微小的差异就足够了。如果目标是i18n，那么它的好处明显大于伤害。如果你只是喜欢一种特定的格式，你可能需要考虑一个库/自定义解决方案。