요약

  • RFC 1922는 중국어 문자를 포함하는 ISO-2022-CN의 모든 줄이 자체 지정(designation)을 포함하고 CRLF 앞에서 ASCII로 되돌아오도록 요구했습니다. 그 결과 화면은 임의의 줄에서 시작하면서도 앞선 텍스트의 보이지 않는 상태를 물려받지 않을 수 있었습니다.
  • 지정, 잠금 시프트, 단일 문자 시프트는 여러 중국어 문자 레퍼토리를 7비트 스트림에서 사용할 수 있게 만들었습니다. 이는 바이트 문법이 입증된 것이지, 전달·폰트 커버리지·발신자 신원·사람의 이해가 입증된 것이 아니었습니다.
  • 판(edition)과 벤더 확장 매개변수는 메시지가 어떤 레퍼토리를 기대했는지 드러냈습니다. RFC는 불일치를 서술 가능하게 만들었고, 실제 구현된 디코더·전송 경로·폰트만이 텍스트를 동작 가능하게 만들었습니다.

20번째 줄은 19번째 줄의 메모리를 빌릴 수 없었다

상태 기반 인코딩은 이후 바이트의 해석 방식을 바꿈으로써 절약을 이룹니다. 그러나 이 거래는 읽는 사람이 첫 바이트부터 시작하지 않을 때 취약해집니다. 메일 리더는 현재 창만 보여줄 수 있습니다. 인용이 중간에서 시작할 수도 있습니다. 손상된 앞부분이 사라지고 뒤의 줄만 남을 수도 있습니다. 활성 문자 집합이 이전 이스케이프 상태에만 존재한다면, 보이는 바이트는 온전하더라도 전혀 다른 의미가 될 수 있습니다.

1996년 3월 Informational 문서로 발표된 RFC 1922는 줄을 복구 경계로 만들었습니다. ISO-2022-CN은 ASCII에서 시작합니다. 어떤 줄이 중국어 문자를 사용하면 그 줄에서 필요한 지정을 다시 반복했습니다. CRLF 앞에서 인코더는SI를 내보내 ASCII로 되돌아갔습니다. 다음 줄은 알려진 상태에서 시작합니다.

이 추가 바이트는 장식이 아니었습니다. 숨겨진 이력을 국소적 증거로 바꾼 것입니다. 디코더는 앞의 모든 줄을 관찰했다는 신뢰 없이도, 현재 줄이 실어 온 내용만으로 현재 줄을 재구성할 수 있었습니다. 이 설계는 실패 범위도 좁혔습니다. 잘못되었거나 유실된 지정 하나가 한 줄을 손상시킬 수는 있어도, 이후 모든 줄을 조용히 재정의하지는 않습니다.

지정은 표를 고르고, 시프트는 순간을 골랐다

ISO-2022-CN은 쉽게 하나로 뭉쳐지는 두 결정을 분리했습니다. 이스케이프 지정은 등록된 문자 집합을 레지스터에 연결합니다. 시프트는 이후 바이트를 어떤 레지스터가 해석할지 선택합니다.SO는 지정된 더블바이트 집합으로 들어가고SI는 ASCII로 돌아갑니다. 같은 레지스터에 대한 이후 지정은 이전 것을 대체합니다.

SS2와SS3는 짧은 차용이었습니다. 각각 다음 두 바이트—중국어 한 글자—에만 적용되고, 해석은 이전SI/SO상태로 돌아갑니다. 이 복귀가 중요했습니다. “중국어 모드”만 기록하는 모니터는 어떤 집합이 지정되었는지, 변경이 잠금인지 단일 시프트인지, 이전 상태가 어디서 복귀하는지 잃어버립니다.

확장 형식인 ISO-2022-CN-EXT는 추가 등록 집합과 플레인을 허용했습니다. 규격은 아직 존재하지 않는 등록을 위한 플레이스홀더 최종 문자를 담은 이스케이프 패턴을 예약했으나, ISO가 배정하기 전까지 사용을 금지했습니다. 문법에 빈 코드 포인트가 있다는 것은 공적 의미를 만들어내는 허가가 아니었습니다.

일곱 개의 깨끗한 비트와 여덟 개의 취약한 비트

7비트 형식은 통과해야 할 메일 인프라의 모양을 따랐습니다. ISO-2022-CN과 ISO-2022-CN-EXT는 모든 옥텟을 128 미만으로 유지했으므로, 상위 비트 보존 자체만으로는 Content-Transfer-Encoding을 필요로 하지 않았습니다. 그렇다고 모든 메시지가 안전해지는 것은 아니었습니다. MIME 라벨, 합법적 이스케이프 상태, 능력을 갖춘 디코더가 여전히 중요했습니다.

