world

파이썬 euc-kr 코덱에 첫가끝 지원 추가

by

그동안 파이썬의 euc-kr 코덱에서는 KS X 1001 완성형에 들어있지
않은 글자는 그냥 에러로 처리해 왔습니다. GNU libiconv나 GNU libc를 포함한
대부분의 오픈소스 프로그램들도 그냥 완성형만 지원해 왔었는데요.
얼마전에 MSIE에서 어떤 상황에서 EUC-KR에서도 첫가끝 코드를 활용하는 사례가 보고되었고, 모질라에서도 2001년부터 이미 첫가끝을 지원하고 있었습니다.

그래서, 파이썬에서도 뭔가 그래도 부록이지만 표준 문서에 있긴 있는 내용이니 지원해야겠다 마음이 들어서, EUC-KR 코덱에 새로 구현하여 넣었습니다. 코덱 이름은 바뀌지 않고 그대로 euc_kr 이기 때문에 사용상 별로 다른 점은 없고, 완성형만 걸러내기 위한 목적으로 쓰셨던 분들은 이제부터 다른 방법을 쓰셔야 됩니다.

예를 들면 이렇게 나옵니다.

적용되는 버전은 호환성 유지를 위해 2.6 이상으로 적용됐기 때문에 앞으로 나올 2.5.2나 2.5.3 버전에는 옛날 동작 그대로 완성형 한글만 변환됩니다.

마지막으로 파이썬의 숨겨진 비밀 하나 공개해 볼까요. 🙂

파이썬 2.4 이상에는 인천여중 학생의 유명한 시(?)가 하나 숨어있습니다. -ㅇ-;; 이렇게 해 보세요.

자주 볼 수 있는 정겨운 깨진 한글들

by

오늘 IRC에서 얘기하다가 생각나서
예전부터 있었던 정겨운 깨진 한글들 패턴 몇개를 모아서 소개해 봅니다. 🙂

占쏙옙占쏙옙!

주로 맥이나 emacs, gnome-terminal등등 유니코드 처리를 하긴 하는데, 설정을 뭔가 잘못했거나 제대로 못 처리한 경우에 자주 발생하는 놈입니다. 구글에서 검색하면 무려 1450000건이나 나옵니다. -ㅇ-; 가히 깨진 한글 중 최고봉..

이 녀석의 의미는 U+FFFD U+FFFD를 utf-8로 인코딩한 것을 euc-kr로 푼 것입니다. 디코드하는 녀석은 euc-kr을 바라고 있고, 인코딩하는 녀석은 뭔가 안에서 단단히 꼬인 경우죠. U+FFFD는 REPLACEMENT CHARACTER이라고, 뭔가 잘못되면 이걸로 글자 수를 유지하기 위해서 바꾸는 경우가 있습니다. 이 경우 대부분 보내는 놈이 잘못했다고 눈치를 챌 수 있습니다.

홰聆究셀

옛날에 PC통신 하시던 분들은 자주 보셨을 것 같은데, 이것도 지금 구글에서 검색하면 29900건이 나오는 상당히 인기깨진한글 입니다. 홰영구셀은 점쏙옙과는 달리 좌우로 물음표나 좀 불길한 표시가 곁들여진다는 특징이 있죠. 🙂

이 놈의 정체는 바로 euc-kr에서 “안녕하세요”에서 첫 바이트를 떼낸 것입니다. 안녕하세요는 문자열이나 각 줄의 맨 앞에 자주 와서 앞 글자가 잘리는 경우가 유독 많죠~

컴컴컴컴컴컴넴

요새는 컴컴컴컴컴이 나오면 좀 어색하겠지만, 옛날에는 동네 꼬마아이들도 컴컴컴컴을 보면 이게 바로 그거구나! 하고 정겨워할 정도였었죠~ 컴컴컴컴컴에는 옆에 넴이나 백백백, 낡낡이 곁들여 줘야 좀 더 맛이 납니다. 이 놈의 정체는 미국 영어 코드페이지인 cp437에서 좌우로 긋는 선문자입니다. 아직도 와레즈 그룹들은 cp437을 자주 쓰는 관계로 .nfo 파일들에서 컴컴컴컴을 만날 수 있어서 나름대로(?) 반갑습니다;;

이 녀석은 구글에서 검색이 되긴 하는데, 길이에 따라 따로 따로 인덱스되어 있어서 전체적인 수는 정확히 모르겠지만 대략 5000은 될 것 같네요.

덈뀗섏꽭 쩗꿇뀘

