php-i18n Digest 21 Nov 2004 18:51:03 -0000 Issue 262

Topics (messages 801 through 807):

Re: Accented characters
        801 by: steve
        802 by: M Saleh EG
        803 by: steve
        804 by: David Powers
        805 by: steve
        806 by: steve
        807 by: David Powers

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------
--- Begin Message ---
Tex Texin wrote:

> The precedence rule that browsers are supposed to follow is that if the
> server sets the charset in the http (transmission) protocol, then that
> should be used.
> If http is not set, then the meta html statement is followed.
> So if after changing the meta statement the browser still insists on
> defaulting to 8859-1,
> Then probably your server is sending the page with http declaring ISO
> 8859-1.
> 
> Depending on your apache version, there was a bug in apache a short while
> back, where it set the http charset to iso 8859-1, when it shouldn't set
> any charset.
> 
> You might try saving the page locally and then opening it with a browser.
> Opening it as a local file will eliminate http as a variable.

This is where I'm getting confused. I guess I need to find out how the
shared hosting company has its Apache configured (just fired off a support
email). Ignoring the new version of the site for a moment, the existing
version has no problems when run on the shared hosting (though the meta
statement is set to iso-8859-1) but does have a problem when run on my
local system - exactly the same page using exactly the same MySQL data. So
it's got to be an Apache config issue, no? Sounds like maybe the shared
hosting has Apache set to utf-8.

All the accented chars that are giving me problems are in data stored in
MySQL tables, so I can't just open a page as a file with the browser - it
needs to go via PHP.

Appreciate you taking your time with this, BTW.

-- 
@+
Steve

--- End Message ---
--- Begin Message ---
Tex meant save the page via ur browser. That is open a page by dialing
it's address from ur browser and then save a static version of it on
ur harddisk somwhere else. And then open the HTML file that you saved.
Not the active, live version on the server. Then the Server charset
and encoding setting will not be taken as the ones to use for the
browser. Check it out.


On Fri, 19 Nov 2004 13:29:05 +0100, steve <[EMAIL PROTECTED]> wrote:
> Tex Texin wrote:
> 
> 
> 
> > The precedence rule that browsers are supposed to follow is that if the
> > server sets the charset in the http (transmission) protocol, then that
> > should be used.
> > If http is not set, then the meta html statement is followed.
> > So if after changing the meta statement the browser still insists on
> > defaulting to 8859-1,
> > Then probably your server is sending the page with http declaring ISO
> > 8859-1.
> >
> > Depending on your apache version, there was a bug in apache a short while
> > back, where it set the http charset to iso 8859-1, when it shouldn't set
> > any charset.
> >
> > You might try saving the page locally and then opening it with a browser.
> > Opening it as a local file will eliminate http as a variable.
> 
> This is where I'm getting confused. I guess I need to find out how the
> shared hosting company has its Apache configured (just fired off a support
> email). Ignoring the new version of the site for a moment, the existing
> version has no problems when run on the shared hosting (though the meta
> statement is set to iso-8859-1) but does have a problem when run on my
> local system - exactly the same page using exactly the same MySQL data. So
> it's got to be an Apache config issue, no? Sounds like maybe the shared
> hosting has Apache set to utf-8.
> 
> All the accented chars that are giving me problems are in data stored in
> MySQL tables, so I can't just open a page as a file with the browser - it
> needs to go via PHP.
> 
> Appreciate you taking your time with this, BTW.
> 
> 
> 
> --
> @+
> Steve
> 
> --
> PHP Internationalization Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


-- 
M.Saleh.E.G
97150-4779817

--- End Message ---
--- Begin Message ---
M Saleh Eg wrote:

> Tex meant save the page via ur browser. That is open a page by dialing
> it's address from ur browser and then save a static version of it on
> ur harddisk somwhere else. And then open the HTML file that you saved.
> Not the active, live version on the server. Then the Server charset
> and encoding setting will not be taken as the ones to use for the
> browser. Check it out.

Yeah, Tex has been in contact via email and is, rather generously, helping
me with this.

