-
- 1. intermap에 인코딩 지정
-
-
- 1.1. 사용법
-
- 1.2. 부작용
-
- 1.3. wiki.pl 수정
-
- 1.4. 추가 업데이트 내역
-
- 1.5. 사용자 의견
-
1. intermap에 인코딩 지정
InterMap 파일에 해당 사이트의 주소 인코딩을 지정하면, 인터위키처리를 할 때 지정된 인코딩으로 컨버트한 후 %-인코드를 하여 링크를 건다.
위키페디아 같은 경우는 페이지 이름으로 반드시 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:위키위키 - 그런 지정이 없는 경우와 비교
-
위키위키
-
위키위키
- IE에서 위의 두 링크를 각각 마우스로 가리키면, 처음 링크는 하단 상태 표시줄에 "%EC%9C..."와 같이 UTF-8코드값을 %-인코딩한 상태로 표시되고, 아래 링크는 EUC-KR코드값을 %-인코딩한 "%C0%A7..."로 나오는 것을 확인할 수 있다. (GyparkWiki가 UTF-8로 넘어갔기 때문에 현재는 둘 다 동일하게 %EC%9C...로 나온다) FF에서는 그걸 다시 스트링으로 바꿔주는지 상태 표시줄에는 둘 다 "위키위키"로 나온다. 어쨌거나 IE나 FF의 URL관련 옵션값에 관계없이 위키페디아 링크가 제대로 작동하는 것을 확인 가능
정확히 얘기하면, intermap에 적힌 인코딩과 자기 홈의 $HttpCharset 변수의 값이 다를 경우에, 페이지 이름 부분만 HttpCharset의 값에서 intermap에 적힌 값으로 컨버트를 시키고, 그걸 %-인코딩한 후, intermap에 적힌 사이트 주소에 합쳐서 링크를 만든다. intermap에 인코딩 명시가 되어 있지 않다거나, 적힌 인코딩과 자기의 캐릭터셋이 같은 경우는 %-인코딩만 한다.
따라서, 페이지 이름 부분이 아니라 사이트 주소 자체에 멀티바이트 문자가 있는 경우는 적용 안 될 것임.
1.3. wiki.pl 수정
sub InterPageLink {
...
($site, $remotePage) = split(/:/, $id, 2);
$url = &GetSiteUrl($site);
my ($image, $url_main, $encoding);
($url, $image, $encoding) = split(/\|/, $url);
$url_main = $url;
return ("", $id . $punct) if ($url eq "");
$remotePage =~ s/&/&/g;
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;
if ($useImage && ($url =~ /^(http:|https:|ftp:).+\.$ImageExtensions$/)) {
$url = $1 if ($url =~ /^https?:(.*)/ && $1 !~ /^\/\//);
...
}
1.4. 추가 업데이트 내역
ext1.111a
- "EUC-KR인코딩을 쓰면서, 슬래쉬링크를 사용하는 위키"에서는 여전히 브라우저 옵션에 따라서 인터위키가 동작을 하다 말다 하기 때문에, 문자셋 인코딩이 같은지 여부에 관계없이 페이지 이름은 무조건 %-인코딩을 하도록 함
오 Orz Wiki에 넣으려던 기능을 훌쩍 넣어버리셨군요.
- 위키페디아 링크를 제대로 못 거는 게 싫어서요. 어제 아침에 생각나고 오늘 낮에 작업했는데,
OrzWiki에서 언급되었던 기억도 났었습니다. ;-) 어서 OrzWiki를 만들어주세요, 갈아타고 저는 좀 얻어쓰면서 놀게 ^^;;;
근데 이 작업 하면서 테스트를 하려 했더니만, 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는 그렇다치고, 다른 사이트에 있는 파일을 인터위키로 연결하는 경우가 되면 이건 어쩝니까. %인코딩을 하지 않으면 브라우저 옵션에 따라서 링크 자체가 되다 말다 그럴테고, %인코딩을 하면 링크는 잘 되는데 다른 이름으로 저장할 때 이름을 직접 쳐넣어줘야 하겠군요.
- 위키의 인코딩과 위키를 통해 업로드한 파일들의 이름 인코딩은 항상 동일할 거라고 생각하고, Upload 에 한해서만 %인코딩하지 않도록 해야겠음.
위키위키분류
![[첫화면으로]](/raymundo_logo.jpg){kind=logo}
UseModWiki소스수정/InterMap에인코딩지정