한글문자의 유니코드 알아내기
http://www.interpia.net/~yoonforh/java/messages/148.html
안녕하세요 강신동입니다.
한글문자 '가'
완성형 B0A1
조합형 8861
Unicode AC00
실행을 위한 코드는 아래와 같습니다.
class A {
public static void main(String[] arg) {
System.out.println(
Character.isDefined('가'));
// 한글문자 '가'가 Unicode로 정의되어 있는지 알아본다.
// 만약 정의되어 있다면 true를 리턴한다.
int i = '가';
// 문자 '가'를 int 형 변수인 i에 대입한다.
// 실제로 문자는 정수와 같다.
System.out.println("'가'의 int형은 " + i);
System.out.println("'가'의 unicode는 "
+Integer.toHexString(i));
// Integer의 static method인 toHexString()을 이용하여
// 10진수를 16진수를 표시하는 문자열로 바꾼다.
System.out.println("'가'의 unicode는 "
+Integer.toHexString(i).toUpperCase());
// 문자열로 바뀐 것은 소문자로 나온다. 대문자로 바꾸기 위해서
// String의 static method인 toUpperCase()를 사용한다.
}
}
실행결과는 아래와 같다.
C:\Java 연습>java A
true
'가'의 int형은 44032
'가'의 unicode는 ac00
'가'의 unicode는 AC00
다음의 예를 보면 아주 정확히 이해 할 것이다.
class A {
public static void main(String[] arg) {
int i = '가';
System.out.println(i);
System.out.println(i+10);
}
}
실행결과는 아래와 같다.
C:\Java 연습>java A
44032
44042
Java Developer Group의 강신동 이었습니다.
http://164.125.88.41 HotJava 1.0만이 지원합니다.
많이 들러 주십시오
읽어주셔서 감사합니다.
유니코드와 UTF-8, 그리고 자바...
http://www.interpia.net/~yoonforh/java/messages/295.html
Posted by 김덕태 on July 02, 1997 at 10:01:40:
Gil wrote:
>
> >: "F900-FFDF 에 CJK Unified Ideographs 라고해서 유니코드에 있는데 이미
> >: 4E00~9FA5 까지 (모두 20902개 , 계산이 맞는지..) 이미 한자 영역이 있습니다.
> >: 그런데 왜 저 곳에 또 무슨 "호환성문자" 라고 해서 넣었는지 모르겠습니다."
> >
> >: 라고 질문했었는데 아직도 모르겠습니다, 다시한번 여기에 :)
> >
> >Compatibility는 말 그대로 호환성이죠.
> >이는 기존의 encoding을 unicode에 대부분 수용하면서 있는 부분입니다.
> >
> >일례로 한글 완성형의 경우 한자가 음을 기준으로 나열이 되어 있습니다.
> > 그래서 중복되는 한자가 있습니다. 이를 수용하기 위해서 이러한 영역이 있습니다.
>
> 그렇네요, 惡를 예로들면,
>
> 악할 악(惡) : 완성형에서 E4C2 : 유니코드에서 60E1
> 미워할 오(惡) : 완성형에서 E7F7 : 유니코드에서 F9B9
>
> 악할 악字가 먼저나와서 그런지 그 다음에 나오는것이 호한성문자영역으로
> 들어가는군요.
>
> 읽어보니 268개의 그런 중복된 경우가 있고 Big5의 경우에는 2개 있고 나머지는
> 잘 모르겠습니다.
> GIL
> http://soback.kornet.nm.kr/~chlang
질문하신 문제에 대하여 그 의미 및 문제점을 파악하기 위해서는
유니코드의 기본 목적을 먼저 확실히 이해하는 것이 중요합니다.
==== 유니코드의 소개 ==========
다음에서 기술하는 유니코드의 목적은 첨부하는 참고문헌의 내용과
상이하며, 제가 나름대로 생각하기에 정말 중요하다고 생각되는 목적만을
나름대로 정리한 것이므로 이점 착오없으시기 바랍니다.
첫째, 통합 문자 세트.
다양한 나라가 서로 동일한 혹은 비슷한 의미의 문자를 저마다 다른 인코딩
방식을 사용함으로써, 자료 및 프로그램의 호환성 및 확장성에 문제를
일으키는 관계로 이를 하나의 문자 세트인 유니코드로 통합시켜
표현함으로써 해결한다는 것입니다.
둘째, 문자 세트 변환의 중심 역할.
기존 문자 세트 표준 (KS C 5601 혹은 일본의 JIS X 0208등등)이 N개가
존재한다고 할 경우, 다양한 문자 세트 표준사이의 변환을 위해서는 N *
(N-1)개의 변환 테이블이 필요하나 이는 구현상 상당한 부담으로
작용합니다. 따라서, 기존 문자 세트 표준사이의 변환을 할 때, 일단
유니코드로 변환한 후 다른 문자 세트 표준으로 변환하게 되면, 변환
테이블이 2 * N개만 필요하게 되므로, 문자 세트 변환을 다루는
프로그래밍이 상당히 간편해진다는 것입니다. 유니코드가 이와같이 문자
세트 변환의 중심을 차지하기위해서는, 기존 문자 세트의 문자를
유니코드로 변환한 후 다시 원래의 문자 세트로 변환하여도 원래의 자료가
변경되지 않고 그대로 복구되어야 한다는 것입니다. 이를 round-trip
conversion compatibility 혹은 source separation rule이라고 합니다.
======= 기존 표준 문자 세트와의 호환성 ==========
참고문헌의 페이지 2-8과 2-9의 내용을 인용하면,
``The Unicode Standard avoids duplicate encoding of characters by
unifying them within scripts across languages; characters that are
equivalent in form are given a single code.
... (중략) ...
The Unicode Standard avoids duplication of characters due to specific
usage in different languages, duplicating characters to support
compatiblity with base standards.
... (중략) ...
In determining whether or not to unifiy variant ideograph forms across
standards, the Unicode Standard follows the principles described in
Section 6.4, CJK Ideographs Area. Where these principles determine
that two forms constitue a trivial (wazukana) difference, the Unicode
Standard assigns a single code. Otherwise, separate codes are assigned.
... (중략) ...
Identifying a character A as a compatibility variant of another
character B implies that generally A can be remapped to B without loss
of information other than formatting. Such remapping cannot always
take place because many of the compatibility characters are in place
just to allow systems to maintain one-to-one mappings to existing code
sets. In such cases, a remapping would lose information that is felt
to be important in the original set. Compatiblility remappings are
called out in Section 7.1, Character Names List. Because replacing a
character by its compatibly equivalent character or character sequence
may change the information in the text, implementation has to proceed
with due caution. A good use of these mappings may not be in
transcoding, but in providing the correct equivalence for searching
and sorting.''
질문하신 문제와 위 인용된 문구와 연관시켜 해석해보면 다음과 같습니다.
KS C 5601에는 한자가 우리나라 한자 발음순으로 배열되어 있습니다.
따라서, `수레 차'를 의미하는 한자의 경우, `수레 거'로 읽을 수 있으므로
실제로는 동일한 한자에 대하여, KS C 5601에서는 이들을 인위적으로
`수레 거' 와 `수레 차'로 나누어 각각 0xCBE7, 0xF3B3으로 인코딩되어
있습니다.
이와 같이 인위적으로 나눈 이유는, 한자의 정렬 (sorting) 및
해당 한자 발음의 한글과의 변환에 모호성이 없어지기 때문으로 보입니다.
그러나, 한중일 통합 한자 영역에는 `수레 차'와 `수레 거'가 동시에
들어갈 수는 없습니다. 이러한 구분은 우리나라에서만 의미 있는 것이므로
`수레 차'의 의미와 `수레 거'의 의미를 구분하지 않는 대표적인 한자
한개만이 들어가야합니다.
KS C 5601과 유니코드의 대응 테이블을 찾아보면, KS C 5601의 `수레 차'는
유니코드의 한중일 통합 한자 영역에 있는 0x8ECA에 대응되고, `수레 거'는
KS C 5601 표준과의 호환 한자 영역내에 있는 0xF90E로 대응되어 있습니다.
즉, `수레 차'는 해당 한자를 대표하는 것으로 간주되고, (아마, `수레
차'가 더 일반적인 발음이므로 그렇게 선택한 것으로 생각됩니다.) `수레
거'는 유니코드로부터 KS C 5601로 다시 역변환해도 round-trip conversion
compatiblity에 의해서 그대로 복구되기 위해 존재하는 것입니다.
하지만, 때로는 `수레 거,차' 구분없이 하나의 유니코드 문자 (0x8ECA)로
대응 (compatibility remapping)시킬 필요가 있습니다. 즉, 구분없이 해당
한자를 탐색 (search)하거나, 어떤 순서 (가령 부수순)로 정렬 (sorting),
혹은 다른 문자 세트 표준과의 보다 적절한 변환이 필요한 경우입니다.
가령, JIS X 0208과 유니코드와의 변환 테이블을 찾아보면 `수레 차'에
대응하는 유니코드 값이 JIS X 0208의 해당 한자에 대응되어 있으나,
`수레 거'에 대응하는 유니코드 값은 해당 한자에 대응되어 있지 않습니다.
(이유는, 2개의 유니코드 값이 하나의 JIS X 0208로 대응될 경우,
1:1 대응이 깨져서 약간 다른 의미의 round-trip conversion
compatibility를 유지하지 못하기 때문으로 보입니다.)
즉, KSC 5601과 JIS X 0208사이의 한자 변환은 compatibility remapping을
하여야만 `수레 거'도 변환이 된다는 것입니다.
이러한 remapping된 값은 참고문헌의 페이지 7-470의 테이블을 보시면,
`수레 거'에 대응하는 유니코드 값이 0xF903이지만 바로 위에 compatiblity
remapping된 유니코드 값인 0x8ECA (KS C 5601의 `수레 차'에 대응하는
유니코드 값)가 적시되어 있습니다.
(시스템마다 다르겠지만, 이런 remapping을 해주는 함수가 제공될 가능성이
있습니다.)
그러나, compatibility remapping을 하게 되면 `수레 거'와 `수레 차'를
구분한 본래의 의미를 상실하게 되어서 무조건 이와 같이 remapping할 수는
없는 것이므로, 특정 application이 상황에 맞는 경우에만 remapping을
하는 것이 적절하여 보통의 변환 함수를 사용하게 되면 remapping을 하지
않을 것입니다.
그런데, 여기서 한가지 주의 해야할 점이 있는데,
유니코드 값 0x8ECA만이 주어졌을 때,
`수레 거'와 구분 되는 `수레 차'의 의미를 갖는 것으로 볼 수도 있고,
`수레 거' 혹은 `수레 차' 2개를 대표하여 이 둘 사이를 구분하지
않는 의미를 갖는 것으로 볼 수도 있는 약간 상반된 2가지 의미론을 동시에
갖는다고 해석됩니다.
제가 이해하기 곤란한 부분이 바로 여기에 있습니다.
유니코드가 이와 같이 모호한 의미론을 갖고 있는 것인지,
아니면, 제가 참고문헌을 제대로 이해하지 못했다거나 더 엄밀한 문서가
혹시 있는 지, 저로서는 모르겠습니다.
또, 정부에서 제정한 KS C 5700이 유니코드 사양과 완전히 동일한 것인지,
아니면 보다 구체적인 사양이 추가되어있는 지, 그래서, 유니코드의
KS C 5601 호환 한자 영역은 가능하면 사용하지 말고 mapping시키도 말
것을 권장하는 지침같은 것이 있는 지도 모르겠습니다.
아시는 분이 계시면 posting 바랍니다.
하지만, 제 개인적인 소견으로는, 유니코드가 다루고 있는 한자의 수
(2만여자)가 KS C 5601 (4888자)보다 휠씬 많고, KS C 5601에 포함되지
않은 한자 중에서, 2개이상의 우리나라 발음을 갖는 한자가 많이 있을
것이므로, 이들에 대하여 모두 호환 한자 유니코드 값을 새로이 할당할
계획이 없다면 (아마, 없겠죠?), 유니코드의 사용이 확대되는 시점에
이르렀을 때, 호환 한자 영역의 사용을 자제하도록 (즉, compatibility
remapping이 default 변환이 되도록) 하고, 따라서, 유니코드 값 0x8ECA의
의미론을 `수레 차', `수레 거'를 대표하는 것으로 의미론을 고정시키는
것이 바람직하다고 봅니다.
============== 유니코드와 UTF-8 인코딩 ====================
한가지 더 제 의견을 개진하고 싶은 것은, 유니코드는 여러가지로
따져보았을 때 프로그램 내부에서 사용하거나 특정 프로그램만이 이해하는
화일 혹은 교환되는 자료의 인코딩으로 적당할 뿐, 일반 텍스트 문서의
인코딩, 혹은 다양한 프로그램 사이에 전달되는 텍스트 자료의
인코딩으로서는 부적당하다는 것입니다. 따라서, 현재와 같이
우리나라에서 일반화된 인코딩 표준인 KS C 5601 (좀더 정확히는 EUC-KR)을
대체하기는 곤란하며, 유니코드와 1:1 대응할 뿐만 아니라, 여러가지
우수한 성질을 갖는 UTF-8 인코딩이 KS C 5601의 대체 인코딩 방법이라는
것입니다. 따라서, 우리나라가 가능하면 빨리 UTF-8로 이행하는 것이
바람직하다고 생각합니다.
============== 참고문헌 ========================
[1] ``The Unicode Standard, Version 2.0,'' The Unicode
Consortium, Addison Wesley, 1996
(평가) 유니코드에 대하여 자세하고 전반적인 설명과 함께, 모든 정의된
유니 코드 문자의 일반적인 특징 및 출력된 모양이 소개되어
있다.
p.s. 유니코드에 대한 오해의 소지를 최소화하고 논의를 활성화하기
위하여 Unicode, Inc. 및 Addison Wesley의 허락 없이 함부로 인용한
점에 대하여 Unicode, Inc. 및 Addison Wesley에 사과의 뜻을
표합니다.
================== 첨부 ============================================
첨부하는 프로그램은 유니코드와의 변환을 제공하는 자바 프로그램입니다.
(JDK1.1 버전)
char 자료형 및 String 자료형이 모두 유니코드이므로, 유니코드의 첫째 및
둘째 목적에 부합하는 프로그래밍이 자연스럽고 손쉽습니다.
-------- HanjaTest.java ----------
// KSC5601내의 한자 범위: 0xCAA1 ~ 0xFDFE (4888 자 = 52 * 94)
public class HanjaTest
{ public static void main(String args[])
throws java.io.UnsupportedEncodingException
{
for( int high = 0xCA; high <= 0xFD; ++high )
for( int low = 0xA1; low <= 0xFE; ++low )
{
String unicode = new String(
new byte[] {(byte) high, (byte) low}, "KSC5601");
byte[] eucjis = unicode.getBytes("EUCJIS");
System.out.print(
Integer.toHexString(high) +
Integer.toHexString(low) +
" (" + unicode + ") ==> " +
Integer.toHexString((int) unicode.charAt(0)));
if ( eucjis.length == 1 && (eucjis[0] & 0xFF) == '?' )
System.out.println( ", 없음" );
else
System.out.println(
", " + Integer.toHexString(eucjis[0] & 0xFF) +
Integer.toHexString(eucjis[1] & 0xFF) ) ;
}
}
}
-------------- end of HanjaTest.java ----------------
C:> java HanjaTest | more
(KSC5601, 유니코드, EUCJIS순으로 해당 코드 값을 출력)
... 전략 ...
cbe7 (車) ==> f902, 없음 // 수레 거
... 중략 ...
f3b3 (車) ==> 8eca, bcd6 // 수레 차
... 후략 ...
--
Deogtae Kim (김덕태)
CA Lab. CS Dept. KAIST
E-Mail : dtkim@camars.kaist.ac.kr
Phone : +82-42-869-3569
Fax : +82-42-869-3510
Follow Ups:
유니코드, 문자 세트, 인코딩의 개념, 자바의 인코딩 개념. 김덕태 10:21:40 7/05/97 (2)
보충... 김덕태 12:34:40 7/05/97 (1)
UTF-8 인코딩과 16 비트 인코딩과의 비교, 인코딩 변환 자바 프로그램 김덕태 17:28:38 7/07/97 (0)
유니코드, 문자 세트, 인코딩의 개념, 자바의 인코딩 개념.
http://www.interpia.net/~yoonforh/java/messages/307.html
Posted by 김덕태 on July 05, 1997 at 10:21:40:
In Reply to: 유니코드와 UTF-8, 그리고 자바... posted by 김덕태 on July 02, 1997 at 10:01:40:
Jungshik Shin wrote:
> 이 부분은 조금 오해의 소지가 있는 듯 합니다. 워낙 이 부분의 용어가
> RFC나 표준 문서마다 제각각이어서 혼동을 초래할 수 밖에 없기B 합니다.
> 이를 정리하기 위한 노력의 일부인 RFC 2130에 비추어 볼 때 위의 단락은
> 좀더 조심스럽게 용어를 사용해서 쓰였으면 좋지 않을까 생각합니다.
>
> RFC 2130의 정의에 의하면 KS C 5601, KS C 5636(US-ASCII), Unicode 등은
> 문자셋(Coded Character Set=CCS)입니다. 이 문자셋(CCS)을 구체적으로
> 표현하기 위해 octet에 대응시키는 인코딩 방법(Character Encoding
> Scheme=CES)이 EUC-KR, ISO-2022(-KR), UTF-8(UTF-FSS), UTF-7,UTF-1 등이
> 있겠지요. 앞의 2개는 KS C 5601과 KS C 5636(US-ASCII)라는 2개의
> 문자셋(CCS)을 인코딩하는 방법(CES)이고 뒤의 세 개는
> Unicode(ISO-10646에서 BMP)라는 문자셋(CCS)을 인코딩하는
> 방법(CES)이겠지요.
>
> 따라서, "KS C 5601을 대체하는 인코딩으로 UTF-8을 쓴다"는 표현은 서로
> 개념적으로 다른 차원의 두 가지를 -KS C 5601은 CCS이고 UTF-8은 CES이므로
> - 같은 차원에 놓은 것으로 보입니다. 마찬가지로 'Unicode와 UTF-8을 같은
> 위치에 놓고 비교하여 어느 한 쪽이 다른 쪽보다 어떤 용도에 보다
> 적합하므로 더 우월하다 '고 하는 것도 혼동의 소지가 있습니다. UTF-8은
> 독립적인 문자셋(CCS)이 아니라 Unicode의 여러 가지 인코딩 방법(CES) 중
> 하나에(위에 적으신대로 'File System Safe'한 특성을 지녔기에
> UTF-FSS라고도 불리며 파일 저장 등에 적합한 CES로 알고
> 있습니다) 불과하니까요. 위의 글에서 Unicode란 단어를 Unicode란 CCS의
> '가장 자연스러운 인코딩' 방법의 의미로 사용하신 듯 합니다. 즉, "Unicode를
> network byte order에 따라 두 개의 octet의 나열로 표현한 인코딩
> 방법(CES)"의 의미로 사용하신 것으로 짐작합니다. 역시, KS C 5601도
> 사람들이 흔히 쓰듯이 KS C 5601과 KS C 5636(US-ASCII)란 2 개의 CCS를
> 전자는 G1에 후자는 G0에 두고 G0은 GL에 G1은 GR에 고정시킨 (ISO-2022 등에
> 대해 전혀 모르는 이라도 쉽게 생각할 수 있는 '자연스러운') 인코딩
> 방법의 의미로 쓰셨으리라 봅니다. 하지만, 이것은 이미 위의 괄호 안에서
> 지적하신 바처럼 EUC-KR로 정확히 부르는 것이 이런 종류의 논의를 할 때에는
> 혼동의 여지가 없으리라고 봅니다.
이런 복잡한 문제에 끌려(?) 들어가고 싶지는 않았지만 짚고 넘어가야 되는
문제로 생각되어 말씀하신 RFC 2130을 뒤져보았습니다.
관련 링크가 잘못되었더군요.
참고문헌 [1]에 가보니 관련 내용을 볼 수가 있었습니다.
======= RFC 2130 ========
RFC 2130은 인터넷 환경에 적합하고 호환성에 문제를 덜 일으키는 octect
(8 bit를 의미, `바이트'의 의미보다 더 엄밀함)를 기준으로 해서 문자
세트 및 인코딩과 관련된 사항을 다음과 같이 3 부분으로 나누어 놓았고,
각종 인터넷 표준을 정의하는 데 있어서 사용되는 용어, keyword등의
의미의 엄밀성과 일치성, 호환성을 기하기 위한 것이 목적일 것이며, 모든
프로그램과 자료가 인터넷만을 목적으로 하지 않는 이상, 이 분류에 맞지
않는 의미의 용어가 나름대로의 가치를 가지고 이와 구분되어 사용될 수
있는 것이라 생각됩니다.
1. A Coded Character Set (CCS) is a mapping from a set of abstract
characters to a set of integers. Examples of coded character sets
are ISO 10646 [ISO-10646], US-ASCII [ASCII], and ISO-8859 series
[ISO-8859].
여기서 정의하는 Coded Character Set의 의미는 각 추상적인 문자에
대하여 정수값을 할당하는 것이고, 정수라는 개념은 몇 비트로 표현한다는
것까지 정의하는 것은 아니므로, 인코딩과는 아무런 관련이 없는 추상적인
개념으로 볼 수가 있습니다.
2. A Character Encoding Scheme (CES) is a mapping from a Coded Character
Set or several coded character sets to a set of octets. Examples of
Character Encoding Schemes are ISO 2022 [ISO-2022] and UTF-8 [UTF-8].
A given CES is typically associated with a single CCS; for example,
UTF-8 applies only to ISO 10646.
말씀하신 대로 EUC-KR은 2개의 CCS (KS C 5601과 KS C 5636)의
CES입니다. 또한, UTF-8은 ISO 10646 CCS의 CES입니다.
KS C 5601을 각 정수 코드 값에 대하여 2 바이트 값으로 매핑한다고
가정한다면 CES로도 볼 수 있겠으나, 그와 같이 사용되는 경우가 거의
없으므로 (아스키문자도 섞어서 쓰므로), KS C 5601이라고만 한다면
CES를 의미하는 것이라고 볼 수 있을 것입니다.
또한, EUC-KR이 해당하는 KS C 5601과 KS C 5636의 합집합을
의미하는 CCS로도 볼 수도 있겠으나, 해당 CCS를 의미하는
용어가 이미 있으므로 EUC-KR이라고만 할 때는 CES를 의미하는 것이
적당할 것입니다. 하지만, 이는 해당 용어 및 keyword가 사용되는
context에 의해 결정되어야 할 것입니다.
참고문헌 [1]을 보면,
``Also, in MIME, the Coded Character Set and Character Encoding
Scheme are specified by the Charset parameter to
the Content-Type header field, and Transfer Encoding Syntax is
specified by the Content-Transfer-Encoding header field.''
즉, MIME에서는 charset 값은 CCS와 CES 둘다 의미하는 keyword이어야
하므로, EUC-KR이 사용된 경우에는 그 의미가 ``CCS는 KS C 5601과
KS C 5636의 합집합을 지정한 것이고, CES는 EUC-KR 인코딩이
나타내듯이 (NULL, 0) ~ (DEL, 127)은 해당 1 바이트로 매핑시키고,
(first_ksc5601_char, 0x2121) ~ (last_ksc5601_char, 0x7d7e)은
그 코드값을 x라 하면, x + 0x8080을 network byte order로 2 바이트로
매핑시키는 것을 의미한다.''라고 해당 표준 문서에 명기할 것을 추천하는
의도로 파악됩니다.
우리나라에서 현재 논란이 되고 있는 ISO-2022-KR의 경우도
MIME charset으로 지정된다면 마찬가지로 ``CCS는 KS C 5601 및 KS C
5636의 합집합을 지정한 것이고, CES는 ISO-2022-KR이 나타내는 CES를
지정한 것이다.''를 의미하는 것으로 정의해야 겠지요.
그러나, 유니코드 2.0이 의미하는 가장 일반적인 의미는 ISO 10646 BMP
및 plane 1 ~ plane 16의 문자를 16 비트 환경으로 인코딩하는 scheme
이라는 의미가 강하므로, RFC 2130의 정의를 따른다면 CCS로도 CES로도
보기 어렵다고 보고 있습니다.
3. Transfer Encoding Syntax
is frequently necessary to transform encoded text into a format
which is transmissible by specific protocols. The Transfer Encoding
Syntax (TES) is a transformation applied to character data encoded
using a CCS and possibly a CES to allow it to be transmitted.
Examples of Transfer Encoding Syntaxes are Base64 Encoding [Base64],
gzip encoding, and so forth.
TES는 CCS 및 CES와는 다소 독립적이며 특정 프로토콜이 이해하고
처리할 뿐 일반 사용자에게는 드러나지 않는 인코딩을 의미하는 것으로
CES와 구분되는 것 같습니다.
하지만, `possibly a CES'라고 되어 있는 점이 좀 비논리적인 것으로
보이는 군요.
CCS와 CES 둘다 정의되어 있지 않으면, 엄밀하게 octect stream
(간단하게 말하면, 바이트 열)으로 변환할 수 없고, 그렇다면, Base64
나 gzip 인코딩 또한 불가능하기 때문입니다.
==== 유니코드 2.0의 정의 =========
참고문헌 [2]의 페이지 1-1을 인용하면,
``The Unicode Standard is a fixed-width, uniform encoding scheme for
written characters and text.
... 중략 ...
The Unicode Standard is modeled on the ASCII character set, but uses a
16-bit encoding to support full multilingual text.''
즉, 유니코드 2.0은 16 비트 인코딩이 가장 정확한 의미라는 것입니다.
16 비트가 나타내는 코드 값으로 추상적인 문자와의 매핑을 정의하는
것으로 볼 수 있다면 CCS라고도 볼 수 있겠으나, 문제는 surrogate
area의 두개의 유니코드 값으로 하나의 추상적인 문자를 나타낸다는
것입니다. 이 surrogate area의 값은 ISO-10646의 plane 1 ~ 16부분에
해당하는 문자 (ISO-10646의 부분집합)로 매핑되게 됩니다. 따라서, 그
코드값을 정수로 표현하게 되면 0 ~ 65535의 범위를 넘어가게 됩니다.
이런 이유로, ISO 10646 BMP와 유니코드를 동일시할 수가 없습니다.
CES로도 볼 수 없는 이유는, 16 비트 인코딩이므로, 유니코드 코드 값의
상위 바이트와 하위 바이트가 어떤 순서로 저장 및 전송될지를
정의하지 않고, 각 시스템에 적합한 순서를 사용할 수 있게 한 것입니다.
그래서, 고정된 octect stream으로 만들어 낼 수 없으므로, 8 bit
인코딩이 될 수 없고 따라서 CES의 정의에 부합하지 못합니다.
참고문헌 [2]의 페이지 3-1을 보면, 바이트 순서에 대한 대한
어느 정도의 언급이 있지만, 완전한 것이라고 보기 어렵습니다.
따라서, 유니코드 + network byte order (big endian)이라고 말한다면
ISO-10646의 부분집합 CCS와의 매핑을 정의하는 CES라고 할 수 있습니다.
Unicode 라는 용어를 ISO-10646의 그 부분집합 CCS를 의미하는 것으로도
쓰일 수가 있겠지만, 이는 Unicode라는 용어가 함축하는 의미의 일부에
지나지 않는 것이므로, Unicode가 그와 같은 CCS를 나타내는 것으로
고정시킬 수도 없습니다. 혼란을 막기 위해서는 뭔가 다른 용어를
만들어 사용하여 해당 CCS를 의미하는 것으로 사용하는 것이 적당할
것으로 생각될 뿐입니다.
또한, 8 비트 인코딩 방법이 16 비트 인코딩 방법보다 더 구체적이라고
보지는 않으며, 단지 가정하는 환경이 다른 것이므로, 문자 자료가 16
비트 환경과 8 비트 환경을 넘나들 때, 문제가 발생할 소지를 안고 있는
것으로 파악하고 있습니다.
이는 7 비트 환경을 가정하는 ISO-2022-KR이 8 비트 환경을 가정하는
EUC-KR보다 더 구체적이라고 말하지는 않는 이유와 같습니다.
물론, 인코딩 방법이 가정하는 비트 수가 적을 수록 호환성에 문제가
적지만 내부적으로 처리하는 자료의 형식으로는 불편해지는 것으로
보아도 좋을 것입니다.
따라서, 유니코드와 UTF-8은 둘다 인코딩이므로, 프로그래밍 하는
사람의 입장에서는 적절한 인코딩을 사용하여 상황에 맞게 선택하여
사용하는 문제일 것입니다.
유니코드 인코딩을 사용할 경우에는, 바이트 순서가 문제가 되지 않는
경우에는 의미 있는 인코딩 방법이기 때문입니다.
(즉, 같은 바이트 순서를 가정하는 환경사이의 자료 저장, 교환 및
바이트 순서를 알아낼 수 있는 적절한 방법이 채용될 경우등등.
가령, 유니코드에서는 0xFEFF라는 값을 바이트 순서 표식 (Byte Order
Mark)라고 하여 자료를 읽은 쪽에서 0xFFEF라고 읽히면, 서로 가정하는
바이트 순서가 뒤집혔다고 판단, 바이트 순서를 뒤집어서 읽도록
하고 있습니다.)
유니코드와 UTF-8을 비교한 것은 16 비트 인코딩 방법으로서의
유니코드 인코딩 및 유니코드 + network byte order등을 모두 포함하고,
이들 방법과 UTF-8과 비교해 볼 때, UTF-8이 안전하고 잇점이 많다라는
것을 말하려는 의도였습니다. 그러나, 이미 RFC 2130에서 UTF-8을
표준 인코딩으로 추천하고 있더군요.
인코딩 방법으로서의 유니코드를 의미한다면 UTF-16이라고 하는 것이 더
엄밀했을 것입니다.
따라서, 제가 의도하고자 했던것을 좀 더 엄밀하게 나타낸다면,
- KS C 5601은 한글을 다 못 나타내는 등 문제가 많아 ISO 10646 문자
세트 (CCS)로 전이하여야 한다.
- 이때, 인코딩 방법으로 UTF-16이 사용될 수 있으나,
-- 바이트 순서에 문제가 발생할 수 있고,
-- 기존 아스키 문서와의 호환성이 문제가 되며,
-- 아스키 문서의 경우, 문서의 크기가 2배가 되며,
-- 아스키 기반의 기존 환경 (운영체제, 프로그램등)과 충돌하며,
-- 차후, 유니코드의 4 바이트 확장판이라고 볼 수 있는 ISO-8859
UCS-4와도 그대로 호환되는 것이 아니다.
따라서, 이와 같은 이슈가 문제가 되지 않는 경우에 해당하는
내부적인 문서의 형식 및 내부적인 처리 용도로 UTF-16을 사용하고,
이외에는, 이러한 문제를 하나도 갖지 않는 UTF-8을 사용하여
인코딩하는 것이 바람직하다.
라는 것이었습니다.
=== 자바에서의 인코딩 이름 =====
언급된 이유로, 자바에서 16 비트 인코딩 이름으로 Unicode 및 8
비트 인코딩으로서 KSC5601, EUCJIS, 8859_1, UTF8등등 여러가지가
동급으로 사용되는 것은 잘못된 게 아니라 생각됩니다.
물론, 여기서 EUC-KR을 사용하지 못하고, 대신 KSC5601을 사용해야만 하는
것은 다소 논란거리가 될 수 있습니다.
그러나, EUC-KR이 우리나라에서 폭넓게 받아들여지고 있는 인코딩 이름이라고
주장할만한 증거 문서를 대기가 곤란하여, 썬사에 bug report를 내기도
곤란하더군요.
p.s. 역시, 이런 문제를 다루는 것은 재미없군요. 또, 저 역시 이쪽
방면으로 전문 지식을 갖고 있는 것은 아니라서...
===== 참고문헌 =======
[1] http://www.globecom.net/(nobg,sv)/ietf/rfc/rfc2130.shtml
[2] ``The Unicode Standard, Version 2.0,'' The Unicode
Consortium, Addison Wesley, 1996
[3] http://www.unicode.org/unicode/standard/principles.html
Follow Ups:
보충... 김덕태 12:34:40 7/05/97 (1)
UTF-8 인코딩과 16 비트 인코딩과의 비교, 인코딩 변환 자바 프로그램 김덕태 17:28:38 7/07/97 (0)
http://wwwcs.dongguk.ac.kr/~byunjy/KLE
4.3 ISO 10646과 유니코드
http://wwwcs.dongguk.ac.kr/~byunjy/KLE/k43.html
1983년에 시작한 ISO 10646의 네 바이트 가운데 두 바이트 기본다국어 판(UCS-2)과 1985년에 비공식으로 발족되어 두 바이트 코드계를 추구하여 온 유니코드와는 91년 프랑스 르노회의에서 통합의 발판을 마련한 다음 92년 ISO 22차 서울회의에서 통합된 형태로 발전하였다[18]. 유니코드는 기본적으로 ISO 2022의 제어문자영역과 도형문자 영역의 구별을 없애고 두 바이트 전체 65536을 문자코드판으로 하여 92년 유니코드 버젼 1.0이 출판되었다[19]. ISO 10646의 기본 다국어 문자판(BMP) 역시 16비트 전 체를 문자코드판으로 하고 제어문제영역 사용을 금지시켰으며, 92년 국제 표준으로 확정되고 93년 5월에 국제표준으로 정식 출판되었다. 곧 이러 한 국제표준을 채택한 소프트웨어가 개발될 것이며 실제로 마이크로 소프 트는 개발을 진행하고 있다.
두코드계는 모두 세계의 모든 문자를 표시할 것을 목표로 하고 있다. 그런데 여기서 문제가 되는 나라의 문자가 곧 한자를 쓰는 극동의 삼국 한국, 중국, 일본이다. 한국은 더욱 문제가 되는 나라로 지목되고 있는 데 그것은 한글의 글자집단이 커기 때문이라 한다. 이것은 문제가 아닐 수 없다. 세계에서 가장 과학적이고 독창적이라는 문자가 어떻게 문제의 문자인가? 그것은 조건제시법이 아니라 원소나열법으로 한글을 취급하려 는 태도 때문일 것이다.
"KSC 5700"의 제정 의미와 전망
(전자신문 95년 12월 7일자)
일명 유니코드로 통하고 있는 국제문자부호계(UCS)가 드디어 KS표준규격으 로제정됐다. 국제문자부호체계란
한마디로 만국공통의 컴퓨터용 문자코드를 말한다. 이 코드는 지난 9월 국제표준기구(ISO)의
문자코드분과위(JTC1.SC2) 에서 통과된 것으로서 정식명칭은 "ISO.IEC 10646-I"(약칭 10646-I). 공업진 흥청이 이번에
"KSC 5700"으로 제정한 코드는 바로 "10646-I"과 내용적으로 일치하는 것이다. "KSC 5700"제정의 의미와 전망 등을
알아보려면 우선 이 " 10646-I"이 어떤 코드시스템인가를 알아볼 필요가 있다. "10646-I"은 문자 하나에 부여되는
데이터 값을 모두 16비트로 통일、 문자간 호환성을 중시하 고 있는 것이 가장 큰 특징이다. 이를테면 영어 알파벳
문자와 한글문자 하 나의 값이 모두 16비트라는 얘기다. 이는 현재 각국이 사용중인 코드의 1문 자당 값이 영어의
경우 7비트、 비영어는 8비트、 한글이나 일본어는 16비트 등 제각각 다르다는 데 따른 불합리성을 해소、
다국어호환성을 제고하기 위 한 것이다.
"10646-I"의 문자판(Plane)에는 영어.일본어.중국어(일부).히브리어.태국 어.아랍어.말레이어 등 전세계에서 사용하고
있는 26개 언어의 문자와 특수 기호 등 4만7천2백68자에 대해 일일이 코드값을 부여하고 있다(최대 수용문 자수는
6만5천5백36자).
이 가운데 한글에 부여된 코드체계는 현대 한글에서 구현할 수 있는 최대 글자수 1만1천1백72자를 가다다순으로
배열해놓은 완성형 부분(HANGUL、 AC 열)、 일명 첫가끝조합형으로 알려진 한글자모 2백40자 부분(HANGUL
JAMO、 11열)、 현재 표준인 KSC 5601의 조합형 한글자모 94자 부분(HANGUL COMPATI BILITY、 31열) 등
3덩어리로 돼 있다. "KSC 5700" 제정에는 바로 이 복수코 드를 모두 표준으로 인정했다는 것을 의미한다.
"10646-I"을 그대로 수용하는 "KS 5700"의 제정은 표면적으로 2가지 의미 가있다. 하나는 국제적으로
외국소프트웨어(ＳＷ)、 특히 영문판SW의 한글화 가크게 간편해졌으며 반대로 국산SW의 외국어판 제작도
쉬워지게 됐다. 물론 이것은 각국이 "10646-I"을 자국 표준으로 정하고 이를 토대로 ＳＷ를 다량 으로 개발하는 것을
전제로 한 것이다.
두번째로는 이 코드 제정으로 그동안 구심점이 없던 한글코드체계 논쟁이 일단 몇 개의 큰 줄기로 방향이 잡혔다는
점이다.
그러나 분명한 것은 "KSC 5700"이 제정됐다 해서 당장 현재의 한글코드 논 쟁이 불식되는 것은 아니라는 사실이다.
"KSC 5700"의 제정에 의해 논쟁의 방향이 잡히게 될 부분은 우선 한글이 표현할 수 있는 모든 글자수인
1만1천1백72자를 가나다순 배열로 코드값을 부여함으로써 일단 기존 "KSC 5601"과 "한글윈도우95" 통합형 코드의
문제점 을극복할 수 있는 길이 열렸다는 것이다.
물론 이같은 문제점이 극복되려면 세계적으로 "10646-I"의 채택이 보편화 되고 국내 ＳＷ회사들도 이를 전폭적으로
지원해야 한다.
반면 "KSC 5700"으로도 풀릴 수 없는 매듭은 컴퓨터에서의 한글 구현을 조 합형 방식으로 할 것인가、 완성형
방식으로 할 것인가라는 점이다.
앞서 지적했던 것처럼 "KSC 5700"에는 완성형 방식의 1만1천1백72자뿐 아 니라 기존 조합형 자모94자、 새로운
첫가끝조합형 자모 2백40자가 동등한 자격으로 들어 있다.
이같은 사실은 줄기차게 조합형을 옹호해온 이들에게 오히려 지금까지의 논쟁에서보다 훨씬 강도 높은 주장을 펼칠
수 있는 단서를 제공하고 있는 셈 이다. 이런 단서는 반대로 완성형 주장자들에게도 똑같이 제공되고 있다. 결 국"KSC
5700"이 정착된다 하더라도 논쟁의 불씨는 수그러들지 않고 오히려 화력이 더 세질 가능성이 있다는 얘기가 된다.
이런 상황에서의 변수가 바로 "한글윈도우95"와 같은 운용체계를 공급하는 마이크로소프트(MS)의 역할이다. MS는
"KSC 5700"시대에도 여전히 자의반 타 의반으로 완성형과 조합형 논쟁에 대한 캐스팅보드를 쥐게 될 것으로 보인 다.
즉 MS가 운용체계 수준에서 어떤 방식을 지원하느냐에 따라 대세가 결정 될수 있다는 것이다.
그런데 지금까지 공식.비공식으로 드러난 바에 따르면 MS가 앞으로 새로 개발할 "한글윈도우9 " 및 "한글윈도우NT"
차기버전에서 "KSC 5700" 내의
조합형을 지원하게 될 가능성은 거의 없어 보인다. 이와 관련해 MS는 현재 " 한글윈도우95"에 채택하고 있는 통합형
코드가 기존 2천3백50자의 "KSC 5601 "완성형과 국제문자부호계 기반의 새로운 "KSC 5700"을 연결시켜주는 징검다
리라고 믿어 의심치 않고 있는 상황이다.
이에 따라 새로운 국가표준코드가 제정됐음에도 불구하고 우리 정부나 업 계의 입장은 여전히 지금처럼 MS의
캐스팅보드에 따라 좌우될 수밖에 없을 전망이다. 이는 "KSC 5700"의 모태가 된 "ISO.IEC 10646-I" 자체가 미 MS에
의해 주도된 유니코드 규격에 기반하고 있다는 태생적 한계 때문이다. <서현진기자> 발 행 일 : 1995/12/08
"유니코드"설명회 지상중계
http://www.hanyang.co.kr/ETNEWS.htm#유니코드설명회
전세계 주요 컴퓨터회사들이 업계표준으로 규정한 만국공통 문자코드 "유니코드" 설명회가 본사 주최로 16일 서울 롯데호텔에서 열렸다. 주제는 지난8월 스위스 국제표준화기구(ISO)가 국제문자부호계(UCS)로 받아들인 최신 "유니코드2.0"과 이를 토대로 지난해 12월7일 공업진흥청이 확정한 "KSC 5700"에 관한 내용이었다.
주요내용을 소개한다. <편집자주>
<>"유니코드2.0"의 개요(어스무스 프라이택박사/유니코드 컨소시엄)
유니코드 컨소시엄은 91년 만국공통의 문자코드를 제정, 보급하기 위해 창설됐으며 현재 북미.유럽.아시아등에서 45개 주요기업이 참여하고 있다. 최근 "유니코드2.0"을 출판했으며 국가 단위의 국제기구인 ISO와 공동표준규격 마련 및 개발자 기술지원서비스를 병행하고 있다.
"유니코드2.0"에는 모두 6만5천5백36자(OXOOOO~OXFFFF)의 코드영역이있는데 이 가운데 3만8천8백85자는 주요 국가언어 구현용으로 이미 할당돼있고6천4백자는 사용자 정의 영역(Private Use Area)으로, 2만2백49자는 향후새로 추가될 언어영역(Future Use Area)으로 각각 비워두고 있다. 현재할당된 주요 언어는 아스키(미국표준정보교환코드).그리스어.라틴어.시릴문자.히브리어.타이어.기호문자(Symbols).함수문자(Punctuation).아 랍어.가나.
자모(Hangul Jamo).CJK(중.일.한 공통한자)영역.표의문자(한자).한글(HangulSyllables).대용문자(Surrogates) 등이다.
코드할당비율을 보면 한자가 39.89%(2만9백2자)로 가장 많고 그 다음이한글 17.04%(1만1천1백72자), 아스키 및 기호문자 10.39%(6천8백11자)등의순이다.
"유니코드2.0"의 설계원리는 16비트코드를 기본으로 모든 언어의 완전코드화와 코드체계 단일화, 코드의 등가성, 코드간 호환성 등이다.
<>"유니코드"와 서체(이재훈이사/한양시스템)
서체(Font) 제작시 고려돼야할 "유니코드"의 특징으로는 새롭게 개정된코드매핑, 한글 1만1천1백72자의 지원 다국어서체 호환가능성 등이다.
"한글윈도우95"에서 구현되는 서체는 기존의 트루타입(TTF)과 유니코드규격, 1만1천1백72자의 한글 등이 고려돼야 할 것이다. "한글윈도우95"에서 사용되는 글자수는 영문 1백28자, 기호문자 9백86자, 한글
1만1천1백72자, 한자4천8백88자 등 총 1만7천1백74자나 된다.
현재 한글문자코드로는 기존의 완성형과 조합형 및 "유니코드2.0"기반의 "KSC 5700"등이 있다. 서체의
글리프(Glyph)구성방식으로는 완성자형(Simple), 자소조합형(Composite)등이 있다. 바람직한 한글서체를
개발하기 위해서는서체품질의 향상과 기하급수적으로 증가하는 글리프 데이터의 양을 억제하는방안 등이
강구돼야할 것이다.
"유니코드"용 한글서체 개발시 선결해야 할 문제들로는 "KSC 5700"의 경우자모 및 고어부문의 구현을 비롯,
고어의 자소조합문제 해결과 자소축소분야의 중복부문 제거, 글리프 데이터의 최소화, 한자의 자소조합형화
등이다. 일본의 리코사와 대만의 다이나랩사의 문제해결방법은 좋은 예가 될 것이다.
<>"유니코드"와 "KSC 5700"(강태진이사/한글과컴퓨터)
한글코드는 74년 7비트코드와 8비트 보조코드로 된 "KSC-5601-1974"로 처음제정됐고 82년에는 74년 버전에
16비트 보조코드를 포함시킨 "KSC-5601-1982"가 나왔다. 이어 87년에는 16비트코드를 준수(ISO 2022)하는
완성형 2천3백50자의 "KSC 5601-1987"이 제정됐다. 이 코드는 89년 개정에 이어 92년조합형을 수용하는
"KSC5601-1992"로 발전됐다.
유니코드와 한글코드의 관계를 보면 유니코드 컨소시엄이 91년 "유니코드1.0"을 제정했을 때 우리나라는
여기에 "KSC 5601"의 2천3백50자와 낱자(자모) 94자를 포함시켰다. 93년에는 ISO가 유니코드를 기반으로 "ISO
10646I"을제정했고 우리나라는 완성형자 6천6백56자와 자모 2백40자(일명 첫가끝)를포함시켰다.
95년 미국 실리콘밸리에서 있었던 유니코드 컨소시엄회의에서는 개정되는"유니코드2.0"에 한글완성형
1만1천1백72자를 포함시켰고 이어 8월 스위스 ISO회의에서 이 안이 통과돼 국제문자부호계로 채택됐다.
"유니코드2.0"과 국제문자부호계에 채택된 한글 1만1천1백72자는 모든 현대한글을 표현할수 있고 자소분리가
쉽다는 특징을 가지고 있다. 그러나 미완성 형태의 한글음절 표현이 어렵다는 단점이 있다. <서현진기자>
작성일자 : 1996.02.17
연 라이브러리 설명에서
http://www.shinbiro.com/~linuscom/kite32.html
About Kite32
수년 전에 필자가 연 한글 1.0이라는 조잡한 프로그램을 천리안에 올려놓은 적이 있습니다. 그때의
목적은 코렐 드로우 등과 같이 한글이 들어가지 않는 프로그램에서 어떻게든 한글을 쓰고자 하는
것이었고, 스스로 글자꼴을 그려가며, 따라서 엉성할 수밖에 없었습니다. (하여간 코렐에서 한글을
쓰자는 기본 목적은 달성했었음.) 세월이 바뀌어 NT가 개인용 컴에서 돌아갈 수 있고, 또 NT가
유니코드를 사용하면서부터 언젠가는 새로운, 좀 쓸만한 한글을 만들었으면 하는 것이 개인적인
바램이었습니다.
하지만 11,172자라는 엄청난 수의 글자꼴을 그려야 한다는 중압감 때문에 감히 손도 못 대다가 NT용
MSIE의 한글용 팩을 받아서 사용하던 중, 굴림체라는 유니코드가 들어있는 것을 발견하고 짬을
내어 작업에 들어가 이렇게 새 판을 내놓게 된 것입니다.
한 마디로 말해서 연 한글은 유니코드만을 사용합니다. 따라서 현재 많은 사람들이 사용하는
95에서는 사용할 수 없음을 미리 밝혀두는 바 입이다. 또한 기존의 완성형 문서와는 전혀 호환성이
없습니다. Microsoft 사에 의하면 95도 유니코드를 사용할 수 있다지만, 현재 필자는 그 방법을 전혀
알지 못하고 또 알고싶은 생각도 없습니다.
높이 나는 새가 떨어지면 더 아프다고, 95가 나오기 전까지 기대했던 만큼 실망이 크기 때문입니다.
다행히 한글 95가 비교적 안정된 작업을 해 준 덕분에 많은 사람들이 한글 95를 잘 쓰고 있기
때문입니다. NT 4.0이 95보다 월등하거나 동등한 성능을 내어주기 때문입니다. 또한 어차피 기존의
조합/완성형 문서는 조만간 모두 유니코드로 바뀌어질 것이기 때문입니다.
연 한글의 장점
필자의 실험에 의하면 만족하게 동작합니다.
앞으로 전 세계의 표준이 될 유니코드를 사용합니다.
윈도우즈 폴더안을 전혀 건드리지 않습니다. 따라서 언인스톨을 하고 싶으면 간단히 연 한글
폴더만 날려버리면 됩니다. (설치하는 굴림체 폰트는 제외)
연 한글의 단점
장점이자 단점. 유니코드를 사용하므로 기존의 문서와 호환성이 없고, 95에서 동작하지
않습니다.
연 한글의 숙제
그림은 스스로, 단추는 좀 예쁘게 그려야 합니다. (저는 예술가가 아닙니다.)
세벌식 자판을 지원하지 않습니다. 다음 판에선 혹시....
한자를 지원하지 않습니다. 이는 기술적 측면이기보다는 필자의 한자실력이 너무 부족하기
때문입니다. 또한 한글을 한자로 변환하는 공식이 없다는 것입니다. 한자씩 손으로(?) 변환해
주어야 합니다.
연 한글의 문제점
현재 유니코드를 사용하는 프로그램이 전무(필자가 테스트했던 제한된 경우)하다는
것입니다. 내부적으로는 유니코드로 동작한다는 NT에서 조차도 유니코드를 받아들이는 곳은
아무도 사용하지 않는 Notepad 와 Paint 뿐입니다. 이 두 군데서라도 유니코드를 쓸 수 있다는
것에 만족해야 되는 것인가요? 최소한 Wordpad에서는 동작하리라 기대 했었는데.... 시간이
해결해 주겠지요. (Office 97 에선 아직 실험하지 못했음.)
글자꼴이 적다는 것입니다. 아직 한글 NT를 접하지 않아서 알 수는 없지만, 현재 필자가
가지고 있는 글자꼴은 굴림체 하나 뿐 입니다. 역시 시간이 해결해 줄 것입니다.
한글과 코드(**)
http://suny.multi.co.kr/~leesl/code/
<html>
<head><title>Code and Hanggul [한글과 코드]</title></head>
<body>
<p>
<center><font size=5> 코드와 한글 [Code and Hangul]</font></center>
<p>
<p align=right>97/06/01<br>
<a href="mailto:leesl@multi.co.kr">이 상 로</a>
</p>
<ul>
<li>1. 서문
<li>2. <a href="character.html">코드에 관한 기본 지식 </a>
<a href="../hwp/character.hwp">
(character.hwp 88K) </a>
<ul>
<li>2.1 최초의 바이너리 코드
<li>2.2 아스키 코드
<li>2.3 94개 문자
<li>2.4 아스키 이후 8비트 코드
<li>2.5 16, 32비트 코드
</ul>
<li>3. <a href="concept.html">코드에 관한 개념및 용어</a>
<a href="../hwp/concept.hwp"> (concept.hwp 93K) </a>
<ul>
<li> 3.1 ISO/IEC 2022의 기본개념
<li> 3.2 코드 테이블 (전반적 구성과
표기법/구조/Escape sequence)
<li> 3.3 코드 요소 (G0/G1/G2/G3 C0/C1 제어기능)
<li> 3.4 코드 레퍼토리
<li> 3.5 용어 정리
</ul>
<li>4. <a href="application.html">문자셋과 응용프로그램 환경 </a>
<a href="../hwp/application.hwp"> (application.hwp 5K)</a>
<li>5. <a href="graphic.html">그래픽 문자(Graphic Character)</a>
<a href="../hwp/graphic.hwp"> graphic.hwp 36K</a>
<ul>
<li>5.1 94, 96문자셋(character set)
<li>5.2 단일바이트와 다중바이트의 문자셋
<ul>
<li>문자셋의 중첩
<li>중첩된 문자셋의 코딩
<li>한국, 중국, 일본의 국가표준문자
<li>가변길이 문자코딩
</ul>
<li>5.3 문자를 통한 조합
</ul>
<li>6. <a href="control.html">문자셋과 제어기능(Control Functions)</a>
<a href="../hwp/control.hwp"> control.hwp 56K </a>
<ul>
<LI>6.1 제어기능문자 기본셋
<li>6.2 제어기능문자 보조셋
<li>6.3 Escape sequences
<ul>
<li> 일반적 구조
<li> 2바이트 escape sequences
<li> 중간바이트가 있는 escape sequences
</ul>
<li>6.4 코드확장
<ul>
<li> Locking shifts
<li> Single shifts
<li> 제어기능문자셋의 지정
<li> Announcement functions
</ul>
<li>6.5 Control sequences
<li>6.6 Control strings
<li>6.7 Control functions for text communication
</ul>
<li>7. 지금까지의 내용정리및 rfc 1557(iso-2022-kr) 해석
<ul>
<li> <a href="1557exp.html"> 내용정리및 ISO-2022-KR의 이해</a>
<a href="../hwp/1557exp.hwp"> (rfc1557.hwp 62K)</a>
<ul>
<li> 1. 내용정리
<ul>
<li> 코드화의 필요성
<li> 주어진 비트배열의 영역 구분(코드테이블)
<li> 코드 확장
<li> 지정(designation)하는 방법
<li> 호출(invocation)하는 방법
</ul>
<li> 2. 2바이트 문자와 KSC 5601-1987
<ul>
<li> 중첩된 문자셋
<li> KSC-5601-1987
</ul>
<li> 3. ISO 2022-KR
</ul>
<li> <a href="../ecma/e035-doc.exe">ISO 2022 원문</a>(꼭읽어 보세요. e035-doc.exe 138K)
<li> <a href="../rfc/rfc1557.txt"> rfc 1557 원문 </a>
<li> <a href="rfc1557draft.html">rfc1557 수정(안)</a>
<a href="../hwp/rfc1557draft.hwp">(rfc1557draft.hwp 33K)</a>
<li> <a href="http://xp6.dejanews.com/dnquery.xp?search=thread&filter=&svcclass=dnold&threaded=1&HIT_CONTEXT=865050896.25045&HIT_NUM=8&recnum=%3ccleanqp.328BB506.15BD@hen.nca.or.kr%3e%233/3">
rfc1557 수정(안)과 관련된 논쟁</a>
</ul>
<li>8. 한글 코드
<ul>
<li><a href="http://www.ewos.be/tg-cs/gtop.htm">코드에 관한 배경지식</a>
<li> 7bit/8bit/ksc5601
<li><a href="isounicode.html"> ISO 10646-1/Unicode 1.1
및 국제표준 한글 부호계의 소개(김경석교수님) </a>
<a href="../hwp/isounicode.hwp"> (HWP 484K)</a>
<li><a href="10646.html"> 국제 표준 한글 부호계 운용방안에 대하여(김경석 교수님) </a>
<a href="../hwp/10646.hwp"> (HWP 37K)</a>
<li><a href="http://www.dongguk.ac.kr/~byunjy/KLE/k000.html">
훈민정음 창제 원리의 공학화에 기반한 한글코드의 발전 방향</a>
, <a href="mailto:byunjy@wonhyo.dongguk.ac.kr">
(변정용 교수님)</a>
<li> hcode(이준엽님)소스에 있는 한글코드에 관한 내용<br>
<a href="../hcode/CODE.def">한글코드</a>,
<a href="../hcode/johap.intro">조합형 소개</a>,
<a href="../hcode/johap.sugg">조합형 제안</a>,
<a href="../hcode/uni.code">유니코드1</a>,
<a href="../hcode/uni.sum">유니코드2</a>,
<a href="../hcode/uni2.sum">유니코드3</a>,
<a href="../hcode/tbl.cons">자음</a>,
<a href="../hcode/tbl.vow">모음</a>,
<a href="../hcode/try.roman">로만</a>
<li> 정주원님의 한글 관련글<br>
<a href="http://simac.kaist.ac.kr/~jwjung/seminar/hangul-i18n/ko-code.html">
한글코드에 대하여</a>,
<a href="http://simac.kaist.ac.kr/~jwjung/seminar/hangul-i18n/iso10646.html">
ISO 10646</a>
<li> 윈도우 95/NT에서 한글 (유니코드)<br>
<a href="http://www.seodu.co.kr/~juria/hangul/">
http://www.seodu.co.kr/~juria/hangul</a>
<li> han.comp.* 뉴스그룹에 올라왔던 한글코드관련 글모음
<ol>
<li><a href="../code/q1.html">
문자셋(character set)과 인코딩과는 어떤 차이가 있습니까?</a>
</ol>
<li> CJK 코드관련 사이트
<ol>
<li><a href="ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf">
Ken Lunde님의 CJK Information</a>
<li><a href="http://www.ora.com/people/authors/lunde/cjk-char.html">
Ken Lunde님의 CJK Information 2</a>
<li><a href="http://www.ifcss.org/ftp-pub/software/info/cjk-codes/">
Ross Paterson님의 CJK information </a>
<li><a href="http://stonehand.com/unicode/faq/cjk.html">
CJK와 East Asian Issues</a>
</ol>
</ul>
<li>9. 유니코드와 ISO 10646
<ul>
<li><a href="http://unicode.org">유니코드 공식 홈페이지</a>
<li>유닉스 소프트웨어 국제화을 위한 개념 정리<br>
<a href="http://cns-web.bu.edu/pub/djohnson/web_files/i18n/i18n.html">
http://cns-web.bu.edu/pub/djohnson/web_files/i18n/i18n.html</a>
</ul>
<li>10. 코드변환 프로그램
<ul>
<li> hcode
<ul>
<li> <a href="../hcode/README">README</a>,
<a href="../hcode/README.mailpatch"> README.mailpatch</a>
<li> <a href="hcode.html">컴파일및 설치</a>
<a href="../hwp/hcode.hwp">(hcode.hwp 6K)</a>
</ul>
<li> hmconv
<ul>
<li> <a href="../hmconv/readme.html">README</a>
<li> <a href="../hmconv/hmconv1.0pl3.c">컴파일및 설치</a>
</ul>
<li> 나랏말씀 (첫가끝 부호체계에 의한 옛한글 문서 편집기)
<ul>
<li> <a href="http://asadal.cs.pusan.ac.kr/ohwp/index.html">
http://asadal.cs.pusan.ac.kr/ohwp/index.html</a>
</ul>
</ul>
<li><a href="http://www.ewos.be/tg-cs/gindex.htm">11. 각종 표준 </a>
<ul>
<li><a href="http://www2.echo.lu/oii/en/chars.html">Character Set Standards</a>,(문자셋표준에 관한 모든것)
<li><a href="http://www.iso.ch">ISO 공식 홈페이지</a>
<li><a href="http://www.ecmanews.ecma.ch">http://www.ecmanews.ecma.ch</a>, ECMA 홈페이지</a>
</ul>
<li><a href="characterlink.html">12. 문자코드와 관련된 자료</a>
<ul>
<li><a href="ascii-code.gif">아스키 코드표</a>
<li><a href="johap.gif">조합형 코드표</a>
<li><a href="ksc5601-char-list.html">KSC 5601 문자표 (텍스트 버전)</a>
<li><a href="ksc-1.gif">KSC 5601 한글부분 1</a>,
<a href="ksc-2.gif">2</a>,
<a href="ksc-3.gif">3</a>,
<a href="ksc-4.gif">4</a>,
<a href="ksc-5.gif">5</a>
</ul>
<li>13. 코드와 폰트
<ul>
<li>각국의 코드와 그에 해당하는 폰트는 어떻게 만드는가에 관한 내용<br>
<a href="http://staff.sb.aol.com/gww/fonts/Charsets.html">
http://staff.sb.aol.com/gww/fonts/Charsets.html</a>
</ul>
<li>14. 한글 뉴스그룹
<ul>
<li><a href="news:han.comp.hangul">han.comp.hangul</a>
<li><a href="http://geo2.skku.ac.kr">http://geo2.skku.ac.kr</a>(HTML 형식으로 han.comp.hangul 글을 모아둠)
</ul>
<li>15. 기타
<ul>
<li><a href="http://ktmp.kaist.ac.kr/~geenie/news/hangul.html">
KSC 5601, 5700이 만들어 질때의 상황</>
<li><a href="http://www.stri.is/TC304/default.html">
유럽 표준위원회의 문자셋에 관한 노력</a>(상당히 참고할만 함)
<li><a href="ftp://dkuug.dk/">각종 문자표준과 유럽의 코드표준 연구자료들이 있음</a>
<li><a href="http://bulsai.kaist.ac.kr/~ysyun/Mail-Archives/hangul/95.12/0037.html">
리눅스에서 유니코드 지원 (95/12/16)</a>
</ul>
</ul>
</ul>
<dl>
<dt><a href="../mail/index.html">저의 센드메일 페이지로 이동</a>
<p>
<dt><a href="../procmail/index.html">저의 Procmail 페이지로 이동</a>
<p>
<dt><a href="http://www.sendmail.org"> 센드메일 공식 홈페이지 </a>
<dd> 센드메일의 공식 홈페이지 입니다.
<dd> 센드메일과 관련된 모든 자료가 연결되어 있습니다.
<p>
<dt><a href="http://www.his.com/~brad/sendmail/index.html">
브래드 크놀스님의 글 </a>
<dd> 센드메일 faq부터ssl과 같은 메일통계 프로그램이
<dd> 있으며 몇몇 센드메일 트레이닝 페이지와 연결하고 있습니다.
<p>
<dt><a href="http://pantheon.yale.edu/~jshin/faq/qa9.html"> 신정식님의 메일관련글</a>
<dd> 바이블에 가까운 신정식님의 글입니다.
<dd><a href="http://pantheon.yale.edu/~jshin/faq/procmail.html"> Sendmail 8.8.x와 Procmail을 이용한 한글 메일 처리</a>
<p>
<dt><a href="../others/cypark.html">박천용님의 한글센드메일</a>
<dd> 박천용님이 4회 워크샵에서 발표한 자료입니다<br>
원래 소스는 <a href="http://www.kisco.co.kr/ws4/D21/">http://www.kisco.co.kr/ws4/D21/</a>에 있습니다.
<p>
<dt><a href="http://entropy.kaist.ac.kr/~jhpark/kesmpre/README.html"> 박재현님의 가짜 센드메일</a>
<dd> 한글센드메일중 한글처리부분만 뽑아 한글을 처리합니다.
<p>
<dt><a href="http://simac.kaist.ac.kr/~jwjung/seminar/hangul-i18n/"> 정주원님의 한글과 국제화(I18N)</a>
<dd>
ISO/IEC-10646 Universal Multiple-Octet Coded Character Set (UCS)에 대해서 <br>
<dd> 한글 코드에 대하여 다룹니다.
</dl>
</body>
</html>
http://suny.multi.co.kr/~leesl/hcode/uni.code
======================================================================
KSC 5601 & 5657
======================================================================
21-22 simbol
23 Full width ASC
24 Hangul Jamo
25 Greek, numbers
26 Graphical Forms
27 Kw, FM so on
28 Latin oE.. , Circles GiYeok, 1/2
29 ...
2a-2b Katakana, Hiragana
2c cyrilic
3021-487e Hangul (2350)
4a21-7d7e Hanja (4888)
KSC-5657 : 5721-75c4 Hanja (2856)
======================================================================
Hangul related codes in Unicode, IS010646-BMP
======================================================================
1. Hangul Jamo Alphabet (1100-11FF)
1100-1159(90 chars) choseong (syllable-initial)
115f choseong filler
1160 jungseong filler
1161-11a2(66 chars) jungseong(syllable-peak)
11a8-11f9(82 chars) jongseong(syllable-final)
2. CJK Auxiliaries
302E HANGUL SINGLE DOT TONE MARK
302F HANGUL DOUBLE DOT TONE MARK
3131-318E : KSC A4 Page
31A1-31FE : Combinig Hangul Jamos (duplication of 3131-318E) Deleted
3200-0D(14Chars) : (K) ... (H)
320E-1C(14Chars) : (KA) ... (HA)
3260-6D : circled (K) .. (H)
320E-1C(14Chars) : circled (KA) ... (HA)
327F KOREAN STANDARD SYMBOL
3. Hangul Precombined Syllable Forms (3400-4DFF)
3400-3D2D (2350) ksc5601
3D2E-44B9 (1932) ksc5657(?)
44B[ABCD] (4) PPOTH, PPUTH, CCWESS, WEOLS
44BE-4DFF (2370) -> MWEOLS
4. CJK Ideograph Compatibility & Other compatibility (F900-FFDF)
F9XX-FAXX Some Hanja
FFA0-FFBE : Halfwidth Fill + Final
FFC2-FFDE(6blank): Halfwidth Vowel with Sambo Code
======================================================================
Unicode, ISO10646 - BMP
======================================================================
No characters are currently assigned to codepoints (bit combinations) outside
of UCS2 (also called the Basic Multilingual Plane or BMP for short). Out
of the 65,536 distinct bit combinations in UCS2, 34,168 are assigned to
characters, 6,467 are reserved, and 24,901 are available for future assignment.
The UCS2 encoding space is divided into sections, whose contents are
characterized below:
A-Zone (Alphabetic) (11,892 assigned, 65 reserved, 8,011 available)
Alphabets
Hangul Jamo Alphabet (1100-11FF)
Latin & Greek Precombined Forms
Symbols
CJK Auxiliaries
Hangul Precombined Syllable Forms (3400-4DFF)
I-Zone (Ideographic) (20,902 assigned, 0 reserved, 90 available)
CJK Unified Ideographs (4E00-9FFF)
O-Zone (Open) (0 assigned, 0 reserved, 16,384 available)
Unassigned (A000-DFFF)
R-Zone (Restricted) (1,374 assigned, 6402 reserved, 416 available)
Private Use Area (E000-F8FF)
CJK Ideograph Compatibility (F900-FA2D?)
Presentation Compatibility
Other Compatibility & Specials
---
Sorry to write in English. My typing in Hangul is very poor.
Once upon a time, there were two big guys named
International Standard Org (ISO) and Unicode Consortium
(A US software and hardware vender consortium). Each of
them though he is the only one who can make a universal
code set so he planed to make it. DIS-10646 from ISO,
Unicode 1.0 from Unicode consortium were the names.
DIS-10646 was a super set of various National standards
in 32-bit space and Unicode 1.0 merges all Hanja used
in China, Korea and Japan and save the code space so
they can fit all possible characters in 16-bit space.
There couldn't be two suns in the sky and they reallize
that they should work together instead of fighting
against each others. May 1991 they agree to make one code set.
At this point, every work was done. Draft of International
standard becomes an IS-10646 by defining 16-bit space char(UCS-2)
(among 32-bit full-possible work space) identical to Unicode 1.1.
And Unicode 1.0 was added with more characters defined in old DIS.
So strictly speaking, Unicode 1.1 is just an implementation of
IS-10646 UCS-2 level 3.
Unfortunately Hangul space was restricted to 6566 Chars
(less than 19*21*28 ~ 11KB to cover all modern syllables).
In addition to 6566 "Precomposed Hangul Syllables"
(WanSungHyeong Hangul in common name in Korea),
240 Modern and Ancient Hangul Jamos (in 1100-11FF)
(90+1 Choseong, 1+66 Jungseong, 82 JongSeong)
were allocated in Alphabet space (0000-1FFF).
This Jamos will be combined to make a graphical
representation of un-precomposed hangul syllables.
Two volume books, Unicode 1.0, were the only information
published but Hangul part was changed so much that
you can't use the book. Changes from Unicode 1.0 to
Unicode 1.0.1 and some more informations can be found
from ftp@unicode.org. Two Mailing list, ISO10646@jhuvm.bitnet
and unicode@sun.com are alive but no so useful.
Final document, IS-10646 is in printing process.
If you need more information, please tell me at
June-Yub Lee <jylee@kitty.cims.nyu.edu> or
Prof Kim Kyongsok <kskim@HYOWON.PUSAN.AC.KR>.
Good Bye.
June-Yub Lee
--
이 글은 최근 관심의 대상이 되고 있는 Unicode/ISO10646-BMP중에서
한글에 관한 간략한 해설을 세부분으로 나누어 설명한 것입니다.
A. 한글 Code Points
B. Unicode와 ISO10646-BMP의 관계
C. ISO10646의 level 1-3의 정의
도움이 되시기를.
이 준엽. at Courant Institute in New York Univ.
A. 한글 Code Points in ISO 10646-BMP/Unicode 1.1
-----------------------------------------------------------------
. BMP is a 2byte char set in ISO 10646 and chars set in Unicode 1.1
has been changed to be identical with ISO 10646-BMP
. Spacing and nonspacing consonant and vowel
has been deleted in the final IS.
1. And we have the following codepoints in BMP:
6656 Precomposed chars : 3400 - 4dff (26pages*256char/page)
2. the codepoints of 240 hangul jamos are as follows accoreding to N868:
choseong (syllable-initial): 1100 - 1159 (90 chars)
choseong filler 115f
jungseong filler 1160
jungseong(syllable-peak) : 1161 - 11a2 (66 chars)
jongseong(syllable-final) : 11a8 - 11fa (82 chars)
^^^^ cf) 11f9-should be
From: kskim@hyowon.pusan.ac.kr(kyongsok kim)
B. Unicode와 ISO10646-BMP의 관계
------------------------------
Unicode 1.1 is an implementation of level 2 (new level 3).
From: "K. Smith-Yoshimura" <BL.KSS%RLG@Forsythe.Stanford.EDU>
C. ISO10646의 level 1-3의 정의
----------------------------
장형규님 글 중에서,
C:우형님> 제가 잘 모르는 점은 아래와 같습니다.
C:우형님>
C:우형님> Unicode Level 1 과 Unicode Level 2이 Exclusive한지?
C:우형님> Unicode Level 1 과 Unicode Level 2의 합이 Unicode Level 3인지?
C:
C:준엽님> Unicode는 3개의 level을 가지는데, level1에서는 6656개의
C:준엽님> Precomposed syllable과 240개의 한글 자모를 쓸 수 있고,
C:준엽님> level2에서는 6656개의 Precomposed syllable 로 표현 되지
C:준엽님> 않는 한글을 240의 Jamo로 Combine합니다. level3에서는
C:준엽님> 한글을 precomposed syllable이나, 240 Jamo combination
C:준엽님> 어느 것으로나 쓸수 있읍니다.
C:
C:> Date: Wed, 19 Aug 92 15:19:38 PDT
C:> To: unicode@Sun.COM
C:> From: "K. Smith-Yoshimura" <BL.KSS%RLG@Forsythe.Stanford.EDU>
C:> Subject: Hangul support
C:>
C:> Combining jamo are allowed in the new implementation level "1.5"
C:> adopted (as requested by the UK), as well as level 2 (unrestricted
C:> use of combining characters.) Implementation level 1 is unchanged
C:> (precomposed only). The new level 1.5 (which will be the new level
C:> 2, with current level 2 becoming level 3) creates a separate level
C:> for scripts where no precomposed characters normally exist, and,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:> therefore, combining marks are mandatory, e.g., Indic scripts, Thai,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:> Arabic, Hebrew, etc. Korea specifically requested that combining
C:> jamos be included in this new level 2. Some of this was discussed
C:> on the ISO10646@JHUVM listserv.
C:
C:준엽님, 제가 그동안 국제 동향에 좀 무관심했었기에 여쭈어봅니다.
C:위에 있는 Smith Yoshimura의 오래된 편지에는 레벨 2에서는 완성형
C:글자가 하나도 없다고 되어있는데 지금은 바뀐 모양이죠? 최근의
C:동향에 대해 hangul@cair와 sg-inet으로 posting을 해주시면 감사하겠습니다.
92년 6월 Seoul Meeting에서 최종 IS 10646이 나오기 직전에,
비공식적으로 level 1에 있는 모든 precomposed(완성형) 한글을
삭제하고, level 2에서 combining jamo들로만 Hangul을 쓰자는
의견이 있었읍니다. 그러나, 이 안은 한번도 공식적인 ISO/unicode
spec이 된 적이 없읍니다. 위에서 보듯이, final IS10646 level 2에서의
jamo comination은 완성형 글자가 없는 경우에 한하여 (scripts where
no precomposed characters normally exist) 사용되도록 되어있읍니다.
즉 모든 code point는 unique합니다. 'Kak'을 'K','a','k'으로
사용하는 것은 level 2에서는 허용되지 않읍니다. 하지만,
'KK','yu','lm'과 같이 완성형이 BMP에 없는 경우는
3code points * 2byte/code points = 6byte로 표현 합니다.
보다 정확한 level 해설은 다음의 discussion에서 볼 수 있읍니다.
-------------------------------------------------------------
From: SCHEIN@TOROLAB5.VNET.IBM.COM
Date: Wed, 2 Sep 92 17:22:25 EDT
S:>- Does level 2 only allow combined characters ?
S:> For example, can you use "A with Diaeresis (code point C4)" in level 2 ?
S:Level 2 includes all characters from Level 1. "A DIAERESIS" is in level2.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ISO 10646 level1,2,3 는 upward compatible scheme입니다.
S:>- If you mix precomposed characters and combined characters,
S:> is it always considered level 3 ?
해답은 combined characters가 precomposed set in BMP에
속해 있느냐, 그렇지 않으냐에 따라 달라집니다.
combined character 들이 BMP에 없었다면 대답은 NO 입니다.
그러나, S:Practically YES.
S:Level 2 is simply defined by a list of combining characters which
S:are allowed in this level. But the combining characters in this list
S:have been chosen from the scripts where precomposed are not usually
S:used, for example, Thai and Indic scripts. But theoretically, if
S:tomorrow some precomposed Thai characters will be added, Thai combining
S:characters will still remain in level 2. Essentially the same effect
S:could be achieved by using subsets.
S:>- If someone chooses to use only combined characters in korean
S:> implementation, do you say "level 2" or do you still say "level 3"
S:> only because there are code points for some korean precomposed
S:> characters in ISO-10646?
S:
S:Yes, it is still level 3. This level 2 & 3 scheme is far from perfect,
S:and, personally, I would rather do without.
S:
S:>Note that not all Korean syllables can be represented by precomposed
S:>characters.
S:
S:Yes, I know. The same is true for Latin script. This is why we have
S:level 3.
S:
S:-Isai
끝으로 우형님의 질문에 답하면, level 1,2,3 는 upward compatible
scheme입니다. 그러나, 그 사용 방법이나 목적이 상이하여 level 3
를 level 2의 upgraded version으로 사용하지는 않을 것이라는 것이
제 추측입니다. level 3은 precomposed와 combining jamo를 random하게
섞어 쓰는 scheme 이라기 보다는, level2 scheme이나 combination method
둘 중의 어느 것이나를 사용자가 정하도록 허용하는 sheme이 될것 같읍니다.
http://simac.kaist.ac.kr/~jwjung/seminar/hangul-i18n/iso10646.html
95/11/11
정 주 원
ISO/IEC-10646 Universal Multiple-Octet Coded Character Set (UCS)에
대해서
1. 개요
흔히 Unicode로 알려져 있는 ISO-10646 UCS (원명: ISO/IEC-10646:1993 Information technology -- Universal Multiple-Octet
Coded Character Set, 이하 ISO-10646이라 칭한다.)는 4바이트로 한 문자를 나타냄으로써, 보다 일반적인 문자 처리가
가능한 문자 집합과 그 부호화를 정의한다.
2. Canonical form과 BMP
ISO-10646은 문자집합의 보다 일반적인 적용을 위해서 canonical form이라는 개념을 사용한다. 각 문자는 문자들끼리
서로 구분되기 위해 4 옥텟의 16진수 이름을 갖게 되는데, 이것을 canonical form이라 한다. 각 문자는 실제로 사용되기
위해 canonical form으로부터 적당한 방법으로 부호화 될 수 있다.
이것은 ISO-2022와 같은 종전의 문자 표준이 코드영역에 직접 문자를 대응함으로써 문자 체계 자체에 제약이 주어진
것과는 달리, canonical form으로 문자 집합을 정해 놓고 그 사용환경에 따라 부호화 하는 방법을 바꿈으로써 코드
사용환경이 바뀌더라도 문자집합 자체는 변경되지 않도록 한 것이다.
그림 1. ISO-10646의 전체 부호화 영역
Canonical form의 부호 영역이 그림 1에 나타나 있다. 한 문자는 4바이트의 이름을 가지며, 각 옥텟은 그룹, 평면, 행,
셀의 의미를 가진다. 이 중에서 특히 그룹 00, 평면 00인 부분을 BMP(Basic Multilingual Plane)이라 부른 다. 현재
ISO-10646에서 문자가 실제로 할당된 부분은 BMP 뿐이다.
BMP는 다시 4개의 영역으로 나누어 지는데 각 영역의 특징은 다음과 같다.
A-zone:
alphabetic and syllabic scripts together with varios symbols
I-zone:
Chinese/Japanese/Korean (CJK) unified ideographs (unified East Asian ideographs)
O-zone:
reserved for future standardisation
R-zone:
restriced use zone (private use characters, presentation forms, compatibility characters, etc.)
그림 2. BMP(Basic Multilingual Plane)
Canonical form은 그 자체로서 하나의 32-bit 부호화가 될 수 있는데 이것 을 UCS-4라 한다. BMP역시 그 자체로서 16-bit
부호화가 될 수 있는데 이것 을 UCS-2라 한다.
3. UCS Transformation format (UTF)
ISO-10646은 현재의 기술 상황을 고려하여 한 글자를 4-octet으로 표현하도 록 하였다. 그러나 현재 환경은 한 글자를
한 바이트로 가정하고 있고, 또 한 그 가정을 기반으로 한 표준들도 있는 상황이다. (대표적인 예 ISO- 2022) 따라서,
ISO-10646에서 규정한 문자집합을 실제로 사용하려면 어느정 도의 변환이 필요하다. 이것은 UTF(UCS Transformation
format)이라 한다. 현재 제정되었거나 제정되고 있는 UTF들은 다음과 같다.
* UTF-1
ISO-2022에서 사용을 금하고 있는 C0, SPACE, DEL, C1 문자들을 사용하지 않도록 부호화 하는 방법이다.
ISO/IEC-10646:1993의 Annex G로 포함되어 있다.
* UTF-7
인터넷 메일과 같은 7 비트 ASCII 문자 전송을 원칙으로 하는 환경에서 사용하도록 고안되었다. 특히
US-ASCII에 해당하는 글자들은 변환을 해도 사람이 읽을 수 있도록 고안되었다. RFC-1642로 등록되어 있다.
* UTF-8 (UCS Transformation Format 8-Bit Form)
이것은 FSS-UTF(File System Safe Universal Character Set Transformation Format)이라고도 불린다.
UFS와 같은 화일 시스템에서, ISO-10646 문자집합을 화일 이름 또는 화일의 내용으로 사용하려면 ASCII
코드로 봤을때 NUL(0x00)문자나 slash(/)문자에 대한 처리가 필요하다. 또한 C언어의 문자열로서 사용하려면
중간에 NUL이나 backslash 문자가 포함되어서는 곤란하다. 이와 같은 문제를 해결한 것이 UTF-8이다.
이것은 ISO/IEC JTC1/SC2/WG2 N 1036 Amendment 2 to ISO/IEC 10646-1:1993 UCS Transformation Format 8
(UTF-8)으로 제출되어, ISO-10646 다음 버젼의 Annex P에 포함될 예정이다.
* UTF-16 (Transformation Format for 16 Planes of Group 00)
초기에는 UCS-2E(Extended UCS-2)라고 불렸다.
ISO-10646은 원칙적으로 4 옥텟이 한 글자이므로 16비트를 한 글자로 잡는다 하더라도 ISO-10646의 문자
집합을 제대로 사용한다고 볼 수 없다. 따라서 BMP이외의 평면을 사용할 경우를 고려하여 고안한 것이
UTF-16이다.
현재 ISO/IEC JTC1/SC2/WG2 N 1035 Amendment 1 to ISO/IEC 10646-1:1993 Transformation Format for 16 Planes of
Group 00 (UTF-16)로 제출되어 있다.
4. Unicode와 ISO-10646의 관계
ISO 10646은 국제표준기구 (ISO; International Standard Organization )와 국제전자기술위원회(IEC; International
Electrotechnical Commission )의 산하 위원회인 ISO/IEC JTC 1 (Information Technology) SC 2 (Coded character sets) WG 2
(Multiple-octet codes)에서 제정 중이던 국제표준이었다. 그에 비하여, Unicode 는 Apple, Metaphor, RLG, Sun, Xerox등이
1989년에 결성하여 만든 Unicode Working Group에서 컴퓨터에서 쉽게 지원해 줄 수 있는 다국어 지원을 목적으로
제정하던 업계 표준이었다.
1991년 Unicode Working Group은 Unicode, Inc.로 조직체계를 바꾸고, 지지부진하고 있는 ISO-10646의 다국어 부분을
Unicode사에서 제정하는 표준을 그대로 사용할 것을 국제표준기구에 제안, ISO-10646의 BMP부분은 Unicode와
동일한 내용을 가질 것을 결의하였다. 결국, ISO-10646중에서 UCS-2 BMP부분은 Unicode와 동일하다.
JTC: Joint Technical Committee
SC: Subcommittee
WG: Working Group
http://unicode.org 유니코드 공식 페이지
http://www.iso.ch
JDK 1.1의 문자세트/인코딩 지원기능
[ Follow Ups ] [ Post Followup ] [ 자바 묻고 답하기 ]
Posted by 김덕태 on August 01, 1997 at 19:47:11:
=== JDK 1.0에서의 문자세트 처리의 문제점
넷스케이프 3.0 이하 및 JDK 1.0은 내부적으로는 유니코드 문자로
처리하나, KSC5601을 비롯한 다양한 문자세트로 적절하게 변환시키지
못한다.
유니코드 문자를 출력할 때는, 유니코드 문자의 코드 값중 상위 바이트
값을 단순히 잘라내고, 입력할때는 입력 바이트에서 상위 바이트 값으로
0을 붙여 유니코드 문자를 만든다. 이는 실질적으로 한글을 포함한 모든
문자가 "8859_1" 인코딩으로 인코딩되어 있다고 가정하는 것과 같으며,
자바가 내부적으로 유니코드로 처리해봤자 아무런 의미를 갖지 못한다.
일부 유니코드 문자와 바이트 배열로 변환하는 메쏘드 중 이와 같이 잘못
변환을 하는 메쏘드는 JDK 1.1에서는 모두 deprecate시켰다.
따라서,
이러한 메쏘드를 계속 사용한다면, 한글이 깨지게 되므로, 한글에 문제가
발생할 경우에는 모두 찾아내서 다시 작성하는 것이 바람직하다.
(JDK 1.1에서 컴파일할 때 경고 메쎄지가 나오므로 이를 쉽게 찾아낼 수
있으며, 별로 많지는 않다.)
print 메쏘드와 println 메쏘드도 역시 이와 같이 잘못 처리했었으나, 너무
많이 사용되고 있으므로, JDK 1.1에서는 deprecate 시키는 대신에 디폴트
인코딩으로 변환시켜 출력하는 것으로 그 의미를 변경하였다.
=== JDK 1.1에서의 문자세트/인코딩 변환 메쏘드
JDK 1.1 (JDK 1.1 이후 버전 포함)은 문자를 내부적으로는 모두 유니코드 (2
바이트 코드 체계)문자로 변환하여 처리하며, 다양한 인코딩 방식으로
인코딩된 문자를 입출력하고 처리할 수 있도록 이들 인코딩과 유니코드 내부
인코딩사이의 변환을 수행해주는 메쏘드를 제공하며, 이러한 메쏘드는 크게
다음과 같이 2가지로 나뉘어진다.
1.인코딩 이름을 매개변수로 하지 않는 메쏘드
PrintStream 클래스의 print(...), println(...)와 같이 자주 사용되는 기본적인
메쏘드를 비롯하여 상당히 많다. 이들은 디폴트 인코딩과 내부 유니코드
인코딩으로 변환한다. 자바 프로그램 (애플리케이션이든 애플릿이든)이
실행될 때의 실행 환경에 의해서 결정된다. 일반적으로 한글 환경이면
디폴트 인코딩이 "KSC5601"이다.
2.인코딩 이름을 매개변수로 갖는 메쏘드:
인코딩 이름을 매개 변수로 지정해 줄 수 있는 메쏘드는 다음과 같이
몇가지 밖에 없으며, 이들을 사용하여 임의의 인코딩과 변환할 수 있다.
디폴트 인코딩과 상관없이 특정 인코딩 (예: "KSC5601")을 가정하고
입출력하는 등의 특정 인코딩과 반드시 변환해야 하는 경우에는
반드시 인코딩을 지정해 줄 수 있는 다음 메쏘드를 이용하여야 한다.
new String(byte[] bytes, String enc)
new String(byte[] bytes, int offset, int length, String enc)
String 클래스의 byte[] getBytes(String enc)
new java.io.InputStreamReader(InputStream in, String enc)
new java.io.InputStreamReader(InputStream in, String enc)
new java.io.OutputStreamWriter(OutputStream out, String enc)
java.io.ByteArrayOutputStream 클래스의 String toString(String enc) 메쏘드
이들 메쏘드 중 특정 인코딩에서 유니코드 인코딩으로 변환하는 경우는
모두 바이트 배열 혹은 바이트 스트림으로부터 유니코드 문자 배열 혹은
유니코드 문자 스트림으로 변환하는 메쏘드들이다.
이들 메쏘드 중 유니코드 인코딩에서 특정 인코딩으로 변환하는 경우는
모두 유니코드 문자 배열 혹은 유니코드 문자 스트림으로부터 바이트
배열 혹은 바이트 스트림으로 변환하는 메쏘드들이다.
=== 디폴트 인코딩과 시스템 디폴트 인코딩
- 디폴트 인코딩
인코딩을 매개변수로 하지 않는 메쏘드들은 디폴트 인코딩과 변환하는
데, 디폴트 인코딩은 "file.encoding" 이라는 시스템 프로퍼티 값을
의미하며, 이 시스템 프로퍼터 값은 System.getProperty("file.encoding")
메쏘드를 호출하여 읽을 수 있다. 이 디폴트 인코딩은 다시 시스템
디폴트 인코딩에 의해 초기화된다.
- 시스템 디폴트 인코딩
한글 환경일 경우, 디폴트 인코딩이 "KSC5601"이 되는 이유는 시스템
디폴트 인코딩이 KSC5601이기 때문이다. 시스템 디폴트 인코딩은
윈도우즈 95의 경우에는 설정 탭에서 언어 설정을 한국어로 선택하거나
(한글 윈도우즈 95에서는 그렇게 되어 있음), 유닉스에서는 쉘에서
setenv LANG ko라고 실행해주면, 시스템 디폴트 인코딩이 "KSC5601"이
된다.
- 디폴트 인코딩의 변경
시스템 디폴트 인코딩이 자신이 원하는 디폴트 인코딩이 아닌 경우 자바
프로그램을 실행시킬 때, 명령행 옵션 -Dfile.encoding=KSC5601를 주어
명시적으로 디폴트 인코딩을 지정할 수 있다.
(예: java -Dfile.encoding=KSC5601 JavaApplication)
그러나, 웹 브라우저에서는 애플릿이 이를 변경할 수 없으며, 웹 문서의
META 태그에 의해서도 영향받지 않고, 사용자의 인코딩 선택에 의해서도
영향을 받지 않는다. 따라서, 애플릿의 경우는 시스템 디폴트 인코딩과
디폴트 인코딩이 같은 것으로 볼 수 있다. (이부분은 좀 더 조사 필요)
http://camool/~dtkim/java/SystemPropertyTest.java 는 시스템
프로퍼티의 값을 알아내는 애플릿/애플리케이션이다. 웹 브라우저의
현재의 시스템 프로퍼티 값은
http://camool/~dtkim/java/SystemPropertyTest.html 을 방문하면 알 수
있다.
==== 자바 프로그램 컴파일
KSC5601로 인코딩된 자바 소스 프로그램을 컴파일할 때, JDK 1.1
컴파일러는 소스 프로그램이 시스템 디폴트 인코딩으로 인코딩되어
있다고 가정하고 컴파일한다.
이때, 디폴트 인코딩이 KSC5601이 아니면, (즉, 8859_1이면) 컴파일
오류가 나거나 성공적으로 컴파일되어도 한글이 깨지게 된다.
시스템 디폴트 인코딩이 KSC5601로 셋팅되어 있지 않고, 셋팅하기
곤란하다면 JDK의 자바 컴파일러에 -encoding KSC5601 옵션, 혹은
-J-Dfile.encoding=KSC5601 옵션을 사용하여 소스 코드의 인코딩을 지정해
줄 수 있다.
(예: javac -encoding KSC5601 JavaProg.java)
==== JDK 1.1에서 지원되는 문자세트/인코딩
유니코드 문자 외부 인코딩
"Unicode", "UTF8", "UnicodeBig", "UnicodeLittle",
"UnicodeBigUnmarked", "UnicodeLittleUnmarked",
유럽 문자 인코딩
"8859_1", "8859_2", "8859_3", "8859_4", "8859_5",
"8859_6", "8859_7", "8859_8", "8859_9",
한국, 일본, 중국 문자 인코딩
"KSC5601", "EUCJIS", "SJIS", "JIS", "JISAutoDetect",
"Big5", "CNS11643", "GB2312",
매킨토쉬
"MacSymbol", "MacDingbat", // ==> 심볼
"MacCentralEurope", "MacGreek", "MacHebrew", "MacRoman", "KOI8_R",
"MacIceland", "MacRomania", "MacTurkish", "MacArabic", "MacThai",
"MacCyrillic", "MacCroatian", "MacUkraine",
마이크로소프트 (?)
"MS874", "Cp037", "Cp273", "Cp277", "Cp278", "Cp280", "Cp284",
"Cp285", "Cp297", "Cp420", "Cp424", "Cp437", "Cp500", "Cp737",
"Cp775", "Cp838", "Cp850", "Cp852", "Cp855", "Cp856", "Cp857",
"Cp860", "Cp861", "Cp862", "Cp863", "Cp864", "Cp865", "Cp866",
"Cp868", "Cp869", "Cp870", "Cp871", "Cp874", "Cp875", "Cp918",
"Cp921", "Cp922",
"Cp930", "Cp933", "Cp935", "Cp937", "Cp939", // ==> EBCDIC (Cp930 ?)
"Cp942", "Cp948", "Cp949", "Cp950", "Cp964", "Cp970",
"Cp33722",
"Cp1006", "Cp1025", "Cp1026", "Cp1046", "Cp1097",
"Cp1098", "Cp1112", "Cp1122", "Cp1123", "Cp1124", "Cp1250",
"Cp1251", "Cp1252", "Cp1253", "Cp1254", "Cp1255", "Cp1256",
"Cp1257", "Cp1258", "Cp1381", "Cp1383",
==== 자바 인터프리터/브라우저의 문자세트/인코딩 지원 검사 결과
익스플로러 4.0 프리뷰 2 한글판과 넷스케이프 4.01 (문자세트 지원 패키지로
업그레이드한 버전)은 모든 JDK 1.1의 모든 인코딩을 지원하지 않으며, 이들
2
브라우저가 공통적으로 지원하는 인코딩은 UTF8, KSC5601, SJIS, JIS, Big5,
GB2312, 8859_1, Cp1250, Cp1251, Cp1252, Cp1253뿐이다.
인코딩 지원 체커 자바 프로그램인
http://camool.kaist.ac.kr/~dtkim/java/EncodingChecker113.java 를
실행하여
자바 인터프리터 및 브라우저가 제공하는 인코딩을 검사할 수 있으며,
애플릿이면서 애플리케이션이므로, 자바 인터프리터 및 웹브라우저로 실행할
수 있다.
또한, http://camool.kaist.ac.kr/~dtkim/java/EncodingChecker113.html 을
방문하여 사용중인 웹브라우저가 지원하는 인코딩을 조사할 수 있다.
- JDK 1.1.3의 자바 인터프리터
C:> java EncodingChecker113 | more
Encodings which can be converted TO/FROM Unicode:
Unicode, UTF8, UnicodeBig, UnicodeLittle, KSC5601,
EUCJIS, SJIS, JIS, Big5, CNS11643,
GB2312, 8859_1, 8859_2, 8859_3, 8859_4,
8859_5, 8859_6, 8859_7, 8859_8, 8859_9,
MacSymbol, MacDingbat, MacCentralEurope, MacGreek, MacHebrew,
MacRoman, KOI8_R, MacIceland, MacRomania, MacTurkish,
MacArabic, MacThai, MacCyrillic, MacCroatian, MacUkraine,
MS874, Cp037, Cp273, Cp277, Cp278,
Cp280, Cp284, Cp285, Cp297, Cp420,
Cp424, Cp437, Cp500, Cp737, Cp775,
Cp838, Cp850, Cp852, Cp855, Cp856,
Cp857, Cp860, Cp861, Cp862, Cp863,
Cp864, Cp865, Cp866, Cp868, Cp869,
Cp870, Cp871, Cp874, Cp875, Cp918,
Cp921, Cp922, Cp930, Cp933, Cp935,
Cp937, Cp939, Cp942, Cp948, Cp949,
Cp950, Cp964, Cp970, Cp33722, Cp1006,
Cp1025, Cp1026, Cp1046, Cp1097, Cp1098,
Cp1112, Cp1122, Cp1123, Cp1124, Cp1250,
Cp1251, Cp1252, Cp1253, Cp1254, Cp1255,
Cp1256, Cp1257, Cp1258, Cp1381, Cp1383,
Encodings which can only be converted TO Unicode:
JISAutoDetect,
Encodings which can only be converted FROM Unicode:
UnicodeBigUnmarked, UnicodeLittleUnmarked,
- 넷스케이프 4.01 (문자세트 패키지로 업그레이드 한버전)
일부 문자세트 변환을 실행할 때, 경우에 따라
UnsupportedEncodingException이
발생하는 대신에 SecurityException이 발생하는 점이 좀 특이함 (정확한
이유를 알 수 없음)
http://camool.kaist.ac.kr/~dtkim/java/EncodingChecker113.html을
방문한 결과
Encodings which can be converted TO/FROM Unicode:
UTF8, KSC5601, EUCJIS, SJIS, JIS,
Big5, CNS11643, GB2312, 8859_1, 8859_2,
8859_3, 8859_4, 8859_5, 8859_6, 8859_7,
8859_8, 8859_9, MacSymbol, MacDingbat, MacCentralEurope,
MacGreek, MacRoman, KOI8_R, MacCyrillic, Cp1250,
Cp1251, Cp1252, Cp1253,
Encodings which can only be converted TO Unicode:
Unicode, UnicodeBig, UnicodeLittle, JISAutoDetect,
Encodings which are NOT supported:
UnicodeBigUnmarked, UnicodeLittleUnmarked, MacHebrew, MacIceland,
MacRomania,
MacTurkish, MacArabic, MacThai, MacCroatian, MacUkraine,
MS874, Cp037, Cp273, Cp277, Cp278,
Cp280, Cp284, Cp285, Cp297, Cp420,
Cp424, Cp437, Cp500, Cp737, Cp775,
Cp838, Cp850, Cp852, Cp855, Cp856,
Cp857, Cp860, Cp861, Cp862, Cp863,
Cp864, Cp865, Cp866, Cp868, Cp869,
Cp870, Cp871, Cp874, Cp875, Cp918,
Cp921, Cp922, Cp930, Cp933, Cp935,
Cp937, Cp939, Cp942, Cp948, Cp949,
Cp950, Cp964, Cp970, Cp33722, Cp1006,
Cp1025, Cp1026, Cp1046, Cp1097, Cp1098,
Cp1112, Cp1122, Cp1123, Cp1124, Cp1254,
Cp1255, Cp1256, Cp1257, Cp1258, Cp1381,
Cp1383,
- 마이크로소프트 인터넷 익스플로러 4.0 프리뷰 2 한국어판
http://camool.kaist.ac.kr/~dtkim/java/EncodingChecker113.html을 방문한
결과
Encodings which can be converted TO/FROM Unicode:
UTF8, KSC5601, SJIS, JIS, Big5,
GB2312, 8859_1, Cp1250, Cp1251, Cp1252,
Cp1253, Cp1254, Cp1255, Cp1256, Cp1257,
Cp1258,
Encodings which are NOT supported:
Unicode, UnicodeBig, UnicodeLittle, UnicodeBigUnmarked,
UnicodeLittleUnmarked,
EUCJIS, JISAutoDetect, CNS11643, 8859_2, 8859_3,
8859_4, 8859_5, 8859_6, 8859_7, 8859_8,
8859_9, MacSymbol, MacDingbat, MacCentralEurope, MacGreek,
MacHebrew, MacRoman, KOI8_R, MacIceland, MacRomania,
MacTurkish, MacArabic, MacThai, MacCyrillic, MacCroatian,
MacUkraine, MS874, Cp037, Cp273, Cp277,
Cp278, Cp280, Cp284, Cp285, Cp297,
Cp420, Cp424, Cp437, Cp500, Cp737,
Cp775, Cp838, Cp850, Cp852, Cp855,
Cp856, Cp857, Cp860, Cp861, Cp862,
Cp863, Cp864, Cp865, Cp866, Cp868,
Cp869, Cp870, Cp871, Cp874, Cp875,
Cp918, Cp921, Cp922, Cp930, Cp933,
Cp935, Cp937, Cp939, Cp942, Cp948,
Cp949, Cp950, Cp964, Cp970, Cp33722,
Cp1006, Cp1025, Cp1026, Cp1046, Cp1097,
Cp1098, Cp1112, Cp1122, Cp1123, Cp1124,
Cp1381, Cp1383,
--
Deogtae Kim (김덕태)
CA Lab. CS Dept. KAIST
http://camool.kaist.ac.kr/~dtkim/java
2. 자바의 기본 요소(2/5)
2. 자바의 기본 요소(2/5)
3) 자료형(계속해서)
문자
유니코드 처리를 위해 하나의 문자는 16비트종류 : char(16), String(16x?)
Boolean
boolean(1)
4) 배열
new 연산자를 이용헤서 메모리 할당
예, int member_id[] = new int[10] ;
exception - ArrayIndexOutOfBoundsException
http://softtech.lgsw.re.kr/pleasure/ppt/Java/tsld006.htm
http://www.elim.co.kr/java/hangul/hanJava.html
자바에서 한글은 어떻게 처리되는가?
작성 : 제이씨현 시스템(주), 엘림네트 장규오
Download : hanJava.doc (56K), hanJava.zip (16K)
서론
한동안 잊고 지냈던 한글 처리문제가 자바에서 다시 등장하고 있다. 어떻게 하면 한글이 보이고, 한글을
쓸 수 있을까? 새로운 환경과 새로운 소프트웨어, 새로운 개발 언어 들이 나올 때 마다 우리는 항상 한글
문제에 대해서 고심하지 않을 수 없다. 오늘 여기 조그만 지면을 빌어 어떻게 자바에서는 한글을 쓰게
되며, 한글을 출력하게 되는지 바른 방향을 모색해 보기로 한다.
자바의 문자 체계
이미 많이 알려진 바와 같이 자바는 플랫폼 독립적인 소프트웨어를 개발할 수 있는 언어로 잘 알 려져
있다. 이러한 것이 가능한 근본적인 이유는, 자바는 운영 체계 위에 자바 가상 기계(Java Virtual Machine)가
있어 자바 클래스를 실행 시키므로, 자바 클래스(자바 프로그램)는 플랫폼에 는 상관없이 이미 이식되어
있는 자바 가상 기계에 의해 실행된다.
이러한 구조적인 특징 덕택으로, 자바 언어의 기본 자료형 역시 어떠한 플랫폼에서든 공통으로 사용된다.
예를 들어 C언어의 정수 자료형 'int'에서 DOS는 16비트를 할당하고 UNIX에서는 32비트를 할당하므로,
같은 C 프로그램이지만 서로 다른 환경에서는 서로 다른 결과값 을 출력하는 문제가 발생할 수 있다.
그렇지만, 자바에서 정수형 'int' 는 공통적으로 32비트를 할당하고 있으므로, 다양한 플랫폼에서 확실한
프로그램을 할 수 있다.
또한 자바에서 문자 자료형 'char'에 해당되는 문자 표현은 아스키 (ASCII) 코드를 사용하지 않고, 보다
국제 표준에 가까운 유니코드 (UNICODE) 체계를 사용한다. 유니코드 문자 세트는 표준 아스키 코드를
대신한 것으로서, 한 문자를 나타내는데 필요한 비트수가 아스키 코드에서는 8비트였으나
유니코드에서는 16비트로 확장된 형태이다. 유니코드는 수많은 비 영어권 언어들의 문자를 쓸 수 있도록
문 자 세트를 확장한 것이다.
자바에서는 유니코드를 지원하므로, C언어를 배울 때 아스키 코드 체계를 배우듯이 자바 프로그래머는
이제 유니코드에 익숙해져야 한다. 그러나, 인터넷의 수많은 문서들 중에 모든 문서가 유니코드로
되어있는 것만은 아니다. 따라서, 자바에서 1바이트 형태의 아스키 코드 입출력이 가능한데 다음과 같은
프로그래밍 기법으로 유니코드 입출력과 아스키 코드 입출력 기법을 구분할 수 있다.
// 유니코드를 유니코드로 출력
FileOutputStream ufos = new FileOutputStream("test.ucd");
DataOutputStream udos = new DataOutputStream(ufos);
udos.writeChars("ABCDE"); // 유니코드 출력
udos.close();
// 유니코드를 아스키 코드로 출력
FileOutputStream xfos = new FileOutputStream("test.xxx");
DataOutputStream xdos = new DataOutputStream(xfos);
xdos.writeBytes("ABCDE"); // 아스키 코드 출력
xdos.close();
유니코드와 컴파일러
Windows95 자바 개발 환경에서 위의 소스 코드를 저장하면 분명 아스키 코드 형태로 저장될 것이다.
그렇다면, 어떻게 유니코드가 아닌데 유니코드로 간주되어 다시 유니코드 형태와 아스키 코드 형태로
출력 된다는 것일까? 그것은 바로 컴파일러가 비록 소스 코드는 아스키 코드지만 유니코드로 바꾸어
인식해서 컴파일 한다는 것이다. 그렇지 않고, 소스 코드가 유니코드 일 때에는 그대로 유니코드로
인식한다. 따라서, 현재 자바 개발 환경은 유니코드와 아스키 코드를 혼돈하며 사용할 여지가 있다는
것이다. 주의해야 한다. 따러서, 제대로된 한글 2바이트 체계에 따른 컴파일러의 유니코드의 변환은
다음과 같이 이루어 져야한다.
순서 완성형 조합형 유니코드Ver2.0 발음
글자수 (2350자) (6656자) (11172자)
1 B0A1 8861 AC00 KIYEOK A
2 B0A2 8862 AC01 KIYEOK A KIYEOK
3 - 8863 AC02 KIYEOK A SSANGKIYEOK
... ... ... ... ...
11170 - D3BB D7A1 HIEUH I THIEUTH
11171 - D3BC D7A2 HIEUH I PHIEUPH
11172 - D3BD D7A3 HIEUH I HIEUH
그러면, 현재 공개된 자바 개발툴로써 JDK와 Visual J++의 컴파일 형태를 알아보겠다. Visual J++은 위
테이블의 형태에 따라 제대로 컴파일 하고 있다. 즉 'KIYEOK A'에 해당하는 완성형코드 "BOA1"은
유니코드 2.0에 따라 "AC00"로 변환한다. 그런데, JDK는 자바를 만든 제임스 고슬링의 한글에서의
2바이트 코드 체계의 이해 부족으로 잘못 변환하고 있다고 한다. 즉, "B0A1"을 영문코드 처리하듯이 "00"을
앞에 붙여 확장한 형태의 "00B0", "00A1" 두개의 코드를 생성한다.
그러면, 어떻게 제대로 컴파일도 되지 않은 자바 프로그램이 브라우저에서 실행되는 것일까? 그것은
Netscape과 JDK의 appletviewer역시 마찬가지로 위와 같은 잘못된 방식으로 코드변환이 이루어지기
때문이다. 한편, Visual J++과 IE(Internet Explorer3.0)는 제대로 유니코드 변환을처리하고 있다. 따라서,
여태까지 JDK로 컴파일된 한글 애플릿이 IE에서 실행되지 않았던 것이다. 그러면, JDK는 고치지 않고
그대로 놔둘것인가? 그렇지 않다. 올해 하반기, 즉 9월에서 12월 사이에 JDK 1.1에서는 이러한 문제를
해결해서 나올 것이다. 따라서, 그동안, JDK로 컴파일된 애플릿은 새롭게 컴파일할 필요성이 있다. 지금
당장은 Visual j++로 컴파일 해야할것이고, 차후에는 JDK 1.1로 컴파일 하면 된다.
자바에서 한글 입력
자바로 개발할 때 여러 컴포넌트를 사용할 수 있습니다. 이들 컴포넌트 중에는 'TextField"라고 하는
에디터와, "TextArea'라는 멀티라인 에디터가 있습니다. 그런데, 여기에는 한글 입력이 불가능 합니다.
따라서, 자바로 개발된 모든 프로그램은 한글 입력이 되질 않습니다. 그렇다면, 이러한 문제는 어떻게
해결할 수 있을까요? 가장 좋은 방법은 표준화된 한글 라이브러리를 배포하는 것입니다. 한글 입력기를
만들려면 한글 코드 테이블이 있어야 하는데 크기가 아주 큽니다. 그런데, 표준화가 되지 않으면,
공통적인 이러한 리소스를 따로 사용함으로써 쓸데없이 리소스를 낭비하게 되는 결과를 초래할 수
있습니다.
한글 라이브러리에 대한 표준은 시급하다고 할 수 있습니다. 지금 자바로 프로그램을 만들었는데,
한글처리 때문에 당장에 고심하는 사람도 있을지도 모릅니다. 그렇다면, 이것은 JDK나 Visual J++에
기본적으로 제공될까요? 그렇지 않고, 제이씨현시스템, 엘림네트 자바 프로젝트팀은 JDK 1.1과 Visual J++
1.0 정식 버전이 나오는 시점에서 여러 가지 유용한 유틸리티들과 한글 코드 변환기 및 입력기를 제공할
것이다. 조만간 이 한글 라이브러리 개발이 완료되면 더 이상 한글 입력에 대해서는 크게 신경 쓰지
않아도 될 것이다.
자바에서 한글 출력
자바 인터프리터(Java지원 브라우저 포함)가 지정하고 있는 폰트에는 5~6가지가 있다.
Dialog
Helvetica
TimesRoman
Courier
DialogInput
ZapfDingbats
하나같이 모두 영문 폰트 이름이다. 한글 폰트 이름은 없다. 그렇지만, 한글 Window95의 경우에는 이들
폰트를 사용하면 한글이 나온다. 물론, X-Motif환경에서는 한글이 전혀 나오지 않다. 그러면 어떻게
해결할 것인가? 한글 입력기와 마찬가지로, 한글 출력을 위한 라이브러리와 한글 폰트를 배포한다?
그것은 별루 좋은 생각이 아니다. 왜냐하면, 한글 폰트의 크기는 실로 어마어마 하기 때문이다. 따라서,
한글 폰트는 시스템에 있는 한글 폰트를 사용해야 한다. 그래서, 자바가 실행되는 시스템에는 한글 폰트
이름을 추가해야 하고, 영문 폰트는 영문만 출력되고, 한글 폰트는 한글만을 출력하도록 제공해야 할
것이다.
따라서, 한국 Microsoft사와 한국Sun사는 이들 한글 폰트에 대한 표준을 만들어 자바에서 한글 폰트를
제공할 것이라 이야기 하고 있다.
이제 프로그래머가 할일만 남아있다. 프로그램을 개발할 때 영문 폰트를 이용해서 한글 출력을 해도
되는가? 이것은 바른 한글 출렵 방법인가? 그렇지 않다. 영문 폰트를 이용해서 확장된 한글을 사용하게
되면, 폰트 정보가 다르므로 폰트가 삐뚤어지거나, 줄이 맞지 않는 결과가 발생할 수 있다. 따라서,
표준적인 자바에서의 한글 폰트 이름을 제대로 사용하고 영문 폰트와는 구분해서 개발해야 할 것이다.
결론
위 그림은 지금까지 설명한 프로그래머가 완성형 한글 코드 또는 유니코드로 작성한 소스코드를
컴파일하고, 실행 할 때 코드의 변환 과정을 보이고 있다.
한편, 프로그래머가 해야 할 일을 정리해본다. 현재, JDK 1.0.2로 컴파일된 기존의 애플릿은 한글 유니코드
체계를 제대로 제공하는 Visual J++로 컴파일 해서 웹에 공개 해야 한다. 그리고, 한글 입력기는 되도록
표준적인 라이브러리를 사용해야 하고, 한글 출력시 폰트이름을 (차후에 제공될 때까지 기다려본다),
영문 폰트 이름과 한글 폰트 이름으로 구분해서 프로그래밍 해야 한다는 것이다. 마지막으로, 제대로된
자바에서 한글 구현 방향에 대한 인식으로 성능 좋은 한글 자바 애플릿이 많이 쏟아져 나왔으면 하는
바램이다.
참고;
http://..kaist.ac.kr/ ?? 선 I18N튜토리얼 번역 자료..
'Computing..' 카테고리의 다른 글
| 한글 코드 (0) | 2008.11.26 |
|---|---|
| 유니코드와 인터넷 한글(한글 인코딩) (0) | 2008.11.26 |
| 윈도우 레지스트리 정리 (0) | 2008.10.30 |
