han.comp.lang.java 뉴스 그룹에서 퍼온 답변.

[ 다음 글들 ] [ 이어서 글올리기(답하기) ] [ 자바 묻고 답하기 ]

글쓴이 :김덕태 1998년 5월 04일 18:11:14

In Reply to: JDK 1.1, 1.2의 한글 관련 인코딩과 기타 posted by 김덕태 on 1998년 4월 22일 16:13:34:

In <353D9891.346FBCF7@calab.kaist.ac.kr>, Deogtae Kim wrote:
: Jungshik Shin wrote:


:> 염려하신대로 JDK 1.1.5에서 확인해 본 결과 상당히 문제가 많은 것을 알
:> 수 있었습니다. Sun이 Cp949(UHC/통합 완성형)을 무엇을 보고 구현했는지
:> 모르겠지만(
:>
:> 에 가면 Cp949 <-> UCS-2 변환 표가 있습니다), UCS-2에서 Cp949로 바꾸는
:> 과정에서 KS C 5601-1987에서 정의하지 않은 글자에 대한 변환이 엉망입니다.


여러 가지 시험을 해 주시고 좋은 정보를 올려 주셔서 감사 드립니다.



: JDK 1.2beta3에서 지원되는 한글 관련 인코딩
: ==========================================



: // 한국 문자 인코딩


: "EUC_KR", // Korean, KS C 5601-1987, EUC Encoding
: /* alias: */ "euc-kr", "euckr", "KSC5601", "ksc_5601",
: /* alias: */ "ksc5601_1987", "ks_c_5601-1987", "ksc5601-1987",


: "Cp949", "Cp949C", // Korean, PC


: "Johab", // KS C 5601-1992, Microsoft Unified Hangul Encoding
: // (US-ASCII + KS C 5601-1987 + 11172 Modern Hangul Syllables ?)
: /* alias: */ "ms949", "windows-949", "ksc5601-1992", "ksc5601_1992",


: 대신 JDK 1.2의 ms949라는 인코딩 이름이 이에 해당합니다.
: ms949는 Johab이라는 인코딩 이름의 alias이므로 서로 동일합니다.
: 즉, 통합 완성형 코드를 조합형 코드라는 의미가 강한 Johab이란
: 이름을 사용하였으므로 무언가 잘못되었다는 생각입니다.


: KSC5601-1992에 대해서는 잘 모르겠으나, KSC5601-1992가 정의하는
: 문자세트을 모두 표현할 수 있는 인코딩이기때문에 (맞나?) 대표하는
: 인코딩으로 Johab이란 이름을 사용한 것으로 추측합니다.


KS C 5601-1992 Annex 3에 나온 이른바 '상용 조합형'은 은 MS의 code
page로는 949가 아니라 125?입니다. 따라서, 'Johab'을 MS의 code page
949/Unified Hangul Code와 같은 의미로 쓰는 것은 말씀하신대로 Sun의
잘못입니다. 또, "Johab"이란 인코딩 이름을 붙이고서 그것이 KS C
5601-1992가 정의한 인코딩이라는 인상을 주면서 실제 지원하는 것이 한글
MS-Windows 95/98에서 쓰는 인코딩(Cp949)인 것도 역시 문제입니다. 이
문제는 분명히 JDK 1.2의 최종판이 나오기 전에 고쳐야겠군요.


진짜 상용 조합형 인코딩(KS C 5601-1992의 Annex 3에 나온)을 지원하고,
Johab이란 말을 그 인코딩에만 쓰거나, 그럴 생각이 없다면
ms949,windows-949 라는 이름만 써야 할 것입니다. "ksc5601-1992"라는
alias를 쓰는 것도 문제가 있습니다. Sun이 Ms949라고 부르는 것과 KS C
5601-1992의 부속서 3에 나온 상용 조합형의 character repertoire가 같은
것을 제외하고는 두 인코딩에 아무런 공통점이 없습니다. 따라서, ms949에
대한 alias에서 ksc5601-1992는 제거해야 할 것입니다. 만일, 이 alias를
쓰고 싶으면 KS C 5601-1992의 부속서 3에서 정의한 상용 조합형을 지원하고
그에 대해 쓰는 것이 더 나을 것입니다 (그것도 그리 바람직한 것은
아닙니다)



: Cp949에 대해
: ==============


: 자바에서의 Cp949는 마이크로소프트 통합 완성형 코드를 의미하지
: 않으며,