요놈은 고정적인 내용을 가지는 것은 아니고 대충 “띠리띠리”가 새끼손가락 콧구멍에 넣고 외계와 통신할 때 내는 소리로 깨지는 형태입니다. 이것도 어설픈 유니코드 프로그램에서 상당히 자주 볼 수 있죠. 이 놈의 정체는 utf-8 인코딩된 것을 cp949로 푼 것입니다. 주로 겹자음과 희한한 받침들이 오는데, 그 이유는 utf-8에서 쓰는 영역이 주로 두 번째 바이트에 0x81~0x9f를 많이 써서, 그 영역이 cp949에서 euc-kr에 추가로 배치한 자주 안 쓰이는 한글 영역과 겹치기 때문입니다.

)C>H3gGO

이것도 고정적인 내용은 아니고 그냥 형태입니다. 주로 대문자, 소문자, 기호 몇가지가 나오고 중간 중간 음표도 곁들여 주며 나오는 이 모양은 8비트를 모두 지원하지 않는 환경에서 EUC-KR에서의 상위 비트가 모두 날아간 놈입니다. 최근에는 볼 일이 거의 없지만, 예전에는 한국IBM같이 도미노 솔루션을 쓰던 곳에서 보낸 메일이 이런식으로 안 보이게 보여서 난감한 경우가 있었죠. 그리고, ISO-2022-KR로 인코드하고 나서 제어문자 필터링에 걸려서 제어문자가 유실되는 경우도 이렇게 됩니다.

¾È³çÇϼ¼¿ä~

아마도 가장 흔하게 많이 볼 수 있는 형태가 아닌가 싶네요~ 요건 EUC-KR을 ISO-8859로 보고 디코딩했을 때 발생하는 형태입니다. 즉, 한글 1글자가 EUC-KR에서 높은 2 바이트가 되기 때문에, ISO-8859에서의 추가 문자에 해당하는 것들이 2개씩 나오게 됩니다. 요건 그래도 ISO-8859-1이 256개 모두 할당되어 있어서 정보의 손실은 없어서 복구는 가능하기 때문에, 다른 것들에 비해서 그래도 준수한 편이라고 할 수 있겠죠. 🙂

켓아~

요놈은 대부분의 글자가 보이지만 일부가 고정적으로 다른 글자로 대체되는 형태입니다. 대표적으로 “횽아” -> “켓아”와 “아햏햏” -> “아쥑쥑” 이 있죠. 둘다 구글에서 검색해 보면 용례가 그렇게 많지는 않지만, 의외로 유닉스 프로그램들에서는 상당히 자주 겪는 패턴입니다.
이 경우는 인코딩이 euc-kr이라고 가정하고, 두 번째 바이트 글자의 하위 7비트만 보고 디코딩해서 생기는 문제입니다. cp949의 경우에는 두 번째 바이트에 MSB가 없는 경우가 있기 때문에, 구분해 줘야 글자를 제대로 판단할 수 있겠죠.

우선 생각나는 것은 써 봤는데, 그 외에 자주 봤던 깨진 한글 있으시면 알려주시면 추가하겠습니다. ^_^

파이썬의 JIS Roman, KS Roman 문제에 대해

by

nohmad님께서 개멍님의 글을 알려주셔서, 일단 직접적인 관련이 있는 당사자로 해명을 해 봅니다. ^^

CP949에서 ‘\\’는 u’￦’가 되어야 하는가?

우선 개멍님의 글 안에서 말씀하셨듯이 euc-kr이나 cp949에서 ‘\\’ (즉 굴림체에서는 원화기호로 보이는 그것)가 유니코드로 u’￦’로 하는 것은 좀 곤란하지 않을까 합니다. 현재 CP949는 표준 문서가 따로 있다기 보다는 △ Microsoft 구현의 실제 동작 △ Microsoft가 Unicode Consortium에 제출한 코드 매핑 두 가지가 권위가 있는 근거로 볼 수 있습니다. 둘 다 ‘\\’에 대해서 U+5C (REVERSE SOLIDUS)로 매핑하고 있기 때문에, CP949측에서는 u’\x5c’로 하는 것이 적당하다고 생각됩니다.

EUC-KR에서 ‘\\’는 u’￦’가 되어야 하는가?

