범용 문자 집합 문자

이 글은 특수문자를 포함하고 있다. 적절한 렌더링 지원이 없으면 물음표, 상자 또는 기타 기호를 볼 수 있다.

유니코드 컨소시엄(UC)과 국제표준화 기구(ISO)는 범용 문자 집합(UCS)에 대해 협력한다. UCS는 자연 언어, 수학, 음악 및 기타 도메인에 사용되는 문자를 기계 판독 가능한 값에 매핑하기 위한 국제 표준이다. 이 매핑을 생성함으로써, UCS는 컴퓨터 소프트웨어 벤더가 UCS 인코딩 텍스트 문자열을 상호 운용하고 전송하는 것을 가능하게 한다. 유니버설 맵이기 때문에 여러 언어를 동시에 나타낼 수 있다. 이것은 복수의 레거시 문자 인코딩을 사용하는 혼동을 방지하는데, 이는 복수의 의미를 갖는 코드 순서와 같은 순서로 이어져 잘못된 코드를 선택하면 부적절하게 디코딩될 수 있다.

UCS는 100만 자 이상 인코딩할 수 있는 잠재 용량을 가지고 있다. 각 UCS 문자는 코드 포인트로 추상적으로 표현되는데, 코드 포인트는 0에서 1,114,111 사이의 정수로서, 텍스트 처리 소프트웨어의 내부 논리 내에서 각 문자를 나타내는 데 사용된다(1,114,112 = 2²⁰ + 2¹⁶ 또는 17 × 2 또는¹⁶ 16진수 110,000 코드 포인트). 2021년 9월 출시된 유니코드 14.0을 기준으로 이들 코드 포인트의 28만8,512명(26%)이 할당돼 있는데, 14만4,762명(13%), 사적 용도로 예약된 13만7,468명(12.3%), 대리용으로 2,048명, 지정 비채무자 66명 등 모두 8만5,600명(74%)이 할당되지 않았다. 인코딩된 문자의 수는 다음과 같이 구성된다.

