유니코드 정규화시 고려사항들
이 페이지 문서는 오래되었습니다. |
이게 뭔가요?
1.4 버전부터 미디어 위키는 form C (정규화양식 C, NFC)에서 언급하고 있는 원칙들을 유니코드 텍스트 입력에 적용해 왔습니다. 이러한 정규화에는 합당한 이유가 있는데:
- 형태적으로는 같은 글자들이지만 의미가 다른 구성요소를 갖는 페이지 표제어들이 서로 충돌하는 경우를 피하며
- 사파리 웹브라우저로부터 업로드되는 미디어 파일에 관한 지속되는 문제: 사파리를 제외한 웹브라우저들은 글자소가 결합된 정상 구문형태를 제공하는데 반해, 사파리 웹브라우저로부터 업로드되는 음악, 동영상 등 미디어 파일들은 화일명을 구성하는 글자소들이 분해되어 개별 글자소형태로 보여지고, 결과적으로 페이지 표제어 또한 분해되어 보여짐.
- 입력된 검색어가 조합되는 양식과 관계없이 검색기능이 예측한대로 작동할 수 있도록 하기 위해
양식 C가 선택되었습니다. 그 이유는:
미리 조합된 글자를 사용하여 양식 C에 근거한 형태로 이미 막대한 양의 데이터가 입력되었으며,
- 양식 C에 근거해서 보이지 않게 기본 글자 + 결합되는 글자의 행렬들을 미리 구성된 글자들로 바꾸는 과정은 상대적으로 손실이 적은 것으로 알려져 있다.이론적으로, 양식 C에 근거해 정규화되었기 때문에 글자의 형태가 바뀌어서는 안된다.
the W3C recommends it 를 참조하라
MediaWiki doesn't apply any normalization to its output, for example cafe<nowiki/>́ becomes "café" (shows U+0065 U+0301 in a row, without precomposed characters like U+00E9 appearing).
When MediaWiki shows an internal link, the page title is also normalized to the form C – even if encoded with HTML entities, references, or most other workarounds which evade respective transformation in the source code.
But no NFC transformation happens (as of MediaWiki 1.35.0) on characters embedded to the page title in percent encoding, such as %E1%BD%B5.
문제점
그러나, 시간이 많이 흐름에 따라 몇 개의 문제점들이 나타났다
- 몇몇 아라비아, 페르시아 및 히브리 연결모음 표시들은 부정확하게 정렬된다.
- 이런 사례들 중 일부는 단지 오류 투성이 폰트 또는 렌더링엔진 때문에 발생하며, 제한된 몇몇 플랫폼에서만 발생한다.
- 그러나 정의된 분류기준이 의미상으로 정확한 분류순서를 생성할만큼 충분하지 못하기 때문에, 꽤 많은 사례들에서 부정확한 문장을 생산할 수 있다. 이는 주로 성경히브리어와 같은 오래된 경전들에 영향을 미친다.
- 벵골어의 놀라운 구성제외 사례.
- 몇몇 소프트웨어 도구들에서는 정확하게 렌더링이 되지 않는데 이는 위에서 언급한 바와 같이 특정 플렛폼과 연계된 버그 때문으로 추정된다.
- 몇몇 제삼의 개발자에 의한 검색 툴은 어떻게 정규화하는지 알지 못하는 것이 분명하며, 구문들을 제대로 정규화하지 못한다.
렌더링 문제와 영세한 개발자에 의해 개발된 잘못된 검색 문제가 우리들을 괴롭히고 있음에도, 단지 시간만 좀 걸릴 뿐, 다른 개발자들이 잘못된 소프트웨어를 고칠 수 있으며, 그 문제들이 무시할만큼 작은 문제라고 우리는 자만하고 있다
정식 순서를 부여하는 문제는 보다 어려운 일이다. 현재 가용한 규준을 따르기만 하면 올바른 결과가 나오는 것은 분명 아니다. 유니코드체계는 호환성 원칙이 깨질 우려가 있기 때문에 정렬순서에 대한 정의를 바꾸지 않을 것이고, 따라서 정확한 정렬순위를 부여한 *새로운* 글자체계를 도입하지 않는 한 이 문제가 해결될 것 같지 않다.
우리는 어떻게 해야할까?
우리는 이 문제를 무시하고 그저 비켜 갈 수 있기만을 바라거나 (가장 손쉬운 방법이긴 하지만, 지속적으로 이의를 제기하는 특정 언어군과 마주해야 함), 완벽한 정규화를 포기하고 이득을 극대화하면서 문제는 최소화할 수 있도록 우리가 적용하는 원칙들을 바꿀 수 있다.
만약 우리가 정규화 양식 C (NFC)가 유해하다고 생각한다면, (비록 자매격인 NFKC 만큼 유해하지는 않지만) 가능한 해결방법 한가지는 아래와 같이 구성될 것이다:
- 모든 웹 입력에 대해 정규화 확인과정을 제거한다; UTF-8 충족 여부만 확인하도록 보다 제한된 형태로 바꾸고, 입력된 그대로 약간 이상한 구성양식을 허용함.
- NFC를 직접 적용하는 것을 꼭 필요한 곳으로 제한:
- Title::secureAndSplit()을 통한 페이지 표제어 정규화
- 검색 엔진 인덱스 생성
- 검색 엔진 질의들
이 방법으로 간섭은 최소화하고, 페이지 구문들이 임의 구성양식을 갖도록 허용하면서 링크와 내부 검색이 계속 작동하도록 보증할 수 있다. 이렇게되면 데이터베이스 양식을 변경하지 않아도 되고, 서비스 중단 없이 적용 가능하다.
그러나, 이는 페이지 표제어에 정규화를 적용함에도 불구하고, 어떤 면에서 보기 흉하거나 부적절한 형태로 보여지는 문제를 남겼다.
장기적 전망
페이지 표제어를 정규화되지 않은 형태로 표시하도록 허용하는 방법도 있다. 이는 임의로 대문자와 소문자를 혼합해서 작성할 수 있도록 허용하는 것과 함께 고려될 것이다.('IMonkey' 대신 'iMonkey')
이렇게 될 경우, 페이지 표제어는 디스플레이용 표제어 양식을 포함하도록 변화될 것이다:
page_title: 'IMonkey' page_display_title: 'iMonkey'
또는 아마도 놀랍기까지한 대-소문자가 혼재된 자료:
page_title: 'imonkey' page_display_title: 'iMonkey'
정식 표제어와 디스플레이용 표제어들은 위키의 본질을 지키기 위해 항상 상호변환이 가능할 것이다; 마우스를 이용하여 표제어를 복사한 후 [[link]]에 붙여넣기가 가능하며, 제대로 작동할 것이라고 기대할 수 있어야 한다.
이러한 변화들은 필연적으로 데이터베이스 구조의 변화를 수반하여 한 테이블에서 다른 테이블로 데이터변환이 대규모로 발생할 수 있으며, 결과적으로 보다 파괴적일 수 있기에, 얻을 수 있는 이득이 막대하게 크지 않는 한 우리는 가급적 이런 변화를 피해야 한다.
다른 정규화 양식들
NFC는 본래 의미론적으로 손실이 거의 없을 것으로 예상되었기에 선택되었지만, 경험상 우리가 바랬던 것처럼 항상 옳지는 않다는 것을 보여주었다.
다음으로 우리는 적어도 일부 목적에 부합하는 대안으로서 NFKC, 호환성 구성 양식을 생각해 볼 수 있다. 이는 명시적으로 보다 많은 손실이 발생한다: 검색을 하기 위해서는 호환성 양식이 권고되는데 이 방식이 추가 글자들 예를 들면 일반 라틴글자와 "전폭" 라틴글자들을을 겹치기 때문이다.
기괴한 입력자료에 대해 부합하는 짝을 찾아내고 검색 인덱스를 구성하기 위해서 NFKC를 사용하는 것이 적절할 수 있다. 그러나 나는 이러한 방식이 페이지 표제어에 대해서 충분히 안전한지 확신할 수 없다; 아마도 디스플레이용 표제어와 함께, 또는 없는 상태에서
정규화와 유니코드화는 양쪽 모두 봇에 의해 수행 가능하다. 지금까지는 "정규화"하는 어떤 봇도 알려진 것이 없지만, 기능 자체는 가능하다. "커프스봇-유니코드화(Curpsbot-unicodify)" 봇은 위키피디아의 다양한 문서들을 유니코드화해왔으며 역방향의 변환은 불가능하다.
같이 보기
- bugzilla:2399 (유니코드 5.0 편집자인 Ken Whistler의 답장과 함께)
- http://www.gossamer-threads.com/lists/wiki/wikitech/184440(메일링 리스트 줄거리 "Unicode equivalence")