Unicode 16.0

🐵

Я не понимаю твои ответы, поэтому не буду их обсуждать, давай вернемся к тому что ты скинул из Wikipedia, буду рассуждать в установленных unicode.org терминах

UTF-32 ... символы Юникод ... индексируемы ...

Это неверно, дальше объясняю почему, но предплагаю что это твое мышление. Символ это не кодовая точка. char32_t может вместить только любую кодовую точку, и думаю лишь временно, а любой символ в него поместить не получится, так же как и в UTF-(8|16), хотя некоторые и влазят.

Когда говорят о возможности индексирования строки, подразумевают что индексируется строка, текст, а не набор кодовых точек Unicode. При возможности беспроблемной индексации строки, операция «заменить 5 символ на символ цифры 1», превращается в

str[5] = '1'

По ссылке ничего вообще не наблюдается, такое ощущение что смотреть эту страницу нужно с поддержкой шрифтов только что зарелизенногоо стадарта.

Когда им уже кто-нибудь геноцид устроит, а? ГОРШОЧЕК, НЕ ВАРИ!!!

Интересно, а сколько всего ещё осталось включить символов?

Полагаю, запас символов во Вселенной не ограничен. Так что только отстрел членов комитета способен остановить эту мясорубку.

раз они такие добавляторы, то могли бы

Фишка комитетов ровно в том, что они не несут ни малейшей ответственности за содеянное. Если бы это было не так, на земле настал бы рай, и в этом раю не было бы ни одного комитета.

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

семь новых символов эмодзи: лицо с «мешками» под глазами, отпечаток пальца, безлистное дерево, корнеплод, арфа, лопата и брызги;

ну наконец-то! лопата есть, теперь можно закапывать это говно!

Символ – это тоже мутное понятие. Является ли лигатура одним символом или несколькими? Являются ли модификаторы эмодзи (пол, всет кожи и т.п.) отдельными символами? Диакритика?

Я думаю разумно вообще забыть о концепции символов при работе с текстом и индексировать всё в байтах. Рассматривать любой символ как строку.

UTF-8 2^21= 2097152 символов, они еще даже 10% не отработали

На unicode.org есть пояснение по терминам, там отвечают на твои вопросы.

Не понял в чём суть. Зачем делить байт номера, например? В целом, напоминает Win1251 и пр. Хотя и без номера кодировки.

Ну основная идея надеюсь понятна? Вместо того чтобы делать одну кодировку на все языки, оставить (как раньше) кучу кодировок, но при этом добавить префикс переключения языка. Это логично, потому что тексты и строки обычно содержат в основном длительные последовательности символов на одном языке. Это позволит сэкономить память.

Дальше уже вопрос, как это сделать лучше, потому что есть несколько вариантов.

Например можно зарезервировать одно значение байта (допустим 255 или 0, но ноль плохо потому что 0 уже используется в С для обозначения конца строки), который будет запрещён к использованию во всех языках и будет обозначать что за ним идёт код переключения языка.

Таким образом, если первый байт строки будет не 255, то по-умолчанию мы может интерпретировать её как ascii, пока не встретится 255. Это даст совместимость с ascii текстами. А если мы встретим в тексте 255, то должны будем прочитать код языка из последующих байт.

Есть и другие варианты, если зарезервировать несколько значений, а не одно.

Например можно зарезервировать одно значение байта (допустим 255 или 0, но ноль плохо потому что 0 уже используется в С для обозначения конца строки), который будет запрещён к использованию во всех языках и будет обозначать что за ним идёт код переключения языка.

Ненадёжно, потеряется этот байт и всё превратится в кашу.

Ненадёжно, потеряется этот байт и всё превратится в кашу.

Да, до следующего байта-переключателя. Но в принципе восстановить текст будет всё ещё возможно статистическими методами (или перебором), как мы это можем сделать и сегодня для текстов в старых кодировках. Человеческие языки сами по себе достаточно избыточны.

