유니코드

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

유니코드는 1980년대에 시작되어 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 처리하기 위한 문자 인코딩 표준이다. 조 베커, 리 콜린스, 마크 데이비스 등이 개발을 시작했으며, 기존 인코딩의 한계를 극복하고 다국어 환경을 지원하기 위해 설계되었다. 유니코드는 각 문자에 고유한 숫자(코드 포인트)를 할당하며, 16진수로 표기한다. 유니코드 컨소시엄은 이 표준의 개발을 주도하는 비영리 단체이며, UTF-8, UTF-16, UTF-32 등의 다양한 변환 형식을 제공한다. 유니코드는 한글, 한자 등 다양한 언어의 문자 처리를 지원하며, 지속적인 버전 업데이트를 통해 새로운 문자와 기호를 추가하고 있다.

더 읽어볼만한 페이지

유니코드에 관한 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
유니코드에 관한 - UTF-1
UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
유니코드 - 이모지
이모지는 1999년 NTT 도코모에서 처음 도입된 그림 문자로, 유니코드 표준 제정 후 전 세계적으로 확산되어 다양한 언어적 기능을 수행하며 대중문화에 영향을 미치지만, 플랫폼별 표현 방식 차이와 의미 해석 논란도 존재한다.
유니코드 - 국제 음성 기호
국제 음성 기호는 국제 음성 협회가 개발한 언어의 음성 표기 문자 기호 체계로, 라틴 문자를 기반으로 자음, 모음, 초분절 기호 등을 포함하여 모든 언어의 음성을 정확하게 표기하는 것을 목표로 한다.
문자 인코딩 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
문자 인코딩 - Shift JIS
Shift JIS는 JIS X 0201을 기반으로 JIS X 0208을 할당하여 일본어 문자를 인코딩하는 방식으로, 이스케이프 시퀀스 없이 문자 집합을 혼용하여 파일 크기를 절약하고 처리 시간을 단축하며, MS-DOS에서 "MS 한자 코드"로 채택된 후 사실상 표준으로 자리 잡았다.

유니코드
기본 정보
유니코드 컨소시엄 로고
표준	유니코드 표준
지원 언어	168개 스크립트 (목록)
인코딩 방식	UTF-8 UTF-16 GB18030
덜 일반적인 인코딩	UTF-32 BOCU SCSU UTF-EBCDIC
폐기된 인코딩	UTF-7 UTF-1
이전 표준	ISO 8859 등
공식 웹사이트	공식 웹사이트 기술 웹사이트
문자 수	154998
최신 버전 날짜	2024년 9월 10일
유니코드 컨소시엄
참고	TUS로 축약되기도 함

2. 역사

유니코드의 기원은 1987년 제록스의 조 베커와 애플의 리 콜린스, 마크 데이비스가 통일된 문자 집합을 만드는 것을 탐구하기 시작하면서 시작되었다.^[421] 1988년 조 베커는 '유니코드'라는 이름의 국제/다언어 문자 인코딩 시스템 초안을 출판하였다.

유니코드는 기존의 모든 문자 인코딩의 한계를 극복하기 위해 설계되었다. 기존 인코딩은 각각의 문맥에서 사용되었지만, 다른 인코딩과의 호환성은 고려되지 않았다. 대부분의 인코딩은 소수의 문자 집합 간의 상호 운용성만 고려되었고, 다수의 문자 집합 간의 상호 운용성이나 모든 지원되는 문자 집합을 일관된 방식으로 처리하는 것은 고려되지 않았다.

유니코드의 기본 철학은 그래픽적 차이를 단순한 변형 글리프로 간주하고, 기본 문자인 글리프와 글리프와 같은 단위를 인코딩하는 것이다. 시각적 표현 문제는 웹 브라우저나 워드 프로세서와 같이 텍스트를 렌더링하는 소프트웨어에 맡겨진다. 그러나 빠른 채택을 위해 초기 모델의 단순성은 시간이 지남에 따라 다소 복잡해졌다.

처음 256개의 코드 포인트는 ISO/IEC 8859-1 표준을 반영하여 서유럽 문자로 작성된 텍스트의 변환을 단순화하려는 의도였다. 서로 다른 레거시 인코딩에서 만들어진 구분을 유지하고 정보 손실 없이 레거시 인코딩과 유니코드 간의 변환을 허용하기 위해 외관과 기능이 거의 동일한 많은 문자에 고유한 코드 포인트가 지정되었다. 예를 들어, 반각 및 전각 형식 블록은 라틴 알파벳의 전체 의미론적 복제본을 포함하는데, 이는 레거시 CJK 인코딩에 "전각"(CJK 문자의 너비와 일치)과 "반각"(일반 라틴 스크립트와 일치) 문자가 모두 포함되어 있기 때문이다.

1987년, 제록스 직원 조 베커(Joe Becker)는 애플 직원 리 콜린스(Lee Collins)와 마크 데이비스(Mark Davis)와 함께 범용 문자 집합을 만드는 실용성에 대한 조사를 시작했다.^[7] 1988년 8월 "국제/다국어 텍스트 문자 인코딩 시스템"에 대한 초안 제안서를 발표했는데, 이는 가칭 "유니코드(Unicode)"라고 불렸다. 그는 "'유니코드'라는 이름은 고유하고, 통합되고, 보편적인 인코딩을 의미하도록 의도되었다"고 설명했다.^[8] "유니코드 88"이라는 제목의 문서에서 베커는 16비트 문자를 사용하는 방식을 설명했다.^[8]

1989년 초, 유니코드 작업 그룹에는 메타포의 켄 위슬러와 마이크 커너건, 연구 도서관 그룹의 카렌 스미스-요시무라와 조안 알리프랜드, 선 마이크로시스템즈의 글렌 라이트가 합류했다. 1990년에는 마이크로소프트의 미셸 수이냐르와 아스무스 프레이타그, 넥스트의 릭 맥고완도 그룹에 합류했다. 1990년 말까지 기존 표준을 재매핑하는 대부분의 작업이 완료되었고, 유니코드의 최종 검토 초안이 준비되었다.

유니코드 컨소시엄은 1991년 1월 3일 캘리포니아에 설립되었고,^[9] 그해 10월에 ''유니코드 표준''의 첫 번째 권이 출판되었다. 한자를 추가한 두 번째 권은 1992년 6월에 출판되었다. 1996년, 유니코드 2.0에 서로게이트 문자 메커니즘이 구현되어 유니코드가 더 이상 16비트로 제한되지 않았다.

