유니코드

Unicode
유니코드
유니코드 컨소시엄의 로고
별칭
언어스크립트 목록 참조
표준.유니코드 표준
인코딩 형식
(uncommon)
(obsolete)
선행후
이 문서에는 흔치 않은 유니코드 문자가 포함되어 있습니다. 적절한 렌더링 지원이 없으면 물음표, 상자 또는 기타 기호가 표시될 수 있습니다.

유니코드(Unicode), 공식적으로 유니코드 표준(Unicode Standard)[note 1]은 유니코드 컨소시엄(Unicode Consortium)이 세계의 모든 주요 필기 시스템에서 작성된 텍스트 사용을 지원하도록 설계된 텍스트 인코딩 표준입니다. 이[A] 표준의 버전 15.1은 일반적, 문학적, 학문적, 기술적 맥락에서 사용되는 149813개의[3] 문자와 161개의 스크립트를 정의합니다.

숫자, 구두점 및 기타 기호를 포함한 많은 일반적인 문자는 표준 내에서 통일되어 있으며 특정한 문자 시스템에 고유한 것으로 취급되지 않습니다. 유니코드는 수천 개의 이모지를 인코딩하고 있으며, 컨소시엄은 표준의 일부로 이모지를 계속 개발하고 있습니다.[4] 게다가 유니코드의 광범위한 채택은 일본 이외의 지역에서 이모지의 초기 대중화에 큰 책임이 있었습니다. 유니코드는 궁극적으로 110만 개 이상의 문자를 인코딩할 수 있습니다.

유니코드는 서로 다른 로케일과 서로 다른 컴퓨터 아키텍처에서 각각 사용되는 수많은 호환되지 않는 문자 집합의 이전 환경을 대체했습니다. 유니코드는 대부분의 웹 페이지를 포함하여 인터넷 상의 텍스트의 대부분을 인코딩하는 데 사용되며, 관련 유니코드 지원은 현대 소프트웨어 개발에서 일반적인 고려 사항이 되었습니다.

유니코드 문자 레퍼토리는 ISO/IEC 10646과 동기화되며, 각각 코드 포 코드가 동일합니다. 그러나 유니코드 표준은 단순히 문자가 할당되는 레퍼토리 이상입니다. 개발자와 설계자를 돕기 위해 이 표준은 차트와 참조 데이터뿐만 아니라 다양한 스크립트에 적용 가능한 개념을 설명하는 부록을 제공하여 구현에 대한 지침을 제공합니다. 이러한 부속서에서 다루는 주제에는 문자 정규화, 문자 구성 및 분해, 대조 및 방향성이 포함됩니다.[5]

유니코드 텍스트는 문자에 대한 표준의 추상화된 코드를 바이트 시퀀스로 변환하는 방법을 정의하는 여러 인코딩 중 하나를 사용하여 이진 데이터로 처리되고 저장됩니다. 유니코드 표준은 자체적으로 UTF-8, UTF-16, UTF-32의 세 가지 인코딩을 정의하지만, 다른 여러 인코딩이 존재합니다. 이 중 UTF-8은 부분적으로 ASCII와의 역호환성 때문에 큰 마진에 의해 가장 널리 사용됩니다.

기원 및 개발

유니코드는 원래 그 시점까지 설계된 모든 텍스트 인코딩에 존재하는 제한을 뛰어넘기 위한 목적으로 설계되었습니다: 각 인코딩은 고유한 컨텍스트에서 사용하기 위해 의존했지만 다른 인코딩과의 호환성에 대한 특별한 기대는 없었습니다. 실제로 선택된 두 인코딩은 함께 사용할 때 완전히 작동하지 않는 경우가 많았고, 하나는 텍스트를 다른 하나는 가비지 문자로 해석했습니다. 대부분의 인코딩은 소수의 스크립트(주로 주어진 스크립트와 라틴 문자 사이) 간의 상호 운용을 용이하게 하도록 설계되었을 뿐, 지원되는 모든 스크립트가 일관된 방식으로 처리되지는 않았습니다.

유니코드의 기반이 되는 철학은 그래픽 구분이 아닌 기본 문자인 문법과 자소 같은 단위를 인코딩하려고 합니다. 이 문자들은 서체나 마크업을 사용하거나 다른 방법으로 가장 잘 처리됩니다. 한 문자의 직교 변형 처리와 같은 특히 복잡한 경우에는 어떤 차이가 자신의 인코딩을 정당화하고 다른 문자의 그래픽 변형에 불과한지에 대해 상당한 의견 차이가 있습니다.

가장 추상적인 수준에서 유니코드는 각 문자에 코드 포인트라는 고유 번호를 할당합니다. 크기, 모양 및 스타일을 포함한 시각적 표현의 많은 문제는 웹 브라우저 또는 워드 프로세서와 같이 실제로 텍스트를 렌더링하는 소프트웨어의 재량에 달려 있습니다. 그러나 부분적으로 신속한 채택을 장려하기 위한 의도로 이 원래 모델의 단순성은 시간이 지남에 따라 다소 정교해졌으며 표준 개발 과정에서 다양한 실용적인 양보가 이루어졌습니다.

처음 256개의 코드 포인트는 ISO/IEC 8859-1 표준을 반영하며, 서유럽 스크립트에서 이미 작성된 텍스트 변환을 사소한 것으로 만들 의도입니다. 다양한 레거시 인코딩에 의한 구별을 유지하기 위해, 따라서 정보의 손실 없이 유니코드와 다른 인코딩 간의 변환을 허용하기 위해, 외관 및 의도된 기능 모두에서 다른 것과 거의 동일한 많은 문자에 고유한 코드 포인트가 부여되었습니다. 예를 들어, 하프폭과 풀폭 폼 블록은 라틴 알파벳의 전체 의미 복제를 포함합니다. 레거시 CJK 인코딩에는 "풀폭"(CJK 문자의 너비와 일치)과 "하프폭"(일반 라틴 문자와 일치) 문자가 모두 포함되어 있기 때문입니다.

유니코드 불독상(Unicode Bulldog Award)은 유니코드 개발에 영향력이 있다고 판단되는 사람들에게 수여되며, 수상자로는 고바야시 타츠오, 토마스 마일로, 루즈베 푸르나더, 켄 런드, 마이클 에버슨 등이 있습니다.[6]

역사

유니코드의 기원은 1980년대 제록스의 문자 코드 표준(XCCS)에 연결된 개인 그룹으로 거슬러 올라갈 수 있습니다.[7] 1987년, 제록스의 직원 조 베커(Joe Becker)는 애플의 직원 리 콜린스(Lee Collins)와 마크 데이비스(Mark Davis)와 함께 보편적인 캐릭터 세트를 만드는 실용성을 조사하기 시작했습니다.[8] 피터 펜윅(Peter Fenwick)과 데이브 옵스타드(Dave Opstad)의 추가적인 의견으로 [7]베커(Becker)는 1988년 8월 "국제/다언어 텍스트 문자 인코딩 시스템, 가칭 유니코드(Unicode)"에 대한 제안 초안을 출판했습니다. 그는 "'유니코드'라는 이름은 독특하고 통일된 보편적인 인코딩을 제안하기 위한 것"이라고 설명했습니다.[7]

Unicode 88이라는 제목의 이 문서에서 Becker는 16비트 문자를 사용하는 방식의 개요를 설명했습니다.[7]

유니코드는 작동 가능하고 신뢰할 수 있는 세계 텍스트 인코딩의 필요성을 해결하기 위한 것입니다. 유니코드는 대략적으로 "광체 아스키"로 묘사될 수 있으며, 이는 전 세계 모든 살아있는 언어의 문자를 포괄하기 위해 16비트로 확장되었습니다. 적절하게 설계된 설계에서 문자당 16비트는 이 목적에 충분합니다.

이 설계 결정은 '현대적'인 사용에서 스크립트와 문자만 인코딩이 필요하다는 가정에 기초하여 이루어졌습니다.[7]

유니코드는 과거 유물을 보존하는 것보다 미래를 위한 효용을 보장하는 것에 더 높은 우선순위를 부여합니다. 유니코드는 첫 번째로 현대 텍스트에 출판된 문자(예: 1988년 세계에서 인쇄된 모든 신문과 잡지의 연합)를 목표로 하며, 그 숫자는 의심할 여지 없이 2 = 16,384에 훨씬 못 미칩니다. 이러한 현대적인 사용 문자 외에 다른 모든 문자는 더 이상 쓸모가 없거나 드문 것으로 정의될 수 있습니다. 이 문자들은 일반적으로 유용한 유니코드의 공개 목록을 혼잡하게 만드는 것보다 개인적인 사용 등록을 위한 더 나은 후보입니다.

1989년 초 유니코드 작업 그룹은 메타포의 켄 휘슬러와 마이크 커너핸, 리서치 라이브러리 그룹의 카렌 스미스-요시무라와 조안 알리프랜드, 썬 마이크로시스템즈의 글렌 라이트로 확장되었습니다. 1990년 마이크로소프트사의 미셸 수이가드와 아스무스 프레이태그, NeXT사의 릭 맥고완도 이 그룹에 합류했습니다. 1990년 말에는 기존 표준을 다시 매핑하는 작업이 대부분 완료되었으며 유니코드의 최종 검토 초안이 준비되었습니다.

유니코드 컨소시엄은 1991년 1월 3일 캘리포니아에 통합되었고,[9] 그 해 10월에 유니코드 표준 제1권이 출판되었습니다. 현재 한 권이 추가된 두 번째 권은 1992년 6월에 출판되었습니다.

1996년에는 유니코드 2.0에 대리 문자 메커니즘이 구현되어 유니코드가 더 이상 16비트로 제한되지 않았습니다. 이것은 유니코드 코드 공간을 백만 개 이상의 코드 포인트로 늘렸고, 이것은 이집트 상형문자와 같은 많은 역사적인 문자들과 표준에 포함될 것으로 예상되지 않았던 수천 개의 거의 사용되지 않거나 쓸모없는 문자들을 인코딩할 수 있게 했습니다. 이러한 문자 중에는 드물게 사용되는 다양한 CJK 문자가 포함되어 있는데, 이 중 많은 문자가 주로 고유 이름에 사용되기 때문에 원래 유니코드 아키텍처가 구상하는 것보다 범용 인코딩에 훨씬 더 필요합니다.[10]

1992년에 발표된 마이크로소프트의 TrueType 사양 버전 1.0은 명명표의 플랫폼 ID에 대해 '유니코드' 대신 '애플 유니코드'라는 이름을 사용했습니다.

유니코드 컨소시엄

주요 기사: 유니코드 컨소시엄

유니코드 컨소시엄은 유니코드의 개발을 조정하는 비영리 단체입니다. Adobe, Apple, Google, IBM, Meta(이전 Facebook), Microsoft, Netflix 및 SAP 등 텍스트 처리 표준에 관심이 있는 주요 컴퓨터 소프트웨어 및 하드웨어 회사 대부분(및 기타 소수)이 정회원으로 가입되어 있습니다.[11]

몇 년 동안 여러 국가 또는 정부 기관이 유니코드 컨소시엄의 회원이 되었습니다. 현재 투표권을 가진 정회원은 오직 기부와 종교부(Oman)뿐입니다.[11]

컨소시엄은 기존의 많은 방식들이 크기와 범위가 제한적이고 다국어 환경과 호환되지 않기 때문에 결국 기존의 문자 인코딩 방식을 유니코드와 표준 유니코드 변환 형식(UTF) 방식으로 대체하겠다는 야심찬 목표를 가지고 있습니다.

대상이 되는 스크립트

주요 기사: 스크립트(유니코드)
많은 최신 애플리케이션은 OpenOffice.org 애플리케이션의 이 스크린샷에서 알 수 있듯이 많은 스크립트 중 상당한 부분을 유니코드로 렌더링할 수 있습니다.

유니코드는 현재 사용 중인 대부분의 주요 쓰기 시스템을 다룹니다.[12][better source needed]

2024년 현재 총 161개의 스크립트가[13] 유니코드의 최신 버전(알파벳, 아부기다 및 강의 계획서 포함)에 포함되어 있지만, 아직 인코딩되지 않은 스크립트, 특히 역사적, 전례적, 학문적 맥락에서 주로 사용되는 스크립트가 있습니다. 이미 인코딩된 스크립트에 문자와 기호, 특히 수학과 음악(음표와 리듬 기호의 형태)에 대한 기호의 추가도 발생합니다.

