wp-slimstat-ex 테스트 중

블로그 전체의 힛 수/리퍼러/검색엔진 키워드 통계등을 위한 WP 플러그인으로, 오늘 오전까지 쓰고 있던 wp-slimstat을 폐기(?)하고 wp-slimstat-ex로 갈아탄 상태

얼마 전에 포스팅 했듯이 wp-slimstat 플러그인의 경우 검색엔진이 referer인 경우 검색어에 해당하는 부분을 추출†해주는데, 문제는 이 검색어의 인코딩을 utf-8내지는 ascii로 판단한다는데에 있다.(사실 아무 신경을 안쓴다 같지만) 그래서 euc-kr로 아직도 버티고 있는 국내 검색엔진들 – 네이버, 다음, 엠파스 등등 -의 검색어가 제대로 안보였다. 다행히 검색어/검색어가 낀 URI가 따로 저장되서 약간의 코드 수정으로 복구(?)할수 있었다.

새로 설치한 wp-slimstat-ex 의 경우엔 아주 즐겁게도 이 문제가 없다 :D
검색어 부분을 판정하는 부분에서 단순히 URI를 해석만 하는게 아니라 검색어에 해당하는 부분이 UTF-8인지 확인하고 그렇지 않은 경우엔 적절한 인코딩 추정 + UTF-8으로의 변환을 시도한다. 그래서 별도의 검색엔진별 분기 없이도 euc-kr만 쓰는 못된(…) 네이버/다음/엠파스의 리퍼러 URI를 처리할 수 있다.

…그러나 문제는 여기에서 시작된다.
리퍼러 URI는 그냥 플레인하게 주소에서 http:// 부분만 떼어내고 저장이 된다. 그런데 한글만 사용한 검색어의 경우에는 이리퍼러 URI를 역참조하면 이상하게 깨져서 간다. 대체 원인이 뭘까? 누군가 뾰족한 해결책을 제시해봅시다 :)

현재 대충해석해낸 결과는 플레인하게 저장하는 거같은데도 리퍼러 URI를 Urldecode()하고 저장한 것 같이 된다.

예를 들어 다음에서 “지하철 출근길”을 검색한 경우에 DB에 등록된 URI 리퍼러는 검색어 부분만 뽑아내보면 대략%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%C3%B6%EF%BF%BD%EF%BF%BD%D9%B1%EF%BF%BD 이런 식의 수상쩍은 URI로 바뀐다. 반면에 Win32 멀티스레딩으로 검색한 리퍼러 URI는 제대로 저장이 된다. 대체 차이가 뭘까 -_-;

누군가 나에게 적당한 힌트/조언/해결책(!)을 Orz

†검색엔진들이 사용하는 URI에서 검색어에 해당하는 부분이 거의 q=검색어 혹은 query=검색어 같은 경우라서 쉽게 추출되고/일부 예외룰을 통해 이 것을 벗어나는 경우를 해석하는 형태로 되어 있다.