유니코드 도움말

http://www.unicode.org/charts/


팀장님 말씀.

---

이후 약 2주간(1월 16일)에 걸쳐 해야 할 주요 내용입니다

우선 첨부된 문서의 완성본을 만들면 된다고 생각하면 됩니다.

 

지난번에 얘기 했었는데요

문자열의 비교함수를 만드는 것입니다.(우선은 초성값으로 비교합니다.)

우선 해당 문자열은 unicode로(utf16/ucs2)들어 오는 경우에 대해서만 고려하고 이후

Utf8이나 ksc5601 확장형등에 대해 고려를 하도록 할 것입니다.

쉽게 말해 일단 Unicode 버전을 먼저 하고 완성 후에 점차 확장해가자는 얘기입니다.

 

이 작업을 위해 Unicode에 대해 어느 정도 지식을 확보 해야하겠죠?

1월 8일까지 자료를 수집정리해서 간단한 브리핑을 진행해 주시고 이후 코드 작성을 해서

(코드는 함수의 형태이면 됩니다.)테스트 진행을 하면 되겠습니다.

 

따라서 8일 브리핑시 함수의prototype과 해당 함수의 동작이 어떻게 되어야 할 것인지

또한, 예외적인 경우의 종류 및 대응 방안 등에 대해서도 함께 얘기하면되겠습니다.

 

이후 완성 후에 최종 세미나를 할 예정이니 미비점은 그때까지 보완하도록 합시다.

잘 작성된 코드를 제공해서 추가된 기능에 대한 테스트 진행 시 사용될 수 있도록 하면 좋겠습니다.

 

코드 작성은 C를 사용하고 가급적 첨부된 코딩 규약에 대한 문서를참조하세요

---

http://www.kristalinfo.com/K-Lab/unicode/Unicode_intro-kr.html

http://www.kristalinfo.com  유니코드(Unicode)와 유니코드 인코딩 원래 유니코드에 관한 개괄적인 내용을 담은 문서는 만들지 않을 작정이었습니다.그런데, 유니코드를 처리하는 부분에 대한작업을 진행하다보니 용어나 인코딩 방식 등에 대해 혼동이 되는 부분이 너무많군요. 제 자신을 위해서도 유니코드에 대한 정리를 할 필요가 있을 듯하여이 문서를 작성합니다. 이 문서에서는 유니코드의 기본 구성 및 인코딩 방식에대해 비교적 자세하게 설명할 것입니다. 성격 급하신 분이라면Unicode Consortium이제공하는 코드간 변환 소스(C 언어)를 바로 보시는 게 더 도움이될 수도 있겠군요 :-) 차례 유니코드 야사 (아마도 이랬을 것입니다) 유니코드의 구조 유니코드 3.1에 정의된 언어 영역 유니코드 용어의 이해 유니코드 인코딩 UTF-8 인코딩 (8 비트) UTF-16 인코딩 (16 비트) UTF-32 인코딩 (32 비트) 보충언어판에 대한 UTF-32와 UTF-16의 인코딩 UTF-16과 UTF-8의 대행코드 인코딩에 관한 오해 기타 참고문헌 유니코드 야사 (아마도 이랬을 것입니다) 거의 모든 프로그래밍 언어에서 사용하는 데이타 기본형으로 char가 있습니다.이것이 8개의 비트, 즉 1바이트로 이루어져 있다는 것은 모두 알고 계시죠?왜 하필 8비트였을까요? 당시의 메모리 사용환경이라던지(지금에 비하면무지무지하게 열악했을 겁니다), CPU 연산속도 때문이라던지(애니악의 경우폰노이만보다 계산속도가 느렸다는 이야기가 있습니다) 이런 이유들때문이었을 까요? 가장 궁극적인 원인은 컴퓨터를 만든 사람들에게 있어서8비트(실제로는 7비트)면 자신들의 언어(영어)를 모두 표현할 수 있었다는 데 있을것입니다. 즉 7비트이면 27(128)개의 코드를 표현할 수 있는데,26x2(알파벳 대소문자) + 10(숫자) + 특수문자 + 통제문자 등등을 모두합쳐 128개이하로 표현이 가능합니다. 세상 모든 사람들이 영어만 쓴다면 Unicode를 만들겠다는 생각을 아무도 하지는않을 것입니다(훗날 외계인들의 언어를 수용한다면 모를까...).1바이트로 모든 문자를 표현할 수 없는 언어를 사용하는 국가에서는 각각자신들만의 인코딩 방법으로 이용하여 문자를 표현해 왔습니다.한국의 경우 KSC5601 표준(완성형)이 대표적이죠. 그러다 보니 한글, 한자,일본어 등을 섞어쓸 수 있는 방법이 묘연했었나 봅니다(제한적이나마가능하긴 합니다만). 그래서 소프트웨어업체들이 생각한 것이 "그러면 세계의 모든 문자를 표현할 수 있는 코드 체계를만들자!"라고 해서 만들어지기 시작한 게 UniCode입니다. 세상에 존재하는 모든 문자의 수가 216(65,536)개 이하라면어떻게 될까요? char를 16비트로 증가시키면 간단하게 해결되겠죠? 처음에는다들 그렇게 생각했나 봅니다. 유럽과 같이 영어 알파벳 쓰는 자잘한 언어들의경우 몇백자면 될테고, 한글도 1만자 조금 넘고, 한자도 2만자 조금 넘게 주면될 것 같고... 모두 합쳐도 6만자도 안되겠네... 그랬나 봅니다.그래서 유니코드는 16비트의 공간에 모든 문자를 집어넣으려고 했습니다.이 16비트 영역을 기본다중언어판(BMP, Basic Multilingual Plane)이라고부릅니다. Unicode 3.0버전까지는 여기에만 문자 코드가 부여되어 있었습니다. 세상일이란 그렇게 만만치 않죠... 한중일에서 고문서를 다루는 사람들도 컴퓨터를사용해야 되지 않겠습니까? 우리말 고어는 어떻게 표현하고, 지금은 사용되지 않는옛 한자는 또 어떻게 하란 말입니까? 새로운 인코딩 방식을 별도로 만들어서사용할까요? 이렇게 되면 유니코드라는 게 의미가 없어질 것입니다.그래서 유니코드 3.0부터 보충언어판(Supplementary Planes)을 정의하였습니다.이를 위해 BMP의 2,048자를 대행코드 영역(Surrogates)으로 할당하고 이중 1,024자를상위대행(high surrogates), 1,024자를 하위대행(low surrogates)으로 정의하여이 둘의 조합으로 다시 1백만여자의 - 1024x1024=1048576 - 문자를 추가로 정의할 수 있도록 하였습니다. 유니코드3.1부터는 실제로 이 영역에 문자를 정의했습니다. 가장 크게 할당 받은 것은역시 한자로 4만여자가 추가로 정의되었습니다. 이러한 세계표준코드를 만들려는 움직임은 소프트웨어 업체들의 연합인유니코드 컨소시엄외에도 있었습니다. 세계표준기구(ISO)가 바로 이 움직임의주체였는데, 다행스럽게도 두 단체가 서로 합의하여 1991년이후로 동일한표준을 만들고 있습니다. 유니코드 표준과 동일한 세계표준기구의 표준안은ISO/IEC 10646으로 명명되었습니다. 두 표준이 내용은 동일하지만 사용하는용어나 논리적인 설명이 약간 다르기 때문에 혼동스러울 때도 있습니다.이러한 이유때문에 제가 이 문서를 작성한 것입니다 :-)