또한, EUC-KR에 대해서도 그런 매핑이 근거를 얻으려면 EUC-KR이 G0 영역(0x20-0x7f)에 KS Roman (KS X 1003)을 할당했다면 됩니다. 그렇지만, 현재 EUC-KR에 대해 권위가 있다고 판단되는 ISO측의 등록에서 G0 영역에 KS Roman이 아닌 US-ASCII를 할당하고 있기 때문에 당연히 0x5c에 대해서 U+5C를 매핑하는 것이 표준에 맞는 동작이라고 볼 수 있겠습니다. 즉, 위 두가지 상황에 대해 키보드에서 누르는 것과 화면에서 원화 기호로 보이는 것, 즉 입력기와 굴림체 글꼴의 버그라고 볼 수 있을 뿐, 인코딩 변환에 관련해서는 문제가 없습니다. 그렇지만 물론 키보드에서 원화 기호가 써 있는 키를 누른다고 해서 진짜로 ￦(WON SIGN)로 나와버리면 곤란하겠죠. 지금까지 전 국민이 U+5C를 써 왔으니..;

후에 추가: EUC-KR에 대한 표준은 찾아보니까 ISO보다는 KS X 2901이 더 권위가 있겠네요. 🙂 그 내용에 대해서는 신정식님의 메일을 참고하시면 명쾌하게 될 듯 합니다.

CJKCodecs에서 JIS 인코딩들의 같은 문제에 대해

반면 JIS 인코딩들 (SHIFT_JIS, EUC-JP)은 G0에 US-ASCII가 아니라
JIS Roman (JIS X 0201)을 할당하고 있기때문에 엔화 기호와
윗줄(OVERLINE)이 대신 변환되는 것이 옳습니다.
그렇지만, 위 글의 코멘트에서 토끼군이 답변하였듯이, 파이썬의 CJKCodecs의 2003년 말 버전에서부터 일본인 사용자들의 끈질긴 요청에 따라 기본 코덱들을 한국처럼 G0에 US-ASCII를 할당하도록
바꾸고, 대신 -strict라고 꼬리를 붙인 표준 준수 코덱들을 넣어
놓았었습니다.

그렇지만, 이것을 구현한 방식이 #ifdef를 이용해서 프리프로세싱을 2번 다르게 해서 표준/비표준 코덱을 구현한 것이다보니 파이썬에 CJKCodecs가 들어가면서 프리프로세싱을 임의로 제어하기가 힘들어져서 결국에는 -strict 코덱들이 모두 제거된 채로 들어갔고, 그로 인해서 표준을 준수하는 코덱이 빠지고, 실질적으로 일본인들이 사용하는 인코딩만 남은 것이 현재 상황입니다.

후에 추가: 일본 인코딩의 경우에도 photon님의 말씀과 다른 자료를 종합해보니, Shift_JIS나 EUC-JP모두 US-ASCII와 JIS X 0201을 어느 쪽을 써도 좋도록 하고 있다고 합니다. 따라서, 위에서 말한 엄격한 표준 준수라는 말은 모두 잘못된 표현이기에 바로잡습니다. ^^;

일본 인코딩 표준의 심각한 문제

사실 -strict 인코딩을 일본인들이 그렇게 싫어했던 이유는 한국 사람들 같이 그냥 단순히 보이는 것이 다르다 정도가 아니라, 아예 “코딩이 불가능”한 상황이었기 때문입니다. JIS Roman에서 교체하고 있는 글자가 2개가 있는데 엔화기호<->REVERSE SOLIDUS와 틸드<->OVERLINE 입니다. 그런데, REVERSE SOLIDUS같은 경우에는 굳이 쓰려면 JIS X 0208에 정의된 것을 쓰면 충분히 roundtrip도 보장되고 억지로 어찌어찌 되기는 하는데, 틸드의 경우가 심각합니다. 즉, JIS X 0208에 틸드가 없기 때문에, 결국 표준에 맞게 구현을 하다보면 SHIFT_JIS에서는 틸드를 아예 못 쓰게 되는 것입니다. 그래서 bitwise not같은 연산자로써나 “hi~~ o/~” 같은 경우에서나, 여러모로 아예 코딩이 불가능한 상황이 오게 된 것입니다. (파이썬은 2.4부터 “항상” UTF-8로 변환한 뒤에 토크나이징/컴파일을 하기 때문에 유니코드에서 뭘로 매핑되느냐가 굉장히 중요합니다.)

그래도 표준 지원..

