دو کار مستقل پشت یک دکمه
«این فایلها را فشرده کن» اغلب دو چیز را همزمان میخواهد:
- چند فایل نامدار را در یک شیء بگذار که جابهجا کردن، پیوست کردن یا دانلود کردنش آسان باشد.
- بایتهای کمتری از آنچه فایلها جداگانه مصرف میکردند به کار ببر.
ZIP میتواند هر دو را انجام دهد، اما اولی به دومی وابسته نیست. قالب، مدخل فشردهنشده را روش ۰ مینامد. مدخل آشنای DEFLATE را روش ۸ مینامد. آرشیو با روش ۰ یک ZIP قلابی یا پوششی دور قالب دیگری نیست؛ همان رکوردهای مدخل و فهرست مرکزیِ یک ZIP فشرده را دارد، با بایتهای منبع که مستقیماً در ناحیهٔ داده قرار گرفتهاند.
این تمایز مهم است چون بسیاری از فایلهای امروزی کار دوم را از قبل خودشان انجام دادهاند. JPEG اطلاعات تصویر را با کدکی تخصصی و بااتلاف توصیف میکند. MP4 جریانهای صوتی و تصویری فشرده دارد. ZIP مدخلهای فشرده دارد. اجرای یک فشردهساز همهمنظوره روی آن بایتها مانند تلاش برای وکیوم کردن چیزی است که از قبل سفت است: کانتینر همچنان میتواند مفید باشد، اما شاید هوایی برای بیرون کشیدن نمانده باشد.
ذخیره همچنان چه چیزی به شما میدهد
فرض کنید مشتری سه عکس، یک PDF امضاشده و یک MP4 کوتاه لازم دارد. پنج پیوست جداگانه میتوانند گم شوند یا جداجدا دانلود شوند. یک ZIP یک نام بیرونی واحد را تثبیت میکند و پنج مرز و نام مدخل را کنار هم نگه میدارد. هر مدخل اندازه و CRC-32 خودش را دارد، و فهرست مرکزی به خواننده اجازه میدهد بدون حدس زدن اینکه از کجا شروع میشود، مدخلی را فهرست یا استخراج کند.
پس ذخیره حتی اگر شمار بایتها اندکی بالا برود ارزش واقعی دارد:
- یک بستهٔ خروجی به جای چند تا؛
- نامها و مرزهای مدخل پایدار؛
- فهرستی که نرمافزار آرشیو میتواند بازرسی کند؛
- یک مقدار تشخیص خطا برای هر مدخل استخراجشده؛
- بایتهای منبع عیناً، بدون هیچ تبدیل رسانهای.
هزینه، سربار ساختاری است. برای هر مدخل، ZIP یک سرآیند محلی نزدیک دادهاش و یک رکورد دیگر در فهرست مرکزی ثبت میکند. نام فایلها در هر دو جا ظاهر میشوند. نویسندههای جریانی میتوانند پس از مدخل یک توصیفگر داده هم اضافه کنند، چون CRC-32 و اندازهٔ فشرده هنگام نوشتن اولیهٔ سرآیند محلی معلوم نیست. یک رکورد پایانی فهرست را میبندد. بنابراین فایلهای کوچک میتوانند سربار درصدی بزرگی نشان دهند، هرچند افزایش مطلق فقط چند صد بایت باشد.
پیش از ادامهٔ مطلب
ده عکس JPEG جمعاً ۲۴ مگابایتاند. حالت ذخیره یک ZIP ۲۴٫۰۰۲ مگابایتی میسازد، در حالی که DEFLATE با سرعت کمتری یک ZIP ۲۴٫۰۰۶ مگابایتی میسازد. کدام نتیجه درست رفتار میکند؟
هر دو نتیجه معتبرند، و ذخیره برای این مجموعه انتخاب بهتری است. روش ۰ هر بایت JPEG را کپی میکند و ساختار ZIP را اضافه میکند، که افزایش کوچک ۲ کیلوبایتی را توضیح میدهد. روش ۸ سپس میکوشد بایتهای از پیش فشردهشدهٔ JPEG را با DEFLATE توصیف کند؛ اگر تکرار مفیدی پیدا نکند، بازنمایی بلوکیاش میتواند چند بایت دیگر اضافه کند، که افزایش ۶ کیلوبایتی و کار اضافی را توضیح میدهد. هدف این ZIP یک کانتینر است، نه یک گذر دوم فشردهسازی تصویر.
DEFLATE کجا جایگاهش را به دست میآورد
DEFLATE ارجاع به رشتههای تکراری را با کدهای فشرده برای نمادهای باقیمانده ترکیب میکند. وقتی منبع واژهها، کلیدها، جداکنندهها، تورفتگی، رکوردها یا دنبالههای بایتی بلند را تکرار میکند، خوب عمل میکند. فایلهای متنی، خروجیهای CSV، JSON، لاگها، کد منبع، XML و برخی قالبهای باینری فشردهنشده اغلب چنین شکلی دارند.
سطح فشردهسازی تغییر میدهد که کدگذار چقدر تلاش صرف یافتن توصیف بهتر میکند. تغییر نمیدهد که خواننده باید از چه چیزی پشتیبانی کند. یک جریان سطح ۱ و یک جریان سطح ۹ هر دو روش ۸ در ZIP هستند، و همان رمزگشای DEFLATE هر دو را باز میکند. پس تلاش بیشتر یک بدهبستان است نه ارتقای سازگاری: میتواند اندکی بیشتر صرفهجویی کند، بسیار بیشتر طول بکشد، یا روی ورودی ساده دقیقاً همان اندازه را تولید کند.
نام فایلها شاهدند، نه اثبات. فایل .txt احتمالاً فشردهشدنی است و .jpg احتمالاً نه، اما فایل متنیای که دادهٔ فشردهٔ base64 شده دارد ممکن است در برابر DEFLATE مقاومت کند، در حالی که یک PDF غیرمعمول با جریانهای فشردهنشدهٔ بزرگ ممکن است بهطور چشمگیری کوچک شود. اگر حجم انتقال مهم است، شمار بایت اندازهگیریشدهٔ آرشیو پاسخ است. اگر تأخیر مهمتر است، بر اساس قالب غالب انتخاب کنید و وقت صرف تعیین یک تفاوت دو کیلوبایتی نکنید.
چرا دو بار فشرده کردن معمولاً شکست میخورد
فشردهساز موفق ساختار پیشبینیپذیر را حذف میکند. خروجیاش قرار است شبیه دنبالهای باشد که بیتهای بعدیاش بدون رمزگشایی آنچه پیشتر آمده سخت پیشبینی میشوند. یک فشردهساز همهمنظورهٔ دیگر، رشتههای تکراری کمتر و بسامد نماد کمسوگیریتری از آنچه دادهٔ اصلی داشت میبیند.
به همین دلیل این انتخابهای آغازین معمولاً معقولاند:
| محتوای غالب | انتخاب اول | دلیل |
|---|---|---|
| JPEG، PNG، WebP، AVIF | ذخیره | کدک تصویر از قبل اطلاعات پیکسل را فشرده کرده است |
| MP3، AAC، MP4، WebM | ذخیره | جریانهای رسانه از قبل کدکهای تخصصی به کار میبرند |
| ZIP، gzip، 7z | ذخیره | محتوا از قبل یک آرشیو یا جریان فشرده است |
| PDF ترکیبی امروزی | ذخیره، سپس اگر حجم مهم است اندازه بگیرید | تصاویر، فونتها و جریانهای صفحه ممکن است از قبل فشرده باشند |
| TXT، CSV، JSON، XML، کد منبع | DEFLATE متعادل | متن و ساختار تکراری معمولاً خوب فشرده میشود |
| دامپهای خام یا بیتمپهای فشردهنشده | DEFLATE و اندازهگیری | تکرار به دادهٔ منبع بستگی دارد |
در هیچیک از دو ستون کیفیتی در خطر نیست. ذخیرهٔ ZIP بایتها را حفظ میکند، و DEFLATE بیاتلاف است. حالت شکست یک گذر فشردهسازی دوم، وقت تلفشده یا بازنمایی اندکی بزرگتر است، نه عکسی خرابشده.
CRC-32 به پرسشی کوچکتر از SHA-256 پاسخ میدهد
ZIP برای هر مدخل یک CRC-32 ذخیره میکند. وقتی نرمافزار فایلی را استخراج میکند، CRC-32 بایتهای بازسازیشده را محاسبه میکند و با مقدار ثبتشده مقایسه میکند. این خرابیهای اتفاقی رایج را میگیرد: بعید است دانلود آسیبدیده، حافظهٔ معیوب یا کپی ناقص از سر تصادف همان مقدار را تولید کند.
اما مدخل را احراز اصالت نمیکند. CRC-32 برای مقاومت در برابر کسی که تغییرات را عمداً انتخاب میکند طراحی نشده، و کسی که بتواند بایتها را جایگزین کند میتواند CRC-32 ثبتشده را هم جایگزین کند. دربارهٔ اینکه چه کسی ZIP بیرونی را داده هم چیزی نمیگوید.
چکسام SHA-256 نقش دیگری دارد. اگر دو طرف چکیدهای مورد اعتماد را از کانالی مستقل از فایل به دست آورند، میتوانند آزمایش کنند که آیا کل ZIPهایشان بایتبهبایت یکسان است. حتی این هم نویسنده را مشخص نمیکند مگر آنکه خود چکیده احراز اصالت شده باشد. امضای دیجیتال بایتها را به یک کلید گره میزند؛ رمزنگاری احراز اصالتشده میتواند محرمانگی و یکپارچگی بیفزاید. ذخیرهٔ سادهٔ ZIP و DEFLATE هیچیک از این دو را انجام نمیدهند.
یک توالی انتخاب عملی
- تصمیم بگیرید هدف اصلی یک کانتینر است، بایت کمتر، یا هر دو.
- به دادهٔ غالب نگاه کنید. برای رسانه و آرشیوهای از پیش فشردهشده ذخیره را انتخاب کنید؛ برای متن و دادهٔ ساختیافته DEFLATE متعادل را.
- ZIP را بسازید و شمار بایت گزارششدهاش را با جمع منبع مقایسه کنید.
- اگر آرشیو ترکیبی آنقدر بزرگ است که تفاوت اهمیت داشته باشد، حالت دیگر را یک بار امتحان کنید و برندهٔ اندازهگیریشده را نگه دارید.
- قبولی CRC-32 را اثبات منشأ نخوانید. وقتی تحویل یکسان مهم است، چکسامی را که از کانالی جداگانه مورد اعتماد است منتشر یا مقایسه کنید، و وقتی تهدید عمدی است از امضا یا برنامهٔ آرشیو رمزنگاریشده استفاده کنید.
مدل ذهنی مفید ساده است: ZIP جعبه است؛ ذخیره یا DEFLATE شیوهٔ قرار گرفتن هر قلم درون آن. یک جعبهٔ خوب میتواند ارزشمند باشد حتی وقتی هیچ چیزی داخلش کوچکتر نمیشود.
پرسشهای رایج
چرا گذاشتن فایلهای JPEG در ZIP آنها را بزرگتر کرد؟
JPEG از قبل دادهٔ تصویر را فشرده میکند، پس DEFLATE معمولاً تکرار کافی برای جبران هزینهٔ بازنمایی خودش پیدا نمیکند. ZIP همچنین باید یک سرآیند محلی، نام فایل، CRC-32، اندازهها، رکورد فهرست مرکزی و رکورد پایانی اضافه کند، پس کانتینری که هیچ صرفهجویی فشردهسازیای ندارد به اندازهٔ سربار ساختاریاش بزرگتر است.
آیا ZIP ذخیرهشده هنوز یک فایل ZIP واقعی است؟
بله. ذخیره، روش فشردهسازی ۰ در ZIP است، نه نبودِ قالب. هر مدخل همچنان نام، اندازهها و CRC-32 دارد، و آرشیو همچنان فهرست مرکزیای دارد که خوانندههای معمولی ZIP میفهمند.
آیا DEFLATE کیفیت عکس یا ویدیو را کم میکند؟
نه. DEFLATE بیاتلاف است و استخراج، دقیقاً بایتهای مدخل را بازتولید میکند. ممکن است روی رسانهای که از قبل فشرده شده بیاثر باشد، اما آن رسانه را رمزگشایی یا دوباره کدگذاری نمیکند و بنابراین نمیتواند کیفیتش را پایین بیاورد.
آیا CRC-32 میتواند بگوید ZIP از طرف شخص درستی آمده است؟
نه. برای تشخیص تغییرات اتفاقی طراحی شده، و کسی که مدخلی را ویرایش میکند میتواند CRC-32 منطبق را محاسبه کند. برای شواهد قویتر منشأ، به چکیدهای که از کانالی جداگانه و مورد اعتماد به دست آمده یا به یک امضای دیجیتال تأییدشده نیاز است.