Кратко

  • «Почти побайтовое копирование» RFC 2159 включало сопоставление параметров, обращение битов, заполнение страниц и границу из шести EOL.
  • Возврат без потерь зависел от границ страниц, завершающих EOL и безымянных битов DCS; одинаковый хеш тела не доказывал восстановление того же факсимильного объекта.
  • Правильный структурный цикл не доказывал поддержку режима декодером, точную геометрию строки или пригодное изображение.

Слово «почти» описывало алгоритм

RFC 2159, опубликованная в январе 1998 года, определила перенос уже закодированных данных факса Группы 3 в MIME и их сопоставление с X.400. image/g3fax не объявлялся универсальным форматом изображений. Задача состояла в сохранении существующего представления между двумя системами сообщений.

Объект содержал параметры кодирования, структуру страниц и биты изображения T.4 для каждой страницы. Параметры переходили в MIME. Последовательность BIT STRING X.400 превращалась в непрерывное тело с разделителем. Для данных применялось другое направление битов внутри байта.

Предыдущая RFC 1494 определяла Byte Copy как копирование без преобразования. Для G3Fax уже использовалось nearly. Изображение не требовало декомпрессии и повторного кодирования, но контейнер приходилось собирать заново.

Отсутствующий параметр тоже выбирал значение

MIME мог передавать длину и ширину страницы, одномерное, двумерное или несжатое кодирование, тонкое или грубое разрешение, число страниц и Device Control String в Base64. По умолчанию действовали A4, A4, одномерный режим и грубое разрешение.

Номера битов одинаковых опций отличались в T.30 и X.400, поскольку стандарты считали с противоположных краёв октета. Шлюз сопоставлял смысл, а не номер. Это отдельно от последующего обращения каждого байта данных страницы.

Если был установлен бит без именованной опции, RFC требовала передать DCS. Одновременно она не гарантировала совместимость для таких NonBasicParameters. Сохранение бита сохраняло доказательство, но не добавляло функцию получателю.

Границу страницы нужно было создать

X.400 хранил последовательность ASN.1 BIT STRING — по одному на страницу. MIME требовал одно тело. RFC 2159 выбрала разделителем шесть EOL подряд; каждый EOL содержал одиннадцать нулей и единицу. Последовательность должна начинаться на границе байта, поэтому добавлялись нули.

Шаблон имел вид 00 10 01 00 10 01 00 10 01 и, по утверждению RFC, не мог появиться внутри изображения. Страницы можно было найти без визуализации, но положение границы, выравнивание и длина заполнения становились частью свидетельства. Плоский поток не доказывал ту же последовательность страниц.

Из X.400 в MIME удалялись конечные EOL, порядок приводился к интернет-соглашению, байт дополнялся, добавлялись шесть EOL, страницы соединялись. На обратном пути тело делилось, конечные EOL сохранялись, биты каждого байта обращались, а последовательность ASN.1 восстанавливалась.

Сохранение EOL было явным изменением по сравнению с RFC 1494, которая удаляла EOL и заполнение. Общий ярлык остался, точное правило возврата изменилось.

Хеш не понимает семантику порядка битов

Стабильный хеш MIME подтверждает сохранность этих октетов на наблюдаемом участке. Он не подтверждает правильный порядок на предыдущем шлюзе. Упакованные байты BIT STRING могут отличаться от MIME при корректном преобразовании, потому что обращение предписано.

Правильное сравнение фиксирует значимые биты каждой страницы, неиспользованные биты ASN.1, правило порядка, число добавленных нулей и смещения разделителей. Обратный путь должен вернуть страницы, значимые биты, параметры и DCS.

RFC 2157 даёт критерий: equivalence — два mapping, вместе обеспечивающие преобразование без потерь. Получение допустимого тела в одном направлении доказывает только одну стрелку.

Обратимость ещё не означала видимость

Рекомендации отделяли структуру от применения. Без fineResolution пиксели были вдвое выше своей ширины. Некоторые разрешения и длины поддерживать было легче, чем ширину B4 или A3. Отдельные аппараты испытывали проблемы, если строка не содержала ровно объявленное число пикселей, например после удаления белого поля справа.

Шлюз может восстановить страницы и опции, а декодер — не поддержать режим. Он может принять данные и исказить геометрию. Правдоподобная страница может быть обрезана. Синтаксис, восстановление, размеры, внешний вид и чтение — разные наблюдения.

Современный реестр IANA содержит image/g3fax, а исторические таблицы MIME/X.400 связывают его с g3-facsimile. Это доказывает публичный идентификатор, но не реализацию продукта и не способность получателя.

Надёжный тест начинается с параметров X.400, DCS, страниц, значимых длин и отпечатков, а также версии шлюза. В MIME сохраняются параметры, заполнение и границы. Обратный проход сравнивает восстановленную последовательность. Лишь потом проверяются режимы, пиксели в строке, размеры и визуализация.

Тексты Lu Heng о работающем коде, минимальной спецификации и слоях реальности служат раскрытой аналитической рамкой: правило, исполнение, представление и результат не заимствуют доказательства друг у друга.

Nearly в RFC 2159 перечисляло то, что оставалось за пределами копии. Без опций, страниц, порядка, заполнения или возможностей получателя целое тело могло перестать быть исходным факсом.

Источники