26 번째 수정본 소스 보기 : 티스토리의받은트랙백링크출력문제
마지막으로 [b]
-- Loading page list... --
내용출력
로그인[l]
Diary
[f]
최근변경내역
[r]
페이지목록[i]
횡설수설[2]
게시판[3]
링크
수정할 수 없습니다: 티스토리의받은트랙백링크출력문제 는 읽기 전용 페이지입니다.
<toc> == # 개요 == 이 얘기가 나오게 된 사연은 [[Diary/티스토리의받은트랙백링크출력문제]]에 적었듯이, 티스토리에 트랙백을 보냈는데, 그 트랙백을 클릭했더니 원래의 페이지로 제대로 돌아오지 못하더라는 겁니다. 일단 결론부터 얘기하면, 이번에도 IE가 뭔가 문제가 있는 듯 하다는 겁니다. 근데 공교롭게 티스토리에서 출력하는 링크가 IE와 만나니까 받은 트랙백 링크를 클릭했을 때 제대로 연결되지 않는 문제가 생깁니다. == # 티스토리에서 받은 트랙백 링크 출력 방식 == 티스토리는 자신이 받은 트랙백URL을 출력할 때 다음과 같이 하더군요. (다른 부분은 잘라내고 트랙백 제목 링크 부분만 옮겼습니다) {{{ <a href="트랙백URL" onclick="window.open(this.href); return false" rel="external nofollow"> 받은 트랙백의 title </a> }}} 즉 링크를 클릭하면, onClick 이벤트가 발생해서 자바스크립트가 "window.open()"을 실행하고, 이 때 open()에 인자로 들어가는 주소는 "this.href", 즉 이 a 태그의 href 속성의 값을 쓴다...는 얘기 같습니다. (제가 html이나 javascript에 대해 별로 알지 못해서, 그런 것 같다..라는 식으로밖에 말을 못 하겠습니다만) 근데 하필 <color(red,"트랙백URL"이, "UTF-8 인코딩에 해당하는 시퀀스로 %-인코딩되어 있는 문자열"을 포함하고 있는 경우)>에, 그 링크를 클릭하면 희한한 주소로 요청이 날아갑니다. == # 실제로 트랙백을 보내 보면... == 예를 들어보죠. 제가 위키 소스 고칠 때 사용하는 테스트용 위키에 "트랙백테스트"라는 페이지가 있습니다. 이 페이지의 URL은 {{{ http://gypark.pe.kr/cgi-bin/utf/wiki.pl/트랙백테스트 }}} 입니다. [http://gypark.pe.kr/cgi-bin/utf/wiki.pl/트랙백테스트 클릭]해 보시면 잘 됩니다. 근데 URL에 한글이 들어가 있다보니, 제 위키 내부에서 서로 링크를 걸 때야 알아서 처리해 주지만, 이 주소를 가지고 다른 곳에 트랙백을 보낸다거나 RSS에 이 URL 엔트리를 포함해서 출력하거나 하면, 상대방 블로그나 RSS 리더가 제대로 처리를 못해서 문제를 일으키는 경우가 많습니다. 그래서 트랙백을 보내는 경우에, 제 위키는 저 페이지의 URL을 %-인코딩해서 처리합니다. "트랙백테스트"(한글 6글자)가 EUC-KR로 처리되는 경우라면 %-인코딩의 결과는 "%C6%AE%B7%A2%B9%E9%C5%D7%BD%BA%C6%AE"이고, UTF-8로 처리되는 경우라면 "%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8"가 됩니다. 따라서 "트랙백테스트" 페이지의 트랙백을 어딘가 보낼 때, url 필드의 값은 {{{ http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8 }}} 가 됩니다. (UTF-8 위키니까) 이렇게 %-인코딩된 상태의 주소도 [http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8 클릭]해 보면 잘 됩니다. 이제, 이 트랙백을 티스토리가 받아서 출력할 때는 {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> }}} 와 같이 출력할 텐데... 저렇게 출력된 링크를 클릭하면 말이죠... ---- <html> <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> </html> - IE6에서 마우스 좌클릭해 보세요. ---- 결과는... || Upload:20070308_01.png || =.=?? 이게 어찌된 영문일까요? 제 위키가 있는 서버쪽에서 아파치 웹서버의 access_log를 보니, 저 링크를 클릭했을 때의 로그가 다음과 같더군요. {{{ /cgi-bin/utf/wiki.pl/%C3%AD%C2%8A%C2%B8%C3%AB%C2%9E%C2%99%C3%AB%C2%B0%C2%B1 %C3%AD%C2%85%C2%8C%C3%AC%C2%8A%C2%A4%C3%AD%C2%8A%C2%B8 HTTP/1.1 (한 줄로 되어 있는데 길어서 제가 줄바꿈 한 겁니다) }}} 도대체 "%C3%AD%C2%8A%C2%B8%C3%AB%C2%9E%C2%99%C3%AB%C2%B0%C2%B1%C3%AD%C2%85%C2%8C%C3%AC%C2%8A%C2%A4%C3%AD%C2%8A%C2%B8"라는 해괴망칙한 시퀀스는 어디서 나타난 건지 짐작도 못하겠습니다. 첨에는 UTF-8을 EUC-KR이라고 잘못 판단하고 그걸 다시 UTF-8로 바꾼 건가 했는데 그건 아닌 것 같습니다. 더 재밌는 것은, 저 링크를 왼쪽 버튼으로 클릭하지 말고, * 우클릭해서 메뉴가 뜨면 "새 창으로 열기"를 선택하던가, * 우클릭해서 "바로 가기 복사"를 한 후 주소창에 붙여넣기 하면 아무 문제 없이 잘 보인다는 겁니다. URL도 링크에 있는 그대로 나오고요. == # 다른 형태의 URL을 보내 본 결과 == 위의 결과와, 아래 세 가지 테스트 결과 모두 제가 티스토리에 만들어 두고 테스트용으로 쓰는 블로그에서 확인할 수 있습니다. http://raymundo.tistory.com/5 === # %-인코딩하지 않고 그냥 보냄 === 제 위키를 수정해서, URL을 %-인코딩하지 않고 바로 보내도록 했습니다. 결과적으로 티스토리의 출력은 {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/트랙백테스트" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> }}} 가 되고, <html> <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/트랙백테스트" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> </html> - 클릭해 보면 잘 됩니다. === # EUC-KR 시퀀스로 %-인코딩한 경우 === 예전에 수정해서 쓰던 EUC-KR 시절의 구버전 위키를 가지고 테스트해 보았습니다. [http://gypark.pe.kr/cgi-bin/testwiki/wiki.pl?트랙백테스트 EUC-KR 위키의 트랙백테스트 페이지]를 가지고 티스토리로 트랙백을 보내봤습니다. EUC-KR 셋에서 "트랙백테스트"를 %-인코딩한 결과는 "%C6%AE%B7%A2%B9%E9%C5%D7%BD%BA%C6%AE"이고, 결과적으로 티스토리의 출력은 {{{ <a href= "http://gypark.pe.kr/cgi-bin/testwiki/wiki.pl?%C6%AE%B7%A2%B9%E9%C5%D7%BD%BA%C6%AE" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트</a> }}} <html> <a href= "http://gypark.pe.kr/cgi-bin/testwiki/wiki.pl?%C6%AE%B7%A2%B9%E9%C5%D7%BD%BA%C6%AE" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트</a> </html> - 역시 잘 됩니다. === # EUC-KR 시퀀스, %-인코딩하지 않고 그냥 보낸 경우 === %-인코딩을 하지 않았기 때문에, 결과적으로 티스토리 링크는 {{{ <a href= "http://gypark.pe.kr/cgi-bin/testwiki/wiki.pl?트랙백테스트" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트</a> }}} 그런데 저 "트랙백테스트"는 '''어차피 UTF-8로 취급됩니다''' 왜냐하면 티스토리 블로그가 UTF-8로 출력되고 있고, IE나 FF 둘 다 "UTF-8 인코딩된 웹페이지 안에 있는 링크는 UTF-8"로 간주해서 처리하기 때문이죠. 그러면 위에 "%-인코딩하지 않고 그냥 보냄" 섹션에서와 똑같이 잘 보여야 하는데... <html> <a href= "http://gypark.pe.kr/cgi-bin/testwiki/wiki.pl?트랙백테스트" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트</a> </html> - IE에서는 깨집니다. "잘못된 페이지"라고 나올 겁니다. 이 때 깨지는 이유는, URL의 "?"뒤에 오는 쿼리스트링을 UTF-8로 변환할 경우 제대로 변환하지 못하는 IE의 버그 때문입니다. (이와 관련해서 지겹게 테스트했던 얘기는 [[유니코드논의/파일명인코딩]]에서 볼 수 있고, 이 버그에 관한 건 알록블록의 [http://alogblog.com/alog/archives/2006/02/06_ms_ie_6_and_7_beta_2_encoding_bugs_in_urls_query_part/ alogblog: MS IE 6 and 7 beta 2 encoding bugs in URLs query part] 등에서 볼 수 있습니다) == # 다른 브라우저에서는? == 제가 설치한게 IE6하고 FF2.0뿐이라서 더는확인 못 했습니다. :-) <color(red,FireFox에서는, 위 네 가지 다 잘 보입니다.)> 총 4가지 링크 중에 첫번째와 세번째 것은 이미 %-인코딩되어 있는 URL이니 그대로 요청을 보내고, 두번째와 네번째는 링크의 "트랙백테스트"라는 한글을 자기가 %-인코딩해서 요청을 보내기 때문에, 아무 문제 없이 연결이 되고 있습니다. == # 어느 시점에서 문제가 되나 == 다시 문제의 첫번째 링크로 돌아와서, {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8" onclick="window.open(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> }}} 위 링크를 클릭했을 때, 어느 시점에서 "/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8"가 "%C3%AD%C2%8A%C2%B8%C3%AB%C2%9E%C2%99%C3%AB%C2%B0%C2%B1%C3%AD%C2%85%C2%8C%C3%AC%C2%8A%C2%A4%C3%AD%C2%8A%C2%B8"라는 괴물로 변신을 하는 걸까요? 둘 중 하나이겠죠. * "windows.open()"이 창을 열고 주소를 채워넣는 과정에서 변신을 시키거나 * open()에 들어온 this.href 값 자체가 이미 변신이 되어 있었거나 제가 자바스크립트를 잘 알거나 하는 게 아니라서 제대로 체크할 수는 없었지만, 일단 혐의는 this.href에게 갔습니다. windows.open 대신에 alert을 사용해서 onClick 이벤트 시에 "alert(this.href)"를 실행하게 해보면, <html> <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8" onclick="alert(this.href); return false" rel="external nofollow"> 트랙백테스트 </a> </html> - 이 링크를 클릭해보면 경고 다이얼로그가 뜨는데 여기 나오는 메세지도 이미 깨져 있는 상태고, 깨져 있는 형태가 위의 링크를 클릭했을 때와 같거든요. 아니면, this.href는 아무 죄가 없는데, alert과 open이 둘 다 변신을 시키는 걸 수도 있겠군요. 어쨌거나, 똑같은 자바스크립트 코드를 수행하는데 FF와 IE의 동작이 다르고, 그래서 멀쩡한 트랙백을 멀쩡하게(?) 클릭하는데 그게 제대로 보여지지 않는다는 게 참 당혹스럽네요. === # 추가3 - this.href가 범인인 듯 === 위의 실험만 가지고는, this.href가 범인인지, 아니면 alert()과 window.open() 둘이 범인인지 확실치 않아서, 다음과 같이 %-인코딩된 문자열을 원래의 href값에서 떼어내어서 open()의 인자로 직접 넣어 보았습니다. {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/" <-- 이쪽에 있던 %-인코딩된 부분을 떼어서 onclick="window.open(this.href+'%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8'); <-- 이쪽으로 return false" rel="external nofollow"> 트랙백테스트 </a> }}} <html> <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/" onclick="window.open(this.href+'%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8'); return false" rel="external nofollow"> 트랙백테스트 </a> - 성공함 </html> 제대로 되네요! "트랙백테스트"에서 "트"자만 href값에 포함해 볼까요? {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8" onclick="window.open(this.href+'%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8'); return false" rel="external nofollow"> 트랙백테스트 </a> }}} <html> <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8" onclick="window.open(this.href+'%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8'); return false" rel="external nofollow"> 트랙백테스트 </a> - 첫 글자만 깨짐 </html> "트"만 깨지고 "랙백테스트"는 잘 나오는군요. <mysign([[Raymundo]],2007-3-10 1:34 am)> == # 굳이 저렇게 링크를 걸지 않아도...? == 이글루스에도 트랙백을 보내 봤습니다. http://raymundo.egloos.com/3006594 이글루스에서는 받은 트랙백 링크를 평범(?)하게 {{{ <a href= "http://gypark.pe.kr/cgi-bin/utf/wiki.pl/%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8" target="_new"> 트랙백테스트</a> }}} target="_new" 속성을 지정해서 클릭하면 새 창으로 뜨게 되어 있고, 이건 IE에서도 잘 됩니다. (이 것마저 잘 안 되면 IE는 진작에 폐기처분됐겠죠 -_-;) 티스토리에서 사용한 자바스크립트도 제가 보기에는 그냥 "새 창 열고 거기에 띄우기"인 것 같은데, (다른 의미가 더 있다면 가르쳐 주시면 감사하겠습니다) 왜 굳이 이글루스처럼 하지 않았는지 모르겠습니다. FF에서는 잘 되고 있으니 결국 IE의 문제라고 생각하면 그만일 수도 있지만, 이왕이면 양쪽 브라우저에서 잘 되는 고전적인 방식을 써도 안 될 것 없지 않나...라는 생각입니다. === # 추가1 - 링크를 저런 식으로 한 이유가 있었군요. === 구글링하다 본 [http://plyfly.net/76 상상공장 : 스킨공작소 :: 이래도 새창이 필요하드냐...]에서, leezche란 분도 왜 저런 식으로 링크를 만드는지 의아해했다가 아래와 같은 답을 들었다는군요. <blockquote> 그라피티에님 曰 : 에~~ 그거는 말이죠! 시각장애인을 위한 겁니다. 어떤 링크를 클릭했을때 새창으로 뜨게 된다면 시각장애인은 자신이 기억하고 있는 포커스(위치)를 잃어 버리게 됩니다. 아주 당황스러운 일인거죠. 이렇게 하는 것은 그들을 위한 작은 배려가 아니라 기득권의 횡포를 이제 막아 주는 거죠. onclick은 어떻게 해서든 새창을 띄우고 싶은 사람들의 꼼수인거죠. 어떤 링크를 정말 필요해서 새창으로 열고 싶다면, 오른쪽 버튼 클릭하면 "새창에서 열기"라고 있는데 그걸 이용하면 됩니다 </blockquote> 요컨데, 일반 브라우저로 그냥 클릭하면 자바스크립트를 사용해서 새 창을 띄우고, 시각 장애인용 시스템에서는 - 자바스크립트를 처리를 하지 않음으로써 - 현재 창에 띄우게 할 수 있다...라는 것 같군요. 그래서 위에 있는 문제의 그 링크도, 우클릭해서 "새 창으로 열기", "바로가기 복사", 심지어 그냥 "열기"를 선택했을 때 다 잘 되는 거군요. 그 때는 자바스크립트가 관여하지 않으니까. 그렇지만... 그럼 일반 브라우저로 "현재 창에" 링크를 띄우고 싶은 사람은??? 매번 우클릭해서 "열기"를 해야겠군요. 누군가는 좌클릭했을때 만큼은 현재 창에 뜨기를 바라는 사람도 있을 테고, 또 다른 누군가는 좌클릭만 해도 알아서 새 창으로 뜨기를 바라는 사람도 있을테니, 링크 하나로 양쪽을 다 만족시킬 수 없다면 차라리 현재 창으로 뜨는 링크와 새 창으로 뜨는 링크 두 개를 연달아 배치하는 건 어떨까 하는 생각도 듭니다. 저 블로그 링크처럼 ^^ (링크 우측에 있는 작은 아이콘을 클릭하면 새 창으로 뜹니다) == # 추가2 - 본문 내의 링크와 댓글의 링크 == 오늘 갑자기 든 생각... "왜 이 문제를 이제서야 발견했을까?" 제가 제 홈페이지를 블로그로 운영하는 건 아니지만 남의 블로그 가서 댓글도 달고 트랙백도 걸고 했었는데 말이죠. 그리고 인코딩이나 트랙백 등등 관련해서 테스트하느라고 테스트용 블로그도 태터, 티스토리, 이글루스(거기에 거의 안 쓰지만 네이버, 다음 등등)에 다 가지고 있는데... 근데 그럴 수 밖에 없었던게, 본문이나 댓글에 제 위키의 링크를 남길 때는 URL에 한글이 그대로 들어간 채로 남겼었거든요. 이 경우 그 한글URL은 블로그의 인코딩에 따라서 EUC-KR과 UTF-8 중 하나로 인코딩되어 있을테고, 어느 쪽이건 제 위키에서 받아서 처리할 수 있기 때문에 링크는 아주 잘 동작해죠. 아까 다시 확인해 보니 티스토리의 코멘트 창에 URL을 남기면 자동으로 링크가 걸리는데 그 링크도 자바스크립트를 쓰고 있기 때문에 %-인코딩된 URL을 적은 경우는 문제가 됩니다. 제 위키야 한글이 있는 URL을 그대로 복사해서 댓글에 적으면 상관이 없지만, 위키페디아의 주소(예를 들어 http://ko.wikipedia.org/wiki/%EC%9C%84%ED%82%A4%EB%B0%B1%EA%B3%BC) 같은 걸 적으면 그것들도 문제가 되겠죠. 본문에 링크를 남기는 경우는 또 다르더군요. URL을 바로 적으면 자바스크립트 없이 그냥 <nowiki><a href="주소">주소</a></nowiki>로 링크를 걸고 있기 때문에 클릭하면 현재 창에 잘 뜹니다. 상단의 도구모음을 이용해서 링크를 만들 경우, 현재 창과 새 창 중 어느 쪽으로 띄우게 할 건지 선택할 수가 있는데, "새 창으로"를 선택하면 링크가 target="_blank"속성으로 생기네요 =.=; 그래서 본문에서 건 링크는 어찌 되었건 잘 됩니다. 본문과 댓글에 링크를 남긴 예제도 제 테스트용 [http://raymundo.tistory.com/5 티스토리 블로그]에 같이 남겨 두었습니다. == # 추가3 - 아주 간단한 해결책이 있다 == 이것저것 확인하던 중에 발견했던 건데 여기 적는 걸 잊고 있었다. 문제는 IE에서 this.href이므로, 이것만 안 쓰면 된다. {{{ <a href="http://...." onclick=window.open(this.href)> }}} 대신에 {{{ <a href="http://...." onclick=window.open("http://....")> }}} 이렇게 주소를 다시 한 번 적어주면 된다. 이 얘기를 [http://forum.tattersite.com/ko/viewtopic.php?id=2973 TNF]에 적었었는데 안 읽는지 그 이후 반응이 없더라. == # 결론 == 1) 아 정말 IE6 못 써먹겠다 -_-; * 2월에 위키를 유니코드로 옮기면서부터 FF는 괜찮은데 IE만 안 되어서 별도로 처리하게 해야 했던 게 몇 개였는지 이젠 셀 수도 없음. * 게다가 위에서 링크했던 [http://alogblog.com/alog/archives/2006/02/06_ms_ie_6_and_7_beta_2_encoding_bugs_in_urls_query_part/ alogblog의 포스트]에 따르면 IE7은 한 술 더 떠서 쿼리가 아니라 path에 들어 있는 한글을 UTF-8로 변환할 때도 문제를 일으키는 모양... * 나 혼자야 FF쓰면 그만이라치고 URL에 한글이 잔뜩 들어간 내 위키의 운명은... =.=; 2) IE가 고쳐지길 기대할 수는 없으니... 티스토리나 태터툴즈에서에서 받은 트랙백이나 댓글의 링크를 출력할 때 window.open()안에 this.href 대신에 URL 자체를 인자로 적어주면 된다. 3) 근데 티스토리 측에 이걸 물어보려면 어디가서 하는게 제일 좋을까요? == # 관련 링크 == * [[유니코드논의]] * [[유니코드논의/파일명인코딩]] * [[UTF-8이전작업]] * [http://jspwiki.org/wiki/BugFailToAttachAFileToAPageWithMultibytePageName JSPWiki: Bug Fail To Attach A File To A Page With Multibyte Page Name] - 구글에서 "internet explorer window.open url encoded utf-8"를 검색했다가 나온 글 ** 여기서 window.open()을 언급하고 있길래 앗싸 싶었는데, 여기서 제안한 escape()와 encodeURI() 어느 걸 써서 this.href를 변환해봐도 무소용이었음. ** 저 글에서 언급한 [http://xkr.us/articles/javascript/encode-compare/ xkr.us / javascript / escape(), encodeURI(), encodeURIComponent()]도 봐 둘 만 한 듯. == # 의견란 == <div class="comments"> 저 텍스트는 EUC-KR로 들어 온 문자열을 UTF-8로 인코딩한 다음에 그걸 (ISO-8859-1로 해석해서) 다시 UTF-8로 인코딩하면 나오는 결과물입니다. <mysign(lifthrasiir,2007-3-8 10:26 pm)> 허업, 테스트해 보니 정말이군요. 도대체 어떻게 저걸 보고 그걸 아실 수가 @.@; \\ \\ 그러면... \\ "%ED%8A%B8%EB%9E%99%EB%B0%B1%ED%85%8C%EC%8A%A4%ED%8A%B8"을 새 창으로 띄우랬더니만, 이게 디코딩되어 UTF-8 문자열 "트랙백테스트"가 되고, 엄연한 UTF-8문자열을 ISO-8859-1취급해서 다시 UTF-8로 변환하고, 그 결과를 %-인코딩해서 "%C3%AD%C2%8A%C2%B8%C3%AB%C2%9E%C2%99%C3%AB%C2%B0%C2%B1%C3%AD%C2%85%C2%8C%C3%AC%C2%8A%C2%A4%C3%AD%C2%8A%C2%B8"가 되었다는 얘기... -_-? 아니면 중간에 디코딩과 인코딩은 생략되고 %HH.. 상태에서 바로 변환이 되었을 수도 있긴 하겠군요. (%HH형태는 겉으로는 평범한 아스키일 뿐이니 곧바로 변환하진 못할 것 같지만 뭐 IE 속이 어떻게 생겨먹었는지 모르니..) <mysign([[Raymundo]],2007-3-8 10:39 pm)> [http://report.tistory.com/6#comment1629861 티스토리 리포트 블로그 :: 티스토리 버그 리포트]에 댓글로 문의 남겨 둔 상태. <mysign([[Raymundo]],2007-3-8 11:19 pm)> : 댓글에 이 페이지의 링크를 적으면서, "이것도 깨지면 어떡학지?"라고 생각했는데, 댓글에서는 페이지이름이 "티스토리의..."라고 그냥 한글인 상태니까 괜찮음. \\ \\ 그렇다고 티스토리를 위해서 트랙백 보낼때 %-인코딩을 하지 않게 했다가는 EUC-KR로 된 페이지에 보낼 때 난리가 날테고... 이러지도 저러지도 못하겠음. <mysign([[Raymundo]],2007-3-9 1:40 pm)> [http://forum.tattersite.com/ko/index.php TNF : Tatter Network Foundation forum]에서 "window.open"으로 검색한 결과에 있는 글들을 보니, target 이라는 속성이 표준에서 빠지는 분위기인 듯? 여기 포럼에 질문을 남길 수 있으려나 했는데 개발자들만 회원으로 가입해서 사용하는 공간인 듯 싶다. 가입하기도 그렇고... <mysign([[Raymundo]],2007-3-9 1:55 pm)> : 위의 검색 결과 링크에 결과물이 안나오는군요. \\ 어쨌든. target은 XHTML에서 이미 빠져있습니다. XHTML 2.0이 나오면 다시 부활할 가능성이 있기는 합니다만... <mysign([[조프]],2007-3-9 3:00 pm)> : 검색결과는 일시적인 캐시였나보군요. 삭제했습니다. 근데 target을 뺀 건 이유가 뭐였을지 궁금하네요. <mysign([[Raymundo]],2007-3-9 8:15 pm)> 여전히 티스토리의 그 문제는 여전하고, 이후에 더 받은 답변도 없어서 다시 [http://report.tistory.com/9#comment1049171 문의]함. <mysign([[Raymundo]],2007-6-24 11:38 pm)> 애초에 이 문제 자체가... \\ * 받은 트랙백의 URL 또는 댓글 안에 있는 URL \\ * 이 URL이 하필이면 %-인코딩된 형태이고 \\ * 그 %-인코딩되어 표현된 값이 하필이면 UTF-8 시퀀스이며 \\ * 하필 그걸 IE에서 클릭했을 때 \\ 발생하는 문제이다보니, 결코 "흔히 발생하는" 문제가 아니라는 건 나도 안다. 그래서 사실 기대도 하지 않았다만... \\ \\ 티스토리는 "확인 후 연락주겠다"고 한 후 감감무소식이고, 나는 여전히 마눌 홈페이지에 트랙백을 보낼 수 없다. 보내봤자 깨지는데 뭘. \\ \\ 태터에는 문의하니 "티스토리 쪽은 자기네가 어쩔 수 없으니 그쪽으로 문의하라"길래, 태터는 안 그런가 싶어서 다시 태터 깔고 확인해서 "태터도 그렇다"고 했더니 그 후로는 읽었는지 말았는지 답글이 없길래, 더 얘기하기도 구차해서 말았다. \\ \\ 암튼 저 두 가지에 완전히 정나미 떨어지게 되었음. ''블로그, 관리자 화면에서 XHTML 1.1 을 준수하며, 여러 웹 브라우저 환경에서 무리 없이 쓸 수 있도록 제작되고 있습니다''[http://www.tattertools.com/ko/about02.php] <mysign([[Raymundo]],2007-6-24 11:56 pm)> 티스토리 포럼에 다시 [http://www.tistory.com/forum/viewtopic.php?id=3285 문의]함. 내가 내 아내의 블로그에 트랙백 보낼 때마다 그 링크가 깨지는 걸 보고 있자니 정말 분통이 터져서... <mysign([[Raymundo]],2008-11-25 9:00 pm)> IE7 켜고 본문의 링크들을 하나씩 눌러보니 다 잘 나옵니다. 그리고 스팸 트랙백 축하드립니다. (… ;) <mysign([[LeSo]],2009-2-20 9:55 am)> <longcomments(100)> ---- <trackbackreceived> </div> ---- [[컴퓨터분류]]
티스토리의받은트랙백링크출력문제
페이지로 돌아가기 |
다른 수정본 보기
![[첫화면으로]](/raymundo_logo.jpg){kind=logo}
26 번째 수정본 소스 보기 : 티스토리의받은트랙백링크출력문제26 번째 수정본 소스 보기 : 티스토리의받은트랙백링크출력문제