| -27,7 +27,7 |
| }}} |
| * KoWikipedia:위키위키 |
| * GyparkWiki:위키위키 |
| * IE에서 위의 두 링크를 각각 마우스로 가리키면, 처음 링크는 하단 상태 표시줄에 "%EC%9C..."와 같이 UTF-8코드값을 %-인코딩한 상태로 표시되고, 아래 링크는 EUC-KR코드값을 %-인코딩한 "%C0%A7..."로 나오는 것을 확인할 수 있다. FF에서는 그걸 다시 스트링으로 바꿔주는지 상태 표시줄에는 둘 다 "위키위키"로 나온다. 어쨌거나 IE나 FF의 URL관련 옵션값에 관계없이 위키페디아 링크가 제대로 작동하는 것을 확인 가능 |
| * IE에서 위의 두 링크를 각각 마우스로 가리키면, 처음 링크는 하단 상태 표시줄에 "%EC%9C..."와 같이 UTF-8코드값을 %-인코딩한 상태로 표시되고, 아래 링크는 EUC-KR코드값을 %-인코딩한 "%C0%A7..."로 나오는 것을 확인할 수 있다. (GyparkWiki가 UTF-8로 넘어갔기 때문에 현재는 둘 다 동일하게 %EC%9C...로 나온다) FF에서는 그걸 다시 스트링으로 바꿔주는지 상태 표시줄에는 둘 다 "위키위키"로 나온다. 어쨌거나 IE나 FF의 URL관련 옵션값에 관계없이 위키페디아 링크가 제대로 작동하는 것을 확인 가능 |
|
| 정확히 얘기하면, intermap에 적힌 인코딩과 자기 홈의 $HttpCharset 변수의 값이 다를 경우에, 페이지 이름 부분만 HttpCharset의 값에서 intermap에 적힌 값으로 컨버트를 시키고, 그걸 %-인코딩한 후, intermap에 적힌 사이트 주소에 합쳐서 링크를 만든다. intermap에 인코딩 명시가 되어 있지 않다거나, 적힌 인코딩과 자기의 캐릭터셋이 같은 경우는 %-인코딩만 한다. |
|
| -86,7 +86,7 |
|
| 근데 이 작업 하면서 테스트를 하려 했더니만, EUC-KR을 사용하는 위키들은 주로 물음표링크를 쓰기 때문에 브라우저가 무조건 EUC-KR로 보내니까 상관이 없고.. 노스모크 같은 경우는 UTF-8을 쓰지만 EUC-KR로 넘어온 주소를 알아서 처리하고, 제 홈은 반대로 EUC-KR을 쓰지만 UTF-8로 넘어온 걸 처리하게 했고... 그래서 딱히 테스트할 만한 곳도 많지 않더군요. 제 생각에도 각각의 위키사이트 쪽에서 자신의 인코딩과 다른 방식으로 넘어온 페이지 이름을 처리할 수 있게 해 주는 게 낫다고 봐요. 위키페디아가 그런 처리를 안 해주는게 오히려 뜻밖이었다고 할까. (하긴 도대체 어느 나라 말로 날아올 지 모르니 전부 다 처리해 줄 수 없을지도) \\ |
| \\ |
| 그나마 좀 전에 번뜩 AlbireoWiki:AlbireoWiki""가 모니위키면서 EUC-KR을 쓰더라는 생각이 나서, 테스트해보니 역시나 %-인코딩은 무조건 해 주는게 안전하겠더군요. 수정했습니다. <mysign([[Raymundo]],2007-2-12 1:03 am)> |
| 그나마 좀 전에 번뜩 AlbireoWiki:AlbireoWiki"" (DeadLink)가 모니위키면서 EUC-KR을 쓰더라는 생각이 나서, 테스트해보니 역시나 %-인코딩은 무조건 해 주는게 안전하겠더군요. 수정했습니다. <mysign([[Raymundo]],2007-2-12 1:03 am)> |
|
| "Upload :한글파일명"처럼 인터위키로 다른 위키 페이지가 아니라 파일을 링크하는 경우에는 링크를 좌클릭하는 경우 외에 우클릭해서 다른 이름으로 저장을 하는 경우도 고려해야겠는데... \\ |
| \\ |
![[첫화면으로]](/raymundo_logo.jpg){kind=logo}
"UseModWiki소스수정/InterMap에인코딩지정" 페이지의 변경 내역