사실 한동안 까먹고 있어서 진행이 안 되고 있었는데, 파이썬에 있는 CJKCodecs는 표준 지원을 위해서 다음 몇가지를 진행할 계획이 있습니다.

  • CNS11643 캐릭터셋 통합 (현재는 CJKCodecs에만 있음)
  • iso-2022-cn, euc-tw 지원 (CNS11643 캐릭터셋이 있어야 함)
  • 일본 MS 확장 인코딩 표준 지원 (일본 Legacy Encoding 프로젝트 작업분 통합)
  • 일본 -strict 코덱 부활
  • Big5 확장 인코딩을 변경할 수 있게 매핑 오버라이딩 지원

으흐흐. 2.6 나오기 전까지는 할 거예요 =3=3

인코딩을 모르는 문서 디코드하기

by

피드를 읽다가 BeautifulSoup 새 버전이 나왔다는 소식을 듣고, 뭐가 바뀌었는지 궁금해서
홈페이지를 가 봤습니다. 그런데, 전에 없던
cjkcodecs, iconvcodec에 대한 링크가 갑자기 생긴 것입니다.
오잉 BeautifulSoup에서 웬 cjkcodecs 링크람~ 하고 자세히 봤더니
옆에 chardet라는
인코딩을 자동으로 결정해 주는 라이브러리가 붙어있는 것입니다!

호오.. BeautifulSoup은 지금까지 취해왔던 “개떡같이 쓴 것도 찰떡같이 알아듣는다”를 충실히 지키기 위해, 이제 인코딩이 언급되어 있지 않은 문서도 마구 디코딩을 해 줄 장정인가봅니다;;

Mark Pilgrim이 만든 chardet는 작년 8월에 나온 것인데, 노가다로 일일이 디코딩해보고 결정하는 것이 아니라, 각 인코딩 별로 보통의 빈도에 대한 통계
자료를 기반으로 해서 결정한다고 합니다.
나온지는 제법 오래된 것인데, 참 신기하고 재미있네요.
이제 트랙백 받는 것도 chardet 붙여서 똑똑하게 받아 봐야겠습니다.
^.^; (통계자료는 모질라 안에 들어있는 것을 포팅한 것이라고 합니다.)

CJK 정보 위키 페이지 복구

by

예전의 OpenLook 위키에 있었던 거의 유일한 유용한 자료였던 CJK 페이지를 요즘 쓰고 있는 trac 페이지로 옮겼습니다.

여전히 덜 쓴 부분이 아직 좀 남아 있지만, 혹시 그동안 보고 싶었는데 위키에 안 올라가 있어서 못 보신 분들은 얼른 가셔서 보세용~ (언제 또 trac을 내릴지도 모르는 일 =3=3)

Internationalized Resource Identifiers

by

그동안 “URL을 항상 UTF-8로 보냄을 끄시오.” 이런 류의 불친절하고 무식하기 짝이 없는 문구를 여러 사이트에서 보아 왔습니다. 이제 더 이상 주소창에 한글을 쓰기 위해서, 최종 사용자가 인코딩을 신경써야 할 필요가 없습니다!

원래 URI에서는 US-ASCII외의 문자는 사용이 전혀 금지되어있습니다. 따라서, URI에는 한글을 못 쓰는 것이 당연한데, 이를 퍼센트 이스케이프를 사용해서 EUC-KR이나 UTF-8로 인코딩해서 보내 왔습니다. MSIE의 디폴트 옵션과, 모질라 계열 브라우저에서는 UTF-8을, Safari와 맥용 MSIE, 국내의 많은 사이트에서는 EUC-KR로 인코딩한 것을 쓰고 있어서, 사실 여러 인코딩의 난무에 제대로 보이게 해 주기가 곤란했고, 가장 심각한 경우가 블로그 trackback의 초기 스펙에서 GET으로 보내는 바람에 자기 사이트와 상대 사이트의 인코딩이 같아야만 트랙백이 깨지지 않고 보내는 문제까지도 발생했었습니다.

곧 RFC에 등록될 [WWW]draft-duerst-iri-09에서는 이 문제를 해결하기 위해서, IRI를 소개했습니다. 이 작업은 W3C의 주도로 이뤄지고 있는데, Microsoft 직원도 공동 저자로 표기되어있는 걸로 봐서 MSIE에서도 곧 지원하지 않을까 합니다. (물론 CSSv3같이 자기가 만들고 자기가 지원 안하는 경우가 있을지도 모르겠지만 –;)