유니코드 로드맵 위원회(Michael Everson, Rick McGowan, Ken Whistler, V.S. Umamaheswaran)[14]는 유니코드 컨소시엄 웹사이트의 유니코드 로드맵[15] 페이지에서 인코딩 후보 또는 잠재적인 후보인 스크립트 목록과 이들의 잠정 코드 블록 할당을 유지합니다. Jurchen 및 Khitan 대형 스크립트와 같은 Roadmap 상의 일부 스크립트에 대해서는 인코딩 제안이 이루어졌으며 승인 절차를 거치고 있습니다. 마야(숫자 외에도)나 롱고롱고(Rongorongo)와 같은 다른 스크립트의 경우 아직 제안이 이루어지지 않았으며, 캐릭터 레퍼토리 및 기타 세부 사항에 대한 사용자 커뮤니티의 합의를 기다리고 있습니다.

아직 유니코드에 포함되지 않았거나 실제 사용이 부족하여 유니코드에 포함될 자격이 없는 일부 현대적으로 발명된 스크립트(예: Tengwar)는 비공식적이지만 널리 사용되는 개인 사용 영역 코드 할당과 함께 콘스크립트 유니코드 레지스트리에 나열됩니다.

라틴 중세 특수 문자에 초점을 맞춘 중세 유니코드 폰트 이니셔티브도 있습니다. 이러한 제안 중 일부는 이미 유니코드에 포함되어 있습니다.

스크립트 인코딩 이니셔티브

캘리포니아 대학교 버클리에서 데보라 앤더슨(Deborah Anderson)이 운영하는 스크립트 인코딩 이니셔티브([16]Script Encoding Initiative)는 아직 표준에 인코딩되지 않은 스크립트에 대한 제안 자금을 지원하기 위해 2002년에 설립되었습니다. 이 프로젝트는 최근 몇 년 동안 표준에 대한 추가 제안의 주요 소스가 되었습니다.[17]

버전

유니코드 컨소시엄은 ISO와 함께 유니코드 표준의 첫 출판 이후 공유 레퍼토리를 개발했습니다. 유니코드와 ISO의 UCS(Universal Coded Character Set)는 동일한 문자 이름과 코드 포인트를 사용합니다. 그러나 유니코드 버전은 ISO 버전과 두 가지 중요한 점에서 다릅니다.

UCS는 간단한 문자 맵이지만 유니코드는 서로 다른 플랫폼과 언어 간의 상호 운용성을 달성하는 데 필요한 규칙, 알고리즘 및 속성을 지정합니다. 따라서 유니코드 표준에는 비트 단위 인코딩, 대조 및 렌더링과 같은 심층적인 주제를 다루는 더 많은 정보가 포함되어 있습니다. 또한 양방향 텍스트를 지원하는 데 필요한 문자 속성과 구현자를 돕기 위한 시각적 차트 및 참조 데이터 세트를 포함한 포괄적인 문자 속성 카탈로그를 제공합니다. 이전에 유니코드 표준은 완전한 핵심 사양, 표준 부속서 [note 2]및 코드 차트를 포함하는 인쇄 볼륨으로 판매되었습니다. 그러나 2006년에 출판된 버전 5.0이 이러한 방식으로 인쇄된 마지막 버전이었습니다. 버전 5.2부터는 주문형 인쇄 용지백으로 발행되는 핵심 사양만 구입할 수 있습니다.[18] 반면 전문은 유니코드 웹사이트에 무료 PDF로 공개됩니다.

이 게시 방법의 실질적인 이유는 UCS와 유니코드 간의 두 번째 중요한 차이점(업데이트된 버전이 출시되고 새 문자가 추가되는 빈도)을 강조합니다. 유니코드 표준은 정기적으로 연간 확장 버전을 출시해 왔으며, 때때로 달력 연도에 하나 이상의 버전이 출시되고 예정된 출시가 연기되어야 하는 드문 경우가 있습니다. 예를 들어, 버전 13.0이 발표된 지 한 달 후인 2020년 4월, 유니코드 컨소시엄은 버전 14.0의 출시 예정일을 변경했다고 발표하여 COVID-19 팬데믹으로 인해 6개월 뒤인 2021년 9월로 연기했습니다.

최신 버전인 유니코드 15.1은 2023년 9월 12일에 출시되었습니다. 2022년 9월 13일에 출시된 버전 15.0의 마이너 버전 업데이트로, 두 개의 새로운 스크립트, CJK Unified Ideographes 블록 확장, 기존 블록에 여러 개의 추가된 여러 개의 새로운 문자를 포함하여 총 4,489개의 새로운 문자가 추가되었습니다. 'wireless'(네트워크) 심벌과 색심벌 등 33개의 이모지가 새롭게 추가됐습니다.

지금까지 다음과 같은 버전의 유니코드 표준이 출판되었습니다. 캐릭터 레퍼토리의 변경 사항이 포함되지 않은 업데이트 버전은 세 번째 숫자(예: "버전 4.0.1")로 표시되며 아래 표에서 생략됩니다.[21]

유니코드 버전 기록 및 문자 및 스크립트의 주목할 만한 변경 사항
버전 날짜. 책 UCS판 총 세부 사항
스크립트 문자[a]
1.0.0[22] 1991년10월 ISBN 0-201-56788-1
(1권)
 — 24 7129 대상 초기 스크립트: Arabic, Armenian, Bengali, Bopomofo, Cyrillic, Devanagari, Georgian, Greek and Coptic, Gujarati, Gurmukhi, Hangul, Hebrew, Hiragana, Kannada, Katakana, Lao, Latin, Malayalam, Odia, Tamil, Telugu, Thai, and Tibetan
1.0.1[23] 1992년 6월 ISBN 0-201-60845-6
(2권)
 25 28327+21204
−6 		초기 20,902 CJK 통합 아이디어
1.1[24] 1993년6월 — ISO/IEC 10646-1:1993

[b]

24 34168+5963
−9 		제어문자로 재분류한 33개 한글 음절 4,306개, 티베트어 제거
2.0[25] 1996년7월 ISBN 0-201-48345-9 25 38885+11373
−6656 		원래의 한글 음절 세트를 제거하고 새로운 위치에 11,172개의 한글 음절 세트를 추가했으며 티베트어는 새로운 위치에 다시 추가했으며 다른 문자 레퍼토리를 사용하여 대리 문자 메커니즘을 정의하고 평면 15 및 평면 16 사적 용도 영역을 할당했습니다.
2.1[26] 1998년 5월 — 38887+2
 		U+20AC € EURO 사인, U+FFFC  개체 교체 문자
3.0[27] 1999년9월 ISBN 0-201-61633-5 ISO/IEC 10646-1:2000 38 49194+10307
 		체로키, 게 ʽ, 크메르, 몽골, 버마, 오함, 룬, 신할라, 시리아어, 타아나, 캐나다 원주민 음절, 점자 패턴
3.1[28] 2001년3월 — ISO/IEC 10646-1:2000[c]
ISO/IEC 10646-2:2001 		41 94140+44946
 		사막, 고딕 및 고대 이탈리아어, 서양 및 비잔틴 음악을 위한 상징 세트, 42,711개 CJK Unified Ideographes 추가
3.2[29] 2002년3월 45 95156+1016
 		필리핀 문자(부히드, 하누누, 타갈로그어, 타갈반와)
4.0[30] 2003년4월 ISBN 0-321-18578-1 ISO/IEC 10646:2003

[d]

52 96382+1226
 		키프로스어 음절, 림부, 선형 B, 오스만야, 샤비안, 타이 르, 우가리트어, 헥사그램 기호
4.1[31] 2005년3월 — 59 97655+1273
 		부기네세, 글라골틱, 카로스티, 뉴타이루, 올드 페르시아어, 실헤티 나그리, 티피나그, 그리스어와 통일되지 않은 콥트어, 고대 그리스 숫자와 음악 기호가 처음으로 명명된 문자 시퀀스가 소개되었습니다.[32]
5.0 2006년7월 ISBN 0-321-48091-0 64 99024+1369
 		발리어, 설형어, N'Ko, ʼ 파그스파, 페니키아어
5.1[34] 2008년4월 — 75 100648+1624
 		Carian, Cham, Kayah Li, Lepcha, Lychian, Lydian, Ol Chiki, Rejang, Saurashtra, Sundanese 및 Vai, Paistos 디스크 기호 세트, Mahjong 타일, Domino 타일, 버마어 추가, Scribal 약어, U+1E9E ß 라틴 대문자 샤프 S
5.2[35] 2009년10월 ISBN 978-1-936213-00-9 90 107296+6648
 		아베스탄, 바뭄, 가디너의 이집트 상형문자 기호 목록, 제국 아람어, 비문 팔라비, 비문 파르티아어, 자바어, 카이티, 리수, 미테이 마예크, 구남아라비아어, 구튀르크어, 사마리아어, 타이탐어, 타이비엣, 기타 CJK 통일 이데아그래프, 구한글용 자모, 베다 산스크리트어
6.0[36] 2010년10월 ISBN 978-1-936213-01-6 ISO/IEC 10646:2010

[e]

93 109384+2088
 		바탁, 브라흐미, 만다이크, 플레잉 카드 기호, 운송 및 지도 기호, 연금술 기호, 이모티콘 및 이모지 추가[37] CJK 통합 아이디그래프
6.1[38] 2012년1월 ISBN 978-1-936213-02-3 ISO/IEC 10646:2012

[f]

100 110116+732
 		Chakma, Meroitic 필기체, Meroitic 상형문자, Miao, Sharada, Sora Sompeng, Takri
6.2[39] 2012년9월 ISBN 978-1-936213-07-8 110117+1
 		U+20BA ₺ 터키 리라 사인
6.3[40] 2013년9월 ISBN 978-1-936213-08-5 110122+5
 		5개의 양방향 포맷 문자
7.0[41] 2014년6월 ISBN 978-1-936213-09-2 123 112956+2834
 		Bassa Vah, Caucasian Albanian, Duployan, Elbasan, Grantha, Khojki, Khudawadi, Linear A, Mahajani, Manichaean, Mende Kikakui, Modi, Mro, Nabataean, Old North Arabian, Old Permic, Pahawh Hmong, Palmyrene, Pau Cin Hau, Psalter Pahlavi, Siddham, Tirhuta, Warang Citi, and dingbats
8.0[42] 2015년6월 ISBN 978-1-936213-10-8 ISO/IEC 10646:2014

[g]

129 120672+7716
 		아옴, 아나톨리아 상형문자, 하트란, 물타니, 올드 헝가리어, 사인라이팅, 추가 CJK Unified Ideographes, 체로키용 소문자, 이모지 피부톤 수식어 5개
9.0[45] 2016년6월 ISBN 978-1-936213-13-9 135 128172+7500
 		아들람, 백수키, 마르첸, 뉴아, 오사지, 탕굿, 72 이모지[46]
10.0[47] 2017년6월 ISBN 978-1-936213-16-0 ISO/IEC 10646:2017

[h]

139 136690+8518
 		자나바자르 광장, 소욤보, 마사람 곤디, 누슈, 헨타이가나, 7,494 CJK 통일이데그래프, 56 이모지, 비트코인 심볼
11.0[48] 2018년6월 ISBN 978-1-936213-19-1 146 137374+684
 		도그라, 그루지야어 음타브룰리 대문자, 군잘라 곤디, 하니피 로힝야어, 인디시야크 숫자, 마카사르, 메데파이드린, 올드 소그디안 및 소그디안, 마야 숫자, 5 CJK 통합 이데아그래프, 샹치 및 별 등급 기호, 145 이모지
12.0[49] 2019년3월 ISBN 978-1-936213-22-1 150 137928+554
 		Elymaic, Nandinagari, Nyiakeng Puachue Hmong, Wancho, Miao 문자, Hiragana 및 Katakana 작은 글자, 타밀 역사적 분수 및 기호, Pali를 위한 라오스 문자, 이집트학 및 우간다어 번역을 위한 라틴 문자, 상형문자 형식 제어, 61 이모지
12.1[50] 2019년 5월 ISBN 978-1-936213-25-2 137929+1
 		U+32FF ㋿ SQUARE ARA NAME REIWA
13.0[51] 2020년3월 ISBN 978-1-936213-26-9 ISO/IEC 10646:2020

[52]

