BinHex

Первоначально BinHex был написан в 1981 году Тимом Манном (англ. Tim Mann) — одним из разработчиков шахматной программы Crafty — для компьютера TRS-80 как отдельная версия схемы кодирования популярного эмулятора терминала ST80-III, предназначенная для пользователей других терминалов. Он использовался для отправки файлов через крупные онлайн-сервисы, такие как CompuServe, которые, не будучи 8-разрядными, требовали, чтобы файлы сохраняли защиту в формате ASCII. Система приобрела большую популярность после того, как Манн загрузил её в раздел файлов TRS-80 на CompuServe^[1].

В период использования ранних ПК и модемных сетей файлы часто передавались через BBS, электронную почту и файловые архивы. При этом многие каналы передачи не гарантировали целостность двоичных данных (могли искажать управляющие символы, менять кодировки и т. п.). BinHex кодировал двоичный файл (например, программу для TRS‑80) в безопасный текстовый формат, а на приёмной стороне его декодировали обратно в рабочий файл. Для TRS‑80 BinHex являлся инструментом, позволявшим безопасно передавать программы и данные между пользователями через ненадёжные текстовые каналы.

Кодирование происходило следующим образом: двоичные файлы разбивались на группы (обычно по 4 бита), каждая группа представлялась шестнадцатеричной цифрой или буквой (0–9, A–F), после каждых 60 символов добавлялся символ новой строки. Также быстро добавлялась контрольная сумма (CRC или аналоги) для проверки на наличие ошибок. Формировался текстовый файл с заголовком, закодированными данными и контрольной суммой.

Последующее преобразование для использования компилятора BASIC/S позволило системе работать гораздо быстрее, чем исходная интерпретируемая версия^[1].

Декодирование происходило так: получатель запускал утилиту BinHex, которая проверяла контрольную сумму, преобразовывала шестнадцатеричные пары обратно в байты, сохраняла оригинальный файл.

На TRS‑80 работали утилиты BinHex/DeBinHex (часто на BASIC или ассемблере), позволявшие кодировать/декодировать файлы локально. Закодированные файлы имели расширения: .HXY, .HEX, .BINHEX (но единой «официальной» схемы не было). В сообществах пользователей TRS‑80 распространялись архивы с программами, играми и данными в формате BinHex, чтобы минимизировать риск повреждения при передаче.

Вскоре появились порты для других популярных компьютеров той эпохи, включая Apple II. Позже, когда CompuServe добавила поддержку 8-битных передач, формат вышел из употребления^[1].

Когда в январе 1984 года был выпущен Macintosh 128K, проблема с загрузкой файлов на CompuServe всё ещё существовала. В апреле BinHex был портирован на Mac с использованием MS BASIC для Macintosh (диалектом Microsoft BASIC для Macintosh)^[1]. В файловой системе Macintosh было реализовано хранение файлов в виде «ветви ресурсов» (англ. resource fork) и «ветви данных» (англ. data fork), а порт Macintosh поддерживал только кодирование ветви данных файлов, то есть его можно было использовать только для файлов данных. В 1984 году было опубликовано несколько новых версий, в результате чего появился BinHex 3, способный кодировать обе ветви в 7‑битный текстовый формат.

Ив Лемперёр (англ. Yves Lempereur), автор первого ассемблера для Mac (MacASM), перенёс BinHex 3 на язык ассемблера, увеличив его скорость в сто раз, и выпустил его как BinHex 1.0^[2].

Простота исходного формата BinHex сделала его неэффективным, поскольку каждый байт входных данных увеличивался до двух, как того требует шестнадцатеричное представление, кодируя данные с 8-битной точностью до 4-битной.

Ив Лемперёр выпустил оптимизированную версию под названием BinHex 2.0, в ней была реализована новая кодировка с 8-битной точностью до 6-битной точности, что уменьшило размер файла на 50 % и увеличило контрольную сумму с 8 до 16 бит^[2].

Новая кодировка использовала первые 64 печатных символа ASCII, включая пробел, для представления данных, аналогично uuencoding. Поскольку файлы меньшего размера были несовместимы со старым форматом, Ив Лемперёр изменил расширение файла на .hcx, где c означает «компактный» (англ. compact). Название BinHex не изменилось, несмотря на то, что формат больше не являлся шестнадцатеричным^[2].

В 1985 году Ив Лемперёр выпустил BinHex 4.0, пропустив версию 3.0, чтобы избежать путаницы с версией BASIC с аналогичным номером. Эта версия выполняла следующую последовательность операций^[3]:

• генерация циклических контрольных сумм (CRC) для ветви данных, ветви ресурсов и метаданных файла вместо единой контрольной суммы;
• объединение форков и метаданных с их контрольными суммами в общий 8-битный формат;
• применение кодирования длин серий для обеспечения определённого сжатия;
• выполнение преобразования из 8 бит в 6 бит.

Полученные файлы были примерно того же размера, что и файлы BinHex 2, но гораздо более надёжными, поскольку метаданные в заголовке были защищены от повреждения, так как больше не хранились в виде простого текста. Расширение файла для этого нового формата было .hqx^[2].

