청기와랩 블로그
한글, EUC-KR vs UTF-8
2014년 10월 01일 by 청기와랩
조만간 돌아오는 한글날 공휴일에 대비하여...
(대왕님 항상 고맙게 생각 합니다... 충성!)
SMS API 를 사용할 때 가장 고민되는 부분이기도 하거니와 한글날의 의미도 되새긴다는 의미에서 오늘은 EUC-KR vs UTF-8 이라는 주제로 기술 블로그를 장식해 볼까 합니다.
EUC-KR, UTF-8은 한글 문자세트의 인코딩 방식 입니다.
한글 문자 세트는 EUC-KR, CP949, UTF-8, UTF-16 등으로 표현될 수 있습니다. 이것을 바로 인코딩이라고 합니다.
한글 문자 세트도 한국 IT 역사에 있어 여러 발전의 과정을 거듭하였는데요.
보통 KSC5601과 Unicode 정도만 기억 하시면 됩니다. (조합형 한글 등의 흑역사를 아신다면 당신은 최소 16진수로 스무살 이상^^)
KSC5601은 완성형 문자세트로 Unix 계열에서는 EUC-KR 인코딩으로 사용 되었고, MS사의 공헌(?)으로 확장 완성형으로 발전 되며 Windows 계열의 OS 에서는 CP949 라는 인코딩으로 널리 사용 되었습니다.
EUC-KR과 CP949는 거의 같다고 보면 됩니다만 EUC-KR이 표현하지 못하는 문자세트를 더 포함하고 있습니다.
가령 "쀍" 같은 글자 말이죠. :-)
잠시 SMS 관련 내용으로 빠지자면...
과거 한국의 CDMA 무선 통신망은 EUC-KR을 사용하여 단문전송 서비스를 지원 하고 있습니다. 아무래도 통신망과 연동되는 네트워크 장비류들은 전통의 Unix 계열에서 돌아갔었기 EUC-KR 이 선택된게 아닐까 추측 되는데, CDMA 쪽 표준의 경우 한국어는 반드시 EUC-KR을 쓰게끔 표준에 명시 되어 있는 부분이 있어 CDMA에 한국 쪽 입김이 꽤 강했었구나 하는 생각도 듭니다.
반면 유럽쪽의 GSM의 단문 전송 표준의 경우 Latin 언어들은 7비트 ASCII 를 사용하는 등, 한 바이트에 한 글자라도 더 보내고자 했던 처절한 몸부림의 흔적이 남아 있는 반면, 한,중,일 등의 언어들은 대충 고민 하고 UCS2 (UTF-16) 을 쓰도록 한 수퍼 쿨한 모습도 보였었죠.
다시 본론으로 돌아와서...
이후 확장완성형에서 표현하지 못하는 한글은 사용되지 않다 보면 없어질 수도 있다는 위기감과 인터넷의 발달로... 유니코드가 드디어 한글 컴퓨팅 환경의 기본의 자리를 차지하게 되었는데요. Linux 를 필두로한 Unix 기반 OS 들은 EUC-KR 에서 UTF8 또는 UCS4등으로 한국어 Locale 지원을 변경하게 됩니다. 그렇게 대혼란의 몇년이 지나고 지금은 별 불편 없이 UTF-8로 대동단결 하는걸로 정리 되었습니다.
(물론 BSD계열에서 UCS4를 사용하는 것도 있고, UTF-8의 경우 Unicode Normalization 관련하여 타 OS와는 다른 정책 - NFC vs NFD - 을 택하고 있어 여전히 혼란은 조금 남아 있습니다. 특히 Mac OS X에서 가져온 한글 파일명이 다른 OS에서는 분해되는...."한글" <-> "ᄒ ᅡ ᆫ ᄀ ᅳ ᆯ" 그래도 UTF-8 <-> EUC-KR 시 글자가 사라지는 것보다는 훨씬 낫습니다.)
그렇다면... 청기와랩의 SMS API는 무슨 문자세트와 인코딩을 사용하느냐????
바로 바로 유니코드기반의 UTF-8을 기본으로 하고 있습니다.
인터넷에 기반한 Open API 이고 그에 걸맞게 JSON 을 자료 전송 규격으로 채택했기 때문인데요. ECMA-404 표준에 따라 JSON 표기시 Unicode 인코딩 (uHHHH) 또는 UTF-8인코딩으로 문자열을 처리하는 것이 기본 원칙 입니다
("한글"은 UCS2의 uHHHH 포맷으로 "\ud55c\uae00"로 표현 되거나, UTF-8로 그냥 "한글" (ed 95 9c ea b8 80) 표현 됩니다.)
참고로 uHHHH 포멧은 인코딩이 아니라 JSON Data Serialization을 위한 Javascript의 문자열 ESCAPE 처리 규칙입니다.
대다수의 JSON 라이브러리들이 알아서 잘 변환 해주니 걱정하실 필요 없습니다. JSON 라이브러리를 사용할 수 없는 부득이한 상황이라면 그냥 UTF-8로 한글을 사용하시면 됩니다. 이때 HTTP Request 헤더의 Content-Type을 application/json;charset=utf-8 로 설정하면 더 명백 합니다. GitHub 의 청기와랩 SMS API 예제들을 참조하세요.
만약 EUC-KR, CP949, Shift-JS 같은 비 유니코드 문자열 인코딩이 포함되어 있다면 ECMA-404 표준에 의거 JSON 오브젝트로 변환하는 Parsing 과정에서 에러가 발생 됩니다. (청기와랩 SMS API사용시 Status Code 406 Not Acceptable 을 받게 되는 원인 중 하나)
사실 JSON에서의 Unicode 문자열 표현과 관련한 내용은 더 적어야 할게 많지만 그것은 libjson 이나 json.jar같은 각 프로그램 언어별 JSON Library들의 몫으로 남겨두겠습니다. 청기와랩 SMS API 에 고려 되어 있는 EUC-KR 변환 문제 관련 내용은 다음 링크의 주석 부분 참조하세요. http://bluehouselab-sms-openapi.readthedocs.org/ko...
그런데 여전히 시대의 흐름과는 다르게 한글 문제에 있어 여전히 대동단결 하지 못한 OS가 있습니다. 바로 MS WIndows 인데요. 시스템 기본 한글 인코딩으로 CP949 를 사용하므로 인터넷과 관련한 프로그램... 특히 웹브라우져 개발자들이 많은 눈물을 흘렸었죠.
그런 이유로 Windows 플랫폼에서 여타 OpenAPI를 연동/활용한 개발의 경우, JSON 포맷으로 EUC-KR이나 CP949로 한글을 넣어서 전송한다 던지 하는 실수가 나올 수 있습니다. HTTP Request Header 에 Content-Type에 EUC-KR이나 CP949를 명시하여 극복 할 수도 있습니다만, 그럴 경우 원래 JSON이 아니기도 하거니와, 윈도 환경의 개발자의 경우 EUC-KR 인지 아닌지 모르고 개발 하게 되는 경우가 많아서 인코딩과 관련한 문제가 생겼을때 상당한 시간을 소비하게 되는 경우가 많습니다.
(청기와랩의 SMS API 예제 코드들은 모두 UTF-8로 작성 되어 있습니다. Windows 환경에서는 GitHub에서 보여주는 코드를 Copy&Paste 할 경우 CP949로 저장될 수 있으므로 꼭 git 로 다운받거나 zip archive로 다운 받아서 실행하세요.)
만약 HTTP Status Code로 406 Not Acceptable을 리턴 받았을 경우 POST로 넘기는 JSON 데이타가 파싱 가능한지와 한글 인코딩이 CP949가 아닌지 먼저 확인해 보시고, Content-Type 부분도 위에 언급한 것 처럼 명백히 지정 되었는지 확인해 보세요.
May the Uni-code be with you...
(대왕님 항상 고맙게 생각 합니다... 충성!)SMS API 를 사용할 때 가장 고민되는 부분이기도 하거니와 한글날의 의미도 되새긴다는 의미에서 오늘은 EUC-KR vs UTF-8 이라는 주제로 기술 블로그를 장식해 볼까 합니다.
EUC-KR, UTF-8은 한글 문자세트의 인코딩 방식 입니다.
한글 문자 세트는 EUC-KR, CP949, UTF-8, UTF-16 등으로 표현될 수 있습니다. 이것을 바로 인코딩이라고 합니다.
한글 문자 세트도 한국 IT 역사에 있어 여러 발전의 과정을 거듭하였는데요.
보통 KSC5601과 Unicode 정도만 기억 하시면 됩니다. (조합형 한글 등의 흑역사를 아신다면 당신은 최소 16진수로 스무살 이상^^)
KSC5601은 완성형 문자세트로 Unix 계열에서는 EUC-KR 인코딩으로 사용 되었고, MS사의 공헌(?)으로 확장 완성형으로 발전 되며 Windows 계열의 OS 에서는 CP949 라는 인코딩으로 널리 사용 되었습니다.
EUC-KR과 CP949는 거의 같다고 보면 됩니다만 EUC-KR이 표현하지 못하는 문자세트를 더 포함하고 있습니다.
가령 "쀍" 같은 글자 말이죠. :-)
잠시 SMS 관련 내용으로 빠지자면...
과거 한국의 CDMA 무선 통신망은 EUC-KR을 사용하여 단문전송 서비스를 지원 하고 있습니다. 아무래도 통신망과 연동되는 네트워크 장비류들은 전통의 Unix 계열에서 돌아갔었기 EUC-KR 이 선택된게 아닐까 추측 되는데, CDMA 쪽 표준의 경우 한국어는 반드시 EUC-KR을 쓰게끔 표준에 명시 되어 있는 부분이 있어 CDMA에 한국 쪽 입김이 꽤 강했었구나 하는 생각도 듭니다.
반면 유럽쪽의 GSM의 단문 전송 표준의 경우 Latin 언어들은 7비트 ASCII 를 사용하는 등, 한 바이트에 한 글자라도 더 보내고자 했던 처절한 몸부림의 흔적이 남아 있는 반면, 한,중,일 등의 언어들은 대충 고민 하고 UCS2 (UTF-16) 을 쓰도록 한 수퍼 쿨한 모습도 보였었죠.
다시 본론으로 돌아와서...
이후 확장완성형에서 표현하지 못하는 한글은 사용되지 않다 보면 없어질 수도 있다는 위기감과 인터넷의 발달로... 유니코드가 드디어 한글 컴퓨팅 환경의 기본의 자리를 차지하게 되었는데요. Linux 를 필두로한 Unix 기반 OS 들은 EUC-KR 에서 UTF8 또는 UCS4등으로 한국어 Locale 지원을 변경하게 됩니다. 그렇게 대혼란의 몇년이 지나고 지금은 별 불편 없이 UTF-8로 대동단결 하는걸로 정리 되었습니다.
(물론 BSD계열에서 UCS4를 사용하는 것도 있고, UTF-8의 경우 Unicode Normalization 관련하여 타 OS와는 다른 정책 - NFC vs NFD - 을 택하고 있어 여전히 혼란은 조금 남아 있습니다. 특히 Mac OS X에서 가져온 한글 파일명이 다른 OS에서는 분해되는...."한글" <-> "ᄒ ᅡ ᆫ ᄀ ᅳ ᆯ" 그래도 UTF-8 <-> EUC-KR 시 글자가 사라지는 것보다는 훨씬 낫습니다.)
그렇다면... 청기와랩의 SMS API는 무슨 문자세트와 인코딩을 사용하느냐????
바로 바로 유니코드기반의 UTF-8을 기본으로 하고 있습니다.
인터넷에 기반한 Open API 이고 그에 걸맞게 JSON 을 자료 전송 규격으로 채택했기 때문인데요. ECMA-404 표준에 따라 JSON 표기시 Unicode 인코딩 (uHHHH) 또는 UTF-8인코딩으로 문자열을 처리하는 것이 기본 원칙 입니다
("한글"은 UCS2의 uHHHH 포맷으로 "\ud55c\uae00"로 표현 되거나, UTF-8로 그냥 "한글" (ed 95 9c ea b8 80) 표현 됩니다.)
참고로 uHHHH 포멧은 인코딩이 아니라 JSON Data Serialization을 위한 Javascript의 문자열 ESCAPE 처리 규칙입니다.
대다수의 JSON 라이브러리들이 알아서 잘 변환 해주니 걱정하실 필요 없습니다. JSON 라이브러리를 사용할 수 없는 부득이한 상황이라면 그냥 UTF-8로 한글을 사용하시면 됩니다. 이때 HTTP Request 헤더의 Content-Type을 application/json;charset=utf-8 로 설정하면 더 명백 합니다. GitHub 의 청기와랩 SMS API 예제들을 참조하세요.
만약 EUC-KR, CP949, Shift-JS 같은 비 유니코드 문자열 인코딩이 포함되어 있다면 ECMA-404 표준에 의거 JSON 오브젝트로 변환하는 Parsing 과정에서 에러가 발생 됩니다. (청기와랩 SMS API사용시 Status Code 406 Not Acceptable 을 받게 되는 원인 중 하나)
사실 JSON에서의 Unicode 문자열 표현과 관련한 내용은 더 적어야 할게 많지만 그것은 libjson 이나 json.jar같은 각 프로그램 언어별 JSON Library들의 몫으로 남겨두겠습니다. 청기와랩 SMS API 에 고려 되어 있는 EUC-KR 변환 문제 관련 내용은 다음 링크의 주석 부분 참조하세요. http://bluehouselab-sms-openapi.readthedocs.org/ko...
그런데 여전히 시대의 흐름과는 다르게 한글 문제에 있어 여전히 대동단결 하지 못한 OS가 있습니다. 바로 MS WIndows 인데요. 시스템 기본 한글 인코딩으로 CP949 를 사용하므로 인터넷과 관련한 프로그램... 특히 웹브라우져 개발자들이 많은 눈물을 흘렸었죠.
그런 이유로 Windows 플랫폼에서 여타 OpenAPI를 연동/활용한 개발의 경우, JSON 포맷으로 EUC-KR이나 CP949로 한글을 넣어서 전송한다 던지 하는 실수가 나올 수 있습니다. HTTP Request Header 에 Content-Type에 EUC-KR이나 CP949를 명시하여 극복 할 수도 있습니다만, 그럴 경우 원래 JSON이 아니기도 하거니와, 윈도 환경의 개발자의 경우 EUC-KR 인지 아닌지 모르고 개발 하게 되는 경우가 많아서 인코딩과 관련한 문제가 생겼을때 상당한 시간을 소비하게 되는 경우가 많습니다.
(청기와랩의 SMS API 예제 코드들은 모두 UTF-8로 작성 되어 있습니다. Windows 환경에서는 GitHub에서 보여주는 코드를 Copy&Paste 할 경우 CP949로 저장될 수 있으므로 꼭 git 로 다운받거나 zip archive로 다운 받아서 실행하세요.)
만약 HTTP Status Code로 406 Not Acceptable을 리턴 받았을 경우 POST로 넘기는 JSON 데이타가 파싱 가능한지와 한글 인코딩이 CP949가 아닌지 먼저 확인해 보시고, Content-Type 부분도 위에 언급한 것 처럼 명백히 지정 되었는지 확인해 보세요.
May the Uni-code be with you...
sms openapi