Кратко

  • Декабрьский RFC 1740 1994 года описал MIME-упаковку файлов Macintosh. AppleSingle складывал содержимое и свойства в один поток байтов; AppleDouble отделял заголовок с ресурсами и настольными сведениями от ветви данных.
  • Для большинства файлов, которым требовалась специальная упаковка, авторы предпочитали multipart/appledouble: часть application/applefile плюс отдельную часть с подходящим типом MIME для данных.

Обычный файл оказался составным

На компьютере, который хранит файл последовательным потоком байтов, вложение в письмо кажется простым предметом. Классический Macintosh распределял его содержимое между Data Fork и Resource Fork. В первой ветви были данные, обычно полезные на другой машине. Во второй могли находиться фрагменты программы, изображения значков и другие свойства. Finder хранил дополнительные сведения. При отправке по почте эту структуру приходилось переводить в форму, понятную системам с иной привычкой хранить файлы.

Patrik Faltstrom, Dave Crocker и Erik E. Fair воспользовались механизмом MIME из RFC 1521. Он позволял одному письму нести несколько частей, каждая со своим типом содержимого. Это был подходящий инструмент для разделения двух нужд. Пользователь Macintosh хотел получить объект вместе с его ресурсами. Получателю на другом компьютере часто требовалось просто прочитать картинку или документ из ветви данных.

Первый вариант, AppleSingle, собирал содержимое и свойства в один непрерывный поток и помечал его application/applefile. Все ехало в одной коробке. Но адресат, желавший лишь данные, сначала должен был знать, как открыть эту коробку. Тип наружной части говорил об упаковке Apple, а не о том, что внутри лежит, например, изображение. Коробка была бережной, но заставляла читателя искать инструмент.

AppleDouble разложил вещи по двум отделениям. Его заголовок нес Resource Fork и информацию рабочего стола; Data Fork оставался отдельным. Внешняя оболочка multipart/appledouble содержала ровно две части. Заголовок получал тип application/applefile. Ветвь данных получала тип, соответствующий содержимому: в примере RFC это image/gif, а при отсутствии подходящего зарегистрированного типа — application/octet-stream. Другой компьютер мог открыть вторую часть обычным MIME-инструментом. Macintosh мог использовать обе.

Авторы не требовали двух отделений ради самого ритуала. Документ с известным MIME-типом и пустой либо несущественной ветвью ресурсов разрешалось посылать как обычную MIME-часть. При отсутствии ветви данных нужен был AppleSingle: делить файл на заголовок и данные было бы нечего. В остальных случаях, особенно при важных ресурсах, AppleDouble становился основным выбором. Формат подстраивался под состав конкретного файла.

Почтовая среда добавляла собственные условия. Для бинарного потока AppleSingle и бинарного заголовка AppleDouble могла понадобиться кодировка передачи; Base64 RFC называл самым надежным вариантом для строгих каналов. Параметр name рекомендовали как подсказку об имени вложения. Унаследованная MIME-грамматика ограничивала его семибитным US-ASCII. Содержимое файла сохранялось богаче, чем надпись на почтовой бирке: характерная подробность переходной эпохи.

AppleDouble решал вопрос о том, кто распаковывает посылку. Mac-получатель работал с полным набором сведений. Другой получатель видел самостоятельную часть данных, описанную стандартным MIME-типом. Такое деление не стирало особенностей Macintosh; оно делало их соседями общей для всех части, а не стеной перед ней.

RFC 1740 можно прочитать как инструкцию для двух новых типов MIME. За ними скрывалось более знакомое действие: отправить файл коллеге так, чтобы он смог открыть нужное, а исходный компьютер потом не обнаружил потерянные ресурсы. У одного письма появились два кармана. Адресат выбирал свой, и обе половины файла доезжали вместе.