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

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

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

Example 3 / 26  Example 인코딩, 디코딩 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

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

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

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

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

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

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 의 용어로 BMP 의 65,536 코드를 정의하며, 2 바이트로 표현됩니다. 1 개의 언어판, 즉 BMP 만이 이에 해당합니다. UCS-2 는 인코딩 방법이 아니며 문자코드 자체입니다. 인코딩으로 봐도 무방하겠군요. 여기서 octet 이라는 용어를 사용했는데 이 용어는 ISO 쪽에서 사용하는 용어로, 유니코드 진영에서 사용하는 바이트와 같은 뜻입니다 UCS-4: Universal Character Set 4(octets) ISO/IEC 의 용어로 4 바이트로 표현됩니다. 모두 128 개의 언어판 그룹, 즉 128*256 언어판 = 32,768 언어판을 정의합니다. 이는 대략 231 = 2,147,483,648 개의 코드에 해당합니다. UCS-4 는 인코딩 방법이 아니며 문자코드 자체입니다.

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 에서는 개의 코드만을 정의할 수 있으나 UTF-16 에서는 1 백만여자를 더 표현할 수 있습니다. UTF-32: UCS Transformation Format, 32-bit form 32 비트 즉 4 바이트로 각 문자를 표현합니다. 이점에서 UCS-4 와 동일하지만 17 개의 언어판만을 정의한다는 점에서는 UCS-4 의 부분집합으로 간주하면 됩니다. UCS-4 와 동일하나 0x ~ 0x0010FFFF 범위만을 문자코드로 간주한다고 이해하시면 됩니다.

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 비트 단위로 표현합니다. 이제 각 인코딩 방식에 대해 좀더 상세하게 설명하겠습니다.

Myth of Unicode 12 / 26  유니코드 인코딩 – UTF16 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 의 차이점입니다.

Myth of Unicode 13 / 26  유니코드 인코딩 – UTF8 UCS-4UTF-8 0x x F0xxxxxxx 0x x000007FF110xxxxx 10xxxxxx 0x x0000FFFF1110xxxx 10xxxxxx 10xxxxxx 0x x001FFFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0x x03FFFFFF111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0x x7FFFFFFF111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx UTF-16 의 문제 - null byte -> 소프트웨어 재개발 - 저장 공간의 문제 -> DB 설계 다시 - 대안 : UTF8 - 중간 바이트에서 0 이 나타나지 않도록 ) - 1byte 에서 4byte 의 가변 바이트

Myth of Unicode 14 / 26  유니코드 인코딩 – UTF32 UTF-32 는 32 비트, 즉 4 바이트로 모든 유니코드 문자를 표현합니다. 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-endianBig-endian UTF-160xFFFE0xFEFF UTF-320x0000FFFE0x0000FEFF 플랫폼 Intel, DEC/Alpha 프로세서 RISC 프로세서, Microprocessor 운영체제 MS Window, 리눅스 / 인텔 Unix, Mac OS

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 워드의 싸움

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

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

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

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

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

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

오라클 NLS 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.KO16MSWIN949 - KOREAN_KOREA.KO16KO16KSC5601 (in unix)

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

오라클 NLS 24 / 26  MS949 에서의 정렬 기존 KO16KSC5601 의 수퍼셋으로 군림하려다 보니 총 자의 한글의 바이트 코드가 한글의 언어적 정렬 순서와 불일치할 수 밖에 없다 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 ’ )

오라클 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"); new String(resultSet.getString( “ val").getBytes("8859_1"),"KSC5601"); 확장 불가, 마이그레이션 불가

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

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