CP949

한글의 전산화
<colbgcolor=#dddddd,#212121> 한글 인코딩	조합형 · 완성형( 한글 목록 · 중복 한자 · CP949) · 조합형 완성형 논쟁 · 남북한 한글 코드의 충돌 문제 · 한컴 2바이트 코드 · 한글 채움 문자( ㅤ) · 유니코드 · 옛한글
타자기와 키보드	두벌식 · 세벌식( 일반 자판 · 속기 자판) · 휴대전화 입력기 · 한영 키

1. 개요2. 개발 이유3. 도입4. EUC-KR과의 혼동5. 방식6. 유사품7. 관련 문서8. 외부 링크

1. 개요

한국어판 Microsoft Windows의 기본 코드 페이지로, 한글 인코딩의 한 종류이며 EUC-KR의 확장형이다. '통합 완성형'이나 '확장 완성형'이라고도 한다. 마이크로소프트가 개발했기 때문에 MS949, Windows-949 등으로도 불린다.

2. 개발 이유

KS C 5601:1987를 베이스로 삼은 EUC-KR은 현대 한글에서 자주 이용되는 2350자만을 지원하였기 때문에, '으쌰으쌰'가 '으?으?'으로 표기되는 등의 문제가 발생하였다. 게다가 쓩처럼 완성형에는 있는데 중간에 나오는 문자(쓔)가 없어서 입력이 불가능한 사례도 있었다. 이에 따라 나머지 8000여자를 지원하는 인코딩의 필요성이 대두되었다.

KS X 1001 자체에는 한글 채움 문자를 사용하여 없는 글자를 표현하는 방식이 정의되어 있지만 구현상의 어려움으로 인해 Mozilla Firefox를 포함한 몇몇 앱밖에 지원하지 않는다.

3. 도입

CP949는 마이크로소프트가 제정한 규격으로, 한글 Windows 95에 처음으로 탑재되었다.[1][2] 등장 초기에는 코드순 정렬 방법으로 가나다순 정렬을 구현할 수 없다는 단점과, 마이크로소프트의 독자규격이 사실상 표준으로 군림하게 됨에 따른 거부감 등의 이유로 많은 질타를 받았으며, 특수 프로그램(HWP, IME[3])을 사용해 가면서 조합형을 고집하는 사람들도 있었다. 이후 시간이 지나면서 이러한 논쟁은 잊어졌다.

현재 윈도우 커널에는 유니코드가 적용되었지만, 한글 윈도우의 명령 프롬프트가 사용하는 기본 인코딩은 여전히 CP949라서 C, C++ 등의 네이티브 프로그래밍 언어를 이용해 UTF-8로 한글 출력을 하려고 하면 한글이 깨져 나오게 된다. PowerShell도 CP949를 사용하지만 UTF-8 등 다른 인코딩으로 변경이 가능하니 이쪽을 이용하자.

4. EUC-KR과의 혼동

CP949는 Shift_JIS와 EUC-JP처럼 전혀 다른 인코딩이 아니라 단순히 EUC-KR을 확장한 수준이기에 둘을 혼동하는 경우도 흔하다. 이 때문에 EUC-KR과 CP949를 구분하거나, 드물게 EUC-KR만을 지원하는 프로그램에서는 CP949로 작성된 텍스트 파일을 열었을 때 문제가 발생하기도 한다.

한국어 웹사이트 중에는 인코딩으로 EUC-KR을 선언해 두고 CP949로 인코딩된 페이지를 보내는 웹사이트들도 많았는데, 이 때문에 HTML5에서는 아예 EUC-KR로 선언했을 때에도 무조건 CP949로 해석하도록 표준이 정해졌다.

Notepad++의 경우 EUC-KR과 CP949를 구분하는데, 어째 CP949로 작성된 문서를 Notepad++로 열면 시스템 기본 인코딩(ANSI)으로 읽는 경우가 흔하다. 한글 윈도우에서는 기본 인코딩 자체가 CP949라 잘 나오지만, 다른 언어 윈도우에서는 당연히 글자가 깨진다. 둘을 굳이 구분해둔 이유는 프로그래밍 시 둘을 다르게 사용하는 경우가 존재해서 그런 듯하다.

5. 방식

CP949에서 새로이 추가된 8000여자는 다음 규칙에 따라 가나다순을 차례대로 2바이트로 할당받았다.

첫 번째 바이트는 0x81~0xC6 사이를 할당받는다.
두 번째 바이트는 0x41~0x5A(대문자 A~Z), 0x61~0x7A(소문자 a~z), 0x81~0xFE를 할당받는다.
단, EUC-KR와의 충돌을 피하기 위해, 첫 번째 바이트가 0xA1 이상인 경우에는 두 번째 바이트가 0xA0을 초과하지 않도록 제한한다.

EUC-KR 자체에는 할당되지 않은 바이트가 꽤 있기 때문에 Shift_JIS에 비해서는 확장이 수월한 편이었으며, 덕분에 호환성 문제도 훨씬 적다. Shift_JIS의 경우에는 반각 가타카나가 확장 영역의 상당수를 잡아먹고 있기 때문에 둘째 바이트의 범위를 엄청나게 넓혀야 했다. 당연히 0x5C 문제도 없다.

6. 유사품

Mac OS 클래식에는 애플판 CP949라고 할 수 있는 "MacKorean"이라는 문자셋이 있었지만 소리소문없이 묻혀 버렸다. MacJapanese의 영향을 받은 건지 표준 KS X 1001에 비해 쓸데없는 특수문자들이 잔뜩 들어가 있는 차이점이 있었다. 지금은 macOS의 문자표에서 그 흔적을 찾아볼 수 있을 뿐이다.

거의 쓰이지 않지만 IBM이 정의한 코드 페이지 949라는 것이 또 있다. 이 인코딩은 EUC-KR에서 싱글 바이트 코드 0x80-0x84와 더블 바이트 코드 0x8FA1~0xA0FE 영역에 약간의 커스텀을 추가한 것으로, MS의 CP949와는 EUC-KR 영역을 제외하고는 전혀 호환되지 않는다. Java는 이 인코딩을 CP949로, MS의 CP949는 MS949로 이름붙여 놓았기 때문에 혼동하기 쉽다.

7. 관련 문서

8. 외부 링크

문자 집합 위키의 CP949 표

[1] 당시에는 MS-DOS 및 Windows 3.x와의 하위 호환 문제로 인해 출력만 가능하고 입력은 불가능하도록 제약이 걸려있었다. Windows 98부터는 입출력 모두 가능하게 되었다. 그래서인지 당시에는 Windows 95에 CP949를 탑재하려다가 반발로 인해 무산되었다고 잘못 아는 사람들이 많았다. 이는 한/글 97의 도움말에도 나오는 내용인데, 조합형의 우수성을 강조하면서 "윈도우즈 95 한글판에서 통합형 코드 체계가 결정적으로는 채택되지 않은 것이 그나마 천만의 다행이었던 것입니다."라고 적힌 내용이었다. [2] 물론 Moziske같은 확장 문자표로 불러올수 있었다. Global IME도 가능한데 호환 앱(IE, Office 2000)에서 타 언어의 IME로 바꾸고 다시 바꾸면 확장완성형으로 입력이 된다. [3] 단 IME를 쓰더라도 16비트 앱에서는 입력이 안된다.