考虑到数据类型的各种怪癖和本地化,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"我假设使用的方法应该在两个方向上使用,与服务器之间进行传输.
我一直无法找到标准 - 您是否有答案,或者可以指向我定义此资源的资源？这似乎是一个普遍的问题.
我打算创建一个包含金额的API.我想知道最佳做法是什么,或者某人是否对某些格式有一些好的或坏的经历.
我见过以下两种可能性:
我要在这两者之间来回走动.所以我出去查看其他API使用的内容,并提出以下列表:
因此,在18个采样的API中,4个使用次要单位,13个使用基本单位,1个使用难以理解的混合物.在13个使用基本单位的人中,10个是以引用的字符串形式传输它们,3个是不带引号的小数字(如果你看Intuit则实际为2个半).
我个人觉得不得不解析像"8.20"之类的字符串,因为如果你解析它会变成"8.19999999 ......"如果你错误地使用了浮点数.所以我倾向于只发送整数.但我不认为这是一个很好的论点,我发现通常API倾向于将基本单位作为字符串.
你对每种格式有什么好的论据吗？