ANSI는 American National Standards Institute(이하 ANSI)의 약어로 미국 국가 표준 협회를 의미한다. 일반적으로 인코딩(Encoding)을 타나내는 표기 중 하나로 사용되기도 하는데 이는 ANSI Code Page를 나타낸다고 할 수 있다.

ANSI Code Page는 보통 Windows Code Page라고도 하며, 아스키(ASCII)가 아닌 국제적인 문자를 표현하기 위해 사용하는 코드 페이지(Code Page) 이다. 원래 Windows ME 계열(9x 계열)에서 사용되지만, Windows NT 계열 이상에서도 사용할 수 있다.

현재는 대부분이 유니코드(Unicode)로 문자를 표기하기 때문에 UTF-16이나 UTF-8 등의 인코딩을 많이 사용하지만, 아직도 많은 레거시(Legacy) 어플리케이션(또는 프로그램)에서 코드 페이지 기반의 인코딩을 사용하고, 새로운 어플리케이션에서도 코드 페이지 인코딩을 사용하고 있다. 코드페이지를 사용하는 이유는 주로 다음과 같다.

• 레거시 어플리케이션과의 호환성 문제

• 유니코드를 지원하지 않는 오래된 메일이나 뉴스 서버와의 호환성문제

• 유니코드를 지원하지 않는 Windows 콘솔과의 호환성 문제

일반적으로 코드 페이지는 cp1252와 같이 숫자로된 식별자를 사용하여 표기하며, 유니코드나 Character Set API 함수에 의해 처리된다.

원래 영어와 서부 유럽언어 기반의 Windows는 코드페이지로 1252(이하 cp1252)를 사용 했는데, 이는 ANSI 초안을 기반으로 한 코드페이지이다. ANSI 초안은 ISO 8859-1 이었지만, 최종 표준이 되기 전에 cp1252가 구현되었다. cp1252와 ISO 8859-1은 유사하지만 정확하게 동일하지는 않다.

기본적으로 Windows에서는 ANSI로 사용하는 인코딩 코드 페이지가 언어 마다 다르게 적용된다. 영어나 서부 유럽언어에서는 위에서 언급한 것처럼 cp1252를 사용하지만, 한글에서는 cp949를 사용하고, 중국어는 cp936, 일본어는 cp932를 사용한다.

ANSI와 유니코드는 처리하는 텍스트가 다르다(ANSI는 Windows Code Page, 유니코드는 Unicode 텍스트). 하지만 코드 페이지에서도 유니코드 인코딩을 구현한 경우가 있는데, CP65000과 CP65001이 그것이다. CP65000은 UTF-7을 구현한 코드페이지 이고, CP65001은 UTF-8을 구현한 코드페이지이다. 이를통해 Windows 콘솔에서도 유니코드 인코딩이 UTF-7이나 UTF-8로 되어 있다면
유니코드 텍스트를 처리할 수 있다.

한글 Windows에서 한글 문자 집합을 표현하기 위한 코드 페이지로 cp949를 ANSI Code Page로 사용한다고 위에서 언급했다. 하지만 한글을 표현하기 위한 문자 인코딩이 cp949만 있는 것은 아니다. 유니코드 인코딩을 제외하고, iso-2022-kr, ks_c_5601-1987, euc-kr이 한글 표기를 위한 인코딩으로 사용되며 이들은 현대에는 특별히 구분하지 않고 사용되는 경우가 많다. 또한 위에 언급한 한글 인코딩은 모두 완성형 이라는 특징을 가지며, 이와 다른 조합형 이라고 하는 인코딩이 존재한다.

조합형
조합형은 자음 모음을 분리하여 한글을 표현할 때 각각의 초성, 중성, 종성에 해당하는 자모 조합으로 표기하는 방법이다. 따라서 조합 가능한 모든 한글을 표기할 수 있지만 용량 효율성이 떨어진다는 단점이 있으며, 이 뿐만 아니라 한글 출력 시 한자를 함께 출력해야 하는 사회적 요구와, 국가 간의 정보 교환을 위한 코드 표준화로 채택된 코드 체계에도 맞지 않았기 때문에 조합형을 수용하기에는 어려움이 있었다.

ISO 2022는 문자 코드 구조 및 확장을 위한 ISO 표준으로, 다음과 같은 기술구성을 가진다.

• 단일 문자 인코딩 시스템에 복수의 문자 셋트를 포함하는 기술

• 동일한 인코딩을 사용하여 7bit 및 8bit 시스템에서 이러한 문자 셋트를 표현하기 위한 기술

