Перейти к основному содержимому

1.20. Специализированные форматы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Всем

Специализированные форматы​

В экосистеме информационных технологий термин формат файла обозначает установленный способ организации данных внутри файла, включая как структурные, так и семантические соглашения. Формат определяет, как данные записаны на носитель, как они интерпретируются программным обеспечением, и какие метаданные или ограничения накладываются на содержимое. Все форматы условно делятся на общепринятые (например, .txt, .jpg, .pdf) и специализированные — те, что возникают в узких технических или организационных контекстах и не предназначены для прямого восприятия человеком без соответствующих инструментов.

Специализированные форматы не являются стандартами в общемировом или даже отраслевом масштабе. Их происхождение обычно связано с конкретной задачей, программным продуктом, аппаратной платформой или внутренними договорённостями разработчиков. Такие форматы служат для хранения данных, не поддающихся адекватному представлению в универсальных форматах, или для обеспечения функциональных свойств — таких как целостность, безопасность, эффективность обработки, обратная совместимость, разграничение доступа и управление жизненным циклом.

Расширение (например, .db, .sig) выступает лишь внешним идентификатором, маркером, указывающим на ожидаемую интерпретацию содержимого. Само содержимое может быть устроено по-разному: бинарно или текстово, с фиксированной или динамической структурой, с или без заголовков, с проверочными суммами, с метками версий. Поэтому при описании специализированных форматов необходимо рассматривать как сигнатуру расширения, так и типичные внутренние структуры, характерные для данного класса файлов.

Ниже рассматриваются наиболее распространённые специализированные форматы, встречающиеся в повседневной практике системного администрирования, разработки ПО, сопровождения инфраструктуры и обеспечения информационной безопасности. Каждый формат анализируется с точки зрения происхождения, назначения, типичного содержания, особенностей обработки и потенциальных рисков.

.BIN — бинарные образы и низкоуровневые данные​

Расширение .bin (сокращение от binary) не определяет единого стандарта, но указывает на то, что файл содержит сырые (raw) бинарные данные — последовательность байтов без встроенной разметки в виде текстовых меток, заголовков или разделителей. Такие файлы не предназначены для непосредственного редактирования человеком; их содержимое интерпретируется исключительно по контексту использования.

Наиболее характерные применения .bin:

  • Образы устройств и носителей — например, образы оптических дисков (CD/DVD/Blu-ray), флеш-памяти, целых разделов или дисков. В таком случае .bin содержит побайтовую копию содержимого физического или логического блочного устройства. Часто сопровождается дополнительными файлами: .cue (для описания дорожек и режимов записи), .mds/.mdx (в экосистеме Daemon Tools), .iso (который по сути — частный случай бинарного образа с соблюдением спецификации ISO 9660).

  • Прошивки и микрокод — бинарные файлы, предназначенные для записи во встроенную память аппаратных устройств (маршрутизаторов, BIOS/UEFI материнских плат, микроконтроллеров, принтеров). Содержимое таких файлов строго привязано к архитектуре целевого устройства и часто защищено контрольными суммами или цифровыми подписями. Подмена или повреждение прошивки может привести к аппаратному отказу («кирпичу»).

  • Игровые данные и ассеты — в индустрии разработки игр .bin часто применяется для хранения скомпилированных ресурсов: текстур, анимаций, уровней. В этом случае формат — проприетарный и определяется движком игры; для извлечения или модификации требуется специализированный инструментарий (например, asset unpackers).

  • Результаты низкоуровневых операций — например, дампы памяти процесса, снимки сетевого трафика (raw pcap вне заголовков libpcap), выходные данные утилит вроде dd, ddrescue, nanddump. Такие файлы служат диагностическим целям и анализируются с помощью утилит (hexdump, xxd, binwalk, foremost и др.).

Ключевая особенность .bin — отсутствие самодокументированности. Без внешнего контекста невозможно однозначно определить, что представляет собой файл. Поэтому при работе с .bin критически важны сопутствующие метаданные: имя файла, каталог размещения, дата создания, сопутствующая документация, контрольные суммы. Автоматическая идентификация возможна с помощью сигнатур (например, через file в Unix-системах), но не всегда надёжна.

Практический аспект: при архивировании или передаче .bin следует избегать текстовых преобразований (например, перекодировок, обработки как текста в FTP-режиме ASCII). Такие файлы должны обрабатываться в двоичном режиме.

.DB — файлы локальных баз данных​