Кто его знает, будет ли это лучше и экономичней. «Просто текст» сейчас редкость. Текст сейчас в основном форматирован. Попадая в Word (Writer) и прочие он сразу автоматом приобретает массу параметров. Или взять html. Там текст заключён в тэги. Одни теги вложены в другие. Где ставить маркер? Где-то в начале? Может вообще в head? Или в каждый отдельный p? В общем, много вопросов.

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

вспоминаю старую идею, иметь номер кодировки перед группой символов. Типа сначала идёт номер кодировки «русский», а потом символы в этой кодировке

Так в Delphi сделано. Но там номер кодировки не на группу символов, а на всю строку.

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

Я описал как хранить в большом куске, в файле. А для работы с отдельными строками в памяти возможны варианты. Тебя же устраивает сегодня что где-то по тексту в текстовом файле раскиданы переводы строк?

Текстовый редактор, например, может вставлять маркер в начале каждой строки при загрузке файла в память. И наверное ещё лучше пойти дальше и разделять на строки в памяти всегда так, чтобы они всегда были на одном языке.

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Не сильно усложняется даже по сравнению со старым однобайтовым текстом. Да, для работы со строками удобней будет использовать библиотеку, но это же сегодня надо делать и для юникода. Собственно работа с маркером языка будет подобна тому что и сегодня с маркером новой строки (который у нас ещё и двух типов - юниксовый однобайтовый и досовский из двух байт). Обычно строки при загрузке из текстового файла разбивают по этим маркерам. А тут нужно будет разбивать дополнительно и по маркеру 255. Всего-то! Примерно столько же работы. А если в каждой строке хранится её кодировка, то всё просто. То есть ты всегда будешь знать какой язык у тебя в строке хранится.

Так в Delphi сделано. Но там номер кодировки не на группу символов, а на всю строку.

Ну я больше про файлы говорил. А в памяти наверное действительно удобней будет хранить один язык в одном monostring. А для удобства работы наверное неплохо будет сделать ещё один уровень абстракции - цепочка строк, что-то вроде сhainstring, который будет объединять цепочку monostring в одну строку. Вопрос только, лучше ли их хранить одним куском в памяти или отдельными кусками. Наверное понадобятся оба варианта.

Можно ещё посмотреть, как хранятся в памяти всякие markdown тексты, которые имеют маркеры.

Бедные авторы шрифтов…

чтобы написать свинья используя египетские иероглифы - нужно поставить птицу, хуюмбулу и свинью. хотя свинья это отдельный иероглиф. к чему бы не использовать его без птицы 𓃟𓃟𓃟

𓂸𓂸𓂸𓂸𓂸𓂸 𓂺𓂺𓂺𓂺𓂺𓂺 обращайтесь

ГОРШОЧЕК, НЕ ВАРИ!!!
Когда им уже кто-нибудь геноцид устроит, а?

Когда кончится место в 32 битах.

Я думал что одних только японских иероглифов около 150000. Плюс китайских столько же. Плюс прочие символы.

Когда задумывали Юникод в самом начале 1990-х, исходили из того, что все иероглифы Китая, Кореи и Японии — общие (CJK — Chinese, Japanese, Korean), и их менее 40 000. Плюс слоговые алфавиты для Кореи и Японии. Реально там нашлись неучтённые тонкости, но этот блок более чем достаточен для повседневного использования. Встречал утверждения, что в японскую 2-байтную таблицу впихнули всё вышеперечисленные с учётом этих тонкостей, плюс все европейские, включая кириллицу, и ещё много места осталось, но все предпочли Юникод.

https://cs7.pikabu.ru/post_img/2018/05/09/7/1525861965179115960.jpg

Колба с нагреваемой жидкостью и приёмник запечатаны резиновыми пробками? Обязательно должно рвануть. Хотя бы хлопнуть и выбить пробки.

чтобы написать свинья используя египетские иероглифы - нужно поставить птицу, хуюмбулу и свинью. хотя свинья это отдельный иероглиф. к чему бы не использовать его без птицы

