Передача файла в теле запроса

1. user1086697 30.10.24 10:37 Сейчас в теме
Здравствуйте.
Как можно несколько файлов передать в теле HTtp запроса?
httpзапрос.УстановитьтелоИзДвоичныхДанных(новые двоичныеданные(ПутьКФайлу))
Файл все равно не устанавливается
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
3. Sashares 35 30.10.24 10:55 Сейчас в теме
(1) https://wonderland.v8.1c.ru/blog/novye-instrumenty-dlya-raboty-s-dvoichnymi-dannymi-obespechivayut-kak-posledovatelnyy-dostup-k-danny/?sphrase_id=1013756

Смотри в разделе "Пример чтения и записи составного (multipart) HTTP-сообщения"
user1671936; NicolasCage; user1863362; +3 Ответить
7. starik-2005 3091 30.10.24 14:04 Сейчас в теме
А есть разница, как их отправлять? В стародревние времена придумали сериализацию. В итоге создаешь массив, добавляешь в него кучу двоичных данных, сериализуешь его в JSON, например, а потом постишь. На той стороне пусть этот JSON обойдут, вытащат двоичные данные и засунут куда там им надо.

Если же разница есть, то читаем RFC про отправку файлов со всеми этими полями разделителей, создаваемых для отделения частей друг от друга.
user1671936; +1 Ответить
8. MissionOnly 8 31.10.24 17:08 Сейчас в теме
(7) Двоичные данные в JSON попадают в BASE64 кодировке?
10. user1863362 31.10.24 17:38 Сейчас в теме
(8)
в BASE64
В чем напишешь. Хочешь - в HEX, хочешь - UUENCODE, хочешь - в BASE122, хочешь - в UTF16, прикрытым URLENCODE...

Нет преград!.
9. user1863362 31.10.24 17:33 Сейчас в теме
(7)
В итоге создаешь массив, добавляешь в него кучу двоичных данных, сериализуешь его в JSON, например, а потом постишь.
Вот так, с помощью нехитрых приспособлений, буханку хлеба можно превратить в троллейбус можно изобрести свой стандарт mime типа multipart/form-data.

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

И эта музыка будет вечной.
11. starik-2005 3091 01.11.24 13:30 Сейчас в теме
(9)
можно изобрести свой стандарт mime типа multipart/form-data
Любой стандарт - это предложение того, как надо делать. Некоторым стандартам уже дофига лет и они морально устарели, ибо в стародревние времена все эти бэйз64 и прочие ЮЮки были придуманы, чтобы данные укладывались в 7-бит с одним битом четности. В современных реалиях это все продолжают юзать, хотя могли бы кидать и через ХТТП2 бинарным потоком, но 1С хттп2 не умеет. А как там под капотом передача по ХТТП1/1+ работает - вообще мало кто задумывается. И правильно, ибо нафиг-нафиг, моск еще напрягать.

А объемы - да, сейчас это малоактуально, если, конечно, у автора не GPRS первого поколения в глухом сибирском лесу, а старлинк вера купить не позволяет.
2. MissionOnly 8 30.10.24 10:42 Сейчас в теме
По одному файлу, как двоичные данные, можно передать по HTTP запросу (вопрос размера открыт, даже большие картинки будут тормозить).
4. user1863362 30.10.24 11:05 Сейчас в теме
(2) Пожми в архив и шли одним зипом.
Но лучше, конечно, разобраться с мультпартом по ссылке ниже.
5. MissionOnly 8 30.10.24 11:47 Сейчас в теме
Вижу необходимость резать один файл на куски, а не отравлять большой файл состоящий из многих вложений. Причем практика показывает, что много маленьких файлов по НТТР запросам проходят быстрее, чем один большой файл такого же размера. И к слову, двоичные данные практически не ужимаются архиваторами.
12. starik-2005 3091 01.11.24 13:36 Сейчас в теме
(5)
Причем практика показывает, что много маленьких файлов по НТТР запросам проходят быстрее, чем один большой файл такого же размера. И к слову, двоичные данные практически не ужимаются архиваторами.
Много маленьких файлов можно отправить параллельно. Т.е. отправил файл, не ждешь завершения и отправляешь следующий. Ну и далее.

По поводу сжатия, то что такое "двоичные данные"? Архиватору наплевать, что сжимать. Картинки, которые уже сжаты (фактически, данные в них реорганизованы так, чтобы достичь очень большой информационной энтропии), будут жаться слабо, ибо сжатие - это повышение той самой информационной энтропии.
Энтропия ограничивает максимально возможное сжатие без потерь (или почти без потерь), которое может быть реализовано при использовании теоретически — типичного набора или, на практике, — кодирования Хаффмана, кодирования Лемпеля — Зива — Велча или арифметического кодирования.
Т.е. двоичные данные с низкой энтропией (например, миллион нолей), сожмутся сильнее, чем какой-нить навороченный XML.

Кстати, вот еще кой-что из теории информации:
Энтропийное кодирование — кодирование последовательности значений с возможностью однозначного восстановления с целью уменьшения объёма данных (длины последовательности) с помощью усреднения вероятностей появления элементов в закодированной последовательности.

Предполагается, что до кодирования отдельные элементы последовательности имеют различную вероятность появления. После кодирования в результирующей последовательности вероятности появления отдельных символов практически одинаковы (энтропия на символ максимальна).
6. user1863362 30.10.24 12:17 Сейчас в теме
(5)
И к слову, двоичные данные практически не ужимаются архиваторами.
Вот это сейчас смешно было, спасибо
user1671936; starik-2005; +2 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот