유니코드 호환성 문자

Unicode compatibility characters

유니코드와 UCS에서 호환성 문자는 오직 다른, 종종 오래된 표준과의 왕복 변환성을 유지하기 위해 인코딩되는 문자다.[1] 유니코드 용어집(Unicode Glogarary)에 따르면 다음과 같다.

다른 표준과의[2] 호환성 및 왕복 변환성을 제외하고 인코딩되지 않았을 문자

이름에는 호환성이 사용되지만 속성으로 표시되지는 않는다. 그러나 용어집에서 밝힌 것보다 정의가 더 복잡하다. 유니코드 컨소시엄이 문자에 부여한 속성 중 하나는 문자의 분해나 호환성 분해다. 5,000자가 넘는 문자는 하나 이상의 다른 UCS 문자에 대한 호환성 분해 매핑을 가지고 있다. 유니코드는 문자의 분해 속성을 설정함으로써 그 문자를 호환성 문자로 설정한다. 이러한 호환성 지정의 이유는 다양하며 아래에 자세히 설명되어 있다. 분해라는 용어는 캐릭터의 분해는 어떤 경우에는 싱글톤이 될 수 있기 때문에 때때로 혼동되기도 한다. 이 경우 한 문자의 분해는 단지 대략적으로(그러나 표준적으로는 아님) 동등한 다른 문자일 뿐이다.

호환성 문자 유형 및 키워드

5,402개의 유니코드 호환성 문자에[when?] 대한 호환성 분해 속성에는 호환성 문자를 17개의 논리 그룹으로 나누는 키워드가 포함되어 있다. 호환성 분해가 있지만 키워드가 없는 문자는 표준 분해 가능한 문자라고 하며 호환성 문자는 아니다. 호환성 분해 가능 문자의 키워드로는 <초기>, <중간>, <최종>, <절연>, <넓은>, <좁은>, <작게>, <사각형>, <수직>, <원>, <노브레이크>, <프랙션>, <서브레이크>, <슈퍼>, <호환> 등이 있다. 이러한 키워드는 호환성 문자와 호환성 분해 문자 시퀀스 사이의 관계를 어느 정도 나타낸다. 호환성 문자는 세 가지 기본 범주로 구분된다.

  1. 완전한 유니코드 텍스트 레이아웃 기능을 포함하지 않는 소프트웨어 및 글꼴 구현을 지원하기 위해 여러 대체 글리프 형식과 사전 컴파일된 디아크리틱스에 해당하는 문자.
  2. 다른 문자 집합에서 포함되거나 유니코드의 일반 텍스트 목표가 아닌 리치 텍스트를 구성하는 UCS에 추가된 문자.
  3. 의미론적으로 구별되지만 시각적으로 유사한 일부 다른 문자.

이러한 의미론적으로 구별되는 문자는 다른 문자의 글립스와 유사한 글립스로 표시될 수 있기 때문에 텍스트 처리 소프트웨어는 최종 사용자를 위해 가능한 혼란을 다루려고 노력해야 한다. 텍스트 문자열을 비교 및 정렬(정렬)할 때 다른 형식과 리치 텍스트 변형 문자는 텍스트 처리 결과를 변경하지 않아야 한다. 예를 들어, 소프트웨어 사용자는 대문자 라틴어 문자 'I'에 대해 페이지에서 찾기를 수행할 때 혼동될 수 있으며, 소프트웨어 애플리케이션은 시각적으로 유사한 로마 숫자 'Ⅱ'를 찾지 못할 수 있다.

호환성 매핑 유형

글리프 대체 및 구성

일부 호환성 문자는 유니코드 표준에 부합하는 텍스트 처리 및 디스플레이 소프트웨어에 전혀 필요하지 않다. 여기에는 다음이 포함된다.

