Тар Vs Zip Vs Gz: Разлика и ефективност

Докато изтегляте файлове, не е необичайно да виждате разширенията .tar, .zip или .gz . Но знаете ли разликата между Tar и Zip и Gz? Защо ги използваме и кой е по-ефективен, tar или zip или gz?

Разлика между катран, цип и gz

Ако бързате или просто искате да запомните нещо лесно, ето разликата между zip и tar и gz:

.tar == некомпресиран архивен файл

.zip == (обикновено) компресиран архивен файл

.gz == файл (архив или не) компресиран с помощта на gzip

Малко история от архивните файлове

Както много неща за Unix и Unix-подобни системи, историята започва много отдавна, в една не толкова далечна галактика, наречена седемдесетте. През студеното утро на януари 1979 г. полезността на tar се появи като част от новоиздадения Unix V7.

Помощната програма tar е проектирана като начин за ефективно записване на много файлове на ленти. Дори и сега, когато днешните лентови устройства са неизвестни на по-голямата част от отделните потребители на Linux, tarballs - псевдонимът на tar архивите - все още се използват често за пакетиране на няколко файла или дори цялото дърво на директориите (или дори горите) в един файл.

Едно от ключовите неща, които трябва да запомните, е обикновен tar файл, който е само архив, чиито данни не са компресирани. С други думи, ако качите 100 файла от 50kB, ще получите архив, чийто размер ще бъде около 5000kB. Единствената печалба, която можете да очаквате от самото използване на tar, би била да се избегне пропуснатото от файловата система пространство, тъй като повечето от тях разпределят пространство при някаква степенност (например, в моята система един байт дълъг файл използва 4kB дисково пространство, 1000 от те ще използват 4MB, но съответният tar архив „само“ 1MB).

Заслужава да се спомене, че tar не е единственият стандартен Unix инструмент за създаване на архиви. Програмистите вероятно знаят ar, тъй като се използва най-вече днес за създаване на статични библиотеки, които не са нищо повече от архиви на компилирани файлове. Но може да се използва за създаване на архиви от всякакъв вид. Файловете .deb пакети, използвани в системите на Дебиан, всъщност са архиви! А на MacOS X, mpkg пакети са (бяха?) Gzip-компресирани cpio архиви. Това, което е казано, нито arp, нито cpio са придобили толкова много, колкото популярността като tar . Може би защото командата tar е достатъчно добра и по-проста.

Не от вида катран, който търсите

Създаването на архиви е хубаво. Но с течение на времето и с настъпването на ерата на персоналните компютри хората осъзнаха, че могат да направят огромни спестявания при съхранението чрез компресиране на данни. Така десетилетие след въвеждането или tar, zip излезе в света на MS-DOS като архивен формат, поддържащ компресията . Най-често използваната схема за компресиране на zip е дефлацията, която сама по себе си е реализация на алгоритъма LZ77. Но ако бъде разработен от PKWARE, форматът zi p е страдал от затруднения с патентите от години.

Ето защо, успоредно, беше създаден gzip за прилагане на алгоритъма LZ77 в свободен софтуер, без да се нарушава патент на PKWARE.

Ключов елемент от философията на Unix е „Да направим едно нещо и да го направим добре“, gzip е създаден само за компресиране на файлове. Така че, за да създадете компресиран архив, първо трябва да създадете архив, използвайки например полезността на tar . И след това ще компресирате този архив. Това е .tar.gz файл (понякога съкратен като .tgz, за да се добави отново към това объркване - и да се съобразят с отдавна забравените ограничения на името на файла MS-DOS 8.3).

С развитието на компютърните науки бяха разработени и други алгоритми за компресия за по-висока степен на компресия. Например алгоритъмът Burrows – Wheeler, реализиран в bzip2 (водещ към архивите .tar.bz2 ). Или по-скоро xz, който е LZMA алгоритъм изпълнение подобно на това, използвано в 7zip полезност.

Наличност и ограничения

Днес можете свободно да използвате всеки архивен файлов формат както на Linux, така и на Windows.

Но тъй като zip форматът се поддържа от Windows, това е особено присъщо в средите с различни платформи. Можете дори да намерите формата на zip файл в неочаквани места. Например, този файлов формат е запазен от Sun за архивите на JAR, използвани за разпространение на компилирани Java приложения. Или за файловете с OpenDocument ( .odf, .odp ...), използвани от LibreOffice или други офис комплекти. Всички тези формати на файлове са маскирани архиви. Ако сте любопитни, не се колебайте да разархивирате един от тях, за да видите какво има вътре:

 sh $ unzip some-file.odt Архив: some-file.odt извличане: mimetype inflating: meta.xml inflating: settings.xml inflating: content.xm [...] inflating: styles.xml inflating: META-INF / манифест .xml 

