Comments | elisitsky: Приключения Unicode в Erlang.

elisitsky

Приключения Unicode в Erlang.

Apr 16, 2010 13:41

Первое, на что я натолкнулся, начав изучать Эрланг - это проблемы со строками, отягощенные всей юникодностью нашего алфавита. Пожалуй, будь моим родным языком английский (или латынь или любой другой с алфавитом, полностью помещающимся в первые 128 символов utf-8), часть проблем бы я просто не заметил, и даже считал, что так оно и должно быть и я ( Read more... )

юникод, эрланг, erlang, unicode, грабли, utf-8

Comments 10

gliv April 16 2010, 14:04:36 UTC

Было б неплохо, если бы еще было написано про xmerl_ucs

elisitsky April 16 2010, 14:15:53 UTC

Очень давно не встречал xmerl_ucs в бою. В основном статьи про него относятся к 2007 году. Тогда было несколько вариантов обработки юникода.
Сейчас по идее ту же функциональность по кодированию-раскодированю сейчас обеспечивают стандартные модули.
Если там есть что-то интересное - дайте знать.

gliv April 16 2010, 15:14:46 UTC

Я тоже хотел бы узнать, кто что использует :)
я нашел полезность только в функциях is_*

elisitsky April 16 2010, 15:22:02 UTC

Мне кажется после принятия EEP-0010 разрабатывать какие-то специфические решения не только ну нужно, но и даже вредно. Да мне самому там не все нравится, но если это стандарт, то больше пользы будет от следования ему, как минимум от совместимости. А то 6 несовместимых JSON-парсеров - курам на смех.

ext_9078 April 16 2010, 19:32:23 UTC

Было бы интересно встретить человека, которому родным языком является латынь. %)

elisitsky April 16 2010, 20:22:01 UTC

Я это для хохмы написал, вы - первый, кто обратил внимание :)

lionet April 17 2010, 02:21:53 UTC

Не надо приводить UTF-8 к внутреннему представлению в code points. Оставляйте всё в UTF-8, пускай строки соответствуют "раздербаненному" бинарнику с UTF-8 внутри.

Список с character codes, вместо списка с utf-8 sequences - это бред, который не решает поставленной задачи.

elisitsky April 17 2010, 07:47:46 UTC

Спасибо, Лев!

Мне тоже кажется, что форма в виде бинарного объекта более естественна для строки. Но в этом случае мы лишаемся некоторых возможностей: например, проверить длину в символах (например, у меня стоит ограничение, что логин должен быть не меньше 3 символов), вхождение различных подстрок, то, что логин скажем не содержит запрещенных символов. Со списками это все просто, но с бинарями как быть?
И не возникнет ли у нас новый вид ошибок поиска - когда заматчатся половины букв? Скажем второй байт первого символа и первый байт второго?

А как вы вводите бинари с русскими символами в текст программы?
Конструкция Msg = "абв", выполеннная в консоли, дает мне список [1072,1073,1074]. Разумный ожидаемый результат. при печате на экране тоже то, что нужно.
Если я пишу в консоли Msg2 = <<"абв"/utf8>>, то получаю ошибку ( ... )

lionet April 17 2010, 08:30:18 UTC

Мне тоже кажется, что форма в виде бинарного объекта более естественна для строки.

Нет, я говорил про обычные строки, которые списком. Именно в них следует держать текст при процессинге.

Но в этом случае мы лишаемся некоторых возможностей

Ничего мы такого не лишаемся, чего получаем, храня code points в списках. Подробнее здесь: http://lionet.livejournal.com/56779.html

И не возникнет ли у нас новый вид ошибок поиска - когда заматчатся половины букв? Скажем второй байт первого символа и первый байт второго?

Хранение в code points этой проблемы не решает. Подробнее здесь: http://lionet.livejournal.com/56779.html в частности, см. про combining characters.

А как вы вводите бинари с русскими символами в текст программы?

Честно говоря, не вводим. Код пишем на эрланге, комментарии на английском, а локализация - она вне программы, в отдельных сущностях (база или файлы).

Если я пишу в консоли Msg2 = <<"абв"/utf8>>, то получаю ( ... )

elisitsky April 17 2010, 08:42:51 UTC

> Нет, я говорил про обычные строки, которые списком. Именно в них следует держать текст при процессинге.

Значит я вас неверно понял. Меня сильно смущает оверхед на хранение и обработку - что нам постоянно надо "бегать" по указателям для любых операций.

> Ничего мы такого не лишаемся, чего получаем, храня code points в списках.
Если список, то да - нам должны быть доступны все списковые операции и модуль string тоже.

> Если я пишу в консоли Msg2 = <<"абв"/utf8>>, то получаю ошибку
> Это меня самого раздражает.
Можно ли как-то с этим бороться? Чтобы поведение было одинаковым? Иначе очень не удобно - нельзя отладить программу в консоли, быстро проверить какую-нибудь мысль и т.п.

> Почему же это бред? Это UTF-8, именно так и должно быть.
Да, это utf-8. Но запись не соответствует EEP-10. По идее должны быть либо code point в списке, либо в виде байт бинарного объекта.
А такая запись - гибрид, который неясно как обрабатывать. Как например, ему сделать uppercase?