我对UCUM如何定义＆＃34;升＆＃34;的符号感到困惑。是的我知道历史上已经使用了符号l，并且标准组织（参见例如BIPM SI第8版）最近添加了L作为{{1的替代方案}}。但我认为UCUM应该给我们一套明确的符号用于交换。
但是，仔细阅读UCUM，我发现它提供了区分大小写和不区分大小写的符号版本。此外，我看到，对于区分大小写，＆＃34;升＆＃34;定义两次，一次使用区分大小写的符号l，另一次使用区分大小写的符号l。因此，我解释这一点的方式是，如果您处于区分大小写的环境中，实际上有两个升符号，L和l，并且两者都意味着相同的事情（有效地使符号不区分大小写 - 谢谢！）。
因此，如果我正确地解释了这一点，那就意味着如果一个程序支持UCUM，即使它以区分大小写的方式这样做，_a UCUM程序必须始终解释L和{{ 1}}作为同义词，包括l / L等派生单位。这是正确的解释吗？ UCUM强迫我们对某些符号进行等效查找吗？
正确解释UCUM会对其实施产生直接影响。以JSR 363为例（参见UCUM UnitFormat for JSR 363），它取代了JSR 275（据称支持UCUM但从未做过），已经取消了UCUM支持并转移到Eclipse UOMo;阅读the horrible story。所以我坚持使用JSR 363参考实现，它将毫升序列化为ml。因此，当UOMo最终为JSR 363添加UCUM支持时，它是否会识别mL＆＃34;序列化来自JSR 363 RI和＆＃34; mL＆＃34;从UCUM可以互换？
Werner Keil告诉我（在前面提到的帖子中），UCUM认为ml和m是＆＃34;两个不同的不同单位＆＃34;。但是ucum.js considers them to be the same units。
所以这是我的具体问题：我使用JSR 363 RI序列化单位，生成l升。我更喜欢UCUM实现，但现在可以使用所有这些功能。如果我使用此实现，它将使用L而不是l生成大量数据。当我的代码最终升级到UCUM实现时，它会将当前序列化的l数据视为等同于L，还是会认为数据与使用l的数据不同单位？ UCUM规范说什么应该发生？
让我以另一种方式提出这个问题：让我们说我将编写自己的UCUM实现JSR 363.如果我的L解析L和{{1} }，根据UCUM规范和JSR 363，结果UnitFormat.parse(CharSequence csq)是否应该返回l或L？