需要帮助解决Apache Windows VS Linux charset问题

Question

I'm not sure exactly how to correctly phrase this question, but here goes. Where I work at, our production server is a LAMP server (and we're planning on keeping it this way). However, all our workstations are Windows based.

The thing is that, because the two systems use different base charset, something that looks good locally will inevitably look scrambled in production as soon as accented characters are involved (unless, of course, we constantly run checks on PHP_OS).

So basically, what we're trying to do is have a setup that'll allow us to have the same output locally as on the production server. Can you like run an Apache server as Linux in Windows or something?

EDIT: I've tried a couple of things, all without success. The first thing I tried was adding the following to httpd.conf

AddDefaultCharset utf-8

Then I tried to edit the file charset.conv and putting the first entry as utf8 and it didn't do anything. Right now, the problem occurs when I try to access data from the database (which is in UTF8).

$sql = "SELECT DISTINCT  f.NoClient ,c.NomClient
        FROM flexgroup.tblfacturation f
            INNER JOIN flexgroup.tblclients c ON c.NoClient = f.NoClient
        WHERE f.NoAssureur = 2 ORDER BY c.NomClient";
    $stmt = $c -> prepare( $sql );

$stmt -> execute();
while($res = $stmt -> fetch(PDO::FETCH_ASSOC))
{
    echo "<option value=\"" . $res['NoClient'] . "\">" . $res['NomClient'] . "</option>
";
}

The above script will work out of the box in Linux, but in Windows, I have to wrap the output in a utf8_encode like so:

echo "<option value=\"" . $res['NoClient'] . "\">" . utf8_encode($res['NomClient']) . "</option>
";

Anyone has a suggestion?

Answer 1

Okay, so it turns out the answer really was in the httpd.conf after all. The only thing was that I wasn't adding the right charset. What I needed to add was the following line:

AddDefaultCharset UTF-16

What I think happens here is that the ODBC driver for Vertica detects on which OS its installed and converts what it receives into the charset it deems appropriate. This is why it worked in Linux where everything everywhere is just UTF-8.

In Windows however, the ODBC driver changes the strings' encoding into ISO-8859-1 before they even reach my application. Of course, my application thinks it's receiving UTF-8 data so the display ends up garbled because of the charset mismatch.

Okay, I furthered my research and was able to reach a much clearer understanding of what happened. I was right in thinking the driver detects on which platform it's installed. However, the charset it uses for Windows is actually UTF-16, not ISO-8859-1 as I originally thought. The reason for my confusion was that the two encoding intersect as far as numbers and letters are concerned. I also assumed because of their similar names, UTF-8 and UTF-16 were compatible... obviously they're not.

Anyway, I hope this helps someone in the future.

Osu