Кратко

  • RFC 2083 назначил каждой букве четырёхбайтового типа PNG отдельное свойство: критический/вспомогательный, публичный/частный, резервный и небезопасный/безопасный для копирования.
  • Четвёртый бит управлял редактором, а не удостоверял содержание. После изменения критических данных неизвестный небезопасный вспомогательный блок надо было удалить; безопасный можно было сохранить.
  • Сохранившийся блок и совпавший CRC доказывали ограниченную сохранность байтов, но не уникальность частного имени, актуальность смысла, автора, разрешение, приватность или точность утверждения изображения.

Редактор меняет палитру и заново записывает IDAT. Между знакомыми блоками он находит неизвестный тип. Можно прочитать длину, пропустить данные и проверить CRC, но нельзя узнать, находится там гистограмма, физическая калибровка, права или состояние закрытого рабочего процесса. Решение о переносе всё равно необходимо.

RFC 2083 не требовал от старой программы понимания всех будущих расширений. Он дал честный путь для незнания. Каждый блок содержит длину, четыре байта типа, данные и CRC. Байты типа принадлежат диапазонам букв ASCII, но обрабатываются как фиксированные двоичные значения. Проверяется бит 5 каждого байта, а не локализованное преобразование регистра.

Четыре буквы разделили четыре обязанности

Первая буква отличает critical от ancillary. Верхний регистр означает: неизвестный критический тип может быть необходим для интерпретации, поэтому декодер не вправе изображать успех. Нижний регистр позволяет пропустить неизвестный вспомогательный блок и продолжить показ. Вспомогательный не значит неважный: права, местоположение или калибровка могут влиять на человеческое решение, не участвуя в извлечении пикселей.

Вторая буква делит публичные и частные имена. Это правило пространства имён, не аутентификация. Будущие публичные назначения не займут частную форму, но две организации всё равно могут дать одному частному имени разные значения. Поэтому RFC рекомендовал помещать дополнительный идентификатор в частные данные.

Третья буква была зарезервирована. Версия 1.0 требовала верхний регистр, но старый декодер не должен был падать лишь из-за нижнего: будущая спецификация могла определить этот бит.

Четвёртая буква нужна редактору: нижний регистр — safe-to-copy, верхний — unsafe-to-copy. Пример bLOb означает вспомогательный публичный блок с нулевым резервным битом, безопасный для копирования. TEXT и Text — разные двоичные типы.

Безопасно скопировать не значит безопасно поверить

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

Автор расширения объявляет зависимость, редактор знает собственное изменение. Правило также ограничивает конструкцию: вспомогательный блок может зависеть от критического, но не должен зависеть от другого вспомогательного. Зависимость от всего потока одним битом не выражается.

Нынешняя третья редакция PNG W3C сохраняет разделение и уточняет порядок. Неизвестный небезопасный блок нельзя перемещать относительно критических; даже безопасный не может свободно пересечь границу IDAT. Safe-to-copy никогда не означало safe-to-move.

CRC закрывал вопрос о байтах, но не о смысле

CRC охватывает тип и данные блока и помогает обнаружить случайное повреждение. RFC предложил даже хранить в частном блоке CRC зависимого PLTE, чтобы замечать смену палитры.

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

Та же граница видна в приватности. Третья редакция напоминает об инструментах, скрывавших пиксели прозрачностью или менявших размеры без удаления восстанавливаемых данных; eXIf может нести GPS. Чистая картинка не доказывает удаления. Бит safe-to-copy тоже не классифицирует приватность — он только объявляет зависимость от критических данных.

Совместимость по функции вместо общей версии

RFC 2083 сознательно не ввёл глобальный номер версии. Высокое число заставляло бы старые программы отвергать файлы без неизвестных критических функций и ничего не говорило бы о частных расширениях.

Неизвестную вспомогательную функцию можно пропустить, неизвестная критическая требует остановки. Решают реально присутствующие возможности. Документ W3C о расширениях PNG и сегодня перечисляет дополнительные публичные блоки отдельно. Регистрация, распознавание и понимание — разные факты.

Позднейшая концепция Lu Heng о минимальной начальной спецификации и локальном будущем решении полезна как ретроспективная линза: тонкая общая грамматика оставила работающим программам локальное принятие, игнорирование или отказ. Это не утверждение о влиянии текста 2026 года на RFC 1997 года.

Различие между слоями реальности и символической властью дисциплинирует доказательства. Бит, класс правки и действие копирования/удаления исполнимы. «Официальный», «истинный», «разрешённый» и «надёжный» требуют других свидетельств.

Аудит должен сохранять хеш входа, упорядоченный список блоков, байты типов, четыре свойства, CRC, известные редактору типы, критические и вспомогательные изменения, решение по каждому неизвестному блоку, порядок и хеш выхода. Если метаданные поддерживают публичное утверждение, нужны также схема, владелец пространства имён, происхождение и основание сохраняющейся применимости.

Четвёртая буква не заверяла метаданные. Она назначала ответственность за решение.

Источники