"PHP" A BOM header caused by the bloodshed ____php

The origin of the thing is a very common code:

<?php

session_start ();

$_session[' test ' = ' test ';

$_session[' name ' = ' name ';

$data = serialize ($_session);

... More subsequent code

?>

No problem, very simple section of the code that sets the session.

But after running the error:

Cannot send session cache Limiter-headers already sent (output started at ...) on line ...

The error message is clearly that there was an output before session_start (), causing the header to fail to send back.

Because in many cases the space before the <?php tag is also sent as the header, so check this first.

Check carefully, there is no space, no echo, no print and other problems caused the output, so what exactly is the problem.

There should be a lot of people thinking about that BOM header.

Yes, this is the BOM head of the ghost.

So what is the BOM header.

Bom:byte Order Mark
is a byte sequential label, similar to a tag, also called a signature, 

the BOM signature means to tell the editor what the current file encoding to facilitate the editor to identify, but the BOM although not displayed in the editor, but will produce output, It's like one more empty line.
a normal encoding set does not appear with a BOM header, and a Unicode encoding set appears.
Common BOM headers are: "Excerpt from: http://www.cnblogs.com/chengmo/archive/2010/10/30/1864004.html"

  UTF-8    ║ef BB BF 
  utf-16le║ff Fe (small tail)
  utf-16be║fe FF (da Mei)
  utf-32le║ff fe 
  utf-32be║00 F E FF

Why BOM header will produce garbled.

"Excerpt from: http://www.cnblogs.com/chengmo/archive/2010/10/30/1864004.html"

has a BOM header storage or byte stream, it must be a Unicode character set encoding. The one that belongs to (Utf-8 or utf-16 or utf-32) can be judged by the head.

as has already said Utf-16,utf-32 does not specify the BOM header, the parser defaults to consider is the ANSI code, appears garbled. The utf-8 specifies or does not specify that the program can determine the character set encoding that is known for. The

problem is here, the possible application (IE6 browser), it is believed that if the Utf-8 encoding, you do not need to specify the BOM header, it can be judged by itself, instead of specifying the BOM header, it will also have problems

(because of its head when the Utf-8 parsing appears garbled). Here is not a screenshot, cnblogs inside talk about this more, the present IE6 will appear problems. Other ie7+,firefox,chrome will not appear and will ignore the BOM header. The

Unified solution is: Save as Utf-8 encoding is, do not need to add BOM header, other utf-16,utf-32 join.

Knowing this, the solution is obvious: Remove the Utf-8 BOM head.

The way is file encoding format select Utf-8 No BOM.

Another excerpt from an online search to remove the BOM header code:

<?php if (isset ($_get[' dir ')) {//config The basedir $basedir =$_get[' dir '];

else{$basedir = '. ';}

$auto = 1;

Checkdir ($basedir);
            function Checkdir ($basedir) {if ($dh = Opendir ($basedir)) {while ($file = Readdir ($DH))!== false) { if ($file!= '. ' && $file!= ' ... ') {if (!is_dir ($basedir.) /". $file)) {echo" filename: $basedir/$file ". Checkbom (" $basedir/$file ")."
                <br> "; }else{$dirname = $basedir. "
                    /". $file;
                Checkdir ($dirname);
    }} closedir ($DH);
    } function Checkbom ($filename) {global$auto;
    $contents = file_get_contents ($filename);
    $charset [1] =substr ($contents, 0, 1);
    $charset [2] =substr ($contents, 1, 1);
    $charset [3] =substr ($contents, 2, 1); if (Ord ($charset [1]) = = 239 && ord ($charset [2]) = = 187 &&ord ($charset [3]) = = 191) {if ($auto = = 1) {$rest= substr ($contents, 3);
            Rewrite ($filename, $rest);
        Return ("<font Color=red>bom found,automatically removed.</font>");
        }else {return ("<font Color=red>bom found.</font>");
} elsereturn ("BOM not Found.");
    function rewrite ($filename, $data) {$filenum = fopen ($filename, "w");
    Flock ($filenum, LOCK_EX);
    Fwrite ($filenum, $data);
Fclose ($filenum); }?>

Another common BOM header is where the XML file is. Failure to parse is a big part of the reason.

Error on line 1 of the document:content is isn't allowed in Prolog. Nested Exception:content is isn't allowed in Prolog.

At this point just remove the BOM header on the line.

I hereby record it and hope to be of help to you. (2011-11-03 happyelements)