货币代码相关工具合集

货币代码工具合集：按 ISO 4217 整理三字母货币代码与符号、各币种的小数位差异，说明金额计算为何要用整数而非浮点数、汇率换算中的舍入与浮点误差问题，以及金额展示时用符号还是代码的本地化取舍，附数值换算与格式化工具入口。适合处理跨境金额展示与账务计算。

货币代码看似只是三四个字母，实际涉及精度、舍入与本地化展示的多重细节。

常见方案对照

维度	浮点数	整数（以最小货币单位计）
精度	二进制无法精确表示十进制	完全精确
累加误差	会累积	无
表示 1.23	1.23（不稳定）	123
舍入	隐式且不可控	显式且可控
数据库字段	DECIMAL 或 FLOAT	BIGINT / INT
JSON 传输	可能有精度显示问题	无此问题
展示时处理	直接显示	按各币种小数位换算
适用场景	科学计算、图形	账务、金额、计费

边界条件

ISO 4217 规定每种货币小数位不同：CNY/JPY/KRW 为 0，USD/EUR 为 2，部分中东货币为 3。
不同币种的换算不是简单乘一个汇率再乘 100，小数位差异必须分别处理。
JSON 里的浮点数在部分语言序列化后可能出现精度显示问题，金额建议传字符串或整数。
舍入方向（向上/向下/四舍五入）必须显式指定，不同语言默认行为不同。

常见坑

对所有币种一律乘除 100，处理日元时金额放大 100 倍。
用浮点数累加金额，跑完一整批后与预期差了几分。
金额字段用 FLOAT 存，累积误差在报表对账时暴露。
JSON 传金额用浮点数，前端与后端各自舍入导致总额不一致。

常见问题

为什么金额计算要用整数而不是浮点数？

因为**浮点数的二进制表示无法精确表达十进制小数**。0.1 + 0.2 在 IEEE 754 里不等于 0.3，累加一百万次后误差会显著累积。财务场景的标准做法是**以最小货币单位为单位的整数**运算：人民币以「分」存 12345，美元以「美分」存 12345，只在展示时除以 100。这样既无浮点误差，也避免了舍入方向的歧义。

JPY 和 CNY 的小数位为什么不一样？

因为 ISO 4217 规定了每种货币的**小数位（minor units）**。人民币、日元、韩元的小数位是 0；美元、欧元是 2；很多中东货币是 3。这个差异是历史形成的，换算时必须按**各自的小数位**处理，不能一律乘除 100。直接套用「乘 100」会在处理日元时放大 100 倍。