graphemes에 기반한 문자열 클래스?

코드 포인트 또는 문자 대신 유니 코드 그래프 클러스터 클러스터를 나타내는 문자열 클래스가없는 이유가 궁금합니다. 대부분의 응용 프로그램에서 프로그래머가 필요에 따라 그래프 요소의 구성 요소에 액세스하는 것이 코드 포인트에서 구성하는 것보다 쉬울 것 같습니다. "중간 그래프"에서 문자열을 우연히 끊지 않아도 필요한 것처럼 보입니다. (적어도 이론상). 내부적으로 문자열 클래스는 UTF-8, UTF-16과 같은 가변 길이 인코딩을 사용하거나이 컨텍스트에서 UTF-32도 가변 길이입니다. 또는 모든 서브 클래스를 구현하고 선택적으로 런타임시 선택 사항을 구성하여 다른 언어가 최적의 인코딩을 사용할 수 있도록합니다. 그러나 프로그래머가 스트링을 검사 할 때 그래 핀 단위를 "볼"수 있다면

정확성을 얻는 가장 좋은 방법은 프로그래머가 "문자열 해킹"을하지 않도록하는 것입니다. 자신 만의 단어 줄 바꿈, 하이픈 넣기, 단어 수, 자리 맞추기, 커서 이동 등을 작성하는 것은 좋지 않습니다. 모든 최신 UI 프레임 워크가 요즘이 작업을 수행합니다.

즉, 일반적으로 작업하는 추상화는 GTK와 같은 "단락 표시 객체"에 가깝습니다. http://library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

http://library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html 과 같은 grapheme 문자열이 아닌

글리프 문자열을 얻으려면 "보기"수준에서만 사용할 수있는 정보가 필요하므로 대부분의 문자열 사용에는이 정보가 없을 수 있습니다. 예를 들어, 글꼴은 합자가 다를 수 있으므로 글꼴을 알아야합니다.

이런 종류의 실용적인 문제 외에도 글리프는 아마도 당신이 원하는 것이 아닙니다.

많은 컨텍스트에서이 API에 표시된 올바른 유니 코드 속성을 사용하려고합니다 (예 : http://library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

이 구조체 (유니 코드 알고리즘을 반영)에서 볼 수 있듯이 글리프 경계에서 다양한 작업을 수행하는 것은 문자 경계에서 수행하는 것보다 더 정확하지 않습니다.

이 두 사양은 서로 다른 종류의 경계를 찾는 알고리즘을 설명합니다.

• http://www.unicode.org/reports/tr14/
• http://www.unicode.org/reports/tr29/

텍스트 처리를 수행하려면 알고리즘으로 해당 경계를 찾은 다음 경계로 작업해야합니다.

모든 언어를 올바르게 처리하는 것이 얼마나 어려운지에 대해 파고 들기 시작하면 전체 단락을보고 올바르게 처리하는 라이브러리가 필요하다는 것을 매우 빨리 깨닫게됩니다. Windows, Mac, Linux (Qt 및 GTK) 및 Java에는 모두이를위한 기능과 함께 http://site.icu-project.org/ 가 있습니다.

불행히도 웹 응용 프로그램을 작성할 때 브라우저 (OS에서 도움을 얻었을 것)가 내가 아는 한이 작업을 수행하도록해야합니다. JavaScript 또는 서버 측에서 할 수있는 모든 작업은 엉망입니다.

어쩌면 나는 대답을 요약 할 것입니다 : 자연 언어 텍스트에서 대부분의 문자열 조작이 중단되었으므로 문자열 클래스에 대해 걱정하지 않아도됩니다.