Кратко

  • RFC 1456 насчитал 134 дополнительные комбинации вьетнамских букв и диакритик и описал VISCII: печатный ASCII сохранялся целиком, а шесть прописных букв занимали шесть позиций управления C0.
  • VIQR решал задачу семибитного пути, используя пунктуацию как мнемонические знаки; буквенное или обычное значение определяли контекст и экранирование.
  • MIME-метка указывала нужную грамматику, но не доказывала соответствие байтов, наличие декодера и шрифта, обратимость преобразования или прочитанный человеком результат.

Файл пережил свой словарь

Типичная ошибка начинается с правдоподобия. В документе VISCII весь печатный ASCII находится на привычных местах. Заголовки, пробелы и многие слова выглядят нормально. Если шесть C0-позиций удалить как «мусор», повреждение затронет только определённые прописные вьетнамские буквы и может долго оставаться незамеченным.

Такое поведение следует из исходного бюджета. RFC 1456 указывал, что помимо букв, уже доступных в ASCII, вьетнамскому требовались 134 сочетания основы и диакритических знаков. Они употреблялись часто, поэтому их нельзя было считать редкими исключениями.

Составная модель с отдельными основами и знаками экономила бы позиции, но плохо входила в большинство тогдашних платформ. Специальная compose-клавиша для обычного текста также переносила цену на пользователя.

VISCII выбрал готовую букву как одну единицу. Это соответствовало редакторам, файлам и приложениям с ожиданием «один символ — один байт». Чтобы сохранить весь графический ASCII, шесть менее частых прописных вьетнамских букв заняли шесть C0-позиций, признанных наименее проблемными.

В ASCII тот же октет оставался управлением. В VISCII он был буквой. Терминальный драйвер мог потребить его раньше декодера, фильтр — вырезать, шрифт — не нарисовать. Значение принадлежало не байту отдельно, а байту под конкретной таблицей.

Рабочий компромисс оставил долг

RFC 1456 сообщал о программах для Unix, MS-DOS и Windows, фильтрах почты и новостей, печати, документах и базах данных. В Plan 9 tcs поддерживал преобразование к ISO 10646/Unicode 1.1.

Это важно как свидетельство работающего кода. Оно не является переписью пользователей и не подтверждает каждую версию или безошибочный round trip. Документ фиксирует доступные авторам реализации, а не универсальный результат.

Установленная база влияла через стоимость. Сдвиг печатного ASCII ломал бы множество инструментов; повторное использование части C0 казалось более узким риском. Решение открыло существующий мир приложений, но обязало будущие архивы хранить происхождение.

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

Семибитная форма с контекстом

VIQR работал на другой границе: почтовые и новостные цепочки, допускавшие только семь бит. RFC называл его соглашением для набора, чтения и передачи, а не таким же способом кодирования, как VISCII.

Левая скобка, ^ и + напоминали соответствующие диакритики. Апостроф, обратная кавычка, вопросительный знак, тильда и точка отмечали тоны; dd и DD передавали перечёркнутую D.

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

Пунктуация сохраняла обычные роли. Вопросительный знак мог закончить вопрос или модифицировать букву. RFC приводил “How are you?” как пример нежелательной композиции и сообщал о способе её предотвращения, но полные детали оставлял внешнему документу.

Следовательно, знак не описывал сам себя. Нужны были выбор VIQR, позиция и состояние экранирования. Человекочитаемость помогала при отсутствии шрифта, но не отменяла синтаксис.

MIME метил вход, не выход

RFC 1456 указал MIME-имена VISCII и VIQR. Соответствующее тело должно было иметь правильный charset, однако общая совместимость с MIME не обязывала поддерживать эти наборы.

Метка была заявлением отправителя. Она не проверяла тело. Байты могли исчезнуть в шлюзе; программа могла знать имя без таблицы; правильные точки кода могли остаться без глифов.

Поздние правила MIME назначили US-ASCII для немаркированного plain text и рекомендовали явное указание. Потеря VISCII-метки возвращала шесть букв в область управления. Потеря VIQR могла оставить текст визуально понятным, но изменить поиск и обратное преобразование.

Текущий реестр IANA сохраняет VISCII и VIQR с MIBenum 2082 и 2083 и псевдонимами csVISCII и csVIQR. Реестр подтверждает стабильные идентификаторы, не современную распространённость или качество декодеров.

UTF-8 не был машиной времени

UTF-8 оставил US-ASCII на месте и расширил универсальный репертуар последовательностями переменной длины. Мировые письменности перестали конкурировать за 256 ячеек.

Старый объект всё равно требует старой грамматики. VISCII сначала читается по VISCII, VIQR разбирается в контексте, и лишь затем символы кодируются в UTF-8. Попытка сразу применить новый декодер создаёт новую версию смысла.

Визуальное совпадение не гарантирует одинаковые точки кода и нормализацию. Поиск, подписи и идентификаторы могут разойтись. Более широкий репертуар не уничтожил необходимость документировать преобразование.

Цепочка реальности

языковой знак → представление → байты → charset → анализатор → точки кода → глифы → чтение

Хеш подтверждает файл, но не charset. Метка подтверждает декларацию, но не поддержку. Снимок подтверждает пиксели, но не обратимость. Человеческое чтение не показывает строку, которую индексировала машина.

Источники и границы

Статус и дата взяты со страницы RFC 1456. Число 134, VISCII, VIQR, отчёт о программах и граница безопасности — из RFC 1456. Современная ему рамка MIME дана в RFC 1341, поздние правила charset — в RFC 2046. Сравнение с UTF-8 основано на RFC 3629. Идентификаторы проверены по реестру наборов символов IANA. Разделение символа и исполняемого результата открыто опирается на Lu Heng: Running Code Is Primary и On Reality Layers.

Источники не доказывают всеобщее принятие, нынешнее использование, идеальную конверсию, реальную аварию архива или прямую причинность к Unicode. RFC 1456 не обсуждал безопасность. Декодирование не аутентифицирует отправителя и не подтверждает понимание.