apache: mod_autoindex hack!!

예전에 써놓은 글에서 구상해뒀던 것들을 전부 패치에 반영시켜버렸습니다… 예전 hack 은 정말 quick & dirty 가 무엇인지를 보여주는 진정한 HACK!! 이었는데… 요번 패치는 옵션에 크게 영향을 받지도 않고, 사용자가 설정할 건덕지가 많아졌다는 점에서 개인적으로 흐뭇합니다…

  1. CSSFile 옵션을 통해 css 파일 지정이 가능
  2. Encoding 옵션으로 meta 데이타로 charset 지정 가능
  3. html 소스를 아주 간단하게 변환
  4. XHTML 1.0 Strict!! (validation 도 통과-_-v)

뭐 이정도를 한 건데… 예전 핵은 정말 너무 지저분하길래 -_-;; 아예 첨부터 작업했습니다. 기본 mod_autoindex에서는 pre~/pre 로 열맞춤을 하고 있는데, 프레젠테이션을 CSS로 바꾸기가 쉽지 않을 것 같아서 table 기반으로 만들었습니다.
그리고 xhtml validation을 위해 모든 태그들을 소문자로 바꿔줬습니다.
패치 파일은 아래서 받을 수 있습니다…
For apache-1.x
http://mytears.org/resources/mysrc/c/patches/mod_autoindexhack-20050816.diff
For apache-2.x
http://mytears.org/resources/mysrc/c/patches/apache2-mod_autoindex-hack-20070922.diff
테스트 페이지는 여기…
http://mytears.org/resources/
ChangeLog:
2007년 9월 22일 – apache2 용 패치 생성

Sender Policy Framework

planet.findout.or.kr 이라던가 기타 여러 곳에서 spf 에 관련된 내용을 듣다가 spf filter 를 붙이면 얼마나 효과가 있을지 궁금해지길래 postfix 에 spf 패치를 해봤습니다. 정상적으로 spf 인증을 통과한 메일헤더에는 pass 했다는 표시가 붙고, 네임서버가 spf 를 지원하지 않는 곳이라면 none, 실패했을 경우엔 spf 정책에 따라 fail 이나 softfail 이라는 에러코드가 붙게 됩니다.
spf 는 Sender Policy Framework 의 약자로 메일에 붙은 return address 를 이용 메일이 인증받은 메일 서버를 통해 발송되었는지를 체크하는 방식입니다. dns(송신 측) 와 smtp server(수신 측) 모두 spf 를 지원하는 경우에 사용할 수 있습니다. (생각해보면 smtp server 대신 mta 에서 지원해도 안될 건 없을거라고 생각합니다.)

SPF makes it easy for a domain, whether it’s an ISP, a business, a school or a vanity domain, to say, “I only send mail from these machines. If any other machine claims that I’m sending mail from there, they’re lying.”

spf 의 원리를 아주 간단하게 표현해 놨길래 인용해봅니다… “난 이 메일서버를 통해서만 메일을 보내니까 만약 다른 메일 서버를 통해 이 메일주소로 메일이 온다면 그건 허위 메일이야!!” 뭐 이 정도로 이해하면 되겠습니다.
아래에 quote 된 결과와 같이, 2006년 9월 24일 현재 대부분의 이메일 서비스에서 spf 를 지원하고 있는 것을 확인할 수 있습니다. 다만 sk telecom 의 경우 이메일 고지서의 return address 가 emailadmin@emailrms.sktelecom.com 로 명시되어 있기 때문에 이메일 고지서는 spf 의 영향을 받지 않아 약간 아쉬움이 남네요. (사실 sk 에 아쉬운 부분은 그것 만이 아니죠. 괜히 ‘ass k’ 라고 부르는 게 아닙니다.)
yahoo 에서 spf 를 지원 안한다는 점 또한 무척이나 아쉬운 부분 중 하나입니다.
[spoiler ‘apblind”결과보기”결과 감추기’]