IRI에서는 그냥 인코딩을 UTF-8로 쓰는 것이나 사실 비슷하긴 한데, 오른쪽에서 왼쪽으로 쓰는 언어를 위한 BiDi 지원에 대한 고려를 좀 추가하였고, 정규화를 NKFC또는 NFC로 명시해서 웹서버를 좀 더 편하게 해 주고 있습니다. 단, IRI는 URI를 기존에 쓰던 위치에서는 그대로 못 쓴다고 명시를 하고 있는데요. 즉, 아직 “URI”를 쓴다고 표시하고 있는 표준에 대해서는 그 위치에 IRI를 바로 쓰는 것이 아니라 IRI를 URI로 변환한 다음에 쓰도록 하고 있습니다. 하지만, IRI를 URI로 변환하면 사실상 정규화와 BiDi를 제외하고는 거의 그냥 UTF-8에 퍼센트 인코딩만 추가한 것이나 비슷한데, “항상 UTF-8로 URL을 보냄을 끄시오.”하는 우리나라 웹 실정과 맞을 지는 의문입니다. –;;

파이썬의 urllib{,2}에서도 draft-duerst-iri-09가 RFC에 등록되자 마자 바로 지원을 할 예정입니다.

Rune Locale의 UTF-8 로캘에서의 문제점

by

며칠 전에 NBSP가 space인가 아닌가에 대해서 얘기를 좀 했었는데, 이 문제가 아무래도 불거지게 된 것은 BSD Rune Locale의 isctype 함수들의 특성 때문이었습니다. BSD Rune은 4.4BSD 시절에 생겨난 것으로, POSIX Locale가 만들어지기 이전부터 디자인된 멀티바이트 캐릭터셋 API이기 때문에, 그 이후 POSIX Locale 스펙과 맞지 않는 점이 있습니다. 바로, POSIX에서는 isspace, isalpha같은 ctype함수들을 싱글 바이트로 표현할 수 있는 코드포인트들로 제한을 하고 있지만, Rune에서는 iswctype이 도입된지도 얼마 되지 않았고 그냥 isctype 함수들이 wide character 코드포인트까지 모두 담당해버려서 결국 UTF-8 로캘같이 전체가 하나의 캐릭터셋이라서 싱글 바이트의 경우와 wide character가 겹쳐버리는 경우 잘못된 답이 나와버리는 것입니다.

구현

isspace(0xa0)

iswspace(0xa0)

isalpha(0xc0)

iswspace(0xc0)

BSD Rune

true

true

true

true

glibc

false

false

false

true

Solaris

false

true

false

true

올바른 답(POSIX/Unicode)

false

true

false

true

그래서 Tim에게 메일을 보냈더니 Rune과의 하위호환성을 5.x까지는 유지하겠다고 manpage에 써 놓아서 우선 바꾸지는 못 하지만, 6.x에서 고칠 수 있겠다는군요.. 그리고 manpage에 언급을 넣어 줘서 COMPATIBILITY에 이제 isctype에서 와이드 캐릭터 전영역을 커버하지 않도록 곧 수정될 수도 있다는 경고가 붙게 되었습니다. 그러면서 우선 버그를 피해갈 수 있는 방법을 하나 알려줬는데.. 이렇게 합니다 ;;

흐흐;; 우선 파이썬 포트와 파이썬 2.4 트렁크에 해당 패치를 넣으려고 합니다.

NBSP는 스페이스인가 아닌가!

by

FreeBSD의 파이썬에서 UTF-8로 로캘을 설정하고 나서, str.split()을 하면 0xa0이 중간에 끼여 들어가 있으면 막 글자 중간에서 짤려서 결국은 invalid seq를 생성해내는 문제가 있습니다.

리눅스에서 테스트를 해 보면 제대로 나오는게 자세히 보니까 이런 리눅스에서는 isspace(0xa0)이 0이군요.. BSD에서는 ISO8859-1과 UTF-8 로캘 모두 1이 나오고..

그런데, 또 재미있는 것은 파이썬에서는 \u00a0이 space입니다 –;

BSD와 마찬가지로 UnicodeData.txt에서 그대로 생성했기 때문에 그런 것인데.. 과연 NBSP가 스페이스는 스페이스니까 스페이스로 인정을 할 것인지.. 브레이크 없는 스페이스니까 스페이스가 아니라고 해야할 것인지 생각을 하면 할 수록 헷갈리는데 우에에.. 분명히 파이썬과 BSD의 locale 중의 하나를 고쳐야할 터인데 뭘 고쳐야할 지 모르겠군요. –; SUS는 봐도 도움도 안되게 간략하게 나와있고..

(소식: 오늘 ftp.unicode.org 를 둘러보다보니 Unicode 4.1이 슬슬 올라오고 있네요.)

