UNICODE Seminar – 한국에서 프로그래머 하기

Presentation on theme: "UNICODE Seminar – 한국에서 프로그래머 하기"— Presentation transcript:

1 UNICODE Seminar – 한국에서 프로그래머 하기
By bleujin

2 Global Software? 영역(Territory)별 지원 달력 설정 방법 - 첫번째 요일 - 첫번째 주 날짜 포맷
- 05/08/10 - May - 中華民國94年07月21日 통화 기호 - W, Kč, $, Dual Currency 숫자그룹 - 2, - 20,000.00 ,00 1 / 26

3 Global Software? 언어(Language)적 지원 캐릭터 셋 - KO16MSWIN949, KO16KSC5601
정렬방식 - Linguistic Sorting(KOREAN_M) 날짜 표기에 사용되는 기호 - month, day, day of week, year 에러메시지 및 번역 2 / 26

4 Example Example 3 / 26 인코딩, 디코딩
Content-type in HTML, ISO ?, ISO 이메일(웹)이 ????? 보여요, 글자가 깨졌어요.. request.getParam(“val”).getBytes(“euc-kr”), (new FileWriter(“aaa.txt”)).writeln(“abc”) 조합형 한글와 완성형 한글? UTF8? Unicode? ALUTF32, UCS-2, UTF16, UTF32??? UTF7 ??? Code947, i18n, L10N ?c각하, 아?? NLS-Lang?? KO16MSWIN949, KO16KSC5601 3 / 26

5 Legend Of ASCII 왜 1byte는 8bit 인가? 1byte -> 8bit -> 2^8 -> 256

6 Legend Of ASCII OEM ASCII의 문제 5 / 26 - OEM 문자 (127)
- Code Page (win98, cp437, cp949) - DBCS(아시아권) 5 / 26

7 Myth of Unicode 유니코드 야사 6 / 26 세계의 모든 문자를 표현할 수 있는 코드 체계를 만들자
- 영어 알파벳 몇백자, 한글 1만자, 한자 2만자.. - 모두 합쳐도 6만자도 안되겠네.. - BMP(Basic Multilingual Plane) - Unicode 3.0 이하 세상일은 그리 만만하지 않다-_- - 한글 고어, 옛 한자 - SP(Supplementary Planes)를 정의 * 1024 = 10 ex) 한자는 추가적으로 약 4만자 유니코드 콘소시엄 + 세계 표준기구(ISO) - 1991년 이후 동일한 표준 - ISO / IEC 10646 6 / 26

8 Myth of Unicode 유니코드 3.1에 정의된 언어 영역 (List of block names for Unicode Standard 3.1) 유니코드의 구조는 17개의 언어판으로 구성 - 1개의 기본 언어판 + 16개의 보충 언어판 - 17 * = 개 7 / 26

9 Myth of Unicode 유니코드 용어 8 / 26 - 기본언어판, BMP
BMP는 Basic Mulitilingual Plane의 약자입니다. 유니코드의 첫 65,536개의 코드를 의미합니다. - 언어판, Plane 256x256 즉 65,536 개씩의 코드 묶음을 이릅니다. 유니코드에서는 현재 17개의 언어판을 사용할 수 있습니다. 모두 그룹 00에 포함됩니다. - 언어판 그룹, Group 256개씩의 언어판을 묶어 하나의 그룹으로 명명합니다. 유니코드의 17개 언어판은 모두 Group 00에 있습니다. 유니코드는 17개의 언어판에 한정되어 정의됩니다. 반면 ISO 표준(UCS-4)에서는 모두 128개의 언어판 그룹이 정의될 수 있습니다. - 1 Plane = 65,536 code points - 1 Group = 256 planes = 256x65,536 = 16,777,216 code points - UCS-4 = 128 groups = 128x16,777,216 = 2,147,483,648 code points 8 / 26

10 Myth of Unicode 유니코드 용어 9 / 26 - 인코딩, Encoding 문자집합을 표현하는 방식을 말합니다.
유니코드는 코드체계 또는 문자집합을 명명하는 것이며 이를 표현하기 위해서는 UTF-8, UTF-16, UTF-32 등과 같은 인코딩이 필요합니다. UCS-2: Universal Character Set 2(octets) 좀더 정확하게는 Universal Multipe-Octet Coded Character Set 2입니다. ISO/IEC 10646의 용어로 BMP의 65,536 코드를 정의하며, 2바이트로 표현됩니다. 1개의 언어판, 즉 BMP만이 이에 해당합니다. UCS-2는 인코딩 방법이 아니며 문자코드 자체입니다. 인코딩으로 봐도 무방하겠군요. 여기서 octet이라는 용어를 사용했는데 이 용어는 ISO쪽에서 사용하는 용어로, 유니코드 진영에서 사용하는 바이트와 같은 뜻입니다 UCS-4: Universal Character Set 4(octets) ISO/IEC 10646의 용어로 4바이트로 표현됩니다. 모두 128개의 언어판 그룹, 즉 128*256 언어판 = 32,768 언어판을 정의합니다. 이는 대략 231 = 2,147,483,648개의 코드에 해당합니다. UCS-4는 인코딩 방법이 아니며 문자코드 자체입니다. 9 / 26