aqua@Macintosh aqua $ nslookup
> set q=txt
> unfix.net
unfix.net text = “v=spf1 a mx ptr ~all”
> dreamwiz.com
dreamwiz.com text = “v=spf1 ip4:211.39.128.0/24 ip4:211.39.129.0/24 ip4:222.122.42.0/25 ~all”
> korea.com
korea.com text = “v=spf1 mx ip4:211.49.224.0/24 ip4:211.109.1.0/24 ip4:211.49.227.32 ip4:211.49.227.33 ~all”
> hanmail.net
hanmail.net text = “v=spf1 ip4:211.43.197.0/24 ptr ~all”
> hotmail.com
hotmail.com text = “v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all”
> gmail.com
gmail.com text = “v=spf1 redirect=_spf.google.com”
> _spf.google.com
_spf.google.com text = “v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all”
> nate.com
nate.com text = “v=spf1 ip4:203.226.253.0/24 ip4:203.226.255.0/24 ~all”
> naver.com
naver.com text = “v=spf1 ip4:220.95.234.208 ip4:61.74.70.0/23 ip4:222.122.16.0/24 ip4:220.73.156.0/24 ip4:211.218.150.0/24 ip4:211.218.151.0/24 ip4:211.218.152.0/24 ip4:218.145.30.0/24 ip4:220.95.237.0/24 ~all”
> msn.co.kr
*** Can’t find msn.co.kr: No answer
> msn.com
msn.com text = “v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all”
> yahoo.com
*** Can’t find yahoo.com: No answer
> yahoo.co.kr
*** Can’t find yahoo.co.kr: No answer
> hitel.net
hitel.net text = “v=spf1 ip4:211.41.82.0/24 a mx ptr ~all”
> sktelecom.com
sktelecom.com text = “v=spf1 ip4:203.236.1.100 -all”
> emailrms.sktelecom.com
*** Can’t find emailrms.sktelecom.com: No answer

[/spoiler]
이번엔 대학 메일 서비스의 경우를 살펴보겠습니다. 결과부터 말하자면 아주 실망스럽습니다. 제가 테스트 해본 대학들의 경우 전부 spf 를 지원하지 않네요.
[spoiler ‘apblind”결과 보기”결과 감추기’]

aqua@Macintosh aqua $ nslookup
> set q=txt
> hongik.ac.kr
*** Can’t find hongik.ac.kr: No answer
> wow.hongik.ac.kr
*** Can’t find wow.hongik.ac.kr: No answer
> korea.ac.kr
*** Can’t find korea.ac.kr: No answer
> snu.ac.kr
*** Can’t find snu.ac.kr: No answer
> yonsei.ac.kr
*** Can’t find yonsei.ac.kr: No answer
> hanyang.ac.kr
*** Can’t find hanyang.ac.kr: No answer

[/spoiler]
spf 를 지원하기 위해선 네임서버의 zone 파일에 “IN TXT “v=spf1 a mx ptr ~all” 정도의 룰을 삽입하면 되며, 룰은 아래의 링크를 이용하면 쉽게 만들 수 있습니다.
http://www.openspf.org/wizard.html?mydomain=&x=21&y=7
p.s) 국내 포털이 spf 를 지원하기 시작한 이후로 스팸의 70% 이상은 spf 로 걸러낼 수 있게 되었습니다.

웹서비스와 utf-8

한국의 웹사이트들을 돌아다니다 보면 “파일이 보이지 않는 경우 ‘URL 을 항상 UTF-8 로 보냄’ 옵션을 꺼주시기 바랍니다.” 라는 메시지를 쉽게 볼 수 있다. 하지만 소위 웹프로그래머라는 사람들 중 저런 문제가 생기는 이유에 대해 관심 있는 사람들은 별로 없는 듯 싶다.

URIs
Internationalization of URIs is important because URIs may contain all kinds of information from all kinds of protocols or formats that use characters beyond ASCII. The URI syntax defined in RFC 2396 currently only allows as subset of ASCII, about 60 characters. It also defines a way to encode arbitrary bytes into URI characters: a % followed by two hexadecimal digits (%HH-escaping). However, for historical reasons, it does not define how arbitrary characters are encoded into bytes before using %HH-escaping.
Among various solutions discussed a few years ago, the use of UTF-8 as the preferred character encoding for URIs was judged best. This is in line with the IRI-to-URI conversion, which uses encoding as UTF-8 and then escaping with %hh:
Guidelines for new URL Schemes, RFC 2718, proposes to base URIs on UTF-8 unless there is some compelling reason for a particular scheme to do otherwise.
URI schemes or components already based on UTF-8:
URN syntax : RFC 2141 (syntactically, URNs look like a URI scheme, but semantically, they are not)
IMAP: RFC 2192 (the IMAP protocol uses a modified version of UTF-7, but its URIs use UTF-8)
FTP ( RFC 2640 uses UTF-8, but tolerates legacy encodings)
XPointer (W3C Working Draft)
From: http://www.w3.org/International/O-URL-and-ident

