Пару дней назад я столкнулся с этой проблемой при получении данных через API, на что ответ (после разрешения обещания) был следующего формата -

<Buffer 7b 22 73 75 ... >

Сначала я подумал, что попадаю не в ту конечную точку, но, проверив конечную точку пару раз через Postman и прочитав о буферах, я понял, что ответ требует немного дополнительной обработки, прежде чем я смогу его использовать/рендерить.

Так что же такое буферы и зачем они нам нужны?

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

Думайте об этом как о еде. Вы не засовываете в рот целый бургер за один раз, вы разбиваете его на более мелкие кусочки. Точно так же большие данные могут быть разбиты на более мелкие фрагменты, а затем эти фрагменты преобразованы в буферы (двоичные данные, хранящиеся вне ядра V8).

Эти фрагменты получены клиентом, и как только они будут объединены в правильном порядке, в нашем распоряжении будут полные данные.

Подробнее о буферах можно прочитать здесь.

Возвращаясь к ответу API

Итак, теперь, когда мы знаем, что такое буферы, как нам обработать ответ API типа «буфер»?

Мы знаем это, поскольку мы получили ответ в формате <Buffer 7b 22 73 75 ... > , и это, вероятно, первый фрагмент данных, который был отправлен нам, поэтому мы, вероятно, должны объединить его с остальным фрагментом и не должны отображать ответ до тех пор, пока данные правильно обрабатывается.

В качестве примера я попытаюсь получить данные по следующей ссылке —

https://jigsaw.w3.org/HTTP/ChunkedScript

Если вы нажмете на ссылку, вы увидите, что в документе много данных, и имеет смысл извлекать их в виде «кусков» или «фрагментов».

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

Здесь я использую модуль https для получения фрагментированных данных. Здесь мы перехватываем сгенерированное событие, а именно данные, где каждый фрагмент регистрируется как буфер. Мы объединяем эти буферы как строку и, наконец, возвращаем их через промис, используя обратный вызов ‘resolve’. Если вы не знаете, как работают промисы, нажмите здесь.

Когда все фрагменты успешно переданы, генерируется событие «end», и именно здесь мы запускаем обратный вызов «resolve».

Как только мы разрешаем данные в блоке кода «затем», мы, наконец, получаем доступ к полным данным, и они извлекаются как «результат».

Вот вывод блока кода на моем терминале —

Обратите внимание, что я зарегистрировал только размер данных, а не сами данные. Это демонстрирует, что суммирование всех фрагментов приведет к полным данным. Я также зарегистрировал сами данные, которые показаны следующим образом:

Журнал, показанный выше, неполный, так как окончательные данные были слишком большими и не поместились на изображении.

Обратите внимание, что каждый фрагмент имеет тип Buffer, где окончательные (объединенные) данные представляют собой не буфер, а строку, поскольку объединенные буферы разрешаются в строку. Если ваши данные не в виде строки и вы пытаетесь получить закодированное изображение, видео или текст, вам может потребоваться дополнительная обработка, простое объединение фрагментов не даст вам правильного результата.

Надеюсь, это поможет вам понять основы извлечения фрагментированных или фрагментированных данных. Хорошего дня. Ваше здоровье!