I reset the config of Apache on my local system to utf-8 and that sorted the
problem. So it looks as though the shared hosting service might also have
utf-8 set - which would surprise me because Apache defaults to iso-8859-1
and the hosting firm has opted for defaults in most cases. But before I
waste too much of Tex's (or anyone else's) time, I think I'll wait for a
response from the tech support guys as to how their Apache server is
configured. Meanwhile, I'll hack through the pages of the site and change
the meta statements to utf-8 in case there's nothing set in Apache.

-- 
@+
Steve

--- End Message ---
--- Begin Message ---
steve wrote:
>  So it looks as though the shared hosting service
> might also have utf-8 set - which would surprise me because Apache
> defaults to iso-8859-1 and the hosting firm has opted for defaults in
> most cases.

Apache 2 defaults to utf-8.
--
David Powers
*******************************************
Co-author, "PHP Web Development with Dreamweaver MX 2004" (Apress)
http://computerbookshelf.com/phpdw.php

--- End Message ---
--- Begin Message ---
David Powers wrote:

> steve wrote:
>>  So it looks as though the shared hosting service
>> might also have utf-8 set - which would surprise me because Apache
>> defaults to iso-8859-1 and the hosting firm has opted for defaults in
>> most cases.
> 
> Apache 2 defaults to utf-8.

The shared hosting server is Apache 1.3.

Apache 2 is also somewhat confusing in the mod_mime-defaults.conf file
which, as it came installed on the SuSE distro, strongly suggests the
default is iso-8859-1.

I've now determined that the shared host MySQL server is using latin1 (I
managed to ssh into it and used myisamchk). My local MySQL server is the
same. I dumped the db table from the live server and uploaded it to my
local one just to double-check I'm using the same data. Using the same
browser, the accents work fine viewing the page delivered by my local
server as utf-8, but are buggered when delivered as iso-8859-1 (ie, when I
change the Apache AddDefaultCharset setting). From the shared host server,
it's the other way around - the accents are fine when the page is viewed as
iso-8859-1 - don't work as utf-8.

Unfortunately, the hosting company's first response to me question about
what encoding is used on their Apache set-up was little better than 'huh?'.
So I've fired off a somewhat more detailed query.

-- 
@+
Steve

--- End Message ---
--- Begin Message ---
Okay. I'll make a last bid for help on this because, while people here have
been very patient and helpful, this actually isn't PHP-related.

To summarise: I have a page which has encoding set to iso-8859-1 in a meta
statement. This shows some text, pulled from a MySQL database, containing
accented characters. The MySQL table and the data it contains are identical
on both the live system (on shared hosting) and my local system. In both
cases, the MySQL server is set to use latin1.

I've just heard from the shared hosting company that its Apache 1.3 server
is set so that it has no default charset. The list of supported charsets
includes utf-8, but not specifically iso-8859-1 (ISO-8859-8, ISO-2022-JP,
ISO-2022-KR, ISO-8859-2, Big5, WINDOWS-1251, CP866, ISO-8859-5, KOI8-R,
UCS-2, UCS-4, UTF-8).

To make a comparison, I configured my local Apache 2 server the same way.

When I view the live page (www.webvivant.com/market/index.php), it renders
the characters correctly when viewed as iso-8859-1 (which is what the
browser defaults to as per the meta statement). It does not render
correctly when viewed as utf-8.

When I view the same page locally, it also comes down as iso-8859-1, but the
characters do not render correctly - instead each accented char appears as
two characters. When I switch the browser to utf-8, it renders correctly.

Huh?

-- 
@+
Steve

--- End Message ---
--- Begin Message ---
steve wrote:
> When I view the same page locally, it also comes down as iso-8859-1,
> but the characters do not render correctly - instead each accented
> char appears as two characters. When I switch the browser to utf-8,
> it renders correctly.

Try this right at the top of the page before any headers are sent, and
remove the charset metatag from the document <head>:

<?php header('Content-Type: text/html; charset=utf-8'); ?>

--
David Powers
*******************************************
Co-author, "PHP Web Development with Dreamweaver MX 2004" (Apress)
http://computerbookshelf.com/phpdw.php

--- End Message ---

Reply via email to