[Encoding]Character Set에 대해서 알아보자.(euc-kr, utf8 등)

실제로 컴퓨터를 하다보면 여러가지 캐릭터 셋을 신경써야한다.

모든 공용 문자셋인 utf-8만 쓰면되지 왜이렇게 많이 존재하느냐?

거기에 대해서 질문하는 사람이 있어서 짤막하게 글을 쓰려고한다.

컴퓨터는 알파벳권에서 처음 만들어졌다. 따라서 처음에는 알파벳만 표시할 수  있으면 장땡이였다.

알파벳은 모든 문자를 다 포함해도 52(대소문자포함)개 밖에 안된다. 따라서 1바이트(256가지)안에 모두 표현할 수 있었다.

이 문자셋을 ascii라고 한다. 엄밀히말하면 1바이트보다도 작다. 7비트(128가지)를 사용하는 문자셋이다.

그러나 곧 유럽권에서 쓰기 시작하면서 조금씩 문제가 생겼다. 유럽권에서는 알파벳으로 표현하지못하거나 기호가 섞여있는 문자들이 있다.

그러나 이들을 다 포함해도 1바이트를 넘지 않았는데 그 이유는 기존의 ascii는 1바이트(8비트)가 아닌 7비트 였으므로

128가지의 여유공간이 남아있었다. 이 여유공간을 마저 활용해서 만든것이 바로 latin1과 latin2이다.

각각 서부유럽과 중부유럽에서 쓰는데 어느정도 호환성은 된다고 들었는데 잘은 모르겠다.

어짜피 ascii도 1바이트고 latin1도 1바이트이며 latin1은 ascii를 완전히 포함한다.(사실 모든 문자셋들은 ascii를 완전히 포함한다.)

그래서 이왕 1바이트 쓰는거 아예 반만 쓰는 ascii를 쓸 바에야 latin1을 쓰는게 낫지 않냐는 취지로 latin1이 대중적인 문자셋이된다.

이제 한국을 예로 들어보자. 한국도 발전하면서 결국 문자셋을 필요로 하게 되었다.

근데 한국은 경우의 수가 너무 많았다.  11,172라는 경우의 수라는게 문제였다.

결국 1바이트안에 전부 우겨넣는 것은 불가능하므로 2바이트를 채택하게 되었다.

2바이트는 총 65536의 경우의 수를 가지므로 모든 한글을 포함할 수 있고 남는 공간에 자주쓰는 한자등 이것저것을 넣게 되었다.

이렇게 해서 탄생한것이 euc-kr이다. 단 맨처음 euc-kr은 모든 한글을 포함하지는 못했다.

그래서 이를 보안해서 마이크로소프트에서 만든것에 CP949 (CP는 CodePage라는 뜻, 다른 플랫폼에서는 MS949라 부름)를 만들었다.

이 는 euc-kr이 포함하지 못하는 부수적인 한글을 포함하게 되므로써 한글 출력문제는 거의 해결되게 되었다.

현재는 euc-kr은 cp949와 거의 동의어 취급을 받는다. 왜냐하면 euc-kr이라 적힌것도 말만 그렇지 실상은 CP949로 매핑되는 경우가 대부분.

가끔 가다 아닌 곳도 있으니 조심은 해야할 것이다.

이까지 되면 해피엔딩이라 생각할 수 있다.

그러나... 실상은 그렇지 않았는데 결국 그 문자셋은 자국에서만 쓸 수 있다는 치명적인 문제점이 있었다.

글로벌화 되면서 여러 나라끼리 대화를 해야하는데 대부분 나라들이 자국에서 만든 2바이트 문자셋(CP 시리즈)을 쓰고 있었다는 문제가 있었다.

결국 서로의 문자셋은 호환이 되지않기에 문제가 생겼다. 그래서 호환되는걸 만들자!! 라는 취지로 유니코드를 만들었다.

근데 유니코드를 만들고 보니까 문제가 생겼다. 전 서계의 모든 문자를 다 포함하자는 취지는 좋았다.