라이거스
라틴어 대본의 'ffi'와 같은 묶음은 레거시 문자 집합에서 별도의 문자로 인코딩되는 경우가 많았다. 유니코드의 끈에 대한 접근방식은 그것들을 풍부한 텍스트로 취급하고, 켜져 있다면 글리프 치환을 통해 처리한다.
사전 계산된 로마 숫자
예를 들어, 로마 숫자 12('AX': U+216B)는 로마 숫자 10('FAX': U+2169)과 두 로마 숫자('AX': U+2169)로 분해할 수 있다. 사전 컴파일된 문자는 Number Forms 블록에 있다.
사전 보정 분수
이러한 분해에는 <굴절>이라는 키워드가 있다. 완전히 준수하는 텍스트 핸들러는 저속한 부분 ¼(U+00BC)을 구성된 부분 ½(숫자 1에 부분 슬래시 U+2044 및 숫자 4)과 동일하게 표시해야 한다[3]. 사전 컴파일된 문자는 Number Forms 블록에 있다.
상황별 글리프 또는 형태
이것들은 주로 아랍어 문장에서 발생한다. OpenType 및 TrueTypeGX와 같은 글리프 대체 기능이 있는 글꼴을 사용하면, 유니코드 호환 소프트웨어는 해당 문자가 단어의 시작, 끝, 중간 또는 분리되어 나타나는지에 따라 동일한 문자에 적합한 글리프를 대체할 수 있다. 이러한 글리프 대체는 일부 동아시아 언어의 수직 텍스트 레이아웃에도 필요하다. 이 경우 글리프는 넓고, 좁고, 작고, 사각형 글리프 형태로 대체하거나 합성해야 한다. 그 대신 다른 문자 집합을 사용하는 부적합한 소프트웨어 또는 소프트웨어는 위치에 따라 동일한 문자에 대해 여러 개의 개별 문자를 사용한다. 즉, 텍스트 처리를 더욱 복잡하게 한다.

UCS, 유니코드 문자 속성 및 유니코드 알고리즘은 소프트웨어 구현에 필요한 모든 것을 제공하며, 분해 등가물에서 이러한 문자를 적절하게 표시하기 위해 필요한 모든 것을 제공한다. 따라서 이러한 분해 가능한 호환성 문자는 중복되고 불필요해진다. 문자 집합에 텍스트가 존재하기 위해서는 텍스트가 적절하게 비교되고 정렬되도록 추가 텍스트 처리가 필요하다(유니코드 정규화 참조). 더욱이 이러한 호환성 문자는 추가적인 의미론이나 구별되는 의미를 제공하지 않는다. 또한 텍스트 레이아웃과 글꼴이 유니코드에 적합하다면 이러한 문자는 시각적으로 구별되는 렌더링을 제공하지 않는다. 또한, 변환은 분해된 문자를 다른 문자 집합의 사전 컴파일된 문자에 쉽게 매핑할 수 있기 때문에 이러한 문자는 다른 문자 집합으로의 왕복 변환에 필요하지 않다. 마찬가지로, 최종 아랍어 문자와 같은 문맥 형태는 단어 내 위치에 따라 적절한 레거시 문자 집합 양식 문자에 매핑될 수 있다.

