Точно так же, какова разница между php://output
а также php://stdout
?
Я пытался выяснить, как серверы обеспечивают php://input
а также php://output
, Единственный способ, которым я мог придумать (учитывая, что оба php://input
а также php://output
не зависят от загадочного файла php.ini согласно эта страница в руководстве) будет меняться stdin
а также stdout
чтобы оба ссылались на дескриптор файла сокета соединения. Но потом, к моему огорчению, я узнал, что php://stdin
а также php://stdout
были также определены — по-видимому, по-другому.
Это просто избыточность или эти имена файлов на самом деле относятся к разным вещам? Может кто-нибудь сказать мне, что здесь происходит?
Разница заключается в среде, где вы должны их использовать. php://stdin
, php://stdout
, а также php://stderr
сопоставлены непосредственно с соответствующими POSIX файловые потоки и предназначены для использования с CLI SAPI. С другой стороны, php://input
а также php://output
предназначены для использования с веб-интерфейсами SAPI.
Попробуйте запустить эти две команды из командной строки:
printf "foo" | php -r "var_dump(file_get_contents('php://stdin'));"
printf "foo" | php -r "var_dump(file_get_contents('php://input'));"
Вы получите такой результат:
Command line code:1:
string(3) "foo"
Command line code:1:
string(0) ""
Так как php://input
ожидает, что будет использоваться веб-SAPI, таким как CGI или mod_php, и не получит содержимое STDIN, переданное ему. Точно так же, пытаясь читать необработанные данные POST (единственное реальное использование для php://input
) с помощью php://stdin
потерпит неудачу
php://output
обычно может использоваться в обеих средах, но редко используется вообще, так как можно просто echo
выход. php://stdout
является более логичным выбором для кода командной строки, хотя опять же, как правило, проще использовать echo
,
php://stderr
конечно, неоценим для программистов командной строки, которым нужно выводить информационные сообщения, сообщения об ошибках или сообщения об ошибках в другой поток, чем выходные данные программы.
Других решений пока нет …