요약

  • RFC 1468은 일본어 메일을 위한 좁은 7비트 전환 프로파일에 이름을 붙였습니다. 이스케이프 시퀀스가 ASCII, JIS X 0201 로만, 또는 두 가지 JIS X 0208 버전 중 하나를 선택하며, 2바이트 문자를 담은 모든 줄은 CRLF 앞에서 그 상태를 벗어나야 했습니다.
  • MIME 라벨은 의도된 디코딩 계약을 식별해 주었지만, 본문이 그 문법을 따랐는지, 중계 장비가 지정 바이트를 보존했는지, 디코더가 같은 문자를 재구성했는지, 독자가 의도한 글리프를 보았는지를 증명하지는 않았습니다.

일본어 메시지에서 가장 영향력이 큰 바이트는 아무것도 인쇄하지 않는 바이트였을 수 있습니다.

1993년 6월,RFC 1468은 JUNET 등 일본 IP 커뮤니티에서 이미 사용되던 인코딩을 문서화했습니다. 저자들은 그것을ISO-2022-JP라고 부르며, 이 이름을 MIMEcharset매개변수용으로 의도했습니다. 이 성취는 익숙한 슬로건으로 압축되기 쉽습니다. 일본어 텍스트가 인터넷 메일에서 식별 가능해졌다는 것입니다. 그러나 그 메커니즘은 훨씬 정밀했습니다. 한 눈에 보이는 문장이 여러 문자 체계를 통과할 수 있었던 이유는, 보이지 않는 이스케이프 시퀀스가 그 이후의 모든 바이트를 읽는 방식을 바꾸었기 때문입니다.

이 차이 때문에 RFC 1468은 유니코드로 가는 길목의 각주 그 이상입니다. 그것은 상호운용성이 '보존된 상태'라는 사실을 담은 압축된 역사입니다. 발신자는 문자를 고르고 라벨을 붙이는 데 그치지 않았습니다. 해석이 이전 전환 이력에 의존하는 시퀀스를 만들었습니다. 중계 장비는 두 시퀀스를 동등해 보이게 표시할 수 있으면서도 하나를 다른 것으로 대체하는 것은 금지되어 있었습니다. 줄바꿈은 단순한 조판이 아니라 복구 경계였습니다. 마지막에 ASCII로 돌아오는 것은 메시지의 디코딩 가능성의 일부였습니다.

이름이 기계를 선택했다