11 Myth of Unicode 유니코드 용어 10 / 26
UTF-8: UCS Transformation Format, 8-bit form Unicode 표준의 인코딩 방식중의 하나입니다. 표준에서는 17개 언어판의 문자만을 표현할 수 있으나 기술적으로는 UCS-4 전영역의 문자를 표현할 수 있습니다. 문자에 따라 1 ~ 4(또는 6) 바이트로 표현됩니다. UTF-16: UCS Transformation Format, 16-bit form 유니코드 3.0에서는 16을 16비트로 해석한 것이 아니라, 그룹 00의 16개 언어판이라고 써 놓았군요. UTF-32의 32가 32비트를 지칭하므로 통일성을 위해 16비트로 이해하시는 게 좋습니다. 16비트로 표현한다는 점에서는 UCS-2와 흡사하지만 대행문자영역(Surrogates)을 이용하여 16개의 보충 언어판 코드를 표현할 수 있는 인코딩입니다. 대행문자영역 2개로 16개의 보충 언어판을 표현할 수 있습니다. UCS-2에서는 65536개의 코드만을 정의할 수 있으나 UTF-16에서는 1백만여자를 더 표현할 수 있습니다. UTF-32: UCS Transformation Format, 32-bit form 32비트 즉 4바이트로 각 문자를 표현합니다. 이점에서 UCS-4와 동일하지만 17개의 언어판만을 정의한다는 점에서는 UCS-4의 부분집합으로 간주하면 됩니다. UCS-4와 동일하나 0x ~ 0x0010FFFF 범위만을 문자코드로 간주한다고 이해하시면 됩니다. 10 / 26

12 Myth of Unicode 유니코드 인코딩 11 / 26
유니코드에서 지원하는 인코딩 방식은 UTF-8, UTF-16, UTF-32의 세가지 방식입니다. UTF는 UCS Transformation Format의 약자이며, 뒤에 붙은 숫자는 인코딩에 사용되는 단위의 비트수를 의미합니다. 즉 UTF8은 8비트 단위, UTF16은 16비트 단위, UTF32는 32비트 단위로 문자를 표현합니다. 세가지 방식의 공통점이라면 16개의 보충언어판에 위치한 1,048,576개의 코드를 표현할 때는 4바이트를 사용한다는 점입니다. 하지만 그 방식은 모두 다릅니다. UTF8은 4개의 바이트로, UTF16은 2개의 16비트로, UTF32는 1개의 32비트 단위로 표현합니다. 이제 각 인코딩 방식에 대해 좀더 상세하게 설명하겠습니다. 11 / 26

13 Myth of Unicode 유니코드 인코딩 – UTF16 12 / 26
UCS-2와 거의 동일합니다. 이 인코딩의 기본 단위는 16비트, 즉 2바이트입니다. 대행문자 영역 2,048개를 제외한 63,488개의 코드를 문자로 사용할 수 있으며(BMP), 대행문자 영역 2개의 쌍을 이용하여 16개의 보충언어판에 위치한 1,048,576개의 코드를 표현할 수 있습니다. 대행 문자 2개의 쌍으로 1개의 문자를 인코딩한다는 점에서 UTF-16의 인코딩은 가변적인 인코딩이라고 할 수 있겠군요. 즉 기본언어판의 문자는 2바이트로 보충언어판의 문자는 4바이트로 인코딩됩니다. 이러한 인코딩 방식때문에 UTF-16에서는 유니코드 표준에서 지원하는 17개의 언어판 코드만 표현이 가능합니다. 가장 유니코드다운 인코딩이라고 할 수 있겠군요 :-) UTF-16에서는 상위대행코드가 나타나면 반드시 뒤이어 하위대행코드가 따라와야 합니다. UCS-2에서는 그렇지 아니한 점이 UTF-16과 UCS-2의 차이점입니다. 12 / 26

14 Myth of Unicode 유니코드 인코딩 – UTF8 13 / 26 UTF-16의 문제 - null byte
-> 소프트웨어 재개발 - 저장 공간의 문제 -> DB 설계 다시 - 대안 : UTF8 - 중간 바이트에서 0이 나타나지 않도록) - 1byte에서 4byte의 가변 바이트 UCS-4 UTF-8 0x x F 0xxxxxxx 0x x000007FF 110xxxxx 10xxxxxx 0x x0000FFFF 1110xxxx 10xxxxxx 10xxxxxx 0x x001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0x x03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0x x7FFFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 13 / 26

