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
Это далеко не всё. Есть еще комбинирующие(ся?) символы, лигатуры и нормализация.

gds 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.
Ну, не всё :)

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

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)

_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

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). А совместимый может быть только хуже в плане поднимаемых проблем.

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

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

  • 1
?

Log in

No account? Create an account