RFC는 ASCII에서 시작합니다. 세 바이트 —ESC $ B— 는 JIS X 0208-1983을 지정하며, 그 이후 문자는 각각 2바이트를 차지합니다.ESC $ @는 1978년 버전을 선택합니다.ESC (J는 JIS X 0201의 로만 세트를 선택하고,ESC (B는 ASCII로 되돌아갑니다.

이 네 가지 선택은 라벨이 붙은 네 개의 독립 블록을 묘사하는 것이 아닙니다. 하나의 진행 중인 해석을 바꿉니다. JIS 지정자 뒤에 바이트 쌍이 도착하면 그것은 94×94의 2바이트 공간에 속합니다. ASCII 리셋 이후의 같은 값들은 더 이상 일본어 문자 쌍이 아닙니다. 디코더는 마지막 유효 지정을 기억해야 하며, 바이트 하나가 그 의미 전체를 홀로 갖지는 못합니다.

두 개의 1바이트 상태조차 서로 교환 가능하지 않았습니다. JIS X 0201 로만은 백슬래시 또는 엔, 물결표 또는 상효선으로 렌더링되는 위치에서 ASCII와 다릅니다. 두 상태가 "충분히 비슷해 보인다"고 단언하는 시스템은 자신의 운영자에게는 그 구분을 숨기면서도 다음 구현에는 결정적인 사안으로 남겨둘 수 있습니다. 프로파일은 JIS X 0201 가나 세트도 배제했습니다. 반각 가타카나는 일본어 라벨 뒤에 숨어 기다리는 다섯 번째 암묵적 상태가 아니었습니다.

따라서ISO-2022-JP라는 이름은 민족적·언어적 범주가 아니라 작은 디코더를 선택했습니다. "아마 일본어가 들어 있을 어떤 바이트들"이라는 뜻이 아니었습니다. 본문이 이 지정, 이 범위, 이 배제, 이 리셋을 따라야 한다는 뜻이었습니다. 라벨이 유용했던 이유는 그 뒤의 기계가 유한하게 한정되어 있었기 때문입니다.

모든 줄이 자기만의 귀환로를 가졌다

RFC 1468은 JIS X 0208 문자를 담은 줄이 종결 CRLF 앞에서 ASCII 또는 JIS X 0201 로만으로 전환할 것을 요구했습니다. 다음 줄은 이전 줄이 끝나기 전 선택된 1바이트 상태로 시작합니다. 전체 텍스트는 ASCII로 끝나야 합니다.

이 규율은 제한된 재동기화 지점을 제공했습니다. 나중 줄부터 읽기 시작하는 독자는 메시지 처음부터의 무한한 2바이트 지정 이력을 재구성할 필요가 없습니다. 인용 프로그램은 줄 앞에>를 삽입하면서 일본어 문자 쌍 한가운데에 ASCII처럼 보이는 바이트를 우연히 주입하지 않을 수 있습니다. 손상되거나 잘린 줄이 뒤따르는 모든 줄에 같은 2바이트 해석을 물려주지 않아도 됩니다.

리셋이 만능 해결책은 아니었습니다. RFC 1468은 줄 끝에서 JIS X 0201 로만으로 돌아가는 것을 허용했으므로, 구현은 여전히 그 상태와 ASCII를 구분해야 했습니다. CRLF가 줄을 감싸더라도, 홀로 있는 CR 또는 LF는 형식 문법 아래에서 여전히 가능한 보통 7비트 값이었습니다. 경계에서의 잘못된 이스케이프는 여전히 구현들의 오류 정책에 따라 갈라지게 만들 수 있었습니다. 그러나 이 설계는 상태가 얼마나 멀리 전파될 수 있는지를 제한했습니다. 오래된 메일 도구들이 이미 검사점을 기대하던 자리에 검사점을 놓았습니다.

이것이 가장 실용적인 형태의 최소 명세입니다. 프로파일은 모든 중계 장비에 일본어 이해를 요구하지 않았습니다. 발신자에게 7비트 경로가 전달할 수 있고 규격 엔드포인트가 예측 가능하게 재시작할 수 있는 스트림을 만들 것을 요구했습니다. 호환성은 네트워크를 전지적으로 만드는 것이 아니라 공유 상태를 좁혀서 얻어졌습니다.

7비트는 폭을 해결했을 뿐 해석을 해결하지 않았다

문서의 MIME 예는Content-Type: text/plain; charset=iso-2022-jp입니다. 허용된 모든 값이 7비트 안에 들어가므로, 본문은 7비트 메일 시스템을 통과하기 위해서만큼은 추가 콘텐츠 전송 인코딩을 요구하지 않았습니다.

그 성질은 들리는 것보다 좁습니다. 7비트 안전한 메시지도 이스케이프 바이트 하나를 제거하거나, 지정을 정규화하거나, 2바이트 문자를 쪼개거나, 잘못된 상태에서 디코더를 적용하면 의미론적으로 파괴될 수 있습니다. 전송 수용은 값이 경로의 옥텟 봉투에 맞는지를 답합니다. 각 옥텟이 자신의 위치와 기능을 유지하는지는 답하지 않습니다.

RFC 1468은 Base64나 quoted-printable이 당시 JUNET 소프트웨어에서 그런 메시지를 읽을 수 없게 만들 것이라 경고했습니다. 날짜가 중요합니다. 정확히 적용되고 정확히 되돌려진다면 그 인코딩들은 원본 바이트를 본질적으로 지우지 않습니다. 그 경고는 설치 기반의 한계를 기록한 것입니다. 네이티브 7비트 프로파일을 아는 소프트웨어가 추가 MIME 전송 계층을 이해하지 못할 수 있었습니다. 형식적으로 가역적인 표현조차 실제 네트워크를 이루던 구동 중인 클라이언트들에서 실패할 수 있었습니다.

교훈은 오래된 소프트웨어가 모든 확장을 거부권으로 막아야 한다는 것이 아닙니다. 배포 가능성은 변환이 구현과 만나는 지점에서 측정된다는 것입니다. 공표는 이용 가능한 계약을 세웁니다. 커뮤니티가 실제로 어떤 조합을 주고받을 수 있는지는 구동 중인 코드만이 보여줍니다.

중계 장비는 해석 면허 없이 보관 책임을 가졌다

RFC에는 이례적으로 날카로운 지침이 있습니다. 일부 시스템은 텍스트를 표시할 때ESC (B와ESC (J를, 또는ESC $ @와ESC $ B를 구분하지 않았습니다. 그럼에도 중계 장비는 이스케이프 시퀀스를 정확히 보존해야 했습니다.

이것은 지역적 동등성과 전달 가능한 동일성을 분리합니다. 중계 장비의 화면이 다음 수신자가 무엇을 구분할 수 있는지의 권위가 아니었습니다. 1978년과 1983년 JIS 지정자는 특정 메시지에서 우연히 같은 글리프를 낼 수 있었습니다. 그래도 하나를 다른 것으로 대체하면 선언된 문자셋 이력을 다시 쓴 것입니다. 백슬래시/엔 구분은 어떤 폰트에서는 보이지 않고 다른 폰트에서는 보일 수 있었습니다. 이후의 파서, 아카이브 비교, 변환 도구는 현재 운영자가 신경 쓰지 않더라도 신경 쓸 수 있었습니다.

바이트 보존은 책임을 추적 가능하게 유지했습니다. 목적지가 다른 문자를 렌더링했다면, 건드리지 않은 원본 스트림 덕분에 불일치를 디코딩이나 표시 단계에서 찾아낼 수 있었습니다. 선의로 정규화하는 중계 장비는 그 법칙적 경계를 지워버립니다. 보내진 것에 대한 증거를 파괴함으로써 더 깔끔해 보이는 지역 복사본을 만들 수 있었습니다.

그 규칙은 중계 장비를 의미의 보증인으로 만들지는 않았습니다. 정확한 보관은 발신자의 지정이 유효하다는 것도, 본문이 참인 명제를 표현한다는 것도 증명하지 않습니다. 그것은 더 작지만 없어서는 안 될 것을 말합니다. 이 중개자가 발신자의 인코딩된 객체를 자신의 해석으로 대체하지 않았다는 것입니다.

표시는 다른 좌표계를 점유했다

RFC 1468은 사람 작성자에게 따옴표를 삽입할 수 있도록 약 75~80 표시 열 근처에 머물 것을 권고했습니다. 그 모델에서 JIS X 0208 문자는 2바이트이자 2열을 소모하고, 이스케이프 시퀀스는 바이트를 소모하되 0열을 소모합니다. 구현은 표시 줄바꿈 중에 2바이트 문자를 쪼개지 말도록 상기되었습니다.

따라서 한 줄 안에는 적어도 세 개의 위치가 존재합니다. 바이트 오프셋, 문자 위치, 표시 열입니다. ASCII 연속 구간에서는 이들이 일치하다가 지정자에서 즉시 갈라집니다. 바이트 80에서 줄을 자르는 도구는 쌍을 자를 수 있습니다. 검증 전에 폭 0 제어 문자를 벗겨내는 도구는 상태를 버릴 수 있습니다. 75열의 단정한 줄을 보여주는 화면은 그 자체로 밑에 있는 표현이 유효한지 아무것도 말해주지 않습니다.

현대의 렌더링은 디코딩된 스칼라 값, 폰트 커버리지, 셰이핑, 폴백, 레이아웃 등 더 많은 계층을 더하지만, 역사적 요점은 이미 1993년 텍스트 안에 있습니다. 무엇이 이동하는가와 무엇이 공간을 차지하는가는 같은 객체가 아닙니다. 스크린샷은 모든 입력 바이트를 재구성할 수 없고, 바이트 해시는 사용자가 어떤 글리프를 보았는지 증명하지 못합니다.

등록은 약속을 안정화했을 뿐 결과를 안정화하지 않았다

이후RFC 2046은 charset 매개변수를 MIME 텍스트에 결정적이라고 설명하며, 본문이 전적으로 명명된 charset의 문자로 구성된다고 말했습니다.RFC 2978은 용어를 더 명확히 했습니다. charset은 옥텟 시퀀스를 문자로 변환하는 방법으로서, 복잡한 ISO 2022 전환 기법을 포함하며, 등록된 정의는 그 사상을 완전히 명시해야 한다고 규정했습니다.

현재IANA 문자셋 레지스트리는ISO-2022-JP를 MIBenum 39로 기록하고, RFC 1468과 RFC 2237을 인용하며,csISO2022JP를 별칭으로 나열합니다. 그 레지스트리 항목은 구현들 사이에서 이름을 조정합니다. 그러나 변환을 실행하지 않습니다. 본문을 검사하지 않고, 게이트웨이를 인증하지 않고, 폰트를 선택하지 않고, 현재 사용량을 측정하지 않습니다.

RFC Editor 메타데이터는 RFC 1468을 인터넷 표준이 아닌 정보성(Informational) 문서로 기록합니다. 어느 쪽 라벨도 실제 이상으로 확대 해석되어서는 안 됩니다. "정보성"이라는 표시가 문서의 역사적 운영 관련성을 지우지는 않습니다. IANA 이름이 그 이름을 달고 있는 모든 메시지를 규격 준수의 증거로 끌어올리지는 않습니다. 문서적 지위, 네임스페이스 안정성, 배포된 행동은 서로 다른 세 개의 영수증입니다.

확장에는 또 다른 이름이 필요했다

한정된 프로파일은 변화도 보이게 만들었습니다. 6개월 뒤,RFC 1554는 실험적인ISO-2022-JP-2다국어 확장을 기술했습니다. 중국어, 한국어, 보조 일본어, 그리스어·라틴 문자 지정을 추가하고, 두 번째 지정 레지스터를 도입했으며, 각 새 줄마다 일부 상태를 초기화했습니다. 더 넓은 디코더에는 별도의 MIME 이름이 주어졌습니다.

1997년,RFC 2237은ESC $ (D로 JIS X 0212를 추가하는ISO-2022-JP-1을 정의했습니다. 최종 ASCII 규칙을 유지하며, 보조 세트가 없을 때는 보통ISO-2022-JP를 사용해야 한다고 밝혔습니다. 확장이 원래 라벨 아래에 조용히 깔리지는 않았습니다.

이것은 레지스트리 정리 그 이상입니다. 같은 이름이 새로운 관찰 가능한 계약 없이 새 상태를 흡수할 수 있다면, 오래된 디코더는 낯선 바이트가 오류인지 정당한 미래 확장인지 알 수 없습니다. 별도로 명명된 프로파일은 발신자가 더 큰 요구사항을 선언하게 하고, 수신자가 그것을 정직하게 거절하게 합니다. 호환성은 지역적이고 명시적으로 유지됩니다.

근거는 독자 앞에서 끝난다

표준들은 규격 스트림이 어떻게 형성되어야 하는지를 확립합니다. 특정 개인이 무엇을 보았는지는 확립하지 않습니다. 방어 가능한 재구성은 MIME 필드, 원본 본문 바이트, 상태 전환 추적, 중계 변환, 디코더 버전, 디코딩된 문자 시퀀스, 폰트, 렌더링 결과를 분리해 둡니다.

공개된 세 편의 Lu Heng 에세이는 그 경계를 더 선명하게 합니다.Minimum Initial Specification은 작은 공통 프로파일이 모든 지역적 선택을 지시하지 않으면서 독립적 구현을 지탱할 수 있는 이유를 설명합니다.Running-Code Primacy는 공표된 프로파일이 배포된 행동과 혼동되는 것을 막습니다.On Reality Layers는 라벨, 바이트 스트림, 디코딩된 텍스트, 표시된 글리프, 사람의 반응이 하나의 상징적 사실로 압축되는 것을 막습니다.

RFC 1468의 지속적 성취는 모든 일본어 메시지를 자기증명적이게 만든 것이 아니었습니다. 하나의 좁은 디코딩 이력을, 표시를 공유하지 않는 시스템들 사이를 건널 수 있을 만큼 휴대 가능하게 만든 것입니다. 그 이름은 올바른 규칙집을 열어주었습니다. 인쇄되지 않은 전환들이 텍스트를 실재하게 만들었습니다.