아스키코드와 유니코드 비교, UTF-8, 한글 유니코드 표기(EUC-KR, CP949, 유니코드)

---

내용을 요약합니다.

ASCii와 유니코드는 문자(언어/숫자/특수문자 등)를 컴퓨터상에서 표시하는 방법이다

1. 아스키는1963년, 유니코드는 1991년 제작되었고, 일부만 호환된다.
2. UTF-8은 유니코드의 종류이다.
3. 한글은 EUC-KR, CP949 표를 사용했지만 현재 유니코드를 주로 사용한다.

---

ASCII (American Standard Code for Information Interchange, 미국 정보 교환 표준 부호)

아스키 코드는 1963년 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다. 인쇄전신기(Teleprinter)를 통한 전신(통신)에서 사용되기 시작했고, 8비트 컴퓨터에서도 활용되어 오늘날 문자 인코딩의 근간을 이루게 된다

https://0pen3r.tistory.com/292

[아스키표] 가독성 좋은 아스키 코드표(ASCii code)

---

유니코드(Unicode)는 전 세계의 모든 문자를 다루도록 설계된 표준 문자 전산 처리 방식이다.

유니코드 컨소시엄(Unicode Consortium)에서 제정, 관리한다.

주요 구성 요소는 ISO/IEC 10646 Universal Character Set과 UCS, UTF 등의 인코딩 방식, 문자 처리 알고리즘 등이다. 전 세계의 모든 문자를 담는 ISO/IEC 10646 코드표를 사용함으로써, 각 언어와 문자 체계에 따른 충돌 문제를 해결하였다. 따라서 유니코드를 사용하면 한글과 신자체·간체자, 아랍 문자 등을 통일된 환경에서 사용할 수 있다.

초창기에는 문자 코드는 ASCII의 로마자 위주 코드였고, 1바이트의 남은 공간에 각 나라가 자국 문자를 할당하였다. 하지만 이런 상황에서 다른 국가에 이메일을 보냈더니 글자가 와장창 깨졌던 것. 인터넷 웹페이지도 마찬가지였다. 이에 따라 4바이트(32비트, 약 42억 자)의 넉넉한 공간에 세상의 모든 문자를 할당한 결과물이 이것이다.

현재의 유니코드는 지구상에서 통용되는 대부분의 문자들을 담고 있다. 여기에는 언어를 표기할 때 쓰는 문자는 물론, 악보 기호, 이모지, 태그, 마작이나 도미노 기호 같은 것들도 포함된다.

