1 个不稳定版本
0.1.0 | 2022年12月28日 |
---|
#1319 在 文本处理
51KB
779 行
bocu1
此 crate 具有以下两个用途
-
为寻找 BOCU-1 可用实现的用户提供一个可行的实现,以及一些与直接处理 BOCU-1 字符串和“小字符串”(打包到 64 或 128 位整数中)相关的实用工具。
-
作为一份详尽的解释/参考,帮助人们理解编码的工作原理,从网络上现有的多个、零散的文档中拼凑信息。
因此,它具有比必要更多的冗余和解释,尽可能“分割”成尽可能多的层,以最大限度地提高清晰度、动机、设计选择等。因此,它的速度可能过于缓慢。但无论如何,它不是一种快速的编码:速度优势来自一次性编码文本并在其编码(更小!)形式下工作。
我还包括了一系列测试向量和与 IBM 之前参考实现相连的随机化验证器。
BOCU-1 是什么
BOCU-1 是一种相对不错的 Unicode 编码,类似于 UTF-8 或类似编码,但有一些不同的权衡。它并不适用于所有(甚至许多)情况,一般来说,大多数应用程序应依赖于 UTF-8,但 BOCU-1 在某些情况下可以提供一些您可能需要的功能
-
通常较小。BOCU-1 中的 'C' 代表压缩,这种编码的主要方式是将其视为一个非常简单的以文本为中心的压缩格式。BOCU-1 字符串比大多数其他常见的 Unicode 编码中的字符串要小。特别是它足够小,足以非常有用,可以用于将小字符串“打包”到多字节机器字(64 或 128 位)中。
-
最小化语言惩罚。拉丁字母语言在编码上并不比非拉丁语言更有效。实际上,大多数脚本在 Unicode 之前的“代码页”时代的编码中几乎与现在一样好。
-
最小的固定压缩开销。压缩从第二个字符开始,无需任何字典或编码元数据。
-
代码点顺序保持不变。您可以比较 BOCU-1 字符串,或者如果小字符串打包到整数中,则可以按整数比较它们,比较将遵循字符串的 Unicode 代码点字典顺序。这可能是这种形式的主要用途:您可以使用 BOCU-1 小字符串打包到整数中(如果您对代码点顺序感到满意)来构建一个非常快速的有序字典类型或数据库键范围。
-
在一定程度上(但不是完美地)与现有环境兼容:在行边界处自同步,避免损坏终端的 ASCII 控制字符,允许一些粗略的基于字节的单词和行断行等。
-
小型、简单、确定性的代码。每个输入只有一个表示形式。
当然,它有几个缺点,应该一开始就承认。
-
状态编码。就是如此。编码器状态经常重置,但是不从这个最近的重置点解码,就无法解码运行中的单个Unicode标量。这意味着类似memchr的字节串搜索多少受到了影响(尽管你可以搜索查询中第二及以后的字符的候选字符,然后完全解码并过滤这些候选字符,所以并不是完全无望)。
-
不如UTF-8 CPU效率高。它使用整数除法和取余操作,而不是仅仅使用位操作。
-
兼容性较差。它重用了许多可打印的ASCII码用于其他目的,并且除了C0控制字符(<= 0x20)外,不将ASCII空间中的大多数值编码为自身。
-
在美国曾获得专利(US专利号6737994,申请于2002年,2022年11月到期)。我实际上在发布它之前4年就写了这个crate,试图联系IBM以获取他们承诺的“免费许可”,他们将为此提供符合标准的实现,发现它在2011年卖给了谷歌,联系了他们,他们表示愿意将其包括在他们所谓的“开放专利非主张誓言”中,但他们停止回复邮件,线索中断,什么也没发生,所以我只是等待。现在专利已经过期,所以我想我已经没事了,但这也是为什么这个包使用MIT许可而不是MIT+ASL2的原因:我对ASL2专利条款在已获得专利的东西上的含义一无所知。
编码概述
BOCU-1由3部分组成
-
一个具有先前字符值的可控状态差分编码器,该值通过某些脚本和块特定的规则进行归一化。
-
对第1部分生成的差分进行变长编码(1..4个编码值),该编码同时保留词序和差分幅度。此编码分别处理前导和尾随值。
-
将第2部分中变长编码的每个尾随编码值映射到输出字节,使用一组小的范围偏移量,从而避免了用于常见ASCII控制码的字节,提供了同步字节,并允许编码点在0x20以下进行自编码。
现有文档和代码看起来复杂的原因之一是,这三个部分看起来非常交织(为了性能),但实际上它们几乎可以完全独立理解。因此,此crate组织为3个主要子模块(加上一些辅助模块),每个子模块对应这样一个部分,仅暴露它们之间需要共享的部分。
许可证:MIT
依赖关系
~255-360KB