이전 포스팅에 썼듯이 어제 저녁에 wp-slimstat-ex에 남는 검색엔진이 리퍼러인 경우를 확인하고 있다.
(다음에서 들어온 검색어 하나가 이상하게 표현되는 문제였음)
유리엘† 아파치 웹서버의 access.log를 뒤져보니 대략 다음과 같은 로그를 찾을 수 있었다. 덤으로 오전에 내가 시도한 검색 결과도.
access.log:144920:219.248.227.217 – – [05/Sep/2007:22:50:36 +0900] “GET /wordpress/?p=217 HTTP/1.1” 200 17433 “http://tab.search.daum.net/dsa/search?nil_profile=g&nil_Search=btn&w=blog&q=\xc1\xf6\xc7\xcf\xc3\xb6\xc3\xe2\xb1\xd9\xb1\xe6” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322)”
access.log:165890:211.189.163.250 – – [06/Sep/2007:09:48:10 +0900] “GET /wordpress/?p=217 HTTP/1.1” 200 18429 “http://tab.search.daum.net/dsa/search?w=blog&collName=blog_total&q=%C1%F6%C7%CF%C3%B6%C3%E2%B1%D9%B1%E6” “Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6”
첫번째 로그가 깨져서 나오는 리퍼러 URI가 담긴 접근 기록이고 두번째가 내가 검색해서 참조해 들어왔을 때의 기록.
차이는 굉장히 단순하다: URI에 포함된 각 인자의 인코딩 방식이 다르다! 실제로 첫번째 로그의 해당 부분을 실제로 웹브라우져에서 사용해보면 제대로 된 검색 페이지가 뜬다.
URI 인코딩을 제대로 아는게 아니라서 첫번째 로그의 q= 이하 부분의 인코딩이 뭔지 알 수가 없다 -_-; 누군가 아는 사람은 설명을 좀(…)
가만히 들여다보니 % -> x로 쓰는 것 뿐이네 -_-;;
FunWebProducts 라는게 아마도 스파이웨어의 일종이거나 북마크 프로그램류 인것으로 보이는군요.
%c1이 utf-8 이나 ISO-8859-1 형식으로 저장될 때 xc1 이라고 변형되는 듯 합니다.
두번째 방문은 사용자가 직접 방문한게 아니라 스파이웨어의 원격 방문일지도 모르겠군요. 아니라면 북마크된 페이지를 열면서 자동으로 보내진 정보 일 수도 있겠구요.
어쨓든 직접 검색엔진을 통해 접속한 사용자의 리퍼러 부분 정보에는 xc1 같은 형식은 표현되지 않을겁니다.
검색해보니 http://www.networkworld.com/newsletters/web/2003/1208web2.html 이런게 나왔습니다.
FunWebProducts browser plugin이란 애가 툴바로 존재하면서(IE에 추가되고; 저것 만드는 회사의 모든 제품의 설치 라이센스에 설치가 강제되어있다함) 검색 엔진을 중계(…)해준답니다.
아마 그쪽에서 이상하게 mangling하는 것 같지만 -_-; 아파치 웹서버의 접근 기록; access.log를 보면 저런 인코딩?이 몇 개 있는걸 보면 비슷한 류의 방법을 쓰는 것들이 있는것 같습니다. 일단 더는 안 생기고 있는 것 같고 – 주로 사용되는게 유럽/북미 인 듯… – 그런 이유로 신경 끄기로 했습니다. /먼산
지금이면 당연히 아실 듯 하지만 저 x 는 html에서 16진수를 표기할 때 쓰입니다. 원래 표준은 어디인지 모르겠지만(rfc인지 아니면 w3c 내부에서인지), xOO 식으로 OO에 16진수의 스트링이 들어갑니다.
XHTML에서는 html entity를 16진수로 표기하는 것을 권장하고 있더군요. 그래서 Numeric Reference Characters를 표기할 때 &#OO; (OO는 10진수 스트링)가 아니라, &#xOO; (OO는 16진수 스트링)으로 표기해라는 것을 본 적이 있습니다.
아 저런게 있군요. 전혀 모르고있었습니다. 새로운 사실 감사합니다 :)