겐도사마의 재림

여기저기 서핑하다가 찾은 페이지 ㄱ-.

특히 제 블로그간에 트랙백 안되는 문제 해결되면 필히 알려주세요. 다시 테스트 해야 함다. ㄱ-

http://gendoh.tistory.com/2510834
http://gendoh.tistory.com/2510833

from 겐도사마의 재림
쓸만한 개발자는 다 데리고 있다라고 자신하는 회사이니 크리스마스 전에 고쳐지리라 예상을!

과거 URL에 ASCII가 아닌 문자가 들어왔을때 브라우저마다 서버마다 꼬여서 나온 것이 mod_url 모듈입니다. url을 검사해서 서버의 케릭터 셋과 맞지 않는다 싶으면 문자를 변환한 후 클라이언트에게 location 헤더로 알려줍니다. 그래서 적당한 곳으로 옮겨주죠. 비슷하게 태터툴즈의 경우 어떤 케릭터 셋으로 날라와도 가능한한 잘 처리하도록 코딩되어 있습니다. 물론 100% 동작은 하지 않지만 꽤 무난한 정도죠.

땜빵은 땜빵을 만들고 그것이 지속되다 결국 댐을 무너트리니, IE7이란 둑에 문제가 생긴 것 같습니다. UTF-8로 전송된 URL에 대해 mod_url이 euc-kr로 변환해서 접속해라고 알려주고 IE6는 이를 그대로 재전송하므로 문제가 없었는데 IE7은 다른 특성을 보입니다. UTF-8 옵션이 있는 경우 location 정보로 euc-kr이 온것을 인식하고는 이를 utf-8로 변환, 전송합니다. mod_url과 IE7과의 무한 전쟁이 시작됩니다. IE7은 끊임없이 UTF-8로 전송을 시도하고 mod_url은 끊임없이 euc-kr 주소로 접속하라고 반송합니다.

서버관리자분들 중 IE7 이후 트래픽이 급증했다고 생각이 든다면 mod_url의 제거를 검토해 보시기 바랍니다. 정상적인 방법이 아니다 보니 IE7에서 문제가 생겨버린 것 같습니다.

이 문제를 해결하는 가장 좋은 방법은 url은 ascii만으로 이루어 지게 하는 것입니다. 비록 그것이 외계어처럼 보여도 '%'가 난리를 치고 링크 길이가 상당히 길어지긴 하지만 url-encoding을 하는 것이 가장 정석입니다.

개인적으로 퍼머링크 같은 것은 시스템만 잘 알아보면 되지 이쁠 필요가 없다라고 생각하여 태터에 대해서도 모든 링크를 수정하려고 하였지만 어떤 사람들은 "이쁜 링크주소"가 필요하다는 군요. 이 상황에서 아마 가장 좋은 방법은 IANA를 뒤집어 엎어서 URL과 HTTP의 헤더 부분에 utf-8을 허용토록 하고는 모든 관련 업체들 보고 그렇게 구현하라고 하는 것입니다. 이러는 경우 어떤 문제가 생기냐면 HTTP를 쓰는 모든 프로그램과 장비들은 기존에 ascii만 써서 쉽게 구현되던 부분이 utf-8 모듈까지 올려야 하는 부담이 생깁니다. 아마 왠만큼 흔들어서는 꿈쩍도 안하겠죠. 따라서 현재 취할 수 있는 방법은 아마 잘 구현일 것입니다.

태터의 방식의 한계는, 아니 utf-8을 쓰지 않는 모든 상황에서 동일합니다만 UTF-8이 아닌경우 단 한가지 언어권의 데이터로만 받을 수 있습니다. euc-kr과 euc-jp를 동시에 처리하는 것은 거의 불가능해 집니다.

아니면 그언젠가 홍보했던 IE 옵션 변경.

후배의 블로그에서 보낸 트랙백이 본인의 사이트에서 외계어로 번역된 케이스가 있다.

제목부분만 살포시 때다가 보자.

나의 개발환경

저 코드를 그대로 브라우저보고 번역해봐! 하면

나의 개발환경

으로 나온다. 대체 뭐가 문제일까.

그 후배녀석이 사용하는 블로그시스템은 ExpressionEngine. 내부적으로 UTF-8을 지원한다라고 되어있는것 같지만 한글을 입력하고 내부적 처리를 보면 전혀 아니다. 한글을 전부 저런식으로 바꾸어 버린다. 그리고 트랙백을 보낼때도 저런식으로 보내는 것이다.

EE에서 보낸 트랙백은 WordPress나 기타 많은 블로그 시스템에서는 잘 보일수도 있다. 왜냐면 액면 그대로 출력을 하고 브라우저가 번역을 하기 때문이다. 반대로 태터는 트랙백 데이터를 원본 그대로 표시하고자 HTML Escaping을 해 주기 때문에 외계어로 보이는 것이다.

누가 틀린것인가?

Trackback에 대한 스펙에서 텍스트의 Representation에 대한 정의는 되어 있지 않다. 뭐 맞고 틀리고 할 기준 자체가 없기는 하다. 허나 스펙에서 charset을 명시하도록 되어 있고 따라서 utf-8로 보낼때 한국어를 저런 외계어로 번역할 필요가 없는 것은 자명하다. 보낼때 번역할 필요가 없다는 것은 받을때도 마찬가지이다. 그대로를 표시해 주면 되는 것이다.

