我对UCUM如何定义“升”的符号感到困惑。是的，我知道历史l上已使用该符号，并且最近L已被标准机构（参见例如 BIPM SI 第 8 版）添加为l. 但我认为 UCUM 应该给我们一个单一的、明确的交换符号集。
但是更仔细地阅读 UCUM，我发现它提供了区分大小写和不区分大小写的符号版本。此外，我看到，为了区分大小写，“liter”被定义了两次，一次是区分大小写的符号，l另一次是区分大小写的符号L。所以我解释这个的方式是，如果你在一个区分大小写的环境中，实际上有两个升符号，l和L，它们都意味着同样的事情（有效地使符号不区分大小写——嘘！） .
因此，如果我对此的解释正确，则意味着如果程序支持 UCUM，即使它以区分大小写的方式这样做， _a UCUM 程序也必须始终将land解释L为同义词，包括派生单位，例如ml/ mL。这是正确的解释吗？UCUM 是否强制我们对某些符号进行等价查找？
正确解释 UCUM 会对其实施产生直接影响。以 JSR 363（请参阅 JSR 363的 UCUM UnitFormat）为例，它取代了 JSR 275（声称支持 UCUM 但从未支持），后者已将 UCUM 支持拉到 Eclipse UOMo；阅读这个可怕的故事。所以我坚持使用 JSR 363 参考实现，它将毫升序列化为ml. 那么当 UOMo 最终添加对 JSR 363 的 UCUM 支持时，它是否会认为m“来自 JSR 363 RI 的序列化和来自 UCUM 的“mL”是可互换的？
Werner Keil 告诉我（在前面提到的线程中）UCUM 认为l和L是“两个不同的不同单位”。但是ucum.js 认为它们是相同的单位。
所以这是我的具体问题：我正在使用 JSR 363 RI 序列化单位，生产l升。我更喜欢 UCUM 实现，但这就是现在可用的全部。如果我使用这个实现，它将使用l而不是生成大量数据L。当我的代码最终升级到 UCUM 实现时，它会认为当前序列化的l数据等同于L，还是认为数据与使用L单位的数据不同？UCUM 规范说应该发生什么？
让我换一种方式问这个问题：假设我要编写自己的 JSR 363 的 UCUM 实现。如果我UnitFormat.parse(CharSequence csq)解析land L，结果应该unitLowercaseL.equals(unitUppercaseL)返回true还是false根据 UCUM 规范和 JSR 363？