فشرده سازی فایل چیست
فشرده سازی یعنی نوشتن همان اطلاعات با بایت کمتر. دو خانواده دارد: بی اتلاف، مثل ZIP و RAR، که فایل اصلی را مو به مو برمی گرداند، و با اتلاف، مثل چیزی که در عکس و صدا و ویدیو اتفاق می افتد، که بخشی از جزئیات را برای همیشه دور می ریزد تا خیلی کوچک تر شود.
- درس ۷ از ۱۲
- مقدماتی
- رایگان، بدون ثبت نام
زیاد وارد می شود، کم عبور می کند، همان بیرون می آید
آنچه می گذارید داخلش
- پوشه سندها
- صفحه گسترده و کد
- متن، پر از تکرار
آنچه بیرون می آید
- همان سندها
- همان صفحه گسترده و کد
- همان متن، بدون یک حرف کم
این شکل فقط فشرده سازی بی اتلاف را توصیف می کند. در فشرده سازی با اتلاف، آنچه پایین بیرون می آید دیگر مو به مو همان بالایی نیست.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
فشرده سازی دقیقا چه کار می کند
فشرده سازی یعنی همان محتوا را با بایت کمتر نوشتن، با پیدا کردن تکرار. ایده اش ساده تر از چیزی است که به نظر می رسد. اگر یک متن سی بار کلمه «سلام» داشته باشد، به جای سی بار نوشتنش، یک بار می نویسید و بیست و نه بار به آن اشاره می کنید. برنامه ای که فایل را باز می کند، از روی همان اشاره ها متن اصلی را دوباره می سازد.
پس هر چه فایل تکرار بیشتری داشته باشد، بیشتر جمع می شود. متن پر از تکرار است و بیشترین سود را می برد.
یک نمونه از همین سایت: فایل استایل قالب rgb.ir در حالت عادی ۱۲۹ کیلوبایت است. همان فایل با gzip می شود ۳۲ کیلوبایت. یعنی حدود یک چهارم، و بدون اینکه حتی یک حرف از آن کم شود.