15 Myth of Unicode 유니코드 인코딩 – UTF32 Byte Order Mark (ex 0x4E00 b:-, l:N)
UTF-8과 UTF-16에 대비해서 고정길이 인코딩이라고 할 수 있겠군요. 4바이트 단위로 표현한다해서 UCS-4와 동일하게 볼 수는 없습니다. 17개의 언어판만을 대상으로 하는 UCS-4의 부분집합이라고 보시면 됩니다(표준상 그렇습니다). 즉 UTF-32의 인코딩 영역은 0x 에서 0x0010FFFF로 제한되어야 합니다 (이 제한을 무시하면 UCS-4와 동일합니다). Byte Order Mark (ex 0x4E00 b:-, l:N) 구분 Little-endian Big-endian UTF-16 0xFFFE 0xFEFF UTF-32 0x0000FFFE 0x0000FEFF 플랫폼 Intel, DEC/Alpha 프로세서 RISC 프로세서, Microprocessor 운영체제 MS Window, 리눅스/인텔 Unix, Mac OS 14 / 26

16 CAMEL PROGRAMMER 한글 한글 한글… 15 / 26 일반 텍스트? - 가가 가가? 제 웹사이트가 깨져 보여요
- Content-type: text/plain; charset=“utf-8” - Explorer 언어 추측 - 언어의 UCS-2 java, c++, c# php 조합형 한글 vs 완성형 한글 ^5 + 2^5 + 2^5 - 아래한글과 MS워드의 싸움 15 / 26

17 오라클 NLS Setup 16 / 26 위 창은 한국어 저장 여부하고는 아무 Never 절대 상관이 없다. - 번역된 메시지
- 폰트 - 로케일정보 16 / 26

18 오라클 NLS 올바른 캐릭터 셋을 선택하자 17 / 26 올바른 캐릭터셋이라 함은 한글을 저장할 수 있는 캐릭터 셋을 말한다.
정해진 캐릭터 셋을 가지고 있지 않은 데이터베이스에 결코 한글 데이터를 저장할 수 없다. 이제 US7ASCII와는 헤어질때다. - KO16KSC5601 - KO16MSWIN949 - UTF8 - AL32UTF8 17 / 26

19 오라클 NLS KO16KSC5601 한글 완성형 코드와 일치( 2350한글(25*94), 4888자의 한자, 히라카나, 카타카나, 영문, 기호 등) UNIX (Lang=ko) default 하지만~~~ KO16KSC5601 캐릭터 셋 사용은 자제하라… 아햏햏 모두에게 먄하게 되었소. 솔믜가 예약했던 커피숖이 배신을 때리는 바람에 그만 낙동강 오리알이 되었지요. 정말 먄하오. 똠방각하 아? ? 모두에게 ?하게 되었소. 솔?가 예약했던 커피?이 배신을 때리는 바람에 그만 낙동강 오리알이 되었지요. 정말 ?하오. ?방각하 18 / 26

20 오라클 NLS KO16MSWIN949 Windows-949 캐릭터셋은 마이크로소프트사의 Windows Codepage 949번, 즉 한글 코드 페이지를 따른 코드셋이다 완성형(KO16KSC5601)을 그대로 포함하고 있으며, 추가로 현대 한글 조합으로 표현할 수 있는 모든 가짓수에 해당하는 8822자의 한글을 추가해 포함하고 있다. 그러니까 "Windows-949 캐릭터셋은 KSC5601의 수퍼셋(Superset)"이 되며, 따라서 "KO16MSWIN949 또한 KO16KSC5601의 수퍼셋" 이다 다른 운영 체제에서도 사용할 수 있다!" 19 / 26

21 오라클 NLS UTF8/AL32UTF8 UTF8은 유니코드를 구현한 캐릭터셋 중에 가변길이 인코딩 방식을 택하고 있는 캐릭터셋이다. 자세한 인코딩 방식은 여기에서 논할 필요가 없지만, 가변 길이를 위해 일종의 플래그 비트를 각 바이트마다 포함시켜야 하다보니, 한 글자를 표한하는데 필요한 바이트의 길이가 최대 3바이트(AL32UTF8의 경우 6바이트)까지 늘어날 수 있다. 유니코드는 잘 알려진 바와 같이 현대 한글 11172자를 모두 가나다 순으로 잘 정렬된 상태로 포함하고 있다. 그래도 한글 한 자가 3바이트의 물리적 공간을 차지하므로, 오로지 모든 한글을 지원한다는 이유만으로 사용하는 것은 곤란하다. 하지만, 한글 이외에도 다른 언어들을 함께 데이타베이스에 저장해야 한다면 다른 선택의 여지가 없는 유일한 선택이 된다. 20 / 26