Насколько я помню детские научно-популярные книги о древнеегипетском, символы большую часть их истории обозначали не слова, от которых они произошли, а какой-то согласный звук из соответствующего слова. Например, символ льва обозначал звук «л». Гласных не было, и читатель должен был угадывать, что и куда в этот набор согласных подставить. А чтобы сделать прочтение однозначным, добавляли специальный символ, обозначавший общую тему. Поэтому могу предположить, что там 2 символа — звуки из слова «свинья», а птица обозначает «животное». Как-нибудь так.

Я тащусь от этих нововведений! Вот бы еще эмодзи всех 65536 гендеров добавили! А то мусора в таблице символов как-то мало, знаете.

Ну так BMP тоже двухбайтовая, и вполне достаточна для повседневного использования. А у JIS-кодировки есть свои проблемы. Но таки да, с CJK в Юникоде тот ещё зоопарк. Вроде как национальные варианты иероглифов должны выбираться при помощи VARIATION SELECTOR, но один хрен их зачем-то море в основной таблице (возможно, как раз потому, что в легаси-кодировках типа JIS они разные).

BMP тоже двухбайтовая, и вполне достаточна для повседневного использования.

BMP и есть более-менее тот Юникод, каким его описывали в 1991 году.

«Просто текст» сейчас редкость.

Наоборот, большая часть текста в памяти это latin-1, думаю что остальная часть это местная кодировка.

Или взять html. Там текст заключён в тэги. Одни теги вложены в другие. Где ставить маркер?

Система кодировки не зависит от формата который ее использует, ты что то не так понимаешь. Вообще в CP-1251 есть английские буквы, поэтому для html переключать кодировку вообще не надо.

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

Что значит текст в середине? Через GUI? Он уже разбил текст по отображаемым символам, у него такой проблемы не будет. Я не знаю как оно на самом деле работает, но привязывать строки или символы к индексам хорошая идея.

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Что значит часть другой строки? Это архивация? Тогда нам все равно, запакуем, при распаковке сделается как было, потому что работаем с потоком байтов, не важно что там внутри текст или изображение.

Если ты мешаешь строки, то ты и в UTF-* не может взять рандомные слайсы и миксовать их, даже просто взять не можешь, иначе обрубишь многобайтовые символы. А до них может быть еще что нибудь, например: https://unicode-explorer.com/c/200F

Новых проблем по сравнению с UTF-* это не добавит. Зато можно будет убрать зависимость от локали, в Unicode некоторые символы отображаются по другому в зависимости от локали пользователя.

Чё-то тут какая-то нескладуха вышла. Ты вообще не понял о чём я написал. Все пункты мимо. А я вообще не понимаю то, что ты написал.

Думаю если ты прочтешь о UTF-8, о работе с unicode-текстом в программах, то все автоматически станет ясно, кроме вот этого:

«Просто текст» сейчас редкость.

Наоборот, большая часть текста в памяти это latin-1, думаю что остальная часть это местная кодировка.

Эту информацию я взял с https://openjdk.org/jeps/254, но более подробной ссылки я найти не смог.

Ты вообще не понял о чём я написал.

Ну как, примерно понял, у тебя очень странная модель того как работают кодировки.

Все пункты мимо.

Скорее всего мои ответы просто тебе непонятны из за того что не натягиваются на твою модель.

Новых проблем по сравнению с UTF-* это не добавит. Зато можно будет убрать зависимость от локали, в Unicode некоторые символы отображаются по другому в зависимости от локали пользователя.

Да, там ещё с одной турецкой буквой был прикол, я смутно помню. Она в зависимости от локали по-разному сортируется. Если одна локаль то сортировка будет по-одному, а если другая локаль, то те же строки будут отсортированы по-другому. То есть вообще бред выходит.

Нужен именно маркер языка, чтобы знать, что за язык в строке, тогда будет понятно как его сортировать. И орфографию будет удобней проверять - будет точно понятно что за язык здесь, в каком словаре смотреть. Я вообще кучу преимуществ вижу, если мы знаем, какой язык здесь.

