RFC 1502: 표시 못 하는 글자는 빈자리를 보여라

요약

RFC 1502는 X.400 GeneralText가 사용한 문자 집합을 알릴 수 있지만, 개별 바이트의 뜻은 ISO 2022의 지정·전환 상태를 따라가야 알 수 있다고 설명했다.
받는 쪽은 출력 장치가 나타낼 수 없는 문자를 표시해야 하며, 같은 비트 위치의 자기 문자로 대체해 원문인 양 보여줘서는 안 된다. 보내는 쪽의 권장 작성법을 그대로 믿어서도 안 된다.

빈칸은 독자를 멈춰 세운다. 틀린 글자는 문장 속으로 자연스럽게 들어간다. 하랄드 알베스트란드는 1993년 8월 X.400의 확장 문자 집합을 다루면서, 이 두 번째 위험을 정면으로 다뤘다. 여러 문자 집합을 실어 나르는 기술이 생겼어도, 마지막 화면에서 원문을 지키는 일은 따로 남아 있었다.

GeneralText의 봉투와 본문 매개변수에는 사용된 문자 집합이 나열된다. 본문 안에서는 ISO 2022의 이스케이프와 전환 순서가 활성 집합을 바꾼다. 시작할 때는 G0에 IA5, C0에 표준 제어 집합이 있다고 가정한다. 다른 상태로 시작한다면 앞에서 알려야 한다. 나열된 집합은 목록일 뿐이다. 중간에 있는 바이트 하나를 해석하려면 그곳까지 거친 상태 변화를 따라가야 한다.

RFC는 보내는 사람에게 US-ASCII를 G0에 두고, 맞는 경우 ISO 8859 집합을 G1에 쓰라고 권했다. ASCII 부분의 비트 표현을 지키는 방법이었다. 그러나 받는 프로그램에는 그 권고가 지켜졌다고 가정하지 말라고 했다. 실제 우편은 서로 다른 소프트웨어와 게이트웨이를 건너온다. 읽어야 하는 것은 이상적인 작성법이 아니라 도착한 흐름이다.

네 번째 절의 화면 규칙은 명료하다. GeneralText를 다룰 수 있는 프로그램은 IA5와 자기에게 익숙한 문자 집합을 알아보고, 출력 장치가 제대로 나타내지 못하는 글자의 존재를 항상 알려야 한다. 모르는 문자 집합의 글자를 같은 비트 자리에 있는 자기 문자로 찍어서는 안 된다. 숫자 자리가 같아도 글자의 뜻은 같지 않다.

대체 표기를 보여주는 보기와 표시 불가능한 지점을 드러내는 보기를 함께 제공하고, 문자 집합 정보까지 담아 원본을 저장하라는 권고도 있다. GeneralText를 MIME 같은 다른 형식으로 바꾸는 게이트웨이에도 이 원칙이 적용된다. 읽기 쉬운 사본을 만들더라도 나중에 원문을 다시 판독할 실마리는 남겨야 했다.

변환 대상 집합에 글자가 없을 때는 대체 제어 문자, 별도 설명이 필요한 니모닉 표기, 사람이 알아볼 만한 대용 표현, 또는 변환 거절을 선택할 수 있었다. 메시지가 손실을 금했다면 거절만 남는다. RFC Editor의 현재 기록은 RFC 1502를 Historic으로 분류하지만, 1993년 원문은 당시의 표준화 경로를 적었다. 특정 메일 프로그램의 실제 화면은 기록하지 않았다. 문서가 남긴 요구는 또렷하다. 기계가 그릴 수 없는 글자를, 작성자가 쓰지 않은 글자로 메우지 말 것.