Никак не могу придумать красивый способ парсинга http stream от TCP_Client.
Если DataType выставлять в dtString, то сохранять приходится в рваном виде в списке строк.
Может кто-нибудь подскажет как парсить dtStream?
Задача - выдрать из потока картинку.

э, я не совсем представляю о чём речь, но когда пришлось работать с рваным текстом, я использовал это code_9941.txt для буферизации. Ну мне было проще - имелся чёткий признак начала/конца блока..

Теперь я не совсем понял... Это ж вроде как вариация на тему массива строк?
Не-е, я имею ввиду парсинг потока, а не массива строк.

я это имел в виду. По поводу самого парсинга ничего сказать не могу ибо не знаком с протоколом HTTP. Наверное всё зависит от того - что тебе надо - мне например понадобилось вынимать телепрограмму, я это сделал, новые картинки из галереи с тяжёлым (для пользователя) HTML интерфейсом - тоже получилось, и т.д., но иногда попадаются страницы, которые мне трудно понять..

Во я рад что хоть ктото тоже работает в томже направлении , вобщимто я пытался тоже обработать в stream http но есть несколько проблем , http заголовок в str а далее идет в stream разделителем можно считать и [b]
[/b]

Баг в TCP_Client, однозначно.
Jpg-файл от камеры, который я пытаюсь принять должен весить 20-35 Кб, а доходит только 500-8500 байт.
Причем заголовок ответа GET и начало файла есть всегда, иногда есть даже конец файла, а вот середина обрывками.
TCP_Client получает данные только в режиме dtString, в остальных режимах молчит как партизан, ни байта не говорит.
Браузеры получают картинку легко, сниффер тоже видит всё хорошо.

прежде чем делать такие сенсационные выводы советую ознакомится с примером SendPicture.sha.

В схеме SendPicture.sha используется режим dtStream и данные пересылаются от клиента к серверу, а не наоборот.
Так-что аналогия некорректна.

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

Редактировалось 1 раз(а), последний 2017-03-04 14:35:24

Редактировалось 1 раз(а), последний 2017-03-04 14:35:25

Alexeylp, суть в следующем , ты принимаеш картинку не в одном пакете а в нескольких , тоесть заголовок HTTP придёт один с куском данных , а дальше начинают партиями поступать данные пока не примеш их все , задача состоит в следующем , отделить первую часть данных от HTTP заголовка , и начинать складывать поступающие части , причём в HTTP заголовке хранится количество байт для подсчёта принятых данных (это намёк ).
А дальше можеш делать с этими данными что хочеш , ещё ... не советую складывать данные в текстовую область , она добавляет знаки перевода строки , от которых потом просто не избавится.....