반응형

     

     

    인코딩 방식 이해하기

     


     

     

     

      한글 인코딩 종류

     

    윈도우를 기본 운영체제로 사용하였을 때는 전혀 느끼지 못했던 인코딩 방식이 웹서버를 운영하면서 인코딩 표준을 따라가다 보니 여러 문제점이 생겼습니다.

     

     

     

    한글 인코딩 방식은 크게 두가지로 나뉩니다. UTF-8EUC-KR 방식입니다. 원래 윈도우는 CP949방식을 사용했는데, 윈도우를 개발한 마이크로 소프트에서 EUC-KR 방식에서 확장하였기 때문에 MS949라고도 부릅니다. 참고로 현재는 윈도우가 유니코드도 지원하며, 요즘 개발되는 윈도우는 유니코드를 베이스로 베이스로 하고 있다고 합니다. (댓글에 little_endian 님이 제보해주신 내용) 하지만 서버로서 윈도우는 아직도 약간의 문제점을 안고 있는 것은 사실입니다.

     

    이름만 듣기에는 굉장히 생소한 부류인데, 컴퓨터를 옛 모델부터 만져오신 분들에게는 이렇게 설명하는 것이 더 편리할 수도 있습니다. 한글 표현(또는 작성 형태)에 따라 조합형완성형으로 불립니다.

     

    조합형 방식 

    한글의 편리함을 그대로 가지고 있는 방식입니다. 자음과 모음을 초성, 중성, 종성으로 구분하여 문자를 작성하는 방식을 이야기 합니다. 초성, 중성, 종성을 각기 따로 인식하고 그 것들을 하나의 바이트로 인식하고 조합되어, 총 3바이트의 문자로 인식합니다. (다른 종류도 있긴 하지만 3바이트 방식이 가장 일반적인것 같습니다.) 

    제 개인적인 견해로는 가장 한글과 맞는 방식이라고 생각합니다.

     

    완성형 방식

    문자를 하나의 완성되어져 있는 글자로 인식하는 방식입니다. 한글이 "가"부터 만들어 질 수 있는 문자표를 토대로 문자를 인식합니다. 유니코드보다는 확장성이 떨어지는데 그 이유는 만약 "꽰" 이라는 글자가 완성형 문자표가 있지않다면 "□" 식으로 표기가 됩니다. 이게 8Bit 시절에 제한된 수의 한글만 사용가능한 글자 체계이기 때문입니다.

    그렇기 때문이 이 방식은 꽤 오래된 한글 표현 방식입니다.

     

    이해하기 쉬운 이미지가 있어서 참고하시는데 도움이 될 듯합니다.

     

    출처 : 

    http://blog.ohmynews.com/q9447/tag/%EC%99%84%EC%84%B1%ED%98%95%20%EC%BD%94%EB%93%9C

     

     

    누가봐도 조합형인 조합형 방식이 한글을 표현하는데에 가장 좋은 방법입니다. 왜냐하면 확장성이 좋으니깐요.

    하지만, 일반적으로 대한민국의 컴퓨터 사용환경에서 조합형방식을 사용하기에는 아주 치명적인 결함이 있습니다. 그 이유는 바로..

     

    윈도우의 운영체제 점유율 때문입니다.

     

    윈도우의 인코딩 방식은 기본적으로 완성형입니다. 엄밀하게 이야기 하자면, CP949 (코드페이지 949) 방식을 사용하여 완성형으로 사용하지요. 완성형이지만 EUC-KR에서 진화한 CP949 방식은 더 많은 한글 테이블을 제공합니다. 거의 조합형로 쓸 수 있는 모든 한글을 포함하고 있다고 보시면 됩니다.

     

    즉, 한글 작성에 있어서는 조합형와 별반 다르지 않았습니다. 그런데, 왜 이게 웹 서버스를 시작하면서 문제가 되느냐, 웹서버나 데이터베이스 또는 php의 경우에 UTF-8과 EUC-KR 중에서 인코딩을 서로 똑같이 맞춰줘야 정상적으로 문자표현이 가능하기 때문입니다.
    그럼 좀더 UTF-8과 EUC-KR 방식에 대해 더 자세히 알아보도록 합시다.

      UTF-8

     

    현재 웬만한 개발자들이 원하는 방식입니다. 이유는 아주 간단합니다. 웬만한 서버 운영체제와 웹 서버 그리고 코딩자체가 UTF-8로 제작하면 별다른 인코딩을 따로 할 필요가 없기 때문입니다. UTF-8 방식은 대표적인 유니코드 인코딩 방식입니다. 최근에는 UTF-8 방식에서도 세분화되어 각 프로그램에 맞추거나, 더 많은 문자열을 지원하는 등 국가별로 더 호환이 잘되게끔 하는 방식도 존재합니다. (DB에서 최근 많이 사용하는 utf8mb4와 같이 이모티콘을 지원하는 유니코드 방식입니다.) 유니코드 인코딩 방식중에서 UTF-8은 가변 길이 방식이기 때문에 1~4바이트까지를 이용해서 문자를 작성할 수 있습니다. (22.06.22 수정)

     

    UTF-8의 경우에는 유니코드 인코딩 방식중 하나입니다. 유니코드 인코딩 방식에서 가장 대표적인 문자집합인데, 그 이유는 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 방식으로 인코딩을 하고 있으며, 그래서 거의 문제가 되는 일이 없습니다.

     

    실제로 저도 몇몇 포스팅에서 인코딩 방식 때문에 윈도우 서버 환경에서는 정상적으로 실행이 되지 않았지만, 리눅스 환경에서는 완벽하게 사용가능하던 소스들이 몇개 있습니다.

     

    해당 글 보기

     

    IIS 개인 서버에 Own Cloud 설치하기

     

    [개인서버 구축] Nas처럼 OS를 사용하자! <웹기반 OS - eyeOS>

     

    FTP 프로그램 없이 Web FTP로 접속하기


     

    이 세가지는 윈도우 + IIS 환경과 리눅스 + Apache 환경에서 모두 테스트를 해봤는데, 윈도우 + IIS 환경에서는 인코딩 방식이 서로 달라 한글 표현 문제가 발생하였습니다.

    예를 들어 "새폴더"라는 이름으로 폴더를 만들고 난 뒤 서버에 저장되어 있는 실제경로로 찾아가 만들어진 폴더 명을 보면 제대로 표현이 안되어 있는 것을 확인할 수 있습니다.
    또한 "한글폴더"로 되어있는 한글명 폴더는 이름을 확인할 수도, 클릭을 할 수도 없었습니다.

     

    웹서버인 IIS는 UTF-8을 지원하는데, 실제경로에 한글폴더를 만드는 과정에서 윈도우가 완성형 한글을 사용하기 때문에 오류가 발생했나 봅니다.
    하지만, 리눅스 + Apache 환경은 별 탈 없이 사용가능 하였습니다. 한글 표현에도 전혀 불편한 부분이 없이 구현이 되더군요.


      EUC-KR, CP949 (MS949)

     

    완성형 한글인 EUC-KRCP949에 대해서 알아보자면 글자하나가 완성된 형태여야 하는 방식입니다. 즉, 완성형 문자로 EUC-KR의 경우에는 웹에서 CP949(엄밀하게는 다르지만 거의 비슷하므로 MS949와 동일하게 취급)의 경우에는 윈도우에서 가장 많이 사용을 합니다.

     

    EUC-KR 방식은 완성형 인코딩방식이고, 한글을 2바이트로 사용하는 문자집합 (Character Set)입니다. 주로 2바이트권 문자에서 사용하는데, 문제는 EUC-KR을 사용하는 국가. 즉, 한글을 사용하는 곳에서만 제대로 문자가 보이는 단점이 있습니다. 한글과 영어만 사용하는 페이지에서 적합합니다. 또한 CP949 역시 연장선에 있기 때문에 같은 2바이트를 사용합니다.

     

    EUC-KR은 KS X 1001와 KS X 1003을 사용하는 8비트 문자 인코딩으로, EUC의 일종이며 대표적인 한글 완성형 인코딩이기 때문에 보통 완성형이라고 불린다.- 출처 : 위키

     

    코드 페이지 949(CP949)는 마이크로소프트사가 도입한 코드 페이지이다. 본래는 KS C 5601의 완성형 한글을 표현한 코드 페이지였으나, 윈도 95부터는 확장 완성형 혹은 통합형 한글 코드(Unified Hangul Code)이라는 명칭으로 확장되어 현대의 모든 한글을 수용하게 되었다. 마이크로소프트에서는 이 인코딩을 기반 문자 집합 이름인 "ks_c_5601-1987"로 사용하고 있다. 다만 이 코드 페이지는 IANA에 등록되어 있지 않으므로 인터넷 상에서 정보를 주고받는 데 대한 표준은 아니다.- 출처 : 위키

     

    저는 게임중에 삼국지에 한참 빠져 살았던 적이 있었는데 그 게임에서는 장수의 이름을 입력할 때 "가"부터 "하"까지의 글자표에서 직접 이름을 찾아 선택을 했던 기억이 납니다. (아마 삼국지 4정도 이지 않을까 합니다.) 지금 생각해보면 그런 한글방식이 바로 완성형 방식인 것이지요.

     

    EUC방식은 영어같은 단일바이트 문자가 아닌 한글, 일본어, 중국어 등과 같은 한 글자를 쓸 때마다 2바이트가 들어가는 더블바이트 문자권에서는 많이 사용되는 방식입니다.

    즉, 한글, 일본어, 중국어 등등은 인코딩 변환에서 자유로울 수 없다는 것이지요.
    하지만, 마이크로 소프트가 한글을 정식으로 사용하기 위해서 개발한 CP949의 경우는 현재 사용하는 한글 중 일정한 규칙에 의해 만들어 낼 수 있는 모든 문자를 완성형으로 만들어 놨기때문에 더 이상 한글표현이 문자표에 없어서 표현이 안되는 일은 없어졌습니다.
    현재는 웹에서 UTF-8를 기본으로 사용하고 있어서 웬만한 한글 사이트를 만드는 경우에는 인코딩을 EUC-KR로 설정해야 한다고 합니다. 이유는 아주 간단한데, 윈도우를 사용하는 사람들이 많기 때문에 정상적으로 사용하기 위해서는 UTF-8보다는 EUC-KR로 인코딩하는 것이 더 적합했지요. 한 때 "사진파일이 보이지 않으면 UTF-8로 보냄 체크를 해제하세요."라는 글을 본적이 있을 텐데 한글 사진 파일을 표현하기 위해서 브라우저에서 제공하는 인코딩 방식을 바꾸라는 아주 유명한 말이지요. 윈도우에서 사진 파일이름을 한글로 하는 경우 자동적으로 완성형으로 인코딩 되는데 서버에서 제공하는 인코딩 방식이 UTF-8인 경우에는 정상적으로 파일이름을 로드할 수가 없기 때문에 나타나는 현상이었습니다.
    이렇듯, 한글과 웹 서비스와는 좀 더 신경써야 하는 부분이 많은데 인코딩을 다양하게 지원해주는 웹 소스가 있으면 아주 반갑습니다.웹 스토리지 오픈 소스 중에서 Pydio는 기본적으로 한글을 인코딩에 맞춰 자동으로 선택해주는 것 같아 보였습니다. 그리고 Pydio6로 판 올림함에 따라서 아예 인코딩 방식을 직접 선택할 수 있도록 하였습니다.

    <Pydio의 경우에는 CP949 인코딩을 지원합니다. 물론 기본 인코딩이 UTF-8인 경우 인코딩 방식이 UTF-8로 기본설정됩니다.>

     

    즉, 웹소스에서 한글을 제대로 사용하려면 소스 자체에서 완성형으로 코딩하든지, 아니면 다양한 인코딩 방식을 지원하든지 하는 방식으로 설정할 수 있습니다.



      인코딩 간의 문제점

     

    위의 내용들을 종합해보면 
    인코딩방식에 따라 표기할 수 있는 관계는 이렇습니다.


    완성형 중에서 EUC-KR의 경우에는 종종 빠져있는 문자가 있지만, 확장 완성형인 CP949의 경우에는 유니코드(UTF-8)에서 표현할 수 있는 모든 문자를 표현 가능합니다. 따라서 웹을 사용하지 않는 윈도우 환경이라면 크게 불편함이 없을 수 있습니다.
    하지만, 웹에서의 관계는 위에처럼 표현가능한 것이 아니라, UTF-8이면 UTF-8, EUC-KR이면 EUC-KR끼리 밖에 제대로 표현을 못합니다. 이런 상황을 생각해보면 각종 웹 소스들을 사용할 때 인코딩 부분만 해결하면 될 것 같습니다.
    인코딩을 변환하도록 하는 함수도 있고, 서버 자체의 인코딩을 바꾸는 방법도 있습니다.
    각 소스별로 안고 있는 문제들이 제각각이기 때문에 혹시라고 한글 문제로 고생하고 계신 분들은 인코딩을 확인해보세요.

    확인해야 할 항목은 다음과 같습니다.
    • 서버 OS 인코딩 상태
    • 웹 서버 인코딩 상태
    • PHP 인코딩 상태
    • 웹 소스 인코딩 상태
    • (데이터베이스를 사용하는 경우) 데이터베이스 인코딩 상태
    이 인코딩 방식등이 다 동일한 방식으로 되어있는지 확인하시기 바랍니다.

     

     

    여담이지만, 인코딩 방식만 이해했을 뿐 인코딩을 변환하는 과정은 아직 알아보는 중입니다. 예전부터 인코딩 문제를 해결하고 이 글을 작성하려고 하였지만 워낙에 궁금해 하시는 분들도 계시고 해서 먼저 작성하였습니다.

    일단 원인을 알았으니 다음과정으로 나아갈 수 있겠죠?

     

     

     

     

     

     

     

     

    반응형
    Posted by clamp2x