Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

22 Январь 2022, 20:10 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Здесь можно поблагодарить участников форума Улыбка
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1 2 »   Вниз
  Печать  
Автор Тема: URLTransformer мне чем-то не подошел  (Прочитано 502 раз)
0 Пользователей и 1 Гость смотрят эту тему.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Стартовое сообщение: 13 Январь 2022, 19:35 »

Стандартный сервис URLTransformer мне чем-то не подошел - надо поискать чем.

Поищите. У нас там такое наворочено в разборе URL, и каждый день приносит новые радости. Это очень сильное колдунство. Лучше им пользоваться, чем писать своё, и если есть баги - не забывайте их сообщать Подмигивающий
Записан

С уважением,
Михаил Каганский
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #1: 13 Январь 2022, 19:53 »

Лучше им пользоваться, чем писать своё
Полностью согласен, но я взял регулярное выражение непосредственно из стандарта RFC3986 и далее использовал "базовый" сервис TextSearch2.

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

Владимир.
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #2: 13 Январь 2022, 20:37 »

Кажется, нашел компромат.  Улыбка

Код:
Sub UrlTest
  Dim oUrlTrans, url As New com.sun.star.util.URL, retval As Boolean, arr
  
  oUrlTrans=CreateUnoService("com.sun.star.util.URLTransformer")
  url.Complete="en.wikipedia.org:443/wiki/URL?key1=a&key2=b#URL_structure"
  retval=oUrlTrans.parseStrict(URL)
  Msgbox "retval::" & retval & " path::" & url.Path & " query::" & url.Arguments
  
  arr=UrlParse(url.complete)
  Msgbox "retval::" & arr(0) & " path::" & arr(3) & " query::" & arr(4)
End Sub


Функция UrlParse приведена здесь.
Макрос выводит:
Код:
retval::True path::443/wiki/URL?key1=a&key2=b#URL_structure query::
retval::0 path::443/wiki/URL query::key1=a&key2=b

Сервис не отделяет параметров (аргументов) от пути, регулярное выражение из RFC3986 отделяет.

Прошу прощения у автора темы за Offtop (хотя мы обсуждаем URL).
« Последнее редактирование: 13 Январь 2022, 21:12 от sokol92 » Записан

Владимир.
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #3: 13 Январь 2022, 21:04 »

Михаил, спасибо за перенос темы (я это не умею делать).
Записан

Владимир.
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #4: 13 Январь 2022, 21:07 »

Такой URL сервис показывает как ошибочный, а стандарту он нравится:

Код:
en.wikipedia.org/wiki/URL?key1=a&key2=b#URL_structure

Firefox тоже не против.
Записан

Владимир.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #5: 13 Январь 2022, 21:44 »

Код:
  url.Complete="en.wikipedia.org:443/wiki/URL?key1=a&key2=b#URL_structure"
  retval=oUrlTrans.parseStrict(URL)

Код:
en.wikipedia.org/wiki/URL?key1=a&key2=b#URL_structure

parseStrict ожидает, что в неё передаётся *полный* URL. То есть у него есть схема и всё остальное. В первом случае она считает схемой всё до двоеточия; во втором - двоеточия вообще нет.

Есть parseSmart, но я его не пробовал.
Записан

С уважением,
Михаил Каганский
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #6: 13 Январь 2022, 22:25 »

Код:
Sub UrlTest
  ...
  url.Complete="en.wikipedia.org:443/wiki/URL?key1=a&key2=b#URL_structure"
  ...
  arr=UrlParse(url.complete)
  Msgbox "retval::" & arr(0) & " path::" & arr(3) & " query::" & arr(4)
End Sub

Макрос выводит:
Код:
retval::0 path::443/wiki/URL query::key1=a&key2=b

Можно заметить, что Ваш код, как и parseStrict, неправильно отделяет путь: 443 - не часть пути. А если вывод сделать таким:

Код:
Msgbox "scheme::" & arr(1) & " host::" & arr(2) & " path::" & arr(3) & " query::" & arr(4) & " fragment::" & arr(5)

то вывод будет

Код:
scheme::en.wikipedia.org host:: path::443/wiki/URL query::key1=a&key2=b fragment::URL_structure

и станет очевидно, что регулярка точно так же обманута (протокол и хост поменялись местами). Тут ситуация очень похожа на "нельзя парсить HTML с помощью регулярок". Эта тема невероятно сложная, и даже несмотря на то, что это решение приведено в стандарте, оно кривое.


Сервис не отделяет параметров (аргументов) от пути, регулярное выражение из RFC3986 отделяет.

Как можно увидеть в исходном коде, parseStrict при обнаружении неизвестного протокола не пытается быть умным, а делит на части очень примитивно - "Minimal support for unknown protocols".
« Последнее редактирование: 13 Январь 2022, 22:28 от mikekaganski » Записан