이러한 호환성 문자를 분사하기 위해서는 텍스트 소프트웨어가 여러 유니코드 프로토콜을 준수해야 한다. 소프트웨어는 다음을 수행할 수 있어야 한다.

  1. 문자 문자에서 분음 부호 표기를 작성하고 분음 부호를 결합한 하나 이상의 별도 표기를 작성한다.
  2. (저자나 독자의 재량에 따라) 끈과 문맥 글리프 변형을 대체한다.
  3. 글립스를 글꼴 데이터에서 또는 필요에 따라 합성하여 작거나 수직, 좁고 넓은 사각형 형태로 대체한 CJKV 텍스트를 (저자나 독자의 재량에 따라) 수직으로 배치한다.
  4. 'Fraction Slash' 문자(½ U+2044) 및 기타 임의 문자를 사용하여 분수를 결합하십시오.
  5. 'Combining Long Solidus Overlay'( ( U+0338)를 다른 기호(예: ∄ 또는 ∄ for ∄(U+2203)와 결합한다.

이러한 호환성 문자는 모두 5,402개의 지정된 호환성 문자 중 총 3,779개의 불완전한 유니코드 구현을 위해 포함되었다. 여기에는 <초기>, <중간>, <최종>, <절연>, <절연>, <완전>, <완전>, <좁은>, <수직>, <제곱>이라는 키워드로 표시된 호환성 문자가 모두 포함된다. 또한 거의 모든 표준어와 대부분의 <호환> 키워드 호환성 문자(예외에는 동봉된 영숫자, 동봉된 문자 및 § Semonically different 문자에서 논의된 문자)를 포함한다.

리치 텍스트 호환성 문자

많은 다른 호환성 문자는 유니코드가 리치 텍스트로 간주하는 것을 구성하며, 따라서 유니코드와 UCS의 목표 밖에 있다. 어떤 의미에서 이전 절에서 논의된 호환성 문자(기존 소프트웨어에서 연결 및 수직 텍스트 표시에 도움을 주는 문자)도 리치 텍스트의 형태를 대체하는데, 리치 텍스트 프로토콜이 텍스트의 표시 여부를 결정하기 때문이다. 그러나 문자열을 연결하거나 연결되지 않은 상태로 표시하거나 수직 대 수평으로 표시하는 선택은 둘 다 대서양이 아닌 리치 텍스트다. 그것들은 단지 스타일 차이일 뿐이다. 이는 기울임꼴, 위첨자 및 첨자와 같은 다른 리치 텍스트 또는 리치 텍스트의 스타일링이 그와 함께 특정 의미론을 내포하는 리스트 마커와 대조적이다.

일반 텍스트를 비교, 결합, 처리 및 저장하기 위해 리치 텍스트 변형은 의미상 중복된다. 예를 들어, 숫자 4에 위첨자 문자를 사용하는 것은 숫자 4에 대한 표준 문자를 사용한 다음 그것을 위첨자로 만들기 위해 리치 텍스트 프로토콜을 사용하는 것과 구별할 수 없을 가능성이 있다. 따라서 이러한 대체 리치 텍스트 문자는 리치 텍스트 서식이 적용된 일반 텍스트 상대 문자와 시각적으로 동일하게 나타나기 때문에 모호성을 야기한다. 이러한 리치 텍스트 호환성 문자는 다음을 포함한다.

수리 영숫자 기호
이 기호들은 단순히 라틴어와 그리스 알파벳과 15개의 다양한 활자체에서 반복되는 인디케이터-아랍어 소수 자릿수를 복제한 것이다. 그것들은 수학적 표기법을 위한 임의의 팔레트로 의도되었다. 그러나, 그것들은 단순한 텍스트 문자만을 지원하려는 유니코드의 목표뿐만 아니라, 인코딩 문자 대 시각적 글리프 인코딩의 구분을 약화시키는 경향이 있다. 수학 기호 팔레트에 대한 이러한 대체 스타일링은 대신에 풍부한 텍스트 프로토콜을 통해 쉽게 만들어질 수 있다.
동봉된 영숫자 및 문자(표기자)
이것들은 주로 목록 표시자를 위해 포함된 문자들이다. 그것들은 일반 텍스트 문자로 구성되지 않는다. 더욱이, UCS에서 프로비저닝된 동봉된 영숫자 또는 문자 집합이 제한적이기 때문에 다른 리치 텍스트 프로토콜의 사용이 더 적절하다.
동그라미 친 영숫자 및 문자
동그라미를 친 형태도 마커로 사용할 가능성이 높다. 다시 말하지만 문자열을 둘러싸기 위해 리치 텍스트 프로토콜과 함께 문자를 사용하는 것이 더 유연하다.
다양한 폭의 공백 및 중단 없는 공간
이들 문자는 단순히 코어 공간(U+0020)과 노브레이크 공간(U+00A0)의 리치 텍스트 변형일 뿐이다. 추적, 커닝 또는 단어 간격 지정 속성과 같은 다른 리치 텍스트 프로토콜을 사용해야 한다.
일부 첨자 및 위첨자 양식 문자
첨자와 위첨자 문자의 다수는 사실 국제 음성 문자 및 기타 문자 체계와 의미론적으로 구별되는 문자로, 실제로 풍부한 텍스트 범주에 속하지는 않는다. 그러나 다른 것들은 다른 그리스어, 라틴어 및 숫자 문자의 풍부한 텍스트 표시 형식을 구성한다. 따라서 이러한 리치 텍스트 위첨자와 첨자 문자는 리치 텍스트 호환성 문자의 이 범주에 적절히 속한다. 이 중 대부분은 "상표 및 첨자" 또는 "기본 라틴어" 블록에 있다.

이러한 모든 리치 텍스트 호환성 문자에 대해 글리프 표시는 일반적으로 호환성 분해(관련) 문자와 구별된다. 그러나, 이것들은 호환 문자로 간주되며, 유니코드가 UCS와 관련 프로토콜로 지원하고자 하는 일반 텍스트 문자가 아니기 때문에 유니코드 컨소시엄에 의해 사용이 금지된다. 리치 텍스트는 HTML, CSS, RTF 및 기타 그러한 프로토콜과 같은 비 유니코드 프로토콜을 통해 처리되어야 한다.

리치 텍스트 호환성 문자는 5,402개의 호환성 문자 중 1,451개로[citation needed] 구성된다. 여기에는 키워드 <서클>과 <퐁>(아래 의미상 구별되는 3개 제외)으로 표시된 호환성 문자, <호환>과 표준문자로부터 11개의 스페이스 변형, 그리고 <호환과 첨자> 블록에서 나온 일부 키워드 <위첨자>와 <구독자>가 포함된다.

의미상 구별되는 문자

많은 호환성 문자는 의미론적으로 구별되는 문자로 표현되는 글리프를 다른 문자와 공유할 수 있다. 대부분의 다른 문자 집합이 하나의 스크립트나 쓰기 시스템에 초점을 맞췄기 때문에 이러한 문자 중 일부는 포함되었을 수 있다. 예를 들어, ISO와 다른 라틴 문자 집합은 주로 하나의 쓰기 시스템이나 스크립트에 초점을 맞출 때, 이러한 문자 집합에는 공통 수학 기호 π에 대한 문자가 없을 것이기 때문에 π (pi)의 문자를 포함했을 가능성이 높다. 그러나 유니코드를 사용하면 수학자들은 수학적 집합이나 수학적 상수를 얻기 위해 세계 어느 알려진 스크립트의 문자를 자유롭게 사용할 수 있다. 현재까지 유니코드는 그러한 몇 가지 수학 상수(예: 유니코드가 호환성 문자로 간주하는 플랑크 상수 U+210E 및 오일러 상수 U+21077)에 대한 구체적인 의미 지원만 추가했다. 따라서 유니코드는 그리스어와 히브리어의 문자를 바탕으로 한 여러 수학 기호를 호환성 문자로 지정한다. 여기에는 다음이 포함된다.

  • 히브리어 문자 기반 기호 (4): 에일프(ℵ ale U+2135), 베팅(ℶℶ U+2136), 기멜(ℷℷ U+2137) 및 달릿(ℸ U+2138)
  • 그리스 문자 기반 기호(7): 베타(beta, U+03D0), 세타(theta), 피(phi), U+03D5(fi), 파이(pi), 카파(kappa, U+03F0), 호(roho), 자본(capital u+03F4)

이러한 호환성 문자는 이름에 "심볼"이라는 단어를 추가해야만 호환성 분해 문자와 구별되지만, 그것들은 쓰여진 수학에서 오랫동안 뚜렷한 의미를 나타낸다. 그러나, 모든 실용적인 목적을 위해 그들은 그들의 호환성에 상응하는 그리스어나 히브리 문자와 같은 의미론을 공유한다. 이들은 경계선 의미론적으로 구별할 수 있는 문자로 간주될 수 있으므로 총계에 포함되지 않는다.

유니코드가 그러한 측정 단위를 인코딩하려는 의도는 아니지만, 레퍼토리는 저자가 사용해서는 안 되는 6개의 기호를 포함하고 있다: 등장인물의 분해는 대신 사용되어야 한다.

  • Unit symbols (6): Angstrom (Å U+212B: use U+00C5 instead), Ohm (Ω, U+2126: use U+03A9 instead), Kelvin (K U+212A: use U+004B instead), Fahrenheit (℉ U+2109: use U+00B0 and U+0046 instead), Celsius (℃ U+2103: use U+00B0 and U+0043 instead), Micro Sign (µ U+00B5: 대신 U+03BC를 사용)

유니코드는 또한 22개의 다른 문자 같은 기호를 호환성 문자로 지정한다.

  • 기타 그리스 문자 기반 기호(4): lunate 엡실론(lunate 엡실론, lunate sigma(lunate U+03F5), capital lunate sigma(lunate U+03F9), upsilon(HUK U+03D2)
  • 수학적 상수(3): 오일러 상수(ULD U+21077), 플랑크 상수(U+210E), 축소 플랑크 상수(U+210F),
  • 통화 기호(2): 루피 기호(U+20A8), 리알 기호(U+FDFC)
  • 구두점(4): 점 지시자 1명(U+2024), 중단 없는 공간(U+00A0), 중단 없는 하이픈(U+2011), 티베트 마크 구분 기호 tsheg bstar(U+0F0C)
  • Other letter-like symbols (10): information source (ℹ U+2139), account of (℀ U+2100), addressed to the subject (℁ U+2101), care of (℅ U+2105), cada una (℆ U+2106), numero (№ U+2116), telephone sign (℡ U+2121), facsimile sign (℻ U+213B), trademark (™ U+2122), service mark (℠ U+2120)

또한 몇몇 스크립트는[which?] 의미론을 구별하기 위해 위첨자, 첨자와 같은 글리프 위치를 사용한다. 이러한 경우 첨자와 위첨자는 단순히 풍부한 텍스트일 뿐만 아니라, 문자 체계(총 130개)에서 분음부와 문자[original research?] 사이의 잡종과 유사한 구별되는 문자를 구성한다.

  • 112 characters representing abstract phonemes from phonetic alphabets such as the International Phonetic Alphabet use such positional glyphs to represent semantic differences (U+1D2C – U+1D6A, U+1D78, U+1D9B – U+1DBF, U+02B0 – U+02B8, U+02E0 – U+02E4 )
  • 칸분 블록에서 14자(U+3192 – U+319F)
  • Tifinagh 스크립트의 문자 1개: Tifinagh Modifier Labialization Mark(영문 U+2D6F)
  • 조지아 스크립트의 문자 1개: 수정자 레터 조지아 나르(U+10FC)
  • 라틴-1 보충[citation needed] 블록에 포함된 남성(U+00BA) 및 여성(U+00AA) 순서 표시기

마지막으로 유니코드는 로마 숫자를 동일한 글리프를 공유하는 라틴 문자에 대한 호환성 동등성으로 지정한다.[citation needed]

  • Capital Roman Numerals (7): One (Ⅰ U+2160), Five (Ⅴ U+2164), Ten (Ⅹ U+2169), Fifty (Ⅼ U+216C), One Hundred (Ⅽ U+216D), Five Hundred (Ⅾ U+216E), One Thousand (Ⅿ U+216F)
  • 및 소문자 변형(7): 1개(U+2170), 5개(U+2174), 10개(U+2179), 50개(U+217C), 100개(U+217D), 500개(U+217E), 1,000개(U+217F)
  • 대문자 및 소문자 변형으로 사전 계산된 로마 숫자 18개(2–4, 6–9, 11–12)

로마 숫자 천은 실제로 같은 의미 단위에 대해 세 번째 형태나 글리프를 나타내는 세 번째 문자를 가지고 있다. 천원 C D(U+2180). 이 글립프로부터 라틴 M을 사용하는 관행이 어디에서 일어났을지 알 수 있다. 비록 유니 코드는 매우 different[표창 필요한](시각이지만 비슷한)라틴어 편지가sign-value 로마 숫자를 이상하게도, 인도 의 아랍어 place-value 10진 자릿수 숫자 24번(240코드 포인트의 10숫자를 위해 총)은 UCS에 걸쳐 또는 분해 관계 매핑 betwe 없이 반복됩니다(위치).그들 en.

분해할 수 있는 문자 사이에 시각적으로 유사하지만 의미론적으로 구별되는 167개의 문자(게다가 경계선 11개의 히브리 문자 및 그리스 문자 기반 기호 및 6개의 측정 단위 기호 포함)가 존재한다는 것은 호환성 문자의 주제를 복잡하게 만든다. 유니코드 표준은 콘텐츠 작성자의 호환성 문자 사용을 금지한다. 그러나 특정 전문영역에서 이러한 문자는 중요하며 호환성 문자 사이에 포함되지 않은 다른 문자와 상당히 유사하다. 예를 들어, 특정 학계에서 같은 글립자를 공유하는 라틴어 문자와 구별되는 로마 숫자를 사용하는 것은 쿠네폼 숫자나 고대 그리스 숫자의 사용과 다르지 않을 것이다. 로마 숫자 문자를 라틴 문자 문자로 축소하면 의미적 구분이 없어진다. 첨자 또는 위첨자 위치의 글리프를 사용하는 음성 알파벳 문자에도 유사한 상황이 존재한다. 음성 문자를 사용하는 전문 서클에서는 풍부한 텍스트 프로토콜에 의존하지 않고 저자가 할 수 있어야 한다. 또 다른 예로 게임 바둑을 설명하기 위해 '원' 호환성 캐릭터를 키워드로 사용하는 경우가 많다. 그러나 이러한 호환성 문자의 사용은 저자가 그렇지 않으면 낙담하는 문자를 사용해야 하는 특별한 이유가 있는 예외를 구성한다.

호환성 블록

유니코드 문자의 여러 블록에는 전체 또는 거의 모든 호환성 문자(비차르를 제외한 U+F900–U+FFEF)가 포함되어 있다. 호환성 블록에는 리알 통화 기호(Rial 통화 기호, U+FDFC)가 하나만 예외적으로 포함된 의미상 구별되는 호환성 문자가 없으므로 호환성 블록의 호환성 분해 가능 문자는 저하된 문자 집합에 모호하지 않게 포함된다. 유니코드는 저자들이 일반 텍스트 호환성 분해 동등성을 대신 사용하고 리치 텍스트 마크업으로 해당 문자를 보완할 것을 권장한다. 이 접근방식은 단지 하나의 예를 제공하기 위해 동그라미 치거나 동그라미 친 영숫자 유한 집합을 사용하는 것보다 훨씬 유연하고 끝이 개방적이다.

불행하게도 호환성 블록 안에서도 그 자체가 호환성 캐릭터가 아니어서 작가들을 혼란스럽게 할 수 있는 캐릭터의 수가 적다. "Enclosed CJK Letters and Months" 블록에는 "한국 표준 기호"(U+327F)라는 단일 비호환 문자가 포함되어 있다. 그 기호와 12개의 다른 문자가 알 수 없는 이유로 블록에 포함되었다. "CJK 호환성 IDographs" 블록에는 다음과 같은 호환되지 않는 유니파이드 Han IDograph가 포함되어 있다.

  1. (U+FA0E): 﨎
  2. (U+FA0F): 﨏
  3. (U+FA11): 﨑
  4. (U+FA13): 﨓
  5. (U+FA14): 﨔
  6. (U+FA1F): 﨟
  7. (U+FA21): 﨡
  8. (U+FA23): 﨣
  9. (U+FA24): 﨤
  10. (U+FA27): 﨧
  11. (U+FA28): 﨨
  12. (U+FA29): 﨩

이 열세 글자는 호환성이 없는 문자로, 어떤 식으로든 사용이 좌절되지 않는다. 그러나 U+FA23 﨣과 같은 U+27EAF 𧺯은 CJK 통합 한자 확장 B로 잘못 인코딩된다.[4] 어떤 경우에도 정규화된 텍스트는 U+27EAF 𧺯과 U+FA23 23을 모두 포함해서는 안 된다. 이러한 코드 포인트는 두 번 인코딩된 동일한 문자를 나타낸다.

이 블록의 다른 몇 개의 문자는 호환성 매핑이 없지만 레거시 지원을 위한 것이 분명하다.

영문자 표시 양식(1)

  1. 히브리 포인트 유대-스페인 바리카(U+FB1E): ﬞ. 이것은 히브리 포인트 라페(U+05BF)의 글리프 변종이다: ֿ, 유니코드는 호환성 매핑을 제공하지 않지만.

아랍어 프리젠테이션 양식(4)

  1. "나쁜 왼쪽 괄호"(U+FD3E): ﴾. U+0029 ''의 글리프 변형)
  2. "오렌트 우측 괄호"(U+FD3F): ﴿. U+0028 '()'의 글리프 변형
  3. "Ligature Bismillah Ar-Rahman Ar-Raheem" (U+FDFD): ﷽. Bismillah Ar-Rahman Ar-Raheem is a ligature for Beh (U+0628), Seen (U+0633), Meem (U+0645), Space (U+0020), Alef (U+0627), Lam (U+0644), Lam (U+0644), Heh (U+0647), Space (U+0020), Alef (U+0627), Lam (U+0644), Reh (U+0631), Hah (U+062D), Meem (U+0645), Alef (U+0627), Noon (U+0646), Space (U+0020), Alef (U+0627), Lam (U+0644), Reh (U+0631), Hah (U+062D), Yeh (U+064A), Meem (U+0645) i.e. بسم الله الرحمان الرحيم [5] (Similarly, U+FDFA and U+FDFB code for two other Arabic ligatures, of 21 and 9 characters respectively.)
  4. "아랍 꼬리 조각"(U+FE733): context 문맥 글리프 처리 없이 텍스트 시스템 지원

CJK 호환성 양식(2개 모두 CJK Unified Idography 관련: U+4E36 丶)

  1. 참깨 도트(U+FE45): ﹅
  2. 흰색 세서미 도트(U+FE46): ﹆

동봉된 영숫자(21개의 리치 텍스트 변형)

  1. 음의 동그라미 숫자 10개(0 및 11 ~ 20) (U+24FF 및 U+24F4를 통한 U+24EB): – – –
  2. 11 이중 동그라미 숫자(0 ~ 10)(U+24F5 ~ U+24FE): ⓵ – ⓾

정규화

주요 기사: 유니코드 정규화

표준화란 유니코드를 준수하는 소프트웨어가 먼저 호환성 분해를 수행한 후 비교 또는 텍스트 문자열을 결합하는 프로세스다. 이는 예를 들어 사용자가 일부 텍스트 내에서 사례 또는 분음 부감각 검색을 수행할 때 필요한 다른 작업과 유사하다. 그러한 경우 소프트웨어는 다른 방법으로 동일하거나 무시하지 않을 문자를 동일시하거나 무시해야 한다. 일반적으로 표준화는 기본 저장된 텍스트 데이터(무손실)를 변경하지 않고 수행된다. 그러나 일부 소프트웨어는 텍스트 저장(손실)과의 표준적 또는 비수평적 호환성 문자 차이를 제거하는 텍스트를 영구적으로 변경할 수 있다.

참조

  1. ^ "Chapter 2.3: Compatibility characters" (PDF). The Unicode Standard 6.0.0.
  2. ^ 유니코드 컨소시엄 유니코드 용어집
  3. ^ The Unicode Consortium (2010). The Unicode Standard, Version 6.0.0 (PDF). Addison-Wesley Professional. p. 212. ISBN 978-0321480910.
  4. ^ IRGN 1218
  5. ^ 유니코드 차트 FB50-FDFF(PDF).

외부 링크