유니코드 3.1에 정의된 언어 영역 (List of block names for Unicode Standard 3.1) 범위 언어 설명 0000..007F Basic Latin 기본 라틴(영어 알파벳) 0080..00FF Latin-1 Supplement 0100..017F Latin Extended-A 0180..024F Latin Extended-B 0250..02AF IPA Extensions 02B0..02FF Spacing Modifier Letters 0300..036F Combining Diacritical Marks 0370..03FF Greek 그리스어 0400..04FF Cyrillic 키릴어 0530..058F Armenian 아르메니아어 0590..05FF Hebrew 히브리어 0600..06FF Arabic 아랍어 0700..074F Syriac 시리아어 0780..07BF Thaana 0900..097F Devanagari 0980..09FF Bengali 벵골어(인도) 0A00..0A7F Gurmukhi 0A80..0AFF Gujarati 0B00..0B7F Oriya 0B80..0BFF Tamil 0C00..0C7F Telugu 0C80..0CFF Kannada 0D00..0D7F Malayalam 0D80..0DFF Sinhala 0E00..0E7F Thai 0E80..0EFF Lao 0F00..0FFF Tibetan 1000..109F Myanmar 10A0..10FF Georgian 1100..11FF Hangul Jamo 한글 자모 1200..137F Ethiopic 13A0..13FF Cherokee 1400..167F Unified Canadian Aboriginal Syllabics 1680..169F Ogham 16A0..16FF Runic 1780..17FF Khmer 1800..18AF Mongolian 몽고어 1E00..1EFF Latin Extended Additional 1F00..1FFF Greek Extended 2000..206F General Punctuation 2070..209F Superscripts and Subscripts 20A0..20CF Currency Symbols 20D0..20FF Combining Marks for Symbols 2100..214F Letterlike Symbols 2150..218F Number Forms 2190..21FF Arrows 2200..22FF Mathematical Operators 2300..23FF Miscellaneous Technical 2400..243F Control Pictures 2440..245F Optical Character Recognition 2460..24FF Enclosed Alphanumerics 2500..257F Box Drawing 2580..259F Block Elements 25A0..25FF Geometric Shapes 2600..26FF Miscellaneous Symbols 2700..27BF Dingbats 2800..28FF Braille Patterns 2E80..2EFF CJK Radicals Supplement 한자 부수 2F00..2FDF Kangxi Radicals 강희자전 부수 2FF0..2FFF Ideographic Description Characters 3000..303F CJK Symbols and Punctuation 3040..309F Hiragana 일본어 히라가나 30A0..30FF Katakana 일본어 카타카나 3100..312F Bopomofo 3130..318F Hangul Compatibility Jamo 한글 호환 자모 3190..319F Kanbun 31A0..31BF Bopomofo Extended 3200..32FF Enclosed CJK Letters and Months 원문자 3300..33FF CJK Compatibility 한중일 호환 3400..4DB5 CJK Unified Ideographs Extension A 한자 확장 A 4E00..9FFF CJK Unified Ideographs 한중일 공통 한자 A000..A48F Yi Syllables A490..A4CF Yi Radicals AC00..D7A3 Hangul Syllables 한글 D800..DB7F High Surrogates 상위대행코드 DB80..DBFF High Private Use Surrogates Private Use용의 15,16 Plane 지정을 위한 상위대행코드 DC00..DFFF Low Surrogates 하위대행코드 E000..F8FF Private Use F900..FAFF CJK Compatibility Ideographs 한중일 호환 FB00..FB4F Alphabetic Presentation Forms FB50..FDFF Arabic Presentation Forms-A FE20..FE2F Combining Half Marks FE30..FE4F CJK Compatibility Forms FE50..FE6F Small Form Variants FE70..FEFE Arabic Presentation Forms-B FEFF..FEFF Specials FF00..FFEF Halfwidth and Fullwidth Forms FFF0..FFFD Specials 10300..1032F Old Italic 10330..1034F Gothic 10400..1044F Deseret 1D000..1D0FF Byzantine Musical Symbols 1D100..1D1FF Musical Symbols 음표 1D400..1D7FF Mathematical Alphanumeric Symbols 20000..2A6D6 CJK Unified Ideographs Extension B 한자 확장 B 2F800..2FA1F CJK Compatibility Ideographs Supplement E0000..E007F Tags F0000..FFFFD Private Use 개인 사용 목적(언어판 15) 100000..10FFFD Private Use 개인 사용 목적(언어판 16) 유니코드의 구조 이제는 유니코드의 구조에 대해 대강 감을 잡으셨을 줄 압니다.유니코드의 구조는 크게 17개(1개의 기본언어판(BMP)와 16개의 보충언어판)의언어판으로 구성되어 있습니다. 각 언어판은 216, 즉 65,536개의문자를 지정할 수 있으니까 유니코드에서 지정할 수 있는 문자의 수는17x65,536=114112개입니다. 하지만 대행코드영역(Surrogates) 2048개를 제외해야하니까 실제로는 1112064개의 문자를 지정할 수 있겠군요. Unicode 3.1 표준에서각 언어판은 다음과 같이 정의되어 있습니다. 표. Unicode 3.1의 각 언어판 정의 언어판 UCS4 영역 이름 문자수 0 (0x00) 0x00000000 - 0x0000FFFF 기본언어판(BMP, Basic Multilingual Plane) 49,196 1 (0x01) 0x00010000 - 0x0001FFFF 보충언어판(SMP, Supplementary Multilingual Plane for scripts and symbols) 1,594 2 (0x02) 0x00020000 - 0x0002FFFF 보충표의문자판(SIP, Supplementary Ideographic Plane) 43,253 3 ~ 13 (0x03~D) 0x00030000 - 0x000DFFFF 아직 사용하지 않음 0 14 (0x0D) 0x000E0000 - 0x000EFFFF 특별보충판(SPP, Supplementary Special-purpose Plane) 97 15 ~ 16 (0x0F~0x10) 0x000F0000 - 0x0010FFFF 개인사용목적으로 지정(Private Use) 0 합계     94,140 유니코드 표준 3.0에서는 49,194 문자가 정의되었고 이들은 모두 BMP에 한정되어정의되었으나, 3.1에서는 BMP에2개의 문자를 추가하고, 보충언어판에 44,944개의 문자를 추가하였습니다.새로 추가된 문자들은 음표, 고대문자, 한자(CJK Ideographic Extension B)등입니다. 제 15, 16 언어판에 대한 설명이 조금 필요할 듯 합니다. 이 두개의 언어판은개인사용(Private Use)로 지정되었습니다. 개발자들에게는 일종의 보너스라고말하는 사람들도 있군요. 어쨌던 이 두 언어판은 상위대행코드중 마지막128개 코드와 하위대행코드의 조합으로 지정됩니다(UTF-16 인코딩의 경우).이 때문인지 유니코드 3.1에서는 U+DB80 ~ U+DBFF 영역을 별도로 분리하여High Private Use Surrogates라고 이름을 붙였더군요. 2002년 1월에 Unicode Standart 3.2 베타판이발표되었습니다. 3.2버전이 고정되는 대로 이 문서를 갱신할 예정입니다. 유니코드 용어의 이해 위의 표에서 뜬금없이 UCS4라는 용어를 사용했습니다. 유니코드 관련 문서를읽다보면 가장 많이 마주치는 용어들이 UCS2, UCS4, UTF8, UTF16, UTF32등과 같은 단어들입니다. 제가 아주 많이 헷갈렸던 관계로 용어들에 대한정리를 간단하게 할 까 합니다. 기본언어판, 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 인코딩, 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는 인코딩 방법이 아니며 문자코드 자체입니다. 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와 동일하나 0x00000000 ~ 0x0010FFFF 범위만을 문자코드로 간주한다고 이해하시면 됩니다. 표. 각 인코딩별 표현가능한 문자 수 인코딩 그룹 언어판 문자수(표준) 문자수(이론적) UCS-2 0 0(BMP) 216=65,536 216=65,536 UCS-4 0 ~ 127 0 ~ 32,767 231=2,147,483,648 231=2,147,483,648 UTF-8 0 0 ~ 16 17*216-211=1,112,064 231=2,147,483,648 UTF-16 0 0 ~ 16 17*216-211=1,112,064 17*216-211=1,112,064 UTF-32 0 0 ~ 16 17*216-211=1,112,064 231=2,147,483,648 위의 표에서 표준이라 함은 유니코드 표준에서 정의하는 것을 의미하며,이론적이라는 것은 표준의 정의를 무시할 때 표현할 수 있는 문자의 수를의미합니다. 211을 뺀 부분이 있는 데, 이것은 상위대행코드(highsurrogates) 1,024개와 하위대행코드(low surrogates) 1,024개의 합입니다.UCS-2에서는 이들이 하나의 문자로 취급되지만, UTF-8, UTF-16, UTF-32의인코딩에서는 보충언어판의 코드를 지정하는데 사용되므로 코드로 취급할 수없습니다. 유니코드 인코딩(Unicode Encodings) 유니코드에서 지원하는 인코딩 방식은 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비트 단위로 표현합니다.이제 각 인코딩 방식에 대해 좀더 상세하게 설명하겠습니다. UTF-8 가장 완벽하게 유니코드 표준을 표현하는 인코딩 방식은 UTF-16이라고 할 수있습니다. 그런데 이 인코딩에서는 16비트 단위로 하나의 문자가 표현되기때문에 전통적인 char 형과는 맞지 않는 부분이 있습니다. UTF-16으로문자열을 표현했을 때 전통적인 char 형으로 이 문자열 취급하게 되면 중간에널(null, 0)값이 들어가게 되어 문제가 발생합니다. 즉 유니코드를 지원하려면,지금까지 개발된 모든 프로그램을 재개발해야 한다는 부담이 발생합니다.현실적으로 이것은 거의 불가능한 일이라고 할 수 있습니다. 이의 대안으로 제시된 인코딩이 바로 UTF8입니다. UTF-8은 문자열의 중간바이트에서 0이 나타나지 않도록 고안되었습니다. 이를 위해 각 유니코드문자는 1바이트에서 4바이트까지 가변적으로 인코딩되도록 하고 있습니다.UTF-8에서는 U+0000 ~ U+007F까지의128자는 1바이트로 표현되는데 이는 ASCII와 동일합니다. 또 U+0080 ~ U+07FF까지는두 바이트, U+0800 ~ U+FFFF까지는 세 바이트로 표현됩니다. 즉 BMP내의모든 문자는 1 ~ 3바이트로 표현됩니다. 그리고 나머지 16개의 보충언어판에위치하는 1,048,576개의 코드는 네 바이트로 인코딩됩니다.다음 표에서 UCS-4와 UTF-8간의 변환 방법을 나타내고 있습니다. 표. UTF-8과 UCS-4간의 변환 규칙 UCS-4 UTF-8 0x00000000 - 0x0000007F 0xxxxxxx 0x00000080 - 0x000007FF 110xxxxx 10xxxxxx 0x00000800 - 0x0000FFFF 1110xxxx 10xxxxxx 10xxxxxx 0x00010000 - 0x001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0x00200000 - 0x03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0x04000000 - 0x7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 위의 표에서는 UCS-4와 UTF-8간의 변환 규칙을 보여주고 있습니다만, UCS-4의모든 영역에 대해서 보여주고 있습니다. 그러나 빨간색으로 칠한 부분을0x0010FFFF로 변경하고 나머지는 삭제해야 정확한 유니코드의 UTF-8 인코딩이라고할 수 있습니다. 이를 모두 표현한 것은 6바이트까지 확장하면 UTF-8로도UCS-4의 전역을 인코딩할 수 있음을 보여주기 위한 것입니다. 아마도 1백만자의코드이면 지구상에 존재했거나 존재하는 모든 문자를 표현하기에 충분할 것으로예상됩니다. 우주의 모든 언어코드를 표현해야 할 때가 오면 0x00110000 이후의영역도 사용할 가능성이 조금이나마 있을까요? 어쨌든, 현재 유니코드 표준에서는 UTF-8이 4바이트까지로 인코딩됩니다.유니코드에 정의된 각 코드는 반드시 다음과 같은 범위에서 인코딩되어야 합니다.다음 표는 UTF-8 인코딩에서 각 바이트에 올 수 있는 값을 보여주고 있습니다. 표. 올바른 UTF-8 바이트 배열 Code Points 1st Byte 2nd Byte 3rd Byte 4th Byte U+0000 ~ U+007F 00 ~ 7F       U+0080 ~ U+07FF C2 ~ DF 80 ~ BF     U+0800 ~ U+0FFF E0 A0 ~ BF 80 ~ BF   U+1000 ~ U+CFFF E1 ~ EC 80 ~ BF 80 ~ BF   U+D000 ~ U+D7FF ED 80 ~ 9F 80 ~ BF   U+D800 ~ U+DFFF ill-formed (surrogate 부분이므로 인코딩되어서는 안됨) U+E000 ~ U+FFFF EE ~ EF 80 ~ BF 80 ~ BF   U+10000 ~ U+3FFFF F0 90 ~ BF 80 ~ BF 80 ~ BF U+40000 ~ U+FFFFF F1 ~ F3 80 ~ BF 80 ~ BF 80 ~ BF U+100000 ~ U+10FFFF F4 80 ~ 8F 80 ~ BF 80 ~ BF UTF-16 UCS-2와 거의 동일합니다. 이 인코딩의 기본 단위는 16비트, 즉 2바이트입니다.대행문자 영역 2,048개를 제외한 63,488개의 코드를 문자로 사용할 수 있으며(BMP),대행문자 영역 2개의 쌍을 이용하여 16개의 보충언어판에 위치한 1,048,576개의코드를 표현할 수 있습니다. 대행 문자 2개의 쌍으로 1개의 문자를 인코딩한다는점에서 UTF-16의 인코딩은 가변적인 인코딩이라고 할 수 있겠군요.즉 기본언어판의 문자는 2바이트로 보충언어판의 문자는 4바이트로 인코딩됩니다.이러한 인코딩 방식때문에 UTF-16에서는 유니코드 표준에서 지원하는 17개의언어판 코드만 표현이 가능합니다. 가장 유니코드다운 인코딩이라고 할 수있겠군요 :-) 이제 대행코드 및 이를 이용한 보충언어판 코드의 인코딩 방식을 알아보겠습니다.유니코드 3.0에서 BMP의 U+D800부터 U+DFFF까지의 2,048 코드가 대행코드영역(surrogates)으로 정의되었습니다. 이중 U+D800 ~ U+DBFF의 1,024개를상위대행코드(high surrogates), U+DC00 ~ U+DFFF의 하위대행코드(lowsurrogates)라고 합니다. 상위대행코드 1개와 하위대행코드 1개의 조합으로,즉, 16비트 단위 2개로 보충언어판의 1백만여개의 코드를 지정할 수 있습니다. 두개의 대행코드로 조합된 코드를 UTF-32 코드로 대응시키는 공식은 다음과 같습니다. CodeValue = (HighSurrogate - 0xD800)*(LowSurrogate - 0xDC00) + 0x10000 여기서 CodeValue는 UTF-32 코드값입니다. 0xD800의 상위대행코드 영역의 시작점이며 0xDC00은 하위대행코드 영역의 첫번째 값입니다. 보충언어판은 0x10000부터 시작하므로 마지막에 이 값을 더해줍니다. 이 공식에 의해 CodeValue는 U+10000 ~ U+10FFFF까지 1048576개의 값을 가질 수 있게 됩니다. UTF-16에서는 상위대행코드가 나타나면 반드시 뒤이어 하위대행코드가 따라와야합니다. UCS-2에서는 그렇지 아니한 점이 UTF-16과 UCS-2의 차이점입니다. UTF-32 UTF-32는 32비트, 즉 4바이트로 모든 유니코드 문자를 표현합니다.UTF-8과 UTF-16에 대비해서 고정길이 인코딩이라고 할 수 있겠군요.4바이트 단위로 표현한다해서 UCS-4와 동일하게 볼 수는 없습니다.17개의 언어판만을 대상으로 하는 UCS-4의 부분집합이라고 보시면 됩니다(표준상그렇습니다). 즉 UTF-32의 인코딩 영역은 0x00000000에서 0x0010FFFF로제한되어야 합니다(이 제한을 무시하면 UCS-4와 동일합니다). 보충언어판에 대한 UTF-32와 UTF-16의 인코딩 위의 세 인코딩간의 변환은 알고리즘의 문제라고 할 수 있습니다.유니코드 컨소시엄에서 제공하는 C 언어로 된 변환 코드를 보면아주 간단하게 세 인코딩간의 변환이 이루어지는 것을 알 수 있습니다. 다음 표에서는 보충언어판(Supplementary Planes)의 코드 인코딩을UTF-32와 UTF-16 인코딩에 대해 보여줍니다. 표. UTF-32와 UTF-16의 보충언어판 코드 인코딩 언어판(plane) UTF-32 Encoding UTF-16 Encoding 1 0x00010000-0x0001FFFF 0xD800DC00-0xD83FDFFF 2 0x00020000-0x0002FFFF 0xD840DC00-0xD87FDFFF 3 0x00030000-0x0003FFFF 0xD880DC00-0xD8BFDFFF 4 0x00040000-0x0004FFFF 0xD8C0DC00-0xD8FFDFFF 5 0x00050000-0x0005FFFF 0xD900DC00-0xD93FDFFF 6 0x00060000-0x0006FFFF 0xD940DC00-0xD97FDFFF 7 0x00070000-0x0007FFFF 0xD980DC00-0xD9BFDFFF 8 0x00080000-0x0008FFFF 0xD9C0DC00-0xD9FFDFFF 9 0x00090000-0x0009FFFF 0xDA00DC00-0xDA3FDFFF 10 0x000A0000-0x000AFFFF 0xDA40DC00-0xDA7FDFFF 11 0x000B0000-0x000BFFFF 0xDA80DC00-0xDABFDFFF 12 0x000C0000-0x000CFFFF 0xDAC0DC00-0xDAFFDFFF 13 0x000D0000-0x000DFFFF 0xDB00DC00-0xDB3FDFFF 14 0x000E0000-0x000EFFFF 0xDB40DC00-0xDB7FDFFF 15 0x000F0000-0x000FFFFF 0xDB80DC00-0xDBBFDFFF 16 0x00100000-0x0010FFFF 0xDBC0DC00-0xDBFFDFFF UTF-16과 UTF-8에서의 대행코드 인코딩에 관한 오해 본 절에서는 대행코드(Surrogates)를 이용하여 보충언어판 코드영역을 인코딩할때 사람들이 종종 오해하는 부분에 대해서 설명하고자 합니다. 앞서 설명했듯이UTF-16에서는 U+10000 ~ U+10FFFF까지의 코드를 인코딩하기 위하여상위대행코드(high surrogate) 1개와 하위대행코드(low surrogate) 1개의 쌍으로표현한다고 하였습니다. 그렇다면 UTF-8에서도 두개의 대행코드를 각각 3바이트씩으로인코딩할 수 있을 것입니다(대행코드가 제안되었을 초기에 개발된 많은프로그램들이 실제로 이렇게 구현했었다고 합니다). 이 방식이 제대로 동작할 수는 있지만 세가지 문제점이 있습니다. 첫째 문제점은보충언어판의모든 코드가 6바이트로 인코딩된다는 것입니다 - 정상적인 방법으로는 4바이트로인코딩됩니다. 두번째는 인코딩된 문자열의 해석입니다. 보충언어판의 실제 코드값은 U+10000 ~ U+10FFFF인데 대행코드를 UTF-8 인코딩에 이용하게 되면,두개의 대행코드로부터실제 코드값으로 다시 계산해주어야 하는 번거로움이 있습니다. 세째, 텍스트인코딩의 안정성이 떨어진다는 것입니다. 세 바이트로 인코딩된 상위대행코드가나타나면 그 다음에는 반드시 하위대행코드가 따라와야 하므로,정상적인 방법에 비해 오류가 발생할 위험성이 그만큼 더 커진다는 것이죠. 이러한 문제점들 때문에 UTF-8에서는 대행코드 자체를 "절대로" 인코딩하지 않습니다.그래서 대행코드영역의 byte sequence를 보면 ill-formed라고 나타내고 있습니다.또한 대행코드를 인코딩한 것을 사용하게 되면 17개의 언어판 밖에는 표현할 수없다는 단점도 가지게 될 것입니다. 이러저러한 이유로 UTF-8은 규칙에 따라순서대로 코드값을 인코딩합니다. 따라서 대행코드영역(Surrogates)은UTF-16 인코딩에서만 됩니다. 기타 제가 프로그램해야 할 유니코드 처리부분은 UTF-8 인코딩을 사용합니다.이 인코딩은 바이트단위이기 때문에 컴퓨터 기종에 따라 발생하는 바이트배열(byte ordering) 순서를 무시할 수 있습니다. 하지만 UTF-16이나 UTF-32와같은 다바이트 인코딩을 이용하려면 이 문제를 신경써야 한다고 합니다.-- little-endian, big-endian 문제...이 때문에 바이트순서표식(BOM, Byte Oder Mark)을 사용하기를 권장합니다.즉 UTF-16이나 UTF-32 문자열의 처음에 BOM을 삽입하면 됩니다.각 인코딩의 BOM은 다음 표와 같습니다. 표. Little-endian, Big-endian 바이트순서에 따른 BOM 구분 Little-endian Big-endian UTF-16 0xFFFE 0xFEFF UTF-32 0x0000FFFE 0x0000FEFF 플랫폼 Intel 프로세서, DEC/Alpha 프로세서 RISC 프로세서, Motorola의 Microprocessor 운영체제 MS Windows, 리눅스/인텔 Unix, MacOS 요즘 생산되는 RISC CPU(MIPS나 ARM 같은)는 big-endian과 little-endian을모두 지원한다고 하는군요. 나의 생각: 개발자들에게는 무지하게 골치아프겠군요- 프로그램할 때 두가지 경우 모두에 대해 고려해야 할 테니... 어쨌든제가 타겟으로 삼고 있는 인코딩은 UTF-8로 정보검색시스템에서 사용할 예정이기때문에 바이트순서에는 별로 상관없을 것 같아서 다행이군요 :-) 참고문헌[Ken Kunde]에 엔디안문제에 따른 좋은 예제가 있어서 이를 설명할까합니다. UTF-16에서 0x4E와 0x00 두 바이트로 예를 들겠습니다.little- 또는 big-endian에 따라 둘의 조합은 0x4E00 또는 0x004E가 될 것입니다.Endian 방식에 따라 두 글자는 서로 다른 글자를 나타내게 됩니다. 결과는다음과 같습니다. 0x4E00/Big-endian : '一' (한자 1) 0x4E00/Little-endian : 'N' (대문자 N) 0x004E/Big-endian : 'N' (대문자 N) 0x004E/Little-endian : '一' (한자 1) 마지막으로 유니코드 컨소시엄이 제공하는 UTF8, UTF16, UTF32 인코딩간의변환 소스를 소개하겠습니다. 이 소스는 C 언어로 되어 있으며http://www.unicode.org/Public/PROGRAMS/CVTUTF/에서 다운로드받을수 있습니다. 이 소스를 분석해보면 각 인코딩 방법에 대해 명확하게이해할 수 있을 것입니다. 유니코드 관련 문서들을 접하면서 제가 받은 느낌은 유니코드는 유니코드컨소시움 답게, ISO/IEC 10646은 ISO답게 코드를 정의했다는 것입니다.그것도 동일한 내용을 정의하면서 느낌이 다르니 참 존경스럽더군요.무슨 말인고 하니, 유니코드는 업체가 제안한 코드이고 10646은 표준기구에서제안하는 코드라는 것입니다. 따라서 유니코드 쪽은 구현이 중요한 쟁점이되고 표준기구에서는 표준의 범용성, 확장성 등 구현 외의 관점들이 더 중요했을것이라는 것입니다. 이런 이유로 유니코드는 코드의 범위를 1백만자 정도로한정함으로써 구현이 쉬울 뿐만니라 코드자체로 인한 오류 발생 가능성을최소화 했다고 볼수 있습니다. 하지만 ISO의 입장에서는 그것이 먼 미래의일일지라도 새로운 문자의 수용 등을 고려할 수 있는 의미론적인 접근이더 중요했을 것 같습니다. 그래서 4바이트 정수형 전체를 코드로 사용할 수있는 가능성을 열어 놓은 것으로 보입니다. 같은 표준으로 참 절묘한차이를 보여주는군요. 긴 글을 다 읽어주셔서 감사합니다. 그리고 많은 도움이 되었기를 바랍니다.-- 김진숙 참고문헌 Unicode 홈페이지, http://www.unicode.org Unicode Online Data, http://www.unicode.org/Public Unicode Public Programs, http://www.unicode.org/Public/PROGRAMS Ken Lunde, 2001, "Unicode encodings: How to interoperate between UTF-8, UTF-16, and UTF-32" Adobe Systems. The Unicode Consortium, 2000, "The Unicode Standard 3.0", Addison-Wesley.

