유니코드 등가성

Unicode equivalence

유니코드 동등성은 유니코드 문자 인코딩 표준에 의해 코드 포인트의 일부 시퀀스가 본질적으로 동일한 문자를 나타낸다는 규격이다. 이 기능은 종종 유사하거나 동일한 문자를 포함하고 있는 기존의 표준 문자 집합과의 호환성을 허용하기 위해 표준에 도입되었다.

유니코드는 표준 등가성과 호환성이라는 두 가지 개념을 제공한다. 표준적으로 동등한 것으로 정의되는 코드 포인트 시퀀스는 인쇄 또는 표시 시 모양과 의미가 동일한 것으로 가정한다. 예를 들어, U+006E(Latin lower case "n") 다음에 U+0303(합성 tilde "◌")"는 유니코드에 의해 단일 코드 포인트 U+00F1(스페인 알파벳의 소문자 "n")과 표준적으로 동등하게 정의된다. 따라서 이러한 시퀀스는 동일한 방식으로 표시되어야 하며, 이름 알파벳화 또는 검색과 같은 응용 프로그램에 의해 동일한 방식으로 처리되어야 하며, 서로 대체할 수 있다. 마찬가지로, 단일 문자로 인코딩되는 각 한글 음절 블록은 선행 결합 자모, 결합 자모, 그리고 해당되는 경우 후행 결합 자모의 조합으로 동등하게 인코딩될 수 있다.

양립가능하다고 정의되는 시퀀스는 어떤 맥락에서 서로 다른 외관을 가질 수 있지만 동일한 의미를 갖는다고 가정한다. 따라서 예를 들어, 코드 포인트 U+FB00(타이포그래픽 연결 "ff")은 U+0066 U+0066(라틴어 "f" 문자 2자)과 호환되도록 정의된다. 호환 가능한 시퀀스는 일부 애플리케이션(예: 정렬 및 색인화)에서는 같은 방식으로 처리될 수 있지만 다른 애플리케이션에서는 처리되지 않을 수 있으며, 어떤 상황에서는 서로 대체될 수 있지만 다른 애플리케이션에서는 그렇지 않을 수 있다. 표준적으로 동등한 순서도 양립할 수 있지만, 그 반대의 경우도 반드시 사실일 수는 없다.

이 표준은 또한 유니코드 정규화라고 하는 텍스트 정규화 절차를 정의하고 있는데, 문자의 등가 시퀀스를 대체하여 동일한 텍스트 두 개를 코드 포인트의 동일한 시퀀스, 즉 원본 텍스트의 정규화 형태라고 한다. 유니코드는 두 개의 등가 개념 각각에 대해 완전 구성(가능한 경우 다중 코드 포인트가 단일 포인트로 대체되는 경우)과 완전 분해(단일 포인트가 여러 개로 분할되는 경우)의 두 가지 정규 형태를 정의한다.

등가선원

캐릭터 복제

