Передача кириллицы в http запросе через curl

finsoftrz · Сообщение **finsoftrz** » 26 Июнь 2025, 9:04

Я с ними третью неделю пытаюсь переписываться. Ответы от первой линии приходят быстро, а вот если передают по цепочке, то уже несколько дней надо ждать. Причем не факт, что ответ будет корректный. Первая линия заточена на объяснение пользователям, какие кнопки в их веб интерфейсе нажимать, по шпаргалке, не задумываясь. Мне на первые письма ответили человек 5 разных людей, по содержанию понятно, что они вообще не врубаются, про что речь.

У меня тоже есть опасение, что за деньги скажут, что через curl работать не получится. Причем api само по себе платное, и клиент уже за него что-то в районе 25 тыр на год оплатил. На мое восприятие, ответы на такие вопросы не должны оплачиваться отдельно. Озвучу клиенту, пусть с ними выясняет, что за что платится, и что делать дальше.

Игорь Столяров

finsoftrz писал(а): 26 Июнь 2025, 9:04 что за деньги скажут, что через curl работать не получится

Есть такая вероятность. Когда работал с тех. поддержкой Сбер СБП - там сразу прямо сказали,
что все мои вот эти примеры и дампы с LibCURL им нафиг не интересны.
Мне показали как сделать запрос с моими данными в POSTMAN и показали его успешный результат.
Всё. Дальше сам.

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

finsoftrz · Сообщение **finsoftrz** » 26 Июнь 2025, 9:36

Вообще не сомневаюсь, что какими-то другими способами, где адресная строка передается в utf8, этот запрос работает.
Чем закончилась история со Сбером?

finsoftrz · Сообщение **finsoftrz** » 26 Июнь 2025, 9:58

На самом деле, проблема с кириллицей вылезает только в запросах, где в параметре указывается имя функции документа. Это запрос xsd схемы и формирование титула документа (то есть содержание формализованного документа в xml формате). В принципе, титул можно формировать и самостоятельно, это более трудоемко. Похоже, что придется идти по этому пути.

Игорь Столяров

finsoftrz писал(а): 26 Июнь 2025, 9:36 Чем закончилась история со Сбером?

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

finsoftrz писал(а): 26 Июнь 2025, 9:36 где адресная строка передается в utf8

Где параметры запроса перадаются в его BODY для указанной в HEADER формате / кодировке. Это REST.
Если посмотреть пример ниже, то для передачи UniversalTransferDocument формируется
всё тот же блок c массивом METADATA в котором передаются параметры запроса к сервису ...

finsoftrz · Сообщение **finsoftrz** » 26 Июнь 2025, 10:46

Это часть адреса обращения к api, а не параметры в боди. С боди проблем нет. Если я правильно понимаю, что Вы пишите.

По Сберу хотелось бы услышать, работаете ли Вы через curlib или другим способом. Что все чудесно работает, я не сомневаюсь.

PS. Стоимость консультаций от сотрудника Диадока 3500 в час, количество часов он определяет самостоятельно. Его квалификация не гарантируется.

Игорь Столяров

finsoftrz писал(а): 26 Июнь 2025, 10:46 работаете ли Вы через curlib или другим способом

Да, конечно.
Запросы выполняются через LibCURL, а я по другому и не умею работать из Clarion с REST.

Игорь Столяров

finsoftrz писал(а): 26 Июнь 2025, 10:46 Это часть адреса обращения к api

REST запрос реализуется через вызов функции с параметрами и передачей заголовка (HEADER) и собственно тела (BODY) запроса.

В Вашей строке:
GetContent - имя функции;
Всё что после "?" - это параметры вызова функции, разделённые "&", в формате "Имя"="Значение"

Конкретно параметр "function" имеет значение "СЧФДОП". Вот и всё ...

Лень лезть в справку DIADOC, но вот тоже самое в ЧЗ, где передаётся параметр CIS:

finsoftrz · Сообщение **finsoftrz** » 27 Июнь 2025, 20:53

Я обобщу. Curl выполняет запрос в ansi, Диадок ожидает utf8. Для передачи кириллического фрагмента в адресе (включая параметры) стандартный способ это кодирование фрагмента в urlencode (предварительно переведя в utf8). Если так кодируется передаваемый параметр, то сервис со своей стороны должен его декодировать. Диадок не выполняет декодирование, а принимает его как есть, исключая символы "%". Поэтому не получается через curl отправлять подобные запросы.

