[홈으로] [게시판]

아래의 논의는 조금 철이 지났습니다. 현재 닥북 한국 위키는 UTF-8을 사용하고 있습니다. 그리고 UTF-8을 지원하는 DbWiki 버전은 KldpNet 닥북 한국 프로젝드의 CVS에(만) 있습니다. BbsTopic:123을 참고하세요. --류광


최초의 문제제기...

아해ㅎ해ㅎ 같은 글자를 입력했을 경우에 &ddddd; 같은 식으로 DocBook 소스가 나오네요. &ddddd; 같은 식으로 되어야 문서 변환시에 제대로 변환될텐데요.. 아예 DocBook 소스를 utf-8로 나오도록 할 수 있다면 깔끔할 것 같습니다.

또 이런 문자를 입력한 경우에 위키 페이지에서도 물음표로 나오네요..


까다로운 문제네요... 오페라에서는 잘 되는데... 브라우저 별로 시험을 해 볼 필요가 있을 것 같습니다. 그리고 & 를 &로 나오게 하는 것은 단순한 문제는 아닙니다. &를 &로 내보내면, DocBook XML 소스의 적격성(wel-formedness)이 깨질 위험이 생기거든요.

utf-8은 고민을 좀 해봐야 겠습니다. 좀 더 많은 의견을 들었으면 좋겠구요..

--류광

&문제는 간단한 트릭이 있습니다. &다음에 공백이 들어갈 경우 amp;로 바꾸면 되고 나머지는 그대로 출력하도록 합니다.

아예 DbWiki를 UTF-8 기반으로 바꾸는 건 어떨까요? 한글로 된 DocBook 문서라도 참고문헌 등에 유럽쪽 저자 이름(ASCII이외의 문자 포함)이 들어가는 경우가 종종 있거든요. -- 김민식

고쳐야 하는 이유

  • EUC-KR 이외의 문자들을 사용할 수 있다. 참고문헌에 들어가는 유럽의 저자 이름, 중국어 문장 인용 등의 외국어 사용이 가능해진다. 또한 직지 프로젝트처럼 고어를 사용하고자 하는 경우에도 필요하다.

고치지 않아야 하는 이유

  • 안 고치는 게 더 편하다 ^^ --류광

고쳐야 한다면 어떻게?

이 부분을 잘 모르겠는데, 일단 DB에 있는 데이터를 모두 UTF-8로 바꾸고, HTML 헤더의 charset 설정을 UTF-8로 바꾸면 되는 건가요?? --류광

예, 소스 중에 특정 인코딩에 의존하는 부분이 없다면 그정도로 가능할 겁니다. -- 김민식

모인모인을 고쳐서 UTF-8로 DocBook 출력을 하도록 하는 작업을 진행중입니다. 원래 모인모인에 이것저것 정리해 놓고 있었는데, 이걸 DocBook으로 뽑아냈으면 했었거든요. 내부에서 문자열 다루는 부분을 기존의 바이트단위의 문자열 대신 파이썬에서 지원하는 유니코드 문자열(UTF-8이 아님)을 쓰도록 바꿨기 때문에 데이터를 쓰거나 HTML로 출력할 때 UTF-8로 변환이 필요합니다. 그 반대 경우도 마찬가지고요. 그 외에는 별다른 추가 작업 없이 UTF-8로 쓸 수 있었습니다. 유니코드 예제를 올려 놓았습니다.

DocBook 변환은 CVS 사용 정도의 간단한 글은 잘 됩니다. (DocBook XML 파일) -- 김민식

릴리스 1.0.0이 완료되면 본격적으로 작업에 들어가겠습니다. 우선 UTF-8에서 PHP 정규표현식 함수들이 제대로 작동하는지부터 점검을 할 생각입니다... --류광


해결해야 할 문제

간단히 시험을 해봤는데 기술적인 문제는 없었습니다. 정규 표현식 등 문자열 처리 부분에서 바꿔야 할 건 없더라구요.

현재로서 제일 걸리는 것은:

인터위키 호환성

어떤 문제냐 하면, 현재 이곳은 EUC-KR이고 김민식님의 위키는 UTF-8 입니다. 여기서 UniMoin:CVS 사용으로 링크를 걸면 http://home.bawi.org/~minskim/moin.cgi/CVS%20%EC%82%AC%EC%9A%A9 로 가는 것이 아니라 http://home.bawi.org/~minskim/moin.cgi/CVS%20%BB%E7%BF%EB 로 가게 됩니다.

