'dev/tMango Project'에 해당되는 글 2건

  1. 2008/01/29 scott EUC-KR / UTF-8 (1)
  2. 2008/01/07 scott SearchBooster #001

EUC-KR / UTF-8

dev/tMango Project RSS Icon ATOM Icon 2008/01/29 19:16 scott

최근 새롭게 전개되고 있는 웹서비스 형태를 정의하는 중요한 요소 중의 하나인 UTF-8 인코딩은, 전세계 문자집합을 동일한 하나의 인코딩 방식으로 표현할 수 있기 때문에 웹에 가장 적합하고, 또 웹 뿐만이 아닌 다른 서비스나 어플리케이션에서 사용하면 좋을 것 같은 문자 집합이다.

그동안 한국에서 웹용으로 가장 많이 사용하는 Charset은 EUC-KR(KSC5601)일 것이고,
개발자들이 어플리케이션이나 엔진, 특히 웹 어플리케이션을 개발하면서 가장 많이 부딪히게 되는 문제가 charset 처리, 국내 개발자들에게는 특히 한글 처리 문제일 것이다. 나도 지금까지는 이 분야에 대해서는 잘 몰라서 직접 해본적이 없는데, 이제는 어쩔 수 없이 직접 하고 있다.
(회사나 어떤 프로젝트를 진행하면서 개발자의 내공이 가장 많이 진보하는 시기는 "사수부재"의 순간이다. 혹은 "나 밖에 없네" 상황을 자각할 때, 그 내공은 못해도 10갑자는 늘기 마련이다.)

개발/튜닝 중인 검색엔진은 한글 처리가 영 신통치 않고, data 흐름에 있어서도 문자열 처리에 있어서는 앞뒤가 안맞는 부분이 많이 있다.
원 제작자가 영어권 사람이라, 비영어권의 multi-byte 캐릭터셋 처리에 있어 특히 아쉬운 부분이 많이 있다.
내가 어떤 서비스를 개발하는 과정에서 가장 신경을 많이 쓰고 공을 들이는 부분은 바로,
제공 되는, 혹은 제공해야 하는 API의 일관성이다. 내가 작성한 코드를 사용해야 하는 다른 코드나, client가 혼동하지 않도록 깔끔한 인터페이스를 작성하는 것이 요즘들어 가장 신경 쓰는 부분이고 후배 개발자들에게도 귀찮게 강조하는 부분이다.
지금 사용 중인 오픈 소스는 이러한 부분에서 약간 아쉽다.
물론 전반적으로 봤을 때는 엄청나고 감탄스럽다. 사실 오기가 발동하기는커녕 그 코드 스타일이나, 디자인 스타일을 모방하기 급급하다.

어쨋건 간에, EUC-KR charset을 유니코드나 멀티바이트 유니코드로 변환하기 위해서,
유니코드간의 인코딩 변환은 계산식으로 가능하지만, EUC-KR은 변환 규칙이 없기 때문에 사이즈가 꽤 큰 매핑 테이블을 사용해야 한다.
계산식이 필요없으므로 바이너리 검색이나 여타 좋은 알고리즘을 사용하면 속도는 더 빠를 수도 있겠지만, dso(dynamic shared object), 혹은 dll로 구현하여 스트레스성의 서비스 어플리케이션에서 빈번하게 로딩을 해야 한다면 라이브러리 내에 이러한 큰 테이블을 가지고 있는 것이 꽤 부담스러워진다. 게다가 테이블을 더 크게 만들거나 추가 테이블을 하드코딩해 놓으면 검색 속도를 높일 수 있다는 악마의 유혹까지 있다면..... 부담스러워도 이게 현실인가보다.

작성 중인 라이브러리의 내부에서 charset을 처리하는 루틴에서는 Simple Unicode를 사용하지만, 외부 인터페이스 부분에서는 UTF-8으로 변환 처리된다. EUC-KR은 데이타 소스로만 존재할 뿐이므로 한번만 Simple Unicode로 변환되면 그 후에는 유니코드 체계내에서만 상호 인/디코딩 처리되도록 한다.

일단 여기까지,,,
뭘 해도 정리가 안되는군.



2008/01/29 19:16 2008/01/29 19:16
받은 트랙백이 없고, 댓글 하나가 달렸습니다.

댓글+트랙백 RSS :: http://www.semanogic.com/blog/tc/scott/rss/response/37

댓글+트랙백 ATOM :: http://www.semanogic.com/blog/tc/scott/atom/response/37

SearchBooster #001

dev/tMango Project RSS Icon ATOM Icon 2008/01/07 13:56 scott

1. 루씬의 한글 처리 오류
루씬의 한글 처리 오류는 먼저 유니코드의 한글 범위를 인식하는 코드의 부재와,
demo 프로젝트에서는 UTF-8 Data source를 wide charater 즉, 유니코드로 변환하는 매크로의 오류 문제였다.
~0x80 이전까지의 ASCII는 유니코드와 100% 호환되기 때문에 1byte로 표현되는 ASCII 영역의 UTF-8 캐릭터를 2byte 자료형에 복사하도록만 처리하여 문제가 생긴 것이었다.
ASCII(~0x80) 보다 큰 영역에 할당된 것들에 대해서는 이렇게 처리하면 안되기 때문이다.
UTF-8 -> Simple Unicode 변환 처리를 수정하고 난 후에는 한글 처리 및 한글 검색이 정상적으로 동작하고 있다.

2. RSS 리더
타겟으로 잡고 있는 data source인 RSS Feed는 UTF-8 인코딩이 추세이긴 하지만, 기존의 EUC-KR 인코딩, 혹은 다른 방식으로 인코딩되어 있는 것들도 많이 존재한다.
XML 파서를 이용하여 Feed의 인코딩 방식을 파악할 수 있다는 것만으로도 가슴을 쓸어내린다.

3. 스파이더
자바 루씬 기반의 오픈 검색 어플리케이션인 Nutch에서 Web Crawler 부분을 따로 떼어내어 스파이더로 사용할 것이다. 이부분은 자바 버전만이 존재하기 때문에 자바 전문가께서 진행 중이다.

2008/01/07 13:56 2008/01/07 13:56
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.semanogic.com/blog/tc/scott/rss/response/1

댓글+트랙백 ATOM :: http://www.semanogic.com/blog/tc/scott/atom/response/1