Previous Entry Share Next Entry
2016-01

Про юникод

Сегодня я понял, что языков программирования, претендующих на звание "поддерживается работа со строками" - нет.

Ну, оно и раньше так было, но мучались только китайцы с японцами. А с приходом эмотиконов (var unicode_emoticons = "😀😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏"; с этим теперь столкнулись все, и делать вид что UCS-2 - это Unicode уже не выходит.

Ради интереса полез посмотреть в сорцы VK и фейсбука. Ну что, тысячи строк регексов, скан-кодов и if'ов шарашат туда-сюда эти кодпоинты, ради того чтобы юзер мог скопипастить смайлик в поле ввода.

Кто-то отдал месяц своей жизни на смайлики. Закат солнца вручную, привет!

С, Lua и Эрланг хотя бы не делают вид, что строки там поддерживаются. Но, знаете, пользоваться строковыми константами всё-таки иногда бывает удобно...

А, да, и RTL локали еще не забудьте.

UPD: отдельное "спасибо" авторам Han unification, из-за которого юникод потерял задуманное изначально свойство "смысл строки не меняется от локали", и мы имеем GB18030 и Shift-JIS.

This entry was originally posted at http://wizzard.dreamwidth.org/414780.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
swizard January 2nd, 2015
> языков программирования, претендующих на звание "поддерживается работа со строками" - нет

Не, ну это, всё же, не совсем так :)


CL-USER> (code-char 128512)
#\GRINNING_FACE
CL-USER> (string #\GRINNING_FACE)
"😀"



Rust, опять же, использует внутри utf-8 для своих строк.

wizzard0 January 2nd, 2015
Это далеко не всё. Есть еще комбинирующие(ся?) символы, лигатуры и нормализация.

109 January 2nd, 2015
нормализация реально раздражает. как только забыл Normalize(), ожидай проблем. но если его всё время надо вызывать anyway, почему не зашить его прямо в оператор присваивания?

wizzard0 January 2nd, 2015
Нормализация, в отличие от кодировки - необратимое преобразование.

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

109 January 2nd, 2015
ну да, я преувеличил. но расход мозга на то, чтобы каждый раз думать, надо тут Normalize(), или нет, намного превышает пользу от нескольких сэкономленных тактов процессора.

justy_tylor January 2nd, 2015
Если так, то удобнее сделать тип NormalizedString, если языковые правила приведения типов позволят.

daedmen January 3rd, 2015
А нормализуют только для сравнения?

gds January 2nd, 2015
в окамле тоже со строками всё честно: набор байтов, а что внутри -- от приложения зависит. Что характерно, внутрь строк обычно лезть не надо, достаточно хранить их как есть, ну и уметь склеивать.

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

wizzard0 January 2nd, 2015
Камл, да.

wizzard0 January 2nd, 2015
> И посмотрел я на языки, "умеющие" юникод.

Ну вот про это и бугурт, да.

justy_tylor January 2nd, 2015
Ох лол. Эти эмотиконы в посте видны колобками, а в ленте (старого стиля) или просмотре сорца 01F6xx-заглушками.

В сорцах и для хранения/передачи жёстко локаю всё на UTF-8, если язык позволяет. Увы, не всегда такое возможно, так как педерастия древней жабы с прохачиванием UTF-16 из UCS-2 докатилась много до чего, включая ахтунг-версию питона Python 3. Но и здесь хаки компенсируются другими хаками.

А вообще, приличной строковой библиотеки (чтобы и соответствие свежему Unicode CLDR, и разные *-insensitive регэкспы на его базе) я пока ни в одном языке не наблюдал.

vgrichina January 2nd, 2015
> языков программирования, претендующих на звание "поддерживается работа со строками" - нет.

В Swift вроде все норм из коробки – http://oleb.net/blog/2014/07/swift-strings/

А вот языков с поддержкой дат пригодной для бизнеса я таки не видел (чтоб год / неделя / день начинались в произвольную дату / день недели / время соответственно).

wizzard0 January 2nd, 2015
> grapheme clusters
О, это хорошо

> The String type does not (yet?) come with a method to specify the language to use for collation.
Ну, не всё :)

Но задел хороший.

vgrichina January 2nd, 2015
> The String type does not (yet?) come with a method to specify the language to use for collation.

Это еще в NSString в Cocoa было решено, так что думаю максимум временная дыра решаемая фоллбеком в старое API.

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/index.html#//apple_ref/occ/instm/NSString/compare:options:range:locale:

+ есть еще плюшки в местах не связанных непосредственно со строками, вот например http://nshipster.com/uilocalizedindexedcollation/

dmih January 2nd, 2015
Моя вера в Unicode пошатнулась буквально только вот год назад, когда внезапно обнаружилось, что Мак и Windows используют разные способы нормализации, что заметно буквально вот начиная с европейских закорючек, которые вообще довольно распространены.
Причем и ту, и другую систему от альтернтативного способа нормализации немного плющит.

Ну т.е. это я к тому, что никаких смайликов вроде бы не надо, ад ближе, чем кажется.

Edited at 2015-01-02 05:01 pm (UTC)

wizzard0 January 2nd, 2015
Ага, про это я тоже знаю :)

altmind January 2nd, 2015
потому что смайликам(которые всего скорее в private section) и emoji не место в юникоде. одни - не имеют стандартного отобраджения, вторые - требуют чтобы рисуемый текст диктовал цвета рисуемого глифа. использовали бы юникод как определено в стандарте (желательно 1.0) и не гробили бы мозг ни себе, ни интеграторам.

wizzard0 January 2nd, 2015
> использовали бы юникод как определено в стандарте (желательно 1.0)
бгы. 1.0 неюзабелен почти совсем вообще. адекватным он стал кажется с 3.0 или 4.0

> как определено в стандарте (желательно 1.0)
и, ээээ, тут какие-то взаимоисключающие параграфы. тут же не "у эпла появились смайлики, их втащили в юникод", а "в стандарт ввели смайлики, некоторые интеграторы начали их использовать, другим тоже пришлось".

Edited at 2015-01-02 05:34 pm (UTC)

altmind January 2nd, 2015
с emoji проблема не в том, что это смайлики, а в том, что они цветные. emoji в стандарте нет, если их кто-то кроме apple испольщует - это сплошь adhoc

wizzard0 January 2nd, 2015
> emoji в стандарте нет
Oh, really?

> цветные
Emoji characters can have two kinds of presentation:

an emoji presentation, with colorful and perhaps whimsical shapes, even animated
a text presentation, such as black & white

altmind January 2nd, 2015
от того, что хрень в стандарте описать, она не становится меньше хренью. это скорее личная неприязнь.

wizzard0 January 2nd, 2015
Тут я всё понимаю.

Это всё от того, что стандарта на ричтекст нету (ни на кодировку, ни на редактирование, доступное простым смертным юзерам).

Ну и далее "а давайте просто символов подсыпем", и понеслась.

nponeccop January 2nd, 2015
> стандарта на ричтекст нету

Ну ты губу раскатал.

wizzard0 January 2nd, 2015
Ну эм. 2014 год, а диаграммы в RFC до сих пор псевдографикой, провести в тексте стрелочку от одного слова к другому - вообще целая проблема.

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

golosptic January 6th, 2015
>с emoji проблема не в том, что это смайлики, а в том, что они цветные

Вот ничё-ничё, рано или поздно в Unicode запихнуть буквы от Ilkash, которые цветные by design, вот тогда отдельные интеграторы возрадуются :)

_winnie January 2nd, 2015
Ещё одна беда - строки в JavaScript внутри UCS-2. Прислал с сервера одну букву-код в честном unicode escaped JSON или JSON-байтовый UTF-8, а клиентский код считает что это две буквы.

Edited at 2015-01-02 06:19 pm (UTC)

grundik January 2nd, 2015
В нашей индустрии вообще нет ничего работающего.

wizzard0 January 2nd, 2015
:)

max630 January 2nd, 2015
Ну и отлично, а то задолбали со своим уникодом. в 95% случаях программе вообще пофиг - текст там или видеоролик.

Есличо, я давно был уверен что с текстом в общем случае нельзя работать как с массивом, надо его потоково процессить: совпадает ли строчка с образцом (другой строкой). Ну и так далее. Тогда и охов по поводу того что utf видите ли индексить по [] нельзя не будет.

wizzard0 January 2nd, 2015
> совпадает ли строчка с образцом
Этого недостаточно: http://en.wikipedia.org/wiki/Unicode_equivalence#Errors_due_to_normalization_differences

max630 January 2nd, 2015
Ну вот всю эту ерунду тоже учитывать, прямо в момент сравнения. Обратимость не нужна кстати. Тут фикус как раз в том чтобы не дробить на символы сначала.

