Unicode normalization considerations/ko

이게 뭔가요?
1.4 버전부터 미디어 위키는 form C (정규화양식 C, NFC)에서 언급하고 있는 원칙들을 유니코드 텍스트 입력에 적용해 왔습니다. 이러한 정규화에는 합당한 이유가 있는데:


 * 형태적으로는 같은 글자들이지만 의미가 다른 구성요소를 갖는 페이지 제목들이 서로 충돌하는 경우를 피하며
 * 사파리를 제외한 웹브라우저들은 글자소가 결합되어 정상적으로 화면을 읽을 수 있지만, 사파리 웹브라우저는 업로드되는 음악, 동영상 등 미디어 파일들은 이름을 구성하는 글자소들이 분해되어 보여지고, 결과적으로 페이지 제목 또한 분해되어 보여지는 문제가 지속되고 있습니다


 * 입력된 검색어가 조합되는 양식과 관계없이 검색기능이 예측한대로 작동할 수 있도록 하기 위해

양식 C가 선택되었습니다. 그 이유는:

미리 조합된 글자를 사용하여 양식 C에 근거한 형태로 이미 막대한 양의 데이터가 입력되었으며,


 * 양식 C에 근거해서 보이지 않게 기본 글자 + 결합되는 글자의 행렬들을 미리 구성된 글자들로 바꾸는 과정은 상대적으로 손실이 적은 것으로 알려져 있다.이론적으로, 양식 C에 근거해 정규화되었기 때문에 글자의 형태가 바뀌어서는 안된다.

the W3C recommends it 를 참조하라

문제점
그러나, 시간이 많이 흐름에 따라 몇 개의 문제점들이 나타났다


 * 몇몇 아라비아, 페르시아 및 히브리 연결모음 표시들은 부정확하게 정렬된다.
 * 이런 사례들 중 일부는 단지 오류 투성이 폰트 또는 렌더링엔진 때문에 발생하며, 제한된 몇몇 플랫폼에서만 발생한다.
 * 그러나 정의된 분류기준이 의미상으로 정확한 분류순서를 생성할만큼 충분하지 못하기 때문에, 꽤 많은 사례들에서 부정확한 문장을 생산할 수 있다. 이는 주로 성경히브리어와 같은 오래된 경전들에 영향을 미친다.


 * 벵골어의 놀라운 구성제외 사례.
 * 몇몇 소프트웨어 도구들에서는 정확하게 렌더링이 되지 않는데 이는 위에서 언급한 바와 같이 특정 플렛폼과 연계된 버그 때문으로 추정된다.
 * 몇몇 영세한 개발자에 의한 검색 툴은 어떻게 정규화하는지 알지 못하는 것이 분명하며, 구문들을 제대로 정규화하지 못한다.

단지 시간만 좀 걸리면, 다른 개발자들이 잘못된 소프트웨어를 고칠 수 있으며, 그 문제들이 무시할만큼 작은 문제라고 거만을 떨고는 있지만, 렌더링 문제와 영세한 개발자에 의해 개발된 잘못된 검색 문제는 여전히 우리들을 괴롭히고 있다.

정식 순서를 부여하는 문제는 보다 어려운 일이다. 현재 가용한 규준을 따르기만 하면 올바른 결과가 나오는 것은 분명 아니다. 유니코드체계는 호환성 원칙이 깨질 우려가 있기 때문에 정렬순서에 대한 정의를 바꾸지 않을 것이고, 따라서 정확한 정렬순위를 부여한 *새로운* 글자체계를 도입하지 않는 한 이 문제가 해결될 것 같지 않다.

우리는 어떻게 해야할까?
우리는 이 문제를 무시하고 그저 비켜 갈 수 있기만을 바라거나 (가장 손쉬운 방법이긴 하지만, 지속적으로 이의를 제기하는 특정 언어군과 마주해야 함), 완벽한 정규화를 포기하고 이득을 극대화하면서 문제는 최소화할 수 있도록 우리가 적용하는 원칙들을 바꿀 수 있다.

만약 우리가 정규화 양식 C (NFC)가 유해하다고 생각한다면, (비록 자매격인 NFKC 만큼 유해하지는 않지만) 가능한 해결방법 한가지는 아래와 같이 구성될 것이다:


 * 모든 웹 입력에 대해 정규화 확인과정을 제거한다; UTF-8 충족 여부만 확인하도록 보다 제한된 형태로 바꾸고, 입력된 그대로 약간 이상한 구성양식을 허용함.


 * NFC를 직접 적용하는 것을 꼭 필요한 곳으로 제한:
 * Title::secureAndSplit을 통한 페이지 제목 정규화
 * 검색 엔진 인덱스 생성
 * 검색 엔진 질의들

이 방법으로 간섭은 최소화하고, 페이지 문장들이 임의 구성양식을 갖도록 허용하면서 링크와 내부 검색이 계속 작동하도록 보증할 수 있다. 이렇게되면 데이터베이스 양식을 변경하지 않아도 되고, 서비스 중단 없이 적용 가능하다.

그러나, 이는 페이지 제목에 정규화를 적용함에도 불구하고, 어떤 면에서 보기 흉하거나 부적절한 형태로 보여지는 문제를 남겼다.

장기적 전망
페이지 제목을 정규화되지 않은 형태로 표시하도록 허용하는 방법도 있다. 이는 임의로 대문자와 소문자를 혼합해서 작성할 수 있도록 허용하는 것과 함께 이행될 것이다.('IMonkey' 대신 'iMonkey')

이렇게 될 경우, 페이지 제목은 표시제목 양식을 포함하도록 변화될 것이다:

page_title:        'IMonkey' page_display_title: 'iMonkey' 또는 아마도 공포스러울 수 있는 대 소문자가 포개어진 자료들

page_title:        'imonkey' page_display_title: 'iMonkey'

The canonical and display titles would always be transformable to one another to maintain purity of wiki essence; you should be able to copy the title with your mouse and paste it into a link and expect it to work.

These kinds of changes could be more disruptive, requiring changes to the database structure and possibly massive swapping of data around in the tables from one form to another, so we might avoid it unless there are big benefits to be gained.

Other normalization forms
NFC was originally chosen because it's supposed to be semantically lossless, but experience has shown that that's not quite as true as we'd hoped.

We may then consider NFKC, the compatibility composition form, for at least some purposes. It's more explicitly lossy; the compatibility forms are recommended for performing searches since they fold additional characters such as plain latin and "full-width" latin letters.

It would likely be appropriate to use NFKC for building the search index and to run on search input to get some additional matches on funny stuff. I'm not sure if it's safe enough for page titles, though; perhaps with a display title, but probably not without.

Normalizaton and unicodification can both be done by bots. While no bot has yet been known to "normalize", the function is possible. The "Curpsbot-unicodify" bot has unicodified various articles on Wikipedia and this should not be undone.