Forum Moderators: coopster
I'm trying to "include" a PHP variable into my page.
At the very top of my document, I have the following:
<?php $lang="en"; include("../admin/var.txt");?>
...
Later in my document, I call the variable:
<p><?php echo $link;?></p>
The complete .txt file looks like this:
<?php
$href[en]="A";
$anchor[en]="B";
...
$link="<a href=\"/".$href[$lang]."/\">".$anchor[$lang]."</a>";
?>
Works great, except when trying to set a variable using non-ASCII characters.
I have tried saving the .txt file as ANSI (characters show as boxes - I knew this one wasn't going to work, but I still tested it for comparission), Unicode and Unicode Big Endian (both inserted the complete txt file into the page at the PHP include line with messed up characters), and UTF-8 (which loads the text properly, but inserts a blank space at the include statement -- messing up layout.) UTF-8 works great in FF, but mess up the layout in IE.
It looks like UTF-8 is the way to go, but I can't seem to figure out this bug? Nor can I find any support information online.
Tested and failed in IE6 and IE7.
Any ideas?
create two files.
index.php
and test.php
Contents of index.php (encoded as UTF-8)
--------------------------------
<?php include("test.php");?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>test</title>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
</head>
<body>
<h1>Test</h1>
<p><?php echo $text1;?></p>
<p><?php echo $text2;?></p>
</body>
</html>
--------------------------------
Contents of test.php (variable encoding: see below)
--------------------------------
<?php
$text1="English";
$text2="Français";
?>
--------------------------------
In Internet Explorer, depending on how you encode test.php, the following will happen:
ANSI: Layout is fine but non ASCII characters are messed up.
Unicode: All of test.php will be inserted into the head of the document as normal text, not PHP. The echo lines of PHP will not function. Non ASCII characters are messed up.
Unicode Big Endian: Same as Unicode.
UTF-8: The contents of the page is moved down, but the ASCII characters are showing properly.
What should I do?
Is any body else getting this?
- Does the server add a default charset via a HTTP header that is overriding the charset defined in the meta element?
- Do you have a byte-order mark (BOM) present in either file?
- What editor are you using?
I'm using Windows XP Notepad to create the files from scratch, and used Dreamweaver to FTP the files.
I use PHP 5.1.4 and Apache 1.3.33.
To the best of my knowledge there is no server default charset, but how could I test?
Also, I am not aware of a byte-order mark in either file, is there a way to test?
Out of curiosity, with both files made using UTF-8, does the H1 tag stay at the same place, or different place if you remove the <?php include("test.php");?> from the top of the document. For me, its lowered if there is the include statement.
Thanks
As for the shifting content, does the include mean that the doctype is no longer on the first line (ie. preceeded by a BOM, white-space, carriage return or other character)? If so, you may be seeing the IE6 bug which makes the browser switch to quirks mode rather than standards-compliance mode when the doctype is not on the very first line of the document. This behaviour should be fixed in IE7, but in reality it may well still exist if the content preceeding the doctype is not a comment or XML prolog.
It was driving me crazy!
Normally I use Dreamweaver to create my files, but it never seemed to handel UTF-8 right, so I opted to use Notepad where I can choose which type of encoding I wanted.
So when I found out Notepad has troubles with UTF-8, I dug deeper into Dreamweaver to see if I can make properly encoded files, and I found out I can.
My script looks great now, and since the problem only appeared in IE (both 6 AND 7), it does look like it might be related to IE going into quirks mode like you suggested.
Thanks again!