Я наткнулся на эту функцию, которая обещала работать через IE, FF и Chrome. Но это не работает в Chrome. Есть ли работа?
function buffer_flush(){ echo str_pad('', 512); echo '<!-- -->'; if(ob_get_length()){ @ob_flush(); @flush(); @ob_end_flush(); } @ob_start(); }
Вот как я получил flush (), работающий в цикле while в Chrome 12.0.742.122 с PHP 5.3.6:
echo("<html><body>"); while(1) { echo(str_pad($my_string_var,2048," ")); @ob_flush(); flush(); }
Использование меньшего значения str_pad тоже работало, но для первого вывода потребуется немного больше времени. Если какая-либо из других строк отсутствует, ничего не появится.
«@» Не является строго необходимым, но он предотвращает заполнение журнала сообщением «ничего в буфере».
И, конечно, если у вас есть уже существующая страница, просто убедитесь, что там находятся теги <html>
и <body>
; Я писал страницу с нуля.
С помощью flush()
/ ob_flush()
вы отправляете только вывод в браузер, но все равно до браузера, когда он отображает его. Я предполагаю, что хром просто ждет, пока у него не будет достаточно данных, чтобы отобразить «полезную» страницу, а не некоторые фрагменты.
В любом случае, некоторые предложения:
@
(особенно, если вы точно не знаете, что он делает) Если вы не вызываете ob_end_*()
, вам больше не нужно вызывать ob_start()
. Его неэффективность
function buffer_flush(){ echo '<!-- -->'; // ? ob_flush(); flush(); }
Некоторые браузеры (IE6, по крайней мере, и, возможно, хром) требуют определенного количества «полезных» символов (т. Е. Не пробелов) до вывода чего-либо. В случае IE6 даже размер сжатых данных должен быть нажат.
function force_flush() { echo "\n\n<!-- Deal with browser-related buffering by sending some incompressible strings -->\n\n"; for ( $i = 0; $i < 5; $i++ ) echo "<!-- abcdefghijklmnopqrstuvwxyz1234567890aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz11223344556677889900abacbcbdcdcededfefegfgfhghgihihjijikjkjlklkmlmlnmnmononpopoqpqprqrqsrsrtstsubcbcdcdedefefgfabcadefbghicjkldmnoepqrfstugvwxhyz1i234j567k890laabmbccnddeoeffpgghqhiirjjksklltmmnunoovppqwqrrxsstytuuzvvw0wxx1yyz2z113223434455666777889890091abc2def3ghi4jkl5mno6pqr7stu8vwx9yz11aab2bcc3dd4ee5ff6gg7hh8ii9j0jk1kl2lmm3nnoo4p5pq6qrr7ss8tt9uuvv0wwx1x2yyzz13aba4cbcb5dcdc6dedfef8egf9gfh0ghg1ihi2hji3jik4jkj5lkl6kml7mln8mnm9ono -->\n\n"; while ( ob_get_level() ) ob_end_flush(); @ob_flush(); @flush(); } # force_flush()
Есть несколько компонентов, которые могут повлиять на эту проблему.
Внимательно прочитайте документацию по этой функции: http://www.php.net/manual/en/function.flush.php
Одно из решений, которое я использовал, – это использование Apache2 с mod-php (не как fcgi, а как собственный apache-модуль) и Chromium. Результат пришел сразу, и скрипт все еще работал и отправлял больше результатов.
После ввода следующих двух кодовых строк всякая эхо-команда сразу же нажимает текст на любой PHP-сервер :
ob_implicit_flush(1); @ob_end_flush(); // set an end to the php-output-buffer!
Но этот php-сервер может иметь свой собственный буфер. Например, я запускаю nginx в качестве web-сервера, а php используется модулем fast-cgi. Сам Nginx имеет свой собственный буфер … и так далее.
Браузер также может буферизовать запрос. Но поскольку у меня есть Chromium (или Google Chrome), у вас есть небольшой или пустой буфер.
Пожалуйста, ознакомьтесь с документацией каждой функции, о которой я говорил, чтобы понять, что они на самом деле делают, – но особенно документацию flush () .
Личный совет: не помещайте лишние символы в выходной буфер, а читайте и понимайте конфигурацию своего сервера.
EDIT: если у вас включен gzip, весь ответ с сервера будет буферизирован.
Я обнаружил, что заголовок типа контента действительно заставляет его работать в chrome после нескольких проб и ошибок.
Но я не знаю, почему хром не сливается в противном случае.
после поиска дополнительных ответов я читал, что хром-флеши, как вы ожидаете, только когда установлен допустимый тип контента. хорошо.
Вот код, который я экспериментировал.
<?php header('Content-Type: text/html; charset=UTF-8'); echo 'starting...'; flush(); echo 'to sleep...'; flush(); sleep(5); echo 'awake';
если я не включаю заголовок типа контента, я получаю следующее за один выстрел через 5 секунд. так что мы ожидаем не получилось.
начиная … спать … отображается бодрствование, и скрипт завершается.
где, как и когда я дал тип содержимого, как указано выше, подтипом (charset), тогда
начало … для сна … отображается сразу, а затем через 5 секунд отображается пробуждение.
Я просто слепо полагаю, что в отношении заголовка типа содержимого хром показывает результат.
Кроме того, когда я дал «Content-Type: text / plain» или «Content-Type: text / html», это не сработало. он работал только с подтипом 'charset = [sometexthere]'.
были как приложения / json. и я не экспериментировал с большим количеством мимов.
Причина, по которой я здесь, – это
Я хотел использовать readistate 3 в ответе ajax. он отлично работает, кроме хрома и сафари. так как хром использует webkit, то и то и другое.
в других браузерах, в том числе IE, промывка работает как ожидалось, а также readystate = 3, но в хроме и сафари я просто использовал вышеописанное решение.
вот скриншот readystate – responseetext из вышеупомянутого скрипта php
на изображении есть два набора ответов, первый из которых с readistate 3 и responseetext пуст, когда тип контента не используется.
во втором ответе вы можете видеть, что состояние готовности 3 имеет answeretext с ожидаемым выходом. это когда используется тип контента.
поэтому … Хром только знает.
при использовании str_pad
Когда вы используете добавление строк, вы можете получить более ожидаемый результат. Я попытался использовать 1024, как и выше, но только с типом контента.
если используется дополнение и не задан тип контента, это не сработало.
а также
я поставил вопрос, подобный этому, и я собираюсь добавить свой собственный ответ, связав этот ответ с этим и обратно к спине … чтобы пользователям было легче получить более подробную информацию. hhmmm.