Всичко това, казано в Unix-подобен свят, все още бих предпочел тип архивиране на tar, защото формата на zip файла не поддържа надеждно всички метаданни на Unix файловата система. За някои конкретни обяснения на последния оператор трябва да знаете, че ZIP форматът само дефинира малък набор от задължителни файлови атрибути, които да се съхраняват за всеки запис: име на файл, дата на промяна, разрешения. Освен тези основни атрибути, архиваторът може да съхранява допълнителни метаданни в така нареченото допълнително поле на заглавната част на ZIP. Но тъй като допълнителните полета са дефинирани за реализация, няма гаранции дори за съвместими архиватори да съхраняват или извличат същия набор от метаданни. Нека проверим това в примерен архив:

 sh $ ls -lsn data / екип общо 0 0 -rw-r - r-- 1 1000 2000 0 януари 30 12:29 отбор sh $ zip -0r archive.zip data / 
 sh $ zipinfo -v archive.zip данни / екип Централна директория запис # 5: --------------------------- данни / екип [.. .] видим тип файл: двоични атрибути на Unix файлове (100644 осмични): -rw-r - r-- атрибути на MS-DOS файл (00 hex): няма полето за централна директория съдържа: - подполе с ID 0x5455 ( универсално време) и 5 ​​байта данни. Местното допълнително поле има UTC / GMT време за промяна / достъп. - подполе с ID 0x7875 (Unix UID / GID (всякакъв размер)) и 11 байта данни: 01 04 e8 03 00 00 04 d0 07 00 00. 

Както можете да видите, информацията за собствеността (UID / GID) е част от допълнителното поле - може да не е очевидно, ако не знаете шестнадесетичен, нито че ZIP метаданните са запазени малко, но за кратко „e803“ е “03e8” с “1000”, UID файл. "07d0" е "d007", което е 2000, файлът GID.

В този конкретен случай, инструментът ZIP -Info, наличен в моята Debian система, съхранява някои полезни метаданни в допълнителното поле. Но няма гаранция, че това допълнително поле ще бъде написано от всеки архиватор. И дори да присъстват, няма гаранция, че това ще бъде разбрано от инструмента, използван за извличане на архива.

Докато не можем да отхвърлим традицията като мотивация за все още да използвате tarballs, с този малък пример разбирате защо все още има (ъглови?) Случаи, в които катранът не може да бъде заменен от zip . Това е особено вярно, когато искате да запазите всички стандартни метаданни на файлове.

Тар срещу Zip срещу Gz тест за ефективност

Тук ще говоря за ефективността на пространството, а не за ефективността във времето - но като правило, по-ефективно е алгоритъм за компресия, повече CPU изисква.

И за да ви дам представа за степента на компресиране, получена при използване на различни алгоритми, събрах на твърдия си диск около 100MB файлове от популярни файлови формати. Ето резултатите, получени на моята Debian Stretch система (всички размери, както е докладвано от du -sh ):

тип файл.jpg.mp3.mp4.odt.png.текст
брой файлове216345279299020724397
пространство на диска98м99m99m98м98м98м
катран94M99m98м93m92м89 млн
цип (без компресия)92м99m98м91m91m86м
цип (дефлация)87m98м93m85м77н28M
катран + gzip86м98м93m82m77н27m
tar + bz287m98м93m42m71м22M
tar + xz7098м22M348K51М19м

Първо, насърчавам ви да вземете тези резултати с огромно количество сол: файловете с данни всъщност са файлове, които се намират на твърдия ми диск и не бих искал да са представителни по никакъв начин. След това трябва да призная, че не избрах тези типове файлове на случаен принцип. Вече казах, че .odt файловете вече са zip файлове. Така че умерената печалба, получена от компресирането им за втори път, не е изненадваща (с изключение на bzip2 или xy, но бих смятал, че това е статистическа аномалия, причинена от ниската хетерогенност на моите файлове с данни - съдържаща няколко архива или работещи версии на същите документи).

Относно .jpg, .mp3 и .mp4 сега: може би знаете, че вече са компресирани файлове с данни. Дори по-добре, може да сте чули, че използват деструктивна компресия . Това означава, че не можете да възстановите точно оригиналното изображение след JPEG компресия. И това е вярно. Но това, което е малко известно е след разрушителната фаза на компресия сама по себе си, данните се компресират за втори път, като се използва алгоритъмът за неразрушителна променлива дума на Huffman, за да се премахне излишната информация.

Поради всички тези причини се очакваше, че компресирането на JPEG изображения или MP3 / MP4 файлове няма да доведе до големи печалби. Моля, обърнете внимание, че типичният файл съдържа както високо компресираните данни, така и някои некомпресирани метаданни, но все още можем да спечелим малко. Това обяснява защо все още имам забележима печалба за JPEG изображения, тъй като имах много от тях - така общият размер на метаданните не беше толкова незначителен в сравнение с общия размер на файла. Още веднъж, изненадващите резултати при компресиране на MP4 файлове с помощта на xz вероятно са свързани с високите сходства между различните MP4 файлове, използвани по време на моите тестове. Или не са?

За да вдигнете тези съмнения, аз силно ви препоръчвам да направите свои собствени сравнения. И не се колебайте да споделите вашите наблюдения с нас, като използвате раздела за коментари по-долу!

Препоръчано

Двигателят на Microsoft Edge за JavaScript е отворен код
2019
Върнете стария си компютър обратно в живота с 4MLinux
2019
Fix Невъзможност за влизане в Ubuntu след надстройка
2019