PS. Вообще collation же может быть разный у строк. Тогда сравнение, по идее, невозможно. Можно считать расхождение платформ частным случаем.

Edited at 2015-01-02 07:28 pm (UTC)

slobin January 2nd, 2015
Где-то я эту идею читал. Где-то на сайте проекта то ли shen, то ли его предшественника Qi. Это такие странные лиспы, и автор у них тоже странный, но в данном конкретном случае продвигалась идея, что общего для всех языков и областей применения содержательного понятия символа НЕТ. Просто нет, и всё, в природе. Есть понятие "осмысленный на данном уровне рассмотрения кусок в начале текста", и в этом смысле, скажем, "слово" и "буква" различаются не принципиально. Просто вот в этом языке есть слова и есть буквы, а где-то ещё есть что-то другое. И, кстати, автор (в ответах на комментарии к статье) пояснял, что нет, он не против юникода, юникод -- хороший стандарт, который многие проблемы не решает, но вот эту проблему он не решает и не должен. Потом поищу ссылку на статью, если не забуду.

... И на "е" бывает, и на "ё" бывает ...


max630 January 3rd, 2015
да вон, в php ord() проверяет "первый символ в строке". Может, я оттуда это и придумал.

_winnie January 3rd, 2015
Всё-таки деление на уровне "простые сервер-скрипты работают приемлемо для web/mobile-пользователя в большинстве случаев для diff/cut/переносов" - это очень важный уровень.

Оторванная диакритика - неприятно, но понятно. Такой разрыв описывается в той модели которую видит пользователь, "ок, е отдельно, ¨ отдельно, вместе получается ё".

А вот такой

перен�
�с

- неприемлем.



Edited at 2015-01-03 09:14 am (UTC)

max630 January 3rd, 2015
Неприемлемо или нет - это субъективно. Извиняюсь за психологию, если человек программист и держит в голове абстракцию "текст как массив символов с произвольным доступом", то ему вторая ошибка непростительна, а первая - "ууу, это сложно". А для пользователя и то и другое - косметический недостаток: прочитать можно но выглядит неаккуратно. На половине европейских сайтов вообще utf-8 с latin1 перепутано, и ничего, живут как-то.

_winnie January 3rd, 2015
Я имел ввиду, что две точки на ё может домыслить и ребёнок, а вот понять что было на месте � c � - нужно доставать hex-редактор и интерпретатор

amarao_san January 2nd, 2015
Ну, соответственно, человечеству ещё осталось что делать. Например, написать язык программирования, который будет поддерживать строковые типы. Полностью.

ufm January 2nd, 2015
Ну в голанг, вроде бы, достаточно внятно всё с юникодом. UTF8 везде, где строки. Впрочем я сильно "странного" не хотел, может и можно нарваться.

kastaneda January 3rd, 2015
Будь проще. Весь существующий софт, все современные стандарты — это пена и мусор. Через сто лет не выживет ни один из современных стандартов. По моим (достаточно оптимистичным) прогнозам Unicode должен быть радикально реформирован в течении ближайших 10 лет. Изначально Unicode задумывался как «почти ASCII, только с поддержкой всех этих кракозябр», но от версии к версии пациенту становилось всё хуже и хуже. Это как Unixtime, который задумывался простым, чётким и логичным, а получился жуткий монстр с високосными секундами. Это как классическое inode:uid:gid:drwxrwxrwx, к которому прикрутили хитросделанные ACLы и всяческие ништяки из SELinux. Даже концепция файла, как последовательности байт, и та просрана — выделение sparce блоков там, или всякие file threads.

Наша эпоха создаст множество работы археопрограммистам будущего.

worm_ii January 4th, 2015
> Unicode должен быть радикально реформирован в течении ближайших 10 лет.
Нет в мире такой силы, которая смогла бы продвинуть несовместимый с Юникодом стандарт (см., например, прогрессивную архитектуру Itanium). А совместимый может быть только хуже в плане поднимаемых проблем.

golosptic January 6th, 2015
Через сто лет не выживет ни один из современных стандартов.
На фортране продолжат программировать. Я гарантирую это (с)

В индустрии нужен фашист с палкой

anonim_legion January 3rd, 2015
Иногда мне думается, что обитатели LOR, со своим принципом "это не нужно", в чем-то правы.

  • 1
?

Log in

No account? Create an account