用于字符串内部编码的 BOCU-1 [关闭]答案

【问题标题】：BOCU-1 for internal encoding of strings [closed]用于字符串内部编码的 BOCU-1 [关闭]
【发布时间】：2020-05-24 18:11:11
【问题描述】：

Java、Javascript、Windows、Dotnet、KDE 等一些语言/平台使用 UTF16。有些人更喜欢 UTF8。

没有语言/平台使用BOCU-1的原因是什么？ JEP 254 和 JEP 254 equivalent for Dotnet 的基本原理是什么？

是BOCU-1申请专利的原因吗？还有什么技术原因吗？

编辑

我的问题不是专门针对 Java。 JEP 254 是指该提案中提到的紧凑型 UTF-16。我的问题是，由于 BOCU-1 对于几乎任何 unicode 字符串都很紧凑，为什么没有任何语言/平台在内部使用它，而不是 UTF-16 或 UTF-8。这种用法可以提高任何字符串的缓存性能，而不仅仅是 ASCII 或 Latin-1。

这种用法也可能有助于以The Language Server Index Format (LSIF) 等格式支持非拉丁编程语言。

【问题讨论】：

JEP 254 说“非目标——在字符串的内部表示中使用 UTF-8 等替代编码不是目标。后续的 JEP 可能会探索这种方法。”我认为“例如”将包括 BOCU-1。
@JonathanLeffler 请看我的编辑。
见过——但我不知道你的问题的答案是什么。我必须搜索 BOCU-1 才能找到有关它的任何信息。免版税许可表明该专利不应该有问题，尽管它确实让使用 BOCU-1 的开发人员有责任从 IBM 获得许可。我有点担心这个问题的答案将是“基于意见的”，这是结束关于 SO 的问题的原因之一。我没有将其标记为关闭（出于任何原因），但请注意，有些人可能会考虑该选项。
嗯，一方面，BOCU-1 更像是一种压缩方案，而不是Unicode 字节编码。例如，在访问/枚举字符串中的单个字符时，必须继续解压缩压缩字符串会降低效率。例如，JEP 254 中的紧凑字符串不使用压缩，它们仅使用较小的字节编码 (Latin-1) 以尽可能节省空间。使用 Latin-1 后端存储对字符串的 UTF-16 接口进行索引相当简单，但使用压缩后端存储对字符串的 UTF-16 接口进行索引就不是那么容易了。
@RemyLebeau 你有什么研究论文可以引用你对official position of the Unicode consortium的否认吗？事实上，对于南亚文、波斯文、西里尔文等许多文字，BOCU-1 UTF16 比 UTF8 UTF16 性能更高。测试机器是 Pentium 2 笔记本电脑，所以今天的机器可能会按照您提到的性能进行压缩。

标签： unicode utf-8 character-encoding utf-16 non-ascii-characters

【解决方案1】：

没有语言/平台使用BOCU-1的原因是什么？

对于 Stack Overflow，这个问题的范围太广了，不可能给出简明的答案。

但是，在 Java 的特定情况下，请注意有人在 2002 年提出了 Java 采用 BOCU-1 作为 RFE（增强请求）的可能性。请参阅 JDK-4787935 (str) Reducing the memory footprint for Strings。

十年后，该错误以“不会修复”的解决方案关闭：

“虽然这是一个非常有趣的提议，但极不可能采用 BOCU 或任何其他内部使用的多字节编码。此外，这归结为时空权衡，其长期后果不明确。鉴于该提案已经拖延了很长时间，因此关闭它似乎是合适的，因为它无法解决“。

JEP 254...的基本原理是什么？

JEP 254 中有一个名为“动机”的部分对此进行了解释，特别是它指出“大多数 String 对象仅包含 Latin-1 字符”。但是，如果您对此不满意，请提出单独的问题。

首先查看What topics can I ask about here?，确保它与 Stack Overflow 相关。审查 JEP 254 的两个人（Aleksey Shipilev 和 Brian Goetz）在此处回复 SO，因此您可能会得到权威的答案。

Dotnet 的 ... JEP 254 等效项的基本原理是什么？

再次，将此作为单独的 SO 问题提出。

是BOCU-1申请专利的原因吗？

That question is specifically off topic here：“法律问题，包括关于版权或许可的问题，不在 Stack Overflow 的主题范围内”，尽管 Wikipedia notes“BOCU-1 是唯一的 Unicode 压缩Unicode 网站上描述的已知受知识产权限制的方案”。

还有什么技术原因吗？

一个很重要的非技术原因是the HTML5 specification explicitly forbids the use of BOCU-1!...

Avoid these encodings

The HTML5 specification calls out a number of encodings that you should avoid...

Documents must also not use CESU-8, UTF-7, BOCU-1, or SCSU encodings, since they... were never intended for Web content and the HTML5 specification forbids browsers from recognising them.

当然，这引发了为什么 HTML 5 禁止使用 BOCU-1 的问题，我能找到的唯一技术原因是 this Mozilla documentation on HTML's <meta> element states：

Authors must not use CESU-8, UTF-7, BOCU-1 and/or SCSU as cross-site scripting attacks with these encodings have been demonstrated.

See this GitHub link 了解有关 BOCU-1 的 XSS 漏洞的更多详细信息。

另外请注意，根据 HTML5 规范，所有主要浏览器都不支持 BOCU-1。

【讨论】：