使用 2016-W4 pdf，它有 2 个大流(第 1 和 2 页)，以及一堆其他对象和较小的流。我正在尝试缩小流，以处理源数据，但我很挣扎。我只能得到损坏的输入和无效的校验和错误。

我已经编写了一个测试脚本来帮助调试，并从文件中提取了较小的流来进行测试。

这是来自原始 pdf 的 2 个流，以及它们的长度对象:

流 1:

149 0 obj
<< /Length 150 0 R /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType
1 /BBox [0 0 8 8] /Resources 151 0 R >>
stream
x+TT(T0�B ,JUWÈS0Ð37±402V(NFJS�þ¶
«
endstream
endobj
150 0 obj
42
endobj

流 2

142 0 obj
<< /Length 143 0 R /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType
1 /BBox [0 0 0 0] /Resources 144 0 R >>
stream
x+T�ç�ã
endstream
endobj
143 0 obj
11
endobj

我只将 stream 内容复制到 Vim 中的新文件中(不包括 stream 之后和 endstream 之前的回车符).

我都试过了:

• compress/flate ( rfc-1951 ) –(删除前 2 个字节(CMF、FLG))
• compress/zlib ( rfc-1950 )

我已将以下流转换为 []byte:

package main

import (
    "bytes"
    "compress/flate"
    "compress/gzip"
    "compress/zlib"
    "fmt"
    "io"
    "os"
)

var (
    flateReaderFn = func(r io.Reader) (io.ReadCloser, error) { return flate.NewReader(r), nil }
    zlibReaderFn  = func(r io.Reader) (io.ReadCloser, error) { return zlib.NewReader(r) }
)

func deflate(b []byte, skip, length int, newReader func(io.Reader) (io.ReadCloser, error)) {
    // rfc-1950
    // --------
    //   First 2 bytes
    //   [120, 1] - CMF, FLG
    //
    //   CMF: 120
    //     0111 1000
    //     ↑    ↑
    //     |    CM(8) = deflate compression method
    //     CINFO(7)   = 32k LZ77 window size
    //
    //   FLG: 1
    //     0001 ← FCHECK
    //            (CMF*256 + FLG) % 31 == 0
    //             120 * 256 + 1 = 30721
    //                             30721 % 31 == 0

    stream := bytes.NewReader(b[skip:length])
    r, err := newReader(stream)
    if err != nil {
        fmt.Println("\nfailed to create reader,", err)
        return
    }

    n, err := io.Copy(os.Stdout, r)
    if err != nil {
        if n > 0 {
            fmt.Print("\n")
        }
        fmt.Println("\nfailed to write contents from reader,", err)
        return
    }
    fmt.Printf("%d bytes written\n", n)
    r.Close()
}

func main() {
    //readerFn, skip := flateReaderFn, 2 // compress/flate RFC-1951, ignore first 2 bytes
    readerFn, skip := zlibReaderFn, 0 // compress/zlib RFC-1950, ignore nothing

    //                                                                                                ⤹ This is where the error occurs: `flate: corrupt input before offset 19`.
    stream1 := []byte{120, 1, 43, 84, 8, 84, 40, 84, 48, 0, 66, 11, 32, 44, 74, 85, 8, 87, 195, 136, 83, 48, 195, 144, 51, 55, 194, 177, 52, 48, 50, 86, 40, 78, 70, 194, 150, 74, 83, 8, 4, 0, 195, 190, 194, 182, 10, 194, 171, 10}
    stream2 := []byte{120, 1, 43, 84, 8, 4, 0, 1, 195, 167, 0, 195, 163, 10}

    fmt.Println("----------------------------------------\nStream 1:")
    deflate(stream1, skip, 42, readerFn) // flate: corrupt input before offset 19

    fmt.Println("----------------------------------------\nStream 2:")
    deflate(stream2, skip, 11, readerFn) // invalid checksum
}

我确定我在某处做错了什么，只是我不太清楚。

(pdf 确实会在查看器中打开)

最佳答案

二进制数据不应该永远从文本编辑器中复制/保存。在某些情况下，这可能会成功，而且只是火上浇油。

您最终从 PDF 中“挖出”的数据很可能与 PDF 中的实际数据不同。您应该从十六进制编辑器中获取数据(例如，尝试使用 hecate 来获取新内容)，或者编写一个简单的应用程序来保存它(严格将文件作为二进制文件处理)。

提示#1:

显示的二进制数据分布在多行中。二进制数据不包含回车符，这是一个文本控件。如果是，那意味着编辑器确实将其解释为文本，因此一些代码/字符“被消耗”以开始新行。多个序列可能被解释为相同的换行符(例如 \n、\r\n)。通过排除它们，您已经处于数据丢失状态，通过包括它们，您可能已经有了不同的序列。并且如果将数据解释并显示为文本，则可能会出现更多问题，因为控制字符更多，并且某些字符在显示时可能不会出现。

提示#2:

当使用 flateReaderFn 时，解码第二个示例成功(完成且没有错误)。这意味着“你找对了树”，但成功与否取决于实际数据是什么以及它被文本编辑器“扭曲”到什么程度。

关于pdf - 如何解压缩/缩小 PDF 流，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42355485/