154 143859+5930
 		Chorasmian, Dhives Akuru, Khitan 소문자, Yeszidi, 4,969 CJK 이데아그래프, Hausa, Wolof, 기타 아프리카 언어를 쓰기 위해 사용된 아랍 문자 추가, 파키스탄 힌드코와 펀자브를 쓰기 위해 사용된 추가, 광둥어에 사용된 Bopomofo 추가, Creative Commons 라이선스 심볼, 문자 및 가정용 컴퓨터 시스템과 호환되는 그래픽 문자, 55 이모지
14.0[53] 2021년9월 ISBN 978-1-936213-29-0 159 144697+838
 		Toto, Cypro-Minoan, Vithkuqi, Old Uyghur, Tangsa, 확장 IPA, 아프리카 및 이란, 파키스탄, 말레이시아, 인도네시아, 자바 및 보스니아 언어에서 사용할 아랍어 스크립트 추가, 존칭 및 코란어 사용 추가, 북미, 필리핀, 인도 및 몽골 언어 지원 추가, U+20C0 ⃀ SOM SIGN, 즈나메니 음악 표기법, 37 이모지
15.0[54] 2022년9월 ISBN 978-1-936213-32-0 161 149186+4489
 		카위와 문다리, 이모지 20개, CJK 아이디지 4,192개, 이집트 상형문자 제어 문자
15.1[55] 2023년9월 ISBN 978-1-936213-33-7 149813+627
 		CJK 추가 아이디얼
  1. ^ 개인용 문자, 제어 문자, 비문자 및 대리 코드 포인트를 제외한 그래픽 및 형식 문자의 총 수).
  2. ^
    • 2.0 수정안 5, 6, 7이 추가되었습니다.
    • 2.1은 수정안 18에서 두 개의 문자를 추가했습니다.
  3. ^ 3.2 수정안 1이 추가되었습니다.
  4. ^
    • 4.1 수정안 1 추가
    • 5.0 수정헌법 2조 및 수정헌법 3조의 4자 추가
    • 5.1 수정안 4 추가
    • 5.2 추가된 수정안 5 및 6
  5. ^ 거기다 인도 루피 사인까지.
  6. ^
  7. ^ 아울러 개정안 1, 라리표지판, CJK 통일이데올로기 9점, 이모지 41점,[43]
    9.0은 수정안 2와 더불어 Adlam, Newa, 일본 TV 심볼, 74개의 이모지 및 심볼을 추가했습니다.[44]
  8. ^
    • 추가로 이모티콘 56개, 헨타이가나 285개, 자나바자르 광장 3개
    • 11.0 Mtavruli Georgian 대문자 46개, CJK 통일 아이디어 5개, 이모지 66개 추가
    • 12.0은 62자를 추가했습니다.

예상 버전

유니코드 컨소시엄(Unicode Consortium)은 일반적으로 1년에 한 번, 또는 가끔 1년에 두 번 새로운 버전의 유니코드 표준(The Unicode Standard)을 출시합니다. 다음 주요 버전인 버전 16.0은 2024년에 출판될 예정이며, 6개의 새로운 스크립트(Todhri, Sunuwar, Gurung Khema, Kirat Rai, Garay 및 Ol Onal), 샨 및 몬 알파벳을 위한 추가 버마 숫자, 레거시 컴퓨팅을 위한 추가 기호 및 최소 6개의 새로운 이모티콘이 포함될 것으로 예상됩니다.[56][57]

건축과 용어

참고 항목: 범용 문자 집합 문자

코드스페이스 및 코드포인트

유니코드 표준은 코드 공간을 정의합니다 [ × 2 간격을 포함하는 코드 포인트라고[59] 하는 정수의 시퀀스를U+0000으로 표시합니다.U+10FFFF.[60] 코드스페이스는 유니코드 표준의 체계적이고 아키텍처에 독립적인 표현이며, 실제 텍스트는 UTF-8과 같은 여러 유니코드 인코딩 중 하나를 통해 이진 데이터로 처리됩니다.[a]

이 표준 표기법에서 두 문자 접두사는 U+ 코드 포인트는 항상 작성된 코드 포인트 앞에 나타나며 [61]코드 포인트 자체는 16진수로 작성됩니다. 필요에 따라 선두 0이 앞에 붙는 16진수 숫자는 항상 4개 이상 작성됩니다. 예를 들어 코드 포인트 U+00F7 ÷ DIVISION SIGN은 선두 0 두 개로 패딩되지만 U+13254 𓉔 이집트 상형문자 O004()는 패딩되지 않습니다.

코드 공간 내에는 총 (2 - 2 + 2 =) 1112064개의 유효한 코드 포인트가 있습니다. (이 숫자는 UTF-16 문자 인코딩의 한계로 인해 발생하며, U+D800 ~ U+DFFF 범위의 2개11 코드 포인트를 제외한 U+0000 ~ U+FFF 범위의 2개16 코드 포인트를 인코딩할 수 있으며, 이는 U+10000 ~ U+10FFF 범위의 2개20 코드 포인트를 인코딩하기 위한 대리 쌍으로 사용됩니다.)

  1. ^ UTF 인코딩의 작동 방식에 대한 설명은 #매핑 및 인코딩을 참조하십시오.

코드 평면 및 블록

본문: 평면(유니코드)

유니코드 코드 공간은 0~16번으로 17개의 평면으로 나뉩니다. 평면 0은 기본 다국어 평면(BMP)이며, 가장 일반적으로 사용되는 문자를 포함합니다. UTF-16 인코딩에서 BMP의 모든 코드 포인트는 단일 코드 유닛으로 액세스되며, UTF-8에서는 1바이트, 2바이트 또는 3바이트로 인코딩될 수 있습니다. 평면 1~16(보충 평면)의 코드 포인트는 UTF-16에서 대리 쌍으로 액세스되며, UTF-8에서는 4바이트로 인코딩됩니다.

각 평면 내에서 문자는 관련 문자의 명명된 블록 내에 할당됩니다. 블록의 크기는 항상 16의 배수이며, 128의 배수인 경우가 많지만, 그렇지 않으면 임의적입니다. 주어진 스크립트에 필요한 문자는 코드 공간 내에서 서로 다른 잠재적으로 분리된 여러 블록에 걸쳐 분산될 수 있습니다.

일반 범주 속성

각 코드 포인트에는 코드 포인트의 General Category 속성으로 나열된 분류가 할당됩니다. 여기서 최상위 레벨의 코드 포인트는 문자, 표시, 숫자, 문장부호, 기호, 구분자 또는 기타 중 하나로 분류됩니다. 각 범주 아래에서 각 코드 포인트는 추가 하위 범주로 분류됩니다. 대부분의 경우 주어진 코드 포인트의 모든 특성을 적절하게 설명하기 위해 다른 속성을 사용해야 합니다.

일반 카테고리 (유니코드 문자 속성)[a]
가치 카테고리메이저,미성년 기본형[b] 부여된[b] 문자 카운트[c]
(15.1 기준)		 언급
L, L, LC, 대문자(Lu, Ll, Lt만 해당)[d]
루 문자, 대문자 그래픽 성격 1,831
Ll 글자, 소문자 그래픽 성격 2,233
Lt 레터,타이틀케이스 그래픽 성격 31 대문자 다음에 소문자 부분(예: dž, lj, nj 및 dz)이 포함된 라이그처 또는 다이그래프
Lm 문자, 수식어 그래픽 성격 397 수식어 글자
로 편지, 기타 그래픽 성격 132,234 유니케이스 알파벳으로 된 아이디그래프 또는 문자
M, 마크
Mn 표식, 띄어쓰기 안 함 그래픽 성격 1,985
맥 표시, 간격 결합 그래픽 성격 452
나야. 마크, 감싸기 그래픽 성격 13
N, 번호
Nd 숫자, 십진자리 그래픽 성격 680 이것들과 이것들만 숫자 유형 = De를 갖습니다.
Nl 번호, 문자 그래픽 성격 236 문자 또는 문자와 같은 기호로 구성된 숫자(예: 로마 숫자)
아니요. 번호, 기타 그래픽 성격 915 예: 저속 분수, 위첨자 및 아래첨자 숫자
P, 구두점
Pc 구두점, 커넥터 그래픽 성격 10 공백 밑줄 문자(예: "_") 및 기타 공백 연결 문자가 포함됩니다. 다른 문장부호 문자와 달리 정규 표현 라이브러리에서는 "단어" 문자로 분류할 수 있습니다.[f]
PD 구두점, 대시 그래픽 성격 26 여러 하이픈 문자 포함
Ps 구두점, 오픈 그래픽 성격 79 괄호 열기 문자
페 구두점, 닫기 그래픽 성격 77 괄호 닫기 문자
파이 문장부호, 초성사 그래픽 성격 12 따옴표를 엽니다. ASCII "중립" 따옴표를 포함하지 않습니다. 용도에 따라 Ps 또는 Pe처럼 동작할 수 있음
Pf 구두점, 최종견적 그래픽 성격 10 따옴표 마감중입니다. 용도에 따라 Ps 또는 Pe처럼 동작할 수 있음
포 구두점, 기타 그래픽 성격 628
S, 기호
에스엠 기호,수학 그래픽 성격 948 수학 기호(예: +, -, =, ×, ÷, √, ≠, ∊). 범주 Ps 및 Pe에 포함된 괄호 및 괄호는 포함되지 않습니다. 또한 수학 연산자로 자주 사용됨에도 불구하고 주로 "문구"로 간주되는 !, *, - 또는 /를 포함하지 않습니다.
Sc 기호, 화폐 그래픽 성격 63 화폐 기호
에스케이 기호, 수식어 그래픽 성격 125
그렇게 기호, 기타 그래픽 성격 6,639
Z, 구분자
Zs 구분자, 공간 그래픽 성격 17 공간을 포함하지만 Cc인 TAB, CR 또는 LF는 포함하지 않습니다.
Zl 구분자, 선 형식 성격 1 U+2028 라인 분리기(LSEP)만 해당
Zp 구분자, 단락 형식 성격 1 U+2029 문단 구분자(PSEP)만 해당
C, 기타
Cc 기타, 제어 통제 성격 65 (결코 변하지 않음)[e] 이름 없음,[g] <control>
Cf 기타, 형식 형식 성격 170 소프트 하이픈, 합류 제어 문자(ZWNJ 및 ZWJ), 양방향 텍스트를 지원하는 제어 문자 및 언어 태그 문자 포함
Cs 기타 대리인 대리인 없음(UTF-16에만 사용됨) 2,048(결코 변경되지 않음)[e] 이름 없음,[g] <대리인>
코 기타사용 개인용 문자(단, 해석이 지정되지 않음) 총 137,468개([e]결코 변경되지 않음)(BMP의 경우 6,400개, 플레인 15-16의 경우 131,068개) 이름 없음,[g] <private-use>
Cn 기타, 미할당 비문자 것은 아니다. 66 (유니코드 코드 포인트의 범위를 확장하지 않는 한 변경되지 않음)[e] 이름 없음,[g] <비문자>
예약한 것은 아니다. 824,652 이름 없음,[g] <예약>
  1. ^ "Table 4-4: General Category" (PDF). The Unicode Standard. Unicode Consortium. September 2022.
  2. ^ a b "Table 2-3: Types of code points" (PDF). The Unicode Standard. Unicode Consortium. September 2022.
  3. ^ "DerivedGeneralCategory.txt". The Unicode Consortium. 2022-04-26.
  4. ^ "5.7.1 General Category Values". UTR #44: Unicode Character Database. Unicode Consortium. 2020-03-04.
  5. ^ a b c d e 유니코드 문자 인코딩 안정성 정책: 속성 값 안정성 정책: 일부 gc 그룹은 절대 변경되지 않습니다. gc=Nd는 숫자 Type=De(decimal)에 해당합니다.
  6. ^ "Annex C: Compatibility Properties (§ word)". Unicode Regular Expressions. Version 23. Unicode Consortium. 2022-02-08. Unicode Technical Standard #18.
  7. ^ a b c d e "Table 4-9: Construction of Code Point Labels" (PDF). The Unicode Standard. Unicode Consortium. September 2022. 코드 포인트 레이블은 이름이 없는 코드 포인트를 식별하는 데 사용될 수 있습니다. 예를 들어, <control-hhhh>, <control-0088>. Name(이름)은 공백으로 남아 있어 문서에서 Control Name(제어 이름)을 실수로 실제 Control 코드로 교체하는 것을 방지할 수 있습니다. 유니코드는 또한 <noncharacter>에 <not a character>를 사용합니다.

U+D800–U+DBFF 범위의 1024개 지점은 상위 대리 코드 지점으로 알려져 있고, U+DC00–U+DFFF 범위의 코드 지점(1024개 코드 지점)은 하위 대리 코드 지점으로 알려져 있습니다. UTF-16에서는 U+FFFFF보다 큰 코드 포인트를 나타내기 위해 높은 대리 코드 포인트 다음에 낮은 대리 코드 포인트가 대리 쌍을 형성합니다. 원칙적으로 이러한 코드 포인트는 달리 사용할 수 없지만, 실제로는 특히 UTF-16을 사용하지 않을 때 이 규칙이 종종 무시됩니다.

작은 코드 포인트 세트는 문자에 할당되지 않도록 보장되지만, 제3자가 재량에 따라 문자를 독립적으로 사용할 수 있습니다. 다음과 같은 비문자는 66개입니다. U+FDD0–U+FDEF 및 표현이 끝나는 임의의 코드 포인트 FFFE 또는 FFFF (e.g. U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U+10FFFE etc.). 비문자 집합은 안정적이며 새로운 비문자는 정의되지 않습니다.[63] 대리인과 마찬가지로 이러한 규칙을 사용할 수 없다는 규칙은 종종 무시되지만, 바이트 순서 표시의 작동은 U+FFE가 텍스트의 첫 번째 코드 포인트가 될 수 없다고 가정합니다. 대리 및 비문자를 제외하면 1111998 코드 포인트를 사용할 수 있습니다.

개인용 코드 포인트는 할당된 것으로 간주되지만, 이러한 코드 포인트의 상호 교환은 송신자와 수신자 간의 해석에 대한 독립적인 합의가 필요하므로 유니코드 표준에[64] 의해 의도적으로 지정된 해석이 없습니다. 유니코드 코드 공간에는 다음과 같은 세 가지 개인용 영역이 있습니다.

  • 개인 사용 영역: U+E000–U+F8FF (6400 characters),
  • 보조 개인 용도 지역-A: U+F0000–U+FFFD(65534자),
  • 보조 개인 용도 지역-B: U+100000–U+10FFFD (65534 characters).

그래픽 문자는 유니코드 표준에서 특정 의미론을 갖도록 정의한 문자로, 글리프 모양을 보이거나 공백을 나타냅니다. 유니코드 15.1을 기준으로 149641개의 그래픽 문자가 있습니다.

포맷 문자는 눈에 보이는 외형은 없지만 이웃 캐릭터의 외형이나 행동에 영향을 줄 수 있는 문자입니다. 예를 들어, U+200C ZERO WIDTH NON-JOINER 및 U+200D ZERO WIDTH JOINER는 인접 문자의 기본 성형 동작을 변경하기 위해(예를 들어, 결찰을 억제하거나 결찰 형성을 요청하기 위해) 사용될 수 있습니다. 유니코드 15.1에는 172개의 형식 문자가 있습니다.

65개의 코드 포인트, U+0000–U+001F and U+007F–U+009F는 ISO/IEC 6429에 정의된 C0 및 C1 제어 코드에 해당하는 제어 코드로 예약됩니다. U+0089 라인 표, U+008ALINE 피드 및 U+000DCARIAGE RETURN은 유니코드를 사용하는 텍스트에 널리 사용됩니다. mojibake로 알려진 현상에서 C1 코드 포인트는 이전에 서유럽 상황에서 널리 사용되었던 Windows-1252 코드 페이지에 따라 부적절하게 디코딩됩니다.

그래픽, 형식, 제어 코드 및 개인 사용 문자를 함께 할당 문자라고 통칭합니다. 예약된 코드 포인트는 유효하고 사용할 수 있지만 아직 할당되지 않은 코드 포인트입니다. 유니코드 15.1을 기준으로 824652개의 예약 코드 포인트가 있습니다.

추상문자

추가 정보: 범용 문자 집합 문자 § 문자, 자소 클러스터 및 글리프

유니코드에서 정의한 그래픽 및 형식 문자 집합은 유니코드에서 표현할 수 있는 추상 문자의 레퍼토리와 직접적으로 일치하지 않습니다. 유니코드는 추상적인 문자를 특정 코드 포인트와 연관시켜 문자를 인코딩합니다.[65] 그러나 모든 추상 문자가 단일 유니코드 문자로 인코딩되는 것은 아니며, 일부 추상 문자는 두 문자 이상의 시퀀스로 유니코드로 표현될 수 있습니다. 예를 들어, 리투아니아어에서 필요한 ogonek, 위의 점, 그리고 급성 악센트가 있는 라틴어 작은 글자 "i"는 문자 시퀀스 U+012F로 표시됩니다. U+0307; U+0301. 유니코드는 유니코드에서 직접 인코딩되지 않은 추상 문자에 대해 고유하게 명명된 문자 시퀀스 목록을 유지 관리합니다.[66]

할당된 모든 문자에는 고유하고 변경할 수 없는 이름이 있으며 이 이름을 통해 식별됩니다. 이 불변성은 Unicode Standard 버전 2.0부터 Name Stability 정책에 의해 보장되었습니다.[63] 이름에 심각한 결함이 있고 오해의 소지가 있거나 심각한 오타가 있는 경우 공식 문자 이름을 대신하여 응용 프로그램을 사용하도록 권장하는 공식 별칭을 정의할 수 있습니다. 예를 들어, U+A015 ꀕ YI WU는 공식 별칭 YI 음절 반복 표시를 가지며, U+FE18 ︘ 표현 양식은 수직 오른쪽 렌티큘러 브래킷에 대한 공식 별칭 표현 양식을 갖습니다.

기성품 문자 대 합성 문자

유니코드에는 글리프의 지원 레퍼토리를 크게 확장하는 문자 수정 메커니즘이 포함되어 있습니다. 이것은 사용자가 기본 문자 뒤에 추가할 수 있는 이임계 표시를 결합하는 용도를 다룹니다. 동일한 문자에 여러 개의 결합 다이어크리틱이 동시에 적용될 수 있습니다. 또한 유니코드에는 일반적으로 사용되는 대부분의 문자/문자 조합의 사전 구성 버전이 포함되어 있습니다. 이를 통해 레거시 인코딩으로의 변환을 보다 쉽게 할 수 있으며, 응용 프로그램이 문자를 결합할 필요 없이 유니코드를 내부 텍스트 형식으로 사용할 수 있습니다. 예를들면, é U+0301 ◌́ COMB 뒤에 U+0065 eLATIN 작은 문자 E로 유니코드로 나타낼 수 있습니다.급성 악센트), 그리고 급성과 함께 미리 구성된 문자 U+00E9 éLATIN 작은 문자 E와 동등합니다. 따라서 사용자는 동일한 문자를 인코딩하는 여러 동등한 방법을 사용하는 경우가 많습니다. 유니코드 표준 내의 표준 동등성 메커니즘은 이러한 동등한 인코딩의 실질적인 상호 교환성을 보장합니다.