ISO 2022 인코딩을 포함하는 수 많은 문자 집합들은 단일 문자에 대응하는 투-바이트를 사용하는 ‘double bytes’ 인코딩이다. 따라서 0x7F(10진수로 127)까지의 바이트는 7-bit ASCII에 해당하는 문자를 표현하고(0x20, 0x0F는 제어 문자), 이후 범위에서 ISO 2022는 가변 길이 인코딩 방식이 된다.

iso-2022-kr은 ISO 2022 표준을 따르는 한글 인코딩을 의미한다. iso-2022-kr는 이전에 KS C 5601-1987이라고 불리는 KS X 1001 -1992 인코딩을 사용한다. KS C 5601-1987은 한 문자당 2 바이트로 표현되는 인코딩이다.

ISO 2022 표준으로 사용되는 한글 인코딩이다. KSC5601으로도 불리고 있으며, 이 또한 구 명칭으로 KS X 1001이라고 한다. KS X 1001은 대한민국 국가기술표준원에서 개발하였고, 현재 대한민국 산업표준으로 정식 한글 표준 명칭은 정보 교환용 부호계(한글 및 한자) 이다.

KS X 1001은 한글과 한자 뿐만 아니라 일본어(히라가라, 가타카나)도 표현이 가능하며 여러 가지 기호도 포함되어 있다.

KS X 1001은 ISO 2022 표준의 G1이라는 문자 집합으로 설계되어, 94 x 94 크기의 문자 집합을 갖는다. 1행부터 12행까지는 한글 자모, 일본어를 포함한 각종 기호¹, 16행부터 40행까지는 한글(2,350자), 42행부터 93행 까지는 중국어(4,888자)로 총 8,224자로 구성되어 있다.

1행~12행까지의 기호들은 현재도 흔히 사용하는 ㅁ + 한자 조합과 같이, 자음(ㄲ, ㄸ, ㅃ, ㅆ 포함) + 한자 키 조합으로 모두 입력할 수 있다.

EUC는 Extended Unix Code의 약자로 주로 일본어와 한글, 중국어를 위해 사용되는 멀티-바이트 문자 인코딩 시스템이다. EUC의 구조는 ISO-2022를 기반으로 하고 있다. ISO 2022의 G0에 해당하는 0x7F 이하의 문자에 대해서는 거의 항상 ISO 646 호환 코드 문자 집합을 사용하며, US-ASCII가 이에 해당한다. 한글에서는 ISO 646:KR 표준에 해당하는 문자 집합으로 KS X 1003이 사용된다.

KS X 1003
KS X 1001과 마찬가지로 대한민국 산업 표준으로 구 명칭은 KSC5636, 한글 표준 명칭은 정보 교환용 부호(로마문자)이다.
US-ASCII와 동일한 문자 집합을 가지고 있으나 역 슬래시(＼)를 원화(￦)로, 물결(~)을 발음구별기호(￣)로 바꿨다는 부분에만 차이가 있다.

결론적으로, euc-kr은 가변 길이 인코딩으로 한글 텍스트를 표현하기 위해 KS X 1001, KS X 1003 이 두 가지의 문자 집합을 사용한다. KS X 2901(구 KS C 5861)이 인코딩을 규정했고, RFC 1557은 그것을 EUC-KR 이라고 부른다. KS X 2901(표준명: 유닉스 한글 환경)은 유닉스 운영 체제의 커널 서비스와 명령어 및 라이브러리를 이용하는 사용자와 한글 유닉스 운영 체제를 개발하고자 하는 프로그래머들에게 표준화 된 한글 처리 환경을 제공하기 위한 제반사항에 대하여 규정한다.²

한국에서 EUC-KR은 주요 플랫폼(Unix 계열 OS, Windows 및 Mac)모두 에서 가장 널리 사용되는 레거시 문자 인코딩이지만 UTF-8이 대중화되어(특히 리눅스 및 Mac OS) EUC-KR의 사용이 점차 감소하고 있다. 또한 euc-kr과 같이 한글에 ks x 1001 문자 집합을 사용하는(KS C 5601, iso-2022-kr) 인코딩을 완성형이라고 하는데 완성형의 문제는 제한된 바이트 범위에 모든 한글 조합이 적용되지 못한다는 것이다. 대표적으로 똠방각하 의 똠이 있다. 이는 확장 완성형 한글 문자 집합을 사용하여 표기할 수 있다.

완성형과 확장완성형의 차이는 표현 가능한 문자의 범위이다. ISO 2022를 기반으로 KS X 1001 한글 문자 집합을 사용하는 인코딩은 모든 한글 범위를 포함하지 않는다. 이는 위에서 언급한 CP949를 제외한 인코딩 모두 이에 해당한다. CP949는 처음에는 KS C 5601를 표현한 코드 페이지 였지만 Windows95버전 부터 확장 완성형 한글 또는 통합형 한글 코드(Unified Hangeul Code)라는 명칭으로 확장되어 현대의 모든 한글을 표현할 수 있게 되었다.