위에서 보다시피 RFC2718 에서는 URL 을 UTF-8 로 보내라고 제안하고 있으며, FTP 관련해서는 RFC2640 에서 path name 을 UTF-8 로 넘겨주라고 되어 있다. 그러므로 Internet Explore 에서 ‘URL 을 항상 UTF-8 로 보냄’ 을 해제시키는 것은 올바른 해결법이 아니라고 생각된다.
현재 까지의 대부분의 ftp client 에서 i18n 관련해서 별다른 고려를 하지 않고 있었기 때문에 path name 을 client 의 legacy charset 을 이용해서 넘겨주도록 구현되어 있다. 그렇기 때문에 (한글 기준으로) euc-kr 로 된 path name 이 사용되어 왔고 결국 server 측에도 euc-kr 로 저장되고 있는 실정이다.
그런 상황이다 보니 위의 권고안 대로 URL 을 UTF-8 로 넘겨주는 경우 실제 파일을 찾지 못하고 ‘404 Page Not Found’ 를 만나게 될 수 밖에 없는 것이다.
해결책은 간단하다고 생각한다. RFC2640 이 구현된 FTP server/client 를 사용하게 될 경우 자동으로 path name 에 UTF-8 을 사용하게 되므로 server 측에서 path name 에 별다른 조작을 가하지 않는 이상 filename 에 UTF-8 로 사용하게 될테고… 결국 UTF-8 로 된 URL 을 아무 문제없이 파일을 처리할 수 있게 된다.
얼른 이런 것들이 흥보가 되고 널리 쓰이게 되서 ‘URL 을 항상 UTF-8 로 보냄’ 을 체크해제 하라는 말을 안볼 수 있는 세상이 왔음 좋겠다 -_-;;
p.s) 현재 RFC2640 이 구현되어 있는 건 filezilla 밖에 모르겠네요. proftpd 의 경우 1.3.1rc 버젼부터 rfc2640 을 지원합니다.

이미지만으로 도배된 스팸

스팸들을 보다보면.. 내용은 하나도 없이 이미지 만으로 혹은 첨부파일 하나 딸랑 오는 메일들이 상당히 많다. 당연히 이미지 안에 내용을 전부 넣어버리기 때문에 필터링할만한 문자열이 아예 없다 -_-!! 그래서 생각인데 tag 를 깨끗이 비워버리고 trim 을 해보면 이런 메일들을 쉽게 거를 수 있지 않을까 싶다.

  1. title,style,script,object ~ /title,style,script,object 를 제거..
  2. 나머지 태그들을 깨끗이 제거!!
  3. trim

이 정도로만 해도 이미지로 도배된 스팸들은 다 거를 수 있지 않을까 싶은데… 뭐 역시나 귀차니즘이 문제 (어제 12시에 자러간 이후 지금까지 내 메일계정으로 온 스팸 중엔 스팸필터를 통과한 게 하나도 없다.. 친구껄로 온건 몇 개 있는거 같지만 -_-!!)
또한 본문을 seperator 기준으로 잘라서 토큰으로 만든 후… 영어로만 이루어진 토큰에 한해 spellcheck (aspell 같은걸 쓰면 되니까) 를 하고, spell 에 맞지 않는 것들의 수가 일정 % 이상이라면 스팸이라고 판단하는 방식도 유용하지 않을까 싶다.

스팸과의 전쟁 -_-!!

우선 게시판 스팸은 회원제로 바꿔버리면 반 이상은 해결할 수 있을거 같으니 제껴두고, procmail 룰 강화로 인해 필터링되지 않아야 할 메일이 필터링 되는 일이 있는지 체크할 겸 해서 로그를 남겨 지켜보는 중인데.. “광고” 라는 문구를 넣으면서도 필터링에서 피하기 위해 노력한 흔적들이 상당히 많이 보인다 -_-!!

  • 제목에 “(광고)” 란 단어를 넣긴 했지만.. base64 로 인코딩해서 보냄
  • 역시 제목에 “(광고)”란 단어를 넣긴 했지만.. quoted print 로 인코딩해서 보냄
  • &#unicode;&#unicode; 식의 방식을 사용.. “(광고)” 를 표현..