태터도 WP처럼 저런 인코딩을 지원해 주면 되지 않냐에 대해선 저렇게 했다간 반대로 현재 이글을 트랙백 보냈다간 중간의 "나" 라는 부분에서 문제가 생긴다. 따라서 어설프게 다른 블로그 시스템의 문제점을 케어해 주긴 어려울 것으로 보인다.

결론.
무늬만 UTF-8 지원하는 놈들 쓰면서 한글 사용은 자제하길. 한글을 포기하거나 시스템을 바꿔야 한다.

PS.
한국어(혹은 non-english)를 사용한다라는 점이 Unicode 프로그래밍을 하는 상황에선 장점으로 작용되기도 한다. 많은 외국에서 제작된 프로그램들이 Unicode 환경에서 정상 동작을 하지 않기도 한다(Google Earth 대표적).
우리의 것(프로그램)이 좋은 이유가 이런 것인지도.
뭐 태터도 아랍권 가면(글의 방향이 우->좌) 머리아픈 상황이 되겠지만 :)

PS2.
일부사이트는 UTF-8 트랙백을 못받는 놈들도 있다. 포탈 블로그중에도 상당수 있다. 그래서 태터 내부엔 몇몇 사이트를 센싱해서 euc-kr로 기꺼이 지원해 주는 케이스도 있는 것이다.

이번 TatterTools 1.02와 더불어 등장한 Migrator.php를 뜯어보자. 우선 주의할 것은 케릭터셋 변환을 위한 데이터가 들어 있어서 어정쩡한 에디터로 읽었다간 파일이 망가질 수 있다. 가능하면 UTF-8로 읽어 내기를 권장한다.

주의! 여기의 내용은 상당히 위험한 방법일 수 있기 때문에 어느정도 프로그래밍이 가능하고 특별한 처리를 하기 위한 상황에서만 실제 적용을 하기 바랍니다. 초보자를 위한 FAQ같은 것은 아닙니다. 또한.. 언제나 잊지 말것은 Backup!

UTF 판별하기 함수
이전에 UTF8의 판별에 대해 적은 글이 있는데 그 방법의 결정판이 이 파일의 250번째줄 근처에 있는 isUTF8과 adjustUTF8 함수일 것이다. 허나 이 함수에서 주의할 점이 하나 있다. 나름대로 제너럴 하게, 그리고 무난하게 판단하고 변환을 시켜주고 있지만 자신의 데이터가 특별한 경우 가차없이 '?'로 변신 시키는 함수기도 하다. 특수한 언어 체계(?)를 사용중이라던가 컨텐트 중에 특수한 케릭터 변환이 필요하다면 이 함수를 약간 손봐줘야 할 것이다. 0.96 즉 euc-kr에서 변환하는 경우에 xml에서 import 도중 에러가 날때도 역시 여기를 고민해 봐야 할 수 도 있다.

특정 영역의 변환 문제
1.02로의 변환중 특정 영역에 euc-kr로 남아 있어서 문제라거나 utf-8로 변환되어 버려 문제가 생기는 경우, 그리고 특정 문자의 치환이 필요하다면 300라인쯤 부터 펼쳐지는 "각부분처리기"에서 수정할 수 있다.
우선 변환과 관련된 것은 iconver, 그리고 치환자는 str_replace를 사용하고 있다. 특정 글의 특정 부분에 이런것을 적용하거나 해제하고 싶다면 바로 이부분에서 수정할 수 있다. 특히 420번째즘 나오는 $post->content 영역의 경우 글에 들어 있는 스크립트를 1.02에서 사용하기 위해 태터 플러그인족에 공개된 PureCode를 사용하도록 수정할 수 있게 자동 변환할때 사용해야할 키워드일 것이다. "<script>"의 "<"를 "&lt;"로 변환하고 앞뒤로 PURE를 붙여주는 작업등을 할 수 있다. 본인의 경우 글이 100개밖에 안되서 대충 보고 문제되는 놈들은 0.96을 옆에 뛰우고는 에디터로 Copy&Paste를 하는 식으로 작업했지만 도저히 수작업으로 불가능 하다면 이 방법을 생각해 볼 수 있다.

마이그레이션 이후
0.96에서 바로 1.02로 점프한 나로서는 일종의 "플랫폼 변환"을 당하고 말았다. 체계도 달라지고 에디터도 다르고 글을 쓸때 정보도 다르다. "Borland C++ for Windows"를 쓰다가 "Visual Studio 98"로 넘어갈때의 느낌이랄까? 좋아진점도 있지만 나빠진 것도 많고 그보다 중요한 것은 새로운 것을 배워야 하고 적응해야 한다. 그리고 이런 이동에서 격어야 하는 어려움들... Tatter&Company의 개발자도 죽어라 디버깅 했겠지만 나도 이 이동을 위해 한달 전 부터 나름대로 준비를 해 왔다. 그래도 여전히 이동 당일날 약간의 트러블은 생기게 되고 아직도 FF에서는 배경의 격자가 보이지 않고 등등..

그러나, 아픈만큼 성숙해 지는 법이다.