8비트 대안들은 다른 노출을 지녔습니다.CN-GB와CN-Big5는 7비트 경로에서는 Base64 또는 Quoted-Printable로, 실제로 SMTP의 8BITMIME 확장이 협상된 경로에서는 그대로 전송될 수 있었습니다. 구식 7비트 메일러를 통과한 생 8비트 텍스트는 상위 비트를 잃고 읽을 수 없게 될 수 있었습니다. 발신자의 로컬 성공이 나머지 경로를 보증하지는 못했습니다.

이 구분은 세 기록을 분리해 두었습니다. MIME charset은 의도된 해석을 명명합니다. Content-Transfer-Encoding은 제약된 전송을 가로질러 표현을 보호합니다. 8BITMIME은 전송 능력을 협상합니다. 어느 것도 작성자를 인증하거나, 수신 폰트를 보장하거나, 화면에 실제로 나타난 것을 증명하지 않습니다.

한 해가 진실이 되지 않고 실수를 줄일 수 있었다

중국어 표준은 판(edition)이 바뀌었습니다. RFC 1922는charset-edition을 도입하여 메시지가 기대하는 판의 연도를 명시할 수 있게 했습니다. 매개변수를 이해하는 구현은 올바른 매핑을 고를 수 있었습니다. 이해하지 못하는 구현은 매개변수를 무시하도록 지시받았는데, 이 경우 새로운 기본값을 만들어내는 대신 이전 판 기준의 제한된 수의 오류로 표시될 수 있었습니다.

charset-extension은 또 다른 발산 원천, 즉 벤더나 로컬 글리프 확장을 다루었습니다. 등록된 값과 사설x-이름은 메시지가 추가 레퍼토리에 의존함을 드러낼 수 있었습니다. 라벨은 진단을 개선하지만 빠진 글리프를 만들어낼 수는 없습니다. 실제로 RFC는 이런 확장이 상호운용성을 떨어뜨릴 수 있다고 경고했습니다.

Big5와 CNS 11643도 같은 경계를 드러냈습니다. 변환 표와 벤더 매핑은 구현의 책임으로 남았습니다. 유효한 바이트 스트림은 레퍼토리를 정확히 명명하면서도, 표·판·폰트가 다른 디코더와 마주할 수 있었습니다. 인코딩은 글리프 전통을 시사할 뿐, 발신자의 국적이나 읽는 사람의 해석을 증명하지 않습니다.

줄에는 물리적 폭도 있었다

RFC 1922는 화면 배치를 운영상 상호운용성의 일부로 다루었습니다. 이스케이프 시퀀스는 바이트를 차지하지만 칼럼은 차지하지 않습니다. 중국어 한 글자는 보통 두 바이트, 두 화면 칼럼을 차지합니다. 구현은 두 바이트를 줄 사이에서 쪼개지 말도록 지시받았고, 메일 인용이 삽입하는>를 위한 여유를 두며 줄을 약 75칼럼으로 유지하도록 권장되었습니다.

이것은 소박한 형태의 종단 간 현실감이었습니다. 문법은 올바르면서 회답 동작이 여백에서 그 문법을 훼손할 수 있습니다. 인용을 위한 예산을 마련하고 각 줄이 상태를 복원하게 함으로써, 이 인코딩은 깨끗한 운반을 가정하는 대신 메일 소프트웨어가 수행하는 평범한 변형을 예상했습니다.

관련 문서는 맥락이지 채택이 아니었다

주요 기록은RFC 1922입니다.RFC 1468과RFC 1557은 관련된 일본어·한국어 7비트 메일 설계를 제공합니다.RFC 1521은 당시의 MIME 프레임워크를,RFC 1652는 협상된 8비트 SMTP 경계를,RFC 2046은 이후의 MIME 미디어 타입 명확화를 제공합니다.RFC 3629는 이후의 UTF-8 표준화를 기록합니다.

함께 보면 이는 설계 궤적이지 설치 조사가 아닙니다. RFC 1922는 적어도 ISO-2022-CN의 송수신과 가능한 한 많은 기술된 인코딩의 수신을 권장했습니다. 특정 제품이 준수했는지, UTF-8로의 이행이 자동적이며 무손실이었는지는 증명하지 않았습니다. 보안 고려 사항 절에서는 보안이 논의되지 않았다고 명시했습니다.

러닝 코드 우선성은 여기서 이후의 규율로 유용합니다: RFC와 등록된 이름은 조정 표면을 서술하지만, 파서·릴레이·폰트가 운영 현실을 결정합니다.최소 초기 규격, 지역화된 미래 결정, 자발적 채택은 경계를 더 명확히 합니다. 결정론적 공통 코어는 작았습니다—지정, 시프트, 바이트 범위, 리셋—반면 레퍼토리 지원과 채택은 국소적으로 남았습니다. 어느 노트도 RFC 저자들의 의도에 대한 증거가 아닙니다.

RFC 1922의 지속적인 성과는 몇 바이트의 반복을 지불하여 현재가 보이지 않는 과거에 의존하지 않도록 한 것입니다. 모든 줄이 ASCII로 돌아왔고, 그 후퇴가 중간을 읽을 수 있게 만들었습니다.