---

http://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C_A000~AFFF

유니코드 A000~AFFF

위키백과 ― 우리 모두의 백과사전.

이동: 둘러보기, 찾기

이 문서 안에는 일부 컴퓨터·브라우저에서 표시할 수 없는 문자가 있습니다. 그러므로 유니코드 글꼴이 있는 환경에서 보시는 것이 좋습니다.

다음은 U+A000에서 U+AFFF 안의 유니코드 문자 목록이다. ‘(Y)YYY0’번째 줄 ‘X’번째 칸에 있는 문자의 코드는 ‘U+(Y)YYYX’이고, HTML 실제 참조 코드는 ‘&#x(Y)YYYX;’이다. 이는 환경에 따라 표시가 다를 수 있다.

설명 유니코드 1.0 유니코드 4.0 유니코드 1.1 유니코드 4.1 유니코드 2.0 유니코드 5.0 유니코드 2.1 유니코드 5.1 유니코드 3.0 비어 있음 유니코드 3.1 사용하지 않음 유니코드 3.2

유니코드 목록 (범위) 기본 다국어 평면 보조 다국어 평면 보조 상형 문자 평면 보조 특수 목적 평면 0000~0FFF 1000~1FFF 2000~2FFF 3000~3FFF 4000~4FFF 5000~5FFF 6000~6FFF 7000~7FFF 8000~8FFF 9000~9FFF A000~AFFF B000~BFFF C000~CFFF D000~DFFF E000~EFFF F000~FFFF 10000~10FFF 11000~11FFF 12000~12FFF 13000~13FFF 14000~14FFF 15000~15FFF 16000~16FFF 17000~17FFF 18000~18FFF 19000~19FFF 1A000~1AFFF 1B000~1BFFF 1C000~1CFFF 1D000~1DFFF 1E000~1EFFF 1F000~1FFFF 20000~20FFF 21000~21FFF 22000~22FFF 23000~23FFF 24000~24FFF 25000~25FFF 26000~26FFF 27000~27FFF 28000~28FFF 29000~29FFF 2A000~2AFFF 2B000~2BFFF 2C000~2CFFF 2D000~2DFFF 2E000~2EFFF 2F000~2FFFF E0000~E0FFF

