위키페디아 같은 경우는 페이지 이름으로 반드시 UTF-8이 와야 하는데, 이곳에서 "KoWikipedia:위키위키"와 같이 적으면 (IE의 "URL을 항상 UTF-8로 보냄"옵션이 꺼진 경우) 페이지를 찾지 못한다고 나오고, 그렇다고 "KoWikipedia:%EC%9C%84%ED%82%A4%EC%9C%84%ED%82%A4"처럼 적자니 매우 기분이 나빠서 (^^;) 만들었음
아이콘은 wikipedia-16.png, 인코딩은 utf-8 KoWikipedia http://ko.wikipedia.org/wiki/|wikipedia-16.png|utf-8 만일 아이콘은 따로 없고 인코딩만 지정해준다면 아이콘을 지정하기 위한 "|"는 적어주어야 한다. (기존 소스와 호환성을 유지하면서 수정을 최소로 하려다보니...) KoWikipedia http://ko.wikipedia.org/wiki/||utf-8 # "|"가 두 개
예:
* KoWikipedia:위키위키 * GyparkWIki:위키위키 - 그런 지정이 없는 경우와 비교
정확히 얘기하면, intermap에 적힌 인코딩과 자기 홈의 $HttpCharset 변수의 값이 다를 경우에, 페이지 이름 부분만 HttpCharset의 값에서 intermap에 적힌 값으로 컨버트를 시키고, 그걸 %-인코딩한 후, intermap에 적힌 사이트 주소에 합쳐서 링크를 만든다. intermap에 인코딩 명시가 되어 있지 않다거나, 적힌 인코딩과 자기의 캐릭터셋이 같은 경우는 %-인코딩만 한다.
따라서, 페이지 이름 부분이 아니라 사이트 주소 자체에 멀티바이트 문자가 있는 경우는 적용 안 될 것임.
sub InterPageLink { ... ($site, $remotePage) = split(/:/, $id, 2); $url = &GetSiteUrl($site); ############### ### added by gypark ### interwiki 아이콘 # 이 단락 안의 내용을 다시 아래와 같이 고친다 my ($image, $url_main, $encoding); ($url, $image, $encoding) = split(/\|/, $url); $url_main = $url; ### ############### return ("", $id . $punct) if ($url eq ""); $remotePage =~ s/&/&/g; # Unquote common URL HTML # 아래 줄을 주석 처리하고, # $url .= $remotePage; # 아래 단락 추가 ### intermap 에 인코딩 지정 my $encoded_page = $remotePage; if (($encoding ne "") && (lc($encoding) ne lc($HttpCharset))) { $encoded_page = &encode_korean($encoded_page, $HttpCharset, $encoding); } $encoded_page = &EncodeUrl($encoded_page); $url .= $encoded_page; ############### ### added by gypark ### InterWiki 로 적힌 이미지 처리 ### from Jof's patch if ($useImage && ($url =~ /^(http:|https:|ftp:).+\.$ImageExtensions$/)) { $url = $1 if ($url =~ /^https?:(.*)/ && $1 !~ /^\/\//); ... }
오 Orz Wiki에 넣으려던 기능을 훌쩍 넣어버리셨군요.
근데 이 작업 하면서 테스트를 하려 했더니만, EUC-KR을 사용하는 위키들은 주로 물음표링크를 쓰기 때문에 브라우저가 무조건 EUC-KR로 보내니까 상관이 없고.. 노스모크 같은 경우는 UTF-8을 쓰지만 EUC-KR로 넘어온 주소를 알아서 처리하고, 제 홈은 반대로 EUC-KR을 쓰지만 UTF-8로 넘어온 걸 처리하게 했고... 그래서 딱히 테스트할 만한 곳도 많지 않더군요. 제 생각에도 각각의 위키사이트 쪽에서 자신의 인코딩과 다른 방식으로 넘어온 페이지 이름을 처리할 수 있게 해 주는 게 낫다고 봐요. 위키페디아가 그런 처리를 안 해주는게 오히려 뜻밖이었다고 할까. (하긴 도대체 어느 나라 말로 날아올 지 모르니 전부 다 처리해 줄 수 없을지도)
그나마 좀 전에 번뜩 AlbireoWiki (DeadLink)가 모니위키면서 EUC-KR을 쓰더라는 생각이 나서, 테스트해보니 역시나 %-인코딩은 무조건 해 주는게 안전하겠더군요. 수정했습니다.
"Upload :한글파일명"처럼 인터위키로 다른 위키 페이지가 아니라 파일을 링크하는 경우에는 링크를 좌클릭하는 경우 외에 우클릭해서 다른 이름으로 저장을 하는 경우도 고려해야겠는데...
UTF-8위키에서, 한글파일명이 UTF-8로 저장되었고, 링크를 UTF-8로 %인코딩했다면 => 좌클릭도 되고 저장도 잘 됨
EUC-KR위키에서, 한글파일명이 EUC-KR로 저장되었고, 링크를 EUC-KR로 %인코딩했다면 => 좌클릭은 되는데 저장할때는 파일명이 엉망으로 나옴... ㅠ,.ㅠ
UTF-8이든 EUC-KR이든, %인코딩을 하지 않았다면 => 어느쪽이든 저장 잘 됨..
이건 IE의 경우고, FF에서는 이런 문제 없음... 아 정말... IE때문에 인터위키 이름이 Upload 인 경우에 한해서만 %인코딩을 하지 않는 예외를 두던가 해야 할 듯.
Upload는 그렇다치고, 다른 사이트에 있는 파일을 인터위키로 연결하는 경우가 되면 이건 어쩝니까. %인코딩을 하지 않으면 브라우저 옵션에 따라서 링크 자체가 되다 말다 그럴테고, %인코딩을 하면 링크는 잘 되는데 다른 이름으로 저장할 때 이름을 직접 쳐넣어줘야 하겠군요.