인코딩을 모르는 문서 디코드하기

피드를 읽다가 BeautifulSoup 새 버전이 나왔다는 소식을 듣고, 뭐가 바뀌었는지 궁금해서
홈페이지를 가 봤습니다. 그런데, 전에 없던
cjkcodecs, iconvcodec에 대한 링크가 갑자기 생긴 것입니다.
오잉 BeautifulSoup에서 웬 cjkcodecs 링크람~ 하고 자세히 봤더니
옆에 chardet라는
인코딩을 자동으로 결정해 주는 라이브러리가 붙어있는 것입니다!

호오.. BeautifulSoup은 지금까지 취해왔던 “개떡같이 쓴 것도 찰떡같이 알아듣는다”를 충실히 지키기 위해, 이제 인코딩이 언급되어 있지 않은 문서도 마구 디코딩을 해 줄 장정인가봅니다;;

Mark Pilgrim이 만든 chardet는 작년 8월에 나온 것인데, 노가다로 일일이 디코딩해보고 결정하는 것이 아니라, 각 인코딩 별로 보통의 빈도에 대한 통계
자료를 기반으로 해서 결정한다고 합니다.
나온지는 제법 오래된 것인데, 참 신기하고 재미있네요.
이제 트랙백 받는 것도 chardet 붙여서 똑똑하게 받아 봐야겠습니다.
^.^; (통계자료는 모질라 안에 들어있는 것을 포팅한 것이라고 합니다.)

6 thoughts on “인코딩을 모르는 문서 디코드하기”

  1. EUC-KR, EUC-JP를 정확히 구별할 수는 없을텐데요… (어차피 통계라는 게 다 그런건가?)

  2. 어차피 통계로 하는거니까, 대충 EUC-KR에서 많이 쓰는 다, 습, 과, 은, 는, 이 이런 것들이 아무래도 걸릴테고.. EUC-JP에서는 카타카나 영역이나 이스케이프 시퀀스가 EUC-KR과 구분 지을 수 있는 통계적 샘플이 되겠죠~ 그런데, 모질라쪽 통계 데이터에서는 특정 부분을 샘플로 잡은게 아니라, 그냥 통짜로 다 돌려서 한 것 같더군요. (소스 보면 정말 노력이 가상해서 이 정도면 되긴 되겠구나 하는 생각이.. ㅎㅎ;)

    옥션은… 알렉사 같은 사이트에서 높아서일까요? =3=3

  3. 전에 비슷한 C++ 라이브러리를 본적이 있다는….

    처음 첫 몇 바이트만 보고 판단하는 라이브러리 였던거 같던데요.

    IE도 이런식이 아닌가 합니다. ㅋㅋ

  4. 예전에 이를 구현해서 웹 페이지들에 적용해 본 적이 있었습니다. 영어, 일어, 한국어만 구분해내는 루틴이었는데도 불구하고 가끔은 실패하더군요. IE가 어떻게 하는지는 모르지만 처음 몇바이트만 보고 구분하기는 어려웠었는데… 페이지 전체에 나온 글자를 보고 확신도를 계산하는 루틴이었습니다. IE나 파폭도 가끔씩은 실패했기 때문에 결국 완전한 구현은 못했지만요. 역시 유니코드를 써야한다는 ^^;;;

  5. EUC-KR과 EUC-JP, GB2312(x-EUC-CN) 등의 구별은 그리 힘들지 않습니다. (100% 확실하지는 않습니다, 물론.) 인코딩 구조는 같지만(정확히 말하면 EUC-JP는 다릅니다), 각 언어별로 쓰는 코드 포인트의 빈도가 크게 달라서 이에 바탕한 통계 모델을 쓰면 어느 정도 긴 텍스트가 들어 오면 별로 많이 틀리지 않습니다. 모질라에서 오래 전부터 구현되어 있습니다. MS IE도 마찬가지이리라고 짐작합니다. Google이나 Yahoo에서 쓰고 있는 녀석들은 모질라에 있는 것보다 더 똑똑하고요. Google에서 쓰는 것은 Basis Tech에서 만든 것이거나 그 변형일텐데, BasisTech은 매우 짧은 텍스트라도 잘 구별한다고 주장하고 있더군요. 모질라에서 쓰는 방법에 대한 얘기는 http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html

    BasisTech의 로제타(언어 및 인코딩 식별 기능을 제공)에 대한 얘기는

    http://www.basistech.com/language-identification/

Comments are closed.