Расширение .db (от database) используется для обозначения файлов, содержащих данные, организованные в соответствии с моделью базы данных, чаще всего реляционной. В отличие от клиент-серверных СУБД (например, PostgreSQL, MySQL), файловые СУБД хранят всю базу данных — схему, данные, индексы, иногда журналы транзакций — в одном или нескольких файлах на локальной файловой системе.

Наиболее распространённые СУБД, использующие .db-файлы:

  • SQLite — де-факто стандарт для встраиваемых баз данных. Файл .db в SQLite полностью самодостаточен: не требует отдельного серверного процесса, поддерживает ACID-транзакции, имеет строгую типизацию (хотя и динамическую), и обеспечивает конкурентный доступ на уровне чтения (запись блокирует базу целиком). Формат открыт, стабилен, с обратной совместимостью на уровне байткода. SQLite используется повсеместно: от мобильных приложений (Android, iOS) до браузеров (Chrome, Firefox — для хранения истории, куков), от IoT-устройств до вспомогательных баз в крупных системах.

  • Berkeley DB — библиотека ключ-значение, исторически популярная в Unix-средах (например, для хранения man-страниц, кэшей nscd). Работает на уровне пар «ключ — байтовый массив», поддерживает различные режимы доступа (B-дерево, хеш, очередь). Современное применение сокращается в пользу более развитых решений (RocksDB, LevelDB), но остаточные .db-файлы часто встречаются в legacy-системах.

  • Проприетарные форматы — например, старые версии Microsoft Access (*.mdb, иногда переименованные в .db), 1C:Предприятие (файловый режим), или внутренние базы прикладных систем (например, конфигурационные хранилища). Такие файлы обычно несовместимы вне контекста родного приложения.

Структура .db-файла зависит от СУБД, но типичные составляющие включают:

  • Заголовок (magic bytes, версия формата, размер страницы, флаги состояния — например, «база закрыта корректно»);
  • Таблицы и их метаданные (имена, типы столбцов, ограничения);
  • Данные, размещённые постранично;
  • Индексы (B-деревья, хеш-таблицы);
  • Журналы (WAL — Write-Ahead Logging, или rollback-журналы);
  • Свободное пространство (для повторного использования при удалении записей).

.db-файл не является «архивом» или «резервной копией» в общем смысле. Это рабочее хранилище. Прямое копирование файла во время активной работы СУБД может привести к повреждению данных, если не используются механизмы «горячего» резервного копирования (например, VACUUM INTO в SQLite или PRAGMA wal_checkpoint перед копированием WAL-файла).

Для диагностики .db применяются специализированные утилиты: sqlite3 (интерактивная оболочка и CLI), DB Browser for SQLite, hexdump с анализом сигнатур, а также инструменты восстановления (sqlite3 с PRAGMA integrity_check, sqlite3_recover).

.SQL — исполняемые скрипты языка структурированных запросов​

Файл с расширением .sql представляет собой текстовый документ, содержащий последовательность инструкций на языке SQL (Structured Query Language) или его диалектах. Такие файлы описывают операции над данными или структуру хранилища. Их суть — декларативное или императивное предписание для СУБД.

Необходимо разделять два основных класса .sql-файлов по их содержанию и цели:

1. Скрипты определения структуры (DDL-скрипты)​

Содержат операторы определения данных (Data Definition Language):
CREATE TABLE, CREATE INDEX, ALTER TABLE, DROP VIEW, GRANT, REVOKE и др.

Такие файлы используются для:

  • Инициализации схемы базы данных при развёртывании системы;
  • Миграции структуры (версионирование схемы — например, в рамках Liquibase, Flyway или кастомных решений);
  • Восстановления метаданных из резервной копии (в связке с .dump или .backup);
  • Документирования структуры — человекочитаемый источник истины, особенно когда прямой доступ к СУБД ограничен.

Характерные особенности:

  • Часто включают IF NOT EXISTS или проверки существования объектов для идемпотентности;
  • Могут содержать комментарии, оформление, секционирование по логическим блокам (например, «Таблицы», «Индексы», «Ограничения»);
  • Чувствительны к порядку выполнения (зависимости между объектами: таблица должна существовать до создания внешнего ключа);
  • Могут быть сгенерированы автоматически (pg_dump --schema-only, mysqldump -d).

2. Скрипты манипуляции и инициализации данных (DML/DCL-скрипты)​

Содержат операторы:

  • Data Manipulation Language: INSERT, UPDATE, DELETE, SELECT (для генерации данных);
  • Data Control Language: GRANT, REVOKE (если не включены в DDL);
  • Иногда — процедурные расширения (BEGIN ... END, DECLARE, LOOP), если СУБД поддерживает (PL/pgSQL, T-SQL, PL/SQL).