그 예로는 한글이 있습니다. 유니코드는 개별 한글 자모 하위 구성 요소에서 한글 음절을 구성하는 메커니즘을 제공합니다. 그러나 가장 흔한 자모로 만들어진 11172개의 미리 구성된 음절의 조합도 제공합니다.

CJK 문자는 현재 분해할 수 없는 라디칼과 미리 구성된 형태에 대한 코드만 가지고 있습니다. 대부분의 한 문자는 래디컬(radical)이라고 불리는 더 단순한 정사적 요소로부터 의도적으로 구성되었거나 재구성되었으므로 원칙적으로 유니코드는 한글과 마찬가지로 구성을 가능하게 할 수 있었습니다. 이것은 필요한 코드 포인트의 수를 크게 줄일 수 있을 뿐만 아니라 많은 임의의 새로운 문자의 알고리즘 합성을 허용할 수 있지만, 문자 어원의 복잡성과 급진적인 시스템의 사후 특성은 제안에 엄청난 복잡성을 더합니다. 실제로 한자가 한글처럼 단순하거나 규칙적으로 분해되지 않는 현실에서 라디칼을 구성하는 기반 위에 CJK 부호화를 설계하려는 시도는 어려움을 겪어 왔습니다.

CJK Radical Supplement 블록은 U+2E80–U+2 범위에 할당됩니다.EFF 및 Kangxi 라디칼은 U+2F00–U+2에 할당됩니다.FDF.Ideographic Description Sequences 블록은 U+2 범위를 다룹니다.FF0–U+2FFB, 그러나 유니코드 표준은 다른 곳에서 인코딩된 문자에 대한 대체 표현으로 자신의 문자를 사용하지 말라고 경고합니다.

이 프로세스는 아이디그래프의 형식적 인코딩과는 다릅니다. 인코딩되지 않은 아이디얼에 대한 표준 설명이 없고, 설명된 아이디얼에 대한 의미 할당이 없으며, 설명된 아이디얼에 대해 정의된 동등성이 없습니다. 개념적으로는 <U+0065, U+0301>이라는 문자 시퀀스보다는 "e"라는 영어 문구에 더 가깝습니다.

결찰기

야나 산스크리트 산스의 데바나가르 ī ddhrya-ligature (द् + ध् + र् + य = द्ध्र्य)
아랍어 람-알리프어 (ل + ا = لا)

아랍어와 데바나가르 ī를 포함한 많은 스크립트는 문자 형식의 특정 조합을 특별한 결찰 형식으로 결합해야 하는 특별한 맞춤법 규칙을 가지고 있습니다. 결찰 형성을 지배하는 규칙은 매우 복잡할 수 있으며, ACE(1980년대 DecoType에 의한 아랍어 캘리그라피 엔진)와 같은 특수한 스크립트 모양 기술이 필요하며, 이는 OpenType(Adobe와 Microsoft에 의한)의 개념 증명이 되었습니다. 그래파이트(SIL International 기준) 또는 AAT(Apple 기준).

또한 글꼴에 명령어를 내장하여 운영 체제에 다양한 문자 시퀀스를 적절하게 출력하는 방법을 알려줍니다. 결합 마크 또는 격음기 배치에 대한 간단한 해결책은 마크를 0의 폭으로 할당하고 글리프 자체를 왼쪽 사이드베어링의 왼쪽 또는 오른쪽에 배치하는 것입니다(사용하려는 스크립트의 방향에 따라 다름). 이러한 방식으로 처리된 표시는 앞에 있는 문자 위에 나타나지만 기본 글리프의 너비나 높이에 따라 위치가 조정되지 않습니다. 시각적으로 어색할 수 있으며 일부 글리프와 겹칠 수 있습니다. 실제 적층은 불가능하지만 제한된 경우 근사치를 얻을 수 있습니다(예를 들어 태국어 상단 결합 모음과 음조 표시는 처음부터 다른 높이일 수 있습니다). 일반적으로 이 접근 방식은 단일 공간 글꼴에서만 효과적이지만 더 복잡한 메서드가 실패할 때 폴백 렌더링 방법으로 사용될 수 있습니다.

표준화된 부분집합

유니코드의 여러 하위 집합이 표준화되어 있습니다. 윈도우 NT 4.0은 657자의 WGL-4를 지원하기 때문에, 이는 라틴어, 그리스어 또는 키릴 문자를 사용하는 모든 현대 유럽 언어를 지원하는 것으로 간주됩니다. 유니코드의 다른 표준화된 하위 집합에는 다국어 유럽 하위 집합 [69]MES-1(라틴어 스크립트 전용, 335자), MES-2(라틴어, 그리스어, 키릴 문자 1062자),[70] MES-3A & MES-3B(여기에 표시되지 않은 두 개의 더 큰 하위 집합)가 포함됩니다. MES-2는 MES-1 및 WGL-4의 모든 문자를 포함합니다.

표준 DIN 91379는[71] 유니코드 문자, 특수 문자, 문자 및 반음 부호 시퀀스의 하위 집합을 지정하여 이름을 올바르게 표현하고 유럽에서 데이터 교환을 단순화합니다. 이 표준은 모든 유럽 연합 국가의 모든 공용어와 독일 소수 언어, 아이슬란드, 리히텐슈타인, 노르웨이, 스위스의 공용어를 지원합니다. 관련 ISO 표준에 따라 다른 쓰기 시스템의 이름을 라틴어 스크립트로 변환할 수 있도록 필요한 모든 조합의 기본 문자와 발음 기호가 제공됩니다.