그런데 용량이 4바이트로 커지게되었다는것이다. 사실 전세계의 문자를 다 포함하는데 4바이트나 들지는 않는데...

여러가지 복잡한 이유때문에 합리적이게 만들다보니 4바이트가 되었다.

이 유니코드를 인코딩하기 위해서 제일 처음 고안된건 utf16이라는 가변길이 인코딩이다.

사실 세상에 딱 필요한 문자만 다 긁으면 어거지로 2바이트 안에 들어가진다.

그리고 보조 문자들을 다른 2바이트 안에 넣어서 꼭 필요한건 2바이트로, 아닌건 4바이트로 표현하는 방식이다.

다행히도 한글,일본어,중국어 등의 문자들도 이 2바이트 영역안에 들어가지므로 각나라의 CP를 쓰는것 보다 낫다고 할 수 있다.

utf16은 최소 단위가 2바이트이기에 문제가 하나 있는데 웹으로 전송할때 컴퓨터에 따라서 be(빅엔디안)나 le(리틀엔디안) 둘중 하나를 선택해야한다.

빅엔디안과 리틀엔디안이 뭔지 모르는 사람은 검색해서 보라. 여기서는 설명치 않겠다.

그래서 utf16과 utf16le가 탄생하게 된다. 일반적인 utf16은 be고 utf16le는 le인 것이다.

그리고 utf16le를 마이크로소프트에서 기본 인코딩으로 채택하게 된다.

여러분이 마이크로소프트에서 모든 문자를 볼 수 있는 이유는 마이크로소프트의 윈도우즈 운영체제가 utf16le를 채택했기 때문이다.

그러나 유럽권과 미국권에서는 길길이 띌수 밖에 없었는데 그 이유는 용량의 문제였다.

한국이야 별 상관없다. 왜냐하면 원래 2바이트였기 때문이다.

latin1이나 latin2를 쓰던 유럽권과 미국권에서는 유니코드를 쓰면 강제로 2바이트로 증가되게 된것인데

이는 문서들의 용량이 2배로 뻥튀기가 된다는 이야기이다. 이는 선택이 아니라 강제였던것.

다른나라 문자 없어도 잘 사는 유럽권에서 고작 호환성좀 늘리자고 utf16을 써? 안 써! 가 된것이다.

그러나 문제점이 없진 않았기에 결국 모든 나라 문자를 표현하려는 욕구 + 유럽쪽의 요구를 충족시킬 해결책으로 내놓은게

utf8이라는 유니코드 인코딩 방식이다. 이 방식에 의하면 기존의 유럽권은 1바이트로 표현하고

경우에 따라서 2바이트로, 3바이트로, 4바이트로 표현하는 가변길이 코딩이 된것이다.

이 인코딩 방식으로 따지면 한,중,일은 3바이트에 위치해서 기존의 2바이트 보다 1.5배 늘어서 손해를 보게 된다.

그래도 양보심 많은 동양권 나라들은 그냥 1.5배 늘리고 utf8을 공용으로 쓰자는데 동의한다.

는건 개소리고 utf16은 태생이 데이터 전송에 불리하다. 왜냐하면 2바이트로 데이터를 전송하는데 컴퓨터의 엔디안 방식에 따러 전처리를 해야하기 때문.

그러나 utf8은 어짜피 1바이트씩 보내기에 컴퓨터 엔디안에 영향을 미치지 않는다.

그래서 그냥 전송에 가장 합리적인 방식이 utf8이기에 utf8을 선택한 것이다.

반대로 마이크로 소프트가 utf16을 썼던 이유는 전송이 중요하지 않다면 utf16이 합리적이기 때문이다.

한국에서는 예전에 만든 사이트들은 euc-kr(CP949)를 사용하는 경향이 있고 최근에는 용량 손해를 감수하고서라도 utf8을 사용하는 추세이다.

사실 용량을 위해서라면 CP949를 써라! 라고 말하고 싶긴한데 웹에서 사용하기 매우 불편하므로 그냥 utf8로 바꿔서 쓸 수 있다면

바꿔서 쓰는 쪽을 추천한다.