Например, одна и та же по-начертанию буква «с» есть во множестве языков, но тем не менее, влепили две буквы «с», одну кириллическую, другую латинскую. Спрашивается, зачем, если я всё равно не знаю, какой язык? Тогда бы уже сделали алфавит для каждого языка, чтобы их можно было отличать. Но нет - тут сэкономили… А с маркером языка это становится логично, упорядочено и удобно. Главное - компактно

Думаю если ты прочтешь о UTF-8, о работе с unicode-текстом в программах

Это не особо требуется. Что оно из себя представляет я в общих чертах понимаю. Для высокоуровневых языков этого уже достаточно.

Просто всё что ты написал, оно вообще никак не стыкуется с тем, что написано у меня. Я даже удивлён, если честно. Лень вникать в подробности, потому что там 100% непонимание. Реально о разных вещах говорим.

Новых проблем по сравнению с UTF-* это не добавит.

По мне так добавит. Даже такая мелочь как bom требует к себе особого внимания и может сбить с толку, если забываешь про неё. А тут речь про «bom» в самых неожиданных местах. Мне кажется, что это всё сильно осложнит. Будешь вместо простейших манипуляций со строками (ну типа, нашли нужный символ, берём подстроку от начала до найденого, или от найденого + ещё столько-то) ты будешь вынужден постоянно контролировать этот «bom». Ну это капец какой-то. И там, где-то в обсуждении было замечание, типа, «ты же не против перевода строк». Но если ты чуток ошибся и захватил лишний перевод строки или пробел, то это не так критично, как если ты захватил такой вот «bom» от другого языка.

Всё это, разумеется, imho.

В UTF-* этот аналог BOM уже присутствует, примеры выше.

И что?

X: Новых проблем по сравнению с UTF-* это не добавит.
Y: По мне так добавит ... BOM ...
X: В UTF-* этот аналог BOM уже добавлен
Y: И что?

То что оно не может добавить BOM, он уже есть.

Вот ты как себе это представляешь? Предположим, сидит человек и набирает текст на русском, потом он переключает раскладку на украинский и первое что он ставит это пробел. Получается что маркер языка стоит перед пробелом. Это никак не осложняет ситуацию? По мне так осложняет. Потому что ты, предположим, потом сделаешь сплит по пробелам. Куда уйдёт маркер? Не туда куда нужно! И исчезнет там, где он должен быть. И таких ситуаций море.

s = "куда уйдет <202e> маркер"
print(s)
s = s.split(' ')
s.reverse()
print(' '.join(s))

куда уйдет ‮ маркер
маркер ‮ уйдет куда

--------------------

s = "куда уйдет <202e> маркер"
print(s)
print(s.split(' ')[-1])

куда уйдет ‮ маркер
маркер

И что это за клинопись? Зачем ты всё соединил опять? Показывай построчно, где оказался маркер.

Это UTF-8, маркер это <202e>, как видишь уже на UTF-8 все сломалось ((

С тобой тяжело. Может ты какой-то гений, но почему-то не понимаешь простейших вещей, сразу углубляясь куда-то. Вот я написал bom, а потом поставил «bom» в кавычки, какбэ показывая, что это что-то-вроде-бом. А ты мне что пишешь? И так далее. Надо как-то на одном уровне общаться. Либо на простом, либо на сложном. Короче я пас.

Предположим, сидит человек и набирает текст на русском, потом он переключает раскладку на украинский и первое что он ставит это пробел. Получается что маркер языка стоит перед пробелом. Это никак не осложняет ситуацию? По мне так осложняет. Потому что ты, предположим, потом сделаешь сплит по пробелам. Куда уйдёт маркер? Не туда куда нужно! И исчезнет там, где он должен быть. И таких ситуаций море.

Я правильно понял задачу? У меня есть длинный кусок файла с маркерами и я хочу её разделить его по словам, выбросить пробелы, переводы строк и распихать слова в отдельные строки? Ну я пойду с начала строки и буду вырезать слова, при этом буду следить за маркерами языка и сохранять в каждой строке правильный маркер. Немного усложняется, но по-моему совсем немного.