Кириллица в адресной строке встречается только в специальных вызовах api Диадока, касающихся генерации титула формализованного документа. Титул формализованного документа это файл в формате xml. Например, упд или документ подтверждения со стороны покупателя. Титулы формализованных документов, касающиеся счетов-фактур (упд) регламентируются государством. Смысл использования упомянутых вызовов в api Диадока (в основном речь про GenerateTitleXml) это упростить процесс создания титулов, так как в каждом титуле часть данных сервис может заполнить сам на основании имеющейся у него информации, часть нам надо ему передать в составе тела rest запроса (так называемый упрощенный формат xml). Чтобы на основании упрощенного xml сервис создал полный xml титула, в запросе надо передать, какой именно документ мы хотим создать. Документы в Диадоке делятся по типам, типы делятся на функции, функции делятся на версии. Для каждой цепочки тип - функция - версия содержимое титулов имеет свои особенности, поэтому цепочка передается в составе параметров запроса (в теле только упрощенный xml). Проблемы выросла из того, что по какой-то причине названия функций сделали в кириллице, хотя все остальное в латинице. Например, для стандартной упд с ндс цепочка выглядит так: UniversalTransferDocument - СЧФДОП - utd970_05_03_01. Мы спотыкаемся на названии функции СЧФДОП.

К счастью, использовать вызовы api с кириллическими параметрами не обязательно. Мы можем сформировать титул (полный xml) самостоятельно. В итоге я так и сделал. Идентичность содержимого сверил с результатом выполнения вызова генерации титула через api Диадока в Postmen. В Postmen, как мы и предположили, запрос прошел корректно, так как там он отправляется в utf8. После этого упд подписалось.

На всякий случай, что делает проблемный вызов api. Мне нужно было сформировать титул покупателя, чтобы подписать пришедшее упд от поставщика. В упрощенном xml мы передаем сервису информацию о сотруднике, который принимает документ, и реквизиты мчд (в нашем случае) для проверки подлинности сертификата. Полный xml титула покупателя, как прописано в законодательстве, включает несколько реквизитов из исходного титула продавца и электронную подпись продавца в формате base64 (то есть ту, которой он подписал свой титул при отправке упд). Реквизиты и подпись титула продавца сервис определяет по переданным в строке адреса идентификаторам.
Чтобы нам сформировать титул покупателя самостоятельно, надо получить исходный xml титула продавца, вытащить оттуда нужные реквизиты (не обязательно парсить xml, можно просто через instring). Затем получить подпись продавца и перевести ее в base64 (только учесть, что она в бинарном виде). Затем собрать это в итоговый полный xml титула покупателя.
После того, как мы сформировали титул покупателя (самостоятельно или через запрос к api GenerateTitleXml), мы подписываем его открепленной подписью, переводим титул в base64, собираем тело rest запроса для отправки в формате json, указав в нем тег, соответствующий операции и включив во вложенных тегах титул покупателя и подпись к нему.

Все это (работа с эдо) очень сложно для понимания, надо основательно погружаться. На мое восприятие, существенно сложнее чем, чем работа с другими сервисами. В основном из-за различных нюансов работы с разными видами документов (у каждой функции и версии свои особенности работы, нет единой унификации). Касаемо Диадока, в целом, у них api выглядит достаточно логично. Но заметно, что писалось и переписывалось разными людьми в разное время, и имеются внутренние нестыковки и заплатки. Разбираться по документации довольно сложно, она больше напоминает справочник, а конкретные примеры работы или отсутствуют, или вызывают дополнительные вопросы. Проверка вызовов api затруднена, так как не всегда возвращаются адекватные ответы. Консультировать в Диадоке по работа с api просто так отказываются, предлагая приобрести услуги их отдела внедрения. В этом случае предоставят телефон сотрудника, который по звонку будет отвечать на вопросы по цене 3500 руб в час. Выгодно это или нет, не стал проверять, так как хз, какая там квалификация у этого сотрудника, и не будут ли они дальше раскручивать на увеличение часов.

Игорь Столяров

finsoftrz писал(а): 27 Июнь 2025, 20:53 Проблемы выросла из того, что по какой-то причине названия функций сделали в кириллице
Например, для стандартной упд с ндс цепочка выглядит так: UniversalTransferDocument - СЧФДОП

Наверно просто взяли штатные названия элемента "Функция" для единообразия.
Если кодировка UTF-8, то набор символов для сервиса значения не имеет.

Проблема именно в передаче значений не английских параметров при вызове CURL.EXE из командной строки.
Должно же быть какие-то решение, учитывая популярность CURL во всём мире ...

finsoftrz · Сообщение **finsoftrz** » 27 Июнь 2025, 21:23

