Unicode 16.0

Лучше тогда уж сразу �’

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

Второе, мне было бы насрать на всякое говно напиханное в эмодзи, если бы оно было нормально организованно по группам и отсортировано по частоте применения.

condom отклонили, причем дважды
вместо этого знаете што? вот ☔ што
с такими психотравмами в нашей бессердечной индустрии работать нельзя, уберите ранимых из комитета

Второе, мне было бы насрать на всякое говно напиханное в эмодзи, если бы оно было нормально организованно по группам и отсортировано по частоте применения.

А в чём проблема то? Представь что его нет и всё. Мало ли что там бюрократы награфоманили.

смайлики в ИТ

Ну всё-таки смайлики из CP437 это схожая, но иная вещь. Похожие изобретения могут появиться одновременно.

безотносительно японских эмодзи, которые составлены из иероглифов

Из иероглифов составлены скорее каомодзи.

Я и не начинал еще, всё жду пока эти букварь допишут.

Тю, ещё хуже. Спрайтов понапихали. В юникод. Вот нахуахуа?

чтобы даже сраный блокнот потреблял гигабайты озу

в Arial Unicode MS всего лишь 50377

Ну дык: Arial Unicode MS = 22.1mb / 50377 * 154998 = 67 mb

чтобы даже сраный блокнот потреблял гигабайты озу

Можно сделать редактор с частичной поддержкой юникода. Или вообще без, как mg в OpenBSD.

Тем более эти символы с person/men/women… 🫃🧚‍♂️🧜…

Новые гендеры добавили?

Угу, вот только для того чтобы банальный facepalm или shrug воткнуть приходится листать огроменный список.

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

$ cat smiles.txt 
👍 👎 🔥 😊 😱 🤔 🤡 🤦

facepalm или shrug воткнуть

Куда? :)
Если в ЭТ, то в WezTerm есть встроенная возможность CharSelect.

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

Пока нет беременного боевого вертолёта - никуда не годится!

Немного обновил:

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

Не знаю что такое shrug

¯\_(ツ)_/¯

PS Откуда я это знаю? О.О И на кой чёрт оно в моей голове осело когда-то?! Сколько же там хлама бесполезного…

В UnicodePad для Android (реклама отключается) сегодня добавилась поддержка нового стандарта.

В https://github.com/arp242/uni (на Go) добавили уже 11-го.
Написать новость, что ли. :)

Возмутительно, что добавили контурные буквы только для английского алфавита. Надо было добавлять для всех 250 стран мира.

шрифт, в котором есть всё

К этому стремится проект No Tofu и шрифт Noto.

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

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

а там пол-списка - простыня вот этого самого нотофу.

А нельзя сделать этот самый Noto один в качестве универсального шрифта по умолчанию (fallback)?

Чтобы не было квадратиков и не было вагона ненужных (пользователю) шрифтов.

А есть шрифт, в котором есть всё. Сколько он весит?

Я бы не отказался от моно-ширинки в которой есть 100.0% символов. Даже если это будет надергано из шрифтов разных стилей, лишь бы положили в один файл

Хорошо бы такое получить от unicode.org, раз они такие добавляторы, то могли бы предоставить эталонный такой файл где всё всё есть

В emacs M-x insert-char и там вводишь название.

В на Android часто можно ввести название эмодзи после двоеточия, чтобы оно заменилось нужным эмодзи.

И там и там fuzzy search.

5185 новых символов

Огласите весь список, пожалуйста! (с)

лицо с «мешками» под глазами

О, это для меня добавили :D

А нельзя сделать этот самый Noto один

Это не ко мне вопрос, а к создателям.

После удаления всего ното-интернационала у меня в системе остались:

Noto Color Emoji
Noto Mono
Noto Music
Noto Sans
Noto Sans Display
Noto Sans Mono
Noto Serif
Noto Serif Display

Если похерить еще и эти - перестанут отображаться эмодзи, ноты... ну, и вообще-то тот Ното в Убунтах сейчас шрифт интерфейса по умолчанию. Так что его удаление похерит метапакет *-desktop как минимум, а то и пол-системы.

На данный момент стандарт содержит 154998 символов

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

более 700 символов устаревшей вычислительной техники.

По ссылке никакой устаревшей техники не наблюдается.

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

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

Глядя на все эти символы переменной длины и составные символы в юникоде, которые надо нормализовывать, я вспоминаю старую идею, иметь номер кодировки перед группой символов. Типа сначала идёт номер кодировки «русский», а потом символы в этой кодировке. Реализовать это достаточно просто, а главное места в памяти будет меньше занимать. Длину этого кода сделать переменной длины. Если зарезервировать под это последние, допустим 16 значений из 255 (можно от 1 до 127, сколько именно надо исследовать), то можно даже сохранить совместимость с ascii8.

Да, набор новых символов впечатляет! Как раньше было без лопаты?

Звучит как хорошая идея, языки переключаются не так уж и часто. А индексирование все равно в utf-(8|16|32) невозможно.

Опа! Так вот как это делают!

