Tag: utf-8

wordpress: korean trackback!

어제 까날옹이 egloos 에서 가볍게 트랙백을 날려주셨는데, egloos 에선 trackback 인코딩을 euc-kr 을 사용하는지 트랙백이 깨져서 와버렸네요. 혹시나 관련된 plugin 을 찾아봤지만 plugin 으로는 아직 존재하지 않는 듯 하고, 관련해서 wind-like 님이 문제를 해결한 버젼의 wp-trackback.php 파일을 배포하시더군요.
하지만 wordpress 기본 파일을 수정할 경우 업데이트를 할 때마다 다시 수정해줘야 하는 번거로움이 있기 때문에 그냥 plugin 을 작성해버렸습니다. 막상 plugin 을 작성하려고 보니 trackback_post 에 대한 action 은 글이 삽입된 이후에 실행되도록 되어 있더군요. 역시 그냥 wp-trackback.php 를 수정해서 사용해야 하는건가 하는 생각이 들었지만, 뭐 정도가 아니면 돌아가면 되는 법!! 이미 데이타베이스에 입력완료된 trackback 을 update 하도록 하는 hack 에 가까운 플러그인이 만들어져버렸습니다. -_-v
혹시나 필요한 분은 아래 url 에서 받아서 사용하시면 되겠습니다.
http://mytears.org/resources/distfiles/wp_korean_trrackback-1.0.zip
p.s) wind-like 님이 수정하신 버젼과는 다르게 ‘트랙백을 받는 경우’ 하고만 관련이 있습니다.

RFC2047: Message Header Ext for Non-ASCII

CSS Design Korean 게시판을 보다가 vBulletin 을 통해 발송된 메일의 문제점 관련된 글을 보게되었습니다… mail header 에 ASCII 가 아닌 글자가 들어가게 될 경우엔 오래된 시스템에서 문제를 일으킬 수도 있기 때문에… 한글과 같은 ASCII 영역 밖의 글자들을 사용하고 싶은 경우엔 RFC2047 에 따라 인코딩을 해줘야 합니다…

해당 쓰레드: http://forum.standardmag.org/viewtopic.php?id=189
Continue reading RFC2047: Message Header Ext for Non-ASCII

proftpd: codeconv module

사실 unfix 는 나 혼자 쓰는 서버가 아니고… 파일이름등을 unicode 로 관리할 경우 ms 윈도우와의 궁합이 그다지 좋지 않기 때문에… utf-8 환경을 갖추는 게 망설여지는게 사실이었다.
얼마 전 젠투 한국 사용자그룹의 유리님의 개인 portage-overlay 리스트를 보다가 proftpd 의 charset conversion 패치를 발견했다. 원 출처는 일본 쪽인 듯 싶은데, 이 패치를 적용하면 client 에서 사용하는 charset 과 server에서 사용하는 charset 을 설정하는게 가능해진다.

만약 중간에 charset conversion 에 실패했다거나 한 경우 어떻게 처리를 하나 봤더니, 변환에 실패한 글자를 ‘?’ 로 바꿔버리고 있었다. out_buffer size 를 in_buffer size 의 세 배 크기로 할당하고 중간에 에러가 발생하면 무조건 변환이 실패한 것으로 생각하기 때문에 한 글자를 표현하는데 3바이트보다 더 많은 바이트 수가 필요하다면 (ucs2 로는 표현 못하는 글자를 사용하는 경우), 버퍼 오버플로의 희생양이 될 수도 있을 듯 싶다. 그래도 원하는 코드를 삽입하는 건 힘들고 그저 segmentation error 를 부를 뿐이겠지만 찝찝한 건 사실이므로 에러가 발생할 경우 errno 를 참고하도록 패치를 해야겠다.

근데 실제 적용을 해보니 Directory 나 .ftpaccess 를 통한 지역 설정이 허용되지 않는다. 내가 사용하는 폴더들에 한해서 저 패치의 영향을 받게 하는게 목적이었기 때문에 결국 패치를 해버렸다. proftpd 개발자 문서는 서버가 다운되었었는지 참고를 할 수가 없었고, 그나마 미러링 된 곳도 찾을 수가 없어서 한참 헤매긴 했지만!! 결국!! 내가 원하는 데로 패치 성공 -_-v

mod_autoindex 도 몇 일전에 charset 을 설정해줄 수 있도록 패치했고, 그 외에는 이미 다 준비가 되어 있었기 때문에 누군가 mod_autoindex 의 새로운 테마만 만들어준다면 바로 utf-8 환경으로 넘어갈 수 있을 듯 싶다.

FTP 관련해선 RFC2640 에 있는 것을 구현하는 것이 옳다고 생각하지만 중간 단계로써 mod_codeconv 도 나름의 의미가 있을 듯 싶다.

