使用整个unicode库进行LZW压缩

我正试图解决这个问题：

假设我们有整个Unicode字符集的初始字母表， 而不仅仅是所有可能的字节值。还记得unicode吗 字符是无符号的2字节值，因此这意味着 2字节的未压缩数据将被视为一个符号，并且 我们将有一个超过60000个符号的字母表。（将符号视为 2字节的Unicode，而不是一次一个字节，更适合 在国际化文本的情况下进行压缩。）并且，注意，还有 没有将每个代码的位数限制为最多16位的内容。像你一样 对这个非常大的字母表推广LZW算法，不用担心 如果你有很长的代码

用这个，给出这个四符号序列的压缩版本， 使用我们的项目假设，包括EOD代码和分组 转换为4字节整数。（这三个符号是Unicode值， 用数字表示。）将答案写成3个8位十六进制值， 空格分隔，使用大写十六进制数字，而不是小写

32767 32768 32767 32768

我遇到的问题是，我不知道字母表的整个范围，所以在进行LZW压缩时，我不知道新代码将具有什么字节值。由于这个问题，我也不知道EOD代码会是什么样子

---

而且，在我看来，压缩数据只需要两个整数。

问题陈述的格式不正确

在Unicode中，正如我们今天所知，代码点（那些表示字符、字符的可组合部分和其他有用但更隐蔽的东西的数字）不能全部从0到65535进行编号，以适合16位。Unicode中有超过10万个中文、日文和韩文字符。很明显，你需要17+位才行。因此，Unicode显然不是正确的选择

此外，还存在一种Unicode的“简化”版本，其UCS-2编码使用16位代码点，从技术上讲最多可用于65536个字符等。代码大于65535的字符是不吉利的，UCS-2不能使用它们

---

因此，如果它真的是UCS-2，你可以下载它的规范（我相信是ISO/IEC 10646），并准确地找出使用了这些64K中的哪些代码，从而形成你最初的LZW字母表。

问题一开始就错了——它是在20世纪90年代写的吗？Unicode代码点不能用2字节表示；它们需要21位（或某种曲张编码）。我很难理解实际问题是什么。用UTF-8这样的实际文本编码保存文本，然后在字节上使用LZW似乎更符合逻辑：P