PHP的插入内容之前的字符十六进制数 [英] php inserts HEX number of characters before the content

问题描述

我在移动网站到新的服务器。 （旧的服务器有PHP 5.3.2，新建一个具有PHP 5.5.9）
Centos的，阿帕奇的httpd / 2.2.26。

I'm moving a website to a new server. (Old server had php 5.3.2, the new one has php 5.5.9) Centos, httpd Apache/2.2.26.

我复制的文件，它工作正常，除了唯一奇怪的事情：
一些奇怪的十六进制数的网页内容之前插入：

I've copied files and it works fine except the only weird thing: some strange HEX number is inserted before the content of pages:

此外，在页面的底部， 0 是＆LT后插入; / HTML＆GT; 标记。

Also, in the bottom of the page, 0 is inserted after the </html> tag.

我注意到两件事情：

1）在我来说，只有两个头文件是由PHP脚本发送：

1) In my case only two headers are sent from php script:

header("HTTP/1.1 200 OK");
header("Status: 200");

如果我评论比这将是确定的第一个标题 - 不陌生号码

If I comment the first header than It will be ok - no strange numbers.

2）看起来，这个数字是页面（我已经检查了它）上的字符数。
而如果页面少于8000个字符，超过的数量没有出现，但如果页面有超过8001个字符 1F41 出现

2) It looks like that number is the number of characters on the page (I've checked it). And if the page is less then 8000 characters, than the number doesn't appear, but if page has 8001 characters than 1F41 appears

P.S。我被告知，从文件中删除所有的BOM。文件被确定 - 已经没有BOM。因此，这不是BOM。

P.S. I was advised to remove all BOM from files. Files were OK - already without BOM. So it's not about BOM.

UPD：
我做了一个非常简单的测试（的index.php）：

UPD: I made a very simple test (index.php):

<?php header("HTTP/1.1 200 OK"); ?>
Lorem Ipsum ... 8000 characters

一切正常。

<?php header("HTTP/1.1 200 OK"); ?>
Lorem Ipsum ... 8001 characters

错误发生 1f41 Lorem存有前。

推荐答案

这是不是PHP也不是BOM。你有内容传输编码的问题。

This is not PHP nor a BOM. You have a problem with Content-Transfer-Encoding.

服务器沿一个分块编码发送（这通常是当的Content-Length 不可用），客户端显然不知道如何处理，的或的了头相结合，使客户相信，它可以绕过dechunking。

The server is sending along a Chunked encoding (this is usually done when the Content-Length is unavailable) which the client apparently doesn't know how to handle, or the header combination makes the client believe that it can bypass dechunking.

因此​​，究竟是下一个块的长度获取客户端PTED间$ P $，你可以看到它作为一个十六进制位之前的内容：

Therefore, what is actually the "length of next chunk" gets interpreted by the client, and you see it as a hex bit before the content:

05
These
05
 Are 
03
the
1F
 first characters of the senten
03
ce.

而不是

Content-Length: 48
These are the first characters of the sentence.

（我计算了眼睛的长度，他们可能错了的）

可能的原因是，你有某种的缓存它与内容编码干扰的。如果一切都留在缓冲区内，一切都很好，内容长度是可用的，被发送和鲍勃的你的叔叔。但是，如果你发送超过8000字节的缓冲区越多，缓冲区将刷新和一些不良反应。试着找zlib的输出缓冲的文档中，你可能在的php.ini 之间有什么阿帕奇确实有些冲突做什么PHP。

The likely cause is that you have some kind of buffering which interferes with Content Encoding. If everything stays in the buffer, all well and good, a Content-Length is available, gets sent and Bob's your uncle. But if you send more than the 8000 bytes of the buffer, the buffer is flushed and something untoward happens. Try looking in the documentation for zlib and output buffering, you might have some conflict in php.ini between what Apache does and what PHP does.

这是准确显示8000是如何（是？）在Apache中的某些部分使用的缓冲区大小相关链接：

Interesting links that show how exactly 8000 is (was?) a buffer size used in some portions of apache:

https://bugs.php.net/bug.php?id=45945

<一个href=\"http://serverfault.com/questions/366996/how-can-the-apache-2-2-deflate-module-length-limit-be-increased\">http://serverfault.com/questions/366996/how-can-the-apache-2-2-deflate-module-length-limit-be-increased

这最后一个环节，提出我建议你尝试检查zlib的，mod_gzip的，ob_gzhandler和/或mod_deflate模块是否启用，并且可能相互冲突的，或者尝试更换一个其他的。

This last link suggests me to suggest you to try checking whether zlib, mod_gzip, ob_gzhandler and/or mod_deflate are enabled, and possibly conflicting, or to try exchanging the one for the other.

添加适当Transfer-Encoding头解决了这个问题。

Adding the appropriate Transfer-Encoding header fixes the problem.

那么确实的事？我们知道，输出正确分块恩codeD（即分块的本身的是正确的），并且被告知后，客户能够跨preT它。那么，缺少的是单纯的被分块内容的知识的，它看起来荒谬的，一个好一点的车：无论什么分块内容必须知道它会得到分块（ D'哦！），所以也只好加入适当的标题的责任的，但它并没有的（或没有，但别的东西的剥的话），直到OP整流用手工添加页眉自己的情况。

So what really happened? We know that the output was correctly chunked-encoded (i.e. the chunking itself was correct), and the client was able to interpret it after being told to. So what was missing was simply the knowledge of the content being chunked, which looks absurd and a good bit buggy: for whatever chunked the content had to know it would get chunked (d'oh!), so it had responsibility of adding the appropriate header, and yet it did not (or it did, but something else stripped it), until the OP rectified the situation adding a header himself by hand.

问题现在已经解决了，但我认为必须有仍然在工作流程中的某个地方挥之不去的错误，无论是在模块，应用程序，或者在报头是如何处理的。

The problem is now solved, but I think there must be still a bug lingering somewhere in the workflow, either in the modules, the application, or in how the headers are processed.

这篇关于PHP的插入内容之前的字符十六进制数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！