이 곳 또는 DbWiki를 UTF-8로 바꿨다고 할 때 다른 EUC-KR 위키에서 이곳을 링크하는 경우에도 마찬가지 문제가 생길텐데요. 그 반대의 경우도 역시 문제가 생기구요.

인터위키는 꼭 필요한 기능 중 하나라고 생각하고, 그렇다고 다른 위키들에게 특정 인코딩을 강요할 수도 없고.... 깔끔하게 해결하는 방법이 없을까요? (위키 개발자들이 한 번 모여야 할까요? ^^ )

--류광

두 가지 해결 방법이 생각났는데

  1. 하나는 여기서 다른 곳을 링크할 때 적용할 수 있는 것인데, InterWikiMap에 인터위키 링크를 설정할 때 그 위키가 UTF-8을 사용하는지 아닌지에 대한 어떤 플래그를 추가하는 것입니다. 이 곳에서 인터위키 링크를 걸 때 그 플래그를 보고 URL을 적당히 변환합니다.
  2. 또 하나는, 다른 곳에서의 요청에 대한 해결방법인데, 김민식님 위키의 오류 메시지를 보니 주어진 바이트들이 UTF-8인지 아닌지를 절차적으로 판단할 할 수 있나봐요. 그런 걸 이용하면 되겠죠.

--류광


첫번째가 제일 좋은 방법같네요. 단, URL에 UTF-8을 쓰는 게 RFC 2718의 권고사항이므로 InterWikiMap에 인코딩이 명시되어 있으면 그걸 쓰고, 아무것도 없으면 UTF-8을 쓰도록 하는게 좋을 것 같습니다.

(두번째의 경우)UTF-8의 특성상, EUC-KR 한글 문자열이 UTF-8로 해석되는 건 거의 불가능합니다. EUC-KR로 오는 건 대부분 걸러낼 수 있다는 거죠. fallback_charset이란 설정 내용을 추가해서, URL이 UTF-8로 디코딩되지 않으면 fallback_charset으로 디코딩하도록 했습니다. 이 값을 euc-kr로 해 놓았더니 UniMoin:CVS 사용도 잘 되는군요. -- 김민식


예. PHP의 경우에는 iconv('UTF-8', 'euc-kr', $str)이 false를 돌려주면 $str이 원래부터 euc-kr이었다고 해석하면 될 것 같습니다. 몇 가지 문자열들로 시험을 해 봤는데 잘 됩니다.

그런데 저는 인터위키에 새로운 규칙을 추가하는 것보다는 링크를 받는 쪽에서 해석을 하게 만드는 게 더 좋을 것 같아요. 왜냐하면 InterWikiMap에 새 항목을 추가하거나 수정하는 것은 일반 사용자들이 하는 일인데 실수를 한다던가 하는 여지가 있는 반면 링크 해석을 좀 더 유연하게 하는 것은 개발자가 한 번만 해놓으면 되니까요.... 다른 위키들도 이런 방법을 사용하도록 설득을 하는게 문제겠지만 이런 방법의 장점은 명확하고 또 PHP 예제 코드와 Python 예제 코드를 제공한다면 다들 받아들일 것입니다....

당장 문제는..... 이 n4gate.com 서버의 PHP가 iconv 모듈을 지원하지 않습니다ㅠ.ㅠ 요청을 했는데 컴파일을 다시 해야 하는 문제라서 다음 번 서버 업데이트 때 해준다고 하네요... PHP 스크립트 안에서 해결할 수 있는 방안을 찾아보겠습니다.

--류광


UTF-8로 가거나 그렇지 않거나는 사용자 선택 사항이라고 생각됩니다. $charset 과 같은 변수가 있어서 그 값이 EUC-KR이면 그 위키의 기본 인코딩이 EUC-KR이 되어야 겠고, UTF-8이면 그 위키의 인코딩이 UTF-8이 되어야겠죠. 양쪽을 다 지원해야 하는 것이 정상이고 그렇게 어려운 것은 아니라고 봅니다. --아무개

제일 위로
최종 수정 일시: 01월 17일(2005년) 09:41 PM 편집 | 정보 | 차이 | 비슷한페이지 | DebugInfo
유용한 페이지들: 분류 분류 | 자유로운 연습장 SandBox | 무작위 페이지들 RandomPages | 인기있는 페이지들 MostPopular