그 중 2번째와 세번째 같은 경우는 아예 인코딩된 글자 자체를 필터에 추가시키면 완벽하게 차단이 가능하지만, 문제는 첫번째 방식! base64 인코딩의 경우 7bit 단위로 잘라서.. 테이블을 이용 변환시켜버리기 때문에 “(광고)”라는 글자가 나오는 위치에 따라 결과가 많이 달라지기 때문에.. 필터링 못하는 경우도 생길 듯 하다.. base64 나 qprint 로 인코딩되서 오는 경우엔.. 오히려 어떤 charset 으로 표현된 글자인지를 알 수 있는 장점이 있으므로.. 저렇게 인코딩 해서 보내는게 나쁜건 아니지만.. 뭐 하튼 그렇다는 얘기…
최적의 솔루션이라면 디코딩을 한 후 유니코드로 변환해서 문자열 필터를 통과시키는 방법이겠지만.. 그럴려면 간단한 프로그램을 새로 짜야 하기 때문에, 귀찮은게지 -_-;; 또 제목이 전혀 인코딩되서 오지 않은 경우엔 어떤 언어인지 모르기 때문에 유니코드로 변환하는 도중에 예외 상황이 만들어지는 것도 문제고.. (사실 대강 끼워맞추기로 해결은 가능하지만)
[spoiler ‘simple”그동안의 성과 보기”숨기기’]

unfix skel # cat /var/log/procmail.log |grep ^[Adv|wc -l
429
unfix skel # cat /var/log/procmail.log |grep ^[Fake|wc -l
1561
unfix skel # cat /var/log/procmail.log |grep ^[Spam|wc -l
unfix skel # cat /var/log/procmail.log |grep ^[Viagra|wc -l
1
unfix skel # cat /var/log/procmail.log |grep ^[Virus|wc -l
2
unfix skel # cat /var/log/procmail.log |grep ^[Empty|wc -l
27
unfix skel # cat /var/log/procmail.log |grep ^[Bad|wc -l
127
unfix skel # cat /var/log/procmail.log |grep ^From|wc -l
493

[/spoiler]
지금까지의 작은 노력만으로도 결과는 만족스럽다는 사실 🙂

유용한 procmail 용 rule!!

procmail 관련 해서 검색을 하던 중 아래와 같은 글을 발견했다. 내 스팸 함에 들어있는 메일들과 정상적인 메일들을 대강 훑어보았더니 저 룰만 가지고도 꽤 많은 스팸을 차단 할 수 있겠다는 생각이 들었다.
http://www.itinside.net/tips/045.html
multipart/alternative 방식은 text/plain 과 text/html 이 두 가지를 모두 가지고 있는 방식인데, 스팸 메일러에서 multipart/alternative 라고 선언을 해놓고 text/plain 혹은 text/html 둘 중 한 가지 만을 가지는 요상한 메일들을 보내는 경우가 많다는 점을 이용하는 것! 정상적인 mta 를 사용해서 보낼 경우 저런 잘못된 형식의 메일은 존재하지 않을 것이기 때문에 그냥 스팸이라고 간주해도 문제가 없을 것 같다.
(둘 중 하나만 집어 넣을거면 처음부터 text/plain, text/html 로 해서 보내면 된다. 첨부파일이 있다면 multipart/alternative 가 아닌 multipart/mixed 를 사용해야 하고…)
바로 적용시켜놔봤는데 결과가 어떨지는 자고 일어나 보면 알 수 있지 않을지 😉
p.s) 원본 사이트가 없어져서 rule 을 quote 해놓습니다. 링크도 webarchive 쪽으로…

# This anti-fake method is to detect the format is incorrect.
:0 HB
* ^Content-Type: *multipart/alternative
* !^Content-Type: *text/plain
{
LOG = “[Fake] ”
:0
/dev/null
}
:0 EHB
* ^Content-Type: *multipart/alternative
* !^Content-Type: *text/html
{
LOG = “[Fake] ”
:0
/dev/null
}

컴퓨터 속의 한글

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

오픈 클립아트

Inkscape 의 개발자 분이 만든 사이트 .. 지속적으로 꾸준히 업데이트가 되고 있는 듯 싶다.. 꽤 퀄리티 높은 clipart들도 올라온다.. 특히 Etiquette Icon 테마에 쓰일 아이콘들이나.. Animal 섹션에 있는 것들은 정말 맘에 든다 🙂
얼른 Etiquette Icon 이.. 많아져서.. 모든 Mime-Type을 커버해내고 -_-!! 내가 쓰는 모든 Apps들을 커버해줬음 하는 작은 바램이 있다.. 흐흐.. 같은 값이면 다홍치마라고.. 그런 세상이 오면 리눅스 쓰는 사람들이 좀 더 늘지도 모르겠다..
관심있는 사람들은 한번 구경해보시길 .. 품질 좋은 svg 포멧의 클립아트가 캬캬..
http://openclipart.org/