EUC-KR에서 KS X 1001 해당하는 2-바이트 코드의 범위는 0x[A1-FE][A1-FE] 이다. 예를 들어 "완" 이라는 문자는 EUC-KR에서 0xBFCF가 된다. 하지만 KS X 1001에 해당하지 않는 문자인 "똠"의 경우 완성형에서 이를 표현하는 코드는 존재하지 않는다. 하지만 확장 완성형에서는 KS X 1001에서 할당되지 않는 범위에 표현 가능한 모든 한글을 적용하고 있다.

그림 1. Windows 명령 프롬프트(CMD)에서 euc-kr에 해당하는 code page로 테스트한 결과

위 그림 1. 에서는 간단하게 명령 프롬프트를 사용하여 euc-kr에 해당하지 않는 문자를 물음표로 저장하는 것을 볼 수 있다. chcp 명령어로 프롬프트의 활성 코드 페이지를 변경할 수 있으며, euc-kr의 코드 페이지 값은 51949³이다. 활성화된 코드 페이지에서 "똠방각하"를 euc-kr.txt에 저장하고, type 명령어로 그 내용을 읽어오면 "똠"에 해당하는 문자가 물음표("?")로 저장된 것을 확인할 수 있다.

현재는 EUC-KR로 인코딩이 표기 되더라도 이를 완성형만으로 인코딩하지 않는 경우가 많으며, 한글 문자 집합을 표현하기 위한 인코딩 명칭으로 EUC-KR을 사용하기도 한다. 이는 어플리케이션 마다도 다르게 적용하기 때문에 확인이 필요하다. 예를 들어, Visual Studio Code에서는 CP949로 저장한 "똠"에 대해서도 EUC-KR 인코딩으로 열면 문자가 보이는 반면, Notepad++에서 인코딩을 EUC-KR로 지정한 경우 "똠" 부분이 물음표("?")로 보여진다.

확장 완성형에 해당하는 CP949는 첫 번째 바이트에 ASCII 바이트와 충돌하지 않게 0x81(129)부터 0xC5(197)까지를 사용하며, 두 번째 바이트에는 0x81(129)부터 0xFE(254)까지 사용하는데 기존 KS X 1001과 충돌하지 않게 첫 번째 바이트가 0xA1(161)이상인 경우 두 번째 바이트는 0xA1(161)이상이 될 수 없다. 결국 위의 규칙을 따르는 확장 완성형 인코딩 CP949에서 "똠"을 저장하면, 코드 값은 0x8C63 이 된다.

아래는 엑셀로 작성한 완성형 한글 코드와, 확장 완성형 한글 코드의 바이트 범위를 보여주는 표이다. 행(row)에 해당하는 값이 첫 번째 바이트의 범위를 의미하고 열(column)에 해당하는 값이 두 번째 바이트의 범위를 의미한다.

그림 2. 한글 인코딩 표

예를 들어 위 표(그림2.)에서 완성형 한글에 해당하는 "가"의 코드 값은 0xB0A1 이 된다. 엑셀 표를 다운로드 받고 싶다면 아래 파일을 다운로드하면 된다.

위 엑셀 파일에서 좌측 상단에 위치한 변환 기능을 사용하면, HEX(16진수)코드와 DEC(10진수)코드를 입력하여 해당 코드가 어떤 글자인지 확인할 수 있다.

그림 3. 한글 인코딩 검색

HEX와 DEC 중에 하나를 선택하고 코드값을 입력하면 입력한 코드에 해당하는 문자와 완성인지 확장인지가 출력된다.

현대에 와서 ksc5601이니 euc-kr이니 하는 것은 별로 의미가 없는 것처럼 느껴진다. 한글 인코딩을 euc-kr로 거의 통일해가는 것도 있지만, 결국 유니코드를 사용하면 웬만한 인코딩 문제에서는 해방되기 때문이다. 다만 한글 인코딩에 관한 문제에 접하게 되었을 때 이러한 규칙을 알고 있다면 훨씬 도움이 될 것이라고 생각한다.

1. 기술/학술기호 등 특수문자 432자， 숫자 30자， 한글 낱자 94자， 로마문자
52자， 그리 스 문자 48자， 패션 조각 68자， 라틴 문자 27자， 일본 문자
169자， 러시아 문자 66자

2. KS X 2901, 한국표준정보망, http://www.kssn.net/StdKS/KS_detail.asp?K1=X&K2=2901&K3=4

3. Code Page Identifier, https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx