Fatal编程技术网
  • javascript/
  • Javascript 使用Number.toLocaleString（）时货币格式的差异

Javascript 使用Number.toLocaleString（）时货币格式的差异

javascript unicode localization

Javascript 使用Number.toLocaleString（）时货币格式的差异,javascript,unicode,localization,currency,icu,Javascript,Unicode,Localization,Currency,Icu,我一直在研究javascript的区域设置感知数字格式，而number.toLocaleString和by似乎是解决这个问题的好方法 特别是，我更喜欢在已经实现的抽象基础上构建特定于区域设置的格式，而不是重新发明轮子，为已经解决的问题提供更多的解决方案 因此，我在一些不同的javascript环境中调用了Number.toLocaleString，发现货币格式似乎发生了变化： (5).toLocaleString('fr-CH', {currency: 'CHF', style: 'curre

我一直在研究javascript的区域设置感知数字格式，而
number.toLocaleString
和by似乎是解决这个问题的好方法

特别是，我更喜欢在已经实现的抽象基础上构建特定于区域设置的格式，而不是重新发明轮子，为已经解决的问题提供更多的解决方案

因此，我在一些不同的javascript环境中调用了
Number.toLocaleString
，发现货币格式似乎发生了变化：

(5).toLocaleString('fr-CH', {currency: 'CHF', style: 'currency'});
// Node v10.15.1:  'CHF 5.00'
// Node v12.1.0:   '5.00 CHF'
// Firefox 66.0.2: '5.00 CHF'
// Chrome 73.0.…:  '5.00 CHF'
// Safari 12.0.3:  '5.00 CHF'
// IE 11:          '5.00 fr.'
  • IE 11与其他的不同，但考虑到它的年龄，我并不感到惊讶
  • 令我惊讶的是
    fr CH
    中
    CHF
    的格式似乎在节点版本
    10
    和
    12
    之间发生了变化
  • 为了进行比较，我查看了glibc LC_的货币设置，发现它似乎将
    CHF
    置于金额之前，至少在1997年左右。对于大多数当前浏览器，
    CHF
    的位置似乎不同，这使得它特别令人困惑
我想知道并理解：

  • 为什么在这些情况下，
    CHF
    的位置不同？
    • 我知道这可能取决于可用的系统区域设置或浏览器。但是节点版本之间的变化似乎对我来说意味着一个更为近期和自愿的变化
  • 是否有正确的方法放置
    CHF
    ，或者这两种选择是否都适用于CH，或者更具体地说
    fr CH
    ？
    • 因此，拥有像论文或研究数据库这样的真实来源，而不是道听途说或轶事，将是一件美妙的事情
    • 更新（2019-05-16）： 针对我的部分建议，我想具体说明：

    • 在commit中，
      fr#u CH
      的格式决定为
      currencyFormat{“#，###0.00·；-#，###0.00·”}
      ，但我仍然缺少决定的来源，我很想知道它
    所以我已经检查了，看看是否可以找到
    Number.toLocaleString
    的行为定义在哪里

    • 在
      builtins number.cc
      中，我找到了
      BUILTIN（NumberPrototypeToLocaleString）{…}
      ，它使用
      Intl:：NumberToLocaleString（…）
    • 这让我想到了
      intl objects.cc
      ，它使用
      icu:：number:：LocalizedNumber格式化程序实现了
      intl:：NumberToLocaleString
    因为v8使用了，所以我签出了以继续搜索

    • 我第一次试图找到数字格式的来源，这让我先查看了
      decimfmt
      和
      numfmt
      ，但不知怎么的，我一直在失去跟踪
    • 然后我意识到，将格式定义与代码的其余部分保持一定的分离可能是有意义的。通过查看网站和源代码，我终于找到了
      icu4c/source/data/locales/de_CH.txt
      和
      icu4c/source/data/locales/fr_CH.txt
      。 
      • de_CH.txt
        有
        currencyFormat{“·0.00；·0.00；·0.00”}
      • fr#u CH.txt
        具有
        currencyFormat{“#，##0.00·；-#，##0.00·”}
    • 现在使用
      git
      我找到了19个月前首次为
      fr\u CH
      （）引入
      currencyFormat
      的提交。
      • 这可能介于节点
        v10
        和
        v12
        之间
      • 我还可以看到，在
        curreencyFormat
        被添加到
        fr\u CH
        之前，回退到
        de\u CH
        是有意义的，因此可以看到格式将改变它的方式
    提交中提到了CLDR 32 alpha，我找到了。 但是，我目前无法确定定义
    fr\u CH
    的
    currencyFormat
    的图表的位置

    我觉得通过查找对
    fr\u CH
    currencyFormat
    的更改，我发现并理解了导致不同节点版本之间行为更改的更改

    到目前为止，我不明白为什么
    glibc
    和
    icu
    在这里有差异，但这是我可以在具体项目的背景下询问的

    我的印象是，我仍然缺少导致
    currencyFormat
    实现的具体决策或数据点-如果我找到了，我会将其添加到这里并感到满意

    更新2019-05-18：
    • CLDR 32数据可以在下的下载部分找到。
      • 我可以从中下载
        cldr-common-32.zip
        ，其中包括文件
        common/main/fr_CH.xml
        ，其中货币格式定义如下：
    
#,##0.00 ¤ ;-#,##0.00 ¤
    • Via我还发现了一种调查工具，用于决定这些事项并记录这些决定的结果。
      • 在中，我可以看到决策来源：

    更新2019-05-21： 出于好奇，我在清单上以及unicode组织票证系统上都询问了这个问题

    这促使我进一步调查，在与一位朋友研究这一点时，我们偶然发现Github专注于CLDR数据，而不是像icu那样在其中包含CLDR相关数据

    我们发现commit引入了第一个变化，导致
    CHF
    被放在数字之后而不是之前，commit对两张票证有了更好的认识。 这些票据是和，第二个票据是后续票据，用于清除某些格式

    表面上，CLDR-9370似乎主要讨论十进制分隔符，但也讨论了货币符号的位置

    其中一个来源是由