mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-11-29 12:00:36

유니코드


파일:나무위키+유도.png  
은(는) 여기로 연결됩니다.
D4DJ의 등장 유닛에 대한 내용은 UniChØrd 문서
를
의 번 문단을
의 부분을
, 대한민국의 5인조 걸그룹에 대한 내용은 유니코드(아이돌) 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
, 에 대한 내용은 문서
를
의 번 문단을
의 번 문단을
의 부분을
의 부분을
참고하십시오.

[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]
[ 펼치기 · 접기 ]
||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 || 수학( 해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학( 환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학( 형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU( 그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
기술 기계어 · 어셈블리어 · C/ C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시( SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속
연구
및
기타 		논리 회로( 보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{ 컴파일러( 어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩( 유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도( 최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리( 기계 번역 · 음성인식) · 버전 ( 버전 관리 시스템 · Git · GitHub)

<colcolor=#5555FF> Unicode
파일:유니코드 로고.svg
파일:홈페이지 아이콘.svg | 테크니컬 사이트 | 파일:X Corp 아이콘(블랙).svg | 파일:유튜브 아이콘.svg
1. 개요2. 역사3. 표기 관례4. 유니코드 테이블
4.1. 유니코드의 구조 및 블록 목록4.2. 유니코드와 한글
4.2.1. 한글 전산화4.2.2. 조합형 낱자들로 만들 수 있는 한글 완성자의 수4.2.3. 옛한글과 유니코드 정규화의 부작용
4.3. 유니코드와 한자
4.3.1. 한자 통합 기준4.3.2. CJK 통합 한자와 CJK 호환용 한자의 차이4.3.3. 미묘한 이체자 처리 문제
4.4. 문자 비할당 영역
5. 인코딩
5.1. UTF-85.2. UTF-165.3. UCS-25.4. UTF-32
6. 유니코드 정규화7. 변종 문자(위 첨자·아래 첨자·작은 대문자 등) 사용 시 권장 사항8. 유니코드 지원 폰트9. 키보드에 없는 문자 입력하기10. 관련 문서
10.1. 개별 문서가 있는 유니코드 특수 문자

[clearfix]

1. 개요

유니코드(Unicode)는 전 세계의 모든 문자를 다루도록 설계된 표준 문자 전산 처리 방식이다. 유니코드 컨소시엄(Unicode Consortium)에서 제정, 관리한다.

주요 구성 요소는 ISO/IEC 10646 Universal Character Set과 UCS, UTF 등의 인코딩 방식, 문자 처리 알고리즘 등이다. 전 세계의 모든 문자를 담는 ISO/IEC 10646 코드표를 사용함으로써, 각 언어와 문자 체계에 따른 충돌 문제를 해결하였다. 따라서 유니코드를 사용하면 한글과 신자체· 간체자, 아랍 문자 등을 통일된 환경에서 사용할 수 있다.

컴퓨터의 태동기에는 거의 컴퓨터 제조사마다 문자 코드를 하나씩 가지고 있었으나, 1963년 ASCII가 등장한 이후 1바이트 문자 코드는 차차 ASCII로 통합되기에 이른다. 문제는 ASCII는 로마자, 그것도 영어에서 쓰는 알파벳 26자만 들어 있는 코드였다는 것이다. 때문에 ě나 ý처럼 영어에서 쓰지 않는 로마자를 쓰는 나라들은 ASCII의 남는 공간에 자신들의 언어에서 쓰는 알파벳을 할당하여 확장 ASCII를 만들었다. 또 한자나 한글처럼 글자 수가 너무 많아, 도저히 1바이트 공간에 문자를 다 넣을 수가 없는 한자 문화권 국가들은 2바이트 MBCS를 만들어 사용하였다. 이러한 접근법은 컴퓨터로 다른 나라의 문서를 처리할 일이 별로 없었던 80년대까지는 그럭저럭 작동했다.

하지만 인터넷으로 전 세계의 컴퓨터가 연결되기 시작하자 이야기가 달라졌는데, 다른 국가에 이메일을 보냈더니 글자가 와장창 깨졌던 것. 인터넷 웹 페이지도 마찬가지였다. 이런 세계적 흐름에서 2바이트(16비트, 65,535자) 공간에 세상의 모든 문자를 넣어서 전산화해 보자는 야심찬 목표로 출범한 프로젝트가 유니코드이다. 다만 프로젝트가 출범한 지 몇 년 되지 않아서 세상의 모든 문자를 넣기에 65,535자로는 부족하다는 사실이 밝혀졌고[1], 결국 공간을 4바이트(32비트, 약 42억 자)로 넉넉하게 늘리면서 정말로 세상의 모든 문자를 할당할 수 있을 정도가 되었다.

현재의 유니코드는 지구상에서 통용되는 대부분의 문자들을 담고 있다. 여기에는 언어를 표기할 때 쓰는 문자는 물론, 악보 기호, 이모지, 태그, 마작이나 도미노 기호 같은 것들도 포함된다.

모든 문자 체계를 담고 있는 것은 아니라서, 과거에 사용된 문자 체계나 쓰임이 적은 인공 문자,[2] 자료가 많이 남아 있지 않은 문자 체계는 등록이 되어있지 않아 유니코드로 표현할 수 없다. 물론 아직 유니코드에 없다뿐이지 어지간한 문자 체계는 유니코드에 집어 넣으려는 계획이 진행 중이다. 앞으로 유니코드에 뭘 넣을지 보여 주는 로드맵[3]이 있는데 꽤 알차게 차 있다. 물론 빈 공간도 꽤 있어 앞으로 유니코드 공간이 부족한 일이 생기려면 한참 남았다. 17개의 플레인 중에 현재는 7개만 사용되고 10개는 아직 사용되지 않고 있다. 공실률(?)로 치면 60%에 육박하는, 말 그대로 반 이상이 현재 미할당이다.

2. 역사

유니코드는 1991년 10월에 최초 버전(1.0.0)이 발표됐으며, 1992년 6월 1.0.1버전에서 CJK 공통 한자(CJK Unified Ideographs)가 정의되었다. 1993년 6월 1.1버전에서 기존 한글 2,350글자에 추가 4,306글자가 할당되었다. 그러다가 1996년 7월 2.0버전이 발표되었는데, 한국 측의 요청으로 한글 대이동 사건이 벌어졌다. 기존 배치는 삭제되고, 현대 한글의 모든 글자 11,172개가 U+AC00~D7A3 영역으로 재배치되었다. 그리고 이후로는 한번 할당된 문자는 더 이상 옮기지 않는다는 원칙도 만들어졌다.

현재 최신 버전은 2024년 9월 12일에 발표된 16.0이다.

3. 표기 관례

유니코드 문자의 경우 해당 글자의 코드를 표기할 때 U+(16진수 숫자)[4]라고 쓴다. 예를 들면 한글 '가' 자는 유니코드에서 16진수로 AC00(10진수의 44032)라는 코드 넘버를 가지는데, 이것을 U+AC00이라고 적는 식이다.

문자 표기 관례는 아니지만 16진수 표기의 관례를 따라 0x 를 붙여 0xAC00라고 표기된 경우도 간혹 있으니 참고하면 좋다. 레지스트리 편집 등의 컴퓨터에서의 수 표현 영역으로 넘어가면 AC 00이라 적힌 것을 볼 수 있고, Endian에 따라 00 AC로 적히기도 한다.

참고로 U+라는 표기 자체는 LG( LG U+)보다 유니코드 쪽이 20년 정도 먼저 써 왔다.

4. 유니코드 테이블

4.1. 유니코드의 구조 및 블록 목록

유니코드 문자 집합의 문자 평면
{{{#!wiki style="word-break: keep-all; margin:0 -10px -5px; min-height:calc(1.5em + 5px)"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-5px -1px -11px" 		<rowcolor=#FFF> 기본 보조
<rowcolor=#FFF> Plane 0
0000~FFFF 		Plane 1
10000~1FFFF 		Plane 2
20000~2FFFF 		Plane 3
30000~3FFFF 		Planes 4-13
40000~DFFFF 		Plane 14
E0000~EFFFF 		Planes 15-16
F0000~10FFFF
기본 다국어 평면
BMP 		보조 다국어 평면
SMP 		보조 표의문자 평면
SIP 		3차 표의문자 평면
TIP 		(사용 안 함) 보조 특수 목적 평면
SSP 		사용자 자유 영역
PUA
0XXX 8XXX 10XXX 18XXX 20XXX 28XXX 30XXX 38XXX 문자 없음 E0XXX 15: PUA-A
1XXX 9XXX 11XXX 19XXX 21XXX 29XXX 31XXX 39XXX F0000-​FFFFF
2XXX AXXX 12XXX 1AXXX 22XXX 2AXXX 32XXX 3AXXX
3XXX BXXX 13XXX 1BXXX 23XXX 2BXXX 33XXX 3BXXX 16: PUA-B
4XXX CXXX 14XXX 1CXXX 24XXX 2CXXX 34XXX 3CXXX 100000-​10FFFF
5XXX DXXX 15XXX 1DXXX 25XXX 2DXXX 35XXX 3DXXX
6XXX EXXX 16XXX 1EXXX 26XXX 2EXXX 36XXX 3EXXX
7XXX FXXX 17XXX 1FXXX 27XXX 2FXXX 37XXX 3FXXX
}}}}}}}}} ||


유니코드는 대개 기본 문자가 들어 있는 BMP(Basic Multilingual Plane), BMP에 없는 옛 글자 등을 넣는 SMP(Supplementary Multilingual Plane), 한자를 더 넣기 위해 별도로 정의한 SIP(Supplementary Ideographic Plane), 확장 한자 G 등이 포함되는 TIP(Tertiary Ideographic Plane), 앞의 영역에 포함되지 않는 기타 문자 등이 들어가는 SSP(Supplementary Special-purpose Plane), 자유 영역인 PUA(Private Use Area) 등이 정의되어 있다.

자세한 구조는 다음 표와 같다.
[표 펼치기 · 접기]
||<rowcolor=#111><bgcolor=#CCEEFF> 평면 ||<bgcolor=#CCEEFF> 블록 시작 ||<bgcolor=#CCEEFF> 블록 끝 ||<bgcolor=#CCEEFF> 블록 크기 ||<bgcolor=#CCEEFF> 블록 이름 ||<colcolor=#111><bgcolor=#CCEEFF> UTF-8 바이트 수 ||
BMP U+0000 U+007F 128자 Basic Latin 1[5]
U+0080 U+00FF 128자 Latin-1 Supplement 2
U+0100 U+017F 128자 Latin Extended-A
U+0180 U+024F 208자 Latin Extended-B
U+0250 U+02AF 96자 IPA Extensions
U+02B0 U+02FF 80자 Spacing Modifier Letters
U+0300 U+036F 112자 Combining Diacritical Marks
U+0370 U+03FF 144자 Greek and Coptic
U+0400 U+04FF 256자 Cyrillic
U+0500 U+052F 48자 Cyrillic Supplement
U+0530 U+058F 96자 Armenian
U+0590 U+05FF 112자 Hebrew
U+0600 U+06FF 256자 Arabic
U+0700 U+074F 80자 Syriac
U+0750 U+077F 48자 Arabic Supplement
U+0780 U+07BF 64자 Thaana
U+07C0 U+07FF 64자 NKo
U+0800 U+083F 64자 Samaritan 3
U+0840 U+085F 32자 Mandaic
U+0860 U+086F 16자 Syriac Supplement
U+0870 U+089F 48자 Arabic Extended-B
U+08A0 U+08FF 96자 Arabic Extended-A
U+0900 U+097F 128자 Devanagari
U+0980 U+09FF 128자 Bengali
U+0A00 U+0A7F 128자 Gurmukhi
U+0A80 U+0AFF 128자 Gujarati
U+0B00 U+0B7F 128자 Oriya
U+0B80 U+0BFF 128자 Tamil
U+0C00 U+0C7F 128자 Telugu
U+0C80 U+0CFF 128자 Kannada
U+0D00 U+0D7F 128자 Malayalam
U+0D80 U+0DFF 128자 Sinhala
U+0E00 U+0E7F 128자 Thai
U+0E80 U+0EFF 128자 Lao
U+0F00 U+0FFF 256자 Tibetan
U+1000 U+109F 160자 Myanmar
U+10A0 U+10FF 96자 Georgian
U+1100 U+11FF 256자 Hangul Jamo[6]
U+1200 U+137F 384자 Ethiopic
U+1380 U+139F 32자 Ethiopic Supplement
U+13A0 U+13FF 96자 Cherokee
U+1400 U+167F 640자 Unified Canadian Aboriginal Syllabics
U+1680 U+169F 32자 Ogham
U+16A0 U+16FF 96자 Runic
U+1700 U+171F 32자 Tagalog
U+1720 U+173F 32자 Hanunoo[M]
U+1740 U+175F 32자 Buhid[M]
U+1760 U+177F 32자 Tagbanwa[9]
U+1780 U+17FF 128자 Khmer
U+1800 U+18AF 176자 Mongolian
U+18B0 U+18FF 80자 Unified Canadian Aboriginal Syllabics Extended
U+1900 U+194F 80자 Limbu
U+1950 U+197F 48자 Tai Le[10]
U+1980 U+19DF 96자 New Tai Lue
U+19E0 U+19FF 32자 Khmer Symbols
U+1A00 U+1A1F 32자 Buginese
U+1A20 U+1AAF 144자 Tai Tham[11]
U+1AB0 U+1AFF 80자 Combining Diacritical Marks Extended
U+1B00 U+1B7F 128자 Balinese
U+1B80 U+1BBF 64자 Sundanese
U+1BC0 U+1BFF 64자 Batak
U+1C00 U+1C4F 80자 Lepcha[12]
U+1C50 U+1C7F 48자 Ol Chiki
U+1C80 U+1C8F 16자 Cyrillic Extended-C
U+1CC0 U+1CCF 16자 Sundanese Supplement
U+1CD0 U+1CFF 48자 Vedic Extensions
U+1D00 U+1D7F 128자 Phonetic Extensions
U+1D80 U+1DBF 64자 Phonetic Extensions Supplement
U+1DC0 U+1DFF 64자 Combining Diacritical Marks Supplement
U+1E00 U+1EFF 256자 Latin Extended Additional
U+1F00 U+1FFF 256자 Greek Extended
U+2000 U+206F 112자 General Punctuation
U+2070 U+209F 48자 Superscripts and Subscripts
U+20A0 U+20CF 48자 Currency Symbols
U+20D0 U+20FF 48자 Combining Diacritical Marks for Symbols
U+2100 U+214F 80자 Letterlike Symbols
U+2150 U+218F 64자 Number Forms
U+2190 U+21FF 112자 Arrows
U+2200 U+22FF 256자 Mathematical Operators
U+2300 U+23FF 256자 Miscellaneous Technical
U+2400 U+243F 64자 Control Pictures
U+2440 U+245F 32자 Optical Character Recognition
U+2460 U+24FF 160자 Enclosed Alphanumerics
U+2500 U+257F 128자 Box Drawing
U+2580 U+259F 32자 Block Elements
U+25A0 U+25FF 96자 Geometric Shapes
U+2600 U+26FF 256자 Miscellaneous Symbols
U+2700 U+27BF 192자 Dingbats
U+27C0 U+27EF 48자 Miscellaneous Mathematical Symbols-A
U+27F0 U+27FF 16자 Supplemental Arrows-A
U+2800 U+28FF 256자 Braille Patterns
U+2900 U+297F 128자 Supplemental Arrows-B
U+2980 U+29FF 128자 Miscellaneous Mathematical Symbols-B
U+2A00 U+2AFF 256자 Supplemental Mathematical Operators
U+2B00 U+2BFF 256자 Miscellaneous Symbols and Arrows
U+2C00 U+2C5F 96자 Glagolitic
U+2C60 U+2C7F 32자 Latin Extended-C
U+2C80 U+2CFF 128자 Coptic
U+2D00 U+2D2F 48자 Georgian Supplement
U+2D30 U+2D7F 80자 Tifinagh
U+2D80 U+2DDF 96자 Ethiopic Extended
U+2DE0 U+2DFF 32자 Cyrillic Extended-A
U+2E00 U+2E7F 128자 Supplemental Punctuation
U+2E80 U+2EFF 128자 CJK Radicals Supplement
U+2F00 U+2FDF 224자 Kangxi Radicals
U+2FF0 U+2FFF 16자 Ideographic Description Characters
U+3000 U+303F 64자 CJK Symbols and Punctuation
U+3040 U+309F 96자 Hiragana
U+30A0 U+30FF 96자 Katakana
U+3100 U+312F 48자 Bopomofo
U+3130 U+318F 96자 Hangul Compatibility Jamo
U+3190 U+319F 16자 Kanbun
U+31A0 U+31BF 32자 Bopomofo Extended
U+31C0 U+31EF 48자 CJK Strokes
U+31F0 U+31FF 16자 Katakana Phonetic Extensions
U+3200 U+32FF 256자 Enclosed CJK Letters and Months
U+3300 U+33FF 256자 CJK Compatibility
U+3400 U+4DBF 6592자 CJK Unified Ideographs Extension A
U+4DC0 U+4DFF 64자 Yijing Hexagram Symbols
U+4E00 U+9FFF 20992자 CJK Unified Ideographs
U+A000 U+A48F 1168자 Yi Syllables
U+A490 U+A4CF 64자 Yi Radicals
U+A4D0 U+A4FF 48자 Lisu
U+A500 U+A63F 320자 Vai[13]
U+A640 U+A69F 96자 Cyrillic Extended-B
U+A6A0 U+A6FF 96자 Bamum
U+A700 U+A71F 32자 Modifier Tone Letters
U+A720 U+A7FF 224자 Latin Extended-D
U+A800 U+A82F 48자 Syloti Nagri
U+A830 U+A83F 16자 Common Indic Number Forms
U+A840 U+A87F 64자 Phags-pa
U+A880 U+A8DF 96자 Saurashtra
U+A8E0 U+A8FF 32자 Devanagari Extended
U+A900 U+A92F 48자 Kayah Li
U+A930 U+A95F 48자 Rejang
U+A960 U+A97F 32자 Hangul Jamo Extended-A
U+A980 U+A9DF 96자 Javanese
U+A9E0 U+A9FF 32자 Myanmar Extended-B
U+AA00 U+AA5F 96자 Cham
U+AA60 U+AA7F 32자 Myanmar Extended-A
U+AA80 U+AADF 96자 Tai Viet
U+AAE0 U+AAFF 32자 Meetei Mayek Extensions
U+AB00 U+AB2F 48자 Ethiopic Extended-A
U+AB30 U+AB6F 64자 Latin Extended-E
U+AB70 U+ABBF 80자 Cherokee Supplement
U+ABC0 U+ABFF 64자 Meetei Mayek
U+AC00 U+D7AF 11184자 Hangul Syllables
U+D7B0 U+D7FF 80자 Hangul Jamo Extended-B
U+D800 U+DB7F 896자 High Surrogates
U+DB80 U+DBFF 128자 High Private Use Surrogates
U+DC00 U+DFFF 1024자 Low Surrogates
U+E000 U+F8FF 6400자 Private Use Area[14]
U+F900 U+FAFF 512자 CJK Compatibility Ideographs
U+FB00 U+FB4F 80자 Alphabetic Presentation Forms
U+FB50 U+FDFF 688자 Arabic Presentation Forms-A
U+FE00 U+FE0F 16자 Variation Selectors
U+FE10 U+FE1F 16자 Vertical Forms
U+FE20 U+FE2F 16자 Combining Half Marks
U+FE30 U+FE4F 32자 CJK Compatibility Forms
U+FE50 U+FE6F 32자 Small Form Variants
U+FE70 U+FEFF 144자 Arabic Presentation Forms-B[15]
U+FF00 U+FFEF 240자 Halfwidth and Fullwidth Forms
U+FFF0 U+FFFF 16자 Specials
SMP U+10000 U+1007F 128자 Linear B Syllabary 4
U+10080 U+100FF 128자 Linear B Ideograms
U+10100 U+1013F 64자 Aegean Numbers
U+10140 U+1018F 80자 Ancient Greek Numbers
U+10190 U+101CF 64자 Ancient Symbols
U+101D0 U+101FF 48자 Phaistos Disc
U+10280 U+1029F 32자 Lycian
U+102A0 U+102DF 64자 Carian
U+102E0 U+102FF 32자 Coptic Epact Numbers
U+10300 U+1032F 48자 Old Italic
U+10330 U+1034F 32자 Gothic
U+10350 U+1037F 48자 Old Permic
U+10380 U+1039F 32자 Ugaritic
U+103A0 U+103DF 64자 Old Persian
U+10400 U+1044F 80자 Deseret
U+10450 U+1047F 48자 Shavian
U+10480 U+104AF 48자 Osmanya
U+104B0 U+104FF 80자 Osage
U+10500 U+1052F 48자 Elbasan
U+10530 U+1056F 64자 Caucasian Albanian
U+10600 U+1077F 384자 Linear A
U+10800 U+1083F 64자 Cypriot Syllabary
U+10840 U+1085F 32자 Imperial Aramaic
U+10860 U+1087F 32자 Palmyrene
U+10880 U+108AF 48자 Nabataean
U+108E0 U+108FF 32자 Hatran
U+10900 U+1091F 32자 Phoenician
U+10920 U+1093F 32자 Lydian
U+10980 U+1099F 32자 Meroitic Hieroglyphs
U+109A0 U+109FF 96자 Meroitic Cursive
U+10A00 U+10A5F 96자 Kharoshthi
U+10A60 U+10A7F 32자 Old South Arabian
U+10A80 U+10A9F 32자 Old North Arabian
U+10AC0 U+10AFF 64자 Manichaean
U+10B00 U+10B3F 64자 Avestan
U+10B40 U+10B5F 32자 Inscriptional Parthian
U+10B60 U+10B7F 32자 Inscriptional Pahlavi
U+10B80 U+10BAF 48자 Psalter Pahlavi
U+10C00 U+10C4F 80자 Old Turkic
U+10C80 U+10CFF 128자 Old Hungarian
U+10E60 U+10E7F 32자 Rumi Numeral Symbols
U+11000 U+1107F 128자 Brahmi
U+11080 U+110CF 80자 Kaithi
U+110D0 U+110FF 48자 Sora Sompeng
U+11100 U+1114F 80자 Chakma
U+11150 U+1117F 48자 Mahajani
U+11180 U+111DF 96자 Sharada
U+111E0 U+111FF 32자 Sinhala Archaic Numbers
U+11200 U+1124F 80자 Khojki
U+11280 U+112AF 48자 Multani
U+112B0 U+112FF 80자 Khudawadi
U+11300 U+1137F 128자 Grantha
U+11400 U+1147F 128자 Newa
U+11480 U+114DF 96자 Tirhuta
U+11580 U+115FF 128자 Siddham
U+11600 U+1165F 96자 Modi
U+11660 U+1167F 32자 Mongolian Supplement
U+11680 U+116CF 80자 Takri
U+11700 U+1173F 64자 Ahom
U+118A0 U+118FF 96자 Warang Citi
U+11A00 U+11A4F 80자 Zanabazar Square
U+11A50 U+11AAF 96자 Soyombo
U+11AC0 U+11AFF 64자 Pau Cin Hau
U+11C00 U+11C6F 112자 Bhaiksuki
U+11C70 U+11CBF 80자 Marchen
U+11D00 U+11D5F 96자 Masaram Gondi
U+12000 U+123FF 1024자 Cuneiform
U+12400 U+1247F 128자 Cuneiform Numbers and Punctuation
U+12480 U+1254F 208자 Early Dynastic Cuneiform
U+13000 U+1342F 1072자 Egyptian Hieroglyphs
U+14400 U+1467F 640자 Anatolian Hieroglyphs
U+16800 U+16A3F 576자 Bamum Supplement
U+16A40 U+16A6F 48자 Mro
U+16AD0 U+16AFF 48자 Bassa Vah
U+16B00 U+16B8F 144자 Pahawh Hmong
U+16F00 U+16F9F 160자 Miao
U+16FE0 U+16FFF 32자 Ideographic Symbols and Punctuation
U+17000 U+187FF 6144자 Tangut
U+18800 U+18AFF 768자 Tangut Components
U+1B000 U+1B0FF 256자 Kana Supplement
U+1B100 U+1B12F 48자 Kana Extended-A
U+1B170 U+1B2FF 400자 Nushu
U+1BC00 U+1BC9F 160자 Duployan
U+1BCA0 U+1BCAF 16자 Shorthand Format Controls
U+1D000 U+1D0FF 256자 Byzantine Musical Symbols
U+1D100 U+1D1FF 256자 Musical Symbols
U+1D200 U+1D24F 80자 Ancient Greek Musical Notation
U+1D300 U+1D35F 96자 Tai Xuan Jing Symbols
U+1D360 U+1D37F 32자 Counting Rod Numerals
U+1D400 U+1D7FF 1024자 Mathematical Alphanumeric Symbols
U+1D800 U+1DAAF 688자 Sutton SignWriting
U+1E000 U+1E02F 48자 Glagolitic Supplement
U+1E800 U+1E8DF 224자 Mende Kikakui
U+1E900 U+1E95F 96자 Adlam
U+1EE00 U+1EEFF 256자 Arabic Mathematical Alphabetic Symbols
U+1F000 U+1F02F 48자 Mahjong Tiles
U+1F030 U+1F09F 112자 Domino Tiles
U+1F0A0 U+1F0FF 96자 Playing Cards[16]
U+1F100 U+1F1FF 256자 Enclosed Alphanumeric Supplement
U+1F200 U+1F2FF 256자 Enclosed Ideographic Supplement
U+1F300 U+1F5FF 768자 Miscellaneous Symbols and Pictographs
U+1F600 U+1F64F 80자 Emoticons
U+1F650 U+1F67F 48자 Ornamental Dingbats
U+1F680 U+1F6FF 128자 Transport and Map Symbols
U+1F700 U+1F77F 128자 Alchemical Symbols
U+1F780 U+1F7FF 128자 Geometric Shapes Extended
U+1F800 U+1F8FF 256자 Supplemental Arrows-C
U+1F900 U+1F9FF 256자 Supplemental Symbols and Pictographs
SIP U+20000 U+2A6DF 42720자 CJK Unified Ideographs Extension B
U+2A700 U+2B73F 4160자 CJK Unified Ideographs Extension C
U+2B740 U+2B81F 224자 CJK Unified Ideographs Extension D
U+2B820 U+2CEAF 5776자 CJK Unified Ideographs Extension E
U+2CEB0 U+2EBEF 7488자 CJK Unified Ideographs Extension F
U+2F800 U+2FA1F 544자 CJK Compatibility Ideographs Supplement
TIP U+30000 U+3134F 4944자 CJK Unified Ideographs Extension G
SSP U+E0000 U+E007F 128자 Tags
U+E0100 U+E01EF 240자 Variation Selectors Supplement
PUA U+F0000 U+FFFFF 65536자 Supplementary Private Use Area-A
U+100000 U+10FFFF 65536자 Supplementary Private Use Area-B

기본 평면은 0번 평면으로, 보조 평면은 1번부터 16번 평면으로 평면 번호가 붙는다. 각 평면의 마지막 두 자리(U+xxFFFE, U+xxFFFF)는 비문자(Noncharacter) 영역으로 지정되어 문자가 배당되지 않고 빈자리로 남는다.
거의 알려지지 않은 사실이지만, 새로 배당 및 추가되는 문자들과 스크립트들은 상술한 유니코드 컨소시엄뿐만이 아니라, 외부인들이 제출하는 일종의 아이디어 문서를 검토 및 반영해서 추가되기도 한다. 혹시 궁금할 경우 옆의 두 링크를 참고하자. # #

CJK Unified Ideographs는 정확히 말하면 CJKV Unified Ideographs라고 해야 맞다. 유니코드의 CJK Unified Ideographs에는 근대 이전에 베트남어의 고유어를 표기하기 위해 사용하던 쯔놈 글자들도 섞여 있기 때문이다. 그런데 이미 유니코드 초창기(1.0)부터 CJK Unified Ideograph(s)로 불렀고(당시에는 한국, 중국, 대만, 일본의 표준 문자 코드만을 고려했고, 쯔놈은 상대적으로 나중에 추가됐다), 영역 이름과 문자 이름은 한번 정해지면 절대로 고칠 수 없기 때문에 이를 CJKV로 고치기에는 이미 너무 늦었다.

4.2. 유니코드와 한글

한글의 전산화
<colbgcolor=#dddddd,#212121> 한글 인코딩 조합형 · 완성형( 한글 목록 · 중복 한자 · CP949) · 조합형 완성형 논쟁 · 남북한 한글 코드의 충돌 문제 · 한컴 2바이트 코드 · 한글 채움 문자( ㅤ) · 유니코드 · 옛한글
타자기와 키보드 두벌식 · 세벌식( 일반 자판 · 속기 자판) · 휴대전화 입력기 · 한영 키


유니코드에서 한글은 8만 자 이상인 한자 다음으로 많은 코드를 차지하고 있는 문자다. 왜 저렇게 많냐면 현대 한국어 음절 조합과 한글 자모를 모두 집어넣었기 때문이다. 한글의 경우, 현대 한국어의 자모 조합으로 나타낼 수 있는 모든 한글 글자 11,172자(가, 각, 갂, 갃, …, 힠, 힡, 힢, 힣)이 모두 들어가 있다. 그래서 쿈이나 슌처럼 한글 채움 문자 없이 KS X 1001에서는 쓸 수 없는 글자들도 전혀 문제없이 쓸 수 있다.[18]

또한 U+1100 ~ U+11FF, U+A960 ~ U+A97F, U+D7B0 ~ U+D7FF에 배당된 한글 자모는 한글을 조합형으로 구현할 수 있게 초·중·종성을 일일이 배당한 것이며, 여기에는 옛한글 낱자들도 같이 포함되어 있다. 그래서 ᄒᆞᆫ과 같은 옛한글도 옛한글 전용 글꼴만 있으면 문제없이 쓸 수 있다.

따라서 유니코드 환경이라면 현대 한글은 완성형으로도 조합형으로도 표현할 수 있지만, 조합형은 데이터 크기가 3배로 커지기 때문에 별로 사용되지 않는다. 보통 조합형은 옛한글을 표현할 때 쓰인다. 옛한글을 완성형으로 하나하나 배당하려면 유니코드 전체를 다 쓰더라도 모자라기 때문에 조합형으로 표현할 수밖에 없다.[19]

4.2.1. 한글 전산화

대한민국의 한국어 컴퓨터 환경에서는 유니코드가 도입되기 전에는 주로 2바이트 완성형(KS C 5601-1987, 조합형을 복수 표준으로 만든 KS C 5601-1992와 다른 한글 코드 표준들과 통합하고 2004년에 개정되면서 KS X 1001:2004로 개칭됨)이라는 코드와 이에 기반한 EUC-KR 인코딩을 사용하였다. 그러나 완성형의 한글 글자 수는 2,350자로, 현대 한글이 표현할 수 있는 글자 중 빈도가 높은 일부분만 수록되어 있는 상태였다. 이것 때문에 똠을 똠이라 쓰지 못하는 일이 있기도 했다[20]. 이를 해결한 CP949/UHC(통합 완성형)라는 코드도 있는데 완성형에 없는 글자를 억지로 구겨 넣었기 때문에 코드가 자모 순으로 구성되지 않을 뿐만 아니라 코드 표준에 맞지 않게 구현한 프로그램이 많아서 자잘한 문제가 많았다. 사실 한글 채움 문자를 쓰면 되겠지만 불편해서 잘 쓰이진 않았다.

유니코드는 1991년 발표된 1.0 버전부터 KS C 5601에 포함된 완성형 2,350자 한글을 지원하였다. 1993년 발표된 1.1 버전에는 KS C 5657(이후 KS X 1002)에 포함된 1,930자 및 중국에서 요청한 6글자를 포함한 2,376자를 추가해 총 6,656자가 수록되었다.[21] 믿기 어렵겠지만 유니코드 1.1에는 옛한글까지 고려한 조합형 한글 낱자도 포함되어 있었고(U+1100 - U+11FF) 실제로 이걸로 넘어가자는 제안도 있었다.[22] 그러나 당시 한국에서는 2,350자를 벗어난 현대 한글을 사용하려면 그냥 조합형을 사용하면 되었기 때문에 이렇게 추가된 6,656자만으로는 유니코드 기반 완성형을 사용할 이유가 없었다. 조합형이라고 해서 상황이 나은 것도 아닌게 첫가끝 기반 조합형은 90년대 초반까지 한국에서 사용한 조합형과는 달랐고, 지금도 OS X과 윈도우 사이에서 파일을 복사할 때 자주 글자가 풀려 버리는 등 이걸 제대로 지원하는 플랫폼은 흔치 않다. 완성형 한글도 한 번에 일괄적으로 추가되지 않았고 빠진 글자들이 단계별로 추가되었기 때문에 배열 순서가 CP949/UHC보다도 개판이었고 나머지 4,516자를 추가하려고 해도 제대로 추가할 수가 없었다. 한편 유니코드 1.1을 지원했다가 한국에서 한동안 피를 본 프로그램 중 하나가 오라클 DB이었다. 자세한 사항은 오라클(기업) 개요를 참고할 것.

그래서 대한민국 대표는 유니코드 2.0 제정 시 완성형 현대 한글 11,172자를 가나다순으로 새 영역에 배당할 것을 요청했다. 한국 대표는 유니코드의 한글 배당을 바꿔달라고 주장하면서, 당시까지 유니코드를 사용하는 한글 소프트웨어가 사실상 거의 존재하지 않아서 호환성에 문제가 없다고 주장했다. 또한 그렇게 쓰는 소프트웨어가 없는 이유 중 하나가 완성형을 기반으로 한 유니코드의 문제 때문이기도 했으며, 이는 한국이 유니코드에서 벗어나서 별도의 표준을 사용하게 되는 사태를 일으킬 수도 있었다.

이 요청에 대해 각국 대표들 사이에서 논쟁이 오갔지만, 결국 대한민국 대표의 요청이 받아들여져서 1996년 발표된 유니코드 2.0에서 1.1 때까지 U+3400 ~ U+4DFF[23]에 배당되어 있던 한글 6,656자를 없애고 새 영역(U+AC00 ~ U+D7A3)에 가나다순으로 11,172자를 배당했다. 이렇게 배당된 11,172자가 2.0부터 현재까지 한글·한국어 처리에 쓰이고 있다. 이로 인해 유니코드 2.0 이상과 그 이전 버전은 서로 호환되지 않는다. 그리고 이 '한글 대이동 사건'을 계기로 2.0부터는 한번 배당한 문자는 절대 옮기거나 없애지 않는다는 정책을 세웠다.

당연하게도 이 11,172자는 대한민국의 가나다순으로 배당되었다. 대한민국과 북한은 한글 낱자의 정렬 순서가 다른데[24], 북한이 이것을 문제 삼아 이 11,172자를 북한식으로 재배열해 줄 것을 2000년경에 요구했으나, 이미 한글은 코드 위치가 한번 대이동한 전례도 있고 문자를 절대 옮기거나 없애지 않는다는 정책에도 위배되기 때문에 보기 좋게 씹혔다. 그리고 북한은 코드순으로 정렬하면 북한식으로 제대로 정렬이 되지 않는다는 것을 문제 삼았는데, 단순 코드순 정렬은 어차피 그 어떤 언어에서도 적절하지 않으며, 정렬은 따로 테이블을 만들거나 알고리즘을 짜서 해야 한다. 영어조차도 코드순으로 정렬하면 대문자 Z가 소문자 a보다 앞에 온다. 물론 코드에서 이미 정렬이 되어 있으면 정렬 테이블 및 알고리즘 제작이 쉬워지고 받침에 따라 바뀌는 조사 붙이기가 용이해진다는 장점은 있다. 과거 확장 완성형이나 유니코드 1.1이 문제가 됐던 것도 배열 순서가 너무 심하게 뒤죽박죽이었기 때문이다.

그래서 한때 북한에서는 자기네들 순서를 기준으로 한글 영역을 쓴 적이 있었다. 남북한 한글 코드의 충돌 문제 문서 참고. 지금 북한은 울며 겨자 먹기로 대한민국순으로 배당된 11,172자를 쓰고 있다.

북한은 이것만이 아니라 자기들이 우상화 목적으로 국규 9566에 배당한 ' 김, 일, 성, 김, 정, 일'도 그대로 유니코드에 넣고자 했으나 퇴짜 맞았다. 그래서 북한에서 만들어진 폰트에서는 볼드 처리한 김, 일, 성, 김, 정, 일, 김, 정, 은을 PUA 코드에 할당하기도 하며, 북한제 운영 체제의 입력기에서도 이걸 감안하여 김일성, 김정일, 김정은 이름을 쓰면 자동으로 PUA 내 볼드 처리된 글자로 변환한다고 한다. PUA, 문화어 문서 참조.

4.2.2. 조합형 낱자들로 만들 수 있는 한글 완성자의 수

유니코드에 있는 모든 한글 낱자는 다음과 같다. 자음의 경우 위의 것이 초성, 아래의 것이 종성이다.

파일:attachment/UnicodeHangulJamoInOrder.png
없음 종류 낱자 개수
HCF[25] A
초성 		ᄀ ᄁ ᅚ ~ ᅘ ᅙ ꥼ 125
HJF[26] B
중성 		ᅡ ᅶ ᅷ ~ ᆠ ᆡ ᆢ 95
(없음)[27] C
종성 		ᆨ ᆩ ᇺ ~ ᇷ ᇸ ᇹ 138

일단 단순 계산으로만 125×95×138=1,638,750자가 나온다(!). 여기서 125, 95, 138은 각각 초성, 중성, 종성이 비어 있는 경우도 포함한 수치이다. 즉 '가'와 같이 종성이 없는 글자(A+B+없음)도, 'ᅟᅡᆨ'과 같이 초성이 없는 글자(HCF+B+C)도[28], 'ᄀᅠᆨ'과 같이 중성이 없는 글자(A+HJF+C)도 들어간 것이다.

다만, 여기서 다음 수만큼 빼야 한다. 즉 KS X 1026-1 규격상으로 허용되는 모든 한글 완성자는 1638750−(1+16988)=1621761자가 된다.

여기에는 초성, 중성, 종성 중 한 자모만 드러나고 나머지는 HCF나 HJF, (종성 없음)인 것도 있는데 이들을 단순히 낱자로 치고 완성자로 치지 않는다면, 위 1621761자에서 다음 수만큼 또 빼야 할 것이다. 즉 1621761−(124+94+137)=1621406자가 될 것이다.

이 1621406자에 초성과 종성만으로 이뤄진 글자(A+HJF+C)를 다시 더한다면 1621761−(124+94+137)+16988=1638394자가 될 것이다. 즉 초성, 중성, 종성 중 두 개 이상의 자모가 쓰여 만들어진 완성자 개수가 된다.

물론 어디까지나 '이론적으로' 160만 자 정도 나오는 것이고, 실제로 고문헌에 등장하는 글자 수는 5천여 자 정도밖에 안 된다고 한다. 현대 한글 낱자로 조합 가능한 11,172자 중에서 실제로 쓰이는 건 2천 ~ 3천 자 정도밖에 안 되는 것과 비슷하다고 보면 된다. 물론 이런 안일(?)한 생각 때문에 초기 완성형과 같은 문제가 생겼고, 디지털 문서화된 중세 국어 문헌이 많지 않아서 얼마든지 기존에 보이지 않았던 조합이 생길 수 있다는 점도 고려해야 한다.[29]

참고로 저 1,638,750자를 빠짐없이 모두 나열한 곳이 존재한다(!). 혹시 전체 리스트가 필요하다면 저곳을 참고할 것. 로딩하다 브라우저 뻗는다 자신이 프로그래밍을 할 줄 안다면, 1,638,750자를 조합해 직접 출력해 볼 수 있다.

4.2.3. 옛한글과 유니코드 정규화의 부작용

유니코드에서 하나의 grapheme은 여러 가지 형태로 표현될 수 있다. 예를 들어 á는 한 코드 포인트짜리 U+00E1로도 표현될 수 있지만 a\́(a(U+0061)와 ◌́(U+0301)의 결합)으로도 표현될 수 있다. 이들을 어느 한쪽으로 통일시키는 게 유니코드 정규화이다.

유니코드 정규화 타입은 C, D, KC, KD가 있다. C와 KC에서는 글자들을 조합하며, D와 KD에서는 분리한다. 그래서 위에서 예로 든 á는 C와 KC에서는 U+00E1로 표현되고 D와 KD에서는 a(U+0061)와 ◌́(U+0301)로 분리된다. 한글 또한 C와 KC에서는 합쳐지고(예: 한 U+D55C) D와 KD에서는 분리된다(예: ᄒ\ᅡᆫ U+1112 U+1161 U+11AB).

그런데 옛한글의 경우 C와 KC에서 문제가 있다. 초성과 중성이 현대 한글이고 종성이 옛한글인 경우 초성과 중성은 완성자로 변환되고 옛한글 종성만 따로 남는 문제가 발생한다(예: ᄀ\ᅡᇫ → 가ᇫ U+AC00 U+11EB).

반면 한국 산업 표준 KS X 1026-1은 위와 같은 경우에 완성자를 사용하지 말고 자모들만 사용할 것을 요구한다(예: ᄀ\ᅡᇫ U+1100 U+1161 U+11EB).

미디어위키는 자동으로 유니코드 정규화 타입 C를 적용한다. 그래서 위키백과 등 미디어위키를 사용하는 곳에서는 위와 같이 초성과 중성은 완성자로 변환되고 옛한글 종성만 따로 남는 문제를 피하기 위해 초성과 중성 사이에 <nowiki></nowiki>를 삽입하거나(예: ᄀ<nowiki></nowiki>ᅡᇫ), 초성 또는 중성을 HTML numeric character reference로 표기한다(예: ᄀ&\#x1161;ᇫ). 다만 문서 제목에서는 이런 방법을 쓸 수 없기 때문에 문서 제목에서만은 초성과 중성이 완성자로 변환되고 종성만 따로 남는 걸 어쩔 수 없이 감수해야 한다.

나무위키는 유니코드 정규화를 자동으로 적용하지는 않으나, 어떤 웹 브라우저들은 문서 저장 시 정규화 타입 C를 적용하기도 한다. 그래서 이런 웹 브라우저로 옛한글이 들어간 문서를 편집하면 위와 같은 문제가 생길 수 있다. 나무위키에서는 초성과 중성 사이에 \\ 문자를 넣는 걸로 위 문제를 피할 수 있다(예: ᄀ\ᅡᇫ → ᄀ\\ᅡᇫ).

4.3. 유니코드와 한자

유니코드에서는 유니코드 한자들에 대한 정보를 담은 Unihan Database를 제공한다. 부수 + 나머지 획수, 국가·지역별 source, 한자 사전들에서의 위치, 창힐수입법 코드, 사각호마 코드, 기타 문자 집합들에서의 매핑, 언어별 독음, 한자의 영어 뜻, 이체자(간체자-번체자 포함) 정보 등을 수록하고 있다(예: U+5B57 字).

4.3.1. 한자 통합 기준

기본적으로 모양에 차이가 큰 것은 별도의 코드로 분리하고 모양에 차이가 작은 것은 한 코드에 통합한다. 예를 들어 學/学, 經/経/经와 같이 차이가 큰 것은 별도의 코드로 분리됐고, 아래 이미지의 次와 같이 차이가 작은 것은 한 코드에 통합됐다.
파일:attachment/CJK_variant_characters.png

다만 차이가 작더라도 土와 士, 日과 曰처럼 아예 다른 글자라면 통합하지 않고, 緒/緖, 淸/清과 같이 차이가 작아도 분리된 예외가 몇몇 존재한다.[30] 원칙적으로 者의 점의 유무와 靑/青의 차이는 인정하지 않고 통합된다.

중국어 간체자와 정체자는 유니코드에서 다른 글자로 본다(예: 紅(U+7D05)/红(U+7EA2), 語(U+8A9E)/语(U+8BED)). 간체자와 정체자를 한 코드에 통합할 수 없는 데에는 여러 가지 이유가 있다. 일단 간체자와 정체자가 언제나 일대일로 대응되는 게 아니고(发, 干 등만 해도 두세 글자를 하나로 합친 것이다), 중국 대륙에서도 번체자의 사용을 '금지'한 게 아니며, 일본어에서 간체자와 번체자와 같은 모양의 신자체와 구자체(예: 国-國 등)를 고유 명사 등에서 구별해서 쓰는 경우가 있기 때문이다.

그리고 유니코드에 간체자와 정체자가 반드시 동시에 추가되지는 않기 때문에, 간체자가 먼저 추가되고 나중에 그에 대응하는 정체자가 추가되거나 그 반대의 경우가 생기기도 한다. 예를 들어 간체자 䢂(U+4882)은 그에 대응하는 정체자 𨋢(U+282E2)보다 유니코드에 먼저 추가됐다.

구글이나 바이두 등의 검색 엔진에서는 간체자로 검색해도 간체자와 함께 정체자 검색 결과가 걸리고 정체자로 검색해도 정체자 함께 간체자 검색 결과가 걸리는데, 이는 검색 엔진 내부에 간체자와 정체자를 짝지어 놓은 테이블이 있기 때문에 가능한 것이다. 간체자와 정체자를 같은 글자로 인식하게 만드는 건 별도의 테이블 없이는 불가능하다.

구글이나 바이두 등에서도 유니코드에 나중에 추가된 간체자나 정체자는 같은 글자로 처리하지 못하기도 한다. 간체자-정체자 대응 테이블을 일일이 수동으로 업데이트해 줘야 하는데, 이게 상당히 번거롭기 때문에 보통은 업데이트를 안 한다.

4.3.2. CJK 통합 한자와 CJK 호환용 한자의 차이

유니코드에서 가장 많은 코드를 점유하고 있는 문자는 한자이고, CJK 통합 한자(Unified Ideographs)와 CJK 호환용 한자(Compatibility Ideographs) 블록을 채우고 있다. 일반적으로 쓰이는 것은 CJK 통합 한자 및 그 확장판들이며, 웬만하면 이 코드만 사용하는 것이 권장된다. 그러나 동아시아의 기존 국가 표준 인코딩에서는 동일한 한자에 중복된 코드가 할당돼 있는 경우가 있어서 이들을 CJK 호환용 한자에 수록하였다. 실수로 중복 배당된 문자(대만 Big5 코드에 중복 배당된 두 글자), 일부러 중복시킨 문자(대한민국 KS 코드[31], 일본의 IBM 확장 한자와 일부 JIS X 0213 한자[32]) 등이 CJK 호환용 한자에 들어갔다. CJK 호환용 한자는 기존 동아시아 문자 코드와 왕복 변환을 위해 마련되었다.

호환용 문자는 다른 코드 체계와의 왕복 변환이 필요하지 않을 경우 웬만하면 안 쓰는 게 깔끔하기 때문에, 일부 소프트웨어는 CJK 호환용 한자가 입력되면 자동으로 거기에 해당되는 CJK 통합 한자로 자동 변환되는 기능을 내장하기도 한다. 예를 들어 미디어위키는 CJK 호환용 한자를 CJK 통합 한자로 자동 변환시키기 때문에, 정 CJK 호환용 한자를 문서에 쓰려면 편집 화면에서 &#xF9E1;[33] 식으로 돌려 써야 한다.

4.3.3. 미묘한 이체자 처리 문제

현재 한자는 나라마다 표준이 다른데, 모양이 많이 다른 이체자[34]들은 각각 코드를 할당해 주고 있다. 예를 들어 '나라 국' 자의 경우 國과 国이 각각 다른 코드를 가진다.

유니코드의 한자 통일(Han Unification)의 기본 철학은, 한자를 X축(뜻), Y축(추상화된 형상), Z축(자형)의 기준에 따라 배열한 뒤, X축과 Y축이 각각 차이나는 글자만 유니코드에 다른 코드로 구분해서 싣고, Z축만 다른 한자는 하나로 통합하는 것이다. 예를 들어 國과 国은 X축(뜻: 나라)이 동일하지만 Y축(추상화된 형상)이 다르므로 다른 코드에 할당되었다. 반면 納󠄁(糸+内)와 納(糸+內)은 X축(뜻), Y축(추상화된 형상) 모두 일치하고 Z축(자형)만 약간 차이를 보이므로 같은 코드에 통합되었다.

문제는 모양이 크게 다르지 않은 이체자를 이체자로 인정할까 말까 하는 것인데, 이 중에 일부는 그냥 한 코드로 합병한 경우가 많다. 예를 들어 '평평할 평(平)' 자의 경우 干에다 ㇒㇔를 덧붙인 듯한 자형도 있고, 干에다 ㇔㇒를 덧붙인 듯한 자형도 있는데, 둘 다 U+5E73으로 하되 구체적인 형태는 폰트에 따라 구분하게 하고 있다.[35] 그러나 이런 식으로 차이가 크지 않은 이체자들을 한 코드로 합병하여 CJK 통합 한자에 추가한 글자 중에는, 그 글자에 대응되는 일부 이체자를 위해 CJK 호환용 한자에 중복 추가한 경우도 있다(주로, 일본 문자코드 내에 등록된, 자형이 비슷한 이체자와의 왕복 변환을 위해 할당됨). 예를 들어 '바다 해' 자의 경우 CJK 통합 한자에 海(U+6D77)가 등록돼 있는데, 이 글자의 마지막 구성요소가 母(어미 모) 형태로 렌더링돼도 되고(한국어, 중국어 정체· 간체, 일본 구자체) 毋(말 무) 형태로 렌더링돼도 된다(일본 신자체). 그래서 Windows에서 한국어·중국어(정체/간체) 입력기로 바다 해를 입력하든 일본어(신자체) 입력기로 바다 해를 입력하든 유니코드의 海(U+6D77)에 해당되는 문자가 입력되며 글자 형태는 폰트에 따라 결정되므로, 언어별 폰트를 적절히 지정해 줘야 해당 언어에 적절한 한자체로 표시된다. 반면에 CJK 호환용 한자에 추가된 海(U+FA45)는 해당 부분이 반드시 母(어미 모)의 형태로 렌더링돼야 한다. CJK 호환용 한자의 海(U+FA45)는 본래 일본 문자 코드에서 구자체를 정확히 렌더링할 때를 위해 추가된 '바다 해' 자와 연동돼 있는 듯한데, 꼭 필요한 경우가 아니라면 사용하지 않는 게 좋을 듯하다.

결국 언어마다 선호하는 한자의 형태가 조금씩 다르기 때문에, 번거롭더라도 각 언어에 맞는 폰트 지정까지 해줘야 적합한 렌더링을 보장할 수 있을 것이다. 그런데 이렇게 폰트를 통해 이체자 처리를 할 경우 폰트 지정이 곤란한 텍스트 문서에서는 구분이 불가능한 문제가 생긴다. 특히 일본의 경우 호적 전산화 등에서 이체자 처리를 정밀하게 하고 있어서 폰트를 지정하지 않고 문자 코드만 사용하여 이체자를 정확히 변별할 수 있는 기술에 대한 수요[36]가 있다. 그래서 유니코드에서도 뒤늦게 이에 대응되는 기술의 필요성이 대두되어 현재 유니코드 내에 이체자 선택자(Ideographic Variation Selector, IVS)[37]라는 특수 문자 코드를 덧붙이는 방법도 도입돼 있고, 계속 구체적인 표준을 정하기 위해 작업 중인 듯하다. 이 방식은 한자용 문자와 IVS(화면상에 개별 문자로 표시되진 않음)를 연달아 입력하면 화면에 의도한 한자 한 글자가 지정한 이체자대로 표시되게 하는 식이다. 코드 상으로는 문자를 2개 입력했지만 실제 화면에는 1글자로 보이는 식.[38]

그러나 아직은 많은 소프트웨어·폰트들이 IVS에 대응되지 못하고 있는 상황인 데다가 IVS를 이용한 이체자 처리 규격 자체도 불완전한 상태이다. IVS 출력이 확실한 경우라면 상관 없겠지만, IVS 지원이 미흡한 기종에서도 열어볼 가능성이 큰 문서를 작성할 경우 이 방식의 사용을 지양하는 게 좋을 듯하다. 정 이체자를 정확히 표기해야 한다면 IVS 없이 해당 국가용으로 제작된 폰트로 지정해 준다든가, 그것도 정상 작동을 보장할 수 없을 것 같으면 이미지 파일을 동원하는 게 좋을 듯하다. 참고로 현재까지 유니코드에 포섭된 IVS를 대부분 지원하는 폰트들은 여기(일본어)를 참고할 것.[39]

이런 이체자들을 정리하는 사이트들도 있는데 그중 하나가 글리프위키(일본어)라는 사이트다.[40] 일본어로 된 사이트이지만 한국어를 비롯한 다른 언어로 된 안내문들이 만들어져 있고( 예) 회원 가입 시 옵션에서 일본어 외 다른 언어로 시스템 메시지를 바꿀 순 있다(현재 한국어 지원 중).

아무튼 유니코드에서 미세한 이체자를 무신경하게 한데 통합하는 바람에 문제가 많다. IVS는 나중에 땜질 처방으로 도입된 것이고... 그래서 (주로 일본에서) 유니코드가 전통 문화를 파괴한다고 비난하는 유니코드 안티가 꽤 있었다.

이렇게 된 이유는 유니코드 표준화 초창기에는 2바이트 고정 코드, 즉 65535자만으로 세계의 모든 문자를 표현하려고 했기 때문이다. 당시의 표준 논의[41]에서는 넉넉하게 4바이트를 사용해서 한국 KS코드 한자, 일본 JIS코드 한자, 중국 GB 코드 한자 등등을 전부 별개로 보고 배열하자는 의견도 있었다. 그러나 이렇게 했다간 한 일(一)처럼 누가 봐도 똑같이 생긴 한자도 3개씩 중복 할당되므로 너무 비효율적이라는 반론이 나왔다. 또 이 시기는 80년대 후반~ 90년대 초반이었는데, 당시의 컴퓨터 성능을 고려했을 때 한 글자를 나타내는 데 4바이트를 사용하는 것은 부담스럽다는 것이 중론이었다. 이 때문에 최종적으로 유니코드 1.0에서는 글자당 고정 2바이트를 쓰는 것으로 결론이 났고, 65535자 안에 한자 외에 다른 언어의 문자도 넣어야 되는데다 향후 버전을 위해 어느 정도 공간을 비워놔야 했기 때문에, 비슷한 모양의 글리프는 하나의 코드에 합치는 식으로 적당히 타협할 수밖에 없었던 것이다.

일본의 좀 극단적인 수요에 대응한 초한자(超漢字) OS[42]의 TRON코드에는 한자가 17만 자씩 수록되어 있는데, 이는 한, 중, 일의 국가 표준 코드와 대한화사전(大漢和辭典), GT 서체 등의 글리프를 전부 별개로 보고 각각 다른 구역에 중복으로 배당했기 때문이다. 전반적으로 유니코드 한자 통합 정책의 안티테제적 제품이라고 하겠다. 하지만 이런 독자 표준 소프트웨어로는 현대의 거의 모든 시스템에서 구현하고 있는 세계 표준인 유니코드의 편의성을 따라오지 못했고, 2바이트라는 고집을 버린 유니코드의 한자 이체자 커버리지 확대[43]와 IVS의 도입 등을 통해 웬만해서는 유니코드로 해결을 볼 수 있게 된 2010년대 이후에는 이 극단적인 수요마저도 크게 줄었다.

4.4. 문자 비할당 영역

문자가 할당되지 않은 영역 중 어떤 이유로 문자가 할당되지 않는 영역이 있다. 대부분은 예약된(Reserved) 영역이거나 단순한 미할당(Unallocated) 영역이라 장래에 문자가 할당될 여지가 있지만, 아예 영구적으로 문자가 할당되지 않을 영역도 있다. 쉽게 말해서 유니코드판 영구 결번이다.

비문자(Noncharacter)는 말 그대로 '문자가 아닌 것'으로, 문자로 사용되지 않는 영역이다. 우선 각 평면의 마지막 2개 포인트(U+xxFFFE, U+xxFFFF)가 비문자 영역으로 지정되어 있으며, 기본 다국어 평면의 U+FDDx 및 U+FDEx도 비문자 영역으로 지정되어 있다. 도합 66개 포인트(각 평면당 2개씩 34개, U+FDD0-U+FDEF 32개)가 비문자 영역이다.

비문자의 존재 의의는 절대로 문자가 할당되지 않는 영역인 만큼 소프트웨어 차원에서 이 점을 활용하여 내부적으로 자유롭게 사용할 수 있다는 데 있다. 특히 유용한 예로, 바이트 순서 표식의 코드 포인트가 U+FEFF인데 이 바이트 순서를 뒤집으면 비문자인 U+FFFE가 되므로 맨 앞의 두 바이트가 FF FE이면 리틀 엔디언(역방향)이고 FE FF이면 빅 엔디언(순방향)임을 알 수 있는 것이다.

비문자는 아니지만 U+D800-U+DFFF 범위의 코드포인트 2,048개도 문자 비할당 영역으로 지정되어 있는데, 이유는 UTF-16 인코딩에서 확장 평면에 속하는 문자들을 표현하기 위해 예약된 포인트이기 때문이다. 이 범위에 속하는 영역을 대체 영역(Surrogate)이라고 부른다.

5. 인코딩

유니코드와 유니코드 인코딩을 가장 쉽게 설명하는 방법은 유니코드는 각 글자에 숫자를 배당하는 방식, 규격이고 인코딩은 유니코드 숫자를 저장하는 방식, 표현이라고 보면 된다. 유니코드는 문자 하나를 4바이트(32비트) 테이블에 배당한다. 하지만 이걸 그대로 사용할 경우 (가장 사용 비중이 높은) 로마자(혹은 프로그래밍, URL 등의 통신 포함) 입장에서는 기존의 ASCII에 비해 용량이 4배가 되어 엄청나게 비효율적이 된다.

이 점을 보완하기 위한 것이 가변 길이 문자 인코딩으로, 자주 쓰이는 문자 테이블을 1바이트(UTF-8) 또는 2바이트(UTF-16)으로 표현할 수 있는 대신 자주 쓰이지 않는 문자 테이블을 표현하는 데는 더 많은 바이트가 필요해진다. 대표적으로 UTF-8에서 한글을 표현하는데는 3바이트가 필요하며, 6바이트가 필요한 테이블도 있다.(호환성 문제로 현재는 4바이트까지만 사용) UTF-8 같은 경우 ASCII와 호환된다는 특성도 있다. 흔히 우리가 웹 브라우저의 인코딩을 설정하면서 자주 보는 UTF-8이라는 말이 이것이다.

예를 들어 A(65)를 보자. A라는 글자를 숫자 65에 배당하는 것(65를 읽으면 A라고 표현하라는 것)이 유니코드의 개념이다. 이 65라는 숫자를 2진수로 저장할 때, 8자릿수로 표현해서 0100 0001 이라고 쓰거나, 혹은 규모를 키우기 위해 16자릿수로 표현해서 0000 0000 0100 0001 이라고 쓰거나, 혹은 구버전 호환성을 높이거나 처리 속도를 빠르게 하기 위해 0001 0100 (8자리)와 0001 0100 0000 0000 (16자리) 처럼 거꾸로 쓰거나, 헷갈리지 말라고 110(+2) 0100 0001, 11110(+4) 0000 0000 0100 0001처럼 가변 정보를 넣어 쓰는 등, 이런 논리와 방식을 결정하는 것이 인코딩의 종류다.

참고로 유니코드의 인코딩 방식 종류로는 위에서 언급된 것을 포함하여 대략 다음과 같은 것들이 있다.
UTF-7, UTF-8, UTF-16, UTF-32, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE

많은 서적이나 자료에서 유니코드를 두고 아직까지 '2바이트 인코딩'이라는 표현을 사용하고 있는데, 유니코드 2.0 (1996년 발표)부터는 맞지 않는 말이다. 현대의 유니코드 표준에는 여러 인코딩 체계가 정의되어 있으며, 과거 유니코드 1.x 시절의 UCS-2를 제외하고는 고정 2바이트 인코딩이라고 할 수 있는 것은 없다. 게다가 유니코드에 할당된 문자의 수가 이미 (2바이트로 표현할 수 있는 최대 수치인) 65,535개를 넘어선 지 오래되었기 때문에....

5.1. UTF-8

전문적 지식을 요하지 않는 분야에서 그냥 유니코드라고 했을 때는 십중팔구 이 인코딩이라 생각하면 될 정도로 표준적인, 호환성이 가장 좋은 인코딩이다. 자세한 사항은 문서 참조.

5.2. UTF-16

코드 페이지 1200. UTF-8과 마찬가지로 가변 길이 인코딩이다. 일반적인 이용에서 U+10000부터의 문자를 접할 일이 별로 없어서 대부분 2바이트로 표시할 수 있기 때문에 고정 길이라는 인식이 퍼져 있을 뿐. U+10000 및 이후의 문자는 값에서 U+10000을 뺀 후 문잣값을 10비트씩 쪼갠 후 각각 U+D800, U+DC00의 하위 10비트에 끼워 넣는 식으로 총 4바이트로 표현한다. 코드 중간에 '상위/하위 대체 영역'이라는 문자가 정의되지 않은 부분이 있는 것이 이를 위한 것이다. 이 방법을 이용하면 U+10000부터 U+10FFFF까지 4바이트를 이용하여 표현할 수 있다. 유니코드 평면 수를 0번부터 16번까지 17개로 정의한 이유도 UTF-16에서의 표현 가능 범위를 고려한 것이다.

예를 들어, 높은음자리표(𝄞) 문자를 UTF-16으로 표현한다고 하면 다음과 같이 된다. 이 결과에 의하면 높은음자리표(U+1D11E)는 UTF-16에서 D8 34 DD 1E로 인코딩됨을 알 수 있다.

또한 기본적으로 2바이트의 순서가 정해진 것이 아니기에 시스템에 따라 BOM이 앞에 붙는다. 바이트 순서가 순차적인 것은 빅 엔디안, 역순인 것은 리틀 엔디안이라고 하며, 걸리버 여행기에서 소인국 사람들이 계란을 어느 쪽으로 깨 먹는가라는 주제로 전쟁(...)을 벌인 내용에서 착안했다.

바이트의 순서가 정해진 것이 아니라는 점은 이 인코딩에서 문제를 초래하는데, 빅 엔디안을 사용하는 대부분의 시스템은 아예 BOM을 붙이지 않고, 리틀 엔디안을 사용하는 시스템은 이런 문서를 기본적으로 리틀 엔디안으로 읽는다. 반대로 리틀 엔디안을 사용하는 시스템은 항상 BOM을 붙이는데, 빅 엔디안만 사용하는 대부분의 시스템은 앞의 BOM을 BOM으로 인식하지 않고 문자로 읽어들여서 에러를 낼 가능성이 높다.[44] 이런 이유로 인터넷에서 정보 교환용으로 UTF-16이나 UCS-2 등 16비트 기반 인코딩은 사용하지 말라는 권고를 쉽게 접할 수 있다.

PHP가 버전 6에서 UTF-16을 사용하려고 하다가 개발에 난항을 겪고 취소되었다. 이미 웹 환경이 UTF-8이 대세가 된 것이 주 원인. 결국 PHP 6은 취소되고 2012년 3월 PHP 5.4에 가서야 UTF-8을 사용하게 된다. Java와 .NET Framework는 UTF-16을 기본으로 사용한다. char 타입은 기본적으로 2바이트를 쓰기 때문에 이모지처럼 4바이트를 사용해야 하는 문자의 경우 배열로, 즉 char[2] thinking = "🤔";처럼 써야 한다.[45]

UTF-16의 가장 큰 의의는 UCS-2와의 하위 호환성이다. UCS-2는 원래 2바이트(65536개) 이상의 코드포인트가 필요하지 않다는 전제하에 설계된 인코딩이나 이후 확장 과정에서 이는 현실적이지 않은 가정임이 드러나 이후 4바이트 기반의 UCS-4와 가변 길이 인코딩인 UTF-8이 도입되었다. 하지만 이는 UCS-4의 지나친 대역폭/저장 공간 낭비의 문제와 더불어 아래에서 일부 플랫폼이 이미 UCS-2를 기본 인코딩으로 사용함으로 인해 하위 호환성을 깨지 않으면서 인코딩을 변경하는게 현실적으로 불가능해졌기에 2바이트 기반의 가변 길이 인코딩의 필요성이 제기되었고, 그 결과 UTF-16이 나온 것이다.

Microsoft Windows의 커널 내부에서 사용하는 인코딩도 UTF-16(리틀 엔디안)이다.[46] 그러나, 안타깝게도 예전 운영체제와의 호환성을 위해 커널을 제외한 사용자 영역에서는 아직도 MBCS가 기본값으로 쓰이고 있다. 윈도우의 경우 가장 빠르게 유니코드를 채택한 운영 체제 중 하나인데, 해당 시점에는 UTF-8를 비롯한 가변 길이 인코딩 표준이 존재하지 않았기 때문에 UCS-2를 채택했던 것. 아이러니하게도 너무나도 빠른 얼리 어답터였기 때문에 이후 대세가 된 UTF-8로 넘어가지 못하고 하위 호환이 되는 UTF-16를 기본 인코딩으로 사용하는 상황이다. 마찬가지로 얼리어답터였던 자바 역시 비슷한 역사를 가지고 있다.

5.3. UCS-2

UCS는 Unicode 이전에 사용된 국제 인코딩 규격으로 International Standard ISO/IEC 10646에 정의되어 있다. UCS-2는 UTF-16에 대응되는 규격으로 U+FFFF까지는 UTF-16과 동일하나, 가변길이 부호화를 지원하지 않으므로 U+10000 이후의 문자열을 사용할 수 없다.

전송을 위한 문서들의 경우 UTF-8을 사용하지만 프로그램 내에서 사용하는 코드로는 UCS-2(혹은 UTF-16이라고는 부르나 U+FFFF까지만 사용하니 사실상 UCS-2라고 봐도 좋은)를 사용하는 경우도 많은데, 이는 가변 길이 부호화를 지원하지 않기 때문에 array상에서 인덱스 = 해당 문자로 바로 접근이 가능해 그런 식으로 사용해야 하는 코드에 유리하기 때문이다. 따라서 UTF-8로 전송받은 문서를 UCS-2로 변환해 저장해 사용하는 방식 등을 사용한다.

5.4. UTF-32

유니코드 문자 하나에 32비트를 이용하는 고정 길이 인코딩이다. 인터넷에서 정보 교환용으로는 거의, 아니 사실상 전혀 이용되지 않는데 이는 낭비되는 용량이 너무 크기 때문이다. 유니코드 문자가 U+10FFFF까지 있으므로 총 21비트를 이용하는데, 이는 32비트 중 11비트는 전혀 쓰일 일이 없다는 것이다. 그나마도 현재 이용되는 대부분의 문자가 U+FFFF 아래에 있으므로 16비트로도 거의 충분하므로 실제 낭비는 더 크다. 라틴 문자나 유럽 문자를 주로 쓴다면 대부분 1바이트, 길어야 2바이트로도 충분한 걸 4바이트씩이나 쓰므로 거의 3/4이 낭비되는 셈이다. 또한 실제로 데이터가 저장될 때는 문자들의 위치가 32비트 단위로 딱딱 정렬되지 않는 경우가 많기 때문에[47] 처리 속도가 그리 빨라지지도 않는다. 게다가 HTML5에서는 UTF-16과의 구별에 문제가 생길 수 있다는 이유로 쓰지 말 것을 권고받는 굴욕도 받고 있다.

하지만 프로그램 내부적으로는 UTF-32가 자주 이용되는데, 이는 UTF-32에서는 가변 길이 부호화를 고려할 필요가 없어서 처리가 간단해지고, 현재의 컴퓨터 환경에서는 가장 기본적인 데이터 크기가 32비트이기 때문에 8비트나 16비트를 이용하는 것에 비해 성능 저하가 없으며 메모리 용량도 충분하기 때문이다. 예를 들어 Python 3.3 이상에서 내부적으로 UTF-32를 이용한다. 위의 UTF-16이 사용되는 것과 비슷한 논리.

UTF-32의 경우 고정 길이이기 때문에 U+FFFFFFFF까지 [math(2^{32})] = 약 43억 개의 문자를 인코딩하는 것이 가능하다. 이는 U+7FFFFFFF까지 약 21억 개([math(2^{31})])의 문자를 인코딩 가능한 UTF-8의 두 배이다. 만에 하나 미래에 인류가 43억 개의 문자 이상의 코드를 부여해야 하는 사태가 발생하면 UTF-32로 표현 불가능한 문자들이 생겨나게 되는데, 이는 당분간은 상당한 미래 이야기일 것이다. 글자의 개수가 점점 줄어들고 있는 시대에 미래에도 필요할지 의문일 수도 있으나 실제론 늘어나고 있다. 현재 쓰이지 않는 고대의 모든 문자들도 유니코드의 일부로 포섭하고 있기 때문이다.

6. 유니코드 정규화

Unicode Normalize 공식 페이지

같은 모양의 글자를 서로 다른 코드로 표현이 가능할 때, 유일한 코드로 '정규화'하여 이용하는 것. 대표적으로, 정규화 되지 않고 섞여서 쓰게 되면 정렬 순서가 꼬이고, 검색이 안 되는 상황이 발생한다.

7. 변종 문자(위 첨자·아래 첨자·작은 대문자 등) 사용 시 권장 사항

유니코드 콘소시엄에서는 수학 식의 경우 본래 문자를 사용하여 HTML이나 XML 등에서 제공하는 마크업 문법으로 표현하고, 국제음성기호(IPA) 같은 음성· 음운 기호의 경우 유니코드에 실린 변종 문자를 사용하는 게 낫다고 권고하고 있다. 절대적인 건 아니지만 권고를 따르는 게 유리하다.

예를 들어 수학식의 경우 2의 제곱은 2² 식으로 유니코드 내 위 첨자 ²를 쓰기보다는 그냥 본래의 문자 2만 사용하여 마크업 문법을 활용해 [math(2^2)] 식으로 표현하는 쪽 혹은 ^기호를(2^2) 사용하여 표현하는 쪽이 낫다. 이게 유리한 이유는 [math({2^2}^2)] 식으로 무한히 제곱을 올려 쓰는 경우 등 다양한 사용 방식이 있기 때문에 유니코드 내 위 첨자 ²를 안 쓰는 게 대부분의 경우 편리하다. 하지만 음성·음운 기호의 경우 [pʰ]처럼 유니코드 내 위 첨자(ʰ 등)를 쓰는 게 낫다. 음성·음운 기호는 수학식처럼 첨자를 계속 올려 쓰는 경우가 없으니 이쪽이 편리하다.

8. 유니코드 지원 폰트

유니코드를 바탕으로 각종 문자들을 지원하는 폰트에 대한 정보는 백괴사전의 윤희코드 특수문자 도움말에 상세하게 기록되어 있으니 관심 있는 사람들은 찾아 보기 바란다. 백괴사전에서 백괴사전:, 도움말:로 시작하는 문서는 각종 드립이 생략된 순수 정보 제공 문서다.

9. 키보드에 없는 문자 입력하기

키보드에 없는 유니코드 문자를 입력하는 다양한 방법이 있다. 잘 알아두면 유니코드 문자를 입력하지 못해 籾 대신 '米+刃', 畠 대신 '白 밑에 田', 栃 대신 '又 아닌 万이 들어간 板'같이 표현하는 안쓰러운 일을 피할 수 있다.[53] 참고로 macOS 일본어 입력기에선 이런 상황을 의식해 한자의 구성 성분을 별개로 입력한 후 해당 한자가 포함된 한자를 찾는 한자사전식 한자 변환도 가능하다. 栃나 杤을 입력하고자 하는 경우, 木万를 입력한 후 해당 2개 문자를 선택, Control + 2를 누르면 변환 리스트가 표시된다. 2문자뿐 아니라 3글자 이상도 지원하며, 糸口木로 입력해서 繰 같은 경우도 변환이 가능하다.

10. 관련 문서

10.1. 개별 문서가 있는 유니코드 특수 문자


[1] 참고서나 서적 등에서 유니코드를 '2바이트 문자 체계'라고 소개하고 있다면, 내용이 20년 넘게 업데이트되지 않았다는 것이다. 최신 버전의 유니코드에는 한자만 해도 9만 7천 자 이상이 수록돼 있다. [2] 여담으로 넣을 계획 없는 문자로 넣은 예시 중에 클링온어, 신대문자가 있다. # [3] 타밀 문자 보충, 롱고롱고 등이 있다. 그러나 그중에는 앞뒷면에 ¿?이 있는데 그것은 아직 추가할지 고민 중인 문자이다. 그냥 ???로 되어 있는 부분은 아직 어떤 문자를 추가할지 계획이 잡혀 있지 않은 부분이다. [4] 주로 네 자리로 표기한다. [5] 아스키 코드와 완벽히 호환되기 때문에 영미권 사용자는 일찌감치 UTF-8로 갈아탔다. [6] 옛한글이 포함된 조합형. [M] 필리핀 민도로섬의 망얀(Mangyan)족의 언어를 표기하기 위한 문자. [M] [9] 팔라완 원주민들이 쓰는 문자. [10] 윈난성 남부의 타이누아(Tai nua)족의 문자. [11] 태국 서남부 지역어를 표기하기 위한 문자. [12] 시킴 일대의 렙차인의 문자. [13] 시에라리온의 바이인들이 쓰는 문자. [14] 말 그대로, 글꼴 제작자의 입맛에 따라 어떤 글자를 넣어도 터치를 안 하는 영역이다. 그래서 이 부분은 보통 비어 있다. [15] 아랍 문자의 isolated, initial, medial, final form들이 들어 있는 영역이지만, 이 영역의 마지막 문자는 다름 아닌 BOM. 생뚱맞게 Specials가 아니라 이 영역에 할당되었다. [16] 일반적인 플레잉 카드 외에 게임용 타로 카드(타로 누보)의 트럼프(메이저 아르카나) 21장, 그리고 궁정 카드의 기사 카드 4장 등을 더 포함한다. [17] 1번 평면에 아직 계획되지 않은 영역들이 남아있어서, 남은 영역에 대한 할당 계획이 잡히고 나면 비로소 4번 평면에 대한 논의가 이루어질 것으로 보인다. [18] 한글은 조합형 문자기 때문에, 완성된 단어 이전의 모든 글자를 포함해야 한다. 가령 '안녕'이라는 글자를 타자로 친다고 해도 ㅇ-아-안,ㄴ-녀-녕 의 6자를 쓰게 되는데, 이 과정에서 중간에 포함되지 않은 글자가 있다면 꼼수를 써서 그림을 그리든가, 아니면 문자 표에서 복사하거나 해당 글자를 치는 것을 포기해야 한다. 이러한 글자의 대표적인 예시로는 '쓩'이 있다. [19] 한글의 특성상 자모 하나가 추가되면 조합 가능한 글자 수는 배로 늘어난다. 유니코드에 할당 가능한 문자의 수는 1,117,111개인데 옛한글 완성자의 수는 1,638,750개다. [20] 당시 완성형을 비판하기 위해 주로 거론된 매체는 드라마 똠방각하였고, 흔히 "똠방각하 전홥니다" 라는 문장으로 표현했다. 좀 더 나가면 "찦차를 타고 온 펲시맨과 쑛다리 똠방각하" 같은 문장도 있었지만 이건 완성형을 까기 위해 만든 문장이라는 티가 너무 나서 한컴의 아래아한글 광고 멘트인 "비행기가 날아갑니다. 쓩~" 을 사용하는 경우도 있었다. 어쨌건 자세한 사항은 조합형 완성형 논쟁 항목 참고. [21] 기존 2,350자를 그대로 두고 다른 위치에 한글을 더 추가했기 때문에 CP949의 경우와 마찬가지로 코드로는 가나다순 정렬을 할 수 없는 문제가 있었다. [22] 출처: 단일문자 표준 연구, 한국전산원, 1993년 6월. [23] 참고로 현재 이 부분에는 한자와 주역 64괘 (Yijing Hexagram Symbols)가 들어 있다. [24] 대한민국은 광복 이전부터 쓰던 것을 그대로 쓰고 있지만, 북한은 자체적으로 순서를 새로 짰다. 굳이 정통을 따지자면 대한민국이 정통인 셈. 북한 문화어의 한글 정렬 순서는 정렬/순서 문서의 '북한 문화어' 부분을 참고할 것. [25] U+115F, 한글 초성 채움 문자(HANGUL CHOSEONG FILLER). [26] U+1160, 한글 중성 채움 문자(HANGUL JUNGSEONG FILLER). [27] 종성 채움 문자는 없다. 종성이 없는 경우 그냥 아무것도 넣지 않는다. [28] 실제로 중성과 종성만으로 이뤄진 글자도 문헌에 있으며 《논어언해(論語諺解)》의 "君子(군ᄌᆞ)ᅟᅵᆫ디라(> 군자인지라)"를 예시로 들 수 있다. 명사 '君子(군ᄌᆞ > 군자)' 뒤에 '서술격 조사 '이-'가 붙고, 거기에 '-ㄴ디라(> -ㄴ지라)'가 결합하여 활용되었는데, 이때 '君子(군ᄌᆞ)'가 단모음 '이[ㅣ\]'나 반모음 'ㅣ[j\]' 외의 모음인 'ᄋᆞ[ㆍ\]'로 끝났으므로 '이-'[ㅣ\]의 이형태인 딴이 'ㅣ-'[j\]를 쓴 것이다. 또한 앞 체언이 고유어였다면 '나 + ㅣ라 → 내라'와 같이 합용(ㅏ + ㅣ → ㅐ)하여 썼을 것이나, '君子(군ᄌᆞ)'는 한자어인지라 '군ᄌᆞ(군ᄌᆞ) + ᅟᅵᆫ디라 → 군ᄌᆡᆫ디라'와 같이 합용하지 않고 '君子ᅟᅵᆫ디라'와 같이 쓴 것. [29] 조선 시대의 공식 문서는 한자를 사용한 관계로 한글 문서는 대부분 왕족과 양반 가문, 상민 계층이 사적으로 남긴 기록이다. 그런데 이것이 국가가 관리하는 문화재가 아니고 등록 의무가 없다보니 공식 집계에 오르지 않은 자료가 부지기수로 많고 지금도 더러는 밀유통, 망실되기도 한다. 그나마 옛한글 중에서도 유난히 드물다 싶은 조합들은 " 이게 말이 되냐"식으로 인용한 글자가 많다. [30] 사실 이런 게 생각보다 많다. 분명히 똑같은 차이인데 어떤 경우에는 통합돼 있고(朗) 어떤 경우에는 분리돼 있다(郎/郞). 그래서 뭐가 통합돼 있고 뭐가 분리돼 있는지 일일이 외울 자신이 없다면 그냥 해당 언어 입력기로 치는 게 속 편하다. [31] 자주 쓰이는 한자가 음이 여러 개 있을 경우 발음에 따라 한자를 중복 할당 했다( 완성형/중복 한자 참고). 유니코드에서는 중복된 글자들 중 하나만 대표로 CJK 통합 한자에 대응시키고, 나머지는 CJK 호환용 한자에 대응시켰다. [32] 획에 미세한 차이만 있는 이체자 몇 가지를 중복 수록했는데, 그 중에 너무 미세한 차이만 있는 경우 또는 이미 통합 한자에서 통합된 글자는 유니코드에서 CJK 호환용 한자에 대응시켰다. [33] 이런 표기를 numeric character reference라고 부른다. [34] 훈·음은 같지만 형태가 다른 한자. [35] 이렇게 비슷하게 생긴 문자를 같은 코드로 병합하고 폰트에 따라 알아서 만들게 하는 경우는 한자 외에도 있다. 예를 들어 말 줄임표로 쓰는 점 세 개(…, U+2026)의 경우, 동아시아 언어용으로 제작된 폰트들은 거의 다 가운뎃점(·)이 세 개가 연달아 있는 형태로 렌더링되지만, 서양 언어용으로 제작된 폰트에서는 그냥 점(.) 세 개가 연달아 있는 형태로 렌더링되는 경우가 많다. [36] 국가 표준은 아니지만 일본 일각에서 쓰이고 있는 몇몇 문자 코드 체계(예를 들면 TRON 코드 #나 금석문자경 # 등)들은 유니코드에서 다른 코드로 할당하지 않는 미세한 이체자들을 별도의 문자 코드로 할당한다. 일본은 한자로 된 고유 명사에 대해 특정 형태의 이체자를 쓰고 고유 명사의 주체가 다른 이들에게 자신이 정한 이체자대로 표기해 달라고 하는 경우가 많다. 그래서 일본에서는 이체자의 세밀한 전산화에 대한 수요가 어느 정도 있고 관련 제품들도 거의 일본제가 많다. 심지어 TRON 코드를 채용한 초한자(超漢字)라는 독자적인 운영 체제도 있다. 다만 현실적으로 호스트 OS로 깔아 놓고 쓰는 사람이 드물어서인지 최신판인 초한자 V(로마 숫자 5)부터는 Windows용 VMware Player(또는 VMware Workstation) 위에서 돌아가는 가상화를 전제로 한 운영 체제로 개발되었다. [37] 유니코드 컨소시엄의 설명(영어), 일본어 위키백과의 설명. 확실히 이체자 전산화에 일본인들의 관심이 지대하다는 점이 위키백과에서도 확인된다. 2008년에 일본어판에서는 위키백과 내에서 처음으로 IVS에 대한 독립적인 위키백과 문서를 신설했다. 그리고 2014년 11월 현재 일본어판 위키백과의 IVS 문서는 내용이 매우 상세한 상태인데 다른 언어판으로는 독립적인 IVS 문서가 아예 없는 상황이다. 일본어판 혼자 IVS 문서가 있으면서 내용이 상세하기까지 하니 이 부분에 대한 일본인들의 관심이 얼마나 큰지 짐작할 수 있다. [38] 이렇게 여러 문자를 한데 조합해서 출력해 주는 방식은 한자 외의 문자에도 여럿 있다. 옛한글이나 보조 부호가 붙은 로마자, 그리스 문자, 키릴 문자 등을 종종 이런 방식으로 입력하기도 한다. [39] 저 리스트에 있는 글꼴들은 대부분 한글 지원이 안 되는 폰트들이지만, 본고딕의 경우 한글과 IVS를 동시에 지원하니 참고하자. 다만 본고딕은 모든 유니코드 한자를 표기하지 못하며, 저 리스트에 있는 글꼴 중에 하나조노 명조(花園フォント)가 모든 유니코드 한자를 지원하기로 유명하다. 하나조노 명조에 대한 자세한 내용은 한자 문서 참고. [40] 각 이체자(글리프)마다 문서를 만드는데 문서 제목은 유니코드의 고유 코드를 기준으로 한다. 하지만 아직 유니코드에 수록되지 않은 자형들도 한데 정리한다. 참고로 이 사이트는 미디어위키를 수정한 엔진을 사용하는 위키위키 사이트다. [41] 정확히는 ISO의 폐기된 표준 초안(draft)인 ISO/IEC DIS 10646:1990 (통칭 DIS-1). 이 당시만 하더라도 ISO와 유니코드가 각각 별개의 표준을 만들고 있었으나, 1991년에 ISO와 유니코드가 서로의 목적이 같으니 표준을 통일하기로 합의하였다. [42] 일본에서 독자적으로 개발한 RTOS 스펙인 B-TRON의 상용 구현체이자 한자 입출력 전용 운영 체제. [43] 1996년의 유니코드 2.0에서는 한자가 21,204자였으나 2023년의 유니코드 15.1에서는 한자가 97,680자로 늘어났다. [44] 일이 이렇게 된 것은 컴퓨터 환경이 8비트에서 16비트로 넘어갈 때, 일부 제조사는 기존 8비트와의 호환성 향상을 목적으로 16비트(2바이트) 데이터의 뒤쪽 바이트를 앞 바이트보다 빠른 주소에 넣도록 시스템을 구성(이것을 리틀 엔디안이라고 함)했기 때문이다. 참고로 이렇게 만들어진 가장 대표적인 시스템이 x86이다. [45] 반대로 1바이트 자료형이 필요한 경우에는 byte를 쓰면 된다. [46] Windows 2000 이전까지는 UCS-2였다. [47] 문자가 4바이트(32비트)를 차지하므로 파일에서 각 문자가 0, 4, 8, 12, 16...같이 4의 배수로 배열되면 좋겠지만 실제로는 0, 6, 10, 14, 18...같은 식으로 4의 배수 형태가 아닌 경우가 생길 수 있다. [48] NF는 Normalization form(정규화 형식)의 약자이며 C는 Composition의 약자이다. [49] D는 Decomposition의 약자이다. [50] 한글 첫가끝 코드이다. [51] 멀리 가지 않아도 대부분의 언어에서 문자열 리터럴 이스케이프로(\\uXXXX식) 입력할 수 있다. [52] 그중 안드로이드의 unicode pad가 모든 문자를 가지고 있고 사용방법도 알려줘서 좋다. [53] 연합뉴스 홈페이지 등에서는 유니코드를 지원하는데도 한자 표기를 원칙적으로 한국에서만 쓰는 한자로 표기하고 있다. 유니코드를 쓰면 다른 한자 사용국의 한자도 표기할 수 있는데도 굳이 한자를 억지로 파자해 놓았는데, 연합뉴스가 통신사로서 뉴스를 판매하는 대상이 되는 한국 신문사들이 조판기 활자를 한국형 한자 완성형으로만 취급하고 있기 때문. 당장 한국 신문사에서 한글도 완성형 2,350자만 활자로 바꿨다가 조합형 활자로 처음 바꾼 게 2008년 조선일보였고 2019년에 와서야 다른 신문사까지 한글 조합형 활자가 보급됐을 정도로 한국 신문 조판기 세대 교체가 느리게 진행된다. 한글 조판기 개량조차 이 모양인데 한자 조판기야 더 말할 필요가 없다. 한국 신문사들의 한자 활자는 한자검정시험 1급 기준인 어문회 3,500자만 지원하고 있다. 당연히 3,500자에 없는 한자를 써서 뉴스를 팔았다가 타 신문사가 인쇄하는데 조판기에서 에러 나가지고 클레임 먹을 수도 있다. 연합뉴스 등 한국 언론사들이 괜히 파자해서 쓰는 게 아니다.

분류