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=검색어 같은 경우라서 쉽게 추출되고/일부 예외룰을 통해 이 것을 벗어나는 경우를 해석하는 형태로 되어 있다.

Published by

rein

나는 ...

5 thoughts on “wp-slimstat-ex 테스트 중”

  1. 뭔가 UCS2랑 비슷해보여서 그 쪽으로 생각을 해보는 중인데 잘 안되는 거 같음 -_-;
    좀 더 케이스가 나와줘야할 것 같은데 Orz

  2. urlencode 되는 부분은 검색엔진에서 검색 한 뒤에 해당 페이지의 주소를 보면 이미 인코딩된 주소가 표시됩니다. 따라서 리퍼러 부분에도 그렇게 전송되어지는 거죠.

    확실친 않지만 MySQL 문자셋과 관련되었을 가능성이 좀 있는데…

    우선은 실제로 검색엔진에서 검색했을 때 주소창에 나타나는 주소와, 그 페이지에서 클릭해서 방문했을 때 리퍼러로 저장되는 주소가 같은지 다른지를 확인해 보세요.

    제 경우 엠파스, 다음에서 테스트 했을때 같은 주소가 입력되었고 리퍼러 방문시에도 아무런 문제가 없습니다.

    MySQL문자셋과 관련이 있을것 같다는 생각을 해 봤는데… 이미 urlencoding 된 주소라 상관이 없겠더군요.

Leave a Reply