View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003012 | Plugins | LuaMacro / Macro Browser | public | 2015-06-23 07:53 | 2020-04-06 09:28 |
Reporter | JohnDoe | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0003012: Selene Unicode: обработка паттерна "%p" отличается от штатной обработки lua | ||||
Description | Отсутствие совпадения: $ + < = > ^ ` | ~ Ложное совпадение: б л н ╖ ╗ ┐ | ||||
Steps To Reproduce | for i=0,255 do local c = string.char(i) local f,l = c:match"%p",string.match(c,"%p") if f~=l then print(f,l) end end | ||||
Additional Information | http://forum.farmanager.com/viewtopic.php?p=130793#p130793 | ||||
Tags | No tags attached. | ||||
|
Есть альтернативная библиотека [1], были мысли заменить (в LuaFAR) Selene Unicode на неё. [1] https://github.com/starwing/luautf8 |
|
http://lua-users.org/wiki/LuaUnicode Тут пишут: "it pass lua test suite's string and pattern matching test" Т.е. проблему тикета должно решить. И библиотека поддерживается автором, в отличии от slnunicode. (хотя вот тут что-то ещё происходит https://github.com/LuaDist/slnunicode) Но если сравнивать функциональность, то могут быть сюрпризы, например я не уверен в этом утверждении: >Some routines in string module needn't support Unicode: string.format Кроме того вижу в slnunicode кроме utf-8 ещё и таблицы ascii,grapheme,latin1. Для чего они? |
|
С заменой/незаменой библиотеки есть несколько тонкостей, не будем их сейчас обсуждать. В любом случае должно быть сделано очень аккуратно и с тестированием. То, что я настойчиво повторял "мантис", вызвано тем, что сейчас и в ближайшее время вряд ли смогу этим заниматься из-за нагрузки по работе. > Кроме того вижу в slnunicode кроме utf-8 ещё и таблицы ascii,grapheme,latin1. > Для чего они? Видимо нужны в ситуациях, отличных от нашей. (Простого ответа у меня нет). |
|
@JohnDoe Пожалуйста проверьте актуальность данного тикета. |
|
В актуальной версии различия в обработке появляются только для символов с кодом > 127. 161 162 163 164 165 167 168 171 172 175 177 180 182 183 184 187 191 215 247 |
|
Все эти символы, похоже, не являются валидным UTF-8: |
|
Ни один отдельный символ 128..255 не является валидным utf-8
|
|
> Ни один отдельный символ 128..255 не является валидным utf-8 Это так, но в этом диапазоне есть байты, с которых может начинаться символ UTF-8, и байты, с которых не может. Но моя иысль была не об этом, а о том, что, поскольку данные байты не являются валидными символами UTF-8, то библиотека ведёт себя правильно, не признавая их за символы пунктуации. |
|
В том и дело, что перечисленные символы признаются библиотекой за пунктуацию |
|
Не проверял, поверю вам на слово. Можете зарепортить автору, т.к. у меня пока нет планов углубляться в эту библиотеку. Хотя один фикс в ней я уже сделал. |
|
https://github.com/starwing/luautf8/issues/27 |
|
1. Хорошо, что зарепортили (хотя мой пулл-реквест автор игнорирует уже 3 недели). 2. Вы там пишете "For example, utf8 string cannot start from chars in range 128..255". Это мне кажется либо неправильным, либо неудачно сформулированным утверждением. P.S. Тут ещё проблема с английским у автора - ещё больше, чем у нас с вами. |
|
Возможно, что надо рассматривать ситуацию так: паттерн обязан правильно обрабатывать валидные для UTF-8 последовательности байт, а в случае невалидных последовательностей поведение не определено. |
|
> Это мне кажется либо неправильным, либо неудачно сформулированным утверждением. Исправил на "For example, utf8 string cannot consist of single char in range 128..255." Возможно вы сможете предложить более удачную формулировку. Впрочем, я вижу что уже есть аналогичный репорт 2017 года: https://github.com/starwing/luautf8/issues/13 |
|
> а в случае невалидных последовательностей поведение не определено. Смотрим документацию к нашей библиотеке: https://github.com/starwing/luautf8#usage utf8.match отдельно не документирована, есть только отсылка к тому что функция аналогична той что в strings. Но можно обратить внимание например на следующее: Открываем мануал: https://www.lua.org/manual/5.3/manual.html#6.5 Описание лишь некоторых функций содержит примечание "This function assumes that s is a valid UTF-8 string.", для прочих же явно указано что происходит в случае невалидных данных. Перечисленные функции я проверял, и их поведение не соответствует мануалу. Тоже и с utf8.len. Очевидно что библиотека в принципе не различает некорректные данные. Если после исправления этого недостатка "неопределённость" в частных случаях сохранится, то попрошу автора явно отразить это в документации. |
|
Формально вы правы, но всё не так однозначно. В библиотеке string в Lua 5.3 полностью отсутствуют операции со свойствами юникодных символов (и об этом сказано в мануале). Другими словами - нет операции - нет проблемы. А то, что автор библиотеки luautf8 сослался на мануал Lua 5.3, так это только в смысле, что не хотел дублировать описание некоторых функций. |
|
В каком смысле "только"? Встроенные возможности работы с utf8 в lua 5.3 действительно весьма малочисленны, но на некорректные данные реагируют логичным и документированным образом. Я прекрасно понимаю что задача lua-utf8 сложнее, но не вижу причин почему бы соответствующим функциям из этой библиотеки стоило бы вести себя образом отличным от lua 5.3. |
|
> Я прекрасно понимаю что задача lua-utf8 сложнее, но не вижу причин почему бы соответствующим функциям из этой библиотеки стоило бы вести себя образом отличным от lua 5.3. Автор сделал, что мог сделать. Вы можете лучше - сделайте или помогите автору сделать. Работа с юникодом весьма и весьма нетривиальна. |
|
Исправлено автором: https://github.com/starwing/luautf8/commit/b382abe35809f24df25faf52d91e6f95bfc82816 (не проверял) |
|
Интересно, что автор выпустил новый релиз (предыдущий, которым мы пользуемся, был в мае 2015), но этот новый релиз выпущен 18 часов назад, то есть до исправления, о котором вы пишете. |
|
Судя по комментарию к релизу автор сначала не планировал заморачиваться. Но потом видимо зацепился. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-06-23 07:53 | JohnDoe | New Issue | |
2015-06-23 08:17 | shmuel | Note Added: 0013686 | |
2015-06-23 08:43 | JohnDoe | Note Added: 0013687 | |
2015-06-23 08:53 | shmuel | Note Added: 0013688 | |
2015-06-23 08:54 | shmuel | Note Edited: 0013688 | |
2019-12-31 12:59 | shmuel | Note Added: 0016677 | |
2020-01-03 10:33 | JohnDoe | Note Added: 0016686 | |
2020-01-03 10:56 | shmuel | Note Added: 0016689 | |
2020-01-03 11:27 | JohnDoe | Note Added: 0016690 | |
2020-01-03 11:27 | JohnDoe | Note Edited: 0016690 | |
2020-01-03 13:05 | shmuel | Note Added: 0016691 | |
2020-01-03 14:02 | JohnDoe | Note Added: 0016692 | |
2020-01-03 14:10 | shmuel | Note Added: 0016693 | |
2020-01-04 10:13 | JohnDoe | Note Added: 0016694 | |
2020-01-04 10:24 | shmuel | Note Added: 0016695 | |
2020-01-04 10:28 | shmuel | Note Edited: 0016695 | |
2020-01-04 10:36 | shmuel | Note Added: 0016696 | |
2020-01-04 10:48 | JohnDoe | Note Added: 0016697 | |
2020-01-04 13:22 | JohnDoe | Note Added: 0016698 | |
2020-01-04 13:35 | shmuel | Note Added: 0016699 | |
2020-01-04 15:18 | JohnDoe | Note Added: 0016700 | |
2020-01-04 15:28 | shmuel | Note Added: 0016701 | |
2020-04-06 08:39 | JohnDoe | Note Added: 0016777 | |
2020-04-06 08:56 | shmuel | Note Added: 0016778 | |
2020-04-06 09:28 | JohnDoe | Note Added: 0016779 |