p.s) 위의 사이트에 나와있는 메일 주소로 패치파일을 보내주려 했지만 메일주소가 죽어있네요.

컴퓨터 속의 한글

컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.
우선 한글은 조합형, 완성형, 확장 완성형, iso2022-kr, unicode 등으로 표현이 가능하며… 조합형, 완성형, 확장 완성형, iso2022-kr 등은 symbol table 과 한자 테이블 또한 가지고 있지만 여기서 관련된 내용은 거의 얘기하지 않을 겁니다.

  1. 조합형 (Johab)

    ASC II 범위에 있는 글자는 그대로 프린트하고 한글인 경우 MSB 를 1로 세팅하고 나머지 비트를 초성(5bit) / 중성(5bit) / 종성(5bit) 을 표현하는데 사용한다. 이론 상으로 한글 11172 자를 모두 표현해낼 수 있으며 한글 입력을 처리하기가 아주 쉽다. 다만 Microsoft 에서 완성형을 선택함에 따라 잊혀진 인코딩이 되어가고 있다.

  2. 완성형 (EucKR)

    ksx1001 에 정의되어 있으며 역시나 ASC II 범위의 글자는 그대로 프린트 한다. 한글의 경우 연속된 두 개의 바이트를 이용해서 표현하게 되며 첫번째 바이트와 두번째 바이트 모두 0xA1~0xFE 사이의 값을 가진다.
    한글은 2350 자 밖에 지원하지 않지만 MS windows 에서 선택함에 따라 널리 사용되고 있다.

  3. 확장완성형 (Unified Hangul Code)

    Microsoft 에서 EucKR 에 몇 가지 글자를 더 추가한 인코딩으로 UHC, cp949 등으로도 불린다. 빈 공간에 글자를 추가해 넣었기 때문에 바이너리 값 그대로 정렬을 시도할 경우 한글의 가나다라 순서대로 정렬되지 않는 문제가 있다.
    EucKR 과 마찬가지로 한글을 표현하는데는 2바이트를 사용하며 첫번째 바이트는 0x81~FE 사이 두번째 바이트는 0x41~5A, 0x61~7A, 0x81~FE 영역을 차지한다.

  4. iso2022-kr

    EucKR 을 7bit 만 사용하며 표현하는 방식으로 RFC1557 에 정의되어 있다. Designator Sequence (0x1B 24 29 43), SO (0x0E), SI (0x0F) 등을 이용해 EucKR 을 7bit 로 변환시킨다.
    Designator sequence 는 non ASC character 를 만나기 전에 아무 때나 한 번 출력하면 된다. non asc character들을 출력할 때는 ‘SO char&0x7F char&0x7F char&0x7F SI’와 같은 식으로 SO를 먼저 하나 출력하고, msb가 제거된 non sac character 값들을 모두 출력한 뒤 SI를 출력하면 된다. 이런 과정을 반복하면 EucKR 은 iso2022-KR 로 변환된다.
    그 과정을 pseudo code 로 표현하자면 (위에 설명이 좀 복잡하게 보이는데 실제로 보면 간단하다.)

    (위의 pseudo code 에서는 Designator Sequence 를 맨 앞에 출력을 했지만 iconv 등에서는 처음으로 non asc character 를 만났을 때 출력하고 있다.)

위의 네가지 인코딩 이 그동안 많이 쓰여왔던 인코딩 들인데 국제화 시대인 지금은 오로지 한글만을 표현할 수 있는 저런 인코딩으로는 뭔가 부족하다. 그렇기 때문에 유니코드 콘소시움에서는 여러가지 언어를 함께 표현할 수 있도록 unicode 라는 글자집합(character set)을 만들어 냈으며, 유니코드를 표현하는 5가지의 encoding 을 제공하고 있다. (ucs2, ucs4, utf-7, utf-8, utf-16)

  1. ucs2

    2바이트 고정형 인코딩, unicode 와 4.0 버젼과 동일하다. Endian 관련해서 Big Endian 과 Little Endian 으로 표현이 가능하다.

  2. ucs4

    4바이트 고정형 인코딩. 길이를 제외하곤 ucs2 와 거의 동일하다.

  3. utf-7

    unicode 의 mail safe version. RFC1642 에 정의되어 있다. BASE64 와 비슷한 방식을 통해 unicode 를 7bit 로 표현하게 된다.

  4. utf-8

    가변형 인코딩으로 1바이트영역은 Asc II 와 100% 호환된다. 0x00 이 사용되지 않으므로 전통적으로 C 언어에서 사용해온 null terminated 방식을 사용하는데 문제가 없고 2바이트 이상을 사용하는 경우 특수한 규칙을 가지고 있기 때문에 validation 이 가능하다.

  5. utf-16

    ucs2 와 ucs4 를 적절하게 혼합해서 사용하는 방식으로 BMP (Basic Multilingual Plane) 에 들어있는 글자는 2 바이트로 표현하게 되고 그 외의 글자들은 4 바이트를 이용해서 표현하게 된다.