1984년, ISO의 문자 코드 표준 위원회(ISO/TC 97/SC2)는 전 세계의 문자를 단일 문자 집합으로 처리할 수 있는 문자 코드 표준(ISO 10646)을 작성하기로 결정하고, 전문 작업 그룹(ISO/TC 97/SC 2/WG 2)을 설치하여 작업을 시작했다. 1990년에 완성된 ISO 10646 초판 초안(DIS 10646#DIS 10646 제1판)에서는 한자 코드가 32비트로 표현되고 각국의 한자 코드는 그대로 포함되었다. 그러나 중국은 한자를 통일하여 처리해야 한다고 주장하며 초반부터 이 초안에 반대했고, WG 2는 CJK-JRG(Joint Research Group)라는 그룹을 별도로 설치하여 계속 검토하기로 했다.

1991년 6월, ISO/IEC 10646 초안 "DIS 10646 제1판"은 유니코드와의 통합을 요구하는 여러 국가에 의해 부결되었고, ISO 10646과 유니코드의 통합이 추진되었다. 중국과 유니코드 컨소시엄의 요청에 따라 CJK-JRG에서 ISO 10646과 유니코드의 통합이 추진되었다. CJK-JRG는 각국의 한자 코드를 기반으로 독자적인 통합 기준을 정하고, ISO 10646/유니코드용 통합 한자 코드표를 작성하게 되었다. CJK-JRG 회의는 제1회가 7월 22일부터 24일까지 도쿄에서, 제2회 회의가 9월 17일부터 19일까지 베이징에서, 제3회가 11월 25일부터 29일까지 홍콩에서 개최되었다. 그 결과, 1991년 말에 "ISO 10646=유니코드"용 통합 한자 코드표가 Unified Repertoire and Ordering (URO) 제1판으로 완성되었다.

유니코드 최초로 인쇄된 문서인 유니코드 1.0은 통합 한자표 완성에 앞서 한자 부분을 제외한 유니코드 1.0, Vol.1이 1991년 10월에 출판되었고, 1992년에 한자 부분만 있는 유니코드 1.0, Vol.2가 출판되었다.

1992년, CJK 통합 한자 URO 제2판이 완성되었고, DIS 10646 제2판이 5월 30일 국제 투표에서 가결되었다. 1993년 5월 1일 "ISO/IEC 10646-1: 1993 Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and basic Multilingual Plane"이 제정되었다. 같은 해 6월에 유니코드 1.0은 ISO/IEC 10646-1:1993에 맞춰 변경하여 유니코드 1.1이 되었고, 이후 유니코드와 ISO/IEC 10646은 보조를 맞춰 개정되어 간다.

2. 1. 유니코드 컨소시엄

유니코드 컨소시엄은 유니코드 표준 개발을 주도하는 비영리 단체이다. 어도비, 애플, 구글, IBM, 메타, 마이크로소프트, 넷플릭스, SAP 등 텍스트 처리 표준에 관심 있는 주요 컴퓨터 소프트웨어 및 하드웨어 회사가 정회원으로 참여하고 있다.^[11]

여러 국가 및 정부 기관도 유니코드 컨소시엄의 회원으로 참여해 왔으며, 현재는 오만 종교부(Ministry of Endowments and Religious Affairs (Oman))만이 투표권을 가진 정회원이다.^[11] 대한민국 정부나 관련 단체의 직접적인 참여 여부는 명시되어 있지 않지만, 유니코드와 ISO 10646 통합 과정에서 CJK-JRG(Joint Research Group)를 통해 간접적으로 기여한 것으로 보인다. CJK-JRG는 한국, 중국, 일본의 한자 코드를 통합하는 역할을 담당했으며, 1991년 도쿄, 베이징, 홍콩에서 회의를 개최하여 통합 한자 코드표인 URO(Unified Repertoire and Ordering) 제1판을 완성했다.

2. 2. 버전

유니코드 표준은 여러 버전을 거치며 발전해왔다. 각 버전별 주요 변경 사항과 특징은 다음과 같다.

제정 연월일	버전 번호	수록 문자 수	개요	한국어 주요 추가 문자
1991년 10월	Unicode 1.0.0	7,161	초기 버전, 16비트 문자 코드	JIS X 0201
1992년 6월	Unicode 1.0.1	28,359	CJK 통합 한자 도입	JIS X 0208, JIS X 0212
1993년 6월	Unicode 1.1.0	34,233	ISO/IEC 10646-1:1993에 맞춰 변경
1996년 7월	Unicode 2.0.0	38,950	ISO/IEC 10646-1:1993의 보충 Amd.1부터 Amd.7에 대응. 한글의 대이동으로 Unicode 1.x와의 호환성 상실, 서로게이트 페어(대용쌍) 도입으로 추가면을 가능하게 하여 수용 가능한 문자를 대폭 증가, 21비트 영역으로 확장
1998년 5월	Unicode 2.1.0	38,952	유로 기호와 정오표 추가
1999년 9월	Unicode 3.0.0	49,259	ISO/IEC 10646-1:2000 발행까지의 보충 Amd.8부터 Amd.31의 문자 모두에 대응. CJK 통합 한자 확장 A로 한자 6582자 추가	JIS X 0213의 일부(지명이나 인명 등에 사용되는 한자)
2001년 3월	Unicode 3.1.0	94,205	ISO/IEC 10646-2:2001에 대응. BMP 이외 확장. CJK 통합 한자 확장 B로 한자 42711자 추가	JIS X 0213의 일부(지명이나 인명 등에 사용되는 한자)
2002년 3월	Unicode 3.2.0	95,221	ISO/IEC 10646-1:2000의 보충 Amd.1에 대응	JIS X 0213(정식 대응)
2003년 4월	Unicode 4.0.0	96,447	ISO/IEC 10646:2003에 대응
2005년 3월 31일	Unicode 4.1.0	97,720	ISO/IEC 10646:2003의 보충 Amd.1에 대응
2006년 7월 14일	Unicode 5.0.0	99,089	ISO/IEC 10646:2003의 보충 Amd.2와 신드어에 대응
2008년 4월 4일	Unicode 5.1.0	100,713	ISO/IEC 10646:2003의 보충 Amd.3과 Amd.4에 대응. 이체자 선택자를 한자에 대해 사용하기 시작	마작패, 나눗셈의 필산(장제법) 기호, 전화기의 별표, Adobe-Japan1-6의 한자 자형
2009년 10월 1일	Unicode 5.2.0	107,361	ISO/IEC 10646:2003의 보충 Amd.6까지 대응	ARIB 외자
2010년 10월 11일	Unicode 6.0.0	109,449	ISO/IEC 10646:2010	휴대전화 이모티콘
2012년 1월 31일	Unicode 6.1.0	110,181	ISO/IEC 10646:2012
2012년 9월 26일	Unicode 6.2.0	110,182	신 터키 리라의 통화 기호 추가 등
2013년 9월 30일	Unicode 6.3.0	110,187
2014년 6월 16일	Unicode 7.0.0	113,021	ISO/IEC 10646:2012의 보충 Amd.1과 Amd.2에 대응. 루블, 아제르바이잔 마나트의 통화 기호, 북미·중국·인도·아프리카 언어를 위한 역사적 스크립트 추가.	약 250자의 이모티콘 추가.
2015년 6월 17일	Unicode 8.0.0	120,737	ISO/IEC 10646:2014의 보충 Amd.1에 대응.	U+301C WAVE DASH 수정
2016년 6월 21일	Unicode 9.0.0	128,172	ISO/IEC 10646:2014의 보충 Amd.2에 대응.	91개의 이모티콘 추가, 4KTV 방송용 심볼 19개 추가
2017년 6월 20일	Unicode 10.0.0	136,690	ISO/IEC 10646:2017	변체가나 285자 추가
2018년 6월 5일	Unicode 11.0.0	137,374	ISO/IEC 10646:2017의 보충 Amd.1에 대응
2019년 3월 5일	Unicode 12.0.0	137,928	ISO/IEC 10646:2017의 보충 Amd.1과 Amd.2에 대응	소문자「ゐ」「ゑ」「を」「ヰ」「ヱ」「ヲ」「ン」추가
2019년 5월 7일	Unicode 12.1.0	137,929		「㋿」(일본의 연호「레이와」의 합자) 추가
2020년 3월 10일	Unicode 13.0.0	143,859	ISO/IEC 10646:2020
2021년 9월 22일	Unicode 14.0.0	144,697	ISO/IEC 10646:2021	와행우, 야행이, 야행에 추가
2022년 9월 13일	Unicode 15.0.0	149,186	ISO/IEC 10646:2022
2023년 9월 12일	Unicode 15.1.0	149,813	ISO/IEC 10646:2023
2024년 9월 10일	Unicode 16.0.0^[173]	154,998	ISO/IEC 10646:2024

주요 변경 사항:

Unicode 1.0.0 (1991년 10월): 초기 버전으로 7,161개의 문자를 포함했다.
Unicode 1.0.1 (1992년 6월): 20,902자의 CJK 통합 한자가 추가되었다.^[423]
Unicode 1.1 (1993년 6월): 기존 한글 2,350자에 4,306자가 추가되었고, 티베트 문자가 삭제되었다.^[424]
Unicode 2.0 (1996년 7월): 기존 한글 글자마디가 삭제되고 11,172자의 새로운 한글 완성자 영역이 지정되었다. 티베트 문자가 새로운 위치에 추가되었고, 서로게이트 영역이 지정되어 제15, 제16 평면이 사용자 정의 영역으로 지정되었다.^[425]
이는 유니코드 1.1까지 정의되었던 한글 영역을 폐기하고, 새로운 한글 영역을 다른 위치에 설정하는 대규모 변경이었다. 이를 "한글 대이동"이라고 부른다.
Unicode 2.1 (1998년 5월): 유로 기호 (€)가 추가되었다.^[426]
Unicode 5.2 (2009년 10월): 4,149자의 CJK 통합 한자 (CJK-C)와 옛 한글 확장 자모가 추가되었다.^[434]
Unicode 6.0 (2010년 10월): 이모티콘과 에모지가 추가되었다.^[435]
Unicode 14.0 (2021년 9월): 와행우, 야행이, 야행에 추가

유니코드 컨소시엄은 일반적으로 매년 새로운 버전의 ''유니코드 표준''을 발표한다.^[57]^[58]

3. 유니코드 문자 부호화 모델

유니코드(Unicode)는 전 세계에서 사용되는 모든 문자를 공통된 문자 집합으로 이용할 수 있도록 고안되었으며, 문자 코드는 유니코드 문자 부호화 모델에 따라 다음 4단계로 나뉜다.^[126]

추상 문자 집합(ACR): 부호화 대상이 되는 순서가 없는 문자의 집합.
부호화 문자 집합(CCS): 추상 문자 집합을 음이 아닌 정수에 대응시킨 것. 이 음이 아닌 정수의 범위를 부호 공간, 각 값을 코드 포인트라고 하며, 추상 문자는 대응 후 부호화 문자가 된다.^[127] 추상 문자는 여러 개의 부호화 문자에 대응될 수도 있다.^[128]
문자 부호화 형식(CEF): 부호화 문자 집합의 음이 아닌 정수를 부호 단위열로 변환하는 방법. 컴퓨터 내부에서 실제로 데이터로서 문자를 표현할 수 있게 한다.
문자 부호화 방식(CES): 부호 단위열을 바이트열로 직렬화하는 방법. 부호 단위가 8비트보다 큰 경우 엔디안이 관련된다.

그 후, 바이트열을 gzip 등으로 압축하거나, 7비트 전송 경로를 통과하기 위해 Base64나 Quoted-printable 등으로 변환하는 경우가 있지만, 이들은 문자 코드의 범위를 벗어난다.

문자 부호화 형식 (CEF)	문자 부호화 방식 (CES)
UTF-8	UTF-8
UTF-16	UTF-16
	UTF-16BE
	UTF-16LE
UTF-32	UTF-32
	UTF-32BE
	UTF-32LE

유니코드에서는 문자 부호화 방식으로 '''UTF-8''', '''UTF-16''', '''UTF-16BE''', '''UTF-16LE''', '''UTF-32''', '''UTF-32BE''', '''UTF-32LE'''의 7가지가 정의되어 있다. 각 부호화 형식에 해당하는 부호화 방식은 표와 같다.

문자 부호화 형식과 문자 부호화 방식의 차이는 전자가 프로그램 내부에서 문자를 다룰 때 부호 없는 정수로 문자를 표현하는 방법인 반면, 후자는 입출력 시 바이트열로 표현하는 방법이다. UTF-8은 부호 단위가 8비트이므로 구분할 의미가 없다.

문자 부호화 방식 (CES)	엔디안	BOM 부여
UTF-8		없음
UTF-16	빅/리틀 엔디안	가능
UTF-16BE	빅 엔디안	불가능
UTF-16LE	리틀 엔디안	불가능
UTF-32	빅/리틀 엔디안	가능
UTF-32BE	빅 엔디안	불가능
UTF-32LE	리틀 엔디안	불가능

; UTF-8

UTF-8은 가변 길이(1-4바이트)의 8비트 부호 단위로 표현하는 문자 부호화 방식이다. ASCII에 대해 상위 호환이 되며, 문자의 경계가 명확하고, UTF-16이나 UTF-32와의 변환 및 역변환 시에 곱셈이나 나눗셈 등의 고부하 처리가 필요 없다는 특징을 가지며, 인터넷에서 가장 일반적으로 사용된다.

UTF-8은 8비트를 부호 단위로 하므로 바이트 순서 표시(BOM)가 필요 없지만, UTF-8임을 식별하기 위해 데이터 스트림의 선두에 EF BB BF(U+FEFF의 UTF-8 표현)의 3바이트가 추가될 수 있다. UTF-8의 BOM은 바이트 순서를 나타내는 것이 아니라 UTF-16 등에서의 "진정한 의미의 BOM"과 같은 코드 포인트를 사용하고 있기 때문에 관습적으로 이렇게 불린다. UTF-8에서 BOM 사용은 권장되지 않는다.^[132]

; UTF-16

UTF-16에서는 일반적으로 파일의 선두에 바이트 순서 표시(BOM)가 추가된다. BOM은 통신이나 파일의 읽기/쓰기 등 8비트 단위의 처리에서 바이트 순서를 식별하기 위한 표시이며, 데이터 스트림의 선두에 추가된다. 값은 U+FEFF이다. 시스템이 읽어들인 선두 2바이트가 FF FE이면 리틀 엔디안, FE FF이면 빅 엔디안으로 판단하여 그 이후의 문서를 처리한다.

에서는 BOM이 없는 UTF-16 문서는 빅 엔디안으로 해석하는 것으로 되어 있다. 마이크로소프트 윈도우의 메모장으로 작성한 "유니코드 텍스트"에는 BOM이 추가된다. 빅 엔디안의 부호화 방식을 '''UTF-16BE''', 리틀 엔디안의 부호화 방식을 '''UTF-16LE'''로 구분하기도 한다. 프로토콜이나 애플리케이션 설정 등으로 부호화 방식에 '''UTF-16BE''' 또는 '''UTF-16LE'''을 지정한 경우에는 BOM을 추가하는 것을 허용하지 않는다. Windows의 문서에서 "유니코드 텍스트"는 특별히 명시하지 않는 한 리틀 엔디안의 UTF-16을 의미한다. TCP/IP 네트워크에서는 프로토콜 헤더나 MIME 등으로 부호화 방식이 지정되지 않고 BOM도 추가되지 않은 경우, 빅 엔디안으로 처리한다고 정해져 있다.

; UTF-32

UTF-32도 UTF-16과 마찬가지로 빅 엔디안과 리틀 엔디안이 있으며, 각각 '''UTF-32BE''', '''UTF-32LE'''라고 부른다. 프로토콜이나 애플리케이션 설정 등으로 부호화 방식에 '''UTF-32BE''' 또는 '''UTF-32LE'''을 지정한 경우에는 BOM을 추가하는 것을 허용하지 않는다.

단순한 부호화 방식이지만, 텍스트 파일 등에서는 파일 크기가 커진다(모두 BMP 문자로 된 문장의 경우 UTF-16의 2배, 모두 ASCII 문자의 경우 ASCII/UTF-8의 4배 크기가 된다). 따라서 저장용으로 사용되는 경우는 드물다. 마이크로소프트 오피스에서 "인코딩된 텍스트 파일"의 읽기/쓰기는 Office 2016에서도 아직 지원하지 않는다. 프리웨어·셰어웨어의 텍스트 편집기 중 많은 부호화 방식을 지원하는 것들 중에서도 이 방식을 지원하지 않는 것이 있다.

하지만 모든 유니코드 문자를 처리하는 경우 모든 문자를 단일 부호 단위로 표현하는 것이 처리에 적합하므로, 내부 처리에서는 UTF-32(또는 UCS-4)로 처리하는 경우도 있다. 실례로 리눅스의 C 언어 환경에서는 `wchar_t`가 32비트 정수형이다.

UTF-16과 마찬가지로 UTF-32에도 BOM이 있으며, 데이터 스트림의 선두에 추가된다. 선두 4바이트가 FF FE 00 00이면 리틀 엔디안, 00 00 FE FF이면 빅 엔디안이 된다. UTF-16의 리틀 엔디안과 UTF-32의 리틀 엔디안은 처음 2바이트가 같으므로 4바이트까지 읽어서 판단할 필요가 있다.

각 문자 부호화 방식의 부호화 예
UTF-8	A	Ω		語			😊
UTF-8	41	CE	A9	E8	AA	9E	F0	9F	98	8A
UTF-16BE	A		Ω		語		😊
UTF-16BE	00	41	03	A9	8A	9E	D8	3D	DE	0A
UTF-16LE	A		Ω		語		😊
UTF-16LE	41	00	A9	03	9E	8A	3D	D8	0A	DE
UTF-32BE	A				Ω				語				😊
UTF-32BE	00	00	00	41	00	00	03	A9	00	00	8A	9E	00	01	F6	0A
UTF-32LE	A				Ω				語				😊
UTF-32LE	41	00	00	00	A9	03	00	00	9E	8A	00	00	0A	F6	01	00

3. 1. 코드 공간(Codespace) 및 코드 포인트(Code points)

유니코드 표준은 코드 공간(codespace)을 정의한다.^[59] 코드 공간은 0부터 까지의 범위를 갖는 코드 포인트(코드 포인트)^[60]들의 순서이며, 표준에서는 –로 표기한다.^[61] 코드 공간은 유니코드 표준을 체계적이고 아키텍처에 독립적인 방식으로 나타낸 것이다. 실제 텍스트는 UTF-8과 같은 여러 유니코드 인코딩 중 하나를 통해 이진 데이터로 처리된다.

이 표준 표기법에서 두 문자 접두사 `U+`는 항상 코드 포인트 앞에 오며,^[62] 코드 포인트 자체는 16진수로 표기된다. 항상 최소한 네 자리의 16진수가 표기되며, 필요에 따라 선행 0이 추가된다. 예를 들어, 코드 포인트 는 두 개의 선행 0으로 채워지지만, (

)는 채워지지 않는다.^[63]

코드 공간에는 총 2²⁰ + (2¹⁶ − 2¹¹) = 개의 유효한 코드 포인트가 있다. (이 숫자는 부터 까지의 2¹⁶개의 코드 포인트를 인코딩할 수 있지만, 부터 까지의 2¹¹개의 코드 포인트는 서로게이트 쌍으로 사용되어 부터 까지의 2²⁰개의 코드 포인트를 인코딩하는 UTF-16 문자 인코딩의 제한에서 비롯된다.)

각 코드 포인트에는 코드 포인트의 일반 범주 속성으로 나열된 분류가 할당된다. 최상위 수준에서 코드 포인트는 문자, 마크, 숫자, 구두점, 기호, 구분 기호 또는 기타로 분류된다. 각 범주 아래에서 각 코드 포인트는 더 세분화된다. 대부분의 경우, 주어진 코드 포인트의 모든 특성을 적절하게 설명하려면 다른 속성을 사용해야 한다.

– 범위의 개 포인트는 ''상위 서러게이트'' 코드 포인트로 알려져 있으며, – 범위의 코드 포인트(개 코드 포인트)는 ''하위 서러게이트'' 코드 포인트로 알려져 있다. 상위 서러게이트 코드 포인트 뒤에 하위 서러게이트 코드 포인트가 오면 보다 큰 코드 포인트를 나타내기 위해 UTF-16에서 ''서러게이트 쌍''을 형성한다. 원칙적으로 이러한 코드 포인트는 사용할 수 없지만, 실제로는 특히 UTF-16을 사용하지 않는 경우 이 규칙이 자주 무시된다.

소수의 코드 포인트는 문자에 할당되지 않도록 보장되지만, 제3자는 자체적으로 임의로 사용할 수 있다. 이러한 ''비문자''는 66개가 있다. – 및 각 17개 평면의 마지막 두 코드 포인트(예: , , , , ..., , ). 비문자 집합은 안정적이며 새로운 비문자는 정의되지 않는다.^[64] 서러게이트와 마찬가지로 이러한 코드 포인트를 사용할 수 없다는 규칙은 종종 무시되지만, 바이트 순서 표시의 작동은 가 텍스트의 첫 번째 코드 포인트가 되지 않을 것이라고 가정한다. 서러게이트와 비문자를 제외하면 개의 코드 포인트를 사용할 수 있다.

''개인 사용'' 코드 포인트는 할당된 것으로 간주되지만, 의도적으로 ''유니코드 표준''에서 지정된 해석이 없으므로^[65] 이러한 코드 포인트를 교환하려면 송신자와 수신자 간에 해석에 대한 독립적인 합의가 필요하다. 유니코드 코드 공간에는 세 개의 개인 사용 영역이 있다.

개인 사용 영역: – (개 문자),
보조 개인 사용 영역-A: – (개 문자),
보조 개인 사용 영역-B: – (개 문자).

''그래픽'' 문자는 ''유니코드 표준''에서 특정 의미를 갖도록 정의된 문자로, 눈에 보이는 글리프 모양을 갖거나 눈에 보이는 공백을 나타낸다. 유니코드 16.0 기준으로 그래픽 문자는 개 있다.

''서식'' 문자는 눈에 보이는 모양은 없지만 이웃 문자의 모양이나 동작에 영향을 줄 수 있는 문자이다. 예를 들어, 및 을 사용하여 인접 문자의 기본 모양 동작을 변경할 수 있다(예: 리가처를 금지하거나 리가처 형성을 요청). 유니코드 16.0에는 172개의 서식 문자가 있다.

65개의 코드 포인트(– 및 – 범위)는 C0 및 C1 제어 코드( ISO/IEC 6429에 정의됨)에 해당하는 ''제어 코드''로 예약되어 있다. , , 및 은 유니코드를 사용하는 텍스트에서 널리 사용된다. 모지바케로 알려진 현상에서 C1 코드 포인트는 이전에 서유럽 맥락에서 널리 사용되었던 Windows-1252 코드 페이지에 따라 잘못 디코딩된다.

그래픽, 서식, 제어 코드 및 개인 사용 문자는 통칭하여 ''할당된 문자''라고 한다. ''예약된'' 코드 포인트는 유효하고 사용 가능하지만 아직 할당되지 않은 코드 포인트이다. 유니코드 15.1 기준으로 예약된 코드 포인트는 개 있다.

3. 2. 코드 평면(Code planes) 및 블록(Blocks)

유니코드 코드 공간은 0부터 16까지 번호가 매겨진 17개의 ''평면''으로 나뉜다. 평면 0은 기본 다국어 평면(BMP)이며 가장 일반적으로 사용되는 문자를 포함한다. BMP의 모든 코드 포인트는 UTF-16 인코딩에서 단일 코드 단위로 접근 가능하며, UTF-8에서는 1, 2 또는 3바이트로 인코딩될 수 있다. 평면 1부터 16까지(보조 평면)의 코드 포인트는 UTF-16에서 서로게이트 쌍으로 접근 가능하며, UTF-8에서는 4바이트로 인코딩된다.

각 평면 내에서 문자는 관련된 문자끼리 모아 ''블록''으로 할당된다. 블록의 크기는 항상 16의 배수이며, 종종 128의 배수이지만, 그 외에는 정해진 규칙이 없다. 특정 문자 체계에 필요한 문자들이 코드 공간 내에서 여러 개의 서로 다른 블록에 분산될 수 있다.

한 면에는 65,536개의 코드 포인트가 있다.

면	코드 포인트	영어 명칭	약칭	일본어 명칭	포함된 주요 문자
제0면	`U+0000 - U+FFFF`	Basic Multilingual Plane	BMP	기본 다국어면	기본적인 문자.
제1면	`U+10000 - U+1FFFF`	Supplementary Multilingual Plane	SMP	추가 다국어면	고대 문자, 기호, 이모티콘 등.
제2면	`U+20000 - U+2FFFF`	Supplementary Ideographic Plane	SIP	추가 한자면	한자 전용 영역.
제3면	`U+30000 - U+3FFFF`	Tertiary Ideographic Plane	TIP	제3한자면	추가 한자면에 포함되지 못한 한자. 장래에는 고대 한자나 갑골 문자가 수록될 예정.
제4면	`U+40000 - U+4FFFF`	미사용 (향후 사용 목적도 결정되지 않음).
제5면	`U+50000 - U+5FFFF`
제6면	`U+60000 - U+6FFFF`
제7면	`U+70000 - U+7FFFF`
제8면	`U+80000 - U+8FFFF`
제9면	`U+90000 - U+9FFFF`
제10면	`U+A0000 - U+AFFFF`
제11면	`U+B0000 - U+BFFFF`
제12면	`U+C0000 - U+CFFFF`
제13면	`U+D0000 - U+DFFFF`
제14면	`U+E0000 - U+EFFFF`	Supplementary Special-purpose Plane	SSP	추가 특수 용도면	제어 코드 전용 영역.
제15면	`U+F0000 - U+FFFFF`	Private Use Plane	PUP	사용자 정의 영역	BMP의 U+E000 - U+F8FF 영역 확장.
제16면	`U+100000 - U+10FFFF`	Private Use Plane	PUP	사용자 정의 영역	BMP의 U+E000 - U+F8FF 영역 확장.

2000년, 일본에서는 JIS X 0208을 확장하기 위해 JIS X 0213(JIS 제3·제4수준)이 제정되었다. 이때 새롭게 추가된 문자 중 Unicode에 없던 일부는 BMP에 넣을 수 없어 제2면에 수록되었다. Unicode가 JIS X 0213을 완전히 지원하게 된 것은 2002년이다. 따라서 JIS X 0213 수록 문자를 Unicode로 모두 표현하려면 추가 한자면을 지원하는 OS, 글꼴, 응용 프로그램이 필요하다. Shift_JIS 등 Unicode 이외의 인코딩을 사용하는 경우에도 JIS X 0213에 대응하는 글꼴과 응용 프로그램이 필요하다.

常用漢字의 2010년 개정에서 추가된 글자 중 ''는 U+20B9F로, 추가 한자면에 포함된다. 따라서 개정 이후의 상용한자를 완전히 지원하려면 Unicode 및 확장 영역에 대응해야 한다. 다만, 현재 이 글자는 JIS X 0208에 포함된(Unicode 제정 초기부터 BMP에 수록된) 이체자 '叱'(U+53F1)로 대체되는 경우가 많다.

3. 3. 일반 범주(General Category) 속성

각 코드 포인트에는 일반 범주 속성에 따라 분류가 할당된다. 최상위 수준에서 코드 포인트는 문자, 마크, 숫자, 구두점, 기호, 구분 기호 또는 기타로 분류된다. 각 범주 아래에서 각 코드 포인트는 더 세분화된다. 대부분의 경우, 주어진 코드 포인트의 모든 특성을 적절하게 설명하려면 다른 속성을 사용해야 한다.

3. 4. 결합 문자(Combining characters)

유니코드는 지원되는 글리프의 종류를 크게 확장하기 위해 문자를 수정하는 메커니즘을 포함한다. 여기에는 사용자가 기본 문자 뒤에 추가할 수 있는 결합 부호의 사용이 포함된다. 여러 개의 결합 부호를 동시에 같은 문자에 적용할 수 있다. 유니코드는 일반적으로 사용되는 대부분의 문자/부호 조합에 대한 미리 구성된 버전도 포함하고 있다. 이를 통해 레거시 인코딩과의 변환이 간단해지고, 애플리케이션은 결합 문자를 구현할 필요 없이 유니코드를 내부 텍스트 형식으로 사용할 수 있다. 예를 들어, 'é'는 유니코드에서 다음에 를 사용하여 표현할 수 있으며, 이는 미리 구성된 문자 와 동일하다. 따라서 사용자는 종종 동일한 문자를 인코딩하는 여러 가지 동등한 방법을 사용할 수 있다. ''유니코드 표준'' 내의 정규 등가 메커니즘은 이러한 동등한 인코딩의 실질적인 상호 교환성을 보장한다.

이것의 예는 한국어 알파벳 한글에서 나타난다. 유니코드는 개별 한글 자모 구성 요소로부터 한글 음절을 구성하는 메커니즘을 제공한다. 그러나 가장 일반적인 자모로 만들어진 개의 미리 구성된 음절 조합도 제공한다.

부호가 있는 문자는 일반적으로 하나의 사전 조합 문자 또는 기본 문자와 하나 이상의 비공백 부호의 분해된 시퀀스로 표현될 수 있다. 예를 들어, ḗ (사전 조합된 e에 마크롱과 윗첨자 액센트가 있는 문자)와 ē̊́ (e 다음에 결합 마크롱 위에 결합 액센트가 있는 문자)는 모두 마크롱(◌̄)과 액센트(◌́)가 있는 e로 동일하게 렌더링되어야 하지만, 실제로는 문자를 표시하는 데 사용되는 렌더링 엔진과 글꼴에 따라 모양이 다를 수 있다.

3. 5. 표준화된 부분 집합

마이크로소프트 Windows는 Windows NT 4.0부터 WGL-4(657자)를 지원하여 라틴, 그리스 또는 키릴 문자를 사용하는 모든 현대 유럽 언어를 지원하는 것으로 간주된다.^[70] Unicode의 다른 표준화된 부분 집합으로는 다국어 유럽 부분 집합(MES)이 있다.^[70] MES-1(라틴 문자만, 335자), MES-2(라틴, 그리스 및 키릴 문자, 1062자)^[71], MES-3A와 MES-3B(여기서는 표시되지 않은 두 개의 더 큰 부분 집합)가 있다. MES-2에는 MES-1과 WGL-4의 모든 문자가 포함되어 있다.

표준 DIN 91379^[72]는 이름을 정확하게 표현하고 유럽의 데이터 교환을 단순화하기 위해 Unicode 문자, 특수 문자, 문자와 악센트 부호의 시퀀스 부분 집합을 지정한다. 이 표준은 모든 유럽 연합 국가의 공식 언어뿐만 아니라 독일 소수 언어와 아이슬란드, 리히텐슈타인, 노르웨이, 스위스의 공식 언어도 지원한다. 관련 ISO 표준에 따라 다른 문자 체계의 이름을 라틴 문자로 음역할 수 있도록 모든 필요한 기본 문자와 악센트 부호 조합이 제공된다.

WGL-4, MES-1 및 MES-2
행	셀	범위
00	'20–7E'	기본 라틴어 (00–7F)
00	'A0–FF'	라틴-1 보충 (80–FF)
01	'00–13, 14–15, 16–2B, 2C–2D, 2E–4D, 4E–4F, 50–7E,7F	라틴 확장-A (00–7F)
01	8F, 92, B7, DE-EF, FA–FF	라틴 확장-B (80–FF)
02	18–1B, 1E–1F	라틴 확장-B (00–4F)
	59, 7C, 92	IPA 확장 (50–AF)
	BB–BD, 'C6, C7,C9, D6, 'D8–DB, DC, DD,' DF, EE	띄어쓰기 수정 문자 (B0–FF)
03	74–75, 7A, 7E, 84–8A, 8C, 8E–A1, A3–CE, D7, DA–E1	그리스어 (70–FF)
04	00–5F, 90–91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9	키릴 문자 (00–FF)
1E	02–03, 0A–0B, 1E–1F, 40–41, 56–57, 60–61, 6A–6B, 80–85, 9B, F2–F3	라틴 확장 추가 (00–FF)
1F	00–15, 18–1D, 20–45, 48–4D, 50–57, 59, 5B, 5D, 5F–7D, 80–B4, B6–C4, C6–D3, D6–DB, DD–EF, F2–F4, F6–FE	그리스어 확장 (00–FF)
20	'13–14, 15, 17, 18–19, 1A–1B, 1C–1D,1E, 20–22, 26, 30, 32–33, 39–3A, 3C, 3E, 44, 4A	일반 구두점 (00–6F)
	7F, 82	위첨자 및 아래첨자 (70–9F)
	'A3–A4, A7, AC,' AF	통화 기호 (A0–CF)
21	'05, 13, 16, 22, 26,2E	문자와 같은 기호 (00–4F)
	'5B–5E'	숫자 형태 (50–8F)
	'90–93,94–95, A8	화살표 (90–FF)
22	00, 02, 03, 06, 08–09, 0F, 11–12, 15, 19–1A, 1E–1F, 27–28, 29, 2A, 2B, 48, 59, 60–61, 64–65, 82–83, 95, 97	수학 연산자 (00–FF)
23	02, 0A, 20–21, 29–2A	기타 기술 (00–FF)
25	00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50–6C	상자 그리기 (00–7F)
	80, 84, 88, 8C, 90–93	블록 요소 (80–9F)
	A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6	기하학적 도형 (A0–FF)
26	'3A–3C, 40, 42, 60, 63, 65–66, 6A,6B	기타 기호 (00–FF)
F0	(01–02)	개인 사용 영역 (00–FF ...)
FB	01–02	알파벳 표현 형태 (00–4F)
FF	FD	특수 문자

4. 유니코드 변환 형식(UTF)과 국제 문자 세트(UCS)

유니코드는 '''유니코드 변환 형식(UTF)''' 인코딩과 '''국제 문자 세트(UCS)''' 인코딩이라는 두 가지 매핑 방법을 제공한다. 인코딩은 유니코드 코드 포인트 범위(일부만 해당될 수도 있음)를 ''코드 유닛''이라는 고정된 크기의 값들의 연속된 형태로 매핑한다. 모든 UTF 인코딩은 코드 포인트를 고유한 바이트 열에 매핑한다.^[73] 인코딩 이름에 붙은 숫자는 코드 유닛당 비트 수(UTF 인코딩의 경우) 또는 코드 유닛당 바이트 수(UCS 인코딩 및 UTF-1의 경우)를 나타낸다. 가장 일반적으로 사용되는 인코딩은 UTF-8과 UTF-16이다. UCS-2는 UTF-16의 구식 하위 집합이며, UCS-4와 UTF-32는 기능적으로 동일하다.

UTF 인코딩에는 다음이 포함된다.

UTF-8: 코드 포인트당 1~4개의 8비트 유닛을 사용하며,^[74] ASCII와의 호환성을 최대화한다.
UTF-16: U+010000 미만의 코드 포인트에는 1개의 16비트 유닛을 사용하고, U+010000부터 U+10FFFF 범위의 코드 포인트에는 서로게이트 쌍인 2개의 16비트 유닛을 사용한다.
UTF-32: 코드 포인트당 1개의 32비트 유닛을 사용한다.
UTF-EBCDIC: ''유니코드 표준''의 일부로 지정되지 않았으며, 코드 포인트당 1~5개의 8비트 유닛을 사용하여 EBCDIC과의 호환성을 최대화하도록 설계되었다.

4. 1. UTF-8

UTF-8은 코드 포인트당 1~4개의 8비트 유닛(바이트)을 사용하는 가변 길이 문자 인코딩 방식이다.^[74] ASCII와의 호환성이 최대화되어 있으며,^[74] 라틴 문자와 ASCII를 사용하는 환경에서 효율적이기 때문에 유니코드 텍스트 교환의 사실상 표준 인코딩으로 자리 잡았다. FreeBSD와 최신 리눅스 배포판에서는 일반적인 텍스트 처리에서 레거시 인코딩을 대체하여 사용되고 있다.

2008년 이후로 월드 와이드 웹에서 가장 많이 사용되는 인코딩 방식이다.^[76] 2024년 현재, UTF-8은 모든 웹 페이지의 평균 98.3%(상위 1,000개 웹 페이지 중 983개)를 차지한다.^[77] 많은 페이지가 콘텐츠 표시에 ASCII 문자만 사용하지만, UTF-8은 8비트 ASCII를 하위 집합으로 포함하도록 설계되었기 때문에, 거의 모든 웹사이트가 UTF-8 대신 ASCII만 사용한다고 인코딩을 선언하지 않는다.^[78]

인터넷 기술 특별 위원회에서 관리하는 모든 인터넷 프로토콜(예: FTP)^[79]은 1998년 발표 이후 UTF-8 지원을 필수로 요구하고 있으며, 모든 IETF 프로토콜은 "UTF-8 문자 집합을 사용할 수 있어야 합니다"라고 명시하고 있다.^[80]

UTF-8, UTF-16, UTF-32 인코딩 예시
	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
UTF-8	A	Ω		語			😊
UTF-8	41	CE	A9	E8	AA	9E	F0	9F	98	8A
UTF-16	A		Ω		語		😊
UTF-16	0041		03A9		8A9E		D83D		DE0A
UTF-32	A				Ω				語				😊
UTF-32	00000041				000003A9				00008A9E				0001F60A

4. 2. UTF-16

UTF-16은 1문자를 1~2 코드 단위로 표현하는 가변 길이 문자 인코딩 형식이며, 1코드 단위는 16비트이다. 기본 다국어 평면의 문자는 코드 단위 하나로, 다른 문자는 서로게이트 쌍(대용쌍)이라는 메커니즘을 사용하여 코드 단위 두 개로 표현한다.^[73]

서로게이트 쌍(Surrogate Pair)은 16비트 유니코드 영역 중 1,024자씩 두 개를 사용하여(전반부 U+D800 ~ U+DBFF, 후반부 U+DC00 ~ U+DFFF) 각각 하나씩으로 이루어진 쌍으로 1,024 × 1,024 = 1,048,576자를 나타낸다. 이는 16면에 해당하며, 1면부터 16면(U+010000 ~ U+10FFFF)의 문자를 이것으로 나타낸다. 여기에 0면(기본 다국어 평면)도 사용 가능하므로, 유니코드에는 총 1,048,576 + 65,536 - 2,048 = 1,112,064자의 공간이 확보되었다. 유니코드의 코드 공간이 U+10FFFF₁₆까지(서로게이트 영역을 제외하고 1,112,064자)인 것은 UTF-16이 표현 가능한 한계이기 때문이다.

서로게이트는 유니코드의 코드 위치 U+010000 ~ U+10FFFF 범위를 16비트 유닛의 쌍(두 개)으로 표현하는 집합이며, 첫 번째 16비트 유닛을 전반부 서로게이트 또는 하이 서로게이트, 두 번째를 후반부 서로게이트 또는 로우 서로게이트라고 한다. 하이 서로게이트는 U+D800 ~ U+DBFF 범위이고, 로우 서로게이트는 U+DC00 ~ U+DFFF 범위이다.

서로게이트 쌍은 UTF-16에서만 사용되며^[133], UTF-8, UTF-32에서는 모든 코드 위치를 인코딩할 수 있으므로 이러한 특별한 처리가 필요 없다.

서로게이트 인코딩은 코드 포인트를

CP

, 하이 서로게이트를

HSG

, 로우 서로게이트를

LSG

라고 할 때 다음과 같이 계산한다.

:

HSG = \mathrm{floor}\left(\frac{CP - 10000_{16}}{400_{16}}\right) + {\rm D800}_{16}

:

LSG = \left(CP - 10000_{16}\right)\bmod 400_{16} + {\rm DC00}_{16}

디코딩은,

:

CP = 10000_{16} + \left(HSG - {\rm D800}_{16}\right)\times 400_{16} + \left(LSG - {\rm DC00}_{16}\right)

이다.

; 코드 변환 예: “𠮷” U+20BB7의 인코딩

::

{\color{green}0010\ 0000\ 10}{\color{blue}11\ 1011\ 0111}_2\ ({\rm 20BB7}_{16})

에서

::

0001\ 0000\ 0000\ 0000\ 0000_2\ (10000_{16})

을 빼면

::

{\color{green}0001\ 0000\ 10}{\color{blue}11\ 1011\ 0111}_2\ ({\rm 10BB7}_{16})

이 된다.

: 이것을 상위 10비트 값과 하위 10비트 값으로 분할한다.

::

{\color{green}0001\ 0000\ 10}_2\ ({\color{green}0042}_{16}),\ \ {\color{blue}11\ 1011\ 0111}_2\ ({\rm\color{blue}03B7}_{16})

: 하이(상위) 서로게이트를 형성하기 위해 상위 비트에

{\rm D800}_{16}

을 더한다.

::

{\color{green}00\ 0100\ 0010}_2\ ({\color{green}0042}_{16}) + 1101\ 1000\ 0000\ 0000_2\ ({\rm D800}_{16}) = 1101\ 10{\color{green}00\ 0100\ 0010}_2 ({\rm D842}_{16})

: 로우(하위) 서로게이트를 형성하기 위해 하위 비트에

{\rm DC00}_{16}

을 더한다.

::

{\color{blue}11\ 1011\ 0111}_2\ ({\rm\color{blue}03B7}_{16}) + 1101\ 1100\ 0000\ 0000_2\ ({\rm DC00}_{16}) = 1101\ 11{\color{blue}11\ 1011\ 0111}_2 ({\rm DFB7}_{16})

: 결과

::

{\rm\color{green}D842}_{16},\ {\rm\color{blue}DFB7}_{16}

(UTF-16 코드 단위열)

::

{\rm\color{green}D8}_{16},\ {\rm\color{green}42}_{16},\ {\rm\color{blue}DF}_{16},\ {\rm\color{blue}B7}_{16}

(UTF-16BE로 인코딩된 바이트열)

::

{\rm\color{green}42}_{16},\ {\rm\color{green}D8}_{16},\ {\rm\color{blue}B7}_{16},\ {\rm\color{blue}DF}_{16}

(UTF-16LE로 인코딩된 바이트열)

다음 표는 이 문자 변환과 다른 것들을 정리한 것이다. 색은 코드 포인트에서 비트가 UTF-16 바이트에 어떻게 할당되는지 보여준다. UTF-16 인코딩 프로세스에 의해 추가된 추가 비트는 검은색으로 표시되어 있다.

문자 （코드 포인트）		UTF-16 코드 단위열(2진수)	UTF-16 코드 단위열	UTF-16BE 인코딩된 바이트열	UTF-16LE 인코딩된 바이트열
$	`U+0024`
€	`U+20AC`
𠮷	`U+20BB7`	`1101 1000 0100 0010 1101 1111 1011 0111`	`D842 DFB7`	`D8 42 DF B7`	`42 D8 B7 DF`
최댓값	`U+10FFFF`	`1101 1011 1111 1111 1101 1111 1111 1111`	`DBFF DFFF`	`DB FF DF FF`	`FF DB FF DF`

윈도우 NT와 그 후속 버전( 2000, XP, Vista, 7, 8, 10, 11)은 UTF-16을 유일한 내부 문자 인코딩으로 사용한다. 자바 및 .NET 바이트코드 환경, macOS, 그리고 KDE도 내부 표현에 UTF-16을 사용한다.

4. 3. UTF-32

UTF-32는 코드 포인트당 1개의 32비트 유닛을 사용하는 유니코드 인코딩 방식이다.^[73] UTF-32는 모든 문자의 코드 포인트를 직접 나타내기 때문에 다른 인코딩 방식에 비해 처리가 간편하다는 장점이 있다.

UTF-32는 프로그램 내부에서 텍스트를 표현하는 데 널리 사용된다. 예를 들어, GCC 컴파일러를 사용하는 모든 유닉스 운영 체제는 UTF-32를 표준 "와이드 문자" 인코딩으로 사용한다. Seed7과 같은 일부 프로그래밍 언어는 문자열과 문자의 내부 표현으로 UTF-32를 사용한다. 파이썬 프로그래밍 언어의 최신 버전(2.2부터)도 유니코드 문자열 표현에 UTF-32를 사용하도록 구성할 수 있다.

하지만 UTF-32는 각 문자를 표현하는 데 4바이트(32비트)가 필요하기 때문에 다른 인코딩 방식에 비해 더 많은 저장 공간을 필요로 한다는 단점이 있다.

5. 유니코드와 한국어

유니코드에서 한국어는 한글 음절 영역과 한글 자모 영역으로 나뉜다. 한글 음절 영역에는 현대 한글 11,172자가 모두 배당되어 있으며, 한글 자모 영역에는 한글 자모와 옛한글 자모가 배당되어 있다.

유니코드 2.0에서는 "한글 대이동"이 있었다. 이는 유니코드 1.1까지 정의되었던 한글 영역을 폐기하고, 새로운 한글 영역을 다른 위치에 설정하며, 폐기된 영역에는 다른 문자를 할당한 사건이다. 유니코드 3.0에서는 기존 한글이 할당되었던 영역에 CJK 통합 한자 확장 A가, 유니코드 4.0에서는 육십사괘가 할당되었다. 이 때문에 유니코드 1.1 이전에 한글을 기술한 문서와 유니코드 2.0 이후에 CJK 통합 한자 확장 A를 기술한 문서는 호환되지 않는다.^[420] JCS 위원장인 시바노 고지(芝野耕司)는 유니코드에 일본어 한자를 수록하는 논의에서 한글 대이동에 대해 "한국이 저지른 엉터리 행동"이라고 언급했다.^[420]

표의문자 연구 그룹(IRG)은 한자 통합(Unihan)과 관련하여, 특히 CJK 통합 및 호환 표의문자를 레퍼토리에 추가하는 것에 대해 유니코드 컨소시엄과 ISO에 자문하는 역할을 한다. IRG는 역사적으로 한자를 사용해 온 각 지역의 전문가들로 구성되어 있다. 그러나 위원회 내의 심의에도 불구하고, 한자 통합은 프로젝트 초기부터 ''유니코드 표준''에서 가장 논쟁이 많은 부분이었다.^[95]

JIS X 0208( Shift JIS로 인코딩됨)과 같은 기존 문자 집합 표준은 통합 기준, 즉 한자 변체가 필체/글꼴 차이로 간주되어 통합되어야 하는지, 아니면 철자 차이로 간주되어 별도로 인코딩되어야 하는지를 결정하는 규칙을 정의했다. 유니코드는 표준의 의미론적 변형 대신 스타일 변형을 인코딩하는 원칙 때문에 특정 희귀하고 고대의 한자 변체에 코드 포인트를 할당하지 않은 것에 대해 비판을 받았는데, 이는 고대 및 드문 일본식 이름의 처리를 복잡하게 만들 수 있다.^[96]

TRON 코드, CCCII 인코딩과 같이 덜 자주 사용되는 대안 인코딩도 존재한다.^[98]

유니코드 최초 버전에는 비교적 일반적인 현대 사용에 있는 문자로 대부분 제한된 2만 1000개 미만의 한자 레퍼토리가 있었다. 버전 16.0 기준으로 이 표준은 이제 9만 7000개가 넘는 한자를 인코딩하고 있으며, 동아시아 문화권 전역에서 사용되는 수천 개의 역사적 및 방언적 변형 문자를 추가하기 위한 작업이 계속되고 있다.

현대 글꼴은 다양한 지역적 그래픽 표현으로 통합된 한자를 묘사하는 데 있어 실질적인 문제 중 일부를 해결하는 수단을 제공한다. 'locl' 오픈타입 테이블을 통해 렌더러는 텍스트 로캘에 따라 각 코드 포인트에 대해 다른 글리프를 선택할 수 있다.^[99]

5. 1. 한글 처리

유니코드에서 한글은 한글 음절 영역과 한글 자모 영역에 나누어 배당되어 있다. 한글 음절 영역에는 현대 한글 11,172자가 모두 배당되어 있으며, 한글 자모 영역에는 한글 자모와 옛한글 자모가 배당되어 있다.

유니코드 2.0에서는 "한글 대이동"이 있었다. 이는 유니코드 1.1까지 정의되었던 한글 영역을 폐기하고, 새로운 한글 영역을 다른 위치에 설정하며, 폐기된 영역에는 다른 문자의 영역을 할당한 것이다. 유니코드 3.0에서는 기존 한글이 할당되었던 영역에 CJK 통합 한자 확장 A가, 유니코드 4.0에서는 육십사괘가 할당되었다. 이 때문에 유니코드 1.1 이전에 한글을 기술한 문서와 유니코드 2.0 이후에 CJK 통합 한자 확장 A를 기술한 문서는 호환되지 않는다.^[420] JCS 위원장인 시바노 고지(芝野耕司)는 유니코드에 일본어 한자를 수록하는 논의에서 한글 대이동에 대해 "한국이 저지른 엉터리 행동"이라고 언급했다.^[420]

5. 2. 한자 처리

표의문자 연구 그룹(IRG)은 한자 통합(Unihan)과 관련하여, 특히 CJK 통합 및 호환 표의문자를 레퍼토리에 추가하는 것에 대해 유니코드 컨소시엄과 ISO에 자문하는 역할을 한다. IRG는 역사적으로 한자를 사용해 온 각 지역의 전문가들로 구성되어 있다. 그러나 위원회 내의 심의에도 불구하고, 한자 통합은 프로젝트 초기부터 ''유니코드 표준''에서 가장 논쟁이 많은 측면 중 하나였다.^[95]

JIS X 0208( Shift JIS로 인코딩됨)과 같은 기존 문자 집합 표준은 통합 기준, 즉 한자 변체가 필체/글꼴 차이로 간주되어 통합되어야 하는지, 아니면 철자 차이로 간주되어 별도로 인코딩되어야 하는지를 결정하는 규칙을 정의했다. 유니코드의 CJK 문자에 대한 문자 모델은 JIS X 0208에서 사용된 통합 기준과 중국 공통 한자 코드 협회에서 개발한 기준을 기반으로 했다.^[96] 유니코드는 표준의 의미론적 변형 대신 스타일 변형을 인코딩하는 원칙 때문에 특정 희귀하고 고대의 한자 변체에 코드 포인트를 할당하지 않은 것에 대해 비판을 받았는데, 이는 고대 및 드문 일본식 이름의 처리를 복잡하게 만들 수 있다. 중국어, 일본어, 한국어가 공통적으로 많은 문자를 공유하는 데 특별한 중점을 두기 때문에 한자 통합은 때때로 이 세 가지를 동일한 것으로 취급하는 것으로 인식되기도 한다.^[97]

덜 자주 사용되는 대안 인코딩이 존재하며, 종종 유니코드보다 앞서 있다. 이들은 유니코드와 다른 문자 모델을 사용하여 지역 및/또는 비표준 문자 형태 간의 다양한 스타일 차이를 보존하는 것을 목표로 한다. 한 예로 일부 사용자가 역사적인 일본어 텍스트를 처리하기 위해 선호하지만 일본 대중 사이에서는 널리 채택되지 않은 TRON 코드가 있다. 또 다른 예로 홍콩, 타이완 및 미국의 도서관 시스템에서 채택된 CCCII 인코딩이 있다. 이러한 인코딩은 일반적인 사용에 있어 자체적인 단점이 있으며, 이로 인해 (CCCII 4년 후인 1984년에 도입된) Big5 인코딩이 도서관 시스템 외부에서는 CCCII보다 더 일반적으로 사용되게 되었다.^[98] 애플에서 연구 도서관 그룹의 CJK Thesaurus(CCCII의 EACC 변형을 유지하는 데 사용됨)를 기반으로 한 작업이 유니코드의 Unihan 집합의 직접적인 전신 중 하나였지만, 유니코드는 JIS 스타일 통합 모델을 채택했다.^[96]

유니코드의 최초 버전에는 비교적 일반적인 현대 사용에 있는 문자로 대부분 제한된 2만 1000개 미만의 한자 레퍼토리가 있었다. 버전 16.0 기준으로 이 표준은 이제 9만 7000개가 넘는 한자를 인코딩하고 있으며, 동아시아 문화권 전역에서 사용되는 수천 개의 역사적 및 방언적 변형 문자를 추가하기 위한 작업이 계속되고 있다.

현대 글꼴은 다양한 지역적 그래픽 표현으로 통합된 한자를 묘사하는 데 있어 실질적인 문제 중 일부를 해결하는 수단을 제공한다. 'locl' 오픈타입 테이블을 통해 렌더러는 텍스트 로캘에 따라 각 코드 포인트에 대해 다른 글리프를 선택할 수 있다.^[99] 유니코드 변형 시퀀스는 원하는 글리프 선택에 대한 텍스트 내 주석을 제공할 수도 있다. 이를 위해서는 표의문자 변형 데이터베이스에 특정 변형을 등록해야 한다.

6. 유니코드 목록

(BMP)다국어 보충 평면
(SMP)상형 문자 보충 평면
(SIP)상형 문자 제3 평면
(TIP)특수 목적 보충 평면
(SSP)

유니코드

1. 개요

더 읽어볼만한 페이지

2. 역사

2. 1. 유니코드 컨소시엄

2. 2. 버전

3. 유니코드 문자 부호화 모델

3. 1. 코드 공간(Codespace) 및 코드 포인트(Code points)

3. 2. 코드 평면(Code planes) 및 블록(Blocks)

3. 3. 일반 범주(General Category) 속성

3. 4. 결합 문자(Combining characters)

3. 5. 표준화된 부분 집합

4. 유니코드 변환 형식(UTF)과 국제 문자 세트(UCS)

4. 1. UTF-8

4. 2. UTF-16

4. 3. UTF-32

5. 유니코드와 한국어

5. 1. 한글 처리

5. 2. 한자 처리

6. 유니코드 목록

7. 문제점

7. 1. 문자 통합 문제

7. 1. 1. 한자 통합

7. 1. 2. 키릴 문자의 이탤릭체 또는 필기체 문자

7. 1. 3. 지역화된 대소문자 쌍

7. 1. 4. 소문자 {{serif|I}}의 발음 구별 부호

7. 2. 레거시 문자 집합으로의 매핑

7. 3. 인도 문자군

7. 4. 이상 현상(Anomalies)

참조