이 유니 코드 NFC 변환이 맞습니까?

Question

"대소 문자를 구별하지 않는"정규화 된 형식의 유니 코드 텍스트를 생성해야하는 C 프로젝트에서 작업 중입니다. 정규화 형식을 NFD로 정규 변환 한 다음 유니 코드 대괄호 알고리즘을 적용하고 마지막으로 결과를 유니 코드 정규화 형식 NFC로 변환하여 정규화 된 형식을 정의하도록 선택했습니다.

유니 코드 표현 및 유틸리티 기능을 위해 ICU의 C API를 사용하고 있으며 ICU의 unorm_normalize() 및 u_strFoldCase() 기능을 사용하여 내 체계를 구현하는 것이 매우 간단했습니다. 하지만 내 테스트 중 하나가 실패하고, 왜 그런지 이해하지 못합니다. ICU는 내가 예상했던 것과 다른 NFC 형태를 생성하는 것 같습니다. 디버거를 통해

U+0020, U+1EA5, U+0328, U+1EC4, U+031C 

, 나는 그 ICU를 결정 나는 경우 폴딩 후 중간 결과에 대해 동의합니다 :

입력 순서는 이러한 BMP 코드 포인트로 구성되어 특히

U+0020 U+0061 U+0328 U+0302 U+0301 U+0065 U+031C U+0302 U+0303 

주 NFD를 형성하기위한 이전의 변환은 U + 1EC4의 분해의 중간으로 문자 U + 031C를 옮겼다. 관련 문자의 상대적인 CCC 번호를 기반으로 적절하다. 그게 제가 시험하려고하는 부분입니다.

이제 좋은 부분 : ICU에 따르면, 접힌 문자 시퀀스의 NFC 정상화 내가 세 후행 결합 문자가 이미 있기 때문에

U+0020 U+0105 U+0302 U+0301 U+0065 U+031C U+0302 U+0303 

해야한다고 생각하는 반면

U+0020 U+0105 U+0302 U+0301 U+1ec5 U+031C 

입니다 정식 순서이며 U + 0065 및 U + 031C의 정식 구성은 없습니다.

그래서, 두 가지 질문 :

올바른 NFC 양식은

1. ?
2. ICU가 올바른 경우 그 이유는 무엇입니까?

Answer 1

ICU가 맞습니다. (정규 분해 또는 호환성 분해의) 코드화 된 문자 시퀀스에서 두 번째 문자에서 시작 : 이유를 이해 chapter 3 of the Unicode Standard에 정의 된 정규 합성 알고리즘을 살펴해야합니다 :

D117 정규 합성 알고리즘을 다음 단계를 수행하십시오.

R1 문자 시퀀스에서 C에 선행하는 마지막 시작 문자 L을 찾으려면 문자 C에서 코드화 된 문자 시퀀스를 뒤로 (왼쪽) 탐색하십시오.

R2 L이 있고 C가 L에서 차단되지 않고 시퀀스 < L, C>와 정규적으로 동일한 Primary Composite P가있는 경우 시퀀스에서 L을 P로 바꾸고 삭제 C에서.차단

D115 :

은 또한 특히, 앞의 정의를 이해해야 렛 및 코딩 된 문자 시퀀스 < A, ... C>의 두 자 C. C가 A에서 차단되고 ACC와 A 사이에 문자 B가있는 경우 (예 : < A, ... B, ... C>) 및 ccc (B) = 0 또는 ccc (B)> = ccc (C)이다.

U+0065 U+031C U+0302 U+0303 
L  C 

C는 분명하지 않다 :

U+0065 U+031C U+0302 U+0303 

우리는 문자 U+031C로 시작하고 다시 U+0065입니다 마지막 선발을 추구 :

지금 당신의 입력 순서의 다음과 같은 문자열을 고려 L에서 차단되었지만 <L, C>에 해당하는 기본 컴포지트가 없으므로 다음 문자로 진행합니다.

U+0065 U+031C U+0302 U+0303 
L    C 

이제 C는 여전히 ccc(U+031C) = 220 < 230 = ccc(U+0302) 때문에 U+0065 U+0302에 해당 기본 복합 U+00EA이 존재 (즉, 당신이 아마 오해은 무엇입니까) L에서 차단되지 않습니다. 그래서 우리는 L을 교체 C 삭제 : 다시

U+00EA U+031C U+0303 
L    C 

을 C가 L에서 차단되지 않고, 일차 복합체 U+1EC5는 U+00EA U+0303 동등하므로, 조성물의 최종 결과는 :

U+1EC5 U+031C 

이 ICU의 출력과 일치합니다.