WGL-4, MES-1 and MES-2
배를 젓다 세포 범위
00 20~7E 기본 라틴어(00~7층)
A0–FF 라틴어-1 보충제(80–FF)
01 00–13, 14–15, 16–2B, 2C–2D, 2E–4D, 4E–4F, 50–7E, 7F 라틴어 확장 A (00-7F)
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~6층)
7층, 82 위첨자 및 아래첨자(70~9층)
A3–A4, A7, AC, AF 통화 기호(A0–CF)
21 05, 13, 16, 22, 26, 2E 문자와 같은 기호(00~4F)
5B-5E 번호 양식(50-8층)
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~4층)
FF FD 스페셜

유니코드 문자를 적절하게 처리할 수 없는 렌더링 소프트웨어는 종종 열린 직사각형으로 표시하거나 U+FFFD로 표시하여 인식되지 않은 문자의 위치를 나타냅니다. 일부 시스템에서는 이러한 문자에 대한 더 많은 정보를 제공하려고 시도했습니다. Apple의 Last Resort 글꼴은 문자의 유니코드 범위를 나타내는 대체 글리프를 표시하고 SIL International의 Unicode fallback 글꼴은 문자의 16진수 스칼라 값을 나타내는 상자를 표시합니다.

매핑 및 인코딩

일련의 코드 포인트를 일련의 바이트로 저장하기 위한 몇 가지 메커니즘이 지정되었습니다.

유니코드는 UTF(Unicode Transformation Format) 인코딩과 UCS(Universal Coded Character Set) 인코딩의 두 가지 매핑 방법을 정의합니다. 인코딩은 유니코드 코드 범위를 코드 단위라고 하는 일부 고정된 크기 범위의 값 시퀀스로 매핑합니다. 모든 UTF 인코딩은 고유한 바이트 시퀀스를 매핑합니다.[72] 인코딩 이름의 숫자는 코드 단위당 비트 수(UTF 인코딩의 경우) 또는 코드 단위당 바이트 수(UCS 인코딩 및 UTF-1의 경우)를 나타냅니다. UTF-8 및 UTF-16은 가장 일반적으로 사용되는 인코딩입니다. UCS-2는 UTF-16의 더 이상 사용되지 않는 부분 집합입니다. UCS-4와 UTF-32는 기능적으로 동등합니다.

UTF 인코딩은 다음과 같습니다.

  • 코드 포인트당 1~4바이트를 사용하며 ASCII와 최대 호환성을 갖춘 UTF-8
  • UTF-16은 코드 포인트당 16비트 단위를 하나 또는 두 개 사용하지만 대용품을 인코딩할 수 없습니다.
  • UTF-32, 코드 포인트당 하나의 32비트 단위를 사용합니다.
  • 코드 포인트당 1~5바이트를 사용하는 유니코드 표준의 일부로 지정되지 않은 UTF-EBCDIC는 EBCDIC와의 호환성을 극대화하기 위한 것입니다.

UTF-8은 코드 포인트당 1-4 바이트를 사용하며 라틴어 스크립트와 ASCII 호환을 위해 컴팩트하므로 유니코드 텍스트 교환을 위한 사실상의 표준 인코딩을 제공합니다. FreeBSD와 최신 리눅스 배포판에서 일반 텍스트 처리에서 레거시 인코딩을 직접 대체하는 데 사용됩니다.

UCS-2 및 UTF-16 인코딩은 텍스트 파일의 시작 부분에 사용할 유니코드 바이트 순서 표시(BOM)를 지정하며, 이는 바이트 순서 감지(또는 바이트 엔디언니스 감지)에 사용될 수 있습니다. U+FEFF BYTE ORDER MARK로 인코딩된 BOM은 사용된 유니코드 인코딩에 관계없이 바이트 순서 변경에 대한 명확성의 중요한 속성을 갖습니다. U+FFE(바이트 교환 U+FEFF의 결과)는 법적 문자와 동일하지 않습니다. 그리고 텍스트의 시작이 아닌 곳의 U+FEFF는 0폭의 논브레이크 공간(외모가 없고 결찰의 형성을 막는 것 외에 다른 효과가 없는 캐릭터)을 전달합니다.

UTF-8로 변환된 동일한 문자가 바이트 시퀀스가 됩니다. EF BB BF . 유니코드 표준은 BOM이 "문자 집합이 표시되지 않은 UTF-8 인코딩된 텍스트에 대한 서명 역할을 할 수 있다"는 것을 허용합니다.[73] 일부 소프트웨어 개발자는 UTF-8을 로컬 8비트 코드 페이지와 구별하기 위해 UTF-8을 포함한 다른 인코딩에 이를 채택했습니다. 그러나 UTF-8 표준인 RFC3629는 UTF-8을 사용하는 프로토콜에서 바이트 순서 표시를 금지할 것을 권장하지만 이것이 불가능할 수 있는 경우에 대해 논의합니다. 또한, UTF-8의 가능한 패턴에 대한 큰 제한은 (예를 들어, 하이 비트 세트가 있는 어떤 단독 바이트도 있을 수 없음), UTF-8을 BOM에 의존하지 않고 다른 문자 인코딩과 구별하는 것이 가능해야 함을 의미합니다.

UTF-32 및 UCS-4에서 하나의 32비트 코드 유닛은 어떤 문자의 코드 포인트를 상당히 직접적으로 표현하는 역할을 합니다(다른 플랫폼에 따라 다른 엔디안니스는 코드 유닛이 바이트 시퀀스로 나타나는 방식에 영향을 미칩니다). 다른 인코딩들에서, 각각의 코드 포인트는 가변적인 수의 코드 유닛들로 표현될 수 있습니다. UTF-32는 소프트웨어를 생성하기 위해 gcc 컴파일러를 사용하는 모든 유닉스 운영 체제가 표준 "넓은 문자" 인코딩으로 사용하기 때문에 프로그램에서 텍스트의 내부 표현으로 널리 사용됩니다. Seed7과 같은 일부 프로그래밍 언어는 문자열과 문자에 대한 내부 표현으로 UTF-32를 사용합니다. 최근 버전의 파이썬 프로그래밍 언어(2.2부터 시작)는 유니코드 문자열의 표현으로 UTF-32를 사용하도록 구성되어 높은 수준의 코딩 소프트웨어에서 이러한 인코딩을 효과적으로 배포할 수 있습니다.

또 다른 인코딩 형태인 Punycode를 사용하면 유니코드 문자열을 ASCII 기반 DNS(Domain Name System)에서 지원하는 제한된 문자 집합으로 인코딩할 수 있습니다. 인코딩은 IDNA의 일부로 사용되며, IDNA는 유니코드에서 지원하는 모든 스크립트에서 국제화된 도메인 이름을 사용할 수 있도록 하는 시스템입니다. 이전과 현재의 역사적 제안에는 UTF-5 및 UTF-6이 포함됩니다.

GB18030은 중국 표준화국의 유니코드를 위한 또 다른 인코딩 형태입니다. 그것은 중화인민공화국의 공식 문자 집합입니다. BOCU-1과 SCSU는 유니코드 압축 체계입니다. 2005년 만우절 RFC는 두 개의 패러디 UTF 인코딩인 UTF-9와 UTF-18을 명시했습니다.

입양

참고 항목: UTF-8 § 채택

UTF-8 형태의 유니코드는 2008년부터 월드 와이드 웹의 가장 일반적인 인코딩이었습니다.[74] 거의 보편적인 채택을 가지고 있으며 UTF-8이 아닌 콘텐츠의 대부분은 다른 유니코드 인코딩(예: UTF-16)에서 찾을 수 있습니다. 2024년 기준 UTF-8은 전체 웹 페이지의 평균 97.8%(최고 순위 1,000개 웹 페이지 중 987개)를 차지합니다.[75] 많은 페이지가 내용을 표시하기 위해 ASCII 문자만 사용하지만, UTF-8은 8비트 ASCII 부분 집합으로 설계되었으며, 현재 거의 어떤 웹사이트도 UTF-8 대신 ASCII로만 인코딩한다고 선언하지 않습니다.[76] 추적된 언어 중 3분의 1 이상이 100% UTF-8을 사용합니다.

1998년 RFC 2277이 발표된 이후, 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)에 의해 유지되는 모든 인터넷 프로토콜([77]예: FTP)은 UTF-8에 대한 지원을 필요로 하며, 이 프로토콜은 모든 IETF 프로토콜이 "UTF-8 문자 세트를 사용할 수 있어야 한다"고 명시했습니다.[78]

운영 체제

유니코드는 텍스트의 내부 처리 및 저장을 위한 지배적인 체계가 되었습니다. 많은 텍스트가 여전히 레거시 인코딩에 저장되어 있지만 유니코드는 새로운 정보 처리 시스템을 구축하는 데 거의 독점적으로 사용됩니다. 얼리 어답터들은 UCS-2(고정 길이 2바이트의 구식 전구체인 UTF-16)를 사용하는 경향이 있었고, 나중에 UTF-16( 가변 길이 현재 표준)으로 옮겨갔습니다. 이것이 비 BMP 문자에 대한 지원을 추가하는 가장 덜 파괴적인 방법이었기 때문입니다. 이러한 시스템 중 가장 잘 알려진 것은 윈도우 NT(그리고 그 후손들, 2000, XP, Vista, 7, 8, 10, 11)이며, 이 시스템은 유일한 내부 문자 인코딩으로 UTF-16을 사용합니다. 자바와.NET 바이트코드 환경, macOS, KDE에서도 내부 표현에 사용합니다. 유니코드 부분 지원은 마이크로소프트 유니코드 계층을 통해 Windows 9x에 설치할 수 있습니다.

UTF-8([79]원래 플랜 9용으로 개발됨)은 대부분의 유닉스 계열 운영 체제에서 주요 스토리지 인코딩이 되었는데, 이는 기존의 확장된 ASCII 문자 집합을 비교적 쉽게 대체하기 때문입니다. 또한 UTF-8은 월드 와이드 웹의 HTML 문서에서 사용되는 가장 일반적인 유니코드 인코딩입니다.

유니코드를 사용하는 다국어 텍스트 렌더링 엔진에는 마이크로소프트 윈도우용 Uniscription 및 DirectWrite, macOS용 ATSUI 및 Core Text, GTK+ 및 GNOME 데스크톱용 Pango가 있습니다.

입력방법

주요 기사: 유니코드 입력

키보드 레이아웃은 모든 문자에 대해 간단한 키 조합을 가질 수 없기 때문에 여러 운영 체제에서 전체 레퍼토리에 액세스할 수 있는 대체 입력 방법을 제공합니다.

코드 포인트에서 유니코드 문자를 입력하는 방법을 표준화하는 ISO/[80]IEC 14755는 여러 방법을 지정합니다. Basic 메소드가 있는데, 시작 시퀀스가 코드 포인트의 16진수 표현과 끝 시퀀스가 뒤따릅니다. 문자 맵 프로그램과 같이 화면에 문자가 표로 나열되는 화면 선택 입력 방법도 지정되어 있습니다.

알려진 문자의 코드 포인트를 찾기 위한 온라인 도구로는 조나단 헤들리(Jonathan Heddley)의 유니코드 조회(Unicode Lookup[81])와 벤자민 마일드(Benjamin Milde)의 샤페캐쳐(Shapecatcher[82])가 있습니다. Unicode Lookup에서 검색 키(예: "분수")를 입력하면 코드 포인트가 있는 해당 문자 목록이 반환됩니다. Shapecatcher에서는 Shape 컨텍스트를 기반으로 상자에 문자를 그리면 코드 포인트를 사용하여 도면에 근접한 문자 목록이 반환됩니다.

이메일

주요 기사: 유니코드 및 이메일

MIME은 ASC가 아닌 인코딩을 위한 두 가지 다른 메커니즘을 정의합니다.전자 메일의 II 문자는 문자가 전자 메일 헤더(예: "Subject:")에 있는지 또는 메시지의 텍스트 본문에 있는지에 따라 다르며, 두 경우 모두 원래 문자 집합과 전송 인코딩이 식별됩니다. 유니코드의 전자 메일 전송의 경우 메시지의 상당 부분이 ASCII 문자로 구성되어 있는지 여부에 따라 UTF-8 문자 집합과 Base64 또는 Quoted-printable 전송 인코딩이 권장됩니다. 두 가지 다른 메커니즘의 세부 정보는 MIME 표준에 지정되어 있으며 일반적으로 전자 메일 소프트웨어 사용자에게 숨겨져 있습니다.