В Windows и в GTK для этого есть специальный диалог и клавишесочетание, с поиском текстом https://www.omgubuntu.co.uk/wp-content/uploads/2018/06/emoji2.jpg

А индексирование все равно в utf-(8|16|32) невозможно.

utf-32 тут лишняя.

Нет, иначе получится как в питоне

>>> s = '⚔️'
>>> len(s)
2
>>> s[1]
'️'

Нет

Читай https://ru.wikipedia.org/wiki/UTF-32:

Главное преимущество UTF-32 перед кодировками переменной длины заключается в том, что символы Юникод непосредственно индексируемы. Получение n-ой кодовой позиции является операцией, занимающей одинаковое время. Напротив, коды с переменной длиной требует последовательного доступа к n-ой кодовой позиции. Это делает замену символов в строках UTF-32 простой, для этого используется целое число в качестве индекса, как обычно делается для строк ASCII.

Попробуй открыть глаза %) Я пример выше привел. Код_с_примером > Какая_то_писанина

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

Может показаться, что использование UTF-32 в качестве внутреннего формата строки является убедительным, поскольку он использует одну кодовую единицу на кодовую точку . Однако символы Unicode редко обрабатываются в полной изоляции. Например, объединение последовательностей символов может потребовать обработки как единого целого ...

В общем один utf32_t не подходит для индексирования отдельно от других символов. Так что прежде чем позорится, лучше прочти что кидаешь другим.

Так и utf8 можно индексировать, надеясь что нету символов (воспринимаемых человеком) которые кодируются больше чем одним байтом.

Как-то маловато. Я думал что одних только японских иероглифов около 150000.

Существенно меньше, японцы у себя насчитывают ~50 тыщ, у китайцев ~85 тыщ. И это уже включая всякие там архаизмы и слова, употреблённые пять раз за всю историю языка, т.е. для нас что-то типа словаря от «кринжа» и «хлеба» до «доднеже» и «поелику». Реально в Японии в ходу где-то 5 тысяч. Для обычной грамотности нужно знать ~2.5 тысячи. Ну как знать... узнавать на письме скорее. Сами японцы и китайцы обычно нихрена не знают в рамках «активного словаря», кроме самых ходовых. Причём у японцев всегда есть план Б, тупо хираганой написать слово.

Скудно и мало. Обращаю внимание, что всё уже придумано до нас, осталось только внедрить: https://www.youtube.com/watch?v=73fmGhEoBy0

Когда завезут в perl5 поддержку этого стандарта? А то Владимир Перепелица любил хвалица. Что perl5 — ЯП, в котором первом появляется новейшая версия юникода.

Всмысле «скудно и мало»? Макском выбрал полезные смайлы из юникодных простыней, ими и пользуюсь, не вижу смысла искать другие. Я и про эти не знал пока реакции на лоре не ввели.

Код_с_примером

Натянул питона на морковку комбинируемые символы.

Однако символы Unicode редко обрабатываются в полной изоляции. Например, объединение последовательностей символов может потребовать обработки как единого целого …

Не доходит, что эта обработка строк UTF-32 будет быстрее, чем обработка UTF-8?

Так что прежде чем позорится, лучше прочти
позорится

Ожегова. Лучше прочти https://tsya.ru.

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

Да нет, utf-8 быстрее скорее всего будет, ему надо раза в 2.5-3 меньше байт из памяти в среднем читать. А индексированные строки что там что там не получаются.

utf-8 быстрее скорее всего будет, ему надо раза в 2.5-3 меньше байт из памяти в среднем читать

Но тратится время на декодирование/преобразование байтов в int. В UTF-32 они уже декодированы.

А индексированные строки что там что там не получаются.

Получаются:
~ $ uni identify ⚔️

Dec    UTF8        HTML       Name
'⚔'  U+2694  9876   e2 9a 94    ⚔   CROSSED SWORDS [military term, battleground (on maps), killed in action]
'◌️'  U+FE0F  65039  ef b8 8f    ️   VARIATION SELECTOR-16 [emoji variation selector]

Всего два int/codepoint: 9876 и 65039. Но графема одна.

Возможно ты споришь, потому что думаешь sizeof(графема) == char32_t, иначе я не понимаю зачем ты ее тут выделил. В UTF-8 точно так же, несколько символов (charX_t), для одной графемы.

Но тратится время на декодирование/преобразование байтов в int.

А зачем тебе их преобразовывать в int?

Ну и? Какой индекс у этой графемы и сколько байт она занимает?

В UTF-8 точно так же, несколько символов (charX_t), для одной графемы.

Начинай сначала. :(
Речь была об обращении к этим символам по индексу!

А зачем тебе их преобразовывать в int?

Потому что codepoint не влезает в байт. Пусть будет uint32_t, не суть.

Макаки развлекаются короче, понятно.

тратится время на декодирование/преобразование байтов в int.
В UTF-32 они уже декодированы.

Время тратится внутри процессора. А узкое место - это доставка из памяти и в память. Поэтому это нормально - хранить строки в памяти зазипованными.