Saat mengunduh file, tidak jarang melihat .tar , .zip atau .gz ekstensi. Tapi tahukah Anda perbedaan antara Tar dan Zip dan Gz? Mengapa kami menggunakannya dan mana yang lebih efisien, tar atau zip atau gz?
Perbedaan antara tar, zip, dan gz
Jika Anda sedang terburu-buru atau hanya ingin mendapatkan sesuatu yang mudah diingat, berikut perbedaan antara zip dan tar dan gz:
.tar ==file arsip tidak terkompresi
.zip ==(biasanya) file arsip terkompresi
.gz ==file (arsip atau tidak) dikompresi menggunakan gzip
Sedikit riwayat file arsip
Seperti banyak hal tentang Unix &sistem mirip Unix, ceritanya dimulai lama sekali, di galaksi yang tidak terlalu jauh yang disebut tahun tujuh puluhan. Di suatu pagi yang dingin di bulan Januari 1979, tar utilitas muncul sebagai bagian dari Unix V7 yang baru dirilis.
The tar utilitas dirancang sebagai cara untuk secara efisien menulis banyak file pada kaset. Meskipun saat ini tape drive tidak dikenal oleh sebagian besar pengguna Linux individu, tarball — nama panggilan tar arsip — masih umum digunakan untuk mengemas beberapa file atau bahkan seluruh pohon direktori (atau bahkan hutan) ke dalam satu file.
Satu hal penting yang perlu diingat adalah tar plain polos file hanyalah arsip yang datanya tidak dikompresi. Dengan kata lain, jika Anda tar 100 file berukuran 50kB, Anda akan mendapatkan arsip yang ukurannya sekitar 5000kB. Satu-satunya keuntungan yang dapat Anda harapkan dengan menggunakan tar saja adalah dengan menghindari ruang yang terbuang oleh sistem file karena sebagian besar dari mereka mengalokasikan ruang pada beberapa perincian (misalnya, pada sistem saya, file sepanjang satu byte menggunakan ruang disk 4kB, 1000 dari mereka akan menggunakan 4MB tetapi arsip tar yang sesuai “hanya” 1MB).
Perlu disebutkan di sini tar tentu saja bukan satu-satunya alat Unix standar untuk membuat arsip. Pemrogram mungkin tahu a karena sebagian besar digunakan saat ini untuk membuat perpustakaan statis, yang tidak lebih dari arsip yang dikompilasi file. Tapi adalah dapat digunakan untuk membuat arsip dalam bentuk apa pun. Faktanya, .deb file paket yang digunakan pada sistem Debian adalah ar arsip! Dan di MacOS X, mpkg paket dikompresi dengan gzip cpio arsip. Dikatakan demikian, atau ar atau cpio memperoleh popularitas sebanyak tar di antara pengguna. Mungkin karena perintah tar cukup bagus dan mudah digunakan. |
Membuat arsip itu bagus. Namun seiring berjalannya waktu, dan dengan munculnya era komputer pribadi, orang-orang menyadari bahwa mereka dapat menghemat banyak penyimpanan dengan mengompres data. Jadi satu dekade setelah pengenalan atau tar , zip muncul di dunia MS-DOS sebagai format arsip yang mendukung kompresi . Skema kompresi paling umum untuk zip adalah mengempis yang merupakan implementasi dari algoritma LZ77. Namun sedang dikembangkan secara komersial oleh PKWARE, zip format telah mengalami pembebanan paten selama bertahun-tahun.
Jadi, secara paralel, gzip dibuat untuk mengimplementasikan algoritme LZ77 dalam perangkat lunak gratis tanpa melanggar paten PKWARE.
Elemen kunci dari filosofi Unix adalah “Lakukan Satu Hal dan Lakukan dengan Baik“ , gzip dirancang untuk hanya kompres file. Jadi, untuk membuat arsip terkompresi , Anda harus terlebih dahulu membuat arsip menggunakan tar utilitas misalnya. Dan setelah itu, Anda akan mengompres arsip itu. Ini adalah .tar.gz file (kadang-kadang disingkat .tgz untuk menambah kebingungan itu — dan untuk mematuhi batasan nama file MS-DOS 8.3 yang telah lama terlupakan).
Seiring berkembangnya ilmu komputer, algoritme kompresi lainnya dirancang untuk rasio kompresi yang lebih tinggi. Misalnya, algoritme Burrows–Wheeler diimplementasikan di bzip2 (mengarah ke .tar.bz2 arsip). Atau baru-baru ini xz yang merupakan LZMA implementasi algoritme mirip dengan yang digunakan di 7zip utilitas.
Ketersediaan dan batasan
Hari ini Anda dapat dengan bebas menggunakan format file arsip apa pun baik di Linux &Windows.
Tetapi sebagai zip format didukung secara asli di Windows, yang satu ini terutama hadir di lingkungan lintas platform. Anda bahkan dapat menemukan zip format file di tempat yang tidak terduga. Misalnya, format file tersebut dipertahankan oleh Sun untuk JAR arsip yang digunakan untuk mendistribusikan aplikasi Java yang dikompilasi. Atau untuk file OpenDocument(.odf , .odp …) digunakan oleh LibreOffice atau suite kantor lainnya. Semua format file tersebut adalah arsip zip dalam penyamaran. Jika Anda penasaran, jangan ragu untuk unzip salah satunya untuk melihat isinya:
sh$ unzip some-file.odt Archive:some-file.odt extracting: mimetype inflating: meta.xml inflating: settings.xml inflating: content.xm [...] inflating: styles.xml inflating: META-INF/manifest.xml
Semua yang dikatakan, di dunia mirip Unix, Saya akan tetap mendukung tar jenis arsip karena zip format file tidak mendukung semua metadata sistem file Unix dengan andal. Untuk beberapa penjelasan konkret dari pernyataan terakhir tersebut, Anda harus mengetahui bahwa format file ZIP hanya menentukan sekumpulan kecil atribut file wajib yang akan disimpan untuk setiap entri:nama file, tanggal modifikasi, izin. Di luar atribut dasar tersebut, pengarsip dapat menyimpan metadata tambahan di bidang tambahan yang disebut header ZIP. Namun, karena bidang tambahan ditentukan oleh implementasi, tidak ada jaminan bahkan bagi pengarsip yang sesuai untuk menyimpan atau mengambil kumpulan metadata yang sama. Mari kita periksa pada contoh arsip:
sh$ ls -lsn data/team total 0 0 -rw-r--r-- 1 1000 2000 0 Jan 30 12:29 team sh$ zip -0r archive.zip data/
sh$ zipinfo -v archive.zip data/team Central directory entry #5: --------------------------- data/team [...] apparent file type: binary Unix file attributes (100644 octal): -rw-r--r-- MS-DOS file attributes (00 hex): none The central-directory extra field contains: - A subfield with ID 0x5455 (universal time) and 5 data bytes. The local extra field has UTC/GMT modification/access times. - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes: 01 04 e8 03 00 00 04 d0 07 00 00.
Seperti yang Anda lihat, informasi kepemilikan (UID/GID) adalah bagian dari bidang tambahan — mungkin tidak jelas jika Anda tidak mengetahui heksadesimal, atau metadata ZIP itu disimpan little-endian, tetapi singkatnya "e803" adalah "03e8" dengan "1000", file UID. Dan “07d0” adalah “d007” yaitu 2000, file GID.
Dalam kasus tertentu, Info-ZIP zip alat yang tersedia di sistem Debian saya menyimpan beberapa metadata yang berguna di bidang tambahan. Tetapi tidak ada jaminan bahwa bidang tambahan ini akan ditulis oleh setiap pengarsip. Dan bahkan jika ada, tidak ada jaminan untuk memahami hal ini oleh alat yang digunakan untuk mengekstrak arsip.
Padahal kita tidak bisa menolak tradisi sebagai motivasi untuk tetap menggunakan tarball , dengan contoh kecil ini, Anda memahami mengapa masih ada beberapa kasus (sudut?) di mana tar tidak dapat diganti dengan zip . Ini terutama benar jika Anda ingin mempertahankan semua metadata file standar.
Uji Efisiensi Tar vs Zip vs Gz
Saya akan berbicara di sini tentang efisiensi ruang, bukan efisiensi waktu — tetapi sebagai aturan praktis, algoritme kompresi yang lebih berpotensi efisien, memerlukan lebih banyak CPU.
Dan untuk memberi Anda gambaran tentang rasio kompresi yang diperoleh dengan menggunakan algoritme yang berbeda, saya telah mengumpulkan di hard drive saya sekitar 100MB file dari format file populer. Berikut adalah hasil yang diperoleh pada sistem Debian Stretch saya (semua ukuran seperti yang dilaporkan oleh du -sh ):
jenis file | .jpg | .mp3 | .mp4 | .odt | .png | .txt |
jumlah file | 2163 | 45 | 279 | 2990 | 2072 | 4397 |
ruang pada disk | 98M | 99M | 99M | 98M | 98M | 98M |
tar | 94M | 99M | 98M | 93M | 92M | 89M |
zip (tanpa kompresi) | 92M | 99M | 98M | 91M | 91M | 86M |
zip (kempis) | 87M | 98M | 93M | 85M | 77M | 28M |
tar + gzip | 86M | 98M | 93M | 82M | 77M | 27M |
tar + bz2 | 87M | 98M | 93M | 42M | 71M | 22M |
tar + xz | 70M | 98M | 22M | 348K | 51M | 19M |
Pertama, saya mendorong Anda untuk mengambil hasil tersebut dengan sebutir garam:file data sebenarnya adalah file yang tergantung di hard drive saya, dan saya tidak akan mengklaim mereka sebagai perwakilan dengan cara apa pun. Kemudian, saya harus mengakui bahwa saya tidak memilih jenis file itu secara acak. Saya sudah mengatakannya, .odt file sudah menjadi file zip. Jadi keuntungan sederhana yang diperoleh dengan mengompresinya untuk kedua kalinya tidak mengejutkan (kecuali untuk bzip2 atau xy, tapi saya akan anggap itu sebagai kelainan statistik yang disebabkan oleh rendahnya heterogenitas file data saya — berisi beberapa cadangan atau versi kerja dari dokumen yang sama).
Mengenai .jpg , .mp3 dan .mp4 sekarang:mungkin Anda tahu itu sudah berkas data terkompresi. Bahkan lebih baik, Anda mungkin pernah mendengar mereka menggunakan kompresi destruktif . Itu berarti Anda tidak dapat merekonstruksi dengan tepat gambar asli setelah kompresi JPEG. Dan itu benar. Tapi yang sedikit diketahui adalah setelah fase kompresi destruktif per se , data dikompresi untuk kedua kalinya menggunakan algoritme panjang kata variabel Huffman non-destruktif untuk menghapus redundansi data.
Untuk semua alasan tersebut, diharapkan mengompresi gambar JPEG atau file MP3/MP4 tidak akan menghasilkan keuntungan yang tinggi. Harap perhatikan karena file tipikal berisi data yang sangat terkompresi dan beberapa metadata yang tidak terkompresi, kami masih dapat memperoleh sedikit sesuatu di sana. Ini menjelaskan mengapa saya masih memiliki keuntungan yang nyata untuk gambar JPEG karena saya memiliki banyak dari mereka — jadi ukuran metadata keseluruhan tidak dapat diabaikan dibandingkan dengan ukuran file total. Sekali lagi, hasil yang mengejutkan saat mengompresi file MP4 menggunakan xz mungkin terkait dengan kesamaan yang tinggi antara berbagai file MP4 yang digunakan selama pengujian saya. Atau bukan?
Untuk akhirnya menghilangkan keraguan itu, saya sangat menganjurkan Anda untuk membuat perbandingan sendiri. Dan jangan ragu untuk membagikan pengamatan Anda kepada kami melalui bagian komentar di bawah!