IETF는 UTF-8을 사용하여 국제화된 이메일의 프레임워크를 정의했으며[83][84], 그 프레임워크에 따라 여러 프로토콜을 업데이트했습니다[85][86][87][88].

이메일에서 유니코드의 채택은 매우 느렸습니다.[citation needed] 일부 동아시아 텍스트는 여전히 ISO-2022와 같은 인코딩으로 인코딩되어 있으며 휴대폰과[citation needed] 같은 일부 장치는 여전히 유니코드 데이터를 올바르게 처리할 수 없습니다. 그러나 지원은 개선되고 있습니다. 야후와 같은 많은 주요 무료 메일 제공업체들! 메일, Gmail, Outlook.com 에서 지원합니다.

웹

주요 기사: 유니코드 및 HTML

모든 W3C 권장 사항은 HTML 4.0부터 유니코드를 문서 문자 집합으로 사용했습니다. 웹 브라우저는 수년 동안 유니코드, 특히 UTF-8을 지원해 왔습니다. 예전에는 주로 글꼴 관련 문제로 인한 표시 문제가 있었습니다. 예를 들어 마이크로소프트 인터넷 익스플로러의 v6 이상 버전은 코드 포인트를 포함하는 글꼴을 사용하라는 명시적인 지시가 없으면 코드 포인트를 많이 렌더링하지 않았습니다.[89]

구문 규칙이 문자의 출현을 허용하는 순서에 영향을 미칠 수 있지만 XML(XHTML 포함) 문서는 정의상 다음을 제외하고 대부분의 유니코드 코드 포인트에서 문자로 구성됩니다.[90]

  • FFFE or FFFF.
  • 대부분의 C0 제어 코드,
  • 영구적으로 할당되지 않은 코드 포인트 D800 ~ DFFF,

HTML 문자는 인코딩이 지원하는 경우 문서의 인코딩에 따라 바이트로 직접 표시되거나 사용자가 문자의 유니코드 코드 포인트를 기반으로 숫자 문자 참조로 작성할 수 있습니다. 예를 들어, 참조는 &#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;,그리고. &#47568; (또는 16진수로 표시된 동일한 숫자 값, 의 경우) &#x 접두사로)는 모든 브라우저에서 δ, й, ק, م, ๗, あ, 叶, 葉 및 말로 표시되어야 합니다.

예를 들어 HTTP 요청의 URL로 URI를 지정할 때 ASC가 아닌 경우II 문자는 퍼센트로 인코딩해야 합니다.

글꼴

주요 기사: 유니코드 글꼴

유니코드는 글꼴 자체를 구현 선택으로 간주하여 원칙적으로 글꼴 자체와 관련이 없습니다.[91] 주어진 캐릭터는 더 일반적인 굵은 글씨, 이탤릭체 및 밑줄 글자 형태부터 복잡한 장식 스타일에 이르기까지 많은 알러지를 가질 수 있습니다. 유니코드 표준에 정의된 코드 포인트를 사용하여 글꼴의 글리프에 액세스할 수 있는 경우 글꼴은 "유니코드 준수"입니다.[92] 표준에서는 글꼴에 포함되어야 하는 최소 문자 수를 지정하지 않습니다. 일부 글꼴은 레퍼토리가 상당히 작습니다.

TrueType 및 OpenType은 유니코드(및 WOFF 및 WOFF2)를 지원하기 때문에 유니코드를 기반으로 하는 무료 및 소매 글꼴을 널리 사용할 수 있습니다. 이러한 글꼴 형식은 유니코드 코드 포인트를 글리프에 매핑하지만 OpenType 및 TrueType 글꼴 파일은 65,535 글리프로 제한됩니다. 모음 파일은 단일 글꼴 파일에서 이 한계를 극복하기 위한 "갭 모드" 메커니즘을 제공합니다. (그러나 모음 내의 각 글꼴에는 여전히 65,535개의 한계가 있습니다.) TrueType Collection 파일의 파일 확장자는 일반적으로 .ttc입니다.

수천 개의 글꼴이 시장에 존재하지만 유니코드의 대부분의 캐릭터 레퍼토리를 지원하려고 시도하는 글꼴은 12개 미만입니다. 대신 유니코드 기반 글꼴은 일반적으로 기본 ASCII 및 특정 스크립트 또는 문자 또는 기호 집합만 지원하는 데 중점을 둡니다. 응용 프로그램과 문서가 하나 또는 두 개 이상의 쓰기 시스템에서 문자를 렌더링할 필요가 거의 없으며, 글꼴은 컴퓨팅 환경에서 리소스를 요구하는 경향이 있으며, 운영 체제와 응용 프로그램은 필요에 따라 별도의 글꼴 파일에서 글리프 정보를 얻는 것과 관련하여 증가하는 지능을 보여줍니다.e. 글꼴 대체 또한 수만 개의 글리프에 대한 일관된 렌더링 명령어 세트를 설계하는 것은 기념비적인 작업입니다. 이러한 벤처는 대부분의 서체에 대한 수익을 줄이는 지점을 지나갑니다.

새 선

유니코드는 다른 플랫폼에서 텍스트 파일을 읽으려고 할 때 발생하는 새 줄 문제를 부분적으로 해결합니다. 유니코드는 적합한 응용 프로그램이 라인 터미네이터로 인식해야 하는 많은 수의 문자를 정의합니다.

새로운 라인 측면에서 유니코드는 U+2028 라인 분리기와 U+2029 단락 분리기를 도입했습니다. 이는 단락과 행을 의미론적으로 인코딩하는 유니코드 솔루션을 제공하여 잠재적으로 다양한 플랫폼 솔루션을 모두 대체하려는 시도였습니다. 이를 통해 유니코드는 과거 플랫폼에 의존하는 솔루션을 해결할 수 있는 방법을 제공합니다. 그럼에도 불구하고 유니코드 솔루션이 이러한 유니코드 선 및 단락 구분자를 유일한 표준 선 종단 문자로 채택한 경우는 거의 없습니다. 그러나 이 문제를 해결하기 위한 일반적인 접근 방식은 새로운 라인 정규화를 통한 것입니다. 이것은 Mac OS X의 코코아 텍스트 시스템과 W3C XML 및 HTML 권장 사항을 통해 달성됩니다. 이 접근 방식에서는 가능한 모든 새 줄 문자가 내부적으로 공통 새 줄로 변환됩니다(렌더링을 위한 내부 작업이기 때문에 그다지 중요하지 않습니다). 즉, 텍스트 시스템은 입력의 실제 인코딩에 관계없이 문자를 새 행으로 올바르게 처리할 수 있습니다.

문제들

문자 통일

한통일

주요 기사: 한통일

IRG(Ideographic Research Group)는 한 통일, 즉 유니한과 관련하여 컨소시엄과 ISO에 조언하는 임무를 수행하며, 특히 CJK 통일 및 호환 아이디어를 레퍼토리에 추가하는 작업을 수행합니다. IRG는 역사적으로 한자를 사용한 각 지역의 전문가들로 구성되어 있습니다. 그러나 위원회 내의 심의에도 불구하고, 통일은 프로젝트가 시작된 이래로 유니코드 표준의 가장 치열한 논쟁의 대상 중 하나였습니다.[93]

일본어 JIS X 0208(Shift JIS로 인코딩됨)과 같은 기존 문자 집합 표준에서는 단일화 기준을 정의했는데, 이는 변형된 한자가 언제 필기/서체 차이(따라서 통일된 것)와 철자 차이(따로 인코딩되는 것)로 간주되어야 하는지를 결정하기 위한 규칙을 의미합니다. CJK 문자에 대한 유니코드의 문자 모델은 JIS X 0208에서 사용한 통일 기준과 중국의 중국 공통 중국어 코드 협회에서 개발한 통일 기준을 기반으로 했습니다.[94] 유니코드는 양식적 변형 대신 시맨틱을 인코딩하는 표준의 원칙 때문에 특정 희귀하고 오래된 한자 변형에 코드 포인트를 할당하지 않아 고대 및 희귀한 일본어 이름의 처리를 복잡하게 만들 수 있다는 비판을 받았습니다. 중국어, 일본어, 한국어가 공통적으로 많은 문자를 공유하는 것을 특별히 강조하고 있기 때문에, 한 통일은 또한 때때로 세 가지를 같은 것으로 취급하는 것으로 인식됩니다.[95]

덜 자주 사용되는 대체 인코딩이 존재하며, 종종 유니코드 이전에 존재하며, 이 패러다임과는 다른 문자 모델이 존재하며, 지역 문자 형식 및/또는 비표준 문자 형식 간의 다양한 스타일 차이를 보존하는 것을 목표로 합니다. 그 한 예는 일본 대중들 사이에서 널리 채택되지는 않았지만 역사적인 일본어 텍스트를 다루기 위해 일부 사용자들이 선호하는 TRON 코드입니다. 또 다른 하나는 홍콩, 대만 및 미국의 도서관 시스템에서 채택한 CCCII 인코딩입니다. 이것들은 일반적인 용도에서 그들만의 단점이 있어서, Big5 인코딩(CCII 이후 4년 후인 1984년에 도입)이 라이브러리 시스템 외부에서 CCCII보다 더 일반화되게 되었습니다.[96] 연구 도서관 그룹의 CJK Thesaurus를 기반으로 한 Apple 작업은 CCCII의 EACC 변형을 유지하는 데 사용되었지만 유니코드는 JIS 스타일의 통일 모델을 채택했습니다.[94]

유니코드의 초기 버전은 21,000한자 미만의 레퍼토리를 가지고 있었는데, 주로 비교적 일반적인 현대 사용법으로 제한되었습니다. 버전 15.1을 기준으로 이 표준은 현재 97,000개 이상의 한 글자를 인코딩하고 있으며, 수천 개의 한 글자를 추가하기 위해 작업을 계속하고 있습니다. 주로 시노스피어 전체에서 사용되는 역사적 및 변증법적 변형 문자입니다.

현대 서체는 다양한 지역 그래픽 표현으로 통일된 한 문자를 묘사하는 데 있어 몇 가지 실용적인 문제를 해결할 수 있는 수단을 제공합니다. 'locl' OpenType 테이블을 사용하면 렌더러가 텍스트 로케일을 기준으로 각 코드 포인트에 대해 다른 글리프를 선택할 수 있습니다.[97] 유니코드 변형 시퀀스는 원하는 글리프 선택을 위한 텍스트 내 주석을 제공할 수도 있습니다. 이를 위해서는 특정 변형을 이데아그래픽 변형 데이터베이스에 등록해야 합니다.

키릴 문자의 이탤릭체 또는 필기체

직립형, 사선형, 이탤릭체가 번갈아 나타나는 다양한 키릴 문자

같은 스크립트 내의 문자에 대한 적절한 글리프가 이탤릭체에서만 다른 경우, 유니코드는 일반적으로 이탤릭체를 통일하였는데, 이는 오른쪽의 러시아어, 전통적인 불가리아어, 마케도니아어, 세르비아어 텍스트에서 일반적으로 나타나는 7개 문자의 이탤릭체 글리프 집합 간의 비교에서 볼 수 있듯이, 스마트 폰트 기술 또는 수동으로 폰트를 변경하여 차이점을 표시하는 것을 의미합니다. 동일한 OpenType 'locl' 기법이 사용됩니다.[98]

레거시 문자 집합에 매핑

유니코드는 기존 문자 인코딩과의 코드 포인트 단위 왕복 형식 변환을 제공하도록 설계되어 컨텍스트 의존적 해석을 사용하지 않고 이전 문자 집합의 텍스트 파일을 유니코드로 변환한 다음 다시 동일한 파일을 반환할 수 있습니다. 이는 2음자와 미리 구성된 문자를 결합하는 것과 같은 일관되지 않은 레거시 아키텍처가 모두 유니코드에 존재한다는 것을 의미하며, 일부 텍스트를 표현하는 한 가지 이상의 방법을 제공합니다. 이것은 한국어 한글에 대한 세 가지 다른 인코딩 형태에서 가장 두드러집니다. 버전 3.0 이후, 이미 존재하는 문자들의 결합된 시퀀스로 표현될 수 있는 미리 구성된 문자들은 다른 버전의 유니코드를 사용하는 소프트웨어 간의 상호 운용성을 유지하기 위해 더 이상 표준에 추가될 수 없습니다.