그러면, Cp949는 무엇일까요? Unicode ftp archive에 있는 Cp949는
분명히 한글 MS-Windows 95/98에서 사용하는 통합 완성형입니다.



: 썬사에서 949 코드를 이와 같이 2가지로 나눈 것은
: 마이크로소프트사가 Cp949의 의미를 변경시켰기 때문이 아닌가
: 추측하고 있습니다.
: 윈도우즈 3.1에서 Cp949가 사용되고 있다면, 그런 경우에도
: 통합 완성형 코드의 의미를 갖는가요?


한글 MS Windows 3.1의 code page가 Cp949라고 불리웠다면 그것은
기본적으로 EUC-KR의 다른 이름에 다름이 아닐 것입니다. 혹은 C1 영역에
EUC-KR이 정의하지 않은 확장 문자(단, 이것은 한글이 아니라 다른 특수
문자로 알고 있습니다)를 정의해 놓았을 가능성은 있습니다. 그렇다면,
UCS-2를 Cp949로 변환할 때 KS C 5601-1987의 character repertoire에 없는
한글 음절은 "?"로 바꿔 주어야지 이상한 byte seq.로 바꾸는 것은
버그입니다. 어쨌든, Unicode archive에 있는 Cp949는 Sun이 ms949라고
부르는 것입니다.



: 결론적으로, ms949라는 인코딩 이름을 사용하여, 통합 완성형 코드의
: 모든 문서, 자료를 모든 자바 1.2 플랫폼에서 처리할 수 있다는 것입니다.
: 또한, 눈에띄는 버그도 없었습니다.


: 하지만, 사용자가 모두 자바 1.2 환경 및 윈도우즈 환경만을 사용하는 것은
: 아니므로, 그 인코딩을 사용하는 경우에는 이러한 제한점을 고려해야 할
: 것입니다.


Sun이 ms949라고 부르는 CP949/UHC/통합 완성형은 내부 사용이
아닌 경우에는(정보 교환을 위해서는) 절대로 써서는 안 되겠지요.


: 신정식님이 올리신 다음 프로그램중 "KSC5601" 을 "ms949"로 바꾼 후


소스는 바꾸지 않고, 그냥 'java KoreanTest ms949'라고 하셔도 되는데.... :-)


: 실행시켜보면, 윈도우즈의 도스창에서는 모든 현대 한글이 가나다라 순서로
: 바르게 출력이 됩니다.


JDK 1.2beta3을 설치할 상황이 아니라서 시험해 볼 수 없었는데 시험해
주셔서 감사합니다.


: 하지만, 유닉스의 hanterm, vi등 여러
: 프로그램에서 기대되지 않는 코드값이 끼치는 영향은 다양하더군요.
: 엉뚱한 문자로 보인다던가, 정상적인 문자도 영향을 받아 깨져서
: 보인다던가...


한텀의 최신 버전은 EUC-KR, 상용 조합 인코딩 (KS C 5601-1992, 부속서
3)과 UTF-8을 지원합니다. 여기에 UTF-7과 Cp949/UHC 지원을 더하는 것은
아주 힘든 일은 아닐 것입니다. 폰트 인코딩은 KS C 5601 GL과 GR 인코딩과
'조합 방식'을 지원하지요. font index와 glyph index가 모두 조합 방식인
폰트와 UCS-2인 폰트 지원을 더하는 것도 생각해 볼 수 있을 것입니다. HWP용
font를 그런 식으로 포장해 주는 font server가 있고, (한글) truetype
font를 원하는 어떤 인코딩으로나 변환해 주는 변환 프로그램(ttf2bdf)도
있으므로, 이런 폰트 인코딩을 지원하는 것은 필요한 일입니다.


: 또한, 코드값을 세밀히 관찰하지 않고서는 언뜻보아서
: euc-kr 문서인지, ms949인지, 훼손된 문서인지 분간하기도 어렵습니다.
: 표준화되지 못한 another encoding이 끼치는 악영향이라고 볼 수 있겠죠.


잘 아시듯이 EUC-KR에서 쓸 수 없는 한글 음절(8822자)를 쓰지 않는 한
Cp949(Sun이 ms949라고 부르는)과 EUC-KR의 차이는 하나도 없습니다.
(어쩌면, 원화 기호 처리에서 차이가 날 수도 있습니다)
따라서, 2350 자 이외의 한글 음절을 쓰지 않는 한 구별은 힘든 것이 아니라
불가능하지요.



