☰

为什么大多数文件（例如 jpeg 或 pdf）不只使用 ASCII 字符进行编码？

tag-icon • tag-icon encoding
为什么大多数文件（例如 jpeg 或 pdf）不只使用 ASCII 字符进行编码？

每当我们尝试使用任何文本编辑器打开 JPEG 或 PDF 文件时，我们都会发现除 ASCII 之外的奇怪符号。ASCII 不是最高效的吗？因为可用的字符数量有限，占用的空间更少。

在终端中打开的文件

我正在使用 plocate 在 Linux 中处理数据库文件，发现了类似的情况。

答案1

Ascii 不是最高效的吗？因为可用的字符数量有限，占用的空间更少。

一点也不。你从哪里得到这个想法的？

ASCII 字符长度为 7 位，但硬件不支持存储 7 位项，因此 ASCII 以 8 位存储，第一位始终为 0。此外，ASCII 包含许多控制字符，在某些情况下可能会导致问题。因此，最突出的 ASCII 编码（base 64）仅使用 6 位。这意味着为了编码 3 个字节（38 = 24 位）的数据，您需要 4 个 ASCII 字符（46 = 24）。然后使用 4 个字节将这 4 个 ASCII 字符存储在磁盘上。因此，将文件转换为 ASCII 会使磁盘使用率增加 33%。

您可以使用以下base64命令进行测试：

base64 pic.jpg > b64_jpeg.txt
ls -lh pic.jpg b64_jpeg.txt

当然，您可以尝试使用标准 base64 以外的其他 ASCII 编码，并使用 ASCII 中可用的所有 7 位。磁盘上每字节仍将只有 7 位数据，因此相同数据的磁盘使用率将增加 14%。

答案2

所有现代存储都使用 8 位字节。ASCII 是过时的 7 位标准，因此它将占用 8/7 的存储空间（+14%）。

答案3

这与位数无关，所有二进制文件都是相同的 2 位（真或假），图像或 PDF 与 Ascii 文本的不同之处在于，每个字节的位都按组压缩，以实现最佳效率。这些符号字符串可能是 ASCII，但压缩率约为 10%。

以如下方式获取图表的 pdf

  • ASCII = 394,132 字节
  • ZIP = 88,367 字节
  • PDF = 75,753 字节
  • DocX = 32,940 字节，包括文本和行（无图像）

拍摄图像

  • PNG = 265,490 字节
  • ZIP = 265,028 字节
  • PDF = 220,152 字节
  • PDF 为 ASCII = 3,250,970 字节
3 0 obj
<</Length 3120001/Type/XObject/Subtype/Image/Width 640/Height 800/BitsPerComponent 8/SMask 4 0 R/ColorSpace/DeviceRGB/Filter/ASCIIHexDecode>>
stream
9cb6c79cb6c79cb6c79cb6c79db7c89db7c89db7c89fb7c9a0b8caa1b8caa1b8
caa1b8caa2b9cba2b9cba2b9cba2b9cba3bacba3bacaa4bbcba4bbcba6bccca7
...to infinity and beyond

那么为什么 ASCII 图像比其他所有图像都大，是因为它们9cb6c7可以被标记为 4 x 9cb6c7、3 x9db7c8等，这大致就是 RunLengthEncoding 的工作方式，但 zip 比这更好。

因此，pdf 的部分内容可能会以 zip 编码风格（用于无损字体和位图）进行压缩（需要较慢的解压速度才能查看），而其他部分可能会保留其最佳的原生摄影有损压缩（如 jpeg）。总体而言，对于 PDF 解析，更高百分比需要为 8 位 ANSI（兼容单编码或每个平台变量）或 7 位 ASCII 进行简单解析。

简短答案压缩是减少传输时间或存储资源量的手段。但是解压缩会增加开销，因此比 RAW ASCII 更慢地显示为图形。避免在大多数对象需要快速解压缩的 PDF 中使用奇异小波。

相关内容