U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A000	ꀀ	ꀁ	ꀂ	ꀃ	ꀄ	ꀅ	ꀆ	ꀇ	ꀈ	ꀉ	ꀊ	ꀋ	ꀌ	ꀍ	ꀎ	ꀏ
A010	ꀐ	ꀑ	ꀒ	ꀓ	ꀔ	ꀕ	ꀖ	ꀗ	ꀘ	ꀙ	ꀚ	ꀛ	ꀜ	ꀝ	ꀞ	ꀟ
A020	ꀠ	ꀡ	ꀢ	ꀣ	ꀤ	ꀥ	ꀦ	ꀧ	ꀨ	ꀩ	ꀪ	ꀫ	ꀬ	ꀭ	ꀮ	ꀯ
A030	ꀰ	ꀱ	ꀲ	ꀳ	ꀴ	ꀵ	ꀶ	ꀷ	ꀸ	ꀹ	ꀺ	ꀻ	ꀼ	ꀽ	ꀾ	ꀿ
A040	ꁀ	ꁁ	ꁂ	ꁃ	ꁄ	ꁅ	ꁆ	ꁇ	ꁈ	ꁉ	ꁊ	ꁋ	ꁌ	ꁍ	ꁎ	ꁏ
A050	ꁐ	ꁑ	ꁒ	ꁓ	ꁔ	ꁕ	ꁖ	ꁗ	ꁘ	ꁙ	ꁚ	ꁛ	ꁜ	ꁝ	ꁞ	ꁟ
A060	ꁠ	ꁡ	ꁢ	ꁣ	ꁤ	ꁥ	ꁦ	ꁧ	ꁨ	ꁩ	ꁪ	ꁫ	ꁬ	ꁭ	ꁮ	ꁯ
A070	ꁰ	ꁱ	ꁲ	ꁳ	ꁴ	ꁵ	ꁶ	ꁷ	ꁸ	ꁹ	ꁺ	ꁻ	ꁼ	ꁽ	ꁾ	ꁿ
A080	ꂀ	ꂁ	ꂂ	ꂃ	ꂄ	ꂅ	ꂆ	ꂇ	ꂈ	ꂉ	ꂊ	ꂋ	ꂌ	ꂍ	ꂎ	ꂏ
A090	ꂐ	ꂑ	ꂒ	ꂓ	ꂔ	ꂕ	ꂖ	ꂗ	ꂘ	ꂙ	ꂚ	ꂛ	ꂜ	ꂝ	ꂞ	ꂟ
A0A0	ꂠ	ꂡ	ꂢ	ꂣ	ꂤ	ꂥ	ꂦ	ꂧ	ꂨ	ꂩ	ꂪ	ꂫ	ꂬ	ꂭ	ꂮ	ꂯ
A0B0	ꂰ	ꂱ	ꂲ	ꂳ	ꂴ	ꂵ	ꂶ	ꂷ	ꂸ	ꂹ	ꂺ	ꂻ	ꂼ	ꂽ	ꂾ	ꂿ
A0C0	ꃀ	ꃁ	ꃂ	ꃃ	ꃄ	ꃅ	ꃆ	ꃇ	ꃈ	ꃉ	ꃊ	ꃋ	ꃌ	ꃍ	ꃎ	ꃏ
A0D0	ꃐ	ꃑ	ꃒ	ꃓ	ꃔ	ꃕ	ꃖ	ꃗ	ꃘ	ꃙ	ꃚ	ꃛ	ꃜ	ꃝ	ꃞ	ꃟ
A0E0	ꃠ	ꃡ	ꃢ	ꃣ	ꃤ	ꃥ	ꃦ	ꃧ	ꃨ	ꃩ	ꃪ	ꃫ	ꃬ	ꃭ	ꃮ	ꃯ
A0F0	ꃰ	ꃱ	ꃲ	ꃳ	ꃴ	ꃵ	ꃶ	ꃷ	ꃸ	ꃹ	ꃺ	ꃻ	ꃼ	ꃽ	ꃾ	ꃿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A100	ꄀ	ꄁ	ꄂ	ꄃ	ꄄ	ꄅ	ꄆ	ꄇ	ꄈ	ꄉ	ꄊ	ꄋ	ꄌ	ꄍ	ꄎ	ꄏ
A110	ꄐ	ꄑ	ꄒ	ꄓ	ꄔ	ꄕ	ꄖ	ꄗ	ꄘ	ꄙ	ꄚ	ꄛ	ꄜ	ꄝ	ꄞ	ꄟ
A120	ꄠ	ꄡ	ꄢ	ꄣ	ꄤ	ꄥ	ꄦ	ꄧ	ꄨ	ꄩ	ꄪ	ꄫ	ꄬ	ꄭ	ꄮ	ꄯ
A130	ꄰ	ꄱ	ꄲ	ꄳ	ꄴ	ꄵ	ꄶ	ꄷ	ꄸ	ꄹ	ꄺ	ꄻ	ꄼ	ꄽ	ꄾ	ꄿ
A140	ꅀ	ꅁ	ꅂ	ꅃ	ꅄ	ꅅ	ꅆ	ꅇ	ꅈ	ꅉ	ꅊ	ꅋ	ꅌ	ꅍ	ꅎ	ꅏ
A150	ꅐ	ꅑ	ꅒ	ꅓ	ꅔ	ꅕ	ꅖ	ꅗ	ꅘ	ꅙ	ꅚ	ꅛ	ꅜ	ꅝ	ꅞ	ꅟ
A160	ꅠ	ꅡ	ꅢ	ꅣ	ꅤ	ꅥ	ꅦ	ꅧ	ꅨ	ꅩ	ꅪ	ꅫ	ꅬ	ꅭ	ꅮ	ꅯ
A170	ꅰ	ꅱ	ꅲ	ꅳ	ꅴ	ꅵ	ꅶ	ꅷ	ꅸ	ꅹ	ꅺ	ꅻ	ꅼ	ꅽ	ꅾ	ꅿ
A180	ꆀ	ꆁ	ꆂ	ꆃ	ꆄ	ꆅ	ꆆ	ꆇ	ꆈ	ꆉ	ꆊ	ꆋ	ꆌ	ꆍ	ꆎ	ꆏ
A190	ꆐ	ꆑ	ꆒ	ꆓ	ꆔ	ꆕ	ꆖ	ꆗ	ꆘ	ꆙ	ꆚ	ꆛ	ꆜ	ꆝ	ꆞ	ꆟ
A1A0	ꆠ	ꆡ	ꆢ	ꆣ	ꆤ	ꆥ	ꆦ	ꆧ	ꆨ	ꆩ	ꆪ	ꆫ	ꆬ	ꆭ	ꆮ	ꆯ
A1B0	ꆰ	ꆱ	ꆲ	ꆳ	ꆴ	ꆵ	ꆶ	ꆷ	ꆸ	ꆹ	ꆺ	ꆻ	ꆼ	ꆽ	ꆾ	ꆿ
A1C0	ꇀ	ꇁ	ꇂ	ꇃ	ꇄ	ꇅ	ꇆ	ꇇ	ꇈ	ꇉ	ꇊ	ꇋ	ꇌ	ꇍ	ꇎ	ꇏ
A1D0	ꇐ	ꇑ	ꇒ	ꇓ	ꇔ	ꇕ	ꇖ	ꇗ	ꇘ	ꇙ	ꇚ	ꇛ	ꇜ	ꇝ	ꇞ	ꇟ
A1E0	ꇠ	ꇡ	ꇢ	ꇣ	ꇤ	ꇥ	ꇦ	ꇧ	ꇨ	ꇩ	ꇪ	ꇫ	ꇬ	ꇭ	ꇮ	ꇯ
A1F0	ꇰ	ꇱ	ꇲ	ꇳ	ꇴ	ꇵ	ꇶ	ꇷ	ꇸ	ꇹ	ꇺ	ꇻ	ꇼ	ꇽ	ꇾ	ꇿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A200	ꈀ	ꈁ	ꈂ	ꈃ	ꈄ	ꈅ	ꈆ	ꈇ	ꈈ	ꈉ	ꈊ	ꈋ	ꈌ	ꈍ	ꈎ	ꈏ
A210	ꈐ	ꈑ	ꈒ	ꈓ	ꈔ	ꈕ	ꈖ	ꈗ	ꈘ	ꈙ	ꈚ	ꈛ	ꈜ	ꈝ	ꈞ	ꈟ
A220	ꈠ	ꈡ	ꈢ	ꈣ	ꈤ	ꈥ	ꈦ	ꈧ	ꈨ	ꈩ	ꈪ	ꈫ	ꈬ	ꈭ	ꈮ	ꈯ
A230	ꈰ	ꈱ	ꈲ	ꈳ	ꈴ	ꈵ	ꈶ	ꈷ	ꈸ	ꈹ	ꈺ	ꈻ	ꈼ	ꈽ	ꈾ	ꈿ
A240	ꉀ	ꉁ	ꉂ	ꉃ	ꉄ	ꉅ	ꉆ	ꉇ	ꉈ	ꉉ	ꉊ	ꉋ	ꉌ	ꉍ	ꉎ	ꉏ
A250	ꉐ	ꉑ	ꉒ	ꉓ	ꉔ	ꉕ	ꉖ	ꉗ	ꉘ	ꉙ	ꉚ	ꉛ	ꉜ	ꉝ	ꉞ	ꉟ
A260	ꉠ	ꉡ	ꉢ	ꉣ	ꉤ	ꉥ	ꉦ	ꉧ	ꉨ	ꉩ	ꉪ	ꉫ	ꉬ	ꉭ	ꉮ	ꉯ
A270	ꉰ	ꉱ	ꉲ	ꉳ	ꉴ	ꉵ	ꉶ	ꉷ	ꉸ	ꉹ	ꉺ	ꉻ	ꉼ	ꉽ	ꉾ	ꉿ
A280	ꊀ	ꊁ	ꊂ	ꊃ	ꊄ	ꊅ	ꊆ	ꊇ	ꊈ	ꊉ	ꊊ	ꊋ	ꊌ	ꊍ	ꊎ	ꊏ
A290	ꊐ	ꊑ	ꊒ	ꊓ	ꊔ	ꊕ	ꊖ	ꊗ	ꊘ	ꊙ	ꊚ	ꊛ	ꊜ	ꊝ	ꊞ	ꊟ
A2A0	ꊠ	ꊡ	ꊢ	ꊣ	ꊤ	ꊥ	ꊦ	ꊧ	ꊨ	ꊩ	ꊪ	ꊫ	ꊬ	ꊭ	ꊮ	ꊯ
A2B0	ꊰ	ꊱ	ꊲ	ꊳ	ꊴ	ꊵ	ꊶ	ꊷ	ꊸ	ꊹ	ꊺ	ꊻ	ꊼ	ꊽ	ꊾ	ꊿ
A2C0	ꋀ	ꋁ	ꋂ	ꋃ	ꋄ	ꋅ	ꋆ	ꋇ	ꋈ	ꋉ	ꋊ	ꋋ	ꋌ	ꋍ	ꋎ	ꋏ
A2D0	ꋐ	ꋑ	ꋒ	ꋓ	ꋔ	ꋕ	ꋖ	ꋗ	ꋘ	ꋙ	ꋚ	ꋛ	ꋜ	ꋝ	ꋞ	ꋟ
A2E0	ꋠ	ꋡ	ꋢ	ꋣ	ꋤ	ꋥ	ꋦ	ꋧ	ꋨ	ꋩ	ꋪ	ꋫ	ꋬ	ꋭ	ꋮ	ꋯ
A2F0	ꋰ	ꋱ	ꋲ	ꋳ	ꋴ	ꋵ	ꋶ	ꋷ	ꋸ	ꋹ	ꋺ	ꋻ	ꋼ	ꋽ	ꋾ	ꋿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A300	ꌀ	ꌁ	ꌂ	ꌃ	ꌄ	ꌅ	ꌆ	ꌇ	ꌈ	ꌉ	ꌊ	ꌋ	ꌌ	ꌍ	ꌎ	ꌏ
A310	ꌐ	ꌑ	ꌒ	ꌓ	ꌔ	ꌕ	ꌖ	ꌗ	ꌘ	ꌙ	ꌚ	ꌛ	ꌜ	ꌝ	ꌞ	ꌟ
A320	ꌠ	ꌡ	ꌢ	ꌣ	ꌤ	ꌥ	ꌦ	ꌧ	ꌨ	ꌩ	ꌪ	ꌫ	ꌬ	ꌭ	ꌮ	ꌯ
A330	ꌰ	ꌱ	ꌲ	ꌳ	ꌴ	ꌵ	ꌶ	ꌷ	ꌸ	ꌹ	ꌺ	ꌻ	ꌼ	ꌽ	ꌾ	ꌿ
A340	ꍀ	ꍁ	ꍂ	ꍃ	ꍄ	ꍅ	ꍆ	ꍇ	ꍈ	ꍉ	ꍊ	ꍋ	ꍌ	ꍍ	ꍎ	ꍏ
A350	ꍐ	ꍑ	ꍒ	ꍓ	ꍔ	ꍕ	ꍖ	ꍗ	ꍘ	ꍙ	ꍚ	ꍛ	ꍜ	ꍝ	ꍞ	ꍟ
A360	ꍠ	ꍡ	ꍢ	ꍣ	ꍤ	ꍥ	ꍦ	ꍧ	ꍨ	ꍩ	ꍪ	ꍫ	ꍬ	ꍭ	ꍮ	ꍯ
A370	ꍰ	ꍱ	ꍲ	ꍳ	ꍴ	ꍵ	ꍶ	ꍷ	ꍸ	ꍹ	ꍺ	ꍻ	ꍼ	ꍽ	ꍾ	ꍿ
A380	ꎀ	ꎁ	ꎂ	ꎃ	ꎄ	ꎅ	ꎆ	ꎇ	ꎈ	ꎉ	ꎊ	ꎋ	ꎌ	ꎍ	ꎎ	ꎏ
A390	ꎐ	ꎑ	ꎒ	ꎓ	ꎔ	ꎕ	ꎖ	ꎗ	ꎘ	ꎙ	ꎚ	ꎛ	ꎜ	ꎝ	ꎞ	ꎟ
A3A0	ꎠ	ꎡ	ꎢ	ꎣ	ꎤ	ꎥ	ꎦ	ꎧ	ꎨ	ꎩ	ꎪ	ꎫ	ꎬ	ꎭ	ꎮ	ꎯ
A3B0	ꎰ	ꎱ	ꎲ	ꎳ	ꎴ	ꎵ	ꎶ	ꎷ	ꎸ	ꎹ	ꎺ	ꎻ	ꎼ	ꎽ	ꎾ	ꎿ
A3C0	ꏀ	ꏁ	ꏂ	ꏃ	ꏄ	ꏅ	ꏆ	ꏇ	ꏈ	ꏉ	ꏊ	ꏋ	ꏌ	ꏍ	ꏎ	ꏏ
A3D0	ꏐ	ꏑ	ꏒ	ꏓ	ꏔ	ꏕ	ꏖ	ꏗ	ꏘ	ꏙ	ꏚ	ꏛ	ꏜ	ꏝ	ꏞ	ꏟ
A3E0	ꏠ	ꏡ	ꏢ	ꏣ	ꏤ	ꏥ	ꏦ	ꏧ	ꏨ	ꏩ	ꏪ	ꏫ	ꏬ	ꏭ	ꏮ	ꏯ
A3F0	ꏰ	ꏱ	ꏲ	ꏳ	ꏴ	ꏵ	ꏶ	ꏷ	ꏸ	ꏹ	ꏺ	ꏻ	ꏼ	ꏽ	ꏾ	ꏿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A400	ꐀ	ꐁ	ꐂ	ꐃ	ꐄ	ꐅ	ꐆ	ꐇ	ꐈ	ꐉ	ꐊ	ꐋ	ꐌ	ꐍ	ꐎ	ꐏ
A410	ꐐ	ꐑ	ꐒ	ꐓ	ꐔ	ꐕ	ꐖ	ꐗ	ꐘ	ꐙ	ꐚ	ꐛ	ꐜ	ꐝ	ꐞ	ꐟ
A420	ꐠ	ꐡ	ꐢ	ꐣ	ꐤ	ꐥ	ꐦ	ꐧ	ꐨ	ꐩ	ꐪ	ꐫ	ꐬ	ꐭ	ꐮ	ꐯ
A430	ꐰ	ꐱ	ꐲ	ꐳ	ꐴ	ꐵ	ꐶ	ꐷ	ꐸ	ꐹ	ꐺ	ꐻ	ꐼ	ꐽ	ꐾ	ꐿ
A440	ꑀ	ꑁ	ꑂ	ꑃ	ꑄ	ꑅ	ꑆ	ꑇ	ꑈ	ꑉ	ꑊ	ꑋ	ꑌ	ꑍ	ꑎ	ꑏ
A450	ꑐ	ꑑ	ꑒ	ꑓ	ꑔ	ꑕ	ꑖ	ꑗ	ꑘ	ꑙ	ꑚ	ꑛ	ꑜ	ꑝ	ꑞ	ꑟ
A460	ꑠ	ꑡ	ꑢ	ꑣ	ꑤ	ꑥ	ꑦ	ꑧ	ꑨ	ꑩ	ꑪ	ꑫ	ꑬ	ꑭ	ꑮ	ꑯ
A470	ꑰ	ꑱ	ꑲ	ꑳ	ꑴ	ꑵ	ꑶ	ꑷ	ꑸ	ꑹ	ꑺ	ꑻ	ꑼ	ꑽ	ꑾ	ꑿ
A480	ꒀ	ꒁ	ꒂ	ꒃ	ꒄ	ꒅ	ꒆ	ꒇ	ꒈ	ꒉ	ꒊ	ꒋ	ꒌ
A490	꒐	꒑	꒒	꒓	꒔	꒕	꒖	꒗	꒘	꒙	꒚	꒛	꒜	꒝	꒞	꒟
A4A0	꒠	꒡	꒢	꒣	꒤	꒥	꒦	꒧	꒨	꒩	꒪	꒫	꒬	꒭	꒮	꒯
A4B0	꒰	꒱	꒲	꒳	꒴	꒵	꒶	꒷	꒸	꒹	꒺	꒻	꒼	꒽	꒾	꒿
A4C0	꓀	꓁	꓂	꓃	꓄	꓅	꓆
A4D0
A4E0
A4F0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A500	ꔀ	ꔁ	ꔂ	ꔃ	ꔄ	ꔅ	ꔆ	ꔇ	ꔈ	ꔉ	ꔊ	ꔋ	ꔌ	ꔍ	ꔎ	ꔏ
A510	ꔐ	ꔑ	ꔒ	ꔓ	ꔔ	ꔕ	ꔖ	ꔗ	ꔘ	ꔙ	ꔚ	ꔛ	ꔜ	ꔝ	ꔞ	ꔟ
A520	ꔠ	ꔡ	ꔢ	ꔣ	ꔤ	ꔥ	ꔦ	ꔧ	ꔨ	ꔩ	ꔪ	ꔫ	ꔬ	ꔭ	ꔮ	ꔯ
A530	ꔰ	ꔱ	ꔲ	ꔳ	ꔴ	ꔵ	ꔶ	ꔷ	ꔸ	ꔹ	ꔺ	ꔻ	ꔼ	ꔽ	ꔾ	ꔿ
A540	ꕀ	ꕁ	ꕂ	ꕃ	ꕄ	ꕅ	ꕆ	ꕇ	ꕈ	ꕉ	ꕊ	ꕋ	ꕌ	ꕍ	ꕎ	ꕏ
A550	ꕐ	ꕑ	ꕒ	ꕓ	ꕔ	ꕕ	ꕖ	ꕗ	ꕘ	ꕙ	ꕚ	ꕛ	ꕜ	ꕝ	ꕞ	ꕟ
A560	ꕠ	ꕡ	ꕢ	ꕣ	ꕤ	ꕥ	ꕦ	ꕧ	ꕨ	ꕩ	ꕪ	ꕫ	ꕬ	ꕭ	ꕮ	ꕯ
A570	ꕰ	ꕱ	ꕲ	ꕳ	ꕴ	ꕵ	ꕶ	ꕷ	ꕸ	ꕹ	ꕺ	ꕻ	ꕼ	ꕽ	ꕾ	ꕿ
A580	ꖀ	ꖁ	ꖂ	ꖃ	ꖄ	ꖅ	ꖆ	ꖇ	ꖈ	ꖉ	ꖊ	ꖋ	ꖌ	ꖍ	ꖎ	ꖏ
A590	ꖐ	ꖑ	ꖒ	ꖓ	ꖔ	ꖕ	ꖖ	ꖗ	ꖘ	ꖙ	ꖚ	ꖛ	ꖜ	ꖝ	ꖞ	ꖟ
A5A0	ꖠ	ꖡ	ꖢ	ꖣ	ꖤ	ꖥ	ꖦ	ꖧ	ꖨ	ꖩ	ꖪ	ꖫ	ꖬ	ꖭ	ꖮ	ꖯ
A5B0	ꖰ	ꖱ	ꖲ	ꖳ	ꖴ	ꖵ	ꖶ	ꖷ	ꖸ	ꖹ	ꖺ	ꖻ	ꖼ	ꖽ	ꖾ	ꖿ
A5C0	ꗀ	ꗁ	ꗂ	ꗃ	ꗄ	ꗅ	ꗆ	ꗇ	ꗈ	ꗉ	ꗊ	ꗋ	ꗌ	ꗍ	ꗎ	ꗏ
A5D0	ꗐ	ꗑ	ꗒ	ꗓ	ꗔ	ꗕ	ꗖ	ꗗ	ꗘ	ꗙ	ꗚ	ꗛ	ꗜ	ꗝ	ꗞ	ꗟ
A5E0	ꗠ	ꗡ	ꗢ	ꗣ	ꗤ	ꗥ	ꗦ	ꗧ	ꗨ	ꗩ	ꗪ	ꗫ	ꗬ	ꗭ	ꗮ	ꗯ
A5F0	ꗰ	ꗱ	ꗲ	ꗳ	ꗴ	ꗵ	ꗶ	ꗷ	ꗸ	ꗹ	ꗺ	ꗻ	ꗼ	ꗽ	ꗾ	ꗿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A600	ꘀ	ꘁ	ꘂ	ꘃ	ꘄ	ꘅ	ꘆ	ꘇ	ꘈ	ꘉ	ꘊ	ꘋ	ꘌ	꘍	꘎	꘏
A610	ꘐ	ꘑ	ꘒ	ꘓ	ꘔ	ꘕ	ꘖ	ꘗ	ꘘ	ꘙ	ꘚ	ꘛ	ꘜ	ꘝ	ꘞ	ꘟ
A620	꘠	꘡	꘢	꘣	꘤	꘥	꘦	꘧	꘨	꘩	ꘪ	ꘫ
A630
A640	Ꙁ	ꙁ	Ꙃ	ꙃ	Ꙅ	ꙅ	Ꙇ	ꙇ	Ꙉ	ꙉ	Ꙋ	ꙋ	Ꙍ	ꙍ	Ꙏ	ꙏ
A650	Ꙑ	ꙑ	Ꙓ	ꙓ	Ꙕ	ꙕ	Ꙗ	ꙗ	Ꙙ	ꙙ	Ꙛ	ꙛ	Ꙝ	ꙝ	Ꙟ	ꙟ
A660			Ꙣ	ꙣ	Ꙥ	ꙥ	Ꙧ	ꙧ	Ꙩ	ꙩ	Ꙫ	ꙫ	Ꙭ	ꙭ	ꙮ	꙯
A670	꙰	꙱	꙲	꙳									꙼	꙽	꙾	ꙿ
A680	Ꚁ	ꚁ	Ꚃ	ꚃ	Ꚅ	ꚅ	Ꚇ	ꚇ	Ꚉ	ꚉ	Ꚋ	ꚋ	Ꚍ	ꚍ	Ꚏ	ꚏ
A690	Ꚑ	ꚑ	Ꚓ	ꚓ	Ꚕ	ꚕ	Ꚗ	ꚗ			Ꚛ	ꚛ	ꚜ	ꚝ	ꚞ	ꚟ
A6A0
A6B0
A6C0
A6D0
A6E0
A6F0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A700	꜀	꜁	꜂	꜃	꜄	꜅	꜆	꜇	꜈	꜉	꜊	꜋	꜌	꜍	꜎	꜏
A710	꜐	꜑	꜒	꜓	꜔	꜕	꜖	ꜗ	ꜘ	ꜙ	ꜚ	ꜛ	ꜜ	ꜝ	ꜞ	ꜟ
A720	꜠	꜡	Ꜣ	ꜣ	Ꜥ	ꜥ	Ꜧ	ꜧ	Ꜩ	ꜩ	Ꜫ	ꜫ	Ꜭ	ꜭ	Ꜯ	ꜯ
A730	ꜰ	ꜱ	Ꜳ	ꜳ	Ꜵ	ꜵ	Ꜷ	ꜷ	Ꜹ	ꜹ	Ꜻ	ꜻ	Ꜽ	ꜽ	Ꜿ	ꜿ
A740	Ꝁ	ꝁ	Ꝃ	ꝃ	Ꝅ	ꝅ	Ꝇ	ꝇ	Ꝉ	ꝉ	Ꝋ	ꝋ	Ꝍ	ꝍ	Ꝏ	ꝏ
A750	Ꝑ	ꝑ	Ꝓ	ꝓ	Ꝕ	ꝕ	Ꝗ	ꝗ	Ꝙ	ꝙ	Ꝛ	ꝛ	Ꝝ	ꝝ	Ꝟ	ꝟ
A760	Ꝡ	ꝡ	Ꝣ	ꝣ	Ꝥ	ꝥ	Ꝧ	ꝧ	Ꝩ	ꝩ	Ꝫ	ꝫ	Ꝭ	ꝭ	Ꝯ	ꝯ
A770	ꝰ	ꝱ	ꝲ	ꝳ	ꝴ	ꝵ	ꝶ	ꝷ	ꝸ	Ꝺ	ꝺ	Ꝼ	ꝼ	Ᵹ	Ꝿ	ꝿ
A780	Ꞁ	ꞁ	Ꞃ	ꞃ	Ꞅ	ꞅ	Ꞇ	ꞇ	ꞈ	꞉	꞊	Ꞌ	ꞌ
A790
A7A0
A7B0
A7C0
A7D0
A7E0
A7F0												ꟻ	ꟼ	ꟽ	ꟾ	ꟿ
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A800	ꠀ	ꠁ	ꠂ	ꠃ	ꠄ	ꠅ	꠆	ꠇ	ꠈ	ꠉ	ꠊ	ꠋ	ꠌ	ꠍ	ꠎ	ꠏ
A810	ꠐ	ꠑ	ꠒ	ꠓ	ꠔ	ꠕ	ꠖ	ꠗ	ꠘ	ꠙ	ꠚ	ꠛ	ꠜ	ꠝ	ꠞ	ꠟ
A820	ꠠ	ꠡ	ꠢ	ꠣ	ꠤ	ꠥ	ꠦ	ꠧ	꠨	꠩	꠪	꠫
A830
A840	ꡀ	ꡁ	ꡂ	ꡃ	ꡄ	ꡅ	ꡆ	ꡇ	ꡈ	ꡉ	ꡊ	ꡋ	ꡌ	ꡍ	ꡎ	ꡏ
A850	ꡐ	ꡑ	ꡒ	ꡓ	ꡔ	ꡕ	ꡖ	ꡗ	ꡘ	ꡙ	ꡚ	ꡛ	ꡜ	ꡝ	ꡞ	ꡟ
A860	ꡠ	ꡡ	ꡢ	ꡣ	ꡤ	ꡥ	ꡦ	ꡧ	ꡨ	ꡩ	ꡪ	ꡫ	ꡬ	ꡭ	ꡮ	ꡯ
A870	ꡰ	ꡱ	ꡲ	ꡳ	꡴	꡵	꡶	꡷
A880	ꢀ	ꢁ	ꢂ	ꢃ	ꢄ	ꢅ	ꢆ	ꢇ	ꢈ	ꢉ	ꢊ	ꢋ	ꢌ	ꢍ	ꢎ	ꢏ
A890	ꢐ	ꢑ	ꢒ	ꢓ	ꢔ	ꢕ	ꢖ	ꢗ	ꢘ	ꢙ	ꢚ	ꢛ	ꢜ	ꢝ	ꢞ	ꢟ
A8A0	ꢠ	ꢡ	ꢢ	ꢣ	ꢤ	ꢥ	ꢦ	ꢧ	ꢨ	ꢩ	ꢪ	ꢫ	ꢬ	ꢭ	ꢮ	ꢯ
A8B0	ꢰ	ꢱ	ꢲ	ꢳ	ꢴ	ꢵ	ꢶ	ꢷ	ꢸ	ꢹ	ꢺ	ꢻ	ꢼ	ꢽ	ꢾ	ꢿ
A8C0	ꣀ	ꣁ	ꣂ	ꣃ	꣄										꣎	꣏
A8D0	꣐	꣑	꣒	꣓	꣔	꣕	꣖	꣗	꣘	꣙
A8E0
A8F0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A900	꤀	꤁	꤂	꤃	꤄	꤅	꤆	꤇	꤈	꤉	ꤊ	ꤋ	ꤌ	ꤍ	ꤎ	ꤏ
A910	ꤐ	ꤑ	ꤒ	ꤓ	ꤔ	ꤕ	ꤖ	ꤗ	ꤘ	ꤙ	ꤚ	ꤛ	ꤜ	ꤝ	ꤞ	ꤟ
A920	ꤠ	ꤡ	ꤢ	ꤣ	ꤤ	ꤥ	ꤦ	ꤧ	ꤨ	ꤩ	ꤪ	꤫	꤬	꤭	꤮	꤯
A930	ꤰ	ꤱ	ꤲ	ꤳ	ꤴ	ꤵ	ꤶ	ꤷ	ꤸ	ꤹ	ꤺ	ꤻ	ꤼ	ꤽ	ꤾ	ꤿ
A940	ꥀ	ꥁ	ꥂ	ꥃ	ꥄ	ꥅ	ꥆ	ꥇ	ꥈ	ꥉ	ꥊ	ꥋ	ꥌ	ꥍ	ꥎ	ꥏ
A950	ꥐ	ꥑ	ꥒ	꥓	꥔											꥟
A960
A970
A980
A990
A9A0
A9B0
A9C0
A9D0
A9E0
A9F0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AA00	ꨀ	ꨁ	ꨂ	ꨃ	ꨄ	ꨅ	ꨆ	ꨇ	ꨈ	ꨉ	ꨊ	ꨋ	ꨌ	ꨍ	ꨎ	ꨏ
AA10	ꨐ	ꨑ	ꨒ	ꨓ	ꨔ	ꨕ	ꨖ	ꨗ	ꨘ	ꨙ	ꨚ	ꨛ	ꨜ	ꨝ	ꨞ	ꨟ
AA20	ꨠ	ꨡ	ꨢ	ꨣ	ꨤ	ꨥ	ꨦ	ꨧ	ꨨ	ꨩ	ꨪ	ꨫ	ꨬ	ꨭ	ꨮ	ꨯ
AA30	ꨰ	ꨱ	ꨲ	ꨳ	ꨴ	ꨵ	ꨶ
AA40	ꩀ	ꩁ	ꩂ	ꩃ	ꩄ	ꩅ	ꩆ	ꩇ	ꩈ	ꩉ	ꩊ	ꩋ	ꩌ	ꩍ
AA50	꩐	꩑	꩒	꩓	꩔	꩕	꩖	꩗	꩘	꩙			꩜	꩝	꩞	꩟
AA60
AA70
AA80
AA90
AAA0
AAB0
AAC0
AAD0
AAE0
AAF0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AB00
AB10
AB20
AB30
AB40
AB50
AB60
AB70
AB80
AB90
ABA0
ABB0
ABC0
ABD0
ABE0
ABF0
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AC00	가	각	갂	갃	간	갅	갆	갇	갈	갉	갊	갋	갌	갍	갎	갏
AC10	감	갑	값	갓	갔	강	갖	갗	갘	같	갚	갛	개	객	갞	갟
AC20	갠	갡	갢	갣	갤	갥	갦	갧	갨	갩	갪	갫	갬	갭	갮	갯
AC30	갰	갱	갲	갳	갴	갵	갶	갷	갸	갹	갺	갻	갼	갽	갾	갿
AC40	걀	걁	걂	걃	걄	걅	걆	걇	걈	걉	걊	걋	걌	걍	걎	걏
AC50	걐	걑	걒	걓	걔	걕	걖	걗	걘	걙	걚	걛	걜	걝	걞	걟
AC60	걠	걡	걢	걣	걤	걥	걦	걧	걨	걩	걪	걫	걬	걭	걮	걯
AC70	거	걱	걲	걳	건	걵	걶	걷	걸	걹	걺	걻	걼	걽	걾	걿
AC80	검	겁	겂	것	겄	겅	겆	겇	겈	겉	겊	겋	게	겍	겎	겏
AC90	겐	겑	겒	겓	겔	겕	겖	겗	겘	겙	겚	겛	겜	겝	겞	겟
ACA0	겠	겡	겢	겣	겤	겥	겦	겧	겨	격	겪	겫	견	겭	겮	겯
ACB0	결	겱	겲	겳	겴	겵	겶	겷	겸	겹	겺	겻	겼	경	겾	겿
ACC0	곀	곁	곂	곃	계	곅	곆	곇	곈	곉	곊	곋	곌	곍	곎	곏
ACD0	곐	곑	곒	곓	곔	곕	곖	곗	곘	곙	곚	곛	곜	곝	곞	곟
ACE0	고	곡	곢	곣	곤	곥	곦	곧	골	곩	곪	곫	곬	곭	곮	곯
ACF0	곰	곱	곲	곳	곴	공	곶	곷	곸	곹	곺	곻	과	곽	곾	곿
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AD00	관	괁	괂	괃	괄	괅	괆	괇	괈	괉	괊	괋	괌	괍	괎	괏
AD10	괐	광	괒	괓	괔	괕	괖	괗	괘	괙	괚	괛	괜	괝	괞	괟
AD20	괠	괡	괢	괣	괤	괥	괦	괧	괨	괩	괪	괫	괬	괭	괮	괯
AD30	괰	괱	괲	괳	괴	괵	괶	괷	괸	괹	괺	괻	괼	괽	괾	괿
AD40	굀	굁	굂	굃	굄	굅	굆	굇	굈	굉	굊	굋	굌	굍	굎	굏
AD50	교	굑	굒	굓	굔	굕	굖	굗	굘	굙	굚	굛	굜	굝	굞	굟
AD60	굠	굡	굢	굣	굤	굥	굦	굧	굨	굩	굪	굫	구	국	굮	굯
AD70	군	굱	굲	굳	굴	굵	굶	굷	굸	굹	굺	굻	굼	굽	굾	굿
AD80	궀	궁	궂	궃	궄	궅	궆	궇	궈	궉	궊	궋	권	궍	궎	궏
AD90	궐	궑	궒	궓	궔	궕	궖	궗	궘	궙	궚	궛	궜	궝	궞	궟
ADA0	궠	궡	궢	궣	궤	궥	궦	궧	궨	궩	궪	궫	궬	궭	궮	궯
ADB0	궰	궱	궲	궳	궴	궵	궶	궷	궸	궹	궺	궻	궼	궽	궾	궿
ADC0	귀	귁	귂	귃	귄	귅	귆	귇	귈	귉	귊	귋	귌	귍	귎	귏
ADD0	귐	귑	귒	귓	귔	귕	귖	귗	귘	귙	귚	귛	규	귝	귞	귟
ADE0	균	귡	귢	귣	귤	귥	귦	귧	귨	귩	귪	귫	귬	귭	귮	귯
ADF0	귰	귱	귲	귳	귴	귵	귶	귷	그	극	귺	귻	근	귽	귾	귿
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AE00	글	긁	긂	긃	긄	긅	긆	긇	금	급	긊	긋	긌	긍	긎	긏
AE10	긐	긑	긒	긓	긔	긕	긖	긗	긘	긙	긚	긛	긜	긝	긞	긟
AE20	긠	긡	긢	긣	긤	긥	긦	긧	긨	긩	긪	긫	긬	긭	긮	긯
AE30	기	긱	긲	긳	긴	긵	긶	긷	길	긹	긺	긻	긼	긽	긾	긿
AE40	김	깁	깂	깃	깄	깅	깆	깇	깈	깉	깊	깋	까	깍	깎	깏
AE50	깐	깑	깒	깓	깔	깕	깖	깗	깘	깙	깚	깛	깜	깝	깞	깟
AE60	깠	깡	깢	깣	깤	깥	깦	깧	깨	깩	깪	깫	깬	깭	깮	깯
AE70	깰	깱	깲	깳	깴	깵	깶	깷	깸	깹	깺	깻	깼	깽	깾	깿
AE80	꺀	꺁	꺂	꺃	꺄	꺅	꺆	꺇	꺈	꺉	꺊	꺋	꺌	꺍	꺎	꺏
AE90	꺐	꺑	꺒	꺓	꺔	꺕	꺖	꺗	꺘	꺙	꺚	꺛	꺜	꺝	꺞	꺟
AEA0	꺠	꺡	꺢	꺣	꺤	꺥	꺦	꺧	꺨	꺩	꺪	꺫	꺬	꺭	꺮	꺯
AEB0	꺰	꺱	꺲	꺳	꺴	꺵	꺶	꺷	꺸	꺹	꺺	꺻	꺼	꺽	꺾	꺿
AEC0	껀	껁	껂	껃	껄	껅	껆	껇	껈	껉	껊	껋	껌	껍	껎	껏
AED0	껐	껑	껒	껓	껔	껕	껖	껗	께	껙	껚	껛	껜	껝	껞	껟
AEE0	껠	껡	껢	껣	껤	껥	껦	껧	껨	껩	껪	껫	껬	껭	껮	껯
AEF0	껰	껱	껲	껳	껴	껵	껶	껷	껸	껹	껺	껻	껼	껽	껾	껿
U+	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
AF00	꼀	꼁	꼂	꼃	꼄	꼅	꼆	꼇	꼈	꼉	꼊	꼋	꼌	꼍	꼎	꼏
AF10	꼐	꼑	꼒	꼓	꼔	꼕	꼖	꼗	꼘	꼙	꼚	꼛	꼜	꼝	꼞	꼟
AF20	꼠	꼡	꼢	꼣	꼤	꼥	꼦	꼧	꼨	꼩	꼪	꼫	꼬	꼭	꼮	꼯
AF30	꼰	꼱	꼲	꼳	꼴	꼵	꼶	꼷	꼸	꼹	꼺	꼻	꼼	꼽	꼾	꼿
AF40	꽀	꽁	꽂	꽃	꽄	꽅	꽆	꽇	꽈	꽉	꽊	꽋	꽌	꽍	꽎	꽏
AF50	꽐	꽑	꽒	꽓	꽔	꽕	꽖	꽗	꽘	꽙	꽚	꽛	꽜	꽝	꽞	꽟
AF60	꽠	꽡	꽢	꽣	꽤	꽥	꽦	꽧	꽨	꽩	꽪	꽫	꽬	꽭	꽮	꽯
AF70	꽰	꽱	꽲	꽳	꽴	꽵	꽶	꽷	꽸	꽹	꽺	꽻	꽼	꽽	꽾	꽿
AF80	꾀	꾁	꾂	꾃	꾄	꾅	꾆	꾇	꾈	꾉	꾊	꾋	꾌	꾍	꾎	꾏
AF90	꾐	꾑	꾒	꾓	꾔	꾕	꾖	꾗	꾘	꾙	꾚	꾛	꾜	꾝	꾞	꾟
AFA0	꾠	꾡	꾢	꾣	꾤	꾥	꾦	꾧	꾨	꾩	꾪	꾫	꾬	꾭	꾮	꾯
AFB0	꾰	꾱	꾲	꾳	꾴	꾵	꾶	꾷	꾸	꾹	꾺	꾻	꾼	꾽	꾾	꾿
AFC0	꿀	꿁	꿂	꿃	꿄	꿅	꿆	꿇	꿈	꿉	꿊	꿋	꿌	꿍	꿎	꿏
AFD0	꿐	꿑	꿒	꿓	꿔	꿕	꿖	꿗	꿘	꿙	꿚	꿛	꿜	꿝	꿞	꿟
AFE0	꿠	꿡	꿢	꿣	꿤	꿥	꿦	꿧	꿨	꿩	꿪	꿫	꿬	꿭	꿮	꿯
AFF0	꿰	꿱	꿲	꿳	꿴	꿵	꿶	꿷	꿸	꿹	꿺	꿻	꿼	꿽	꿾	꿿

char *를 유니코드(WCHAR)로 변경하기

2008/09/23 20:37 :: 프로그램하는손군

출처: http://blog.empas.com/palazzo/read.html?a=11547141

L" " 사용

또는

MultiByteToWideChar 이 함수를 사용

------------------------------------------------------------------------

---ex-----

 

function(L"아야어여");

 

char *mychar = "아야어여";

WCHAR myWCHAR[256];

MultiByteToWideChar( CP_ACP, 0, mychar  , strlen(mychar)+1,

  myWCHAR, sizeof(myWCHAR)/sizeof(myWCHAR[0]));

 

유니코드를 char*로 변경은

WideCharToMultiByte()를 사용한다.