CJKCodecs 1.1 진행상황

by

파이썬 2.4a1 릴리스에 반영될 버전인 CJKCodecs 1.1 작업을 띄엄띄엄 생각나면 하고 있습니다. 흐흐. (이제 마비노기도 가입했으니 언제 끝날지는 –;; )

CJKCodecs 1.1에서는 당초 JIS X 0213:2004 지원만 넣으려던 계획에서 좀 확장을 해서, CNS 11643 1번 평면부터 7번 평면까지를 모두 넣어서 EUC-TW와 ISO-2022-CN을 지원하고, 홍콩자치구의 BIG5HKSCS를 지원할 예정입니다. 지금 CNS11643, HKSCS 매핑과 EUC-TW, BIG5HKSCS 인코딩 구현은 모두 끝났고, ISO-2022-CN와 JIS X 0213:2004는 아직 구현이 안 됐습니다. CNS11643 매핑은 소스 파일이 총 920KB이고 바이너리로 340KB인데.. 이건 CJKCodecs의 대만을 제외한 다른 한,중,일 3개국 매핑을 모두 합친 것보다 많은 것이라, 이제 앞으로 대만 사람들을 보면 눈을 한번쯤 흘겨줄 겁니다. HKSCS는 BIG5에 그냥 덧씌운 캐릭터셋인데, 일부 C6~C8까지는 BIG5와 겹치기도 합니다. 요건 매핑 소스가 140KB, 바이너리가 80KB정도 나와서 홍콩에는 계속 좋은 감정을 가질 수 있게 되었습니다. ;; (앞으로 혹시나 홍콩할매귀신을 만나서 “왜 CJKCodecs에서 HKSCS지원 안 해주는 거야 으흐흐흐~~ 잡아먹을테다~~”하는 상황을 피하게 돼서 다행입니다;;)

이번에 정리 작업을 하면서 전에 올렸던 글에서 처럼 바이너리를 정리했는데, 그 뿐만 아니라, 아예 코덱 파일을 모두 나라별로 1개씩으로 합쳐버렸고, ISO-2022도 각 나라별 모듈에서 따로 떼내어서, 기존에 500라인짜리 매크로 파일로 떡칠이 되어있던 소스를 간편한 함수 포인터 기반 소스로 바꾸었습니다. 아주 상쾌합니다. 이히히 :) 결과적으로 파일 개수가 1.0.3에 비해 1/3로 줄었습니다.

그러나, HKSCS와 CNS11643 매핑의 등장으로 타볼 용량은 상당히 늘었는데, tar.bz2가 예전엔 400KB정도였는데 이제는 780KB입니다. 아무래도 이렇게 갑자기 불면 미국애들 눈치를 많이 봐야하기때매.. 파이썬에 넣을 때는 CNS11643매핑은 빼고 넣으려고 생각하고 있습니다. 구글에서 검색해봐도 파이썬에서 euc-tw 안 된다고 투덜대는 사람이 없는 걸로 봐서는 필요도 없는데 괜히 수백KB 덧붙이면서 싸울 필요는 없을 것 같아서 ^^;;

JIS X 0213:2004 개정판

by

최근에 CJKCodecs에서 JIS X 0213:2004를 언제 지원할 거냐는 메일을 받았습니다. 그래서, 정보를 찾아 봤더니, 원래 CJKCodecs에서 쓰던 JIS X 0213:2000이후에 2004년 2월에 개정판이 나왔네요.

주로 바뀐 점은, 한자 1개, 비한자 2개가 유니코드 매핑이 바뀌었고, 기존에 두글자 매핑이 안 되어 있던 25개의 유니코드 조합 도형이 이제 매핑이 표준화가 되었습니다. 그리고, 인코딩도 바뀌었는데, 기존에 shift-jisx0213 euc-jisx0213 iso-2022-jp-3 같은 그나마 정상적인 이름을 써 왔는데, JIS X 0213:2004에서는 헉… shift-jis-2004 euc-jis-2004 iso-2022-jp-2004 라고 합니다. 이런 엽기적인 -_- 그동안 CJKCodecs는 1 C모듈 대 1 파이썬 모듈을 원칙으로 하고 있었는데, 계속 이런식으로 가다가는 인코딩이 늘어서 도저히 감당을 못할 것 같아서, 이제 JIS X 0213지원을 위해서라도 한 C 모듈에서 여러 개의 코덱을 지원할 수 있도록 해야될 판입니다. ㅡ.ㅜ

한자 적은 우리나라 만세~ ..;;