Передача файла в теле запроса
По теме из базы знаний
- Отправка файлов через SOAP. SOAP with attachments, MTOM
- http - сервис (выгрузка файлов обработок)
- Подробнее о создании ботов Телеграм с помощью расширения Боцман
- Взаимодействие с сотрудниками и клиентами из одного окна конфигурации 1С (Телеграм, ВКонтакте, Facebook, Discord). Преимущества, технические особенности, подводные камни
- Варианты отладки и оптимизации запросов в 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
А есть разница, как их отправлять? В стародревние времена придумали сериализацию. В итоге создаешь массив, добавляешь в него кучу двоичных данных, сериализуешь его в JSON, например, а потом постишь. На той стороне пусть этот JSON обойдут, вытащат двоичные данные и засунут куда там им надо.
Если же разница есть, то читаем RFC про отправку файлов со всеми этими полями разделителей, создаваемых для отделения частей друг от друга.
Если же разница есть, то читаем RFC про отправку файлов со всеми этими полями разделителей, создаваемых для отделения частей друг от друга.
(7) буханку хлеба можно превратить в троллейбус можно изобрести свой стандарт mime типа multipart/form-data.
Потом обнаружить, что сериализация увеличивает размер данных, начать пытаться сжимать уже их, так как
И эта музыка будет вечной.
В итоге создаешь массив, добавляешь в него кучу двоичных данных, сериализуешь его в JSON, например, а потом постишь.
Вот так, с помощью нехитрых приспособлений, Потом обнаружить, что сериализация увеличивает размер данных, начать пытаться сжимать уже их, так как
двоичные данные практически не ужимаются архиваторами.
, открыть для себя идею сплошного архива, увидеть, что файл получается все равно слишком большим, и начать думать о том, как его в несколько файлов передать в теле http запроса
...
И эта музыка будет вечной.
(9)
А объемы - да, сейчас это малоактуально, если, конечно, у автора не GPRS первого поколения в глухом сибирском лесу, а старлинк вера купить не позволяет.
можно изобрести свой стандарт mime типа multipart/form-data
Любой стандарт - это предложение того, как надо делать. Некоторым стандартам уже дофига лет и они морально устарели, ибо в стародревние времена все эти бэйз64 и прочие ЮЮки были придуманы, чтобы данные укладывались в 7-бит с одним битом четности. В современных реалиях это все продолжают юзать, хотя могли бы кидать и через ХТТП2 бинарным потоком, но 1С хттп2 не умеет. А как там под капотом передача по ХТТП1/1+ работает - вообще мало кто задумывается. И правильно, ибо нафиг-нафиг, моск еще напрягать.
А объемы - да, сейчас это малоактуально, если, конечно, у автора не GPRS первого поколения в глухом сибирском лесу, а старлинк вера купить не позволяет.
Вижу необходимость резать один файл на куски, а не отравлять большой файл состоящий из многих вложений. Причем практика показывает, что много маленьких файлов по НТТР запросам проходят быстрее, чем один большой файл такого же размера. И к слову, двоичные данные практически не ужимаются архиваторами.
(5)
По поводу сжатия, то что такое "двоичные данные"? Архиватору наплевать, что сжимать. Картинки, которые уже сжаты (фактически, данные в них реорганизованы так, чтобы достичь очень большой информационной энтропии), будут жаться слабо, ибо сжатие - это повышение той самой информационной энтропии.
Кстати, вот еще кой-что из теории информации:
Причем практика показывает, что много маленьких файлов по НТТР запросам проходят быстрее, чем один большой файл такого же размера. И к слову, двоичные данные практически не ужимаются архиваторами.
Много маленьких файлов можно отправить параллельно. Т.е. отправил файл, не ждешь завершения и отправляешь следующий. Ну и далее.
По поводу сжатия, то что такое "двоичные данные"? Архиватору наплевать, что сжимать. Картинки, которые уже сжаты (фактически, данные в них реорганизованы так, чтобы достичь очень большой информационной энтропии), будут жаться слабо, ибо сжатие - это повышение той самой информационной энтропии.
Энтропия ограничивает максимально возможное сжатие без потерь (или почти без потерь), которое может быть реализовано при использовании теоретически — типичного набора или, на практике, — кодирования Хаффмана, кодирования Лемпеля — Зива — Велча или арифметического кодирования.
Т.е. двоичные данные с низкой энтропией (например, миллион нолей), сожмутся сильнее, чем какой-нить навороченный XML.
Кстати, вот еще кой-что из теории информации:
Энтропийное кодирование — кодирование последовательности значений с возможностью однозначного восстановления с целью уменьшения объёма данных (длины последовательности) с помощью усреднения вероятностей появления элементов в закодированной последовательности.
Предполагается, что до кодирования отдельные элементы последовательности имеют различную вероятность появления. После кодирования в результирующей последовательности вероятности появления отдельных символов практически одинаковы (энтропия на символ максимальна).
Предполагается, что до кодирования отдельные элементы последовательности имеют различную вероятность появления. После кодирования в результирующей последовательности вероятности появления отдельных символов практически одинаковы (энтропия на символ максимальна).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот