Posted by 김덕태 on July 07, 1997 at 17:28:38:
In Reply to: 보충... posted by 김덕태 on July 05, 1997 at 12:34:40:
bangjy@geocities.com wrote:
>
> 한글이 3바이트로 표현된다는 점입니다. 물론 영어권 사용자들을
> 위해 만든 코딩 방식이니 그쪽 언어는 1바이트로 표현이 가능하다
> 는 장점이 있지만...글쎄, 어느 쪽이 이익이 될까요? 한글이나
> 영어나 모두 2바이트로 쓰는 것과 한글은 3바이트, 영어는 1바이트
> 로 쓰는 것 중에서 말입니다.
우선, 저는 UTF-8이 영어권 사용자들을 위해서만 만든 인코딩 방식이라
보지 않습니다.
그 이유는 우리나라에 일반화된 인코딩인 EUC-KR이 이미 아스키
인코딩을 포함하고 있으며, 포스팅하신 글중에서도 공백문자 (' ', '\t'),
숫자 ('1', '2', '3'), 기호 ('.', '?'), 눈에보이지는 않는 제어 문자
('\r', '\n')등의 아스키 인코딩이 이미 사용되었습니다.
KS C 5601내에 정의되어 있는 한글만을 사용한 텍스트 문서가 과연 얼마나
되겠습니까?
텍스트 문서 및 문자 자료 교환을 위한 일반화된 인코딩 선택의 한
기준으로서 문자를 표현하는 데 차지하는 공간의 크기를 엄밀하게 따져 볼
필요가 있을 것이므로, 다음과 같이 여러 가지로 분석해 보았습니다.
====== Unicode 16 비트 인코딩과 EUC-KR, UTF-8의 수학적 비교 =====
유니코드는 모든 문자를 2 바이트로 표현하므로, 아스키 문자 및 한글 또한
각각 2 바이트로 표현될 것입니다 유니코드 인코딩을 사용하여 작성된 문자
자료의 크기를 1이라고 할 때, UTF-8로 인코딩된 문자 자료의 크기는
최선의 경우 0.5 (아스키 문자로만 작성된 경우)이고 최악의 경우 (순수한
한글로만 작성된 경우)는 1.5가 될 것입니다. 즉, 1 킬로 바이트의
유니코드 문서가 UTF-8 문서로 바뀔 경우 최소 0.5 킬로 바이트에서 최대
1.5 킬로 바이트를 차지할 것입니다. 일반 한글 문서의 경우 아스키
문자와 한글 문자와의 비율이 대략 1:2 ~ 1:4 가량 될 것입니다.
이 비율을 1:3으로 잡겠습니다.
유니코드 1 문자를 표현하기 위한 평균 바이트 수는 물론 2 바이트이고,
한글 문서에서의 1 문자를 표현하기 위한 평균 UTF-8 바이트 수를 x라
하면, x = 1 * 1/4 + 3 * 3/4 = 2.5
즉, 2 : 2.5 = 1 : 1.25 가 됩니다.
따라서, 한글 문서를 표현하기 위한 바이트 수의 비율은 다음과 같이
정리됩니다.
Unicode 16 비트 UTF-8의 최소 UTF-8의 평균 UTF-8의 최대
--------------- ------------ ------------ ------------
100 % 50 % 125 % 150 %
또한, 기존 EUC-KR 인코딩으로 인코딩된 문서를 유니코드 16 비트 및
UTF-8로 변환하였을 경우의 비교도 필요할 것입니다.
이러한 비교를 간단하게 하기 위해, 유니코드에서의 바이트 수와
EUC-KR에서의 바이트 수를 먼저 비교하였습니다.
한글 문서의 1 문자를 표현하는 데, EUC-KR로 인코딩될 때의 평균 바이트
수를
x라 하면, x = 1 * 1/4 + 2 * 3/4 = 1.75
즉, 유니코드 16 비트 인코딩과 EUC-KR의 바이트 수 비율은
2 : 1.75 = 1 : 0.875 가 됩니다.
Unicode 16 비트 EUC-KR의 최소 EUC-KR의 평균 EUC-KR의 최대
--------------- ------------- -------------- ------------
100 % 50 % 87.5 % 100 %
평균 EUC-KR : UTF-8 = 87.5 : 125 ~= 1:1.43
EUC-KR UTF-8의 최소 UTF-8의 평균 UTF-8의 최대
----------- ------------ ------------ -------------
100 % 100 % 143 % 150 %
====== 유니코드 16 비트 인코딩과 EUC-KR, UTF-8의 실험적 비교 ======
실험적 비교치를 얻기 위해서 실험 자료로 포스팅하신 글을 다음과 같이
윈도우즈에서 저장하고, 그 밑의 문자 세트/인코딩 변환 프로그램을
사용하여 그 크기를 비교하였습니다.
------- sample.kr --------------------------------------------
한글이 3바이트로 표현된다는 점입니다. 물론 영어권 사용자들을
위해 만든 코딩 방식이니 그쪽 언어는 1바이트로 표현이 가능하다
는 장점이 있지만...글쎄, 어느 쪽이 이익이 될까요? 한글이나
영어나 모두 2바이트로 쓰는 것과 한글은 3바이트, 영어는 1바이트
로 쓰는 것 중에서 말입니다.
---------------------------------------------------------------
다음 문자세트/인코딩 변환 자바 프로그램은 썬사에서 문자 세트/인코딩
변환 클래스를 아직 제공하지 않고 차후 제공될 예정이라서
모든 문자세트/인코딩 변환에 사용될 수 있거나 변환에 문제가 발생할 경우
보다 유용한 정보와 적절한 경고 메쎄지를 만들어 주도록 할 수가
없었습니다.
그러나, 대부분의 일반적인 인코딩 변환에는 별 문제없이 사용하실 수
있습니다.
또, JDK1.1.2는 인코딩 처리에 다소 문제가 있다고 하니, JDK1.1.3을
설치하여 사용하시기 바랍니다.
------- EncodingConverter.java -----------------------------------
// Usage: java EncodingConverter
import java.io.*;
public class EncodingConverter
{
public static void main(String args[])
throws IOException
{ InputStreamReader in
= new InputStreamReader(System.in, args[0]);
OutputStreamWriter out
= new OutputStreamWriter(System.out, args[1]);
for(int ch; (ch = in.read()) != -1;)
{ out.write(ch);
if ( ch == 0xfffd )
System.err.println("warning: some input character"
+ " cannot be converted to Unicode character");
}
out.close();
}
}
------------------------------------------------------------------
--------- 실험 결과 ----------------------------------------------
C:\> javac EncodingConverter.java
C:\> java EncodingConverter KSC5601 Unicode < sample.kr > sample.uni
C:\> java EncodingConverter KSC5601 UTF8 < sample.kr > sample.utf8
C:\> dir sample.*
sample kr 278 97-07-07 13:05 sample.kr
sample uni 336 97-07-07 13:07 sample.uni
SAMPL~C5 UTF 389 97-07-07 13:09 sample.utf8
실험 자료에 대해서는 UTF-8 인코딩의 문서 (sample.utf8)가 389
바이트이므로, 유니코드 16 비트 인코딩에 대해서는
389/336 * 100 = 116 % 이므로, 16% 밖에 증가하지 않았으며,
EUC-KR에 대해서는 40% 증가한 것임을 알 수 있습니다.
======== 결론 ====================================================
UTF-8로 인코딩된 한글 자료는
유니코드 16 비트 인코딩에 비하여 최대 50%, 평균 15% ~ 25% 증가하며,
EUC-KR에 비해서는 최대 50%, 평균 40% 증가합니다.
(물론, 더 엄밀한 평균치는 다양한 한글 문서에 대하여 실험해 보아야 할
것입니다.)
일반화될 인코딩 표준의 선택 기준에 있어서, 이 정도의 크기 증가는
크게 문제가 되는 것이 아니라 판단되며, 그 이유는 다음과 같습니다.
1. 하드 디스크 및 메모리의 대용량화 및 저렴화되는 추세임
2. 네트워크 속도가 향상되는 추세임
3. 하드 디스크와 네트워크 traffic을 많이 차지하는 것은 문자 자료가
아니라, 정지 영상, 동영상등의 각종 그림 화일 및 오디오 화일들이며,
이들에 비하여 문자 자료가 차지하는 비중은 더욱 더 줄어드는 추세임
(참고: 인터넷 네트워크 traffic의 대부분을 차지하는 것은 도색
그림 화일이라는 연구 결과를 어디서 보았으나 그 출처는 기억하지
못하겠음)
물론, 이 정도의 크기 증가도 문제가 되는 경우가 있을 수 있으며, 그러한
경우에는 보다 효율적인 압축 알고리즘을 사용하여 저장, 검색, 전송하는
것이 보다 적절한 선택이지, 일반화될 인코딩의 선택 기준에 중대한 영향을
미칠만큼 중요하다고 보지 않고 있습니다.
또 한가지 고려해보아야 하는 점은 미국 및 유럽쪽에서의 표준화
추세입니다. 이들 나라에서 수입한 시스템 및 S/W를 사용할 뿐만 아니라,
우리나라에서 만든 시스템 및 S/W가 이들과 서로 문제없이 동작함으로써
이들을 사용하여 보다 효율적으로 부가 가치를 창출하고, 이를 다시 수출도
하기위해서는 이들 나라의 표준화 추세를 무시할 수가 없습니다.
저로서는 이들 나라의 표준화 추세까지 조사해 보지는 못했으나,
1. 이들은 동양권 문화에 비하여 사용되는 대부분의 문자가 아스키
문자이므로, UTF-8을 일반화된 인코딩 표준으로서 선택하는 것이
순리이고,
2. RFC 2130이 갖는 영향력이 얼마나 큰지는 모르겠으나, 해당 문서에서
UTF-8을 디폴트 인코딩으로서 권장하고 있는 점으로 미루어 볼 때,
UTF-8로의 이행은 세계적인 추세가 될 것으로 추측됩니다.
--
Deogtae Kim (김덕태)
CA Lab. CS Dept. KAIST
dtkim@camars.kaist.ac.kr