유니코드로의 변환을 용이하게 하고 레거시 소프트웨어와의 상호 운용성을 허용하기 위해 기존 레거시 문자 집합의 문자와 유니코드의 문자 사이에 주입식 매핑을 제공해야 합니다. Shift-J와 같은 이전 일본어 인코딩 간의 다양한 매핑의 일관성 부족IS 또는 EUC-JP와 유니코드는 왕복 형식 변환 불일치, 특히 레거시 데이터베이스 데이터에 많이 사용되는 문자 JIS X 0208 '~'(1-33, WAVE DASH)를 U+FF5E ~ FULLWIDTH TILDE(마이크로소프트 윈도우의 경우) 또는 U+301C ~ WAVE DASH(기타 공급업체)에 매핑했습니다.[99]

일부 일본 컴퓨터 프로그래머들은 유니코드를 반대했는데, 이는 JIS X 0201의 0x5C에 매핑된 U+005C \ REVERSE SOLIDUS (backslash)와 U+00A5 ¥ YEN SIGN의 사용을 분리해야 하기 때문이며, 이 사용으로 많은 레거시 코드가 존재합니다. (또한 이 인코딩은 tilde '~' 0x7E를 macron '¯'로 대체하며, 현재는 0xAF입니다.) 이러한 문자의 분리는 유니코드 이전부터 ISO 8859-1에 존재합니다.

지시 스크립트

타밀어와 데바나가리와 같은 지시 스크립트는 ISCII 표준과 일치하는 128개의 코드 포인트만 할당됩니다. Unicode Indic 텍스트를 올바르게 렌더링하려면 저장된 논리적 순서 문자를 시각적 순서로 변환하고 구성 요소에서 연결(연결이라고도 함)을 형성해야 합니다. 일부 지역 학자들은 유니코드 코드 포인트의 할당에 찬성하는 주장을 펼쳤으며, 이는 다른 쓰기 시스템에 대한 관행에 어긋나는 것이지만, 유니코드에는 하위 호환성 목적으로만 일부 아랍어와 다른 문자열이 포함되어 있습니다.[101][102][103] 부분적으로 문자열 집합이 글꼴 종속적이고 유니코드는 글꼴 변형과 독립적인 인코딩이기 때문에 유니코드에서 새 문자열의 인코딩은 발생하지 않습니다. 2003년 중국 표준화 관리국이 956개의 미리 구성된 티베트 음절을 부호화할 것을 제안하면서 티베트 문자에 대해서도 같은 종류의 문제가 발생했지만,[104] 이들은 관련 ISO 위원회(ISO/IEC JTC 1/SC 2)에서 부호화를 거부당했습니다.[105]

태국어 알파벳 지원은 태국어 문자를 주문하는 것으로 인해 비판을 받았습니다. 앞 자음의 왼쪽에 쓰여지는 모음 เ, แ, โ, ไ, ใ는 다른 인디크 스크립트의 유니코드 표현과 달리 음성 순서 대신 시각적 순서로 되어 있습니다. 이러한 복잡성은 유니코드가 태국 산업 표준 620을 계승했기 때문인데, 이는 같은 방식으로 작동했고, 항상 키보드에 태국어가 쓰여져 있던 방식이었습니다. 이 순서 지정 문제는 유니코드 대조 프로세스를 약간 복잡하게 하므로, 대조를 위해 태국 문자의 순서를 다시 지정하기 위해 테이블 검색이 필요합니다.[95] 유니코드가 음성 순서에 따라 인코딩을 채택했더라도 단어를 사전 순서로 대조하는 것은 여전히 문제가 될 것입니다. 예를 들어, แสดง [sad ɛːŋ] "perform"이라는 단어는 자음 클러스터 "สด"(자음 "ส"에 고유 모음이 있음)로 시작하며, 구어 순서의 모음 แ-는 ด 뒤에 오지만, 사전에서는 단어가 쓰여 있는 대로 모음이 ส 뒤에 따라붙습니다.

문자 조합하기

주요 기사: 문자 조합하기
참고 항목: 유니코드 정규화 § 정규화

격음 표시가 있는 문자는 일반적으로 단일 미리 구성된 문자 또는 기본 문자와 하나 이상의 공백이 없는 표시의 분해된 시퀀스로 표현될 수 있습니다. 예를 들어, ḗ(위의 마크롱과 급성으로 미리 구성된 것)과 ḗ(e 뒤에 마크롱을 결합하고 위의 마크롱을 결합하는 것과 급성으로 결합하는 것)은 마크롱(◌̄)과 급성 억양(◌́)을 가진 e로 동일하게 렌더링되어야 하지만, 실제로는, 글자를 표시하기 위해 사용되는 렌더링 엔진과 글꼴에 따라 모양이 달라질 수 있습니다. 마찬가지로, Indic의 로마자 표기에서 필요한 언더닷은 종종 잘못 배치됩니다.[citation needed] 많은 경우 미리 합성된 글리프에 매핑되는 유니코드 문자를 사용할 수 있으므로 문제를 피할 수 있지만, 미리 합성된 문자가 인코딩되지 않은 경우에는 그래파이트, 오픈타입('gsub') 또는 고급 렌더링 기능을 위한 AAT 기술을 사용하는 샤리스 SIL과 같은 전문 유니코드 글꼴을 사용하여 문제를 해결할 수 있는 경우가 많습니다.

이상 징후

주요 기사: 유니코드 별칭 이름 및 약어

유니코드 표준은 안정성을 보장하기 위한 규칙을 부과했습니다.[106] 규칙의 엄격성에 따라 변경이 금지되거나 허용될 수 있습니다. 예를 들어, 코드 포인트에 지정된 "이름"은 변경할 수 없고 변경되지도 않습니다. 그러나 "스크립트" 속성은 유니코드 자체 규칙에 의해 더 유연합니다. 버전 2.0에서 유니코드는 버전 1에서 많은 코드 포인트 "이름"을 변경했습니다. 동시에 유니코드는 코드 포인트에 할당된 이름은 절대로 변경되지 않는다고 밝혔습니다. 이는 실수가 게시되면 사소한 것이라도 이러한 실수를 수정할 수 없음을 의미합니다(문자 이름에서 BRAKET에 대한 철자 BRAKET의 경우 한 사례에서 발생한 것처럼). 2006년 캐릭터 이름의 이상 징후 목록이 처음 발표되었으며 2021년 6월 기준으로 104개의 캐릭터가 확인되었습니다.[107] 예를 들어 다음과 같은 문제가 있습니다.

  • U+034F ͏ COMING GAPHEM JOINER: 자소를 결합하지 않습니다.
  • U+2118 ℘ SCRIPT CAPTIAL P: 작은 글씨입니다. 수도는 U+1D4입니다.AB 𝒫 수학 스크립트 대문자 P.
  • U+A015 ꀕ YI 음절 WU: 이것은 Yi 음절이 아니라 Yi 반복 표시입니다.
  • U+FE18 ︘ VERTICAL WHITE LENTICUL BRAKET용 표: 괄호의 철자가 잘못되었습니다. (Unicode 별칭 이름을 사용하여 철자 오류를 해결합니다.)

유니코드는 스크립트 지정자(이름)를 "Phags_Pa"로 정의하지만, 스크립트의 문자 이름에는 하이픈이 추가됩니다. U+A840 ꡀ PHAGS-PA LETTER KA.[110][111] 그러나 이것은 예외가 아니라 규칙입니다. 하이픈은 스크립트 지정자에서 밑줄로 대체됩니다.[110]

보안.

유니코드에는 많은 수의 동형문자가 있는데, 그 중 많은 수가 아스키 문자와 매우 유사하거나 동일해 보입니다. 이들을 대체하면 정확해 보이지만 예상과 다른 위치로 향하는 식별자 또는 URL을 만들 수 있습니다.[112] 또한, 호모글리프는 자연어 처리(NLP) 시스템의 출력을 조작하는 데에도 사용될 수 있습니다.[113] 완화를 위해서는 이러한 문자를 허용하지 않거나 다르게 표시하거나 동일한 식별자로 해결해야 합니다.[114] 이 모든 것은 크고 지속적으로 변화하는 문자 집합으로 인해 복잡합니다.[115][116]

2021년에 캠브리지 대학과 에딘버러 대학의 두 연구원이 BiDi 마크를 사용하여 코드의 큰 부분이 보이는 것과 다른 일을 하도록 만들 수 있다고 주장하는 보안 자문을 발표했습니다. 문제의 이름은 "Trojan Source"입니다.[117] 이에 대해 코드 에디터들은 강제적인 텍스트 방향 변경을 나타내기 위해 표시를 강조하기 시작했습니다.[118]

참고 항목

메모들

  1. ^ 때로는 TUS로 약칭되기도 합니다.[1][2]
  2. ^ "Unicode Standard Annex(UAX)는 Unicode Standard의 필수적인 부분을 구성하지만, 별도의 문서로 발행됩니다."[1]

