Формат SHAR (SHell ARchive) — это формат архивирования и сжатия файлов, который обычно используется в Unix и Unix-подобных операционных системах. Он был разработан как простой способ упаковать несколько файлов и каталогов в один архивный файл для более простого хранения и передачи. Формат SHAR позволяет выполнять необязательное сжатие архивируемых файлов для уменьшения общего размера результирующего архива.
Архив SHAR по сути является сценарием оболочки, который содержит ряд команд для воссоздания исходной структуры каталогов и файлов. Когда файл SHAR выполняется, оболочка интерпретирует команды и извлекает файлы в их исходные расположения. Это упрощает создание и извлечение архивов SHAR без необходимости использования специализированных инструментов архивирования, если доступна оболочка Unix.
Структура архива SHAR состоит из заголовка, метаданных файла и фактического содержимого файла. Заголовок обычно включает строку shebang (например, `#!/bin/sh`) для указания интерп ретатора для сценария оболочки, за которым следуют любые необходимые команды оболочки или объявления переменных. Заголовок также может включать комментарии или инструкции по извлечению архива.
После заголовка архив SHAR содержит ряд разделов для каждого архивируемого файла или каталога. Каждый раздел начинается с метаданных о файле, таких как его имя, разрешения, права собственности и временные метки. Эти метаданные представлены с использованием команд оболочки, которые устанавливают соответствующие атрибуты при извлечении файла.
После метаданных в архив включается фактическое содержимое файла. Содержимое файла обычно кодируется с использованием схем кодирования `uuencode` или `base64`, чтобы гарантировать, что содержимое совместимо с текстовой природой сценария оболочки. Закодированное содержимое делится на более мелкие фрагменты и выводится в виде серии команд `echo` или `printf` в сценарии.
Если архив SHAR включает каталоги, структура каталогов воссоздается с использованием комбинации команд `mkdir` и соответствующих настроек метаданных. Затем файлы в каждом каталоге добавляются в архив таким же образом, как описано выше.
По желанию архив SHAR может включать сжатие для уменьшения размера результирующего файла. Обычные методы сжатия, используемые с SHAR, включают `gzip`, `bzip2` и `compress`. Сжатие обычно применяется к отдельным файлам, прежде чем они кодируются и добавляются в архив. Когда архив SHAR извлекается, сжатые файлы автоматически распаковываются сценарием оболочки.
Чтобы создать архив SHAR, можно использовать команду `shar`, которая доступна в большинстве Unix и Unix-подобных систем. Базовый синтаксис для создания архива SHAR: `shar [options] file1 file2 directory1 ... > archive.shar`. Указанные файлы и каталоги будут включены в результирующий архивный файл.
Извлечение архива SHAR так же просто, как выполнение сценария оболочки, содержащегося в архиве. Это можно сделать, сделав файл SHAR исполняемым с помощью команды `chmod`, а затем запустив его как сценарий: `chmod +x archive.shar && ./archive.shar`. Оболочка интерпретирует команды в сценарии и воссоздает исходные файлы и каталоги.
Одним из преимуществ формата SHAR является его простота и переносимость. Архивы SHAR можно создавать и извлекать в любой системе с оболочкой Unix без необходимости допол нительного программного обеспечения. Однако формат SHAR имеет некоторые ограничения по сравнению с более продвинутыми форматами архивирования, такими как `tar` или `zip`. В архивах SHAR отсутствуют такие функции, как произвольный доступ к отдельным файлам, проверки целостности или встроенное шифрование.
Несмотря на свои ограничения, формат SHAR остается полезным в определенных сценариях, особенно при работе с системами на базе Unix или когда требуется простота. Он обеспечивает простой способ упаковки и распространения файлов в виде единого самораспаковывающегося архива.
Подводя итог, формат архива SHAR — это простой и переносимый способ упаковки нескольких файлов и каталогов в один архив сценария оболочки. Он позволяет выполнять необязательное сжатие и может быть легко создан и извлечен с использованием стандартных команд оболочки Unix. Несмотря на отсутствие расширенных функций по сравнению с другими форматами архивирования, SHAR остается полезным инструментом в экосистеме Unix для базовых потребностей архивирования и распространения.
Сжатие файлов уменьшает избыточность, чтобы те же данные занимали меньше бит. Верхняя граница задаётся теорией информации: для без потерь пределом является энтропия источника (см. теорему кодирования источника Шеннона source coding theorem и его оригинальную статью 1948 года «A Mathematical Theory of Communication»). Для сжатия с потерями компромисс между битрейтом и качеством описывает теория rate–distortion.
Большинство компрессоров работают в два этапа. Сначала модель предсказывает или выявляет структуру данных. Затем кодер превращает эти предсказания в почти оптимальные шаблоны битов. Классическая семья моделей — Lempel–Ziv LZ77 (1977) и LZ78 (1978) находят повторяющиеся подстроки и излучают ссылки вместо сырых байтов. На стороне кодирования кодирование Хаффмана (см. статью 1952 года) назначает более короткие коды вероятным символам. Арифметическое кодирование и range coding ещё точнее приближаются к пределу энтропии, а современные Asymmetric Numeral Systems (ANS) дают схожие коэффициенты при табличных реализациях.
DEFLATE (используют gzip, zlib, ZIP) сочетает LZ77 и Хаффмана. Спецификации открыты: DEFLATE RFC 1951, оболочка zlib RFC 1950и формат gzip RFC 1952. Gzip ориентирован на потоковую передачу и явно не обеспечивает произвольный доступ. PNG закрепляет DEFLATE как единственный метод (окно до 32 КиБ) согласно спецификации «Compression method 0…» и W3C/ISO PNG 2nd Edition.
Zstandard (zstd): современный универсальный компрессор с высокими коэффициентами и очень быстрой декомпрессией. Формат описан в RFC 8878 (и HTML-зеркале) и в референс-спеке на GitHub. Как и gzip, базовый фрейм не предполагает произвольного доступа. Главное преимущество zstd — словари: маленькие образцы корпуса, резко улучшающие сжатие множества крошечных или похожих файлов (см.документацию словарей python-zstandard и пример Nigela Tao). Реализации принимают «unstructured» и «structured» словари (обсуждение).
Brotli: оптимизирован для веб-контента (WOFF2, HTTP). Совмещает статический словарь и DEFLATE-подобное ядро LZ+энтропия. Спецификация — RFC 7932, где указано окно 2WBITS−16 с WBITS в [10, 24] и то, что формат не предоставляет произвольный доступ. Brotli часто превосходит gzip на веб-тексте и быстро декодируется.
Контейнер ZIP: ZIP — файловый архив, поддерживающий разные методы (deflate, store, zstd и др.). Де-факто стандарт — APPNOTE PKWARE (см.портал APPNOTE, размещённую копиюи обзоры LC ZIP File Format (PKWARE) / ZIP 6.3.3).
LZ4 ориентирован на максимальную скорость при умеренных коэффициентах. См. страницу проекта и формат фреймов. Подходит для кэшей в памяти, телеметрии и горячих путей, где декомпрессия должна быть почти со скоростью RAM.
XZ / LZMA гнётся за плотностью (высоким коэффициентом), но компрессует медленнее. XZ — контейнер; основную работу делают LZMA/LZMA2 (моделирование наподобие LZ77 + range coding). См.формат .xz, спецификацию LZMA (Павлов)и заметки ядра Linux про XZ Embedded. XZ обычно сжимает лучше gzip и соперничает с современными кодеками высокой плотности, но кодирует дольше.
bzip2 использует преобразование Бэрроуза–Уилера (BWT), move-to-front, RLE и Хаффмана. Обычно даёт файлы меньше, чем gzip, но медленнее; см.официальный мануал и man-страницу (Linux).
Важен размер окна. Ссылки DEFLATE смотрят максимум на 32 КиБ назад (RFC 1951) и ограничение PNG 32 КиБ здесь. Brotli поддерживает окна от ~1 КиБ до 16 МиБ (RFC 7932). Zstd настраивает окно и глубину поиска уровнями (RFC 8878). Базовые потоки gzip/zstd/brotli спроектированы для последовательного чтения; сами форматы не гарантируют произвольный доступ, хотя контейнеры (индексы tar, блочное фреймирование, форматные индексы) могут его добавить.
Форматы выше — lossless: можно восстановить те же байты. Медиа-кодеки часто lossy: они отбрасывают незаметные детали ради меньших битрейтов. Для изображений классический JPEG (DCT, квантование, энтропийное кодирование) стандартизован в ITU-T T.81 / ISO/IEC 10918-1. В аудио MP3 (MPEG-1 Layer III) и AAC (MPEG-2/4) используют перцепционные модели и MDCT (см.ISO/IEC 11172-3, ISO/IEC 13818-7и обзор MDCT здесь). Lossy и lossless могут сосуществовать (PNG для UI, веб-кодеки для изображений/видео/аудио).