【发布时间】:2014-09-30 15:55:21
【问题描述】:
我正在实现我自己的河豚编码器/解码器版本。如有必要,我使用 0x80 的标准填充。
我的问题是我是否需要添加一个填充字符,即使我不需要它,因为对于一个自然以 0x80 结尾的文件,在 deconding 部分我将删除这个字符,但在这种情况下这是一个错误的操作,因为 te 0x80 是文件本身的一部分。
这当然可以通过添加最终字符来解决,即使字符总数是编码块的倍数(本例中为 64 位)。我可以实施这个对策,但首先我想知道我是否真的需要它。
自然的后果是考虑是否选择这种类型的字符,因为文件中从未发生过(因此上述错误情况永远不会发生),但我完全不确定。
谢谢!很抱歉这个愚蠢的问题..
【问题讨论】:
-
您的问题可能与操作系统(和文件系统)有关。在 Linux 和大多数其他 Posix 操作系统(及其本机文件系统)上,文件可以包含任意字节的任意序列。所以它可以以
0x80结尾 -
填充是输入/输出数据格式的一部分。作为您提供给解码器的数据的一部分或从编码器输出的数据与可能也在同一文件中的其他数据之间不能有任何混淆(这就是使用填充的原因之一 - 例如每个块的长度可以是已知的。)
-
这个问题不是特定于操作系统的,至少关于文件中可以出现哪些字节。二进制文件(并且您总是希望使用二进制文件)可以包含任何字节。不符合 POSIX 的操作系统可能会用零字节填充二进制文件的末尾,这会使问题变得不简单,但不能禁止 0x80。
-
您可以手动添加填充;如果文件以
0x80字符结尾,则用其他字符填充。如果不需要填充,请添加一个填充有您选择的填充字符的块。这样,最后一个字符会告诉您选择的填充字符。因此,要取消填充,请读取最后一个字符(当然是从解密的内容中)并修剪这些字符。这样,您将永远不会修剪已成为原始内容一部分的字符。 编辑:哦,我刚刚看到你有这个想法。但如果文件以0x80结尾,请确保选择不同的字符。 -
谢谢大家。我看看添加最后 8 个字节是否会在我的算法同步中造成一些灾难。当然,填充仍然可以是 0x80,因为当我检查它时,我会在第一次出现这个字符时停止。