서체와 관련된 희망사항…

어쩌다가 몇 년전에 kldpcdk 의 포럼에서 제가 참여했던 쓰레드들을 다시 보게 되었습니다. 유니코드나 서체와 관련된 글들에서 가끔 흥분을 했던 기억이 있는데, 지금 다시 보니까 얼굴이 화끈화끈 거리는군요. 하여튼 ‘왜 공개 글꼴이 필요한가?’ 쓰레드를 보고 생각난 게 있어서 오랫만에 포스팅을 해보려 합니다.
현재 은글꼴, ttf-alee, 서울체, 남산체, 백묵 글꼴 등등 공개 글꼴들이 하나 둘 나타나기 시작하고 있지만, 아직도 화면용(On screen display)으로 특화된 서체는 없습니다. 그 때문에 웹에서는 IR(Image Replacement) 등의 방법을 통해 이미 렌더링된 이미지로 텍스트를 대체시키는 방법을 많이 사용하고 있는데, 왜 화면용 글꼴에는 다들 관심을 가지지 않는 것일지 조금 아쉽네요.
Microsoft 의 경우 화면 용으로 Webdings, Verdana, Georgia, Trebuchet MS, Comic Sans MS, Impact, Arial, Courier New, Times New Roman 등의 서체를 공개하고 있습니다. 다음 페이지를 참고해보시면 알겠지만 이 서체들은 대부분 IE 나 Microsoft Windows 에 기본으로 번들되어 있기 때문에 대부분 기본으로 설치되게 됩니다.
http://www.microsoft.com/typography/web/fonts/fonts02.htm
또한 다음 URL 을 참고해보시면 웹을 통해 다운로드 받은 뒤 매킨토시에서도 사용할 수 있다고 되어 있습니다. (Verdana, Trebuchet MS 등은 화면용으로는 불필요한 기능들을 제외시킨 화면용 글꼴입니다.) 게다가 Linux 에서도 흔히 Corefonts 란 이름으로 패키징되어 사용되고 있죠.
http://www.microsoft.com/typography/web/fonts/verdana/default.htm
물론 아무 제약 없이 사용할 수 있는 서체의 개발을 의뢰하는 데는 많은 비용이 드는 것으로 알고 있습니다. 그렇기 때문에 서울 남산체, 한강체 처럼 (서울시에서 주도했으니) 나라에서 주도해서 자유롭게 사용가능한 화면용 서체들이 좀 개발되었으면 하는 바램이 있네요. 뭐 조금 앞어나간다면 IE 서비스팩 등에 그 새로운 화면용 글꼴들이 포함되었으면 더 좋겠구요. (이런 건 정치적인 문제다보니…)

wordpress: 최근 추가한 플러그인들…

여기저기 돌아다니다 보니 멋진 플러그인들이 많길래 이것저것 추가해보았습니다.
1. Korean Trackback
이글루스에서 오는 트랙백이 euc-kr 로 인코딩되어 있기 때문에, utf-8 기반의 워드프레스에선 이글루스에서 보내는 트랙백을 제대로 받을 수 없기에… 직접 플러그인을 작성해서 추가해줬습니다. -_-v
url: http://b.mytears.org/2006/09/396
2. iG:Syntax Hiliter
혹시나 포스트에 프로그램 코드를 삽입할 일이 있을 경우를 대비해서, 코드 하일라이팅을 위한 플러그인을 추가했습니다. 상당히 많은 언어를 지원합니다만 sh (쉘스크립트) 는 지원하지 않아서 약간 아쉽네요. 사용 예는 아래와 같습니다.

url: http://blog.igeek.info/wp-plugins/igsyntax-hiliter/
3. wp-scripts, ajax-spoiler
wp-scripts 는 prototype.js 등을 헤더에 삽입해주는 역할을 하고, ajax-spoiler 는 tt 에서와 같이 텍스트를 숨겼다가 보여줬다 하는 기능을 사용할 수 있도록 해줍니다.
tt 처럼 그냥 단순히 보였다 감췄다 정도가 아니라 애니메이션 효과까지 줄 수 있어서 상당히 멋드러집니다. 😉
url: http://082net.com/tag/wp-scripts/
url: http://082net.com/tag/aj-spoiler/
4. bad behavior
request 를 분석해서 봇이라고 생각되면 차단합니다. 적용 후 확실히 스팸이 줄었습니다. (하루 120 통 쯤에서 10통 이하.. 그나마 akismet 에 나머지는 걸립니다.)
url: http://www.homelandstupidity.us/software/bad-behavior/
조금만 부지런하면 이래저래 편리해지는 아름다운 워드프레스 세상입니다. 혹시 또 멋진 플러그인들을 알고 계신 분들은 트랙백 부탁드리겠습니다. 😉

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

컴퓨터 속의 한글

컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.
우선 한글은 조합형, 완성형, 확장 완성형, 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