인코딩 방식 이해하기





    한글 인코딩 종류


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




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


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


    조합형 방식 

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

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


    완성형 방식

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

    오래된 한글 표현 방식입니다.


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


    출처 : 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의 경우에는 조합형 방식의 문자집합(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 방식으로 인코딩을 하고 있으며, 그래서 거의 문제가 되는 일이 없습니다.


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



    이 세가지는 윈도우 + 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 Study For Us clamp2x
    • 체리
      2014.11.27 08:37 신고

      가끔 한글깨지는게 euc문제였군요...

    • 지나가다가
      2015.02.27 11:07 신고

      음 여러가지 잘못된 정보가 있네요..... 아래 URL의 글이 좀 더 명확한것 같습니다.

      http://helloworld.naver.com/helloworld/textyle/19187

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2015.02.27 11:17 신고

        링크에 있는 글을 읽어 보았습니다. 제 글보다 더 전문적이고 역사를 공부할 수 있는 좋은 글이군요. ^^
        근데 제글 중 어느 부분이 잘못된 정보인지 모르겠습니다. 댓글 링크에 있던 글을 읽어봐도 굵직굵직한 부분들은 같은 내용이고 잘못된 내용이다라고 판단이 어렵습니다. ^^
        혹시나 잘못된 부분이 있으면 구체적으로 짚어주세요. 확인해보고 잘못된 정보이면 적극 수정하겠습니다. ^^

    • 지나가다2
      2015.02.27 14:59 신고

      글 전체가 완전히 틀려있습니다.

      Unicode 조합형이라고 쓴 것 부터가 큰 에러입니다.
      Encoding과 Charset 은 다른 개념인데. 이에 대한 이해를 먼저 하시는게 좋겠네요.

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2015.02.27 16:30 신고

        구체적인 지적 감사합니다. ^^
        그러고보니 Charset 과 Encoding 과의 차이점이 없이 적어놓았네요.
        오히려 새롭고 정확하게 알 수 있는 계기가 되었습니다. 조속한 시일내에 (1~2일 이내) 다른 분들이 헷갈리지 않게 옳은 방법으로 정정해놓도록 하겠습니다.
        제가 실제로 사용한 경험을 토대로 느끼고 이해한 부분만 글로 적다보니 이론이 충분하지 못했습니다. 죄송합니다.^^

        제대로된 정보로 지적해주신 것 다시 한번 거듭 감사드리고 수정해놓겠습니다.^^

    • Teru
      2015.09.19 18:05 신고

      ALLUS.com 운영자님..

      글의 작성 실력이나, 애독자의 지식수준 배려,
      본인의 경험과 지식을 대중적인 수준에서 풀어내시는 능력..

      뭐 어느것하나 부족함이 없으십니다..
      매번 놀라는것이지만, 요즘 세상에..
      이런 한 권의 책을 읽는듯한 블로그가 존재한다는 것..
      놀랍고 (운영자님께) 감사할뿐입니다..

      이곳을 알게된것에 대해 무척이나 감사하고있고,
      이러한 블로그에 정성스러운 -무엇하나 놓칠수없는- 가르침을 주셔서 감사드립니다

      (^^)(__)

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2015.09.19 18:06 신고

        언제나 글에다 극찬을 남겨주셔서 감사합니다.^^
        좋은 하루 보내세요~^^

    • 초보개발자
      2015.10.21 16:06 신고

      학기말에 실습을 다니는 학생인데, 모바일 클라이언트 - 웹서버 sms발송 앱제작중에
      여러가지 궁금하여 검색 도중, 블로그에 잠시 들르게 되었습니다.
      생각없이 인코딩을 써왔는데, 이글보고 무엇이 문제이고 무엇이 해결점인지 초점이 잡히게 되었네요.
      좋은글 써주셔서 감사합니다.

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2015.10.21 23:35 신고

        요즘에는 UTF-8로 코딩을 거의다 하는 추세입니다.
        미약한 글이지만 도움이 되었다니 다행입니다. ^^


    • 2015.11.13 22:10

      비밀댓글입니다

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2015.11.13 22:59 신고

        맞춤법에 대해서는 굉장히 신경쓰는 편인데, 감사합니다. 수정했습니다.^^

    • jjkstr
      2016.02.23 16:16 신고

      깔끔하며 논리적인 글 잘 읽었습니다.

      헌데, 유독 코드 페이지 949가 차지하는 바이트에 대한 정보가 빠져있네요?
      euc kr의 확장판으로써 그대로 2바이트인것인지, 아니면 확장한 만큼 늘어난 것인지.
      여기까지 제공되었다면 정말 완벽한 문체를 겸비한 교과 자료로도 손색없는 훌륭한 문서입니다.

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.02.23 17:08 신고

        차이하는 바이트수는 2바이트로 동일합니다. 대신 다양한 문자들로 늘어났을 뿐입니다.

        생각지도 못한 부분에 지적 감사드리며, 본문 글을 수정해놓도록 하겠습니다. 또한 칭찬 감사합니다.^^

    • little_endian
      2016.02.26 17:49 신고

      "현재는 윈도우에서 사용하는 방식은 CP949를 사용하고 있고" <--- 이 부분이 좀 이상합니다.

      이 글 작성 시간이 언제인지 모르겠지만, 윈도우는 이미 NT부터 UNICODE를 기본 베이스로 하고 있습니다. 그리고 기존 CP949는 기존 프로그램과 호환성을 위해서 병행 존재하는 걸로 알고 있는데요, 그 근거는 다음과 같은 간당한 코딩으로 증명이 됩니다.

      먼저 wide character에 'ㄱ'을 담아 헥사 코드로 추출하면,

      wchar_t word = L'ㄱ';
      wcout << hex << static_cast<int>(word) << endl;

      결과값이 3131, 즉 UNICODE 의 'ㄱ'값과 일치합니다. 이는 UNICODE를 지원하고 있다는 이야기죠.

      그리고 wide character를 사용하지 않고, 똑같은 방식으로 헥사를 추출하면
      (댓글 달기에 실체 출력한 스크린샷을 붙혀넣을 수가 없어서 매우 답답하군요^^)

      int word = 'ㄱ';
      cout << hex << word << endl;

      a4a1 이 출력되는데 이는 CP949의 'ㄱ' 과 일치합니다.

      그래서 "현재는 윈도우에서 사용하는 방식은 CP949를 사용하고 있고" <-- 이렇게만 이야기하면 윈도우가 기본적으로 CP949만 사용하는 것으로 오해할 여지가 있는 것 같습니다.

      그리고 윈도우 7의 경우 UNICODE 버전 5.1을 지원합니다.


      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.02.26 17:54 신고

        아, 현재는 CP949만 쓰인다는 내용이 오해의 소지가 있네요. ^^
        본문 수정해놓도록 하겠습니다. 지적 감사합니다. ^^

    • 들려가다가...
      2016.03.11 20:16 신고

      구글로 인코딩 관련 검색을 하다가 들어게 되었습니다. .. 그런데 잘모르시는 분들이 이글을 보고 오해하실까봐 댓글을 남김니다.
      일단 유니코드는 완성형 문자집합입니다. 한글은 유니코드로 2byte 입니다. utf-8은 유니코드를 인코딩하는 방식 중 하나입니다. 한글은 utf-8로 3byte입니다.

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.03.12 01:45 신고

        지적 감사합니다.
        유니코드는 완성형 문자집합이군요. 혹시 제가 더 참고할만한 자료들이 있을까요? 있으면 참고해서 글을 수정하겠습니다.
        님의 댓글대로 이야기를 하면 UTF-8 도 완성형 문자집합을 인코딩하는 방식이라는 이야기인데 좀 더 자세하게 알아보고 싶습니다.^^

      • 피터
        2016.11.01 10:53 신고

        들려가다가님 말씀이 맞네요. 저도 UTF-8이 조합형인줄 알았는데 찾아보니까 유니코드 기반 가변길이 인코딩이네요. UTF-8에서 한글이 3바이트인건 초성+중성+종성 으로 3바이트가 아니라 유니코드에서 한글이 할당된 영역이 3바이트 영역이라 3바이트로 표현되는 것이네요. 생각해보면 한글 초성+중성+종성 으로 3바이트를 써버리면 한글 영어 외의 다른 문자를 표현할 수가 없겠네요.^^; 결론적으로 유니코드는 전 세계 모든 문자를 표현하기 위해 정해진 캐릭터셋이고 유니코드의 1~4바이트 범위를 사용하는 가변 길이 인코딩이 UTF-8이라고 보면 될 듯 합니다.

    • 삼댕
      2016.03.14 17:51 신고

      웹소스 인코딩! 메모장 인코딩을 ANSI로 했었네요. 덕분에 해결했습니다. 감사합니다.

    • phantasy
      2016.05.20 05:42 신고

      안녕하세요. 홈페이지의 한글, 일어 문자가 깨지는 현상때문에 여기저기서 자료를 검색하다가 결국 여기까지 오게 되었습니다.

      분명 예전에는 아무 문제 없이 모든 문자를 잘 출력하던 utf-8 인코딩 문서들이 도메인의 php 버전 업그레이드 이후 깨지기 시작했습니다.

      자세한 내용은 지식인에도 질문해 둔 상태입니다. http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040205&docId=252683734

      일반인 수준의 제 얕은 지식으로는 이 문제의 해결법이 전혀 보이지 않습니다. clamp2x 님은 이 문제의 원인이 무엇인것 같아보이시나요?

      정말 php의 버전업이 문제인걸까요? 혹시 php버전의 문제가 아니라, 호스팅 업체의 서버 쪽의 언어가 문제가 있는 건 아닐까요?

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.05.20 09:06 신고

        링크 주소가 보이지 않는데 질문 내용을 다시 남겨주실 수 있나요?^^

      • phantasy
        2016.05.20 13:38 신고

        링크주소는 올바른데, 티스토리에서 자동링크를 만드는 과정에서 뒤에 <br>이 붙어버리네요. 혹시 클릭해서 페이지가 보이지 않다면, [ http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040205&docId=252683734 ] 해당 주소를 주소창에 복사 붙여넣기 하시면 될 것 같습니다.

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.05.20 13:46 신고

        현재 php 의 기본 언어셋이 서버와 조금 다를 수도 있습니다. 요즘 서버에서 UTF-8 이라도 여러가지 버전이 존재합니다.
        이게 서버와 약간만 맞지 않아도 비슷한 문제가 생기기도 합니다.
        http://studyforus.tistory.com/250
        비슷한 내용의 글입니다. 참고해 보세요.

        현재 이 문제는 클라이언트 단에서 해결할 문제는 아니구요. 서버단에서 설정을 해야 합니다. 호스팅을 이용한다면 호스팅 업체에 언어셋을 맞춰달라고 요청하면 됩니다. ^^

      • phantasy
        2016.05.20 17:33 신고

        좋은 의견 정말 감사드립니다. 여러방면으로 테스트를 해봐도 문서의 언어나 저장방식은 아무 문제점이 없었고 지금도 구버전 서버에선 모든 국가의 언어가 아무 깨짐없이 잘 출력되기에 더 상심이 큽니다.

        호스팅 업체 측에선

        "호스팅환경을 변경하면 변경전 상주하던 버전에 맞추어서 제작을 하시는데 높은버전으로 올리시면 언어가 정상적으로 출력되지 않는다던가. 게시판이나 기타 오류가 다소 생기기 때문에, 작업량이 다소 생기게 됩니다."

        버전에 맞추어서 문서제작을 하지 않은 제게 책임이 있다는 뉘앙스의 답변을 하더라고요. 하지만 일반 사용자 입장에서는 서버의 언어설정과 적용중인 PHP 버전이 잘 연동되고 있는지 확인할 수가 없으니 답답할 따름입니다. 게다가 인코딩과 저장방식 모두 UTF-8 로 모든걸 통일해서 문서를 제작했다면 할 수 있는 최선의 방법은 모두 다 한게 아닐까요...

        심지어는 '문서를 UTF-8 이 아닌, ANSI 형식으로 저장하면 웹에서도 다른 문자들이 정상적으로 보인다'는 조언을 호스팅 업체가 해주긴 햇는데, 아시겠지만 이럴경우 유니코드 계열에서만 구현 가능한 문자들이 여기서 깨지게 돼버리죠.

        으 어쨌든 말이 너무길었네요... 업체측에 다시 한 번 문의를 넣으면서 다른 호스팅 업체측들의 Q/A 게시판도 둘러봐야 할 것 같습니다...

      • Favicon of http://studyforus.tistory.com BlogIcon Study For Us clamp2x
        2016.05.20 17:52 신고

        호스팅 업체측에서 서버측, 웹서버측, php측, 데이터베이스 측 모두 UTF-8을 지원한다면 문서가 정상적으로 출력이 될겁니다. php 버전이 업 된다고 잘 보이던 문서가 같은 인코딩 환경에서 갑자기 글자가 깨질리도 없어보이구요.
        현재는 서버측의 문제로 보입니다.^^

      • 피터
        2016.11.01 11:14 신고

        웹호스팅을 이용하시는거면 서버 환경에 관계없이 인코딩되도록 작성하실 수밖에 없습니다. 웹호스팅에서 특정 사이트에 맞춰서 서버 환경을 세팅해주기는 무리겠지요. 서버 호스팅이라면 웹서버 데몬(apache 등), php, DB 데몬(mysql 등) 설정을 확인해보시기 바랍니다. 서버 시스템 locale은 사실상 관계 없다고 봐도 무방합니다. 데몬이나 패키지 버전이 올라갈 경우 기본 인코딩이 변경될 수 있기 때문에 데몬 설정을 맞춰주던가 소스에서 데몬 설정에 관계없이 인코딩이 고정되도록 작성하시든가 둘 중 하나의 작업은 되셔야 할 것이며 DB 캐릭터셋은 소스에서 설정이 불가능할 것이니 필히 DB 캐릭터셋이 일치해야 합니다. DB 버전도 올라갔으면 마이그레이션 과정에서 캐릭터셋에 유의하지 않으면 한글 데이터가 깨지는 경우도 있습니다. 참고로 위에 분이 올려주신 링크에 ko_KR.UTF-8, en_US.UTF-8 등에 대해 나온 부분은 실제 인코딩 방식에 차이는 없습니다. ko_KR, en_US 은 '기본 언어' 지정일 뿐입니다. 예를 들어 한글 메시지와 영어 메시지 중 어느 쪽을 출력해줄 것인지를 지정하는데 쓰인다고 보면 됩니다.


    • 2017.11.28 09:44

      비밀댓글입니다

티스토리 툴바