utf-8 pages and php 4.1.1

Hi,

I'm running into a problem with php 4.1.1 on IIS (XP Pro version).
For example writing a page test.php that starts with

<?php session_start(); ?>
<?php echo '<?xml version="1.0"'; ?>
<?php echo ' encoding="utf-8" ?>'; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
....

and saving the test.php in UTF-8 format in UltraEdit-32 or SciTE,
then running the page, there's a complaint for session_start() about
headers/page data having already been sent. If the same page is
saved as "plain" ASCII, it works. Any ideas how to get an UTF-8
encoded page to work in php 4.1.1, without upgrading?

thanks,
- Jan

On Mon, 22 Aug 2005 15:35:48 +0300, Jan Wagner wrote:
[color=blue]
> I'm running into a problem with php 4.1.1 on IIS (XP Pro version).[/color]

Upgrade immediately!! Upgrade PHP, that is. Not for functionality
reasons; for security reasons. You have been warned.

--
JDS | jeffrey@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

JDS wrote:[color=blue]
> On Mon, 22 Aug 2005 15:35:48 +0300, Jan Wagner wrote:[color=green]
>>I'm running into a problem with php 4.1.1 on IIS (XP Pro version).[/color]
>
> Upgrade immediately!! Upgrade PHP, that is. Not for functionality
> reasons; for security reasons. You have been warned.[/color]

Unfortunately I'm not the admin, and upgrading to PHP 5.0.3 for
Novell might break some of the hosted sites. I'd have liked
Tomcat/JSP instead of a vulnerability ridden PHP interpreter anyway,
but Tomcat 4/5 won't run on NW5.

However, my devel machine I now upgraded 5.0.4, to check. Oddly I
still get the same session warnings for UTF-8 files:

Warning: session_start() [function.session-start]: Cannot send
session cookie - headers already sent by (output started at
c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php:1) in
c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php on line 1

Warning: session_start() [function.session-start]: Cannot send
session cache limiter - headers already sent (output started at
c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php:1) in
c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php on line 1

and the line 1 is <?php session_start(); ?>

When I convert the php to 8-bit ascii the warnings disappear.
Probably not a bug but a wrong setting somewhere? Or, other way
round, is anyone using UTF-8 encoded .php files and it is working
fine for them? Required changing something in php.ini?

- Jan

On Mon, 22 Aug 2005 19:16:48 +0300, Jan Wagner wrote:
[color=blue]
> Unfortunately I'm not the admin, and upgrading to PHP 5.0.3 for
> Novell might break some of the hosted sites. I'd have liked
> Tomcat/JSP instead of a vulnerability ridden PHP interpreter anyway,
> but Tomcat 4/5 won't run on NW5.[/color]

I didn't say upgrade to PHP5. Update to PHP 4.4. That should prevent
most breakages and improve security.

Unfortunately, I really don't have an answer regarding your UTF problems.
Sorry.

--
JDS | jeffrey@example.invalid
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

On Mon, 22 Aug 2005 15:35:48 +0300, Jan Wagner <no_spam@thanks.net> wrote:
[color=blue]
>I'm running into a problem with php 4.1.1 on IIS (XP Pro version).
>For example writing a page test.php that starts with
>
><?php session_start(); ?>
>
>and saving the test.php in UTF-8 format in UltraEdit-32 or SciTE,
>then running the page, there's a complaint for session_start() about
>headers/page data having already been sent. If the same page is
>saved as "plain" ASCII, it works. Any ideas how to get an UTF-8
>encoded page to work in php 4.1.1, without upgrading?[/color]

Odds are you have a UTF-8 BOM (Byte Order Marker) at the start of the script.

In Ultraedit:

Advanced, Configuration, General tab,
Scroll to "Load/Save Conversions"
Disable the two "Write UTF-8 BOM" options.

http://bugs.php.net/bug.php?id=22108 appears to indicate that UTF-8 encoded
PHP scripts with a leading BOM is basically not supported, for reasonable
reasons (it can't tell if it's a BOM to ignore, a BOM that should be sent, or
actually some binary data that happens to look like a BOM).

Since you can always save it without a BOM that's not too bad.

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

>However, my devel machine I now upgraded 5.0.4, to check. Oddly I[color=blue]
>still get the same session warnings for UTF-8 files:
>
>Warning: session_start() [function.session-start]: Cannot send
>session cookie - headers already sent by (output started at
>c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php:1) in
>c:\Inetpub\wwwroot\spraknat\Kultur-GDolivo-text.php on line 1[/color]

You may not output *ANYTHING* before the headers. Not
a blank line. Not a single space. Not a UTF-8 marker
that says it's UTF-8.
[color=blue]
>and the line 1 is <?php session_start(); ?>[/color]

And what's before the <? on line 1? Dump your file in hex
to be sure.

Gordon L. Burditt

JDS wrote:[color=blue]
> On Mon, 22 Aug 2005 19:16:48 +0300, Jan Wagner wrote:[color=green]
>>Unfortunately I'm not the admin, and upgrading to PHP 5.0.3 for
>>Novell might break some of the hosted sites. I'd have liked
>>Tomcat/JSP instead of a vulnerability ridden PHP interpreter anyway,
>>but Tomcat 4/5 won't run on NW5.[/color]
>
> I didn't say upgrade to PHP5. Update to PHP 4.4. That should prevent
> most breakages and improve security.[/color]

Ok thanks! I'll suggest it to the admin (although the newest php4
for netware is 4.2.3 and not 4.4.0, but I suppose that's still
better than 4.1.1 :)
[color=blue]
> Unfortunately, I really don't have an answer regarding your UTF problems.
> Sorry.[/color]

Found it myself after more digging... Bug #22108,
http://bugs.php.net/bug.php?id=22108, solution included in php 5 cvs
but not enabled per default in the win32 release. "This will come
with Unicode support in PHP 6.0". So looks like until then, no
unicode support in win32 (unless you recompile php5), and all code
and pages must remain "plain" ASCII. Apparently same thing for
netware. Well well...

thanks,
- Jan

(I did not refresh and see this before my prev posting...)

Andy Hassall wrote:[color=blue]
> On Mon, 22 Aug 2005 15:35:48 +0300, Jan Wagner <no_spam@thanks.net> wrote:
> Odds are you have a UTF-8 BOM (Byte Order Marker) at the start of the script.
>
> In Ultraedit:
>
> Advanced, Configuration, General tab,
> Scroll to "Load/Save Conversions"
> Disable the two "Write UTF-8 BOM" options.[/color]

Yes, that works! Good workaround - thanks! :)

- Jan

utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

re: utf-8 pages and php 4.1.1

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about