유니코드와 KS X 1001의 매핑 문제
유니코드와 KS X 1001의 매핑에 관한 글을 써 보았습니다. 이미 기존 체계에 고정되 있는 이상 쉽게 변할거란 생각은 할 수 없더군요. 특히 기존 매핑을 Windows에서 쓰고 있어서 바뀔지는 모르겠어요.
어째든, 여러분은 어떻게 생각하시나요? 아래 말고도, 바꿔야 한다고 생각하는 매핑이 있다고 생각하시나요?
----------------------------------------------------
1. 들어가며
자신과는 밀접하게 관계가 없을 거라고 생각하실지도 모르겠지만, 유니코드는 최근 컴퓨터 기술과 크게 밀접해 있습니다. 윈도우즈(NT 이후)는 유니코드로 구성되면서, 일부 프로그램에서만 기존 인코딩을 사용하지요. 맥 OS X도 유니코드 기반 OS이고, 최근 배포되는 리눅스 배포판에도 유니코드를 기본으로 지원하는게 많이 있습니다.
이렇게 유니코드가 많이 사용되면서 기존 인코딩과 유니코드 인코딩과 상호 변환을 해야 하는 경우가 많이 생겨났습니다. 이러한 변환은 유니코드 컨소시엄에서 제공하는 매핑 테이블을 쉽게 할 수 있습니다만, 아무래도 일부 문자에 있어 그 대응 관계가 불명확한 것으로 보입니다.
이 글에서는 KS X 1001(이하 KS)과 유니코드의 대응 관계를 비교해 보고, 더 나은 관계를 제시하고자 합니다.
2. 문제의 원인
일반적으로 문자 집합을 만들때에는 비슷한 모양의 문자인 경우 모두 하나로 치게 됩니다. 하지만 유니코드의 경우 같은 모양이더라도 의미가 다른 경우 다른 문자로 지정해 두었습니다. -같은 경우 하이픈, 마이너스, 전각 하이픈 등이 따로 존재하며, 라틴 문자 A와 그리스 문자 Α, 키릴문자 А는 모두 문자 번호가 다릅니다.
대체적으로 KS에 속하는 문자를 쉽게 유니코드에 대응할 수 있습니다. 하지만, 위와 같이 KS 문자에 해당하는 게 유니코드에 많이 있으면, 어느 것을 택해야 할 것인지 판단하기 어렵습니다. 단, U+0001~U+0127 영역은 KS X 1003과 일대일 매핑이 되므로, KS X 1001의 매핑 대상으로 고려되지 않습니다.
유니코드 컨소시엄에 올라와 있는 CP949용 매핑 테이블은 유니코드 2.0을 기본으로 작성되었습니다. 일부 개정이 되었지만, 그것은 KS에 새로운 문자가 추가 된것을 반영한 것에 지나지 않습니다. 실제로는 KS C 5601용 매핑 테이블이 최종 작성된 95년 이후로 바뀐게 없다고 봐도 될 것 같습니다.
3. 실제 문자의 비교
a. 과도한 Fullwidth 문자와 대응
EUC-KR 인코딩을 사용할 경우 KS X 1003의 문자는 1바이트로, KS X 1001의 문자는 2바이트로 저장됩니다. 과거에는 2바이트 문자의 너비가 1바이트 문자에 정확히 두배가 되었기 때문에, 전각 반각이란 이름으로 불리게 되었습니다. 그리고 실제로 어느정도 구분하여 사용하였죠. 이를 위해 유니코드에 특별히 Fullwidth and Halfwidth Forms 영역을 두어 호환성을 유지 하였죠.
ASCII 문자 이외에도 일부 문자는 Fullwidth를 가지고 있습니다. 히지만, Fullwidth 문자가 일반 문자 만큼 널리 사용되지 않는 상황에서, 구태여 Fullwidth로 써야할 필요가 없다고 봅니다. 게다가 ASCII 문자 처럼, 굳이 전각과 반각을 구분해야 할 필요도 없지요.
1-43 “센트” 기호
U+00A2 ¢ CENT SIGN
U+FFE0 ¢ FULLWIDTH CENT
SIGN 통화의 교환을 위해선 일반 문자가 더 유용
1-44 “파운드” 기호
U+00A3 £ POUND SIGN
U+FFE1 £ FULLWIDTH POUND SIGN
SIGN 통화의 교환을 위해선 일반 문자가 더 유용
1-45 “엔” 기호
U+00A5 ¥ YEN SIGN
U+FFE1 ¥ FULLWIDTH YEN SIGN 〃
SIGN 통화의 교환을 위해선 일반 문자가 더 유용
1-94 “부정” 기호
U+00AC ¬ NOT SIGN
U+FFE2 ¬ FULLWIDTH NOT SIGN
연산자는 일반 문자가 더 유용
2-6 윗물결표 (Tilde accent)
U+02DC ˜ Α SMALL TILDE
U+FF5E ~FULLWIDTH TILDE
단순한 TILDE가 아닌 ACCENT이므로 SMALL TILDE를 사용
b. 비슷한 모양의 문자와 매핑
특별한 의미가 없이 모양만 있는 문자일 경우, 그와 유사한 것 중 가장 나은 것으로 대응 문자로 선택합니다. 때론, 이러한 문자를 선택할 때 그와 유사한 것으로 택하지 않을 수도 있습니다.
KS X 1001의 2-33 알동그라미표의 경우 U+2299 ⊙ CIRCLED DOT OPERATOR란 수학 기호에 매핑되어 있습니다. 하지만, 2-23은 단순히 빈 원 안에 채워진 원이 들어가 있는 그림일 뿐이죠. 이것과는 U+25C9 ◉ FISHEYE 가 가장 유사합니다. 이것으로, 1-61 겹동그라미가 U+229A ⊚ CIRCLED RING OPERATOR란 수학 기호가 아닌 U+25CE ◎ BULLSEYE에 매핑되어 있다는 것과도 일관성을 유지할 수 있다고 생각됩니다.
c. 유니코드에 존재하지 않는 문자의 매핑
언듯 생각해서는 유니코드가 KS X 1001을 모두 다룰 수 있을 거라고 생각하실지도 모르겠지만, 실제로는 그렇지 않습니다. 2-38 점무늬 사각형표, 2-64 번호 줄임표 (로마자), 2-72 “우편번호” 줄임표 (Zip Code)에 해당하는 문자는 유니코드에 존재하지 않습니다. 현재, 점무늬 사각형표는 U+2592 ▒ MEDIUM SHADE, 번호 줄임표 (로마자)는 U+2116 № NUMERO SIGN에 매핑되어 있습니다. “우편번호” 줄임표 (Zip Code)의 경우 KS X 1001:2002에서 추가된 것으로 유니코드(BMP)에 존재하지 않으며, 저 문자를 표현해 주는 어플리케이션도 없는 듯 합니다.
4. 참조
기존의 문자코드와 유니코드의 대응에 관한 여러 문제
JIS 기호를 UCS BMP 로 매핑하는 문제 및 MS 한자와 Shift-JIS의 차이
제가 주로 애플리케이션 통합에 관련된 일을 하고 있는데요..이러한
제가 주로 애플리케이션 통합에 관련된 일을 하고 있는데요..
이러한 문제는 유니코드와 ASCII 사이에서만 일어나는 것은 아니더군요.
EBCDIC과 ASCII, 유니코드 등 언제 이런 걸 다 만들었나 싶을 정도로
다양한 코드 체계와 그들 간의 불일치 등을 겪어 봤는데 그럴 때마다
편리를 위해 만들어 놓은 어떤 룰이 어떤 경우에는 지속적인 고통이
될 수도 있겠구나 하는 생각이 많이 들죠.
(3바이트 문자 체계를 접해보기도 했습니다. 특정 패키지에만 사용하는 것이지만..)
특히 지적하신 대로 유니코드에 없는 문자들이 좀 있어서 애를 먹었던
기억도 있습니다. ^^ 그런데 바꾸기는 쉽지 않을 듯 하네요.
북한산(X) 삼각산(O) 백운대(X) 백운봉(O)
일부 잘못된 내용이
일부 잘못된 내용이 있어서 내용을 수정합니다.
Unicode는 characters(문자)를 정의하지만, glyphs(자형)를 정의하지는 않습니다.
(자세한 정의 및 내용은 Unicode Standard 2.2 Unicode Design Priciples 또는 http://unicode.org/glossary/ 를 읽어주세요.)
Unicode Standard 15.2 Letterlike Symbols에는 "U+2116 numero sign is provided both for Cyrillic use, where it looks like №*1, and for compatibility with Asian standards, where it looks like №*2"라고 나와 있으며, 같은 책 그림 15-2에는 자주 사용되는 자형을 예시하였습니다. No.는 이 예시에 포함된 하나의 자형 일 뿐입니다. 문자의 의미로 본다면 KS X 1001의 2-64 번호 줄임표는 U+2116 numero sign과 부합한다고 봅니다.
또한“우편번호” 줄임표 (Zip Code)는 Unicode 4.1에서 U+327E CIRCLED HANGUL IEUNG U 로 추가되었습니다.