utf-7 과 utf-8 을 제외하고는 byte order 가 중요시 되기 때문에 BOM(Byte Order Mark) 를 문서 맨 앞에 삽입해야 한다. 그렇기 때문에 Unicode 로 작성된 텍스트 파일의 경우 BOM 을 이용해 어떤 인코딩을 사용하는 지지 알아내는게 가능하다. (utf-8 을 위한 BOM 도 존재하지만 utf-8 의 경우 Byte Order 가 정해져 있기 때문에 BOM 을 의무적으로 삽입할 필요는 없다.)

Encoding UTF-8 UTF-16BE UTF-16LE UTF-32BE UTF-32LE
‘가’ EA B0 80 AC 00 00 AC 00 00 AC 00 00 AC 00 00
Smallest code point 0000 0000 0000 0000 0000
Largest code point 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF
Code unit size 8 bits 16 bits 16 bits 32 bits 32 bits
Byte order N/A big-endian little-endian big-endian little-endian
Byte order mark EF BB BF FE FF FF FE 00 00 FE FF FF FE 00 00
Minimal bytes 1 2 2 4 4
Maximal bytes 4 4 4 4 4

대강 ucs2, ucs4, utf-8, utf-16, utf-32 의 특징을 정리하면 위의 표와 같다. UTF-8 의 경우엔 ASC II 와 호환이 되기 때문에 영어권 언어들에서 별다른 조작 없이도 문제를 일으키지 않게 되므로 널리 쓰이고 있다. UTF-8 과 UCS2 사이의 변환은 아래와 간단한 규칙을 통해 이루어지게된다.

  1. 0x00~0x7F 까지는 그냥 표시한다.
  2. 0x80~07FF 까지는 B110xxxxx 10xxxxxx (2바이트)
  3. 0x0800-FFFF 까지는 B1110xxxx 10xxxxxx 10xxxxxx (3바이트)
  4. 이후는 UCS4 영역이고 위와 같은 방식으로 4바이트까지 확장됩니다.

보다시피 ASC II 는 그대로 표현하고 있습니다. 그리고 2바이트 이상을 사용하는 문자에서는 2진수 기준으로 앞에 붙어있는 1의 개수가 그 글자를 표시하는데 사용된 바이트 수를 나타내며, 2번째 바이트부터는 맨 앞에 10 을 붙여줌으로 이건 글자의 시작이 아니라는 걸 표시하게 됩니다. 위의 두 규칙을 지키면서 unicode 를 2진수로 바꾸어 xx 로 표시된 영역에 차례로 배치하게되면 ucs -> utf-8 변환은 끝이 납니다. 한글은 UTF-8 로 표현하게 될 경우 한 글자 당 3 바이트 씩을 차지하게 됩니다.
그리고 이 유니코드에서 한글이 차지하는 영역은 아래와 같습니다.

  1. U+1100: 조합형 영역

    첫가끝 코드라는 이름으로도 불리고 있으며 초성(첫), 중성(가운데), 종성(끝)이 각기 다른 영역에 배치되어 있다. 이 영역에 있는 글자들을 이용하면 한글 고어까지도 표현이 가능해진다.
    한글 한 글자를 표현하는데 많은 저장공간이 필요하다는 점과, iconv 에서 첫가끝 영역 -> Euc-KR, iso2022-kr, UHC 로의 변환이 불가능한 점 등이 약간의 문제라고 생각됨.

  2. U+3130: 한글 자모 영역

    ㄱ,ㄴ,ㄷ,ㄹ, … , ㅏ,ㅑ,ㅓ,ㅕ, … 등의 자음과 모음이 배치되어 있는 영역

  3. U+AC00: 완성형 영역

    가각… 같이 이미 완성되어 있는 한글 케릭터가 11172 자 배치되어 있다.

Link:

  • http://mytears.org/resources/doc/Hangul_Code/
  • http://www.jinsuk.pe.kr/Unicode/Unicode_intro-kr.html
  • http://ko.wikipedia.org/wiki/UTF-8
  • http://ko.wikipedia.org/wiki/UTF-16
  • http://unicode.org
  • http://www.unicode.org/charts/PDF/U1100.pdf
  • http://www.unicode.org/charts/PDF/U3100.pdf
  • http://www.unicode.org/charts/PDF/UAC00.pdf