이것은 문서의 이전 버전입니다!


Windows-949

마이크로소프트 윈도에서 사용하는 한글 문자 인코딩. 완성형 한글 인코딩(EUC-KR)의 확장이라 확장 완성형이라고도 불렀으며, 윈도에서 문자 인코딩을 부르는 이름을 따서 코드페이지 949라고도 부른다. (Windows-949는 공식 IANA 이름이다.) 윈도95에서 처음으로 도입되었으며, 그 이전에는 그냥 EUC-KR만이 지원되었다.

이 인코딩의 가장 큰 특징은, KS X 1001과 이를 그대로 사용한 EUC-KR이 한글을 2350자 밖에 못 표현하는데 비해 11172자의 모든 현대 한글을 2바이트 안에 표현할 수 있다는 점이다. 그러나 EUC-KR이 이미 A1 A1부터 FE FE까지의 모든 영역을 KS X 1001에 사용하기 때문에, Windows-949에서는 첫째 바이트가 81부터 C6까지, 그리고 둘째 바이트가 41~5A(로마자 대문자), 61~7A(로마자 소문자), 그리고 81~FE인 세 영역 중 앞에서 설명한 영역과 겹치지 않는 부분에 KS X 1001에 없는 한글 8822자(이하 "확장 한글")를 순서대로 할당해 놓았다. Shift_JIS와 매우 유사한 모양이 되어 있는데, Shift_JIS보다는 기존에 이미 할당된 공간이 훨씬 적기 때문에1) 상위 비트가 1이 아닌 둘째 바이트 때문에 문제가 생길 여지가 훨씬 적다. (적어도 Windows-949의 존재를 모르는 프로그램에서 확장 한글을 글자로조차 인식하지 못 하는 문제는 없다.)

2바이트로 모든 것을 끝내려는 노력2) 치고는 비교적 나쁘지 않은 결과였지만, 가뜩이나 완성형조합형논쟁으로 시끄러웠던 시절에 또 다른 완성형 인코딩이 도입된다는 소식 때문에 상당한 반발을 불러 일으켰다. 반발을 못 이긴 한국마이크로소프트상용완성형을 코드 페이지 1361로 추가하긴 했는데, 이게 WideCharToMultiByte 같은 함수에서만 쓸 수 있고 시스템 전체 코드 페이지를 바꿀 수는 없는 것이라 눈가리고아웅이었다. 결과적으로는 나중에 유니코드가 보편화되며 논쟁이 의미가 없게 되면서 유야무야되긴 했다.

EUC-KR과의 혼란

이 인코딩은 그 특성상 EUC-KR과 혼용되는 경우가 매우 많다. 비슷한 구조와 비슷한 역사를 지닌 일본어 문자 인코딩의 경우 EUC-JP와 Shift_JIS는 구조가 아예 다르기 때문에 혼용될 일이 없는데, Windows-949는 EUC-KR에 새로운 문자를 추가한 것에 불과하니 윈도의 시장 지배력과 맞물려 혼용되기 쉬울 수 밖에 없었다.

이 문제는 특히 웹에서 매우 심해서, EUC-KR이라고 쓰여 있는 거의 모든 웹페이지는 항상 Windows-949로 해석해야 할 정도이다. 이걸 쓰여 있는 곧이 곧대로 받아 들인 모질라 초기 버전에서는 EUC-KR이라 쓰여 있는 웹 페이지에서 확장 한글을 입력할 때 Windows-949 식으로 2바이트 인코딩을 쓰는 게 아니라 KS X 1001 8바이트 인코딩을 써서 다른 브라우저에서는 깨지는 괴현상을 일으키곤 했다. 덕분에 HTML5 표준에는 명시적으로 EUC-KR이라고 쓰여 있는 인코딩을 무시하고 무조건 Windows-949로 구현할 것을 요구3)하고 있을 정도니 말을 다 했다.

같이 보기

1) Shift_JIS에서는 JIS X 0201에서 특정한 범위의 첫 바이트를 모두 할당해 버렸기 때문에 둘째 바이트에서 훨씬 넓은 범위를 사용해야 했다.
2) 기술적으로는 KS X 1001에서도 확장 한글을 입력할 수는 있지만, 네 개의 글자로 표현해야 하는데다가 결정적으로 구현하는 곳이 거의 없다. 모질라가 거의 유일한 예.
3) HTML Living Standard §11.2.2.2 Character encodings. "Misinterpreted for compatibility"라고 부른다.

도쿠위키DokuWiki-custom(rev 9085d92e02)을 씁니다.
마지막 수정 2011-09-25 21:33 | 작성자 lifthrasiir