作者:Zhengweiwei313 | 来源:互联网 | 2013-08-14 11:41
开始以为是因为内容中间包含中文字符,因此可能是encoding方面的问题。但是无论encoding从utf-8改为gb2312还是iso之类,都没有任何改变,甚至更糟:中文成了乱码。在办公室的电脑测试,发现全部为英文也有这种错误
错误一:
Fatal error: “Uncaught exception 'Zend_Controller_Response_Exception' with message 'Cannot send headers; ”或者“You must call … before any output has been sent to the browser; output started in …”
解决方案:
修改php.ini的参数配置项
output_buffering off 修改为output_buffering on
其他的方法:
把controller层里面的最后的 “?>”去掉就ok了
不知道你的问题有没有解决,希望你没有应为这个放弃ZF。最近我也遇到同样的问题,找了半天原因,其实是utf-8的问题。解决方法,将所有相关文件保存成UTF8无BOM格式就行了。
分析原因:
根据我的经验,我根据你在redirect之前是不是有echo的输出了?在redirect之前请不要有任何的输出!
看看官方说法:
如果你看到错误信息,"Cannot modify header information – headers already sent" 或者 "You must call … before any output has been sent to the browser; output started in …",那么仔细检查最近的和这信息有关联的原因(函数或方法)。任何请求发送HTTP头的动作,象发送一个COOKIE,必须在发送正常的输出(非缓冲输出)之前完成,除非使用PHP的输出缓冲。
经常使用output buffering就能足够防止这个问题,并帮助提高性能。例如,在php.ini里,"output_buffering = 65535"允许有64K的缓冲。即使输出缓冲在生产服务器上提高性能是一个良好的策略,仅仅依靠缓冲来解决"headers already sent"还是不够。应用程序一定不能超过缓冲的大小,否则无论什么时候输出发送(先于HTTP头)超过缓冲的大小,问题就会发生。
作为选择,尝试重新安排应用程序逻辑,这样先于发送任何输出,动作处理头被执行。
如果一个Zend_Session方法导致这个错误信息,仔细检查这个方法,并确保它的使用在应用程序中是必须的。例如,destroy() 缺省的用法也发送HTTP头来使客户端的会话COOKIE过期。如果这不是必须的,那么使用destroy(false),因为设置COOKIE的指令和HTTP头一起发送。
作为选择,尝试重新安排应用程序逻辑,这样先于发送任何输出,动作处理头被执行。
删除任何结束"?>"标记,如果它们出现在PHP源文件的末尾。它们是必须的,并且新行和其它在结束标记之后的最近的可见的空白字符可以触发输出给客户。
错误二:
Uncaught exception 'Zend_Db_Table_Row_Exception' with message 'Specified column "user_name" is not in the row'。
解决办法
注意字段大小写是否与数据库里一致,尽量保持一致。
分析原因
Zend的fetchAll查询出来的是一个Zend_Db_Table_Rowset,每一条RowSet是与数据库中的字段相对应的。它并没有将其完全封装成一个类似于Hibernate的Pojo。
错误三:
Zend生成的XML不能被解析。也就是在Ajax里面会产生错误。
解决方案
ob_end_clean();
header("Content-Type: text/xml");
如果还不行就在前面再加一条:
ob_end_flush();
ob_end_clean();
header("Content-Type: text/xml");
分析原因
仔细分析发现Zend Framework不知道在哪里提前输出了一些空格内容。
开始以为是因为内容中间包含中文字符,因此可能是encoding方面的问题。但是无论encoding从utf-8改为gb2312还是iso之类,都没有任何改变,甚至更糟:中文成了乱码。在办公室的电脑测试,发现全部为英文也有这种错误。
ob_end_clean()是出掉客户端缓冲,ob_end_flush()前面一个是刷新缓冲。这个空格估计是由于缓冲产生的。