: 코드 값 테이블과 다국어 출력
: ============================


: 자바의 다국어 출력에 관심이 있으시거나, 여러가지 인코딩의 코드값에
: 대해서 쉽게 알고싶으시면
: http://calab.kaist.ac.kr/~dtkim/java/example/i18n/CodeTable.java
: 을 가져가서 사용해보시면 도움이 될 것입니다.



:> Cp949 문제 이외에 다음과 같은 문제가 JDK 1.1.5에 있습니다.
: ....
:>
:> 2. 현재 EUC-KR, ISO-2022-KR, UHC/Cp949, IBM의 AIX에서 쓰는 것(아마,
:> EUC-KR� 변형) 등의 인코딩을 지원하는데(물론, UTF8은 디폴트로
:> 지원하지요), "조합 인코딩"도 -실제로 얼마나 쓸 지는 모르지만-
:> 지원해 주어야 할 것으로 봅니다.


: 조합 인코딩 지원에 대해서는 용도를 잘 모르겠군요.
: 통합 완성형은 코드값이 지저분하기는 하지만, 조사해보니 특수 기호를 피해나가는 등
: 문제의 소지를 최소화하려는 노력이 엿보이더군요.


상용 조합 인코딩과 Cp949/UHC/통합 완성형의 배치는 아래와 같습니다. 둘
다 ISO-2022 체계와 맞지 않는다는 점에서 별로 차이가 없습니다. 아마,
UHC가 두번째 바이트에서 0x5B-0x60(대문자 다음의 기호)과 0x31-0x40(숫자와
몇몇 기호) 영역을 쓰지 않는 것을 보고 '특수 기호를 피해 나가는...
노력'이라고 하신 것 같은데, 그것이 그렇게 중요한지 잘 모르겠습니다.
어차피 둘 다 ISO-2022 체계에 맞지 않고 C1(MSB가 1인 제어 문자) 영역을
침범하는 점에서는 똑같기 때문에 아직 ISO-2022 체계가 널리 쓰이고 있는
상황에서 쓰기에 적합하지 않은 정도는 같다고 봅니다.


따라서, 특정 회사의 특정 제품에서만 쓰이는 인코딩인 Cp949/UHC를
지원하면서(거기에 훨씬 잘 쓰이지 않는 한글 AIX의 인코딩 같은 것도
지원하면서) 비록 부속서이기는 하지만 KS C 5601-1992가 규정한 '상용
조합형 인코딩'을 지원하지 않을 이유는(실제 얼마나 많이 쓰이든지 간에)
별로 없다고 생각합니다. 더구나, 순전히 table lookup 방식에 의존해야 하는
Cp949/UHC에 비해 상용 조합형은 한글 음절 부분의 변환은 산술적으로 할 수
있으므로, 오버헤드도 별로 크지 않을 것입니다.



# 1. 한글
# 1st byte : 0x84-0xd3
# 2nd byte : 0x41-0x7e, 0x81-0xfe
# 2. 한자와 심볼 :
# 1st byte : 0xd8-0xde, 0xe0-0xf9
# 2nd byte : 0x31-0x7e, 0x91-0xfe


# 0xd831-0xd87e and 0xd891-0xd8fe : 사용자 정의 영역
#
# 3. KS C 5636 or US-ASCII (1byte) : 0x21-0x7e
# KS C 5636 is identical to US-ASCII except for WON SIGN, U20A9
# in place of BACK SLASH, U005C at 0x5C


UHC/Cp949는 다음과 같지요.


Two-byte Standard Characters Encoding Ranges
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
first byte range 0x81-0xFE
second byte ranges 0x41-0x5A, 0x61-0x7A,
and 0x81-0xFE


One-byte Characters Encoding Range
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
ASCII 0x21-0x7E



:> 3. 이것은 한국어 locale에만 해당하는 얘기는 아닌데, 도대체 locale과
:> 시간대를 연관시키는 것은 누구의 발상인지 모르겠군요. 한국어 locale을
:> 쓴다고 해도 미국 동부 시간대를 쓸 수도 있고, 중부 유럽 시간대를 쓸 수도
:> 있을텐데, 한국어 locale을 고르면 현재 시스템의 시간대 설정을 무시하고
:> 무조건 한국 표준시로 시간을 표시하다니 어처구니가 없윱求�.