모든 문자 체계를 담고 있는 것은 아니라서, 과거에 사용된 문자 체계나 쓰임이 적은 인공문자, 자료가 많이 남아 있지 않은 문자 체계는 등록이 되어있지 않아 유니코드로 표현할 수 없다. 물론 아직 유니코드에 없다 뿐이지 어지간한 문자 체계는 유니코드에 집어 넣으려는 계획이 진행중이다. 앞으로 유니코드에 뭘 넣을지 보여 주는 로드맵이 있는데 꽤 알차게 차 있다. (https://www.unicode.org/roadmaps/smp/)

출처 : 나무위키(https://namu.wiki/w/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C)

---

---

KSC5601, EUC-KR, CP949 는 한글이 표현되는 언어처리방식이나 현재는 유니코드를 주로 사용

대한민국의 한국어 컴퓨터 환경에서는 유니코드가 도입되기 전에는 KSC 5601(완성형, 이후 KS X 1001로 개칭됨)이라는 코드와 이에 기반한 EUC-KR 인코딩을 사용하였다. 그러나 완성형의 한글 글자 수는 2,350자로, 현대 한글이 표현할 수 있는 글자 중 빈도가 높은 일부분만 수록되어 있는 상태였다. 이것 때문에 똠을 똠이라 쓰지 못하는 일이 있기도 했다

이를 해결한 CP949/UHC(통합 완성형)라는 코드도 있는데 완성형에 없는 글자를 억지로 구겨 넣었기 때문에 코드가 자모 순으로 구성되지 않을 뿐만 아니라 코드 표준에 맞지 않게 구현한 프로그램이 많아서 자잘한 문제가 많았다. 사실 한글 채움 문자를 쓰면 되겠지만 불편해서 잘 쓰이진 않았다

출처 : 나무위키

유니코드는 1991년 발표된 1.0 버전부터 KS C 5601에 포함된 완성형 2,350자 한글을 지원하였다. 1993년 발표된 1.1 버전에는 KS C 5657(이후 KS X 1002)에 포함된 1,930자 및 중국에서 요청한 6글자를 포함한 2,376자를 추가해 총 6,656자가 수록되었다. 믿기 어렵겠지만 유니코드 1.1에는 옛한글까지 고려한 조합형 한글 낱자도 포함되어 있었고(U+1100 - U+11FF) 실제로 이걸로 넘어가자는 제안도 있었다.

 그러나 당시 한국에서는 2,350자를 벗어난 현대 한글을 사용하려면 그냥 조합형을 사용하면 되었기 때문에 이렇게 추가된 6,656자만으로는 유니코드 기반 완성형을 사용할 이유가 없었다. 조합형이라고 해서 상황이 나은 것도 아닌게 첫가끝 기반 조합형은 90년대 초반까지 한국에서 사용한 조합형과는 달랐고, 지금도 OS X과 윈도우 사이에서 파일을 복사할 때 자주 글자가 풀려 버리는 등 이걸 제대로 지원하는 플랫폼은 흔치 않다. 완성형 한글도 한 번에 일괄적으로 추가되지 않았고 빠진 글자들이 단계별로 추가되었기 때문에 배열 순서가 CP949/UHC보다도 개판이었고 나머지 4,516자를 추가하려고 해도 제대로 추가할 수가 없었다. 한편 유니코드 1.1을 지원했다가 한국에서 한동안 피를 본 프로그램 중 하나가 오라클 DB이었다. 

그래서 대한민국 대표는 유니코드 2.0 제정 시 완성형 현대 한글 11,172자를 가나다순으로 새 영역에 배당할 것을 요청했다. 이때 각국 대표들 사이에서 논쟁이 오갔지만, 결국 대한민국 대표의 요청이 받아들여져서 1996년 발표된 유니코드 2.0에서 1.1 때까지 U+3400 ~ U+4DFF에 배당되어 있던 한글 6,656자를 없애고

새 영역(U+AC00 ~ U+D7A3)에 가나다순으로 11,172자를 배당했다. 그리고 이 '한글 대이동 사건'을 계기로 2.0부터는 한 번 배당한 문자는 절대 옮기거나 없애지 않는다는 정책을 세웠다.
그리고 이렇게 배당된 11,172자가 2.0부터 현재까지 한글·한국어 처리에 쓰이고 있다. 이로 인해 유니코드 2.0 이상과 그 이전 버전은 서로 호환되지 않는다.

당연하게도 이 11,172자는 남한의 가나다순으로 배당되었다. 남한과 북한은 한글 낱자의 정렬 순서가 다른데

북한이 이것을 문제 삼아 이 11,172자를 북한식으로 재배열해 줄 것을 2000년경에 요구했으나,
이미 한글은 코드 위치가 한 번 대이동한 전례도 있고 문자를 절대 옮기거나 없애지 않는다는 정책에도 위배되기 때문에 보기 좋게 씹혔다.
그리고 북한은 코드 순으로 정렬하면 북한식으로 제대로 정렬이 되지 않는다는 것을 문제 삼았는데,
단순 코드 순 정렬은 어차피 그 어떤 언어에서도 적절하지 않으며, 정렬은 따로 테이블을 만들거나 알고리즘을 짜서 해야 한다. 영어조차도 코드 순으로 정렬하면 대문자 Z가 소문자 a보다 앞에 온다.
물론 코드에서 이미 정렬이 되어 있으면 정렬 테이블 및 알고리즘 제작이 쉬워지고 받침에 따라 바뀌는 조사 붙이기가 용이해진다는 장점은 있다. 과거 확장완성형이나 유니코드 1.1이 문제가 됐던 것도 배열 순서가 너무 심하게 뒤죽박죽이었기 때문이다.

그래서 한때 북한에서는 자기네들 순서를 기준으로 한글 영역을 쓴 적이 있었다. 
남북한 한글 코드의 충돌 문제 문서 참고. 지금 북한은 울며 겨자 먹기로 남한 순으로 배당된 11,172자를 쓰고 있다.
북한은 이것만이 아니라 자기들이 우상화 목적으로 특수 문자 영역에 볼드 처리한 '김, 일, 성, 김, 정, 일'도 그대로 유니코드에 넣고자 했으나 퇴짜 맞았다. 그래서 북한에서 만들어진 폰트에서는 볼드 처리한 김, 일, 성, 김, 정, 일, 김, 정, 은을 PUA 코드에 할당하기도 하며, 북한제 운영체제의 입력기에서도 이걸 감안하여 김일성, 김정일, 김정은 이름을 쓰면 자동으로 PUA 내 볼드 처리된 글자로 변환한다고 한다.

출처 : 나무위키

 

 

 

 

 

[참고자료]

https://namu.wiki/w/%EC%95%84%EC%8A%A4%ED%82%A4%20%EC%BD%94%EB%93%9C

아스키 코드 - 나무위키

https://namu.wiki/w/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C

유니코드 - 나무위키

https://namu.wiki/w/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C#s-4.2.1

유니코드 - 나무위키

 

 

 

 

-끝-