考虑到数据类型的各种怪癖和本地化,Web服务与应用程序之间传递货币价值的最佳方式是什么？某处有标准吗？
我的第一个想法是简单地使用数字类型.例如
"amount": 1234.56
在使用浮点数据类型进行货币计算时,我已经看到很多关于缺乏精度和舍入误差的问题的论点 - 但是,我们只是传递值而不是计算,所以这无关紧要.
EventBrite的JSON货币规范指定如下:
{
"currency": "USD",
"value": 432,
"display": "$4.32"
}
Bravo用于避免浮点值,但现在我们遇到另一个问题:我们可以容纳的最大数字是多少？
一条评论(我不知道它是否属实,但似乎是合理的)声称,由于数字实现在JSON中有所不同,因此您可以期待的最好的是32位有符号整数.32位有符号整数可以容纳的最大值是2147483647.如果我们表示次要单位中的值,那么是21,474,836.47美元.2100万美元似乎是一个巨大的数字,但是某些应用程序可能需要使用大于此值的值,这并不是不可思议的.对于1000个未成年单位成为主要单位的货币,或者货币价值低于美元的货币,问题会变得更严重.例如,突尼斯第纳尔分为1,000毫米.2147483647 milim,或2147483.647 TND是$ 1,124,492.04.在某些情况下,更有可能超过100万美元的价值.另一个例子:越南盾的子单位因通货膨胀而变得无用,所以让我们只使用主要单位.2147483647越南盾是98,526.55美元.我相信很多用例(银行存款,房地产价值等)远高于此.(EventBrite可能不必担心票价会那么高!)
如果我们通过将值作为字符串传递来避免该问题,那么字符串应该如何格式化？不同的国家/地区具有截然不同的格式 - 不同的货币符号,无论符号出现在金额之前还是之后,无论是否在符号和金额之间有空格,如果使用逗号或句点来分隔小数,如果逗号用作千位分隔符,括号或减号来表示负值,可能还有更多我不知道的值.
如果应用知道它正在使用的语言环境/货币,请传达类似的值
"amount": "1234.56"
来回,并相信应用程序正确格式化金额？(另外:是否应避免使用小数值,以及以最小货币单位指定的值？或者主要和次要单位是否应列在不同的属性中？)
或者服务器应该提供原始值和格式化值？
"amount": "1234.56"
"displayAmount": "$1,234.56"
或者服务器应该提供原始值和货币代码,并让应用程序格式化它？"amount":"1234.56""currencyCode":"USD"我假设使用的方法应该在两个方向上使用,与服务器之间进行传输.
我一直无法找到标准 - 您是否有答案,或者可以指向我定义此资源的资源？这似乎是一个普遍的问题.