بی اتلاف یا با اتلاف؛ تفاوتی که همه چیز را تعیین می کند
این تنها تقسیمی است که در فشرده سازی واقعا مهم است و بقیه چیزها جزئیات آن هستند.
فشرده سازی بی اتلاف قول می دهد فایلی که بیرون می آید مو به مو همان فایلی باشد که رفت. ZIP و RAR و 7z و gzip همه از این خانواده اند. برای سند و کد و صفحه گسترده و هر چیزی که یک بایتش هم مهم است، فقط همین خانواده قابل استفاده است.
فشرده سازی با اتلاف قول دیگری می دهد: خیلی کوچک تر می کنم، به شرطی که اجازه بدهی چیزهایی را دور بریزم که چشم و گوش آدم معمولا متوجهشان نمی شود. عکس JPEG، آهنگ MP3 و ویدیوی MP4 همه محصول همین معامله اند. آنچه دور ریخته شده برنمی گردد. باز کردن دوباره فایل، جزئیات از دست رفته را احیا نمی کند، چون دیگر داخل فایل نیست.
راه ساده ای برای دیدن این تفاوت هست. یک فایل را با gzip فشرده کردیم و دوباره باز کردیم، و اثر انگشت رقمی هر دو نسخه دقیقا یکی بود؛ همان چیزی که در درس نصب امن نرم افزار به آن چک سام می گوییم. هیچ فایل با اتلافی این آزمون را پاس نمی کند و قرار هم نیست پاس کند.
دو خانواده، دو کار متفاوت
بی اتلاف؛ ZIP و RAR و gzip
- فایل مو به مو برمی گردد.
- برای سند و کد و صفحه گسترده.
- روی متن بیشترین سود را می دهد.
- روی فایل از قبل فشرده تقریبا هیچ.
با اتلاف؛ JPEG و MP3 و MP4
- جزئیات دور ریخته برنمی گردد.
- برای عکس و صدا و ویدیو.
- چند برابر کوچک تر از بی اتلاف.
- هر بار ذخیره دوباره، خرابی تازه.
هیچ کدام بهتر از دیگری نیست. انتخاب اشتباه وقتی است که سند را با اتلاف و عکس صفحه وب را بی اتلاف ذخیره کنید.
چرا زیپ کردن پوشه عکس ها حجم را کم نمی کند
این سوالی است که هر کسی یک بار از خودش پرسیده و جوابش یک جمله است: چون آن فایل ها از قبل فشرده اند. عکس JPEG یا WebP، آهنگ MP3 و ویدیوی MP4 همگی محصول یک فشرده سازی سنگین اند و تکراری در آن ها باقی نمانده که ZIP بتواند پیدا کند.
روی همین سرور امتحانش کردیم. یک تصویر WebP از کتابخانه رسانه سایت، ۵۴۹ کیلوبایت. با gzip در بالاترین درجه فشرده اش کردیم و نتیجه ۱۱۵ بایت بزرگ تر از فایل اصلی شد. بزرگ تر، نه کوچک تر. دلیلش هم منطقی است: چیزی برای جمع کردن نمانده بود و هر فایل فشرده چند بایت اطلاعات سرآیند دارد که به آن اضافه می شود.
پس زیپ کردن یک پوشه عکس بی فایده نیست، فقط فایده اش چیز دیگری است. ده ها فایل را به یک فایل تبدیل می کند که فرستادنش راحت تر است و در راه کم و کسر پیدا نمی کند. اگر هدفتان کم کردن حجم است، باید سراغ خود عکس ها بروید، نه سراغ بسته بندی شان. آن کار موضوع درس فرمت های تصویر است.
با اتلاف یعنی چقدر کوچک تر
عدد گفتن اینجا بی معنی است مگر روی یک تصویر مشخص، پس یک تصویر واقعی از کتابخانه رسانه همین سایت را برداشتیم، با ابعاد ۲۵۴۴ در ۱۹۰۴ پیکسل، و چند بار با تنظیمات مختلف ذخیره اش کردیم.
به شکل PNG، که بی اتلاف است، ۷۰۲۱ کیلوبایت شد؛ یعنی حدود هفت مگابایت برای یک تصویر. همان تصویر به شکل JPEG با کیفیت ۹۰ برابر ۱۳۸۸ کیلوبایت شد، با کیفیت ۶۰ برابر ۵۵۴ کیلوبایت، و با کیفیت ۳۰ برابر ۳۱۹ کیلوبایت.
دو چیز در این ردیف عددها دیدنی است. اول اینکه پرش بزرگ بین بی اتلاف و با اتلاف اتفاق می افتد، نه بین کیفیت ۹۰ و کیفیت ۳۰. دوم اینکه پایین آوردن کیفیت از ۶۰ به ۳۰ فقط حدود دویست کیلوبایت می برد و در عوض خرابی را روی لبه ها آشکار می کند. برای همین است که در عمل معمولا جایی بین شصت و هشتاد می ایستیم و پایین تر نمی رویم.
و یک نکته که آموزش ها کم می گویند: کیفیت را فقط یک بار پایین بیاورید. هر بار که یک فایل با اتلاف را باز و دوباره ذخیره کنید، خرابی جدیدی روی خرابی قبلی سوار می شود. نسخه اصلی و بی اتلاف را جایی نگه دارید و همیشه از روی همان خروجی بگیرید.
رمز روی فایل فشرده؛ هم ابزار، هم حقه
تقریبا هر برنامه فشرده سازی می تواند روی بایگانی رمز بگذارد. کار مفیدی است. اگر مجبورید چند فایل حساس را با ایمیل بفرستید، یک بایگانی رمزدار بهتر از فرستادن فایل ها به شکل ساده است، به شرطی که رمز از راه دیگری برسد؛ مثلا تلفنی.
حالا روی دیگر سکه. همان ویژگی، سال هاست یکی از راه های رساندن بدافزار است و دلیلش خیلی فنی نیست. سامانه ای که ضمیمه های ایمیل را بررسی می کند، نمی تواند داخل یک بایگانی رمزدار را ببیند. مستندات خود مایکروسافت برای Defender for Office 365 همین را می نویسد: ضمیمه رمزدار را نمی شود کامل بررسی یا اجرا کرد مگر آنکه رمزش در دسترس باشد، مثلا از متن همان ایمیل استخراج شود. برای همین سیاست پیشنهادی شان قرنطینه کردن چنین پیام هایی است.
پس فرستنده بدافزار رمز را داخل متن ایمیل می نویسد. برای شما هیچ زحمتی ندارد و برای بررسی کننده یک دیوار است.
قاعده ای که از این نتیجه می گیریم ساده است و بهتر است بدون استثنا رعایتش کنید: بایگانی رمزداری را که منتظرش نبوده اید باز نکنید، حتی اگر فرستنده آشنا به نظر برسد. آدرس فرستنده جعل می شود؛ یک تماس تلفنی جعل نمی شود.
فشرده سازی هایی که خودتان نمی بینید
بیشتر فشرده سازی که در زندگی روزمره از آن سود می برید، دست شما نیست و اصلا خبرش را ندارید. هر صفحه ای که در مرورگر باز می کنید، تقریبا همیشه فشرده از سرور می آید و مرورگر پیش از نمایش بازش می کند.
روی همین سایت می شود اندازه اش گرفت. لایه کش rgb.ir در لحظه نوشتن این درس ۳۱۱۱ صفحه آماده روی دیسک دارد. آن صفحه ها روی هم ۴۶۶ مگابایت HTML اند و روی دیسک ۱۰۱ مگابایت جا گرفته اند، یعنی حدود ۲۲ درصد. نکته جالب تر این است که یک نسخه فشرده نشده هم در آن پوشه نیست؛ فقط نسخه فشرده ذخیره می شود و همان مستقیم برای بازدیدکننده فرستاده می شود.
و این دقیقا چیزی است که در بحث سرعت سایت مهم می شود: همان محتوا، یک پنجم ترافیک. اگر این سمت ماجرا برایتان جالب است، مسیر سرعت سایت در همین بخش آموزش ادامه اش می دهد، و اگر سایتی دارید که کند است، صفحه افزایش سرعت سایت نشان می دهد این کار روی یک سایت واقعی چطور انجام می شود.
مسیر سریع با هوش مصنوعی
قبل از اینکه یک پوشه سنگین را زیپ کنید و امیدوار باشید کوچک شود، سی ثانیه وقت بگذارید و ببینید وزن واقعا کجاست. تقریبا همیشه چند فایل بزرگ اند و بقیه بی اهمیت، و تقریبا همیشه آن چند تا از خانواده ای اند که ZIP کمکشان نمی کند. یک دستور فهرست را می دهد و یک مدل زبانی سریع و ارزان از رده Flash فهرست را به تصمیم تبدیل می کند؛ انتخاب فعلی ما در بخش هوش مصنوعی همین سایت فهرست شده.
- بزرگ ترین فایل های پوشه را با اندازه شان فهرست کنید. سی ردیف اول تقریبا همیشه کل ماجراست.
- فهرست را به مدل بدهید و بگویید هر ردیف از قبل فشرده است یا نه، و کدام ها با زیپ کردن واقعا کوچک می شوند.
- اگر جواب این بود که وزن دست عکس و ویدیو است، زیپ را رها کنید و سراغ خود آن فایل ها بروید. زیپ کردنشان فقط بسته بندی است.
نسخه آماده کپی
گرفتن فهرست از پوشه:
find . -type f -printf '%s\t%p\n' | sort -rn | head -30
پرامپت، همراه با همان فهرست:
این سی فایل بزرگ یک پوشه است، ستون اول حجم به بایت.
برای هر ردیف بگو: از قبل فشرده است یا نه، و چرا.
بعد سه گروه بساز:
۱) زیپ کردنشان واقعا حجم کم می کند.
۲) از قبل فشرده اند؛ زیپ فقط بسته بندی است.
۳) وزن اصلی اینجاست و باید خودشان دوباره ذخیره شوند.
هدف من {مقصد: فرستادن با ایمیل / بایگانی بلندمدت / آپلود روی سایت} است.
عدد نساز؛ فقط از همین فهرست حرف بزن.
قبل از اعتماد به خروجی: مدل فقط نام و حجم فایل ها را می بیند، نه محتوایشان را. یک فایل با پسوند zip می تواند داخلش پر از عکس باشد و مدل خبر ندارد. پیش از پاک کردن هر نسخه اصلی، بایگانی را باز کنید و ببینید سالم است؛ و اگر قرار است چیزی برای بلندمدت بماند، دو نسخه در دو جای متفاوت نگه دارید. یک بایگانی خراب دقیقا وقتی خودش را نشان می دهد که به آن نیاز دارید.
هوش مصنوعی در این کار
فشرده سازی جایی نیست که مدل زبانی معجزه کند؛ خود کار را برنامه های معمولی انجام می دهند و رایگان اند. کاری که مدل واقعا خوب انجام می دهد این است: از فهرستی که خودتان از پوشه گرفته اید بگوید وزن کجاست و کدام تلاش بی نتیجه است. و یک کار هم هست که اصلا نباید به آن بسپارید، پایین آمده.
ابزارهایی که واقعا کمک می کنند
- Gemini برای پاس مکانیکی روی فهرست فایل ها، با مدل سریع و ارزانش. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
- Claude برای وقتی که می خواهید خود دستور را بفهمید و نه فقط اجرا کنید، چون توضیح می دهد و توضیحش قابل رد کردن است. ایران در هیچ یک از دو فهرست کشورهای پشتیبانی شده انتروپیک نیست و پرداخت رسمی از ایران انجام نمی شود.
- 7-Zip هوش مصنوعی نیست و عمدا اینجاست: کار اصلی این درس با یک برنامه رایگان انجام می شود و هیچ مدلی لازم ندارد. مدل تصمیم می گیرد، برنامه فشرده می کند.
- RGB لایه دسترسی و پرداخت برای ایران، جدا از خود ابزارها.
کجا نتیجه معکوس می دهد
ریسک این موضوع جای غیرمنتظره ای است: ابزارهای آنلاین «فشرده سازی رایگان». آدرسشان را جستجو می کنید، فایل را آپلود می کنید، نسخه کوچک شده را می گیرید. اما فایل شما رفته روی سروری که نمی شناسید، با سیاست نگهداری که نخوانده اید. برای عکس تعطیلات مهم نیست؛ برای قرارداد، فیش حقوقی و اسکن مدارک، فشرده سازی روی کامپیوتر خودتان با یک برنامه رایگان انجام می شود و هیچ دلیلی برای آپلود کردنش وجود ندارد. همین حرف درباره سپردن سند به یک چت بات هم صدق می کند: اینکه محتوا به آموزش مدل برود یا نه به پلن و تنظیمات همان سرویس بستگی دارد و خود شرکت ها نوشته اند، مثلا صفحه حریم خصوصی گوگل برای اپ های جمنای. ریسک دوم فنی تر است: مدل حجم فایل را حدس می زند و حدسش اغلب غلط است. هر عددی درباره اینکه فایل شما چقدر کوچک می شود، باید از خود اجرای فشرده سازی بیاید نه از یک مدل.
منبع ها: Google: Gemini Apps privacy Where you can use the Gemini web app Anthropic supported countries
حد این توصیه
عددهای این درس روی همین سرور و روی همان فایل هایی که نامشان آمده اندازه گیری شده اند و به فایل شما تعمیم پیدا نمی کنند. یک متن با تکرار زیاد بیشتر از یک چهارم جمع می شود و یک فایل پایگاه داده تقریبا هیچ. نکته دوم اینکه فشرده سازی جای بکاپ را نمی گیرد: یک بایگانی ZIP یک فایل است و اگر خراب شود ممکن است همه محتوایش را با خودش ببرد، در حالی که پوشه معمولی معمولا فقط همان فایل خراب را از دست می دهد. و رمز گذاشتن روی بایگانی، رمزگذاری واقعی سطح سازمانی نیست؛ برای جلوگیری از نگاه اتفاقی خوب است و نه بیشتر.
از تجربه خود ما
هر عددی که در این درس خواندید روی همین سرور در ۲۰۲۶-۰۹-۰۶ گرفته شده و قابل تکرار است. فایل استایل قالب سایت ۱۲۹ کیلوبایت است و با gzip در بالاترین درجه ۳۲ کیلوبایت می شود. یک تصویر WebP از کتابخانه رسانه، ۵۴۹ کیلوبایت، با همان gzip ۱۱۵ بایت بزرگ تر شد نه کوچک تر؛ و همان فایل بعد از رفت و برگشت gzip اثر انگشت sha256 دقیقا یکسانی داشت، که همان چیزی است که بی اتلاف بودن یعنی. جالب ترین بخش اما لایه کش خود سایت است: در آن لحظه ۳۱۱۱ فایل صفحه آماده روی دیسک بود و در آن پوشه حتی یک نسخه فشرده نشده وجود نداشت. یعنی هیچ صفحه ای دو بار ذخیره نمی شود؛ فقط نسخه gzip نوشته می شود و همان مستقیم توسط وب سرور فرستاده می شود. آن ۳۱۱۱ صفحه روی هم ۴۶۶ مگابایت HTML اند و ۱۰۱ مگابایت روی دیسک گرفته اند، یعنی ۲۱.۷۷ درصد.
سوال هایی که واقعا پرسیده می شوند
ZIP بهتر است یا RAR یا 7z؟
هر سه بی اتلاف اند و برای کار روزمره تفاوتشان کم است. ZIP این مزیت را دارد که ویندوز و مک و لینوکس بدون نصب چیزی بازش می کنند، پس برای فرستادن به دیگران انتخاب امن تری است. 7z معمولا کمی بیشتر جمع می کند و در عوض طرف مقابل باید برنامه اش را داشته باشد.
یک فایل را دو بار زیپ کنم کوچک تر می شود؟
نه، و معمولا کمی بزرگ تر می شود. بار اول تکرارها را برداشته و چیزی برای برداشتن باقی نمانده، اما هر بار بسته بندی چند بایت اطلاعات سرآیند اضافه می کند. همان اتفاقی که در این درس روی یک تصویر WebP دیدیم و ۱۱۵ بایت به فایل اضافه کرد.
فایل زیپ من خراب شده؛ کاری می شود کرد؟
گاهی بله. بعضی برنامه های فشرده سازی گزینه تعمیر بایگانی دارند و می توانند بخش سالم را بیرون بکشند، مخصوصا در فرمت RAR که اطلاعات بازیابی اختیاری دارد. اما جواب صادقانه این است که در بیشتر موارد بخش خراب از دست رفته است، و همین دلیل اصلی این است که بایگانی جای بکاپ را نمی گیرد.