View Issue Details

IDProjectCategoryView StatusLast Update
0003012PluginsLuaMacro / Macro Browserpublic2020-04-06 10:28
ReporterJohnDoe Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version3.0 
Summary0003012: Selene Unicode: обработка паттерна "%p" отличается от штатной обработки lua
DescriptionОтсутствие совпадения: $ + < = > ^ ` | ~
Ложное совпадение: б л н ╖ ╗ ┐
Steps To Reproducefor 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 Informationhttp://forum.farmanager.com/viewtopic.php?p=130793#p130793
TagsNo tags attached.

Activities

shmuel

2015-06-23 09:17

developer   bugnote:0013686

Есть альтернативная библиотека [1], были мысли заменить (в LuaFAR) Selene Unicode на неё.

[1] https://github.com/starwing/luautf8

JohnDoe

2015-06-23 09:43

updater   bugnote:0013687

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.
Для чего они?

shmuel

2015-06-23 09:53

developer   bugnote:0013688

Last edited: 2015-06-23 09:54

View 2 revisions

С заменой/незаменой библиотеки есть несколько тонкостей, не будем их сейчас обсуждать. В любом случае должно быть сделано очень аккуратно и с тестированием.

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

> Кроме того вижу в slnunicode кроме utf-8 ещё и таблицы ascii,grapheme,latin1.
> Для чего они?

Видимо нужны в ситуациях, отличных от нашей. (Простого ответа у меня нет).

shmuel

2019-12-31 12:59

developer   bugnote:0016677

@JohnDoe
Пожалуйста проверьте актуальность данного тикета.

JohnDoe

2020-01-03 10:33

updater   bugnote:0016686

В актуальной версии различия в обработке появляются только для символов с кодом > 127.

161
162
163
164
165
167
168
171
172
175
177
180
182
183
184
187
191
215
247

shmuel

2020-01-03 10:56

developer   bugnote:0016689

Все эти символы, похоже, не являются валидным UTF-8:
local t1 = {161,162,163,164,165,167,168,171,172,175,177,180,182,183,184,187,191,215,247}
local t2={}
for i,v in ipairs(t1) do t2[i]=v..": "..tostring(string.char(v):utf8valid()) end
far.Show(unpack(t2))

JohnDoe

2020-01-03 11:27

updater   bugnote:0016690

Last edited: 2020-01-03 11:27

View 2 revisions

Ни один отдельный символ 128..255 не является валидным utf-8
for i=128,255 do
  if string.char(i):utf8valid() then
    print(i)
  end
end

shmuel

2020-01-03 13:05

developer   bugnote:0016691

> Ни один отдельный символ 128..255 не является валидным utf-8

Это так, но в этом диапазоне есть байты, с которых может начинаться символ UTF-8, и байты, с которых не может. Но моя иысль была не об этом, а о том, что, поскольку данные байты не являются валидными символами UTF-8, то библиотека ведёт себя правильно, не признавая их за символы пунктуации.

JohnDoe

2020-01-03 14:02

updater   bugnote:0016692

В том и дело, что перечисленные символы признаются библиотекой за пунктуацию

shmuel

2020-01-03 14:10

developer   bugnote:0016693

Не проверял, поверю вам на слово.
Можете зарепортить автору, т.к. у меня пока нет планов углубляться в эту библиотеку. Хотя один фикс в ней я уже сделал.

JohnDoe

2020-01-04 10:13

updater   bugnote:0016694

https://github.com/starwing/luautf8/issues/27

shmuel

2020-01-04 10:24

developer   bugnote:0016695

Last edited: 2020-01-04 10:28

View 2 revisions

1. Хорошо, что зарепортили (хотя мой пулл-реквест автор игнорирует уже 3 недели).
2. Вы там пишете "For example, utf8 string cannot start from chars in range 128..255". Это мне кажется либо неправильным, либо неудачно сформулированным утверждением.

P.S. Тут ещё проблема с английским у автора - ещё больше, чем у нас с вами.

shmuel

2020-01-04 10:36

developer   bugnote:0016696

Возможно, что надо рассматривать ситуацию так: паттерн обязан правильно обрабатывать валидные для UTF-8 последовательности байт, а в случае невалидных последовательностей поведение не определено.

JohnDoe

2020-01-04 10:48

updater   bugnote:0016697

> Это мне кажется либо неправильным, либо неудачно сформулированным утверждением.

Исправил на "For example, utf8 string cannot consist of single char in range 128..255."
Возможно вы сможете предложить более удачную формулировку.
Впрочем, я вижу что уже есть аналогичный репорт 2017 года: https://github.com/starwing/luautf8/issues/13

JohnDoe

2020-01-04 13:22

updater   bugnote:0016698

> а в случае невалидных последовательностей поведение не определено.

Смотрим документацию к нашей библиотеке: https://github.com/starwing/luautf8#usage
utf8.match отдельно не документирована, есть только отсылка к тому что функция аналогична той что в strings.

Но можно обратить внимание например на следующее:

utf8.offset
utf8.codepoint
utf8.codes
See Lua5.3's manual to get usage.

luautf8
Открываем мануал: https://www.lua.org/manual/5.3/manual.html#6.5
Описание лишь некоторых функций содержит примечание "This function assumes that s is a valid UTF-8 string.", для прочих же явно указано что происходит в случае невалидных данных.
Перечисленные функции я проверял, и их поведение не соответствует мануалу.
Тоже и с utf8.len.

Очевидно что библиотека в принципе не различает некорректные данные. Если после исправления этого недостатка "неопределённость" в частных случаях сохранится, то попрошу автора явно отразить это в документации.

shmuel

2020-01-04 13:35

developer   bugnote:0016699

Формально вы правы, но всё не так однозначно. В библиотеке string в Lua 5.3 полностью отсутствуют операции со свойствами юникодных символов (и об этом сказано в мануале). Другими словами - нет операции - нет проблемы. А то, что автор библиотеки luautf8 сослался на мануал Lua 5.3, так это только в смысле, что не хотел дублировать описание некоторых функций.

JohnDoe

2020-01-04 15:18

updater   bugnote:0016700

А то, что автор библиотеки luautf8 сослался на мануал Lua 5.3, так это только в смысле, что не хотел дублировать описание некоторых функций.

shmuel
В каком смысле "только"?
Встроенные возможности работы с utf8 в lua 5.3 действительно весьма малочисленны, но на некорректные данные реагируют логичным и документированным образом.

Я прекрасно понимаю что задача lua-utf8 сложнее, но не вижу причин почему бы соответствующим функциям из этой библиотеки стоило бы вести себя образом отличным от lua 5.3.

shmuel

2020-01-04 15:28

developer   bugnote:0016701

> Я прекрасно понимаю что задача lua-utf8 сложнее, но не вижу причин почему бы соответствующим функциям из этой библиотеки стоило бы вести себя образом отличным от lua 5.3.

Автор сделал, что мог сделать. Вы можете лучше - сделайте или помогите автору сделать.
Работа с юникодом весьма и весьма нетривиальна.

JohnDoe

2020-04-06 09:39

updater   bugnote:0016777

Исправлено автором: https://github.com/starwing/luautf8/commit/b382abe35809f24df25faf52d91e6f95bfc82816
(не проверял)

shmuel

2020-04-06 09:56

developer   bugnote:0016778

Интересно, что автор выпустил новый релиз (предыдущий, которым мы пользуемся, был в мае 2015), но этот новый релиз выпущен 18 часов назад, то есть до исправления, о котором вы пишете.

JohnDoe

2020-04-06 10:28

updater   bugnote:0016779

Судя по комментарию к релизу автор сначала не планировал заморачиваться.
Но потом видимо зацепился.

Issue History

Date Modified Username Field Change
2015-06-23 08:53 JohnDoe New Issue
2015-06-23 09:17 shmuel Note Added: 0013686
2015-06-23 09:43 JohnDoe Note Added: 0013687
2015-06-23 09:53 shmuel Note Added: 0013688
2015-06-23 09:54 shmuel Note Edited: 0013688 View Revisions
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 View Revisions
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 View Revisions
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 09:39 JohnDoe Note Added: 0016777
2020-04-06 09:56 shmuel Note Added: 0016778
2020-04-06 10:28 JohnDoe Note Added: 0016779