UTF-8이전작업
UseModWiki 0.92K3-ext 를 UTF-8 버전으로 이전하기
-
- 1. 개요
-
- 2. To do
-
- 3. Not to do
-
-
- 3.1. $HttpCharset 값을 UTF-8과 EUC-KR중에 자유롭게 선택
-
- 3.2. 페이지를 디스크에 저장할 때의 파일명
-
4. 테스트 & 소스 다운받기
-
- 5. 작업 일지
-
- 6. 참고자료
-
- 7. 의견
-
최근에 이런 저런 수정을 해서 평소 아쉬웠던 건 거의 끝낸 것 같으니, 슬슬 넘어가기 작업을 해 볼까 합니다. 성공하면 ext2 로 버전명도 업글하던가, 아예 이름을 통채로 바꿀지도?
시간 날 때 틈틈이 할 거라서 언제 끝날 지는 저도 모르겠습니다. :-)
2. To do
고쳐야 할 게 생각날 때마다 여기에 적어 두고, 끝나면 작업 일지로 이동.
- 첫 글자 링크 걸기나 페이지 목록 출력할때, "UTF-8"또는"EUC-KR"인코딩을 "unicode"라는 명칭의 인코딩으로 변환을 하는데, 이게 Encode 모듈 최근 버전에서는 잘 되는데 오래된 버전이나 Text::Iconv 에서는잘 안 된다. 다른 방법이 없을까.
- 없어 보인다 =.=;; Text::Iconv 는 너무 버전이 낮다.
- 문제가 되는 곳은 현재 두 곳, "없는 페이지 첫글자 인코딩"과 "페이지 목록에서 상단 인덱스"
- 관련하여 [KLDP 문의글]
- 전체 페이지 목록에서, 영어도 아니고 한글도 아닌 글자들을 위한 섹션을 따로 두던가, 아예 섹션을 어떻게 구분할 지를 환경설정변수로 지정하게 할 법도.
- 일단은 지금 정도가 한계인 듯.
- 모니위키처럼 페이지 이름을 넣고 키를 얻어내어서 그 키만 TOC에 나오게 할 수 있으면 좋겠는데, 현재는 TOC를 먼저 출력하고 페이지 목록을 바로 print하는 구조라서, 일단 다 스트링으로 저장해두고 마지막에 출력하는 식으로 많이 고쳐야 한다.
3. Not to do
손대지 않고 그냥 넘어갈 것. 또는 손대고 싶지만 능력 부족으로 포기하는 것.
3.1. $HttpCharset 값을 UTF-8과 EUC-KR중에 자유롭게 선택
최대한 두 인코딩 각각을 지원하고자 노력하고 있으나, 소스를 수정할 때마다 두 인코딩에 대해 각각 테스트하는 작업이 만만치 않아서 아무래도 EUC-KR 쪽에는 소홀할지도.
3.2. 페이지를 디스크에 저장할 때의 파일명
따로 %-인코딩 같은 거 하지 않고 그냥 저장합니다. 따라서 파일명을 제대로 보려면 서버에 접속하는 터미널 클라이언트가 UTF-8를 지원해야 하고, FTP로 받아올 때도 마찬가지로 FTP 클라이언트가 지원해야 합니다. (말을 바꾸면, 지원하는 클라이언트를 사용하면 여전히 제대로 한글로 보이니 %-인코딩하는 것보다 관리하기 편할 듯)
4. 테스트 & 소스 다운받기
테스트는 아래 주소에서 할 수 있습니다. (스팸이 두려워서 링크는 안 하니 불편하시더라도 붙여넣기 하셔서...)
이 곳 도메인 이름 뒤에 /cgi-bin/utf/wiki.pl
소스는 UseModWiki소스수정/Download에서 받을 수 있습니다.
5. 작업 일지
(최근 작업이 위에 오게 저장합니다)
아래 항목을 처리하고 CVS 올림. tar.gz 포맷으로도 배포 시작
아래 항목을 처리하고 CVS 올림
- /문자열잘라내기 - 스트링에서 "처음 몇 글자"만 뽑아내는 함수를 하나 만들어서 그걸 사용하도록 해야겠음
- 트랙백 내용의 255자 잘라내기
- 블로그에 최근 코멘트 목록의 20자 잘라내기
- 또 잘라내는 곳이 뭐가 있더라만... 존재하지 않는 페이지의 경우 첫글자 잘라내기도 이 함수를 쓰게 할까나
- GET 메쏘드를 통해 들어온 트랙백의 경우는 guess_and_convert를 사용하여 인코딩 변환 시도
페이지 목록 화면에서 TOC를 적당히 구성함. (A-Z, 기타, 히라가나, 가타가나, 기타, 가~하, 기타) CVS 올림
아래의 사안을 처리하고 CVS에 올림
- /링크패턴
- 기존에 저장된 페이지를 utf-8 인코딩과, $FS값을 치환하여 새로 저장 - restore.pl을 조금 덧붙여서 컨버터를 만듦. gyparkwiki의 데이타를 통채로 옮겨왔는데, 별 문제 없는 것 같음.
- vim plugin - vim 이 호출되는 타이밍에 인코딩 문제로 한글이 깨짐.
Ko~VimProcessorFaq 에 있는 대로 해 줘도 안 되네... 같은 서버에 설치한 모니위키에서는 효과가 있는데 ㅠ,.ㅠ
- 혼자서 고치던 걸 포기하고 다시 기존 vim.pl 에서 호출시 "set enc=$HttpCharset"넣어주니까 해결됨
- 이 뭣같은 IE... 페이지를 저장하고 나면 $q->redirect(-uri=>$url); 를 거쳐서 브라우저로 하여금 자동으로 다시 페이지 출력 화면으로 넘어가게 하는데, 여기서도 UTF-8 스트링을 넘길 때 문제가 있다. 이건 슬래쉬링크를 써도 발생함. 왜 계속 페이지 저장할 때마다 잘못된 페이지라고 나오나 했더니만 -_-; 이건 url을 %-인코딩하게 함으로써 해결
- /브라우저GET요청인코딩판별 - euc-kr버전과 반대로, 이번에는 URL이 EUC-KR로 들어왔을 때의 처리가 필요
- 받은 트랙백의 인코딩 처리
- 위키네임에 영어 뿐 아니라 다른 글자도 쓸 수 있다보니, "UseModWiki를" 등으로 한글을 붙여 쓴 게 죄다 새로운 페이지가 되어 버림... 이건 다른 위키에서 어떻게 하는지를 좀 보면서 영어만 인정하게 하든가 해야겠음.
- 일단 위키네임에는 다른 라틴 문자는 허용하지 않고 영어 알파벳만 사용하게 함
SlashLinks = 1 로 설정하고, 각종 URL변수를 절대 경로로 바꿈. (IE버그 때문에 ? 링크는 곤란)
기존의 배포용 소스에서, *.pl, *.css, intermap 등등 텍스트 파일은 죄다 UTF-8 인코딩으로 저장한 후 CVS에 올림.
6. 참고자료
위키위키분류 주인장분류
Go 버튼을 누를때 UTF-8 스트링인지 검사하는게 스크립트 호출이라면 form에서 submit할때 onsubmit="return 스트링검사펑션()"; 이렇게 해서 검사가 되 되지 않을까 싶은데 제가 질문을 잘 이해한걸까요?
브라우저 주소창에 "wiki.pl/페이지이름"이라고 치면, 지금 gyparkwiki는 페이지이름이 valid한지 보고, 아니라면 "이게 UTF-8로 넘어와서 그런가보다" 가정하고 컨버트를 한 후 결과가 valid하면 ok인건데...
utf위키에서는 반대상황이 되니까, 페이지이름이 valid하지 않으면 "euc-kr인가 보다"..라고 하려고 했는데, 테스트해보니 euc-kr로 들어와도 valid판정이 나 버리더라고요 =.=; 페이지이름 패턴에는 들어맞으니...
그래서 다른 방법으로 페이지이름이 legal한 UTF-8 스트링인지를 확인하고, 맞으면 통과. 그렇지 않으면 UTF-8로 컨버트해야 하는데, 그 확인할 방법을 찾던 중이었습니다. 근데 위 참고자료에 링크한 모듈들을 쓰면 될것 같아요. 그 모듈이 없는 서버에서라면 어쩔수 없고...
Go버튼 얘기는, 이렇게 브라우저 옵션에 따라서 URL이 UTF-8이 아닌 인코딩으로 넘어가버리는 경우 때문에 직접 주소창에 쳐서 다른 페이지로 가기가 힘드니, 항상 UTF-8로 넘어가는 걸 보장하기 위한 폼이 있어야겠더라는 거죠. 이 때 submit 해서 넘어가는 건 폼을 출력했던 페이지의 인코딩을 따라가니 상관없을 것 같습니다. (제가 제대로 아는 거라면)
혹시 뭐 좋은 거 아시면 좀 가르쳐주세요 ^^ 잘 지내시죠? ^_^
1) 불여우에서 트랙백 주소 복사 버튼 눌렀을 때는 무조건 그 창 뜹니다. 복사가 실패했을 때만 뜨게 할 방법을 못 찾았어요 UseModWiki소스수정/TrackBack
2) http://canday.pe.kr/wiki/wiki.pl?테스트 <-- 본문이 UTF-8이라 링크도 UTF-8로 걸리는데, IE가 버그로 저 "테스트"를 제대로 UTF-8로 인코딩하지 못하기 때문에 잘못된 페이지라고 나오는 건 어쩔수 없네요 ㅠ,.ㅠ (FF에서는 잘 나오죠?)
3) 트랙백 받을 때 인코딩 조절하는 걸 넣어야겠군요.
4) 트랙백을 보낼 때도 UTF-8로 보낼 텐데, 그건 받는 쪽에서 변환해야... 우리 위키의 경우는 UseModWiki소스수정/UTF-8트랙백받기에 되어 있습니다.
5) 음 테스트페이지의 하단 트랙백 가이드가 왜 제대로 접혀지지 않는지는 의문.
비누넷에 호스팅 하려고 물어 보니까요.
펄 5.8.5로 운영중이나 encode 모듈은 서비스가 제공되지 않으니 참조하라고 하는데요.
그럼 UTF-8 버전 못 쓰는 건가요?
gcc는 일시적으로 지원된다고 해요.
주소는 그대로예요.
세세하게 확인은 못 해봤지만 index 페이지에서 기타로 나오던 한글 가나다로 잘 나오고요. IE에서도 한글 페이지 잘 연결 되는 것 같아요. UTF-8로 이전하는 작업은 밥 먹고 내일까지 해보려고요. 매번 고맙습니다.