Các tùy chọn chiến lược được đề cập trong Java Deflater bắt nguồn từ việc triển khai zlib (C) của ZLIB và (RFC 1950) và DEFLATE (1951), tôi tin. Chúng có mặt trong hầu như tất cả các thư viện nén thực hiện DEFLATE.
Để hiểu ý nghĩa của chúng, bạn cần biết một chút về DEFLATE. Thuật toán nén kết hợp mã hóa LZ77 và Huffman. Thông tin cơ bản là:
Nén LZ77 hoạt động bằng cách tìm chuỗi dữ liệu được lặp lại. Triển khai thường sử dụng "cửa sổ trượt" từ 1k đến 32k, để theo dõi dữ liệu đã đi trước đó. Đối với bất kỳ lặp lại nào trong dữ liệu gốc, thay vì chèn dữ liệu lặp lại vào đầu ra, nén LZ77 chèn một "tham chiếu ngược". Hãy tưởng tượng tham chiếu ngược lại nói "ở đây, chèn cùng một dữ liệu bạn đã xem 8293 byte trước đây, cho 17 byte". Back-ref được mã hóa dưới dạng cặp số này: chiều dài - trong trường hợp này là 17 - và khoảng cách (hoặc offset) - trong trường hợp này là 8293.
Thay thế mã Huffman mã hóa dữ liệu thực tế. Khi dữ liệu nói X, mã Huffman nói Y. Điều này rõ ràng chỉ giúp nén nếu thay thế ngắn hơn bản gốc. (ví dụ ngược lại là trong phim Jim Carrey Yes Man, khi Norm sử dụng "Xe hơi" cho một tên ngắn cho Carl. Carl chỉ ra rằng Carl đã khá ngắn.) Thuật toán mã hóa Huffman phân tích tần số và sử dụng các sản phẩm thay thế ngắn nhất cho các chuỗi dữ liệu xảy ra thường xuyên nhất.
Deflate kết hợp này, do đó người ta có thể sử dụng mã Huffman trên LZ77 back-refs. Các tùy chọn chiến lược trên các máy nén DEFLATE/ZLIB khác nhau chỉ cho thư viện biết trọng lượng của Huffman so với LZ77.
FILTERED thường có nghĩa là các trận đấu LZ77 đang dừng lại ở một chiều dài 5. Vì vậy, khi các tài liệu nói
sử dụng (lọc) cho dữ liệu được tạo ra bởi một bộ lọc (hoặc dự đoán), ... Dữ liệu được lọc bao gồm hầu hết các giá trị nhỏ với phân phối hơi ngẫu nhiên.
(từ the zlib man page)
... đọc sách của tôi của mã nói rằng nó LZ77 phù hợp, nhưng chỉ lên đến chuỗi 5 hoặc ít byte. Đó là những gì doc có nghĩa là "giá trị nhỏ" tôi đoán.Nhưng số 5 không được đề cập trong tài liệu, vì vậy không có gì đảm bảo rằng số sẽ không bị thay đổi từ rev thành rev, hoặc từ việc thực hiện ZLIB/DEFLATE sang số khác (như phiên bản C và phiên bản Java).
HUFFMAN_ONLY cho biết, chỉ thực hiện các mã thay thế dựa trên phân tích tần suất. HUFFMAN_ONLY rất nhanh, nhưng không hiệu quả trong nén đối với hầu hết dữ liệu. Trừ khi bạn có một phạm vi rất nhỏ các giá trị byte (ví dụ: nếu các byte trong luồng dữ liệu thực tế của bạn lấy một trong số 20 giá trị 255 có thể) hoặc có yêu cầu khắc nghiệt về tốc độ nén với chi phí là HUFFMAN_ONLY sẽ không bạn muốn gì.
DEFAULT kết hợp cả hai cách mà tác giả mong đợi sẽ hiệu quả nhất cho hầu hết các ứng dụng.
Theo như tôi biết, trong vòng Deflate không có cách nào để làm chỉ LZ77. Không có chiến lược LZ77_ONLY. Nhưng tất nhiên bạn có thể xây dựng hoặc mua bộ mã hóa LZ77 của riêng mình và đó sẽ là "LZ77".
Hãy nhớ rằng chiến lược không bao giờ ảnh hưởng đến tính chính xác của nén; nó chỉ ảnh hưởng và hoạt động của nó, và hiệu suất của nó, dù là về tốc độ hay kích thước.
Có nhiều cách khác để tinh chỉnh máy nén. Một là đặt kích thước của cửa sổ trượt LZ77. Trong thư viện C, điều này được xác định với tùy chọn "Window bits". Nếu bạn hiểu LZ77, sau đó bạn biết rằng một cửa sổ nhỏ hơn có nghĩa là ít tìm kiếm trở lại, có nghĩa là nén nhanh hơn, với chi phí thiếu một số kết quả phù hợp. Đây thường là nút hiệu quả hơn để bật khi nén.
Điểm mấu chốt là, đối với trường hợp 80%, bạn không quan tâm đến tinh chỉnh chiến lược. Bạn có thể quan tâm đến việc không quan tâm đến các bit cửa sổ, chỉ để xem điều gì xảy ra. Nhưng chỉ làm điều đó khi bạn đã làm mọi thứ khác mà bạn cần làm trong ứng dụng của mình.
tham khảo:
How DEFLATE works, by Antaeus Feldspar