С уважением,
Михаил Каганский
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #7: 14 Январь 2022, 10:02 »

Есть parseSmart, но я его не пробовал.

Попробовал.
Записан

С уважением,
Михаил Каганский
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #8: 14 Январь 2022, 10:07 »

я взял регулярное выражение непосредственно из стандарта RFC3986

Насчёт стандарта (и о причинах таких проблем) - вот цитата оттуда:

Цитата: RFC 3986
3.  Syntax Components

   The generic URI syntax consists of a hierarchical sequence of
   components referred to as the scheme, authority, path, query, and
   fragment.

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   ...

   The scheme and path components are required, though the path may be
   empty (no characters).

Поэтому никакой URL не может считаться правильным без схемы, хотя мы привыкли вводить просто www.foo.bar. Именно для таких неправильных адресов и придуманы хитрости типа parseSmart.
Записан

С уважением,
Михаил Каганский
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #9: 14 Январь 2022, 13:05 »

Михаил, спасибо за (продуктивное) исследование!
Кстати, у нас есть ведь под капотом этоПодмигивающий
Записан

Владимир.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #10: 14 Январь 2022, 13:18 »

Кстати, у нас есть ведь под капотом этоПодмигивающий

Улыбка не вполне понял, что Вы имеете ввиду - что мы можем это использовать при написании макросов на Питоне, или что-то ещё (скажем, что всякий раз, когда мы парсим URL в коде ЛО, мы должны обращаться к Питону)?
Записан

С уважением,
Михаил Каганский
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #11: 14 Январь 2022, 13:51 »

когда мы парсим URL в коде ЛО, мы должны обращаться к Питону
Тут есть некий дуализм ("не мы, а вы").
Классы UNO это и ТЗ и инструмент для разработчиков (к которым относитесь Вы), и инструмент для прикладных программистов (к которым относимся мы).
Можно, к примеру, создать какой-нибудь сервис URLParse, который будет реализовывать достаточно развитые интерфейсы Питона. Прикладники будут в восторге, разработчикам LO он тоже может пригодиться в каких-то ситуациях. Или в поставляемых версиях LO есть ограничения на использование Python в коде LO?
Записан

Владимир.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #12: 14 Январь 2022, 14:22 »

Ну во-первых, у питона недостаточно развиты интерфейсы парсинга URL Улыбка - посмотрите список поддерживаемых схем. Мы не поддерживаем многое из того, что там перечислено, зато у нас есть свои схемы - macro:, uno: и т.п., а также схемы общего назначения типа Office URI.

Во-вторых, мы парсим URL при каждом чихе. Хотя бы потому, что все команды UNO проходят через URL. И дополнительные накладные расходы (на передачу в Питон, ожидание его интерпретации со всеми чудесами GIL (у нас и так хватает своих чудес типа SolarMutex), получение оттуда и преобразование в наши строки ...) недопустимы.

В-третьих (вытекает из во-первых и во-вторых), поскольку мы не сможем отказаться от своих парсеров, использование классов Python будет очередной реализацией однотипного функционала (а у нас и так две реализации, которые мы объединить боимся, т.к. они несколько отличаются и обе - части API).

Ну и наконец - в такой ситуации нет смысла превращать API ЛО просто в средство альтернативного доступа к библиотекам какого-то ЯП. Если программисту понадобится воспользоваться библиотеками питона - пожалуйста, напрямую с питоном и общайтесь. API ЛО тут ни при чём Улыбка
« Последнее редактирование: 14 Январь 2022, 14:25 от mikekaganski » Записан

С уважением,
Михаил Каганский
sokol92
Опытный пользователь
***
Online Online

Пол: Мужской
Сообщений: 704


WWW
« Ответ #13: 14 Январь 2022, 14:40 »

Понятно, спасибо!
Пользуясь случаем, нагло задам еще родственный вопрос.  Улыбка

Какие в LO предлагаются / планируются средства для обработки HTTP(S) - запросов?
Я с этим столкнулся в первые недели знакомства с LO, когда нужно было получить / передать данные через WEB API. Для POST-запросов нашлась лишь ссылка на японском языке (как я сейчас понимаю, автор - Hanya). Попытки применить указанный подход в реальных случаях не удались. Пришлось применять внешние вызовы программы Curl (успешно). Альтернатива - все тот же Python.
Записан

Владимир.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 514


« Ответ #14: 14 Январь 2022, 14:55 »

Да в принципе никаких, кроме ucp/ucb; если оно не работает, нужны багрепорты Подмигивающий - но удовольствие то ещё, и я думаю, просто мало кто этим реально пользуется.
Записан

С уважением,
Михаил Каганский
Страниц: 1 2 »   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!