Bug #78043 [Opn->Dup]: UTF-8 BOM is carried from an included file into a Header Content
| From: | requinix@php.net | Date: | Mon, 20 May 2019 17:27:42 +0000 |
| Subject: | Bug #78043 [Opn->Dup]: UTF-8 BOM is carried from an included file into a Header Content | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-220923@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=78043&edit=1
ID: 78043
Updated by: requinix@php.net
Reported by: barryd dot it at gmail dot com
Summary: UTF-8 BOM is carried from an included file into a
Header Content
-Status: Open
+Status: Duplicate
Type: Bug
Package: *Unicode Issues
Operating System: Windows
PHP Version: 7.2.18
Block user comment: N
Private report: N
New Comment:
Note that the UTF-8 spec does not recommend using a BOM in the first place.
Duplicate because the issue of PHP recognizing file encodings, especially BOMs, has been raised many
times before. And simply discarding it is not proper.
Previous Comments:
------------------------------------------------------------------------
[2019-05-20 17:26:49] spam2 at rhsoft dot net
the BOM is *before* <?php and so sent to the client
after that you can't no longer send headers
don't create files with a BOM - it's that easy
------------------------------------------------------------------------
[2019-05-20 17:23:50] barryd dot it at gmail dot com
Description:
------------
I included a file into my script, and soon found that since that file was a UTF-8 encoded file which
means that at the beginning of the file, is a UTF-8 BOM code sitting just before the ...<?php
?> tags, and that the information which is sent with Content-Disposition: attachment;, and no
matter what my Content-Type: application/rtf; charset=iso-8859-1//TRANSLIT says, the downloaded
content turned out to be UTF-8 instead of ANSI. The string itself was entirely ASCII. What needs to
be changed is that BOM code needs to be filtered out of the content, thus ensuring that the
content-type can be honored. In order to recreate this scenario, simply change the include.php
files' encoding to UTF-8, and use the code mentioned below. And once you save the file sent
from the web server to you system, you to will find that the content is UTF-8.
Test script:
---------------
<?php
include_once('include.php');
$rtf = 'Testing';
header('Content-Type: application/rtf; charset=iso-8859-1//TRANSLIT');
header('Content-Disposition: attachment; filename="' . '10-Jane-Doe' .
'.rtf"');
header('Content-Length: ' . strlen($rtf));
header('Expires: Fri, 01 Jan 2010 05:00:00 GMT');
header('Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT');
header('Cache-Control: private, must-revalidate');
header('Pragma: no-cache');
ob_start();
echo $rtf;
ob_end_flush();
exit();
?>
Expected result:
----------------
I would expect the web server to honor the Content-Type of the string and the web browser honor the
Encoding of file being downloaded, and not have php push content not part of the string into the
output buffer.
Testing
Actual result:
--------------
â©ââTesting is being downloaded into the rtf file, thus causing the file to be UTF-8,
and then causing the file not to rendered properly with LibreOffice.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=78043&edit=1