LINUX.ORG.RU

Какое внутреннее предствление символов лучше подходит для текстового редактора?

 ,


0

1

Как удобнее внутри некоего абстрактного текстового редактора хранить/обрабатывать текст - в виде мультибайтовых строк, или wchar_t? У кого какие на этот счет мысли. Может здесь кто-то «ковырял» исходники какого-нибудь существующего редактора.

Вроде на первый взгляд удобнее работать с широкими символами. Но может быть и оборотная сторона медали, которая с первого взгляда и не видна?

wchar_t

Осторожнее. «широкие» кодировоки не камильфо, как только потребуется поддержка композитных символов. А так, на вкус и цвет

Deleted ()
Ответ на: комментарий от XMs

Для внутреннего представления UTF-16 — вполне разумный компромисс

Какой-то странный компромисс - не нашим, не вашим. С широкими символами удобно «передвигаться» по тексту. UTF-16 в этом смысле ничем не лучше UTF-8, только для UTF-8 хотя бы стандартная сишная библиотека есть на худой конец.

zloy_starper ★★★ ()
Ответ на: комментарий от zloy_starper

С широкими символами удобно «передвигаться» по тексту.

Чем удобно? «Широкие символы» точно так же могут содержать комбинируемые знаки, поэтому всё равно придётся прочесать всю строку и построить индекс, по какому адресу начинается каждый кластер графем. В этом смысле «широкие символы» ничем не лучше UTF-8.

anonymous ()
Ответ на: комментарий от zloy_starper

У UTF-16 фиксированный размер символа, соответственно, при размещении текста длинными непрерывными блоками можно гарантировать неизменное время доступа к случайному символу ценой большего расхода памяти и ограничению числа возможных значений. С UTF-8 так уже не получится

XMs ★★★★★ ()
Ответ на: комментарий от anonymous

Самый правильный редактор — без преобразования. Хранить надо так, как оно есть в файле, т. е. raw. Преобразования происходят при отображении и при вводе. Binary accuracy, короче.

akk ★★★★★ ()
Ответ на: комментарий от XMs

Многие символы занимают больше двух байтов. В UTF-16 даже русская буква Ё может не поместиться, если её представлять как Е + двоеточие.

Legioner ★★★★★ ()
Ответ на: комментарий от anonymous

При загрузке текста в буфер неплохо бы избавиться от таких штук заменой на эквивалентный символ.

anonymous ()
Ответ на: комментарий от zloy_starper

удобно «передвигаться» по тексту

Бгг. Нет

Deleted ()
Ответ на: комментарий от anonymous

Замени-ка мне а́ на эквивалентный символ.

anonymous ()
Ответ на: комментарий от Legioner

если её представлять как Е + двоеточие

Если так — да. Поэтому я и назвал UTF-16 компромиссом, а не идеальным решением

XMs ★★★★★ ()
Ответ на: комментарий от Deleted

А сейчас это мультибайт

Ты не путаешь с UTF-8? Насколько мне известно, UTF-16 и UTF-32 фиксированы в своём размере

XMs ★★★★★ ()
Ответ на: комментарий от RazrFalcon

А вот об этом я и забыл, ибо не пользуюсь

XMs ★★★★★ ()
Ответ на: комментарий от XMs

«Суррогатные пары» эта шняга называется

Deleted ()
Ответ на: комментарий от anonymous

Это не от меня зависит. Нужно чтобы все сопутствующие либы обновили Unicode до 11 версии.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от Deleted

Ну вообще я за UTF-8 везде. Как видно из URL в профиле.

Про Rope тут уже сказали.

Лучше всего хранить так, как хранят уже существующие текстовые редакторы и не писать новых редакторов.

utf8nowhere ★★ ()

Можешь свой вариант придумать для внутреннего представления исходя из своих целей.

Написать хороший текстовый редактор не так легко, как кажется.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Bfgeshka

Написать хороший текстовый редактор не так легко, как кажется.

Поэтому хорошего до сих пор и нет. Увы.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от utf8nowhere

Это чтобы поиск делать. Если ты файл перезаписываешь, значит уже поменял и формат определяется кодировкой записи.

monk ★★★★★ ()
Ответ на: комментарий от anonymous

неплохо бы избавиться от таких штук заменой на эквивалентный символ

Это не всегда возможно.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от XMs

Нет у UTF16 никакой фиксированности, любой символ за пределами BMP требует кодирования двумя суррогатами, например, emoji. Типичная ошибка, которую UTF16 провоцирует - обрабатывать его как UCS-2, устаревший в 1990-х годах.

quiet_readonly ★★★★ ()
Ответ на: комментарий от x3al

могу выделить мышью 4 отдельных символа (👩‍ ❤️‍💋‍👩)

(👩‍ ❤️‍💋‍👩) и (👩‍❤️‍💋‍👩) — разные строки. Первая — три символа (один из них пробел), вторая — один.

поэтому он не одинок

Так Unicode вообще сложная штука. В этой строке в зависимости от программы до 8 символов распознаётся

monk ★★★★★ ()
Ответ на: комментарий от anonymous

Это у тебя понятия нет, а в юникоде есть однозначное понятие «grapheme cluster».

Сколько графемных кластеров в слове «mach»? 3 или 4?

monk ★★★★★ ()
Ответ на: комментарий от anonymous

И ещё есть, например, «coffin». Тут 6 графемных кластеров и всего 4 глифа.

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.