한글을 컴퓨터에서 표현하는 방법

이전에 조합형, 완성형, 유니코드에 대해 알아보면서 개인적인 생각을 적음.

한글을 컴퓨터에서 표현하는 방법엔 대표적으로 조합형, 완성형, 유니코드가 있다. 조합형 한글은 2 Byte 형 기준이다. 2 Byte는 18Bit인데 가장 앞 1Bit는 영문, 한문을 정의하고 5Bit씩 초성 중성 종성을 결정한다. 한글의 본래 원리를 충실히 반영한 방식이다. 장점으론 한글만 볼 때 가능 훌륭한 형태지만, 한글을 순서대로 정렬할 수 없으며, 다른 언어와 호환성이 떨어지며, 처리상의 부담이 있다. 위의 문제를 해결하기위한 방식이 완성형 표현 방법이다. 완성형 표현 방식은 우리나라가 국가 표준 코드로 지정한 2 Byte 완성형 코드로 한글 2350자, 한자 4887자, 특수문자 978자가 사용 가능한 특징을 가지고 있다. 조합형과 달리 완전한 글자 하나에 코드를 부여하는 방식이므로 정렬 문제를 해결할 수 있다. 하지만 표편 불가능한 문자가 있다는 문제점이 있다. 이런 문제점을 해결하기 위해, 누락된 문자를 추가한 확장형 완성형 한글 코드가 배포되었으나, 이는 ASCII 표준을 위배한다. 유니코드 2.0이 등장하기 전 한글 자판을 입력하는 방식 중 조합형과 완성형중 어느쪽이 더 나은가를 두고 치고받고 싸웠던 조합형 완성형 논쟁 사건이 있었다. 조합형 찬성파에서는 이쪽이 더 한글창제 원리에 맞는다는 이유를 들었지만 당시에만 해도 PC의 메모리가 그다지 넉넉한 편이 아니었기 때문에 완성형이 국가표준으로 되어 있었고, 결국 이 논쟁은 마이크로소프트가 윈도우즈 95에 "확장완성형"이라는 기묘한 코드를 도입함으로써 일단락되는 듯 했으나 그 불씨를 남겼다고 한다. 유니코드는 세계모든 언어를 통일된 방법으로 표현하기 위해 제안된 국제적인 코드이다. 8Bit 체계의 ASCII 코드를 16Bit 로 확장하여 전 세계모든 문자를 표편하는 표준 코드이다. 완전한 모든 문자를 2Byte 에 1:1 대응되도록 만들었다. 모든 글자가 같은 크기를 가지므로 글자 수나 검색이 용이하지만, 알파벳은 1Byte만 있어도 충분히 표현 가능하지만 2Byte씩 사용하여 공간의 낭비가 있으며, 한글의 고어나 중국의 고어를 넣을 만한 충분한 여유 공간이 없다.

위의 내용을 바탕으로 한글을 표현하는데 가장 합리적인 방식은 유니코드라고 생각한다. 한글의 본래 원리를 충실히 사용하라면 조합형이 좋아보이지만, 데이터를 처리하는 과정에서 부하가 걸릴 수 있다. 확장형 완성형 한글 코드가 배포되었지만 유니코드가 더욱 효율 적으로 보인다. 전공이 컴퓨터공학이니 웹페이지, 데이터베이스에 한글을 입력시킬 때, 유니코드로 인코딩하여 입력하지않는다면 모든 한글이 깨져서 저장된다. 글로벌 시대엔 호환성이 가장 중요하다고 생각한다. 예를들어 국내 A라는 회사에서 한글 조합형으로 작성된 문서를 해외 B라는 회사로 전송하였을 때, 높은 확률로 문서의 내용을 읽을 수 없다. 이런 문제를 해결하기위해 인코딩을 거쳐야하는데 대표적인 인코딩 방식은 UTF-8 이다. 이 방식은 대표적인 조합형의 유니코드 인코딩 방식이다. UTF-8의 경우에는 조합형 방식의 문자집합(Charater Set)이면서, 유니코드 인코딩 방식중 하나입니다. 유니코드 인코딩 방식에서 가장 대표적인 문자집합인데, 그 이유는 ASCII 문자들을 표현할 수 있기 때문입니다. 따라서 유니코드 인코딩 하면 UTF-8 방식을 많이 이야기 합니다. 위에 설명했다 시피, 초성, 중성, 종성을 각각 1바이트로 인식해서 일반적으로 한글을 3바이트로 인식하지만 공백이나 영문은 1바이트로 인식을 합니다. 또한 장점이 유니코드의 경우에는 다른 국가에서 한글 언어팩이 설치되지 않았다고 하더라도 한글 표현이 가능합니다. 같은 방식으로 우리 나라에서도 다른 나라의 언어를 볼 수 있습니다. 따라서 다양한 언어로 작성되는 환경이나, 웹과 같은 다양한 국가의 사람들이 보는 경우에는 더 좋은 방식입니다.UTF-8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다. 본래는 FSS-UTF(File System Safe UCS/Unicode Transformation Format)라는 이름으로 제안되었다. UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들어서, U+0000부터 U+007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면(BMP) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF-16과 UTF-8 중 어느 인코딩이 더 적은 바이트를 사용하는지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 DEFLATE와 같은 일반적인 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다. 이러한 압축 알고리즘을 사용하기 힘들고 크기가 중요할 경우 유니코드 표준 압축 방식을 대신 사용할 수 있다.일반적으로 운영되는 서버들의 운영체제는 리눅스 계열입니다. (무료가 많기 때문) CentOS 아니면 Ubuntu 또는 레드햇 계열인데 이런 리눅스 계열은 대부분 유니코드를 지원합니다. 혹시라도 유니코드를 지원하지 않더라도 워낙에 확장성이 좋기 때문에 유니코드로 인코딩을 설정할 수 있지요.또한 많이 사용하는 웹서버가 Apache, IIS, NginX 정도인데 기본적으로 서버인코딩은 UTF-8을 이용합니다.뿐만 아니라, PHP와 MySQL 역시 UTF-8 방식을 기본 인코딩으로 이용하여 웹 서비스를 제공합니다. 이렇게 많이 사용하는 환경에서 수요가 많기 때문에 웬만한 소스들은 UTF-8 방식으로 인코딩을 하고 있으며, 그래서 거의 문제가 되는 일이 없습니다.실제로 저도 몇몇 과제에서 인코딩 방식 때문에 윈도우 서버 환경에서는 정상적으로 실행이 되지 않았지만, 리눅스 환경에서는 완벽하게 사용가능하던 과제가 있습니다. 이러한 내용을 토대로 한글을 표현하는 가장 합리적인 방식은 유니코드라고 생각한다.