Еще такой момент. У разных операторов эдо разное api, но идеология должна быть сходная, так как регламентируется обмен документами между ними самими.
Важный момент, по которому захотели использовать api, это то, что документы приходят на юридическое лицо, в формате обмена между операторами эдо не предусмотрена адресная передача, если несколько подразделений. В частности, у нас все магазины в веб интерфейсе оператора видят общую кучу документов, что приводит к тому, что про некоторые документы забывают и теряют из вида.
Диадок предлагает механизм использования подразделений внутри своего сервиса. То есть, если поставщик тоже пользуется Диадоком, он может при отправке выбрать конкретный магазин покупателя. Для поставщиков, работающих с другими сервисами эдо, Диадок предлагает механизм автоматическое перенаправление на отдельное служебное подразделение, а оттуда уже вручную делать внутренне перемещение в нужный магазин. Это, конечно, неудобно. Кроме этого, есть вариант, что поставщик из Диадока может неверно указать подразделение (магазин), так как это никак не связано с содержимым документа.
В итоги я решил пойти по пути извлечения адреса грузополучателя непосредственно из xml накладной (упд) поставщика. Для этого нужно загрузить xml каждого неподписанного документа и через instring (чтобы не парсить xml целиком) вытащить один из 3 вариантов оформления адреса. Чтобы не делать этого постоянно, связка ид сообщения (документа) и адреса сохраняются в базе данных. Мы приписываем каждому магазину ключевые слова адреса, разделенные пробелом, по которым можно распознать, кому предназначается конкретный документ. У клиента примерно 30 продуктовых магазинов, у каждого магазина за день через эдо может быть с десяток приходов (в крупных еще больше), идентификация новых документов может занимать до 2 мин. В целом, это приемлемо.

finsoftrz · Сообщение **finsoftrz** » 27 Июнь 2025, 21:30

Игорь Столяров писал(а): 27 Июнь 2025, 21:18 Проблема именно в передаче значений не английских параметров при вызове CURL.EXE из командной строки.
Должно же быть какие-то решение, учитывая популярность CURL во всём мире ...

Вот я им так и написал. Техподдержка сказала, что они ничего про это не знают, обращайтесь в отдел внедрения за отдельную плату.
В принципе, как я написал, можно обойтись без этих вызовов api. Они, скорее всего, специфичны именно для Диадока. Можно самостоятельно формировать титулы. Но подтвердить диагноз, конечно, хотелось бы. Вдруг у них есть какое-то специфическое решение. Потому что сервис хоть и не декадирует urlencode, но как-то все таки реагирует на содержание.

Игорь Столяров

finsoftrz писал(а): 27 Июнь 2025, 21:30 Можно самостоятельно формировать титулы.

Можно самостоятельно формировать и EXE файлы. Вопрос в том, кто потом это творчество будет сопровождать.

finsoftrz писал(а): 27 Июнь 2025, 21:30 Техподдержка сказала, что они ничего про это не знают

Я так думаю что они правы. Это не проблема Diadoc. Это вопрос к CURL.EXE.
Кроме частичного перебора методом тыка, должно быть какое-то описание по передаче параметров
в национальной кодировке из командной строки ...

finsoftrz · Сообщение **finsoftrz** » 27 Июнь 2025, 21:36

Игорь Столяров писал(а): 27 Июнь 2025, 21:18 [Проблема именно в передаче значений не английских параметров при вызове CURL.EXE из командной строки.
Должно же быть какие-то решение, учитывая популярность CURL во всём мире ...

Не только из командной строки. Если Вы будете работать из curlib, столкнетесь с аналогичной проблемой. Можете погуглить, в интернете есть подтверждение. Командная строка это просто надстройка над curlib.
Если не верите на слово, можете сделать тест. Я с curlib напрямую не работаю. Могу Вам приватно дать значение id api, текущего токена, строку запроса и упрощенный xml для тела запроса.

finsoftrz · Сообщение **finsoftrz** » 27 Июнь 2025, 21:40

Игорь Столяров писал(а): 27 Июнь 2025, 21:35 Я так думаю что они правы. Это не проблема Diadoc. Это вопрос к CURL.EXE.
Кроме частичного перебора методом тыка, должно быть какое-то описание по передаче параметров
в национальной кодировке из командной строки ...

Они не правы в том, что сервис не умеет декодировать urlencode. Это общепринятый механизм передачи параметров в вебе. И не правы в том, что требуют деньги за ответ на подобный вопрос. По хорошему, они должны были перенаправить его своим старшим, а потом разместить в faq.