Применяются для:

  • Заполнения справочников и начальных данных (например, перечня стран, типов пользователей);
  • Тестовых наборов данных;
  • Массовых корректировок (например, обновление цен по бизнес-правилу);
  • Экспорта/импорта по сценарию.

Особенности:

  • Может содержать тысячи INSERT-запросов — в таком случае часто применяется синтаксис множественной вставки или bulk-форматы (например, COPY в PostgreSQL);
  • Для больших объёмов предпочтительнее бинарные форматы дампов (pg_dump -Fc), но .sql остаётся выбором для переносимости и ревью;
  • Уязвим к ошибкам кодировки, если текстовый редактор не сохраняет в UTF-8 без BOM;
  • Может включать управляющие директивы: -- -*- coding: utf-8 -*-, SET client_encoding = 'UTF8';, BEGIN; ... COMMIT; — для обеспечения воспроизводимости.

Важный нюанс: .sql — это исполняемый код. Как и любой программный артефакт, он подлежит:

  • Версионированию в системе контроля (Git и др.);
  • Ревью перед применением в production;
  • Тестированию на staging-среде;
  • Документированию (например, в начале файла — дата, автор, описание изменений, номер задачи в трекере).

Автоматизация выполнения .sql достигается через CLI-утилиты (psql -f script.sql, mysql < script.sql, sqlcmd -i script.sql), встроенные инструменты СУБД, CI/CD-конвейеры или ORM-миграции. При этом следует учитывать особенности транзакционности: не все СУБД выполняют весь скрипт в одной транзакции по умолчанию (например, MySQL по умолчанию — autocommit включён).

.SIG — файлы цифровой подписи​

Расширение .sig (от signature) обозначает файл, содержащий криптографическую подпись, привязанную к другому файлу. Сам по себе .sig не несёт полезной нагрузки — он бессмысленнен без соответствующего подписанного файла (например, program.exe и program.exe.sig). Его назначение — подтверждение двух свойств:

  1. Целостности — содержимое файла не было изменено после подписания;
  2. Подлинности — файл действительно был подписан владельцем конкретного закрытого ключа.

Механизм работы основан на асимметричной криптографии:

  • Отправитель вычисляет хеш (например, SHA-256) от содержимого файла;
  • Шифрует этот хеш своим закрытым ключом — получает подпись;
  • Передаёт получателю и файл, и .sig;
  • Получатель вычисляет хеш от полученного файла, расшифровывает подпись открытым ключом отправителя и сравнивает два хеша.

Если значения совпадают — подпись валидна.

Распространённые форматы и инструменты:

  • GPG/PGP — .sig часто создаётся утилитой gpg --detach-sign file.bin. Подпись может быть бинарной (по умолчанию, .sig) или ASCII-armored (.asc). Проверка: gpg --verify file.bin.sig file.bin.
  • PKCS#7 / CMS — используется в Windows (например, подписи драйверов .cat, обновлений). Подпись может быть встроенная (в PE-заголовок исполняемого файла) или отсоединённая (.p7s, .sig).
  • XML Signature, JWS (JSON Web Signature) — хотя обычно не используют .sig, концептуально аналогичны.

Особенности .sig:

  • Размер обычно мал (несколько сотен байт — длина ключа + метаданные);
  • Зависит от алгоритма хеширования и подписи (RSA-SHA256, ECDSA-SHA384 и др.);
  • Не содержит исходных данных — только подпись;
  • Требует доверия к открытому ключу (через доверенные сертификаты, ключевые серверы, вручную импортированные отпечатки).

Практическое применение:

  • Распространение ПО (особенно open-source): проекты публикуют .tar.gz и .tar.gz.sig, пользователь сам проверяет подлинность;
  • Обмен конфиденциальными документами;
  • Юридически значимые документы (в РФ — с использованием КЭП/УКЭП, где подпись технически может быть в .sig, но чаще интегрирована в контейнер).

Важно: наличие .sig не заменяет антивирусную проверку. Подпись гарантирует происхождение и неизменность, но не безопасность содержимого. Злоумышленник может подписать вредоносный файл своим ключом — проверка пройдёт успешно.

.TMP — временные файлы​

Файлы с расширением .tmp (от temporary) создаются операционной системой, приложениями или пользовательскими скриптами для хранения промежуточных данных, не предназначенных для долгосрочного использования. Их существование ограничено жизненным циклом операции.