BinHex 4.0 был наиболее распространённой версией.

Примерно в то же время большинство онлайн-сервисов начали поддерживать надёжные 8-битные протоколы передачи файлов, такие как ZMODEM — разработанный в 1986 году для улучшения передачи файлов в сети X.25. Помимо значительного повышения производительности по сравнению со старыми протоколами, ZMODEM предлагал перезапускаемую передачу, автоматический запуск отправителем, расширенный 32-битный CRC и цитирование управляющих символов, поддерживающее 8-битную передачу, что позволяло использовать его в сетях, не передающих управляющие символы.

Это устранило необходимость в кодировании ASCII, но на компьютерах Macintosh по-прежнему существовала необходимость в кодировании двух ответвлений в одно, что привело к разработке формата файла MacBinary, объединившего в себе ветвь данных и ветвь ресурсов классического файла Mac OS в один файл вместе с расширенными метаданными HFS. Полученный файл подходит для передачи по FTP, через Интернет и по электронной почте. Документы также можно хранить на компьютерах под управлением операционных систем без поддержки HFS, таких как Unix или Windows .

В 1985 году Ив Лемперёр выпустил BinHex 5.0, который отличался только использованием MacBinary для объединения форков, но данный формат не получил широкого распространения^[2], его быстро заменил MacBinary II, который добавил поддержку новых функций mac OS.

BinHex 5.0 не является «следующей версией» после BinHex 4.0. Это отдельный формат двоичного кодирования, а не развитие BinHex 4.0^[4].

В 1990-х годах, когда Интернет только набирал популярность, электронная почта по-прежнему оставалась основным способом передачи файлов. Относительно небольшое число людей имели полный доступ к Интернету, и единственным способом загрузки файлов для многих пользователей, было использование FTPmail-сервера для доступа к различным файлам через Интернет. FTPmail — это сервис, который позволяет получать файлы с FTP-серверов через электронную почту. Он был популярен в ранние годы интернета, когда прямой доступ к FTP был ограничен, а электронная почта оставалась доступным способом обмена данными. FTPmail-сервер — это прокси-сервер, который асинхронно подключается к удалённым FTP-серверам в ответ на запросы электронной почты, возвращая загруженные файлы в виде вложений.

При использовании данного сервиса двоичные файлы по-прежнему требовали кодирования, и BinHex 4.0 оставался популярным инструментом для этого вплоть до конца 1990-х годов. Бинарные файлы всё ещё можно найти в архивах классического программного обеспечения для Mac OS^[2].

Файл BinHex может начинаться с любого текстового содержимого, за которым следует строка, указывающая формат файла и начало двоичных данных: (This file must be converted with BinHex 4.0 — Этот файл должен быть преобразован с помощью BinHex 4.0).

Текст, предшествующий этой строке, игнорируется при преобразовании файла из формата BinHex^[3][5].

Двоичные данные кодируются в 7-битные символы ASCII, при этом три байта входных данных (24 бита) делятся на четыре 6-битных значения, аналогично кодированию Base64, но с использованием другого набора символов. Перед и после закодированных данных ставится двоеточие ( :), и они разбиваются на строки длиной не более 64 символов^[3].

(This file must be converted with BinHex 4.0)

:$f*TEQKPH#jdCA0d,R0TG!"6594%8dP8)3#3"!&m!*!%EMa6593K!!%!!!&mFNa
KG3,r!*!$&[rr$3d,BQPZD'9i,R4PFh3!RQ+!!"AV#J#3!i!!N!@QKUjrU!#3'[q
3"&4&@&483N)f!3#Xaj6bV-H8mJ!!!B3!N!0"!*!$[3#3!cR@iiY)!*!'[I%4!!J
Fp$X%X3@J!mZE6!GRiKUi$HGKMf0U61S46%i1"AB!TI,fLl!d1X3RDDE8ALfTCbM
8UP9p4iUqY-0k4krHpk9XK@`rbj2Ti'U@5rGH@+[fr-i4T6-qXpfl26,k!H5$Nml
TIkI'(l3GI4)f8mII&01CNEbC2LrNLBeaZ1HG@$G8!Z6"k)hh,q9p"r6FC*!!Se"
(ic,Pd(4(b`pflKC`H1&JN5)GVX3mREdH55[l`%`Yhp%q092c`A(hPV)!83Dr&f4
$$L#I1aM-"VjqV-q$34KQq6$M$f8#,Zc,i),!(`*ZN!$K$rS!LA%3cL+dYi"@,K(
Z"`#3!fKi!!!:

С развитием 8‑битно‑чистых протоколов (например, в интернете) потребность в ASCII‑кодировании отпала. Современные системы передают двоичные файлы напрямую. Формат BinHex уступил место Zip, MacBinary, Base64 и другим более эффективным архивам.

Но BinHex остаётся важным историческим стандартом и иногда используется для совместимости со старыми системами. BinHex был ключевым решением для передачи Mac‑файлов в эпоху ограниченных каналов связи. Сегодня он имеет скорее историческую ценность, хотя некоторые старые архивы до сих пор встречаются в формате .hqx. В современной разработке (особенно на версии Python 3.9+) считается устаревшим^[6].