22 오라클 NLS 한글 캐릭터 셋 비교 21 / 26 KO16KSC5601 KO16MSWIN949 UTF8 AL32UTF8
한글 지원 한글 2350 2350+확장 8822(총11172자) 한글 11172자 인코딩 버전 한글 완성형 확장은 MS949에 따라 배열 Unicode2.1, 3.0 Unicode 3.0, 3.1, 3.2, 4.0 한글 바이트 2 byte 2byte 3byte 지원버전 7.x 8.0.6 이상 8.0 이후 9i R1 이상 Nchar로 설정가능 불가 가능 한글정렬 단순 바이너리정렬 KOREAN_M, UNICODE_BINARY 한글 : 바이너리 한자 : KOREAN_M 장점 없음 2byte로 모든 한글 입출력 가능 정렬이 효과적, 다른언어들과 같이 저장되어야 할 경우 다른 대안이 없음 동일 단점 한글 2350 가능한 사용자제 완성형과 호환 문제로 글자배열순과 정렬순서가 다름 공간의 소모 인코딩/디코딩 시간 21 / 26

23 오라클 NLS 자. 이걸 기억하자 - KOREAN_KOREA.KO16MSWIN949 (in window) 22 / 26
- 한글 지원을 위해서는 반드시 위의 네 가지 캐릭터셋 중에 하나를 선택해야 한다 - 한국에서만 사용하는 시스템이라면 KO16MSWIN949를 선택한다 - 한국어 뿐 아니라 중국어, 일본어, 러시아어 등 다양한 언어로 된 데이타를 저장해야 한다면 UTF8, AL32UTF8을 선택한다. - 대부분이 한글이며, “일부” 컬럼에 외국어가 필요하다면, 한국어 기반의 캐릭터셋(KO16MSWIN949)을 사용하되, National Characterset을 이용한 컬럼에 외국어를 저장한다. ex) CREATE TABLE test_table ( varchar_value VARCHAR2(2000), nvarchar_value NVARCHAR2(2000) ); NLS_LANG 변수는 데이타베이스에게 사용자의 환경을 알려주는 인식표 역할을 한다. - KOREAN_KOREA.KO16MSWIN949 (in window) - AMERICAN_AMERICA.KO16MSWIN KOREAN_KOREA.KO16KO16KSC5601 (in unix) 22 / 26

24 오라클 NLS KSC5601에서 지원되지 않는 글자들의 입출력 23 / 26
KO16KSC5601 CS에 얼마든지 그런 글자들을 삽입할 수 있던데요? insert into test(a) values(‘숖’) ; select * from test ? NLS_LANG를 KO16KSC5601로 하면 ? Insert 실패 숖, 똠, 믜, 뾃, 햏 KSC5601 CS의 정렬 한글, 그리고 한문도 한자의 음에 맞게 정렬 그러나 한글 2350자와 한자 4888자에 대한 정렬 지원하지 않는 글자에 대한 정렬은 되지 않음 23 / 26

25 오라클 NLS MS949에서의 정렬 24 / 26 기존 KO16KSC5601의 수퍼셋으로 군림하려다 보니
총 11172자의 한글의 바이트 코드가 한글의 언어적 정렬 순서와 불일치할 수 밖에 없다 Select * From test Order by a 똠방각하 먄해 가나다라마바사 라디오를켜라 햏햏 Select * From test Order by NLSSORT(a, ‘NLS_SORT=UNICODE_BINARY’) 똠각하 Select * From test Order by NLSSORT(a, ‘NLS_SORT=KOREAN_M’) 24 / 26

26 오라클 NLS 바로잡기의 필요성을 인식하라 확장 불가, 마이그레이션 불가 25 / 26 Ex)
String p_UserComment = new String(request.getParameter(“val").getBytes("KSC5601"),"8859_1"); pstmt.setString(1,p_UserComment); pstmt.executeUpdate(); if(resultSet.next()) {     String v_UserComment = new String(resultSet.getString(“val").getBytes("8859_1"),"KSC5601"); 확장 불가, 마이그레이션 불가 25 / 26

27 오라클 NLS 캐릭터 셋 변경의 위험성 26 / 26 데이터 절삭 데이터 깨짐
- US7ASCII에서 한글데이타를 exp/imp를 이용하여 MS949나 UTF8로 마이그레이션 - 불가능 - KO16KSC5601에서 한글 데이터를….. - 일부 데이터 깨짐 어플리케이션 오동작 - 글자 길이 연산의 오동작 length, instr, substr 기존 캐릭터 셋 새로운 캐릭터 셋 변경가능여부 US7ASCII KSC5601/MS949/UTF8/AL32UTF8 가능 KO16KSC5601 KO16MSWIN949 UTF8 불가능 AL32UTF8 26 / 26

28 참조 참조 Joel 의 블로그 오라클 NLS 진숙의 Unicode 이야기 Windows tool charmap