참고문헌

  1. ^ The Unicode Standard, Version 15.1.0. South San Francisco, CA: The Unicode Consortium. 2023. ISBN 978-1-936213-33-7.
  1. ^ "Unicode Technical Report #28: Unicode 3.2". Unicode Consortium. 2002-03-27. Retrieved 2022-06-23.
  2. ^ Jenkins, John H. (2021-08-26). "Unicode Standard Annex #45: U-source Ideographs". Unicode Consortium. Retrieved 2022-06-23. 2.2 The Source Field
  3. ^ "Unicode Character Count V15.1". Unicode. Archived from the original on 2023-10-09. Retrieved 2023-09-12.
  4. ^ "Emoji Counts, v15.1". Unicode. Archived from the original on 2023-09-28. Retrieved 2023-09-12.
  5. ^ "The Unicode Standard: A Technical Introduction". Retrieved 2010-03-16.
  6. ^ "Unicode Bulldog Award". Unicode. Archived from the original on 2023-11-11.
  7. ^ a b c d e Becker, Joseph D. (1998-09-10) [1988-08-29]. "Unicode 88" (PDF). Unicode Consortium. Archived (PDF) from the original on 2016-11-25. Retrieved 2016-10-25. In 1978, the initial proposal for a set of "Universal Signs" was made by Bob Belleville at Xerox PARC. Many persons contributed ideas to the development of a new encoding design. Beginning in 1980, these efforts evolved into the Xerox Character Code Standard (XCCS) by the present author, a multilingual encoding that has been maintained by Xerox as an internal corporate standard since 1982, through the efforts of Ed Smura, Ron Pellar, and others.
    Unicode arose as the result of eight years of working experience with XCCS. Its fundamental differences from XCCS were proposed by Peter Fenwick and Dave Opstad (pure 16-bit codes) and by Lee Collins (ideographic character unification). Unicode retains the many features of XCCS whose utility has been proved over the years in an international line of communication multilingual system products.
  8. ^ "Summary Narrative". Unicode. 2006-08-31. Retrieved 2010-03-15.
  9. ^ "History of Unicode Release and Publication Dates". Unicode. Retrieved 2023-03-20.
  10. ^ Searle, Stephen J. "Unicode Revisited". Retrieved 2013-01-18.
  11. ^ a b "The Unicode Consortium Members". Retrieved 2024-02-12.
  12. ^ "Unicode FAQ". Retrieved 2020-04-02.
  13. ^ "Supported Scripts". Unicode. Retrieved 2022-09-16.
  14. ^ "Roadmap to the BMP". Unicode Consortium. Retrieved 2018-07-30.
  15. ^ "Roadmaps to Unicode". Unicode. Archived from the original on 2023-12-08.
  16. ^ "script encoding initiative". Berkeley Linguistics. Archived from the original on 2023-03-25.
  17. ^ "About The Script Encoding Initiative". The Unicode Consortium. Retrieved 2012-06-04.
  18. ^ "Unicode 6.1 Paperback Available". announcements_at_unicode.org. Retrieved 2012-05-30.
  19. ^ "Unicode 15.0.0". Unicode. Retrieved 2023-09-12.
  20. ^ "Emoji Counts, v15.0". Unicode. Retrieved 2023-09-12.
  21. ^ "Enumerated Versions of The Unicode Standard". Retrieved 2016-06-21.
  22. ^
  23. ^ "Unicode Data 1.0.1". Retrieved 2010-03-16.
  24. ^
  25. ^
  26. ^ a b
  27. ^
  28. ^
  29. ^
  30. ^
  31. ^ "Unicode Data-4.1.0". Retrieved 2010-03-16.
  32. ^ "Named Sequences-4.1.0". Retrieved 2010-03-16.
  33. ^ "Unicode Data 5.0.0". Retrieved 2010-03-17.
  34. ^ "Unicode Data 5.1.0". Retrieved 2010-03-17.
  35. ^ "Unicode Data 5.2.0". Retrieved 2010-03-17.
  36. ^ "Unicode Data 6.0.0". Retrieved 2010-10-11.
  37. ^ "Unicode 6.0 Emoji List". emojipedia.org. Retrieved 2022-09-21.
  38. ^ "Unicode Data 6.1.0". Retrieved 2012-01-31.
  39. ^ "Unicode Data 6.2.0". Retrieved 2012-09-26.
  40. ^ "Unicode Data 6.3.0". Retrieved 2013-09-30.
  41. ^ "Unicode Data 7.0.0". Retrieved 2014-06-15.
  42. ^ "Unicode Data 8.0.0". Retrieved 2015-06-17.
  43. ^ "Unicode 8.0.0". Unicode Consortium. Retrieved 2015-06-17.
  44. ^ "Unicode 9.0.0". Unicode Consortium. Retrieved 2016-06-21.
  45. ^ "Unicode Data 9.0.0". Retrieved 2016-06-21.
  46. ^ Lobao, Martim (2016-06-07). "These Are The Two Emoji That Weren't Approved For Unicode 9 But Which Google Added To Android Anyway". Android Police. Retrieved 2016-09-04.
  47. ^ "Unicode 10.0.0". Unicode Consortium. Retrieved 2017-06-20.
  48. ^ "The Unicode Standard, Version 11.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2018-06-11.
  49. ^ "The Unicode Standard, Version 12.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2019-03-05.
  50. ^ "Unicode Version 12.1 released in support of the Reiwa Era". The Unicode Blog. Retrieved 2019-05-07.
  51. ^
  52. ^ "The Unicode Standard, Version 13.0– Core Specification Appendix C" (PDF). Unicode Consortium. Retrieved 2020-03-11.
  53. ^
  54. ^
  55. ^
  56. ^ "Proposed New Characters: The Pipeline". Unicode. 2023-09-12. Retrieved 2023-09-13.
  57. ^ "Unicode Version 16.0". emojipedia.org. Retrieved 2023-09-13.
  58. ^ "Glossary of Unicode Terms". Retrieved 2010-03-16.
  59. ^ "2.4 Code Points and Characters". The Unicode Standard Version 15.1 – Core Specification (PDF). 2023. p. 29.
  60. ^ "3.4 Characters and Encoding". The Unicode Standard, Version 15.1 (PDF). 2023. p. 88.
  61. ^ "Re: Origin of the U+nnnn notation". Unicode Mail List Archive (Mailing list). 2005-11-08.
  62. ^ "Appendix A: Notational Conventions" (PDF). The Unicode Standard. Unicode Consortium. September 2023.
  63. ^ a b "Unicode Character Encoding Stability Policy". Retrieved 2010-03-16.
  64. ^ "Properties" (PDF). Retrieved 2023-09-12.
  65. ^ "Unicode Character Encoding Model". Retrieved 2023-09-12.
  66. ^ "Unicode Named Sequences". Retrieved 2022-09-16.
  67. ^ "Unicode Name Aliases". Retrieved 2010-03-16.
  68. ^ "JanaSanskritSans". Archived from the original on 2011-07-16.
  69. ^ CWA 13873:2000 – ISO/IEC 10646-1 CEN 작업장 협정 13873의 다국어 유럽 하위 집합
  70. ^ Kuhn, Markus (1998). "Multilingual European Character Set 2 (MES-2) Rationale". University of Cambridge. Retrieved 2023-03-20.
  71. ^ "DIN 91379:2022-08: Characters and defined character sequences in Unicode for the electronic processing of names and data exchange in Europe, with CD-ROM". Beuth Verlag. Retrieved 2022-08-21.
  72. ^ "UTF-8, UTF-16, UTF-32 & BOM". Unicode.org FAQ. Retrieved 2016-12-12.
  73. ^ The Unicode Standard, Version 6.2. The Unicode Consortium. 2013. p. 561. ISBN 978-1-936213-08-5.
  74. ^ Davis, Mark (2008-05-05). "Moving to Unicode 5.1". Official Google Blog. Retrieved 2021-02-19.
  75. ^ "Usage Survey of Character Encodings broken down by Ranking". W3Techs. Retrieved 2023-01-16.
  76. ^ "Usage Statistics and Market Share of US-ASCII for Websites, October 2021". W3Techs. Retrieved 2020-11-01.
  77. ^ B. Curtin (July 1999). Internationalization of the File Transfer Protocol. doi:10.17487/RFC2640. RFC 2640. Retrieved 2022-08-17.
  78. ^ H. Alvestrand (January 1998). IETF Policy on Character Sets and Languages. doi:10.17487/RFC2277. BCP 18. RFC 2277. Retrieved 2022-08-17.
  79. ^ Pike, Rob (2003-04-30). "UTF-8 history".
  80. ^ "ISO/IEC JTC1/SC 18/WG 9 N" (PDF). Retrieved 2012-06-04.
  81. ^ Hedley, Jonathan (2009). "Unicode Lookup".
  82. ^ Milde, Benjamin (2011). "Unicode Character Recognition".
  83. ^ J. Klensin; Y. Ko (July 2007). Overview and Framework for Internationalized Email. doi:10.17487/RFC4952. RFC 4952. Retrieved 2022-08-17.
  84. ^ J. Klensin; Y. Ko (February 2012). Overview and Framework for Internationalized Email. doi:10.17487/RFC6530. RFC 6530. Retrieved 2022-08-17.
  85. ^ J. Yao; W. Mao (February 2012). SMTP Extension for Internationalized Email. doi:10.17487/RFC6531. RFC 6531. Retrieved 2022-08-17.
  86. ^ A. Yang; S. Steele; N. Freed (February 2012). Internationalized Email Headers. doi:10.17487/RFC6532. RFC 6532. Retrieved 2022-08-17.
  87. ^ C. Newman; A. Gulbrandsen; A. Melnikov (June 2008). Internet Message Access Protocol Internationalization. doi:10.17487/RFC5255. RFC 5255. Retrieved 2022-08-17.
  88. ^ R. Gellens; C. Newman (February 2010). POP3 Support for UTF-8. doi:10.17487/RFC5721. RFC 5721. Retrieved 2022-08-17.
  89. ^ Wood, Alan. "Setting up Windows Internet Explorer 5, 5.5 and 6 for Multilingual and Unicode Support". Alan Wood. Retrieved 2012-06-04.
  90. ^ "Extensible Markup Language (XML) 1.1 (Second Edition)". Retrieved 2013-11-01.
  91. ^ Bigelow, Charles; Holmes, Kris (September 1993). "The design of a Unicode font" (PDF). Electronic Publishing. 6 (3): 292.
  92. ^ "Fonts and keyboards". Unicode Consortium. 2017-06-28. Retrieved 2019-10-13.
  93. ^ 캐릭터 코드의 간략한 역사 스티븐 J. 설, 원래 1999년 작성, 마지막으로 업데이트된 2004년
  94. ^ a b "Appendix E: Han Unification History" (PDF). The Unicode Standard Version 15.0 – Core Specification. Unicode Consortium. 2022.
  95. ^ a b Topping, Suzanne (2013-06-25). "The secret life of Unicode". IBM. Archived from the original on 2013-06-25. Retrieved 2023-03-20.
  96. ^ Wittern, Christian (1995-05-01). "Chinese character codes: an update". International Research Institute for Zen Buddhism / Hanazono University. Archived from the original on 2004-10-12.
  97. ^ "Noto CJK fonts". Noto Fonts. 2023-02-18. Select this deployment format if your system supports variable fonts and you prefer to use only one language, but also want full character coverage or the ability to language-tag text to use glyphs that are appropriate for the other languages (this requires an app that supports language tagging and the OpenType 'locl' GSUB feature).
  98. ^ Preuss, Ingo. "OpenType Feature: locl – Localized Forms". preusstype.com.
  99. ^ WAVE DASH에 관한 AFII 기고문,
  100. ^ ISO 646-* 문제, I18n 입문 섹션 4.4.3.5, 쿠보타 도모히로, 2001
  101. ^ "Arabic Presentation Forms-A" (PDF). Retrieved 2010-03-20.
  102. ^ "Arabic Presentation Forms-B" (PDF). Retrieved 2010-03-20.
  103. ^ "Alphabetic Presentation Forms" (PDF). Retrieved 2010-03-20.
  104. ^ "Proposal on Tibetan BrdaRten Characters Encoding for ISO/IEC 10646 in BMP" (PDF). 2002-12-02.
  105. ^ Umamaheswaran, V. S. (2003-11-07). "Resolutions of WG 2 meeting 44" (PDF). Resolution M44.20.
  106. ^ "Character Encoding Stability". Unicode. Archived from the original on 2024-01-01.
  107. ^ a b "Unicode Technical Note #27: Known Anomalies in Unicode Character Names". Unicode. 2021-06-14.
  108. ^ "Unicode chart: "actually this has the form of a lowercase calligraphic p, despite its name"" (PDF).
  109. ^ "Misspelling of BRACKET in character name is a known defect" (PDF).
  110. ^ a b "Unicode Standard Annex #24: Unicode Script Property". The Unicode Consortium. 2021. 2.2 Relation to ISO 15924 Codes. Retrieved 2022-04-29.
  111. ^ "Scripts-15.1.0.txt". The Unicode Consortium. 2023. Retrieved 2023-09-12.
  112. ^ "UTR #36: Unicode Security Considerations". Unicode.
  113. ^ Boucher, Nicholas; Shumailov, Ilia; Anderson, Ross; Papernot, Nicolas (2022). "Bad Characters: Imperceptible NLP Attacks". 2022 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, US: IEEE. pp. 1987–2004. arXiv:2106.09898. doi:10.1109/SP46214.2022.9833641. ISBN 978-1-66541-316-9. S2CID 235485405.
  114. ^ Engineering, Spotify (2013-06-18). "Creative usernames and Spotify account hijacking". Spotify Engineering. Retrieved 2023-04-15.
  115. ^ Wheeler, David A. (2020). "Countermeasures". Initial Analysis of Underhanded Source Code: 4–1.
  116. ^ "UTR #36: Unicode Security Considerations". Unicode. Retrieved 2022-06-27.
  117. ^ Boucher, Nicholas; Anderson, Ross. "Trojan Source: Invisible Vulnerabilities" (PDF). Retrieved 2021-11-02.
  118. ^ "Visual Studio Code October 2021". code.visualstudio.com. Retrieved 2021-11-11.

추가읽기

  • Julie D. 알렌. Unicode Standard, Version 6.0, The Unicode Consortium, Mountain View, 2011, ISBN 9781936213016, (Unicode 6.0.0).
  • 타이포그래피 완전 매뉴얼, 제임스 펠리시, 어도비 프레스; 제1판, 2002. ISBN 0-321-12730-7
  • Unicode Standard, Version 3.0, The Unicode Consortium, Addison-Wesley Longman, Inc., 2000년 4월. ISBN 0-201-61633-5
  • 유니코드 표준, 버전 4.0, 유니코드 컨소시엄, 애디슨-웨슬리 프로페셔널, 2003년 8월 27일. ISBN 0-321-18578-1
  • Unicode Standard, Version 5.0, Fifth Edition, The Unicode Consortium, Addison-Wesley Professional, 2006년 10월 27일. ISBN 0-321-48091-0-->
  • Unicode Demystified: 인코딩 표준에 대한 실용적인 프로그래머 안내서, Richard Gillam, Addison-Wesley Professional; 제1판, 2002. ISBN 0-201-70052-2
  • 유니코드 설명, Jukka K. Korpela, O'Reilly; 제1판, 2006. ISBN 0-596-10121-X
  • 유니코드: 프라이머, 토니 그레이엄, M&T북스, 2000. ISBN 0-7645-4625-2.

외부 링크