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
어흐흐흐 EUC-KR에는 \x5c가 U+005C로 매핑되어야 한다는 건 처음 알았네요. 관련 문서를 대강 대강 보다 보니 아마 원화로 배당되어 있는 거 아닌가 생각하고 있었는데… 제 실수입니다 🙂
너무 수고가 많으세요~~
친절한 설명 감사합니다.
근데 키보드와 폰트의 “버그” 는, 정부 납품을 위해선 KS X 1003 을 따라야 하니 그렇게 된거 아닐까요. dual standard 의 폐해라고 생각합니다.
See also http://faq.ktug.or.kr/faq/EUC-KR
한글 윈도의 원화기호에 대한 그 코드값이 0x5c이니 윈도에서는 우릴 눈속임한거죠. 비밀은 글꼴안에 있던 것이고요 :>
그나저나.. 개멍님은 한텀 개발자셨던 분 아니신지?
Windows에 기본으로 들어 있는 한국어 글꼴과 일본어 글꼴의 U 005C 자리에 원화 기호와 엔화 기호가 들어 있는 건 정말 짜증나는 일입니다. 유니코드 리스트에서 몇 번 얘기가 나왔고, MS 엔지니어에게 몇 번이나 얘기를 했지만 (이런 문제를 너무나 잘 알고 있을만한 얘기가 통한다고 볼 수 있는 사람들), 변화가 없군요.
키보드 문제도 충분히 해결 가능합니다. 자세한 것은 아래 주소에 있는 메일을 보세요.
url에 넣을까 고민하다가 그냥 여기에 씁니다. id는 ‘unicode-ml’이고, 암호는 ‘unicode’입니다.
http://www.unicode.org/mail-arch/unicode-ml/y2002-m10/0340.html
EUC-JP에서도 G0에 항상 JIS X 0201의 “왼쪽 절반”만 쓰이는 게 ‘엄격한’ 표준이라는 근거가 무엇인지 궁금하군요. KS X 2901에 대응하는 일본 표준에서 그렇게 규정했나요?
ISO 2022 coded character registry에 JIS X 0201의 ‘왼쪽 절반'(구 JIS C 6220-1969)을 ISO 646의 일본판으로 등록[1]했다는 것만으로는 그렇게 얘기하기 힘들 것 같은데요. 더구나, IANA에 등록된 EUC-JP에서는 US-ASCII를 G0로 해 놓았습니다. [2] ISO-2022-JP에서는 물론 US-ASCII와 JIS X 0201의 왼쪽 절반을 따로 쓸 수 있으니까 이런 문제가 없고요.
Shift_JIS도 US-ASCII가 아닌 JIS Roman을 쓰는 것*만*이 표준이란 근거를 정확히 알고 싶군요. JIS X 0208:1997에서 Shift_JIS를 공식적으로 규정(그 이전에는 그냥 MS가 만들어서 쓰고 있었고)했다고 하던데, 거기에서 JIS X 0201의 왼쪽 절반만 쓴다고 명시했나요?
개멍님이 얘기한 ‘글꼴’에서 KS X 1003 준수 문제: MS에서 Open type 글꼴 개발팀을 맡고 있는 듯이 보이는 Paul Nelson이 유니코드 리스트에서 비슷끄레마하게 ‘변명’을 했는데 (자기 생각이 아니라 내부의 다른 사람에게 물어 보고 중계한 것임), 별로 설득력이 없습니다. MS가 공급하는 truetype 글꼴에 들어 있는 **Unicode** cmap 테이블의 *U 005C* 위치에 원화 기호에 대응하는 glyph id를 대응시켜 놓은 것은 KS X 1003과 아무런 관계가 없으니까요. 오히려, KS X 1005 (ISO 10646)을 위반한 셈입니다. 키보드 입력은 위에 적어 놓은 유니코드 리스트의 글을 보세요. Windows 98의 지원을 중단하고, Vista를 내놓는 이 시점(즉, 이제 MS가 지원하는 모든 OS는 ‘구식 인코딩’이 아니라 유니코드/ISO 10646/KS X 1005 기반인 셈이 되는 시점)에서야 말로 과거와 과감한 단절을 해야 할 때입니다. 그럼에도 불구하고, MS는 계속 ‘가짜 유니코드 글꼴’을 Vista에도 (확인 안 해 보았지만, 거의 확실히)
배포하고 있으니 짜증납니다.
[1] http://www.itscj.ipsj.or.jp/ISO-IR/014.pdf
[2] http://www.itscj.ipsj.or.jp/ISO-IR/014.pdf
IANA registry에서 Shift_JIS 부분에서는 JIS X 0208:1997 부속서 1을 근거로 CCS가 JIS X 0201과 JIS X 0208이라고 해 놓았군요. 그렇다면(JIS X 0208:1997 부속서 1에서 정말 그렇게 규정해 놓았다면), Shift_JIS는 JIS X 0201의 왼쪽 절반을 US-ASCII 대신 쓰는 게 ‘엄밀하게 말하면’ 표준 준수라고 할 수 있겠군요. 하지만, JIS X 0208:1997에서 공식적으로 규정하기 훨씬 전부터 Shift_JIS가 널리 쓰였고 (Windows, Mac OS, AIX, HP/UX 등에서), 그때는 대부분 US-ASCII로 생각하고 썼음을 감안하면 현실적으로 US-ASCII로 간주해서 처리- 현재 Python에서 하듯이-해야 할 것입니다.
아.. EUC-JP의 경우 제가 최초로 참고해서 만들었던 것이 GNU libiconv와 FreeBSD iconv인데, 거기서 모두 JIS-Roman을 택하고 있고, 일본인 개발자들에게 물어본 결과 emacs에서 -strict 인코딩으로 JIS-Roman을 지정하고 있지만 실제로는 그렇게 쓰지 않는다는 얘기를 들어서 그렇게 알고 있었는데, 방금 CJKV Information Processing을 찾아보니 둘 다 지정하고 있군요. 그렇다면, 일본어 인코딩에서도 REVERSE SOLIDUS와 TILDE가 제자리에 있는 지금 형태를 그대로 표준으로 쓸 수 있을 것 같아서 무척 다행입니다.
Shift_JIS의 경우에도 마찬가지로 동일한 방법으로 JIS X 0201을 쓰고 있다고 생각을 하고 있었는데, 마찬가지로 CJKV Information Processing에서는 US-ASCII or JIS-Roman이라고 하고 있네요.
일본어 인코딩들의 경우에는 표준 문서들에서는 이것 저것 다르게 표현하고 있지만, 사실상 일본인 개발자들 대부분이 US-ASCII를 할당해서 쓰는 것을 선호하는 걸 보면, JIS-Roman을 지정하고 있는 표준이 아직 있더라고 해도, 별로 권위가 있어 보이지는 않는 것 같습니다. 그렇다면 -strict 인코딩으로 추가하는 것은 조금 더 현실적인 고려를 해 봐야겠네요. (실제 그들이 원하는 MS확장 매핑을 넣어주는 것에 집중하는 쪽으로..)
CJKV I.P에서는 물론 둘다 가능하다고 써 놓았음을 저도 잘 알고 있지요. 혹시나 해서, 앞글 올리기 전에도 확인해 보았어요. 🙂 ‘-strict’라는 이름을 붙이셨기에 일본어 개발자들이 Ken Lunde가 보지 못한(그는 일본어를 잘 알기 때문에 JIS 표준 문서들도 모두 다 보았을 것임에 틀림 없지만. 사실은 제가 가지고 있는 한국어 표준 문서도 그가 주었습니다.) 표준 문서를 근거로 얘기를 하지 않았나 해서 질문을 드렸습니다.
GNU libiconv/glibc는 왕복 변환이 가능하지 않게 만들어 두었을 텐데요. (몇 번 ‘논의’ 끝에. 한국어 인코딩도 비슷하게 된 때가 있었는데, 결국 현재처럼 하자는 주장이 강해서 지금처럼 되었고요.) Unicode에서 EUC-JP로 갈 때에는 U+005C와 U+00A5를 모두 0x5c로 변환하고, 반대 방향에서는 항상 0x5c를 U+005C로 변환합니다. 반면에 Shift_JIS에서 유니코드로 갈 때에는 0x5c를 항상 U+00A5로 바꿉니다.
‘물결표/틸더’는 기억이 가물가물하고 확인하기도 귀찮아서 그냥….