Клас струн на основі графем?

Мені цікаво, чому у нас немає деяких рядкових класів, які представляють рядок кластерних графем Unicode замість точок коду чи символів. Мені здається, що в більшості додатків програмістам буде легше отримати доступ до компонентів графеми, коли це необхідно, ніж організувати їх з кодових точок, що видається необхідним, навіть якщо тільки уникнути випадкового розриву рядка в "середині графеми" (принаймні теоретично). Всередині клас рядків може використовувати кодування змінної довжини, наприклад UTF-8, UTF-16, або в цьому контексті навіть UTF-32 є змінною довжиною; або реалізувати підкласи для всіх (та необов'язково налаштувати вибір під час виконання, щоб різні мови могли використовувати свої оптимальні кодування). Але якби програмісти могли "бачити" графічні одиниці під час огляду рядка, не буде "

Здається, найкращим способом коректування є те, щоб програмісти не робили "злому рядків" ... просто не в порядку писати власну обробку слів, дефіс, кількість слів, обґрунтування, переміщення курсору тощо. Усі сучасні структури інтерфейсу будуть робити ці речі для вас сьогодні.

Тобто абстракція, з якою ви зазвичай працюєте, більше "об’єкт відображення абзацу", наприклад, для GTK: http://library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

а не графема, наприклад: http://library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html

Щоб потрапити на рядок гліфів, вам потрібна інформація, яка доступна лише на рівні "view", тому для більшості застосувань рядків ця інформація може не мати. Наприклад, ви повинні знати шрифт, оскільки шрифти можуть мати різні лігатури.

Окрім такої практичної матерії, гліфи, мабуть, не те, чого ви хочете.

У багатьох контекстах потрібно використовувати належні атрибути Unicode, показані в цьому API, наприклад: http://library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

Як видно з цієї структури (яка відображає алгоритми Unicode) робити різні речі на межі гліфів не є більш правильним, ніж робити їх на межі символів.

Ці дві характеристики описують алгоритми пошуку різних видів меж:

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

Обробка тексту включає пошук цих меж з алгоритмами, а потім роботу з межами.

Якщо ви почнете розкопуватись на тому, наскільки важко правильно обробляти всі мови, ви дуже швидко зрозумієте, що вам потрібна бібліотека, яка розглядає цілі абзаци та правильно обробляє їх. Windows, Mac, Linux (Qt та GTK) та Java мають всі можливості для цього, а також http://site.icu-project.org/, наприклад.

Під час написання веб-додатків, на жаль, вам доводиться дозволити браузеру (мабуть, допомагає ОС) робити це, наскільки я знаю. Все, що ви можете зробити в JavaScript або на стороні сервера - це зіпсувати це.

Можливо, я би підсумував відповідь так: більшість маніпуляцій з рядками на тексті натуральної мови порушені, тому не варто багато хвилюватися про клас рядків, крім, можливо, мати один, у якому немає методів на ньому ;-)