호환성이나 다른 이유로 유니코드는 본질적으로 동일한 문자인 엔티티에 서로 다른 두 개의 코드 포인트를 할당하기도 한다. 예를 들어 문자 "ENG"는 U+00C5(표준 이름 "라틴 대문자 A WITH ONT RING ON RING OF 스웨덴어 및 기타 여러 언어로 된 알파벳 문자) 또는 U+212B("ANGSTROM SIGN")로 인코딩할 수 있다. 그러나 앙스트롬의 기호는 스웨덴 문자로 정의되며, 대부분의 다른 기호들은 (볼트의 "V"와 같이) 각 용도에 대해 별도의 코드 포인트를 가지고 있지 않다. 일반적으로, 정말로 동일한 문자(유니코드 글꼴에서 동일한 방법으로 렌더링할 수 있음)의 코드 포인트는 표준적으로 동등한 것으로 정의된다.

조합 문자 및 사전 컴파일 문자

For consistency with some older standards, Unicode provides single code points for many characters that could be viewed as modified forms of other characters (such as U+00F1 for "ñ" or U+00C5 for "Å") or as combinations of two or more characters (such as U+FB00 for the ligature "ff" or U+0132 for the Dutch letter "IJ")

다른 표준과의 일관성을 위해, 그리고 더 큰 유연성을 위해, 유니코드는 또한 자체적으로 사용되지 않고 대신 선행 베이스 문자를 수정하거나 결합하는 것을 의미하는 많은 요소들에 대한 코드를 제공한다. 이러한 결합형 캐릭터의 예로는 일본식 디아크리트 다쿠텐("◌゛", U+3099)이 있다.

유니코드의 맥락에서 문자 구성은 기본 문자의 코드 포인트를 대체한 후 하나 이상의 결합 문자를 하나의 사전 컴파일 문자로 바꾸는 과정이며, 문자 분해는 그 반대 과정이다.

일반적으로, 사전 컴파일된 문자는 어떤 순서로 발생하든, 표준적으로 그들의 기본 문자와 후속적으로 결합되는 분음 부호들의 순서와 동등하게 정의된다.

예

표준 등가 유니코드 형식 2개를 사용하는 아멜리(NFC 및 NFD)
근거리 무선 통신 문자 A m é l i e
근거리 무선 통신 코드 포인트 0041 006d 00e9 006c 0069 0065
NFD 코드 포인트 0041 006d 0065 0301 006c 0069 0065
NFD 문자 A m e ◌́ l i e

인쇄 불간섭

일부 스크립트는 일반적으로 타이포그래프 방식으로 상호 작용하지 않고 조합에 대한 사전 컴파일된 문자가 없는 여러 결합 마크를 정기적으로 사용한다. 이러한 비연동 마크의 쌍은 어느 순서로든 저장할 수 있다. 이러한 대체 순서는 일반적으로 표준적으로 동등하다. 표준형식으로 순서를 정의하는 규칙도 상호작용을 고려하는지 여부를 정의한다.

타이포그래픽 규약

유니코드는 일부 문자 또는 문자 그룹에 대한 코드 포인트를 제공하며, 이러한 코드 포인트는 심미적 이유(접속어, 반 폭의 카타카나 문자 또는 일본어 텍스트에 사용하기 위한 두 폭의 라틴 문자 등)만을 위해 수정되거나, 원래의 의미(첨자 또는 위첨자 위치의 숫자 등)를 잃지 않고 새로운 의미 체계를 추가한다. 일부 일본어 글꼴에서 상속된 동그라미 모양의 숫자(예: "①" 이러한 순서는 외양과 추가된 의미론이 관련이 없는 응용 프로그램의 이익을 위해 원래의 (개별적이고 수정되지 않은) 문자의 순서와 호환되는 것으로 간주된다. 그러나 그 구분이 어느 정도 의미적 가치를 가지고 있고 텍스트의 렌더링에 영향을 미치기 때문에 두 시퀀스는 표준적으로 동등한 것으로 선언되지 않는다.

인코딩 오류

UTF-8 및 UTF-16(그리고 일부 다른 유니코드 인코딩)은 코드 단위의 가능한 모든 시퀀스를 허용하지 않는다. 다른 소프트웨어는 다양한 규칙을 사용하여 잘못된 시퀀스를 유니코드 문자로 변환할 것이며, 그 중 일부는 매우 손실된다(예: 모든 잘못된 시퀀스를 동일한 문자로 변환). 이는 정상화의 한 형태라고 볼 수 있고, 남들과 같은 어려움으로 이어질 수 있다.

정규화

유니코드 문자열 검색의 구현과 텍스트 처리 소프트웨어의 비교는 동등한 코드 포인트의 존재를 고려해야 한다. 이 기능이 없는 경우, 특정 코드 포인트 시퀀스를 검색하는 사용자는 다르지만 표준적으로 동등한 코드 포인트 표현을 가진 시각적으로 구별할 수 없는 다른 글리프를 찾을 수 없을 것이다.

유니코드는 동등한 모든 시퀀스에 대해 고유한 (정상적인) 코드 포인트 시퀀스를 생성하는 표준 정규화 알고리즘을 제공한다. 동등성 기준은 표준(NF) 또는 호환성(NFK)이 될 수 있다. 등가 등급의 대표요소를 임의로 선택할 수 있기 때문에 각 등가기준에 대해 복수 표준형식이 가능하다. 유니코드는 두 가지 호환성 기준 각각에 의미론적으로 의미 있는 두 가지 정상적인 형태를 제공한다. 즉, 구성된 형태의 근거리 무선 통신과 NFKC, 분해된 형태의 NFD와 NFKD이다. 구성 형태와 분해 형태 모두 코드 포인트 순서에 표준적인 순서를 부과하는데, 이는 정상적인 형태가 고유하기 위해 필요하다.

유니코드 문자열을 비교하거나 검색하기 위해 소프트웨어는 구성되거나 분해된 형식을 사용할 수 있다. 이 선택은 검색, 비교 등과 관련된 모든 문자열에 대해 동일한 한 중요하지 않다. 반면 동등성 기준의 선택은 검색 결과에 영향을 미칠 수 있다. 예를 들어, U+FB03 (1983), U+2168 (1903)과 같은 로마 숫자 그리고 첨자와 위첨자와 같은 일부 타이포그래픽 결합이 있다. U+2075 (1987년)에는 고유의 유니코드 코드 포인트가 있다. 표준 정규화(NF)는 이 중 어느 것도 영향을 미치지 않지만, 호환성 정규화(NFK)는 ffi 연결을 구성 문자로 분해하므로 U+0066(f)을 하위 문자열로 검색하면 U+FB03의 NFKC 정상화는 성공하지만 U+FB03의 근거리 무선 통신 표준화는 성공하지 못한다. 마찬가지로 사전 컴파일된 로마 숫자 Ⅱ(U+2168)에서 라틴어 문자 I(U+0049)를 검색할 때도 마찬가지다. 마찬가지로 위첨자 " "" (U+2075)는 호환성 매핑에 의해 "5"(U+0035)로 변환된다.

그러나 상위첨자 정보가 프로세스에서 손실되기 때문에 상위첨자 정보를 기준 등가물로 변환하는 것은 리치 텍스트 소프트웨어에는 적절하지 않을 수 있다. 이러한 구별을 위해 유니코드 문자 데이터베이스에는 호환성 변환에 대한 추가 세부사항을 제공하는 호환성 형식 지정 태그가 포함되어 있다.[1] 타이포그래픽 인대의 경우 이 태그는 단순하다. <compat>, 위첨자의 경우. <super>HTML과 같은 풍부한 텍스트 표준은 호환성 태그를 고려한다. 예를 들어 HTML은 U+0035를 위첨자 위치에 배치하기 위해 자체 마크업을 사용한다.[2]

정상형식

아래 표에는 유니코드 정규화 양식 4개와 이를 얻기 위한 알고리즘(변환)이 나열되어 있다.

NFD
정규화 폼 표준 분해 		문자는 표준적 등가성에 의해 분해되고, 복수의 결합 문자는 특정한 순서로 배열된다.
근거리 무선 통신
정규화 양식 표준 구성 		문자는 분해된 다음 표준 등가성으로 다시 계산된다.
NFKD
정규화 양식 호환성 분해 		문자는 호환성에 의해 분해되고, 복수의 결합 문자는 특정 순서로 배열된다.
NFKC
정규화 양식 호환성 구성 		문자는 호환성에 의해 분해된 다음 표준 동등성에 의해 재구성된다.

이러한 알고리즘은 모두 idempotent transformation으로, 같은 알고리즘에 의해 다시 처리되면 이미 정규화된 형식 중 하나에 있는 문자열은 수정되지 않는다.

정상적인 형태는 끈 연결 하에서 닫히지 않는다.[3] 한글 모음으로 시작하는 유니코드 문자열이나 후행 결합 자모(Jamo)로 시작하는 결함 있는 유니코드 문자열의 경우, 결합하면 합성이 깨질 수 있다.

그러나 주입(다른 원래 글리프 및 시퀀스를 동일한 정규화된 시퀀스에 매핑)하지 않으므로, 또한 편향(복원할 수 없음)도 아니다. For example, the distinct Unicode strings "U+212B" (the angstrom sign "Å") and "U+00C5" (the Swedish letter "Å") are both expanded by NFD (or NFKD) into the sequence "U+0041 U+030A" (Latin letter "A" and combining ring above "°") which is then reduced by NFC (or NFKC) to "U+00C5" (the Swedish letter "Å").

정규화 중인 다른 문자로 대체되는 단일 문자(한글 음절 블록 제외)는 유니코드 테이블에서 비어 있지 않지만 호환성 태그가 없는 경우 식별할 수 있다.

표준순서

정식 순서는 주로 문자를 조합하는 순서의 순서와 관련이 있다. 이 절의 예에 대해, 일반적으로 일부 분음 부호는 문자를 결합하지 않으며 일부 결합 부호는 분음 부호가 아니라고 가정한다.

유니코드는 각 문자에 결합 클래스를 할당하며, 이는 숫자 값으로 식별된다. 비결합 문자는 클래스 번호가 0인 반면, 결합 문자는 양의 결합 클래스 값을 갖는다. 표준 순서를 얻기 위해서는 0이 아닌 결합 클래스 값을 갖는 문자의 모든 하위 문자열을 안정적인 정렬 알고리즘을 사용하여 결합 클래스 값으로 정렬해야 한다. 클래스 값이 같은 문자를 조합하면 활자적으로 상호작용하는 것으로 가정하기 때문에 두 가지 가능한 순서는 등가로 간주되지 않기 때문에 안정적인 정렬이 필요하다.

예를 들어 베트남어에서 사용되는 U+1EBF(ế)라는 문자는 급성 사투리와 곡절 사투리를 모두 가지고 있다. 표준 분해는 3자 시퀀스 U+0065 (e) U+0302 (circumflex content)이다. U+0301(급격한 억양). 두 액센트의 결합 클래스는 모두 230이므로 U+1EBF는 U+0065 U+0301 U+0302와 같지 않다.

모든 조합 시퀀스가 사전 컴파일된 등가물이 있는 것은 아니기 때문에(앞의 예에서 마지막 것은 U+00E9 U+0302로만 축소할 수 있음), 정상적인 형태의 근거리 무선 통신도 캐릭터의 결합 동작에 의해 영향을 받는다.

표준화 차이로 인한 오류

두 애플리케이션이 유니코드 데이터를 공유하지만 이를 다르게 정상화하면 오류와 데이터 손실이 발생할 수 있다. 한 특정 사례에서 OS X는 Samba 파일 및 프린터 공유 소프트웨어에서 전송된 유니코드 파일 이름을 표준화하였다. Samba는 변경된 파일 이름을 원본과 동등한 것으로 인식하지 않아 데이터 손실로 이어졌다.[4][5] 정상화는 손실 없이 되돌릴 수 없는 것이 아니기 때문에 그러한 문제를 해결하는 것은 비견할 수 없다.

참고 항목

메모들

  1. ^ "UAX #44: Unicode Character Database". Unicode.org. Retrieved 20 November 2014.
  2. ^ "Unicode in XML and other Markup Languages". Unicode.org. Retrieved 20 November 2014.
  3. ^ Per 연결에 대해 수행해야 하는 작업
  4. ^ "Sourceforge.net". Sourceforge.net. Retrieved 20 November 2014.
  5. ^ "rsync, samba, UTF8, international characters, oh my!". 2009. Archived from the original on January 9, 2010.

참조

외부 링크