script session not being initiated, corrupt encoding?

schwim

Hi there everyone,

Someone installed a script that I wrote that uses a session to pass some variables but when run, nothing's getting passed. They provided me a url to look at and I noticed that before any html is generated, it's printing this:

ï»¿ï»¿

I've seen this before, but can't remember why. I might suspect doc encoding, but it's happening prior to any HTML being printed.

They're on a Godaddy shared server, and I've installed the script on their servers before without issue.

Any thoughts on what might cause this to happen would be welcome.

thanks,
json

schwim

I found this leading me to believe that it's the script being saved in UTF-8 encoding that's causing the issue.

I thought UTF-8 was the best option allowing all text to display properly. Do you guys save in ansi format or is there a way to resolve this while keeping the encoding?

johanafm

Isn't that the BOM (which always comes before the php opening tag...)? In general I save my files as utf-8 (without BOM) if I have any non ansi characters in it, and there is never a problem with that.

Saving files as utf-8 with BOM is always a bad idea though. I'd try resaving that file using utf-8 without BOM and see what happens.

schwim

Hi there Johan and thanks very much for the reply.

Being ignorant of what BOM is, I googled it and thought the fix would simply be a setting in my configuration, but using Gedit in linux, I can't see anything regarding disabling BoM. Is this something that I need to alter, or is it simply something that I'm doing while coding?

I know this question makes me look like a moron, but I can't quite figure out what's causing the character. Thanks for the help you've already provided.

PS: the person having the problem with the script simply saved the file in notepad in ascii format, resolving his issue.

johanafm

Iirc, Byte Order Mark has no actual meaning for UTF-8, whereas for UTF-16, it's necessary to know in what order bytes are stored. So I don't know why there even is one for utf-8, but the way it works is that the BOM is placed at the very beginning of a file. In the case of utf-8, I believe it's 0xFF 0xFE.
Since the file starts with that if you save using BOM, the PHP parser finds that the file starts with something other than <?php and simply sends the FF FE bytes to output, thus screwing with the ability to send headers etc.

Some text editors lets you specify to save utf-8/16 with or without BOM, others simply save without it and yet others (most commonly windows editors) save with it.

If you need the file to be in utf-8 and have no option of saving without BOM, you could create a php script which checks if the first two bytes are FF FE and if so, strip them from the file. That way, you end up with a file in utf-8 without BOM.

But before you do that, double check on wikipedia what the actual byte sequence is. I wouldn't personally trust my memory on this one 😉

schwim

Thanks again Johan, I'll look at Wikipedia. One more question if I could:

I wrote the script with the intention that it could be used by anyone, anywhere. I thought UTF-8 would be the way to go to achieve this. However, other than the language files, there are no special characters in the script. In my situation, should I be saving everything as ascii and only language files that include the characters should be saved as UTF-8?

It seems so confusing to me because you have a format that the file is saved under, then a format in which the browser is to read it and I think my ignorance on how to use these formats properly is messing up the process, causing this issue.

thanks,
json

johanafm

Well, if there is a BOM, then there is nothing you can do other than save it without BOM. The problem arises in the PHP parser which finds characters not inside php tags and thus outputs them right away.

But you are correct in that only files containing non-ascii characters need to be saved as utf-8 (or whatever format is appropriate). If you have PHP code that contains only ascii, but is used to get utf-8 characters from other files, the PHP code can safely be saved as ISO-8859-1.

Other than that, all you need to do is set an appropriate header

header('Content-type: text/html; charset=utf-8');

Weedpacket

johanafm wrote:
So I don't know why there even is one for utf-8, but the way it works is that the BOM is placed at the very beginning of a file. In the case of utf-8, I believe it's 0xFF 0xFE.

It's allowed to be there because conversions from UTF-16 etc. to UTF-8 aren't allowed to discard characters. So any application reading UTF-8 should anticipate the possible presence of a BOM at the start of a document.

The problem when it comes to PHP is that if you have multiple inclusions then those BOMs will appear in the output document at the points where the included files were - um - included, and not just at the start. (PHP can't remove them from included files because for all it knows they're supposed to be there.)

the PHP code can safely be saved as ISO-8859-1.

If it only contains ASCII then it could be safely saved as ASCII 🙂. ISO-8859-1 covers a wider range (ASCII is a subset of both ISO-8859-1 and UTF-8, but ISO-8859-1 is not a subset of UTF-8).