dokuwiki 한글페이지명에 대한 의문
글쓴이: bootmeta / 작성시간: 토, 2007/02/03 - 1:23오전
개인적인 자료정리를 목적으로 dokuwiki를 ubuntu(utf8-encoding)에 설치했습니다.
처음으로 위키를 사용하게 되어서 막연한 두려움이 있었음에도, 일단 설치하고 나니 관리나 문법등이 의외로 단순해서 편하다는 생각이 듭니다.
(간단해서 인지 의외로 한글 문서들은 없군요. -_-)
제가 dokuwiki를 선택한 가장 큰 이유가 flat text 화일로 되있다는 점인데 문제점이 하나 보입니다.
한글 페이지명은 %ED%82%A4_%EC%84%A4%EC%A0%95같은 utf8포맷으로 바뀌어 저장된다는 것...
혹시 %ED%82%A4_%EC%84%A4%EC%A0%95같은 utf8포맷이 아닌 직접적인 한글 페이지명을 기술할 수 있는 apache설정이나 dokuwiki설정이 있는지 궁금합니다.
dokuwiki에서 만들지 않고 editor로 직접 만든 화일명이 한글인 파일은 목록상에서 정상적으로 한글로 보입니다.(접근시에는 주소창에 utf8포맷으로 보입니다.)
dokuwiki상에서 만들어진 %ED%82%A4_%EC%84%A4%EC%A0%95.txt을 수작업으로 키_설정.txt처럼 한글 파일명으로 바꾸었을 때 dokuwiki상에서 인식을 못하는 것 같습니다.
dokuwiki version 2006-11-06
apache2 version 2.0.55-4ubuntu4
php version 5.1.6-1ubuntu2.1
Forums:
dokuwiki뿐만 아니라
dokuwiki뿐만 아니라 flatfile based 위키는 위와 비슷한 문제점을 가지고 있습니다.
직접 파일을 편집하는 것은 좋지 못한 방법입니다.
일단, %xx 형식은 UTF-8
일단, %xx 형식은 UTF-8 형식이 아니구요... 인코딩 된 URI입니다.
저런 식으로 바꿔서 저장하는 것은 파일 시스템에 관계없이 작동하게 하기 위해서인 것 같습니다. 예를 들어 윈도우라면 UTF-8로 된 파일명을 제대로 저장할 수 없을테니까요.
위키 관련 자료를 살펴보니..
저와 비슷한 질문과 요청 사례가 있었나 봅니다.
http://community.wikidot.com/forum/t-2839
urlencode와 utf8을 순간 제가 착각했었습니다.
제가 생각하기에 OS에서 지원하는 charset을 명시적으로 지정할 수 있수 있게 하는 것은 파일 시스템에 관계없이 작동하게 하는 점보다 자연스럽게 각 파일에 직접 접근해서 작업할 수 있다는 장점이 더 커보입니다.
(개인적으로 flast file형 위키를 선택한 이유가 editor로 직접 편집하는 것이 편리해서 였습니다.)
내부 구조를 들여다 보지 않아서 단정지을 수는 없으나, 설치 OS의 charset만 지정하면 충분히 반영할 수 있을 것도 같습니다.
다른 시스템으로 옮기는 경우에도 간단히 파일명charset 변환도 가능하다는 생각도 듭니다.
dokuwiki외에도 다른 flat file형 wiki들에서도 공통적으로 이런 점이 보인다는 것은 영문권 개발자들과 비영문권과의 간극이 아직도 넓다는 생각도 들게하고, 저를 비롯해 위키를 쓰는 많은 우리나라 사람들이 좀 더 분발해야되지 않나 생각됩니다.
> dokuwiki외에도 다른
> dokuwiki외에도 다른 flat file형 wiki들에서도 공통적으로 이런 점이 보인다는 것은 영문권 개발자들과 비영문권과의 간극이 아직
> 도 넓다는 생각도 들게하고, 저를 비롯해 위키를 쓰는 많은 우리나라 사람들이 좀 더 분발해야되지 않나 생각됩니다.
파일이(페이지가) 몇천개 이상 되면 그 파일이 어떤 이름으로 저장되었는지 알아서 그 파일을 직접 편집한다는게 얼마나 잘못된 편집 방식이라는 것을 쉽게 아실 수 있게 됩니다.
위키에 내장된 기능을 안쓰고 직접 lowlevel로 편집한다는 것은 마치 불도우져를 두고 삽질을 하는 것에 비유할 수 있을 듯. 물론 100개 미만의 페이지를 편집할 경우라면 직접 파일을 다루는 것도 나쁘지 않겠지만요.
또한, 파일을 직접 편집하게 되면 위키의 큰 장점인 히스토리도 무용지물이 되고, 그 페이지에 대한 여러가지 meta정보 역시 제대로 생성되지 않게 되어 위키를 제대로 활용하지 못하게 됩니다.
단순히 파일시스템에 저장하는 문제가 아닙니다.
각종 웹 브라우저에서 URL에 들어있는 생짜 한글을 어떻게 넘겨주는지 분명치 않은 데다, 그게 인코딩마다 다 다르거든요. 위키를 돌리는 스크립트가 브라우저에서 받아야 할 정보가 제대로 넘어가리란 보장이 없기 때문에 굳이 사람이 읽지도 못하는 글자들로 바꿔서 안전하게 넘기는 겁니다.
그동안 '많은 우리나라 사람들'이 아무 생각이 없어서 그냥 둔 게 아닙니다.
아 그렇군요.
브라우저마다 한글을 다르게 처리할 수도 있다는 것은 생각도 못했습니다.
문제에 대해서 깊이 생각 않고 너무 쉽게 생각했군요.
때 늦은 반성을 하게 됩니다.
혹시 비록 브라우저들에서 지키지는 않더라도 urlencoding처럼 여러 언어에 대해 공통적으로 encoding하는 제안이나 표준이 존재하는지 궁금합니다.
혹시 아시는 분이 있으신지?
접근 방식의 차이일 듯 싶습니다.
개인적으로 기존에 가지고 있는 짧은 문서들이 많습니다.
저처럼 기존 자료들을 가지고 있는 사람들은 bottom-up접근 방식을 취하는 경우가 꽤 있습니다.
저에게 위키가 필요한 목적이 주로 기존 자료들을 취합해 정리하려는 것이지 일반적인 top-down식으로 새 위키에서 출발해서 새로운 항목을 늘리는데 있지 않습니다.
그리고 아직까지는 기존 디렉토리구조에 자료를 모아놓고 보는 것에 익숙해서 파일명으로 쉽게 자료를 찾을 수 없다면 구태여 위키를 쓸 필요가 없다는 생각도 드는군요.
(기존 자료가 없다면 옮겨가는 것이 좀 쉽겠죠.)
물론 히스토리 기능과 meta정보 생성을 위해서 편집 후 위키에서 페이지를 열고 닫는 수고 정도는 에디터로 편집하는 만족도를 생각한다면 감내할만하다고 생각듭니다.
아무래도 web기반 wiki보다는 좀 더 개인적인 용도로 쓰이는 emacs-wiki나 muse를 한번 고려해봐야 될 것 같네요.
댓글 달기