신 정 식
: > ISO-2022-KR, 7bit ISO-2022, 8bit EUC-KR 모두 KS C 5601이란 글자셋에 : > 바탕을 둔 인코딩 방법입니다. C-T에는 charset=EUC-KR(여기서 말하는 : > charset은 MIME charset으로 KS C 5601이 글자셋이라고 말할 때의 : > '글자셋'과 다른 의미)가 적혀 있고, C-T-E가 Base64로 된 것은 KS C : 5601의
: 그러니까, : EUC-KR이란 KSC 5601 글자셋의 Extended Unix Character로 코드 : 변환(인코딩)된 MIME 글자셋인가요? 아니면, EUC-KR 자체가 : 인코딩방법인가요?
저도 자세히 안다고 할 수 있는 처지가 아닙니다. 진짜 전문가인 최우형님이나 정주원님이 보면 이상하게 들릴 지도 모르지만, 설명을 해 보도록 하겠습니다. 사실, 전에 두 사람이 잠깐 비슷한 설명을 한 적이 있기도 합니다.
"좁은 의미의" KS C 5601은 실제로 컴퓨터 메모리나 파일 시스템에서 어떤 식으로 기록/표현되느냐와는 어느 정도 독립적인 "추상"적인 것입니다. 단지, (94 x 94의 행렬에) (원소로서) 한글,한자, 그리고 특수 문자들을 배치해 놓은 것 뿐입니다. 마찬가지로 글자셋으로서의 ISO-8859-1은 서유럽 언어의 표기에 필요한 US-ASCII에 없는 94개의 글자의 순차적 나열일 뿐입니다. 글자셋으로서의 US-ASCII(혹은 대응하는 한국 표준인 KS C 5636 또는 ISO 646?; US-ASCII와 KS C 5636의 차이는 US-ASCII의 '\'가 KS C 5636에서는 원화 표시 기호라는 점입니다)도 마찬가지로 영어 사용에 필요한 94개의 글자의 (순차적) 나열입니다. 인간에게 있어서는 다음과 같이 몇 개의 글자를 영어 표기를 위해 쓴다 혹은 한국어 표기를 위해 쓴다고 정해 놓기만 하면 각 글자가 바로 그 의미를 전달하므로 다른 표현 방법이 더 이상 필요 없습니다.
한국인이 쓰는 문서 - 한글,한자,특수 문자, 로마자,문장 부호 등-는 KS C 5601가 정의한 글자와 US-ASCII가 정의한 글자를 혼용해야 합니다. 이 경우에도 사람에게는 눈으로 보는 것만으로 둘은 분명히 다르고, 특별한 표현 (representation) 방법을 따로 만들 필요가 없습니다. 하지만, 컴퓨터 입장에서는 다릅니다. 이들 (추상적인) 글자셋에 들어 있는 각 글자를 컴퓨터가 잘 이해하는 내부의 표현 방법으로 표시해 주어야 합니다. 숫자 3은 1byte짜리 정수를 쓰고(MSB를 부호 비트로 쓴다면) 0000011로 숫자 -5는 11111011 로 표시하는 것과 비슷한 방식으로 '가'라는 글자를 표시할 방식을 고안해야 합니다. 또, 두 글자셋 (KS C 5601과 US-ASCII 혹은 KS C 5601과 KS C 5636)을 섞어 쓰기 때문에 이 표현 방법은 둘을 구별할 방법도 제공해 주어야 합니다.
이를 위해서는 같은 글자셋 안의 각 글자들을 구별할 수 있을 뿐 아니라 두 개의 글자셋 사이의 전환 혹은 구별을 표시할 방법이 필요합니다. 즉, 추상적인 글자셋을 구체적인 bit-stream으로 표기(represent)할 방법을 찾아야 합니다. 그런 방법들이 EUC-KR, ISO-2022-KR, Mule에서 쓰는 ISO-2022-Int(이 경우는 KS C 5601, US-ASCII 뿐 아니라 ISO-2022 scheme에 따라 얼마든지 원하는 글자셋을 한 문서에서 혼용할 수 있습니다. Unicode와는 다른 방식으로 ISO-2022에 의해 다국어 지원을 하는 것입니다) 등입니다. EUC-KR에서는 US-ASCII(KS C 5636)에 속하는 글자는 G0(??GL) 영역인 0x21-0xFE(94자)에 놓습니다. US-ASCII의 첫번째 글자는 0x21으로 94번째 글자는 0xFE로 표시하는 것입니다. 반면에 KS C 5601에 속하는 글자는 그 행수를 첫번째 바이트, 열수를 두번째 바이트에 쓰되 두 바이트 모두 0xA1-0XFE를 사용합니다. 즉 1행/1열 (01/01)의 글자는 16진수 A1A1으로 표시합니다. 하지만, EUC-KR은 8bit transparent 하지 않는 환경(프로그램,저장 장치나 전송 경로)에서는 쓸 수 없습니다. 그런 경우를 위해 쓸 수 있는 것이 하위 7bit만 사용하는 ISO-2022-KR이나 좀더 일반적인 ISO-2022-Int(Mule에서 쓰는) 등입니다. ISO-2022-KR에서는 선두에(KS C 5601에 해당하는 글자가 등장하기 전의 어느 곳이든지 줄의 처음에) 이것은 ISO-2022-KR입니다라고 알리는 "ESC$)C"의 네 글자로 된 지정자를 두고, KS C 5601는 2121 - 7E7E까지를 쓰고, US-ASCII는 21-FE까지를 써서 표시합니다 이렇게 하면 둘 다 21-7E를 쓰므로 둘을 구별할 방법이 필요합니다. 이때 쓰는 것이 SO와 SI입니다. ISO-2022-Int에서는 따로 지정자는 없고, US-ASCII가 나오면 ESC$B(이것은 확인 필요. 지금 기억에 의해 쓰고 있으므로 틀리 수 있습니다)를 KS C 5601이 나오면 ESC$(C (ISO-2022-KR의 지정자와는 닫는 괄호대신 여는 괄호가 쓰였다는 점이 차이입니다)를 씁니다. 다른 글자셋도 (ISO-8859-x,중국어,타이 글자셋) 고유한 Escape sequence를 가지고 있어서 그 글자셋으로 바꿀 경우에는 그 esc. sequence를 준 다음에 21-7E 사이의 글자를 써서 표시합니다. 일본어용 글자셋은 JIS X208, JIS X212, JIS X2?? 등 여러 가지가 있고, 이들을 한 문서에 다 같이 써야 제대로 일본어 표기가 가능하다고 합니다. 이들 글자셋을 섞어 쓰되 컴퓨터가 이해하는 형식으로 표현한 것이 EUC-JP(여기서는 3byte까지도 쓰입니다. 아마 중국어용 EUC-CN, EUC-TW는 4byte까지도 쓰일 것입니다), SJIS, New-JIS 등입니다.
이러한 EUC-KR, ISO-2022-KR, ISO-2022-Int, EUC-JP, SJIS 등이 coded character set 혹은 encoding (혹은 MIME charset)이라고 불리는 것입니다. ISO-8859-1은 두 가지 의미로 다 쓰입니다. (추상적인) 글자셋을 뜻하기도 하고, US-ASCII가 정의한 94자는 21-7E에 두고 ISO-8859-1의 94자는 A1-FE에 둔 방식으로 표시한 encoding/coded character set을 뜻하기도 합니다. MIME에서 얘기하는 (즉, Content-Type의 parameter인 charset의 값) 'charset'은 바로 '추상적인' 글자셋이 아니라 coded character set 혹은 encoding을 의미하는 것입니다. Emacs용의 대표적인 MIME package인 TM(tools for mime)의 저자는 대문자로 쓴 ISO-8859-1은 전자의 의미로 소문자로 쓴 iso-8859-1은 후자의 의미로 쓰고 있더군요. US-ASCII 역시 두 가지 의미로 다 쓰입니다. 영어 표기를 위한 94개 글자의 집합(사실은 제어 문자군의 32개의 글자까지 포함하므로 94자보다 많습니다) 을 뜻하기도 하고, 이 글자들을 구체적으로 21-7E(제어 문자는 00-1F)까지로 표시하는 coded character set/encoding/MIME charset을 뜻하기도 합니다.
지금까지의 설명이 제 의도대로 이해되었다면 EUC-KR과 ISO-2022-KR이 서로 동등한 위치에 있는 것이라는 것을 아실 수 있을 것입니다. 단지, EUC-KR만을 local storage용으로 쓰는 반면에 ISO-2022-KR은 local storage용으로는 쓰지 않고 메일 전송에만 쓰인다는 차이가 있을 뿐입니다. 즉, 한글 메일 전송 규약인 RFC 1557은 메일 전송을 위해 KS C 5601의 7bit encoding (coded character set/MIME charset)인 ISO-2022-KR을 본문에 쓰도록 규정하고 있습니다. 사용자가 MUA/MTA에 넘겨 준 메일의 본문이 ISO-2022-KR encoding이 아니고, 8bit EUC-KR encoding이라면 7bit ISO-2022-KR encoding(MIME charset/coded character set)으로 변환해서 보내야 하는 것입니다.
MIME에서 하나 더 도입한 'layer'는 transfer-encoding입니다. 이것은 말 그대로 MIME charset(coded character set/encoding)이 특정 전송 경로를 통해 온전히 전송되지 않을 경우에 그 전송 경로를 통해 안전하게 내용의 손실없이 전송할 방법을 마련하기 위해 고안한 것입니다. 대표적으로 Base64와 QP(Quoted Printable)가 있습니다. 더 정확히 얘기하면 8bit,7bit,binary도 있지요.
좀더 자세한 설명은 제 FAQ Subject 8(soc.culture.korean에서 찾을 수 있습니다)에서 언급한 참고 문헌들(Ken Lunde의 문서와 ifcss에 있는 문서,그리고 정주원님의 세미나 노트)에서 찾을 수 있습니다.물론, KS C 5601-19xx와 같은 표준 문서나 ISO-2022, ISO 646 등의 문서를 구할 수 있다면 그것도 좋은 자료일 것입니다(저도 한 번도 본 적이 없습니다).
제 설명은 어디까지나 아마추어로서 한 것이므로 모두 맞다고 볼 수 없습니다. 또, G0...G3, GL, GR,locking shift이니 하는 내용은 일부러 넣지 않기도 했습니다. 위 설명에서 잘못된 부분은 진짜 '전문가'들이 고쳐 주시리라 믿습니다. 덧붙여, 최근에는 위 설명에 부합하는 용어를 썼지만, 과거에는 제가 곳곳에서 쓴 용어도 이 글에 비추어 보면 틀린 것이 많았고, 제가 바로 혼동 - 특히 coded character/encoding/MIME charset과 character set 의 구별-을 초래한 원인 제공자이기도 했습니다. 이 글이 그런 혼동을 조금이나마 해소하는데 도움이 되기를 바랍니다.
신정식