This question's answers are a community effort。编辑现有答案以改善此职位。它目前不接受新的答案或互动。
运行脚本时,出现如下错误:
警告:无法修改标头信息-第23行的/some/file.php中已经发送过的标头(输出始于/some/file.php:12)
错误消息中提到的行包含
这可能是什么原因?以及如何解决?
页面/输出始终跟随标题。 PHP必须通过
Web服务器的头。它只能这样做一次。
在两次换行后,它再也不能修改它们。
当PHP收到第一个输出(
刷新所有收集的标头。之后,它可以发送所有输出
它想要。但是,那时不可能发送更多的HTTP标头。
您如何找出过早输出发生的位置?
找出问题原因:
警告:无法修改标头信息-标头已由发送
(输出从/www/usr2345/htdocs/auth.php:52开始)
/www/usr2345/htdocs/index.php,第100行
这里的“第100行”指的是
括号内的“输出始于”注释更为重要。
它表示先前输出的来源。在此示例中,它是
并在
典型原因:
打印,回显
发送HTTP标头的机会。申请流程必须
进行重组以避免这种情况。使用functions
和模板方案。确保在消息之前发生
被写出来。
产生输出的功能包括
以及用户定义的功能。
原始HTML区域
必须注意将触发
在任何原始的
使用模板方案将处理与输出逻辑分开。
将表单处理代码放在脚本之上。
使用临时字符串变量来延迟消息。
实际输出逻辑和混合HTML输出应紧随其后。
如果警告涉及行
开头
类似地,它可能发生在附加的脚本或脚本节中:
实际上,PHP在关闭标签后吃了一个换行符。但这不会
补偿多个换行符或制表符或空格已移入此类间隙。
UTF-8 BOM
仅换行和空格可能是一个问题。但是也有“隐形”
可能导致这种情况的字符序列。最著名的
UTF-8 BOM (Byte-Order-Mark)
大多数文本编辑器都不会显示。这是字节序列
是可选的,对于UTF-8编码的文档是多余的。但是PHP必须处理
作为原始输出。它可能在输出中显示为字符
将该文档解释为Latin-1)或类似的“垃圾”。
特别是图形编辑器和基于Java的IDE忽略了它
存在。他们没有可视化(受Unicode标准约束)。
但是,大多数程序员和控制台编辑器都这样做:
很容易及早发现问题。其他编辑者可能会确定
它在文件/设置菜单中的存在(Windows上的Notepad ++可以识别和
remedy the problem),
检查BOM表存在的另一种方法是求助于hexeditor。
在* nix系统上,通常可以使用
如果不是图形变体,则可以简化审核这些问题和其他问题:
一个简单的解决方法是将文本编辑器设置为将文件另存为“ UTF-8(无BOM)”
或类似的术语。否则,新来者通常会求助于创造新事物
文件,然后复制并粘贴以前的代码。
校正工具
也有自动工具可以检查和重写文本文件
(
对于PHP,特别是
它将关闭和打开标签重写为长短形式,但也很容易
修复了开头和结尾的空格,Unicode和UTF-x BOM问题:
在整个包含目录或项目目录上使用都是理智的。
如果错误源在后面提到
closing
然后在这里写出一些空白或原始文本。
PHP结束标记此时不终止脚本执行
点。后面的任何文本/空格字符将被写为页面内容
仍然。
通常建议,尤其是对新手来说,后跟
关闭标签应省略。这避免了这些情况的一小部分。
(罪魁祸首通常是
错误源提到为“第0行未知”
如果没有错误源,通常是PHP扩展名或php.ini设置
被具体化。
有时是
or the
但也可以是任何双重加载的
生成隐式的PHP启动/警告消息。
前面的错误信息
如果另一个PHP语句或表达式导致警告消息或
注意被打印出来,这也算作过早的输出。
在这种情况下,您需要避免错误,
延迟语句的执行,或通过以下方式禁止显示该消息:
当以后都不妨碍调试时。
没有错误讯息
如果根据
则不会显示警告。但是忽略错误并不能解决问题
远。标头过早输出后仍无法发送标头。
因此,当
建议探测警告。使用两个简单的命令重新启用它们
在调用脚本之上:
或
说到重定向头,您应该经常使用如下习惯用法:
这是最终的代码路径:
最好甚至是实用程序功能,它会打印用户消息
如果
解决方案是输出缓冲
PHP output buffering
是缓解此问题的解决方法。它通常可以可靠地工作,但不应该
替代适当的应用程序结构并将输出与控制分开
逻辑。其实际目的是最大程度地减少到Web服务器的分块传输。
设置仍然可以提供帮助。
在php.ini中进行配置
或通过.htaccess
甚至是.user.ini
现代FPM / FastCGI设置。
启用它将允许PHP缓冲输出,而不是将其传递到Web服务器
即刻。因此,PHP可以聚合HTTP标头。
同样可以调用
在调用脚本之上。但是,由于多种原因,它的可靠性较差:
即使
BOM表可能在rendering it ineffective之前被改组。
它可以隐藏用于HTML输出的空格。但是一旦申请
逻辑尝试发送二进制内容(例如,生成的图像),
缓冲的无关输出成为问题。 (必须
作为进一步的解决方法。)
缓冲区的大小是有限的,当保留默认值时,缓冲区很容易溢出。
而且,difficult to track down也不罕见
当它发生的时候。
因此,两种方法都可能变得不可靠-特别是在
开发设置和/或生产服务器。这就是为什么输出缓冲是
被广泛认为只是拐杖/严格来说是一种解决方法。
另请参见basic usage example
在手册中,以及更多的利弊:
What is output buffering?
Why use output buffering in PHP?
Is using output buffering considered a bad practice?
Use case for output buffering as the correct solution to "headers already sent"
但是它在另一台服务器上工作了!
如果您之前未收到标头警告,则output buffering php.ini setting
已经改变。当前/新服务器上可能未配置它。
用
您始终可以使用
仍然可以...发送标头。这对于有条件打印很有用
信息或应用其他后备逻辑。
有用的后备解决方法是:
HTML
如果您的应用程序在结构上难以修复,则很容易(但是
有点不专业的方法)允许重定向是注入HTML
或短暂延迟:
当通过
大多数浏览器仍然接受它。
JavaScript重定向
作为替代JavaScript redirect
可以用于页面重定向:
尽管这通常比
它会导致对具有JavaScript功能的客户端的依赖。
但是,当使用真正的HTTP标头()时,这两种方法都会产生可接受的回退
通话失败。理想情况下,您总是将其与用户友好的消息结合起来,
点击链接是最后的选择。 (例如http_redirect()
PECL扩展名可以。)
为什么
因此,适用相同的条件,并且将生成类似的错误消息
对于过早的输出情况。
(当然,它们还会受到浏览器中禁用Cookie的影响,
甚至代理问题。会话功能显然也取决于免费
磁盘空间和其他php.ini设置等)
其他连结
Google提供了lengthy list of similar discussions。
当然,many specific cases也已在堆栈溢出中讨论过。
WordPress常见问题解答以通用方式解释How do I solve the Headers already sent warning problem?。
Adobe社区:PHP development: why redirects don't work (headers already sent)
核常见问题解答:What does "page headers already sent" mean?
更为详尽的解释之一是HTTP Headers and the PHP header() Function - A tutorial by NicholasSolutions(Internet存档链接)。
它详细介绍了HTTP,并提供了一些重写脚本的准则。
运行脚本时,出现如下错误:
警告:无法修改标头信息-第23行的/some/file.php中已经发送过的标头(输出始于/some/file.php:12)
错误消息中提到的行包含
header()
和setcookie()
调用。这可能是什么原因?以及如何解决?
最佳答案
发送头之前无输出!
在进行任何输出之前,必须先调用发送/修改HTTP标头的函数。
summary ⇊
否则,调用将失败:
警告:无法修改标头信息-标头已发送(输出从script:line开始)
修改HTTP标头的一些功能是:header
/ header_remove
session_start
/ session_regenerate_id
setcookie
/ setrawcookie
输出可以是:
无意间:<?php
之前或?>
之后的空格
UTF-8 Byte Order Mark特别是
先前的错误消息或通知
故意的:print
,echo
和其他产生输出的函数
原始的<html>
节之前的<?php
代码。
为什么会发生?
要了解为什么必须在输出之前发送标头,这是必要的
看一个典型的HTTP
响应。 PHP脚本主要生成HTML内容,但还会传递
Web服务器的一组HTTP / CGI标头:
HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="/"> <img src=internal-icon-delayed> </a>
页面/输出始终跟随标题。 PHP必须通过
Web服务器的头。它只能这样做一次。
在两次换行后,它再也不能修改它们。
当PHP收到第一个输出(
print
,echo
,<html>
)时,它将刷新所有收集的标头。之后,它可以发送所有输出
它想要。但是,那时不可能发送更多的HTTP标头。
您如何找出过早输出发生的位置?
header()
警告包含与之相关的所有相关信息找出问题原因:
警告:无法修改标头信息-标头已由发送
(输出从/www/usr2345/htdocs/auth.php:52开始)
/www/usr2345/htdocs/index.php,第100行
这里的“第100行”指的是
header()
调用失败的脚本。括号内的“输出始于”注释更为重要。
它表示先前输出的来源。在此示例中,它是
auth.php
并在
52
行。那是您必须寻找过早输出的地方。典型原因:
打印,回显
print
和echo
语句的有意输出将终止发送HTTP标头的机会。申请流程必须
进行重组以避免这种情况。使用functions
和模板方案。确保在消息之前发生
header()
呼叫被写出来。
产生输出的功能包括
print
,echo
,printf
,vprintf
trigger_error
,ob_flush
,ob_end_flush
,var_dump
,print_r
readfile
,passthru
,flush
,imagepng
,imagejpeg
以及用户定义的功能。
原始HTML区域
.php
文件中未解析的HTML部分也可以直接输出。必须注意将触发
header()
调用的脚本条件在任何原始的
<html>
块之前。<!DOCTYPE html>
<?php
// Too late for headers already.
使用模板方案将处理与输出逻辑分开。
将表单处理代码放在脚本之上。
使用临时字符串变量来延迟消息。
实际输出逻辑和混合HTML输出应紧随其后。
<?php
前的“ script.php第1行”警告空白如果警告涉及行
1
中的输出,则主要是开头
<?php
标记之前的空白,文本或HTML。 <?php
# There's a SINGLE space/newline before <? - Which already seals it.
类似地,它可能发生在附加的脚本或脚本节中:
?>
<?php
实际上,PHP在关闭标签后吃了一个换行符。但这不会
补偿多个换行符或制表符或空格已移入此类间隙。
UTF-8 BOM
仅换行和空格可能是一个问题。但是也有“隐形”
可能导致这种情况的字符序列。最著名的
UTF-8 BOM (Byte-Order-Mark)
大多数文本编辑器都不会显示。这是字节序列
EF BB BF
是可选的,对于UTF-8编码的文档是多余的。但是PHP必须处理
作为原始输出。它可能在输出中显示为字符

(如果客户端将该文档解释为Latin-1)或类似的“垃圾”。
特别是图形编辑器和基于Java的IDE忽略了它
存在。他们没有可视化(受Unicode标准约束)。
但是,大多数程序员和控制台编辑器都这样做:
很容易及早发现问题。其他编辑者可能会确定
它在文件/设置菜单中的存在(Windows上的Notepad ++可以识别和
remedy the problem),
检查BOM表存在的另一种方法是求助于hexeditor。
在* nix系统上,通常可以使用
hexdump
,如果不是图形变体,则可以简化审核这些问题和其他问题:
一个简单的解决方法是将文本编辑器设置为将文件另存为“ UTF-8(无BOM)”
或类似的术语。否则,新来者通常会求助于创造新事物
文件,然后复制并粘贴以前的代码。
校正工具
也有自动工具可以检查和重写文本文件
(
sed
/awk
或recode
)。对于PHP,特别是
phptags
tag tidier。它将关闭和打开标签重写为长短形式,但也很容易
修复了开头和结尾的空格,Unicode和UTF-x BOM问题:
phptags --whitespace *.php
在整个包含目录或项目目录上使用都是理智的。
?>
后的空白如果错误源在后面提到
closing
?>
然后在这里写出一些空白或原始文本。
PHP结束标记此时不终止脚本执行
点。后面的任何文本/空格字符将被写为页面内容
仍然。
通常建议,尤其是对新手来说,后跟
?>
PHP关闭标签应省略。这避免了这些情况的一小部分。
(罪魁祸首通常是
include()d
脚本。)错误源提到为“第0行未知”
如果没有错误源,通常是PHP扩展名或php.ini设置
被具体化。
有时是
gzip
流编码设置or the
ob_gzhandler
。但也可以是任何双重加载的
extension=
模块生成隐式的PHP启动/警告消息。
前面的错误信息
如果另一个PHP语句或表达式导致警告消息或
注意被打印出来,这也算作过早的输出。
在这种情况下,您需要避免错误,
延迟语句的执行,或通过以下方式禁止显示该消息:
isset()
或@()
-当以后都不妨碍调试时。
没有错误讯息
如果根据
error_reporting
禁用了display_errors
或php.ini
,则不会显示警告。但是忽略错误并不能解决问题
远。标头过早输出后仍无法发送标头。
因此,当
header("Location: ...")
静默重定向失败时,建议探测警告。使用两个简单的命令重新启用它们
在调用脚本之上:
error_reporting(E_ALL);
ini_set("display_errors", 1);
或
set_error_handler("var_dump");
如果其他所有方法均失败。说到重定向头,您应该经常使用如下习惯用法:
这是最终的代码路径:
exit(header("Location: /finished.html"));
最好甚至是实用程序功能,它会打印用户消息
如果
header()
失败。解决方案是输出缓冲
PHP output buffering
是缓解此问题的解决方法。它通常可以可靠地工作,但不应该
替代适当的应用程序结构并将输出与控制分开
逻辑。其实际目的是最大程度地减少到Web服务器的分块传输。
output_buffering=
设置仍然可以提供帮助。
在php.ini中进行配置
或通过.htaccess
甚至是.user.ini
现代FPM / FastCGI设置。
启用它将允许PHP缓冲输出,而不是将其传递到Web服务器
即刻。因此,PHP可以聚合HTTP标头。
同样可以调用
ob_start();
在调用脚本之上。但是,由于多种原因,它的可靠性较差:
即使
<?php ob_start(); ?>
启动第一个脚本,空格或BOM表可能在rendering it ineffective之前被改组。
它可以隐藏用于HTML输出的空格。但是一旦申请
逻辑尝试发送二进制内容(例如,生成的图像),
缓冲的无关输出成为问题。 (必须
ob_clean()
作为进一步的解决方法。)
缓冲区的大小是有限的,当保留默认值时,缓冲区很容易溢出。
而且,difficult to track down也不罕见
当它发生的时候。
因此,两种方法都可能变得不可靠-特别是在
开发设置和/或生产服务器。这就是为什么输出缓冲是
被广泛认为只是拐杖/严格来说是一种解决方法。
另请参见basic usage example
在手册中,以及更多的利弊:
What is output buffering?
Why use output buffering in PHP?
Is using output buffering considered a bad practice?
Use case for output buffering as the correct solution to "headers already sent"
但是它在另一台服务器上工作了!
如果您之前未收到标头警告,则output buffering php.ini setting
已经改变。当前/新服务器上可能未配置它。
用
headers_sent()
检查您始终可以使用
headers_sent()
来检查是否仍然可以...发送标头。这对于有条件打印很有用
信息或应用其他后备逻辑。
if (headers_sent()) {
die("Redirect failed. Please click on this link: <a href=...>");
}
else{
exit(header("Location: /user.php"));
}
有用的后备解决方法是:
HTML
<meta>
标记如果您的应用程序在结构上难以修复,则很容易(但是
有点不专业的方法)允许重定向是注入HTML
<meta>
标记。重定向可以通过以下方式实现: <meta http-equiv="Location" content="http://example.com/">
或短暂延迟:
<meta http-equiv="Refresh" content="2; url=../target.html">
当通过
<head>
部分使用时,这将导致无效的HTML。大多数浏览器仍然接受它。
JavaScript重定向
作为替代JavaScript redirect
可以用于页面重定向:
<script> location.replace("target.html"); </script>
尽管这通常比
<meta>
解决方法更符合HTML规范,它会导致对具有JavaScript功能的客户端的依赖。
但是,当使用真正的HTTP标头()时,这两种方法都会产生可接受的回退
通话失败。理想情况下,您总是将其与用户友好的消息结合起来,
点击链接是最后的选择。 (例如http_redirect()
PECL扩展名可以。)
为什么
setcookie()
和session_start()
也受到影响setcookie()
和session_start()
都需要发送Set-Cookie:
HTTP标头。因此,适用相同的条件,并且将生成类似的错误消息
对于过早的输出情况。
(当然,它们还会受到浏览器中禁用Cookie的影响,
甚至代理问题。会话功能显然也取决于免费
磁盘空间和其他php.ini设置等)
其他连结
Google提供了lengthy list of similar discussions。
当然,many specific cases也已在堆栈溢出中讨论过。
WordPress常见问题解答以通用方式解释How do I solve the Headers already sent warning problem?。
Adobe社区:PHP development: why redirects don't work (headers already sent)
核常见问题解答:What does "page headers already sent" mean?
更为详尽的解释之一是HTTP Headers and the PHP header() Function - A tutorial by NicholasSolutions(Internet存档链接)。
它详细介绍了HTTP,并提供了一些重写脚本的准则。
关于php - 如何修复PHP中的“ header 已发送”错误,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/30176836/