Типичные сценарии создания .tmp:

  • Редакторы и офисные приложения — для автосохранения (например, ~WRL1234.tmp в Word), предотвращения потери данных при аварийном завершении;
  • Компиляторы и сборщики — промежуточные объектные файлы, препроцессорные выходы, временные архивы;
  • Установщики и обновления — распаковка архивов перед копированием в целевые каталоги;
  • Веб-серверы и приложения — кэширование сессий, загрузка multipart-форм (php://temp, временные файлы в /tmp);
  • Скрипты и пайплайны — промежуточные результаты между этапами обработки (например, sort file.txt > tmp1 && uniq tmp1 > tmp2).

Особенности:

  • Имена часто генерируются автоматически (уникальные строки, PID процесса, временные метки);
  • Могут не иметь расширения .tmp — например, tmp.3Xk9a, /tmp/phpABCD12;
  • Обычно размещаются в выделенных каталогах: /tmp, /var/tmp (Unix), %TEMP%, %TMP% (Windows);
  • Не должны содержать критически важных данных без резервного копирования;
  • Должны удаляться после завершения операции — но на практике часто остаются из-за сбоев.

Риски:

  • Утечка данных — временные файлы могут содержать чувствительную информацию (пароли, персональные данные), если приложение не очищает их или не использует безопасное удаление (shred, sdelete);
  • Заполнение диска — накопление .tmp приводит к отказу сервисов;
  • Race condition — если имя файла предсказуемо, возможна атака «временное имя → симлинк → перезапись чужого файла» (особенно в /tmp без noexec,nosuid и O_EXCL).

Рекомендации для разработчиков:

  • Использовать системные API для создания временных файлов (mkstemp() в C, tempfile.NamedTemporaryFile() в Python, Path.GetTempFileName() в .NET);
  • Устанавливать строгие права доступа (0600 в Unix);
  • Обеспечивать удаление в блоках finally или через RAII-идиомы;
  • Избегать хранения конфиденциальных данных в plaintext без шифрования.

Для администраторов: регулярная очистка /tmp (например, через tmpwatch или systemd-tmpfiles), мониторинг объёма, выделение отдельного раздела.

.BAK — резервные копии​

Расширение .bak (сокращение от backup) указывает на то, что файл является копией другого файла или набора данных, созданной с целью восстановления в случае повреждения, потери или необходимости отката. В отличие от архивов (.zip, .tar.gz) или дампов СУБД, .bak не подразумевает единого стандарта упаковки — это семантическая метка, призванная обозначить роль файла в системе управления данными.

Типы резервных копий и их отражение в .bak​

  1. Простое копирование с переименованием
    Наиболее распространённый способ: перед модификацией оригинального файла (например, config.xml) приложение создаёт его копию как config.xml.bak. Такой подход:

    • Минималистичен — не требует внешних утилит;
    • Позволяет быстро откатиться (удалить изменённый, переименовать .bak обратно);
    • Часто используется текстовыми редакторами (Notepad++, Vim при set backup), СУБД (SQL Server Management Studio при сохранении скрипта), инсталляторами.

    Однако такой метод не масштабируется: при повторной модификации новая копия перезапишет старую .bak, и история будет ограничена одним шагом.

  2. Версионированные резервные копии
    Развитие предыдущего подхода: добавление временной метки или счётчика — config.xml.bak_20251126_1430, data.db.bak.1, data.db.bak.2.
    Позволяет сохранять несколько поколений, но требует управления (ограничение количества, ротация, удаление старых).

  3. Полноконтекстные резервные копии
    В крупных системах .bak может обозначать результат работы специализированных утилит:

    • SQL Server: BACKUP DATABASE ... TO DISK = 'db.bak' — бинарный формат, содержащий не только данные, но и лог транзакций, метаданные, параметры восстановления;
    • 1С:Предприятие: экспорт конфигурации или информационной базы в .dt или .cf, но при копировании файловой базы часто применяется base.1cd.bak;
    • Операционные системы: образы системных томов (часто .vhd, .vhdx, но вручную переименованные в .bak для ясности).

Критические аспекты использования .bak​

  • Не является гарантией сохранности
    Файл .bak подвержен тем же рискам, что и оригинал: повреждение носителя, вирусное заражение, случайное удаление. Надёжное резервное копирование требует:

    • Хранения вне того же физического устройства (другой диск, сервер, облако);
    • Регулярной проверки восстанавливаемости («бэкапы не работают, пока их не восстановили»);
    • Контроля целостности (контрольные суммы, хеши).

  • Семантическая неоднозначность
    Расширение .bak не говорит о формате содержимого. document.docx.bak — обычный ZIP-архив (как и .docx), firmware.bin.bak — бинарный образ, db.bak от SQL Server — проприетарный бинарный формат. Для определения типа требуется анализ сигнатур (file db.bak) или контекст.

  • Автоматизация и политики
    В профессиональных средах ручное создание .bak заменяется:

    • Скриптами с ротацией (например, logrotate для логов);
    • Системами управления конфигурацией (Ansible, Puppet — хранят предыдущие версии конфигов);
    • VCS (Git) — для текстовых файлов резервное копирование избыточно, если используется контроль версий.

  • Юридические и регламентные аспекты
    В системах, подчиняющихся требованиям (PCI DSS, GDPR, ГОСТ Р, ФЗ-152), резервные копии должны:

    • Шифроваться при передаче и хранении;
    • Иметь фиксированный срок хранения;
    • Подписываться (см. .SIG);
    • Документироваться (кто, когда, что, зачем скопировал).

Рекомендация: не полагаться на .bak как на единственную стратегию. Эффективная политика резервного копирования следует правилу 3-2-1:

  • 3 копии данных (оригинал + 2 резервные);
  • 2 различных носителя (например, SSD + облако);
  • 1 копия вне места эксплуатации (off-site).

.OVERRIDE — файлы переопределения​

Расширение .override (иногда .ovr, .override.json, .override.yml) обозначает файл, предназначенный для частичного изменения базовой конфигурации без её полной замены. Такой подход получил широкое распространение в системах, где требуется гибкость настройки при сохранении целостности основного конфигурационного шаблона.

Принцип работы​

Система загружает конфигурацию в несколько этапов:

  1. Чтение базового файла (например, appsettings.json);
  2. Поиск файлов переопределения (например, appsettings.Production.override.json);
  3. Слияние содержимого: значения из .override заменяют соответствующие ключи в базовом файле, остальное остаётся без изменений.

Механизм слияния зависит от формата и реализации:

  • В JSON/YAML — рекурсивное объединение по ключам (вложенные объекты также объединяются, а не заменяются целиком);
  • В плоских .ini или .properties — простая перезапись по имени параметра;
  • В XML — может использоваться XPath-совместимое наложение (например, в .NET configSource или xdt:Transform).

Почему .OVERRIDE, а не редактирование оригинала?​

  1. Идемпотентность развёртывания
    Базовый конфиг — часть дистрибутива, управляется разработкой. Файл переопределения — часть окружения, управляется DevOps или администратором. Обновление приложения не затирает кастомизацию.

  2. Безопасность
    Конфиденциальные параметры (ключи API, пароли) выносятся в .override, который:

    • Исключается из системы контроля версий (.gitignore);
    • Хранится в защищённом хранилище (HashiCorp Vault, Azure Key Vault);
    • Монтируется в контейнер только во время выполнения.

  3. Многократное использование шаблона
    Один базовый конфиг — для dev, test, stage, prod. Отличия (URL базы, уровень логирования, feature flags) — в отдельных .override.

  4. Соблюдение принципа наименьших привилегий
    Администратору не нужен доступ к полному конфигу — только к переопределяемым параметрам.

Практические примеры​

  • ASP.NET Core
    appsettings.json + appsettings.Development.json (фактически override по соглашению). Полноценные override-файлы поддерживаются через ConfigurationBuilder.AddJsonFile("overrides.json", optional: false) с последующим AddJsonFile("overrides.Production.json", optional: true).

  • Docker / Kubernetes
    ConfigMap может содержать базовую конфигурацию, а volumeMount с subPath монтирует overrides.yml поверх.

  • Nginx / Apache
    Хотя напрямую .override не используется, концепция реализована через include *.conf — например, /etc/nginx/sites-enabled/site.conf и /etc/nginx/conf.d/site.override.conf.

  • Unity / Unreal Engine
    Конфигурация проекта (ProjectSettings.asset) — бинарный или YAML, но для билдов под платформы используются override-файлы (AndroidOverride.ini, IOSBuildOverrides.json).

Требования к реализации​

  • Явное указание приоритета: какие файлы перекрывают какие;
  • Поддержка отмены значения (например, null в JSON для удаления ключа);
  • Валидация после слияния — чтобы override не нарушал структуру;
  • Логирование применённых переопределений (для аудита и отладки).

Важно: не все системы поддерживают .override «из коробки». Часто это соглашение, реализуемое на уровне приложения. Поэтому документация должна чётко описывать:

  • Где искать override-файлы;
  • В каком порядке они применяются;
  • Какие ключи допустимо переопределять.