나무모에 미러 (일반/어두운 화면)
최근 수정 시각 : 2024-01-03 22:06:49

한글 인코딩


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


1. 개요2. 역사
2.1. 조합형과 완성형2.2. 완성형의 문제점2.3. 유니코드와 한글
3. 관련 문서4. 관련 문서

1. 개요

한글컴퓨터에 표시하는 방식. 현대 한글은 음소 문자 주제에(…) 음절에 따라 모아쓰기를 하기 때문에[1] 다른 문자 체계와는 다른 별도의 방식을 고안할 수밖에 없었다.[2]

2. 역사

2.1. 조합형과 완성형

한글의 인코딩은 크게 두 가지로 나뉜다. 첫 번째는 '가', '각', '간' 등 한글의 한 글자 한 글자를 독립된 문자로 인식하고 각 글자에 코드를 부여하는 완성형이고, 두 번째는 초성, 중성, 종성을 독립된 문자로 보고 자모의 조합으로 글자를 표현하는 조합형이다. 이렇게 두 가지로 나뉘다 보니 한글 전산화 초기에는 조합형과 완성형 사이의 논쟁이 있었다.

조합형은 한글의 창제 원리를 잘 반영하였고 간단한 계산만으로 초·중·종성을 분리할 수 있다는 장점이 있다. 하지만 2바이트를 비트 단위로 쪼개서 해석을 해야 하기 때문에[3] 처리상의 부담이 컸고 다른 문자 체계들과 호환이 안 된다는 단점이 있었다. 반면 완성형은 한글의 제자 원리를 무시한다는 단점이 있었지만, 조합형의 단점들 때문에 완성형이 국가 표준으로 채택되었다.

2.2. 완성형의 문제점

초기 완성형에서는 현대 한글로 표현할 수 있는 글자 중 사용 빈도가 높은 2350자만을 채택하여 지원하였다. 그래서 '뷁', '힣' 같은 글자는 물론 '귬', '붴', '칢'처럼 표준어에 있는 글자들도 쓸 수가 없었다. 이 점을 해결하기 위해 마이크로소프트에서는 윈도우즈 95에서 코드 페이지 949, 또는 통합 완성형이라는 이름의 코드를 도입하였다. 이 코드에는 EUC-KR의 2350자로 표현할 수 없는 8822자를 추가하였다. 그러나 기존의 2350자가 있던 영역(KS X 1001)과는 다른 별도의 영역에 글자들을 지정하였기 때문에 한글의 순서가 뒤죽박죽이 되었고, 따라서 코드값만으로는 제대로 정렬이 이루어지지 않는 문제점이 있었다. 그러나 어쩌다 보니 확장 완성형이 계속 사용되어 왔다.

저렇게 윈도우에서 기존 EUC-KR를 코드 페이지 949로 확장하였고, 현재 한국어 윈도우에서는 저 코드 페이지 949가 표준적으로 쓰이고 있기 때문에, 순수하게 윈도우 전용의 한국어 인코딩이지만 윈도우 점유율로 인해 코드 페이지 949가 사실상 표준인 셈. 가끔 보면 한국어 윈도우에서 만들어진 파일을 유니코드로 변환할 때 원본 파일의 인코딩을 EUC-KR로 지정하는 경우가 있는데, 이렇게 되면 자주 쓰이는 EUC-KR에 포함된 문자들은 제대로 유니코드로 변환되지만, 차후에 추가된 저 나머지 문자들은 제대로 변환이 안 되니 반드시 CP949로 지정하도록 하자. CP949는 EUC-KR를 완전히 포함하므로 원본 파일이 코드 페이지 949가 아닌 EUC-KR 환경에서 만들어졌더라도 신경 쓸 필요가 없다.

2.3. 유니코드와 한글

파일:상세 내용 아이콘.svg   자세한 내용은 유니코드 문서
번 문단을
유니코드와 한글 부분을
참고하십시오.

현재의 유니코드에는 완성형 11,172자와 조합형 한글 낱자가 모두 수록되어 있어 현대 한글과 옛한글을 모두 완벽하게 표현할 수 있다. 일반적인 한글 문서에는 완성형을 사용하지만, 옛한글 등 특수한 목적을 위해서는 조합형(첫가끝) 한글 낱자를 사용한다.

컴퓨터 운영체제 포맷에 따라 한글 파일명을 완성형(윈도우) 또는 조합형(맥)으로 "유니코드 정규화"해서 인코딩을 한다. 이 때, 서로 다른 운영체제 간 파일 전송 시, 파일명 문자 깨짐이 발생하거나, 그렇지 않더라도 정렬이나 검색에서 파일이 제대로 나오지 않는 상황이 발생하기도 한다.

서로 다른 컴퓨터, 서로 다른 운영체제, 서로 다른 파일 시스템, 서로 다른 문서 양식을 만나게 되는 ""에서는 인코딩이 맞지 않으면 혼파망이 필히 발생했다. 이에 대비해 유니코드의 UTF-8 인코딩이 개발되었고, 2014년 이후부터는 어지간한 컴퓨터 문서에서 이를 사용하기 때문에 한글의 인코딩이 깨지는 문제점은 사라졌다. 만약 웹사이트를 만든다면 인코딩을 EUC-KR이 아닌 UTF-8로 하자.

3. 관련 문서


한글 전산화가 이루어지던 80~90년대에는 그 외에도 도깨비 한글, 7비트 한글 코드 등 독자적으로 쓰이는 코드가 있었다.

4. 관련 문서



[1] 이는 한자 표기와의 호환성을 위해서였다고 생각된다.[2] 한글 풀어쓰기를 주장하는 사람들이 근거로 내세우던 것 중 하나가 바로 이 점이었다. 풀어쓰기를 하면 전산화에 따르는 여러 난점을 해결할 수 있다는 것. 한편 일본어판 위키피디아에서는 '한글은 음절별로 모아쓰기를 하니까 한글은 음소 문자가 아니라 음절 문자'라고 주장한다. 그러니까 자모의 형상을 봤을 때 음소 문자라고[3] 2바이트 조합형의 경우이다. 2바이트(=16비트) 중 맨 처음 1비트는 제외하고 나머지 15비트 중 5비트씩 잘라서 초성, 중성, 종성에 배당하였다.[4] 남한과 북한은 한글 낱자의 정렬 순서가 서로 다르다. 한때 북한이 유니코드에 남한의 낱자 순서만이 반영되어 있는 것을 문제 삼았지만 유니코드는 한 번 지정된 문자는 자리를 옮기지 않는다는 지침을 따르고 있기 때문에 씨알도 안 먹혔다. 사실 이 지침이 제정된 게 한글 때문이기도 하고...[5] 이런 사례가 드문 것은 아니다. 일본도 연호를 ㍻(헤이세이), ㍼(쇼와), ㍽(다이쇼), ㍾(메이지)로 한 글자로 박아넣은 코드가 있고 세로쓰기에 쓰기 위해 ㍍(미터), ㌧(톤), ㌘(그램) 등 여러 글자를 한 코드 안에 박아넣고 있다. 하지만 저 앞의 경우는 편의를 위한 것일 뿐인데 북한이 저렇게 해놓은 목적은 뭐... 일본의 저 사례와 제대로 일치시키려면 세글자를 코드 하나에 욱여넣었어야 제대로 된 비유가 될 듯.