: 로캘과 시간대가 전혀 다른 개념임을 자바소프트 및 연합 회사의 엔지니어들이
: 몰랐을리가 없을 것입니다.
: 자바가 시스템에 설정된 시간대를 알아내는 데 초기부터 문제가 많았으며,
: 또한, 시간대 이름이 충돌하는 경우도 많은 것 같더군요.
: (KST라는 이름이 다른 나라에도 사용되나요?)


쿡 제도의 시간대 이름이 KST입니다. EST(미국 동부 표준시, 호주 동부
표준시), BST (영국 일광 절약 시간, 베이징 표준시?) EDT(미국 동부 일광
절약 시간, 호주 동부 일광 절약 시간), JST, KST 등은 대단히 혼동의 여지가
많은 것으로 시간대 표시는 항상 UTC 기준으로 쓰는 것 이상 더 좋은 방법은
없습니다. 최소한 (대부분의) Unix에서는 시간대 이름과 관계 없이 timezone
파일에는 UTC 기준으로 현재 컴퓨터가 있는 지역의 시간대가 몇 시간 빠른지
늦은지 등에 대한 정보가 잘 들어 있습니다. 하긴, timezone 파일 대신에 TZ
(TZNAME이었나요?) 환경 변수를 사용하는 (바보 같은. POSIX 표준에
부합하기는 하지만 ) 일부 Unix(Solaris 2.x도 아마 그런 Unix 중에
하나??)에서는 분명히 혼동의 여지가 있겠군요.


: 아마도, 이런 문제점을 피해나가기 위한 임시 방편이 아니었나라고
: 추측하고 있습니다.


어쨌든, 이 문제는 시급히 고쳐야 할 것 같습니다. en_US locale을 고르면,
무조건 태평양 표준 시간으로 시간을 표시하니 동부,중부,산악 시간대에 있는
사람은 황당합니다. 중국에 있는 미국인이 en_US locale을 고르면 시간이 미
태평양 연안 표준시로 나오니 더하기 빼기를 해야 합니다...... 마찬가지로
미국 동부에 있는 한국인이 ko_KR locale을 고르면 한국 표준시로 시간이
나오고........



:> 4. 이것도 일반적인 문제인데 locale 설정을 해도 그에 대응하는 인코딩을
:> 손쉽게 설정할 방법(인코딩은 따로 설정해야 함)이 없는 것도 문제인 것
:> 같습니다. ko_KR 같으면 locale 설정시 EUC_KR, ISO-2022-KR, Cp949/UHC,
:> JOHAB, UTF8 등의 인코딩도 지정할 수 있으면 더 좋을 것 같다는 생각입니다.


: 시스템 locale 설정에서의 인코딩 지정은 시스템이 지원하는 것으로만 한정되는
: 것 같습니다.
: 아시다시피 자바는 대단히 많은 인코딩을 지정하고 있으며, 시스템의 기능 추가는
: 일반적으로 쉬운 것이 아니므로, 자바만이 이해하는 인코딩 환경 변수를
: 추가시킨다면 될 것 같습니다.
: 아직은 그런 환경 변수가 없는 것으로 알고 있으며,
: 현재로서는 자바 애플리케이션의 경우에 한하여,
: -Dfile.encoding=ms949 등의 명령행 인자를 사용하는 방법이 있습니다.


제가 제기한 것과 답변하신 것이 같은 문제에 대한 것인지 잘
모르겠습니다. 제가 원한 것은 Java에서 locale을 지정할 수 있는 대부분의 -
모든 경우가 아니라면 - method에 encoding도 사용자가 원하는 경우에는
지정할 수 있도록 하는 것이 더 좋지 않을까 하는 것입니다. Java가
돌아가는 호스트 시스템이 어떤 인코딩을 지원하는지와는 독립적으로 한
application 안에서도 필요할 때마다 언제든지 인코딩을 바꿀 수 있으면
좋지 않을까 하는 것입니다. 지금도 할 수는 있는데, 상당히 불편한 것
같아서 하는 얘기입니다. 잘 모르고 하는 헛소리인지도 모르겠습니다.
그런 것 같으면 무시하세요 :-)


다시 한번 자세한 답변에 감사 드립니다.


신정식

다음 글들:


이어서 글올리기(답하기)

이름:
E-Mail:
제목:
내용:
관련 URL(선택):
URL 제목(선택):
관련 이미지 URL:

[ 다음 글들 ] [ 이어서 글올리기(답하기) ] [ 자바 묻고 답하기 ]