• 144,532자의 그래픽 문자(일부 그래픽 문자 중 일부는 가시적인 글리프가 없지만 여전히 그래픽으로 표시됨
• 제어 및 서식을 위한 특수 목적 문자 230개.

ISO는 문자 이름에서 코드 포인트까지의 문자의 기본 매핑을 유지한다. 종종 "문자"와 "코드 포인트"라는 용어는 서로 바꾸어 사용된다. 그러나, 구별이 되면, 코드 포인트는 문자의 정수 즉, 그 주소라고 생각할 수 있는 것을 가리킨다. UCS 10646의 문자는 코드 포인트와 그 이름의 조합을 포함하지만 유니코드는 문자 집합에 블록, 카테고리, 스크립트 및 방향성과 같은 다른 많은 유용한 속성을 추가한다.

유니코드는 UCS 외에도 다음과 같은 구현 세부 정보도 제공한다.

1. UCS와 다른 문자 집합 간의 매핑 비교
2. 다른 언어에 대한 다른 문자 및 문자 문자열의 조합
3. 같은 줄의 텍스트가 좌우로 이동할 수 있는 양방향 텍스트를 배치하기 위한 알고리즘
4. 사례 분석 알고리즘

컴퓨터 소프트웨어 최종 사용자는 다양한 입력 방법을 통해 이러한 문자를 프로그램에 입력한다. 입력 방법은 키보드나 그래픽 문자 팔레트를 통해 사용할 수 있다.

UCS는 평면, 블록, 문자 범주 또는 문자 속성과 같이 다양한 방식으로 나눌 수 있다.^[1]

문자 참조 개요

HTML 또는 XML 숫자 문자 참조는 범용 문자 집합/유니코드 코드 포인트에 의한 문자를 말하며 형식을 사용한다.

&#nnnn;

또는

&#x흐흐흐;

여기서 nnn은 십진법 형태의 코드 포인트, hhhh는 16진법 형태의 코드 포인트다. x는 XML 문서에서 소문자여야 한다. nnn 또는 hhh는 임의의 자릿수일 수 있으며 선행 0을 포함할 수 있다. hhhh는 대문자와 소문자를 혼합할 수 있지만, 대문자는 일반적인 스타일이다.

이와는 대조적으로 문자 도면요소 참조는 원하는 문자를 대체 텍스트로 가진 도면요소 이름을 가리킨다. 엔터티는 미리 정의된(마크업 언어로 작성)이거나 DTD(문서 유형 정의)로 명시적으로 선언해야 한다. 형식은 다른 엔티티 참조와 동일하다.

&이름을 붙이다;

여기서 이름은 엔터티의 대소문자를 구분하는 이름이다. 세미콜론이 필요하다.

평면

유니코드와 ISO는 코드 포인트 집합을 17개의 평면으로 나누고 각각 65536개의 고유 문자 또는 총 1,114,112개의 문자를 포함할 수 있다. 2021년(유니코드 14.0) ISO와 유니코드 컨소시엄은 17개 평면 중 7개 면에 문자와 블록만 할당했다. 다른 것들은 비어있고 미래에 사용할 수 있도록 유보되어 있다.

대부분의 문자는 현재 첫 번째 평면인 기본 다국어 평면에 지정되어 있다. 이것은 기본 다국어 평면은 단 두 개의 옥텟으로 다루어질 수 있기 때문에 레거시 소프트웨어의 전환을 용이하게 하기 위한 것이다. 첫 번째 평면 밖의 문자는 대개 매우 전문적이거나 드물게 사용된다.

각 평면은 네 개의 최종 평면에 앞서 1, 2개의 16진수 값(0–9, A, F)에 해당된다. 따라서 U+24321은 면 2, U+4321은 면 0(적극적으로 읽음 U+04321), U+10A200은 면 16(헥스 10 = 십진수 16)에 해당한다. 하나의 평면 내에서 코드 포인트의 범위는 16진수 0000이다.FFFF, 최대 65536개의 코드 포인트를 제공한다. 평면은 코드 포인트를 해당 범위의 하위 집합으로 제한한다.

블록

유니코드는 UCS에 블록 속성을 추가하여 각 평면을 개별 블록으로 더 세분화한다. 각 블록은 "수학 연산자" 또는 "히브루 스크립트 문자"와 같은 용도에 의한 문자 그룹이다. 이전에 할당되지 않은 코드 포인트에 문자를 할당할 때, 컨소시엄은 일반적으로 유사한 문자의 전체 블록을 할당한다. 예를 들어, 동일한 스크립트에 속하는 모든 문자 또는 유사하게 자각된 모든 기호가 단일 블록에 할당된다. 또한 컨소시엄이 블록에 추가 할당이 필요할 것으로 예상할 때 블록은 할당되지 않았거나 예약된 코드 포인트를 유지할 수 있다.

UCS에서 처음 256개의 코드 포인트는 서양에서 가장 인기 있는 8비트 문자 인코딩인 ISO 8859-1의 코드 포인트와 일치한다. 그 결과 처음 128자 역시 ASCII와 동일하다. 유니코드는 이들을 라틴어 스크립트 블록으로 지칭하지만, 이 두 블록은 라틴어 스크립트 밖에서 일반적으로 유용한 많은 문자를 포함하고 있다. 일반적으로 주어진 블록의 모든 문자가 동일한 스크립트가 필요한 것은 아니며, 주어진 스크립트는 여러 개의 다른 블록에서 발생할 수 있다.

분류

유니코드는 모든 UCS 문자에 일반 카테고리 및 하위 카테고리를 할당한다. 일반적인 범주는 문자, 마크, 숫자, 문장 부호, 기호 또는 제어(즉, 형식 또는 비그래픽 문자)이다.

유형에는 다음이 포함된다.

• 현대판, 역사판, 고대판. 2021년(유니코드 14.0) 현재 UCS는 전 세계에서 사용되었거나 사용된 159개의 스크립트를 식별하고 있다. UCS의 향후 포함을 위한 다양한 승인 단계에 더 많은 것이 있다.^[2]
• 국제 음성 문자. UCS는 국제 음성 알파벳의 문자에 여러 블록(300자 이상)을 할애한다.
• 분음 부호 결합. 유니코드가 UCS와 텍스트 처리를 위한 관련 알고리즘을 설계할 때 구상한 중요한 진전은 이음매 결합의 도입이었다. 어떤 문자 문자와 결합할 수 있는 억양을 제공함으로써 유니코드와 UCS는 필요한 문자 수를 상당히 줄인다. UCS에는 사전 컴파일된 문자도 포함되어 있지만, 이 문자들은 주로 유니코드가 아닌 텍스트 처리 시스템에 대한 UCS 내 지원을 용이하게 하기 위해 포함되었다.
• 구두점. UCS는 분음 부호를 통합하는 것과 함께 문장 부호를 스크립트에 걸쳐 통합하는 것도 모색했다. 그러나 많은 스크립트는 문장 부호가 다른 스크립트에서 유사한 의미를 갖지 않는 경우 구두점을 포함하기도 한다.
• 기호. 많은 수학, 기술, 기하학적 및 기타 기호가 UCS 내에 포함되어 있다. 이것은 상징적인 글리프를 제공하기 위해 글꼴을 바꾸는 것에 의존하지 않고 고유한 코드 포인트 또는 문자로 구별되는 기호를 제공한다.
  • 통화.
  • 글자 같은. 이 기호들은 ℅과 같은 많은 일반적인 라틴어 스크립트 문자의 조합처럼 나타난다. 유니코드는 보통 문자의 합성 순서에 글리프를 대입하여 일반 텍스트로 사용할 수 있기 때문에 많은 문자 형태의 기호를 호환성 문자로 지정한다. 예를 들어, 문자 c/o의 합성 순서에 글리프 ℅을 대입한다.
  • 번호 양식. 숫자 형식은 주로 사전 계산된 분수와 로마 숫자로 구성된다. 유니코드 접근방식은 문자 시퀀스를 구성하는 다른 영역과 마찬가지로 문자를 결합하여 분수를 합성하는 유연성을 선호한다. 이 경우 분수를 생성하려면 숫자를 분수 슬래시 문자(U+2044)와 결합한다. 이 접근방식이 제공하는 유연성의 예로서 UCS에는 19개의 사전 컴파일된 부분 문자가 포함되어 있다. 그러나 가능한 분수는 무한하다. 합성 문자를 사용하여 분수의 무한도는 11자(0-9 및 분수 슬래시)로 처리된다. 어떤 문자 집합도 모든 사전 컴파일된 분수에 대한 코드 포인트를 포함할 수 없다. 이상적으로는 텍스트 시스템이 사전 컴파일된 분수(예: ⅓) 중 하나인지 또는 문자의 합성 시퀀스(예: ½) 중 하나인지에 대해 동일한 글리프를 분수에 대해 표시해야 한다. 그러나 웹브라우저는 일반적으로 유니코드와 텍스트 처리로 그렇게 정교하지 않다. 이렇게 하면 사전 컴파일된 분율과 시퀀스 프레이트를 조합할 수 있는 분율이 서로 나란히 양립할 수 있게 된다.
  • 화살.
  • 수학적인.
  • 기하학적 도형.
  • 레거시 컴퓨팅.
  • 제어 사진 많은 제어 문자의 그래픽 표현
  • 박스 드로잉.
  • 요소 차단.
  • 점자 패턴.
  • 광학 문자 인식.
  • 기술적이다.
  • 딩배트.
  • 기타 기호.
  • 이모티콘.
  • 기호 및 픽토그래프.
  • 알케미컬 기호.
  • 게임 피스(체스, 체커, 바둑, 주사위, 도미노, 마작, 카드놀이 등)
  • 체스 기호
  • 타이현징.
  • 베이징 헥사그램 기호.
• CJK. 중국, 일본, 한국(CJK), 대만, 베트남, 태국의 언어를 지원하기 위해 한자 및 기타 문자에 전념한다.
  • 래디컬과 스트로크.
  • 문자. 지금까지 UCS의 가장 큰 부분은 동아시아의 언어에서 사용되는 문자에 집중되어 있다. 이들 문자의 글라이프 표현은 그것을 사용하는 언어로 분화되었지만, UCS는 유니코드가 말하는 유니한(통일한)에서 이들 한자를 통일한다. Unihan과 함께 텍스트 레이아웃 소프트웨어는 사용 가능한 글꼴 및 이러한 유니코드 문자와 함께 작동하여 적절한 언어에 적합한 글리프를 생성해야 한다. 이러한 문자를 통일했음에도 불구하고, UCS에는 여전히 9만 2천 개가 넘는 유니한 문자가 포함되어 있다.
• 음악 표기법.
• 듀포판 속기.
• 서튼 서명.
• 호환성 문자. UCS의 몇 개의 블록은 거의 전적으로 호환성 문자에 할당된다. 호환성 문자는 유니코드가 하는 방식대로 문자와 글립자를 구별하지 않는 레거시 텍스트 처리 시스템을 지원하기 위해 포함된 문자들이다. 예를 들어, 많은 아랍어 문자는 단어의 끝에 글자가 나타날 때와 단어의 시작에 글자가 나타날 때 다른 글자로 표현된다. 유니코드의 접근방식은 내부 기계 텍스트 처리와 저장이 용이하도록 동일한 문자에 이러한 문자를 매핑하는 것을 선호한다. 이 접근방식을 보완하기 위해 텍스트 소프트웨어는 문자에 대한 문자의 표시에 대해 문자의 문맥에 따라 다른 글립자 변형을 선택해야 한다. 이러한 호환성을 위해 4000자 이상이 포함되어 있다.
• 컨트롤 문자.
• 대리. UCS에는 대리 코드 포인트 쌍을 위한 기본 다국어 평면(BMP)에 2048개의 코드 포인트가 포함되어 있다. 이러한 대리인들은 16개의 다른 평면에 있는 어떤 코드 포인트도 두 개의 대리 코드 포인트를 사용하여 처리할 수 있도록 한다. 이것은 UTF-16과 같은 16비트 인코딩 내에서 20.1비트 UCS를 인코딩하는 간단한 내장 방법을 제공한다. 이러한 방식으로 UTF-16은 단일 16비트 바이트로 BMP 내의 문자를 나타낼 수 있다. 그런 다음 BMP 외부의 문자는 대리모 쌍을 사용하여 두 개의 16비트 바이트(총 4 옥텟)를 사용하여 인코딩된다.
• 개인용. 이 컨소시엄은 운영체제 및 폰트 공급업체뿐만 아니라 다양한 커뮤니티 내에서 문자를 할당할 수 있는 몇 개의 개인용 블록과 평면을 제공한다.
• 무첨가제. 컨소시엄은 특정 코드 포인트에 캐릭터가 할당되지 않을 것을 보장하고 이러한 비문자 코드 포인트에 전화를 건다. 각 평면의 마지막 두 코드 포인트(FE 및 FF )는 그러한 코드 포인트다. 첫 번째 평면인 기본 다국어 평면 전체에 다른 몇 개가 섞여 있다.

특수 목적 문자

유니코드는 10만 자 이상을 코드화한다. 그 대부분은 선형 텍스트로 처리하기 위한 그래프를 나타낸다. 그러나 어떤 것들은 그래프를 나타내지 않거나, 또는 그래프로써는 예외적인 처리가 필요하다.^[3][4] 레거시 왕복 기능을 위해 포함된 ASCII 제어 문자 및 기타 문자와는 달리, 이러한 다른 특수 목적 문자는 일반 텍스트에 중요한 의미를 부여한다.

일부 특수 문자는 0 너비의 조인자 및 0 너비의 비 조인자와 같이 텍스트 레이아웃을 변경할 수 있지만, 다른 문자는 텍스트 레이아웃에 전혀 영향을 미치지 않고 대신 텍스트 문자열이 결합, 일치 또는 처리되는 방식에 영향을 미친다. 정교한 텍스트 레이아웃 소프트웨어가 주변의 간격을 미묘하게 조정하도록 선택할 수 있지만, 수학적 비사물과 같은 다른 특수 목적 문자는 일반적으로 텍스트 렌더링에 영향을 미치지 않는다.

유니코드는 유니코드 텍스트를 렌더링할 때 글꼴과 텍스트 레이아웃 소프트웨어(또는 "엔진") 사이의 노동 분담을 지정하지 않는다. OpenType 또는 Apple Advanced Typeography와 같은 보다 복잡한 글꼴 형식은 글리프의 문맥적 대체와 위치를 제공하므로, 간단한 텍스트 레이아웃 엔진은 글리프 선택과 배치의 모든 결정을 위해 글꼴에 전적으로 의존할 수 있다. 같은 상황에서 보다 복잡한 엔진은 최적의 렌더링이라는 자체 아이디어를 달성하기 위해 글꼴의 정보와 자체 규칙을 결합할 수 있다. 유니코드 규격의 모든 권장사항을 이행하기 위해서는 문맥 대체 및 위치 지정 규칙이 일부 글꼴 형식으로 존재하지 않으며 나머지 부분에는 선택 사항이기 때문에 텍스트 엔진이 어떤 수준의 정교한 글꼴로 작동하도록 준비되어야 한다. 분수 슬래시를 예로 들 수 있다. 복잡한 글꼴은 분수 슬래시 문자가 있는 곳에 위치 지정 규칙을 제공하여 분수를 만들 수도 있고 그렇지 않을 수도 있지만, 간단한 형식의 글꼴은 그렇지 않다.

바이트 순서 표시

텍스트 파일이나 스트림의 머리 부분에 나타날 때, 바이트 순서 표시(BOM) U+FEFF는 인코딩 양식과 그 바이트 순서를 암시한다.

스트림의 첫 번째 바이트가 0xFE이고 두 번째 바이트가 0xFF인 경우 스트림의 텍스트는 UTF-8에서 유효하지 않기 때문에 UTF-8로 인코딩될 가능성이 없다. 또한 16비트 리틀 엔디안 워드로 읽히는 0xFE, 0xFF가 U+FFE가 될 것이기 때문에 리틀 엔디안 바이트 순서에서 UTF-16일 가능성이 높지 않다. 또한 이 시퀀스는 UTF-32 인코딩의 어떠한 배열에도 의미가 없으므로 요약하면 텍스트 스트림이 빅엔디안 바이트 순서에서 UTF-16으로 인코딩되었다는 상당히 신뢰할 수 있는 지표 역할을 한다. 반대로 처음 두 바이트가 0xFF, 0xFE인 경우 텍스트 스트림이 UTF-16LE로 인코딩되는 것으로 가정할 수 있는데, 이는 16비트 리틀 엔디안 값으로 읽히면서 바이트가 예상된 0xFEFF 바이트 순서 마크를 산출하기 때문이다. 그러나 다음 두 바이트가 모두 0x00이면 이러한 가정은 의심스럽다. 텍스트는 null 문자(U+0000)로 시작하거나, 올바른 인코딩은 실제로 UTF-32LE이며, FFE 00는 전체 4바이트 시퀀스 FFE 00가 하나의 문자인 BOM이다.

U+FEFF에 해당하는 UTF-8 시퀀스는 0xEF, 0xBB, 0xBF이다. 이 시퀀스는 다른 유니코드 인코딩 형식에서는 의미가 없으므로 스트림이 UTF-8로 인코딩되었음을 나타내는 역할을 할 수 있다.

유니코드 규격은 텍스트 스트림에서 바이트 순서 표시를 사용할 필요가 없다. 또한, 인코딩 형식을 신호하는 다른 방법이 이미 사용되고 있는 상황에서는 이러한 방식을 사용하지 말아야 한다고 명시하고 있다.

수학불가침

주로 수학의 경우, 보이지 않는 구분자(U+2063)는 i⁣j와 같은 2차원 지수에서처럼 구두점이나 공백이 생략될 수 있는 문자 사이에 구분자를 제공한다. 보이지 않는 시간(U+2062)과 기능적용(U+2061)은 연산을 나타내는 글리프 없이 용어의 곱셈이나 함수의 적용을 암시하는 수학 텍스트에서 유용하다. 유니코드 5.1은 또한 Mathemical Invisible Plus 문자(U+2064)를 도입하는데, 이 문자는 적분 뒤에 분수까지 오는 정수 숫자는 그 합계를 나타내야 하지만, 그들의 제품은 나타내지 말아야 함을 나타낼 수 있다.

분수 슬래시

분수 슬래시 문자(U+2044)는 유니코드 표준에서 특별한 동작을 가진다. (^[5]섹션 6.2, 기타 문장 부호)

분수 슬래시를 사용하여 구축된 분수의 표준 형식은 다음과 같이 정의된다: 하나 이상의 소수 자릿수(일반 카테고리 = Nd), 그 다음에 분수 슬래시, 그리고 하나 이상의 소수 자릿수 순서가 따른다. 그러한 분수는 ¾과 같은 단위로 표시되어야 한다. 디스플레이 소프트웨어가 단위에 분수를 매핑할 수 없는 경우, 폴백(예: 3/4)으로 단순 선형 시퀀스로 표시할 수도 있다. 분수를 이전 숫자와 분리하려면 적절한 너비(보통, 얇, 0 너비 등)를 선택하여 공간을 사용할 수 있다. 예를 들어 1 + ZERO WIDE SPACE + 3 + PRATE SLASH + 4가 1㎛로 표시된다.

이 유니코드 권장사항을 따름으로써, 텍스트 처리 시스템은 일반 텍스트에서만 정교한 기호를 산출한다. 여기서 분수 슬래시 문자의 존재는 레이아웃 엔진에 슬래시 앞과 뒤에 있는 모든 연속된 숫자로 분수를 합성하도록 지시한다. 실제로 글꼴과 레이아웃 엔진 간의 복잡한 상호 작용으로 인해 결과가 달라진다. 단순한 텍스트 레이아웃 엔진은 분수를 전혀 합성하지 않는 경향이 있으며, 대신 유니코드 예비 구성표에서 설명한 선형 시퀀스로 글리프를 그린다.

보다 정교한 레이아웃 엔진은 유니코드의 권고를 따를 수도 있고, 혹은 폰트의 자체적인 분수 합성 지침에 의존할 수도 있다는 두 가지 실용적인 선택에 직면해 있다. 폰트의 지시를 무시함으로써 레이아웃 엔진은 유니코드의 권장 동작을 보장할 수 있다. 폰트의 지시를 따름으로써, 배치 엔진은 더 나은 타이포그래피를 얻을 수 있다. 왜냐하면 그 특정한 크기의 특정한 폰트에 자리 배치와 모양이 조정될 것이기 때문이다.

글꼴의 지시사항을 따르는 것의 문제는 더 단순한 글꼴 형식이 부분 합성 동작을 명시할 방법이 없다는 것이다. 한편, 더 복잡한 형식은 부분합성 동작을 명시하기 위해 글꼴을 필요로 하지 않으며 따라서 많은 형식은 그렇지 않다. 복잡한 형식의 대부분의 글꼴은 레이아웃 엔진에 "½"과 같은 일반 텍스트 시퀀스를 사전 컴파일된 """ 글리프로 대체하도록 지시할 수 있다. 그러나 그들 중 다수는 분수를 합성하기 위한 지침을 발행하지 않을 것이기 때문에, "221⁄225"와 같은 일반 텍스트 문자열은 22½25로 렌더링할 수 있다(합성되지 않고 ½은 사전 컴파일된 분수를 대체함). 이와 같은 문제들 앞에서, 권장 유니코드 동작에 의존하고자 하는 사람들은, 폰트와 관계없이 유니코드의 권장 동작을 생산하는 것으로 알려진 분수를 합성하는 것으로 알려진 글꼴이나 텍스트 레이아웃 소프트웨어를 선택해야 한다.

양방향 중립 형식

쓰기 방향은 유니코드 문자열에서 문자의 전진 진행과 관련하여 글립스가 페이지에 배치되는 방향이다. 영어와 다른 라틴어 스크립트 언어는 왼쪽에서 오른쪽으로 쓰기 방향을 가지고 있다. 아랍어와 히브리어와 같은 몇몇 주요 쓰기 대본들은 오른쪽에서 왼쪽으로 쓰기 방향을 가지고 있다. 유니코드 명세서는 각 문자에 방향 유형을 할당하여 텍스트 프로세서에 문자의 순서가 페이지에서 어떻게 정렬되어야 하는지를 알려준다.

어휘 문자(즉, 문자)는 일반적으로 단일 쓰기 대본에 특정되지만, 일부 기호와 문장 부호는 많은 쓰기 대본에 사용된다. 유니코드는 레퍼토리에서 방향성 유형별로만 다른 중복 기호를 만들 수 있었지만, 대신 이를 통일해 중립 방향 유형을 할당하는 방식을 택했다. 그들은 인접한 문자로부터 렌더링 시간에 방향을 얻는다. 또한 이러한 문자 중 일부는 오른쪽에서 왼쪽 텍스트로 사용할 때 글리프를 미러 이미지로 렌더링해야 함을 나타내는 비디 미러 특성을 가지고 있다.

중립 문자의 렌더 시간 방향 유형은 방향 변화 사이의 경계에 마크를 배치할 때 모호한 상태를 유지할 수 있다. 이를 해결하기 위해 유니코드는 방향성이 강하고 글라이프가 연결되어 있지 않으며 양방향 텍스트를 처리하지 않는 시스템에 의해 무시 불가능한 문자를 포함한다.

• 아랍어 문자 표시(U+061C)
• 왼쪽에서 오른쪽으로 표시(U+200E)
• 오른쪽에서 왼쪽으로 표시(U+200F)

좌우 표시로 양방향 중립 문자를 둘러싸면 캐릭터가 좌우로 움직이게 되고, 좌우 표시로 둘러싸면 좌우로 움직이게 된다. 이러한 문자의 동작은 유니코드의 양방향 알고리즘에 자세히 설명되어 있다.

양방향 일반 형식

유니코드는 저작자의 개입을 최소화하면서 좌우로 흐르는 다국어, 다국어, 다국어, 심지어 좌우로 흐르는 텍스트까지 처리하도록 설계되어 있지만, 양방향 텍스트의 혼합이 복잡해질 수 있는 특수한 상황이 있어 작성자 통제가 더욱 필요하다. 이러한 상황에서 유니코드는 오른쪽에서 왼쪽으로 텍스트의 복잡한 포함을 제어하기 위해 5개의 문자를 포함하며, 그 반대의 경우도 마찬가지다.

• 좌우 임베딩(U+202A)
• 좌우 임베딩(U+202B)
• 팝 방향 포맷(U+202C)
• 왼쪽에서 오른쪽으로 오버라이드(U+202D)
• 오른쪽에서 왼쪽으로 오버라이드(U+202E)
• 좌우 격리(U+2066)
• 오른쪽에서 왼쪽으로 격리(U+2067)
• 첫 번째 강한 격리(U+2068)
• 팝 방향 격리(U+2069)

선형 주석 문자

• 선형 주석 앵커(U+FF9)
• 선형 주석 구분 기호(U+FFA)
• 선형 주석 터미네이터(U+FFB)

스크립트별

• 접두사 형식 제어
  • 아랍어 번호 기호(U+0600)
  • 아랍어 시그니처 사나(U+0601)
  • 아랍어 각주 마커(U+0602)
  • 아랍어 기호 Safha(U+0603)
  • 아랍어 기호 Samvat(U+0604)
  • 위의 아랍어 번호 표시(U+0605)
  • 아랍어 끝 아야(U+06DD)
  • Syriac 약어 마크(U+070F)
  • 아랍어 파운드 표시 이상(U+0890)
  • 아랍어 Piastre 표시 위(U+0891)
  • 카이티 번호 기호(U+110BD)
  • 위 Kaithi 번호 기호(U+110CD)
• 이집트 상형문자
  • 이집트 상형문자 수직 결합자(U+13430)
  • 이집트 상형문자 수평 조인자(U+13431)
  • 이집트 상형문자 삽입 시작(U+13432)
  • 맨 아래 시작에 이집트 상형문자 삽입(U+13433)
  • 상단 끝에 이집트 상형문자 삽입(U+13434)
  • 아래쪽 끝에 이집트 상형문자 삽입(U+13435)
  • 이집트 상형문자 오버레이 중간(U+13436)
  • 이집트 상형문자 시작 세그먼트(U+13437)
  • 이집트 상형문자 끝 세그먼트(U+13438)
• 브라미
  • 브라흐미 번호 조이너(U+1107F)
• 브라흐미에서 파생된 스크립트 데드 문자 구성(비라마 및 유사한 분음 문자)
  • 데바나가리 시그니처 비라마(U+094D)
  • 벵골 사인 비라마(U+09CD)
  • 구르무키 시그니처 비라마(U+0A4D
  • 구자라티 시그니처 비라마(U+0ACD
  • 오리야 시그니처 비라마(U+0B4D)
  • 타밀 시그니처 비라마(U+0BCD)
  • 텔루구 시그니처 비라마(U+0C4D)
  • 칸나다 시그니처 비라마(U+0CCD)
  • 말라얄람 부호 수직 막대 비라마(U+0D3B)
  • 말라얄람 사인 원형 비라마(U+0D3C)
  • 말라얄람 시그니처 비라마(U+0D4D)
  • 신할라 사인 알라쿠나(U+0DCA)
  • 타이 문자 인투(U+0E3A)
  • 타이 문자 야마칸(U+0E4E)
  • 라오사인팔리비라마(U+0EBA)
  • 미얀마 사인 비라마(U+1039)
  • Tagalog Sign Virama(U+1714)
  • Tagalog Sign PamudPod(U+1715)
  • 하누누 사인 파무드팟(U+1734)
  • 크메르 사인 비리암(U+17D1)
  • 크메르 사인 쿤(U+17D2)
  • 타이탐 사인 사코트(U+1A60)
  • 타이탐 시그니처 라하암(U+1A7A)
  • 발렌시아 아데그 아데그 (U+1B44)
  • 순대 사인 파마아에(U+1BAA)
  • 선다이스 시그니처 비라마(U+1BAB)
  • 바타크 판골라트(U+1BF2)
  • 바탁 파논고난(U+1BF3)
  • 실로티 나그리 사인 하산타(U+A806)
  • 실로티 나그리 사인 대체 하산타(U+A82C)
  • Saurashtra Sign Virama(U+A8C4)
  • 레장 비라마(U+A953)
  • 자바 팡콘(U+A9C0)
  • 메테이 마예크 비라마(U+AAF6)
  • 하로시 비라마(U+10A3F)
  • 브라미 비라마 (U+11046)
  • 브라미 사인 올드 타밀 비라마(U+11070)
  • 카이티 시그니처 비라마(U+110B9)
  • 차크마 비라마(U+11133)
  • 샤라다 시그니 비라마(U+111C0)
  • 코지키 시그니처 비라마(U+11235)
  • 후다와디 시그니 비라마(U+112)EA)
  • 그란타 시그니처 비라마(U+1134D)
  • 뉴아 시그니처 비라마(U+11442)
  • 티루타 시그니처 비라마(U+114C2)
  • Siddham Sign Virama(U+115BF)
  • 모디 시그니처 비라마(U+1163F)
  • 타크리 시그니처 비라마(U+116B6)
  • 아옴 사인 킬러(U+1172B)
  • 도그라 시그니처 비라마(U+11839)
  • 디브 아쿠루 사인 할란타(U+1193D)
  • 디브 아쿠루 비라마(U+1193E)
  • 난디나가리 시그니처 비라마(U+119E0)
  • 자나바자르 스퀘어 시그니처 비라마(U+11A34)
  • 자나바자르 광장 서브조이너(U+11A47)
  • Soyombo Subjoiner(U+11A99)
  • 바이크스키 시그니처 비라마(U+11C3F)
  • 마사람 곤디 사인 할란타 (U+11D44)
  • 마사람 곤디 비라마(U+11D45)
  • 군잘라 곤디 비라마(U+11D97)
• 다른 기능이 있는 과거 Viramas
  • 티베트 마르크 할란타(U+0F84)
  • 미얀마 서명 Asat(U+103A)
  • 임부사인사이(U+193B)
  • 메테이 마예크 아푼 이예크 (U+ABED)
  • 차크마마야아 (U+11134)
• 몽골 변형 선택기
  • 몽골 자유 변형 선택기 1개(U+180B)
  • 몽골 자유 변형 선택기 2(U+180C)
  • 몽골 자유 변형 선택기 3개(U+180D)
  • 몽골모음 구분 기호(U+180E)
• 일반 변동 선택기
  • 가변 선택기-1 ~ -16(U+FE00–U+FE0F)
  • 변동 선택기-17 ~ -256(U+E0100)–U+E01EF)
• 태그 문자(U+E0001 및 U+E0020)–U+E007F)
• 티피나흐
  • 티피나 자음 결합기(U+2D7F)
• 오함
  • 오함 스페이스 마크(U+1680)
• 이데오그래픽
  • 이데오그래픽 변동 표시기(U+303E)
  • 이미지 설명(U+2)FF0-U+2FFB)
• 음악 형식 제어
  • 음악 기호 시작 빔(U+1D173)
  • 음악 기호 끝 빔(U+1D174)
  • 음악 기호 시작 타이(U+1D175)
  • 음악 기호 끝 타이(U+1D176)
  • 음악 기호 시작 슬러(U+1D177)
  • 음악 기호 끝 슬러(U+1D178)
  • 음악 기호 시작 구(U+1D179)
  • 음악 기호 끝 구(U+1D17A)
• 속기 형식 제어
  • 속기 형식 문자 겹침(U+1BCA0)
  • 속기 형식 계속 겹침(U+1BCA1)
  • 단축 포맷 다운 스텝(U+1BCA2)
  • 속기 형식 지정 단계(U+1BCA3)
• 사용되지 않는 대체 형식
  • 대칭 스왑 금지(U+206A)
  • 대칭 스와핑 활성화(U+206B)
  • 아랍어 폼 쉐이핑 금지(U+206C)
  • 아랍어 폼 쉐이핑(U+206D) 활성화
  • 국가별 숫자 모양(U+206E)
  • 공칭 자릿수 형상(U+206F)

다른이들

• 객체 교체 문자(U+FFFC)
• 대체 문자(U+FFFD)

문자 대 코드 포인트

'문자'라는 용어가 잘 정의되어 있지 않고, 우리가 주로 언급하고 있는 것이 바로 '그래프'이다. 그래핀은 그 글립프로 시각적으로 표현된다. 사용된 서체(흔히 폰트라고 잘못 언급됨)는 동일한 문자의 시각적 변화를 묘사할 수 있다. 서로 다른 두 개의 글자가 정확히 같은 글립자를 가질 수도 있고, 시각적으로 너무 가까이 있어서 일반 독자들이 구별할 수 없을 수도 있다.

그래프는 거의 항상 하나의 코드 포인트로 표현된다. 예를 들어, 라틴 대문자 A는 코드 포인트 U+0041로만 표현된다.

DIAERESIS가 있는 그래프는 문자를 둘 이상의 코드 포인트로 나타낼 수 있는 예다. U+00C4 또는 U+0041U+0308일 수 있다. U+0041은 익숙한 A이고 U+0308은 COMB이다.INING DIAERESIS ̈, 결합 분음 부호.

결합 표시가 비결합 마크 코드 포인트에 인접할 경우, 텍스트 렌더링 애플리케이션은 결합 마크를 다른 코드 포인트로 대표되는 글리프에 겹쳐서 규칙 집합에 따라 그래프를 형성해야 한다.^[6]

따라서 BAEM이라는 단어는 세 개의 제자일 것이다. 캐릭터가 실제로 어떻게 구성되느냐에 따라 세 가지 이상의 코드 포인트로 구성될 수 있다.

공백, 조인자 및 구분자

유니코드는 상호운용성 지원을 위해 공백으로 간주되는 문자 목록을 제공한다. 소프트웨어 구현 및 기타 표준은 약간 다른 문자 집합을 나타내기 위해 이 용어를 사용할 수 있다. 예를 들어, 자바는 유니코드가 공백이라고 하더라도 U+00A0 NO-BREAK SPACE 또는 U+0085 <control-0085>(NEXT LINE)를 공백으로 간주하지 않는다. 공백 문자는 일반적으로 프로그래밍 환경을 위해 지정된 문자다. 종종 그들은 그러한 프로그래밍 환경에서 통사적 의미를 갖지 못하고 기계 통역사에 의해 무시된다. 유니코드는 레거시 제어 문자 U+0009 ~ U+000D 및 U+0085를 공백 문자로 지정하고, 일반 범주 속성 값이 구분 기호로 지정된 모든 문자를 지정한다. 유니코드 14.0 기준으로 총 25개의 공백 문자가 있다.

결합자 및 비 결합자 그래프

0폭 조인(U+200D)과 0폭 비조인(U+200C)은 글리프의 결합과 결선을 제어한다. 조인자는 다른 방법으로 결합하거나 래깅하지 않는 문자를 유발하지 않지만, 비 조인자와 결합할 경우 이러한 문자를 사용하여 주변 두 결합 또는 결합 문자의 결합 및 연결 속성을 제어할 수 있다. 콤비네이션 그래핀 조이너(U+034F)는 두 개의 기본 문자를 하나의 공통 베이스 또는 디그그래프로 구분하는 데 사용되며, 주로 기초 텍스트 처리, 문자열의 결합, 케이스 폴딩 등에 사용된다.

단어 결합자 및 구분자

가장 일반적인 단어 구분자는 공간(U+0020)이다. 그러나 단어간의 단절과 줄 바꿈 알고리즘에 참여하는 다른 단어 조인자와 구분자도 있다. No-Break Space(U+00A0)도 글립 없이 기준선 전진을 생성하지만 라인 전열을 활성화하기보다는 억제한다. 제로 와이드 스페이스(U+200B)는 줄 바꿈을 허용하지만 공백은 제공하지 않는다. 즉, 어떤 의미에서는 분리하기 보다는 결합하는 두 단어로 되어 있다. 마지막으로 Word Joiner(U+2060)는 줄 바꿈을 억제하고 기준선 진전에 의해 생성되는 백색 공간을 전혀 포함하지 않는다.

	베이스라인 어드밴스	기준선 진전 없음
줄 바꿈 허용 (분리자)	스페이스 U+0020	제로 폭 공간 U+200B
금지 라인 차단 (조인)	중단 없는 공간 U+00A0	워드 조이너 U+2060

기타 구분자

• 라인 구분 기호(U+2028)
• 문단 구분 기호(U+2029)

이들은 캐리지 리턴(U+000A), 라인피드(U+000D), 넥스트 라인(U+0085)과 같은 레거시 인코딩된 ASCII 제어 문자와는 무관하게 네이티브 단락과 라인 분리기를 가진 유니코드를 제공한다. 유니코드는 아마도 유니코드 일반 텍스트 처리 모델의 일부가 아닌 다른 ASCII 형식 제어 문자를 제공하지 않는다. 이러한 레거시 포맷 제어 문자는 Tab(U+0009), Line Tabulation 또는 Vertical Tab(U+000B), Form Feed(U+000C)를 포함하며, 페이지 구분으로도 생각된다.

공간

일반적으로 키보드의 스페이스바에 의해 입력되는 스페이스 문자(U+0020)는 많은 언어에서 단어 구분 기호로 의미론적으로 사용된다. 기존 이유로 UCS에는 공간 문자의 호환성 등가물인 다양한 크기의 공간도 포함된다. 다양한 폭의 이러한 공간들이 타이포그래피에서 중요한 반면, 유니코드 처리 모델은 그러한 시각적 효과를 풍부한 텍스트, 마크업 및 기타 프로토콜로 처리할 것을 요구한다. 그것들은 주로 다른 문자 집합 인코딩으로부터 무손실 왕복 트랜스코딩을 처리하기 위해 유니코드 레퍼토리에 포함되어 있다. 이러한 공간에는 다음이 포함된다.

1. En Quad(U+2000)
2. Em Quad(U+2001)
3. En Space(U+2002)
4. Em Space(U+2003)
5. 전자당 3개 공간(U+2004)
6. 전자당 4개 공간(U+2005)
7. 전자당 6개 공간(U+2006)
8. 그림 공간(U+2007)
9. 구두점 공간(U+2008)
10. 씬 스페이스(U+2009)
11. 헤어 스페이스(U+200A)
12. 중간 수학적 공간(U+205F)

원래 ASCII 공간 외에 다른 공간은 모두 호환성 문자다. 이러한 맥락에서 이는 그들이 텍스트에 의미론적 내용을 효과적으로 추가하지 않고 대신 스타일링 제어를 제공한다는 것을 의미한다. 유니코드 내에서 이러한 비대안적 스타일링 컨트롤은 흔히 리치 텍스트라고 불리며 유니코드의 목표의 추진력 밖에 있다. 서로 다른 맥락에서 다른 공간을 사용하기보다는 지능형 텍스트 레이아웃 소프트웨어를 통해 이 스타일링을 처리해야 한다.

세 개의 다른 쓰기 시스템별 단어 구분자는 다음과 같다.

• 몽골모음 구분 기호(U+180E)
• 이데오그래픽 공간(U+3000): 이데오그래픽 구분자 역할을 하며 일반적으로 이데오그래프와 같은 폭의 백색 공간으로 표현된다.
• 오함 스페이스 마크(U+1680): 이 문자는 간혹 글립과 함께 표시되며, 다른 때는 백색 공간으로만 표시되기도 한다.

줄 바꿈 제어 문자

몇 개의 문자는 줄 바꿈을 억제하여 줄 바꿈을 제어하는 데 도움을 주도록 설계되거나("샤이 하이픈"이라고도 함) 소프트 하이픈(U+00AD)과 같은 줄 바꿈을 제안한다. 스타일링을 위해 디자인되었지만, 그러한 캐릭터는 아마도 그들이 가능하게 하는 복잡한 유형의 라인 파쇄에 필수불가결한 것일 것이다.

브레이크 억제

1. 깨지지 않는 하이픈(U+2011)
2. 중단 없는 공간(U+00A0)
3. 티베트 문자 구분 기호 Tsheg Bstar(U+0F0C)
4. 좁은 깨지지 않는 공간(U+202F)

브레이크 억제 문자는 Word Joiner U+2060으로 포장된 문자 시퀀스와 동등하게 된다. 그러나 단어 가입자는 줄 바꿈이 그러한 줄 바꿈을 억제할 수 있는 문자 앞에나 뒤에 붙을 수 있다.

사용 중단

1. 소프트 하이픈(U+00AD)
2. 티베트어 마크 인터실라빅 체그(U+0F0B)
3. 제로 폭 공간(U+200B)

끊기 억제 및 끊기 활성화 문자는 모두 다른 구두점 및 공백 문자와 함께 참여하여 텍스트 영상촬영 시스템이 유니코드 라인 끊기 알고리즘 내에서 줄 바꿈을 결정할 수 있도록 한다.^[7]

코드 포인트의 종류

어떤 종류의 목적이나 용도에 주어진 모든 코드 포인트는 지정된 코드 포인트로 간주된다. 그 중 추상적인 성격에 배정되거나 다른 목적을 위해 지정될 수 있다.

할당된 문자

실제 사용 시 코드 포인트의 대부분은 추상 문자에 할당되었다. 여기에는 특정 목적을 위해 유니코드 표준에 의해 공식적으로 지정되지는 않았지만, 의미 있는 정보 교환이 이루어지기 위해 어떻게 해석되어야 하는지에 대해 송신자와 수신자가 사전에 합의하도록 요구하는 개인용도 문자가 포함된다.

개인용도 문자

UCS에는 137,468개의 개인용도 문자가 포함되어 있으며, 이는 각각 PUA(개인용도구역)라고 하는 세 개의 블록에 걸쳐 개인용도 코드 포인트다. 유니코드 표준은 PUA 내의 코드 포인트를 합법적인 유니코드 문자 코드로 인식하지만, 어떠한 (추상) 문자도 할당하지 않는다. 대신에, 개인, 조직, 소프트웨어 벤더, 운영 체제 벤더, 글꼴 벤더 및 최종 사용자의 커뮤니티는 그들이 적합하다고 생각하는 대로 자유롭게 사용할 수 있다. 폐쇄형 시스템 내에서 PUA의 문자는 모호하지 않게 작동할 수 있으며, 이러한 시스템이 유니코드에 정의되지 않은 문자나 글립스를 나타낼 수 있다.^[8] 공공 시스템에서는 등록부가 없고 여러 조직이 다른 목적으로 동일한 코드 포인트를 채택하는 것을 막을 방법이 없기 때문에 이러한 코드 사용이 더 문제가 된다. 이러한 갈등의 한 예는 애플 로고에 U+F8FF를 사용하는 것과 콘스크립트 유니코드 레지스트리가 U+F8FF를 사용하는 것이다. 클링온 문자에서 클링온 미라화 ^[9]글리프

기본 다국어 평면(평면 0)은 U+E000에서 U+F8FF에 이르는 PUA Private Use Area라는 이름의 6,400개의 개인 사용자 문자를 포함하고 있다. 전용 평면 15 및 16면에는 각각 65,534개의 전용 문자(각 평면의 최종 두 개의 코드 포인트가 비문자임)의 PUA가 있다. 이는 U+F0000 ~ U+FFFD 범위의 보조 개인 사용 영역-A와 U+100000 ~ U+10FFFD 범위의 보조 개인 사용 영역-B이다.

PUA는 특정 아시아 인코딩 시스템으로부터 물려받은 개념이다. 이 시스템들은 일본인들이 가이지라고 부르는 것(글꼴에서 보통 찾을 수 없는 문자)을 애플리케이션별 방식으로 인코딩하기 위한 사적인 사용 영역이 있었다.

대리모

UCS는 16비트 이상의 바이트 표현에 의존하지 않고 초기 기본 다국어 평면 외부의 문자를 처리하기 위해 대리인을 사용한다.^[10] 1024개의 "높은" 대용품이 있다(D800–DB).FF) 및 1024 "낮은" 대용물(DC00–DFFF). 한 쌍의 대리인을 결합하면 다른 모든 평면의 나머지 문자(1024 × 1024 = 다른 16개 평면의 1048576 코드 포인트)를 처리할 수 있다. UTF-16에서는 항상 쌍으로 나타나야 하며, 높은 대리모에 이어 낮은 대리모로서 32비트를 사용하여 하나의 코드 포인트를 표시해야 한다.

서로게이트 쌍은 코드 포인트를 나타낸다.

10000₁₆ + (H - D800₁₆) × 400₁₆ + (L - DC00₁₆)

여기서 H와 L은 각각 상위 및 하위 대리점의 숫자 값이다.

DB80-DB 범위의 높은 대리모 값 이후FF는 항상 Private Use 평면에서 값을 생성하며, 높은 대리점 범위는 (정상) 높은 대리점(D800–DB7F)과 "고사용 대리점"(DB80–DB)로 더 세분화할 수 있다.FF).

분리된 대리 코드 포인트는 일반적인 해석을 하지 않으며, 따라서 이 범위에 대한 문자 코드 차트나 이름 목록이 제공되지 않는다. 파이톤 프로그래밍 언어에서 개별 대리모 코드는 유니코드 문자열에 코드화할 수 없는 바이트를 포함하는데 사용된다.^[11]

무차자

비문자(non parameter)란 66개의 코드 포인트(labeled)를 말한다. <not a character>)은 내부 사용을 위해 영구적으로 예약되었으며, 따라서 캐릭터에 절대 할당되지 않을 것을 보장한다.^[12] 17대의 각 비행기에는 두 개의 끝 코드 포인트가 무차장으로 따로 설정되어 있다. 따라서, 비촉자: BMP의 U+FFE 및 U+FFFFF, 면 1의 U+1FFF, 면 16의 U+10FFF까지, 총 34개의 코드 포인트에 대해. 또한 BMP에는 32개의 비문자 코드 포인트(U+FDD0)가 연속적으로 존재한다.따라서 U+FDEF. 소프트웨어 구현은 이러한 코드 포인트를 내부용으로 자유롭게 사용할 수 있다. 비문자의 특히 유용한 예로는 코드 포인트 U+FFE가 있다. 이 코드 포인트에는 바이트 순서 표시(U+FEFF)의 역 UTF-16/UCS-2 바이트 순서가 있다. 텍스트 스트림에 이 비문자가 포함된 경우, 텍스트가 잘못된 엔디안성으로 해석되었음을 잘 나타낸다.

3.1.0에서 6.3.0까지의 유니코드 표준 버전들은 비채택자가 "교체되어서는 안 된다"고 주장했다. 이후 이 표준의 Corrigendum #9는 이것이 "부적절한 과잉 거부"로 이어져 "[비채택자] 상호교환에서 불법이 아니며 잘못된 형식의 유니코드 텍스트를 야기하지 않는다"는 것을 명확히 하고, 원래의 주장을 삭제했다.

예약 코드 포인트

다른 모든 코드 포인트는 지정되지 않은 코드 포인트로, 예비 코드 포인트라고 한다. 이 코드 포인트는 유니코드 표준의 향후 버전에서 특정한 용도로 지정될 수 있다.

문자, 그래핀 군집 및 글리프

다른 많은 문자 집합이 글자의 가능한 모든 글립프 표현에 문자를 할당하는 반면에 유니코드는 글립스와 별도로 문자를 처리하려고 한다. 이러한 구별이 항상 명확하지는 않지만, 몇 가지 예가 그 구별을 설명하는데 도움이 될 것이다. 종종 텍스트의 가독성을 향상시키기 위해 두 문자를 타이포그래픽으로 결합할 수 있다. 예를 들어, 세 글자 순서 "ffi"는 단일 글리프로 처리될 수 있다. 다른 문자 집합은 종종 "f"와 "i"라는 개별 문자 외에 이 글리프에 코드 포인트를 할당한다.

또한 유니코드는 렌더링할 때 단일 글리프가 되는 별도의 문자로 디아크리틱 수정 문자를 접근한다. 예를 들어, diaeresis가 있는 "o"는 "o"이다. 전통적으로 다른 문자 집합은 각 언어에서 사용되는 각 diacritic 수정 문자에 대해 고유한 문자 코드 포인트를 할당했다. 유니코드는 어떤 문자와도 결합할 수 있도록 하여 보다 유연한 접근법을 만들려고 한다. 이는 문자 집합에 필요한 활성 코드 포인트 수를 현저히 줄일 수 있는 잠재력을 가지고 있다. 예를 들어, 라틴 문자를 사용하고 대소문자 "a", "o", "u"와 대소문자를 조합한 언어를 생각해 보자. 유니코드 접근법을 사용하면 라틴어 문자인 "a", "A", "o", "O", "u" 및 "U"와 함께 사용할 문자 집합에 diaereis diacritic 문자만 추가하면 된다. 모두 7자. 레거시 문자 집합은 사전 컴파일된 문자 6개와 함께 디에레시스가 없는 문자에 사용하는 코드 포인트 6개(총 12개 문자 코드 포인트)를 추가해야 한다.

호환성 문자

UCS에는 유니코드가 호환성 문자로 지정하는 수천 개의 문자가 포함되어 있다. 이들은 다른 문자 집합이 구별하는 문자에 대해 구별되는 고유한 코드 포인트를 제공하기 위해 UCS에 포함되었지만 문자에 대한 유니코드 접근 방식에서는 구별되지 않는 문자들이다.

이러한 분화의 주된 이유는 유니코드가 문자와 글립자를 구별하기 때문이다. 예를 들어, 필기체로 영어를 쓸 때, "i"라는 글자는 단어의 시작 부분, 단어의 끝 부분, 단어의 중간 부분 또는 고립된 부분에 나타나는 형태에 상관없이 다른 형태를 취할 수 있다. 아랍어 대본으로 쓰여진 아랍어와 같은 언어는 항상 필기체다. 각 글자는 많은 다른 형태를 가지고 있다. UCS에는 아랍어 양식 문자 730개가 포함되어 있으며, 단지 88개의 고유 아랍어로 분해된다. 그러나 텍스트 처리 소프트웨어가 비 유니코드 소프트웨어에 중요한 정보의 손실 없이 다른 문자 집합의 텍스트를 UCS로 변환했다가 다시 변환할 수 있도록 이러한 추가 아랍 문자를 포함시킨다.

그러나 특히 UCS와 유니코드의 경우, 선호하는 접근방식은 해당 문자가 단어에 어디에 나타나든 항상 인코딩하거나 동일한 문자에 매핑하는 것이다. 그리고 각 글자의 구별되는 형태는 글꼴과 텍스트 레이아웃 소프트웨어 방법에 의해 결정된다. 이렇게 해서 글자에 대한 내부 기억력은 글자가 한 단어로 어디에 나타나든 상관없이 동일하게 유지된다. 이것은 검색, 정렬 및 기타 텍스트 처리 작업을 크게 단순화한다.

문자 속성

유니코드의 모든 문자는 크고 성장하는 속성 집합에 의해 정의된다. 이러한 속성의 대부분은 범용 문자 집합의 일부가 아니다. 그 속성은 텍스트의 정렬이나 정렬, 단어, 문장 및 그래프의 식별, 텍스트 렌더링 또는 이미징 등을 포함한 텍스트 처리를 용이하게 한다. 다음은 몇 가지 핵심 속성의 목록이다. 유니코드 문자 데이터베이스에는 다른 많은 문서들이 있다.^[13]

속성	예	세부 사항
이름	라틴 대문자 A	이것은 유니코드와 ISO UCS의 공동 협력에 의해 부여된 영구적인 이름이다. 몇몇 잘 알려지지 않은 이름들이 존재하며 인정되지만 사양 안정성을 보장하기 위해 변경되지는 않을 것이다.[14]
코드 포인트	U+0041	유니코드 코드 포인트는 또한 "이름" 속성과 함께 영구적으로 할당되며 동반 UCS에 포함된다. 일반적인 관습은 앞에 "U+"라는 접두사가 있는 16진수 숫자로 코드 포인트를 나타내는 것이다.
대표 글리프	[15]	대표 글리프는 코드 차트에서 제공된다.[16]
일반 카테고리	대문자_편지	일반 범주는[17] 대문자의 경우 "Lu" 또는 소수 자릿수의 경우 "Nd"와 같은 두 글자의 순서로 표현된다.
콤비네이션 클래스	Not_Reordered(0)	유니코드에서 여러 문자로 분음부 및 기타 결합 마크를 표현할 수 있기 때문에, "Combining Class" 속성은 문자가 나타내는 결합 문자의 종류에 따라 문자를 구별할 수 있게 한다. 결합 클래스는 0과 255 사이의 정수 또는 명명된 값으로 표현될 수 있다. 정수 값을 사용하면 결합 마크를 표준적인 순서로 순서를 바꿔 동일한 문자열의 문자열 비교가 가능하도록 할 수 있다.
양방향 범주	왼쪽_끝_오른쪽	유니코드 양방향 알고리즘을 적용하기 위한 문자 유형을 나타낸다.
양방향 미러링	아니요.	문자의 글리프를 양방향 알고리즘 내에서 반전하거나 미러링해야 함을 나타낸다. 미러링 글리프는 글꼴 제조업체에 의해 제공되거나 "양방향 미러링 글리프" 속성을 통해 관련된 다른 문자에서 추출되거나 텍스트 렌더링 시스템에 의해 합성될 수 있다.
양방향 미러링 글리프	해당 없음	이 속성은 양방향 알고리즘 내에서 미러링할 때 글리프가 현재 문자의 미러링 글리프 역할을 할 수 있는 다른 문자의 코드 포인트를 나타낸다.
십진수 숫자 값	NAN	숫자의 경우 이 속성은 문자의 숫자 값을 나타낸다. 십진수는 세 개의 값을 모두 동일한 값으로 설정하며, 현재가 풍부한 텍스트 호환성 문자와 다른 아랍어-인도어 비 십진수는 일반적으로 문자의 숫자 값으로 설정된 후자의 두 속성만 가지고 있으며, 로마 숫자 또는 한저우/수저우 숫자와 같은 아랍어 표시 숫자와 무관한 숫자는 일반적으로 h이다.ave "숫자 값"만 표시됨.
디지트	NAN
숫자 값	NAN
이데오그래픽	거짓의	문자가 CJK 문자, 즉 Han 스크립트의 로그 문자임을 표시한다.[18]
디폴트 무식쟁이블	거짓의	문자가 구현에 무식하고 글리프, 마지막 레저 글리프 또는 대체 문자를 표시할 필요가 없음을 표시한다.
사용되지 않음	거짓의	유니코드는 레퍼토리에서 캐릭터를 삭제하는 법이 없지만, 때때로 유니코드는 소수의 캐릭터를 삭제했다.

유니코드는 다양한 특성에 의해 전체 유니코드 문자 레퍼토리를 대화적으로 조회할 수 있는 온라인 데이터베이스를^[19] 제공한다.

참고 항목

• Conscript 유니코드 레지스트리
• 유니코드 호환성 문자

참조

외부 링크

위키미디어 커먼즈에는 유니코드와 관련된 미디어가 있다.

• 유니코드 컨소시엄
• decodeunicode.org 유니코드 Wiki, 98884개의 그래픽 문자 모두 gif로, 전체 텍스트 검색
• 속성별 유니코드 문자