UTF-8 работает на хостинге A, но не на хостинге B, что может быть причиной? - PullRequest
1 голос
/ 15 сентября 2011

У меня есть планы хостинга с двумя разными провайдерами, на провайдере A мой сайт работает без единой проблемы, но на провайдере B, независимо от того, что я делаю, UTF-8 никогда не работает.

Веб-сайт на обоих хостингах одинаков во всех аспектах, поэтому единственное отличие, которое мы имеем здесь, это сервер.

Если я просто создаю файл с указанным ниже содержимым в блокноте, сохраняя его в формате UTF-8:

<?php
header('content-type: text/html; charset: 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">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<?
    $var = "áéíóí";
    echo $var;
?>
<body>
<html> 

Отлично работает на хостинге A, но не показывает символы на хостинге B.

Я проверил оба файла php.ini, и оба они имеют одинаковую информацию.

Что еще я могу попробовать, изменить или попытаться заставить UTF-8 работать на хостинге B?

Из того, что я могу сказать, кажется, что полностью на стороне сервера отсутствует какая-то конфигурация или нет, в противном случае, почему один и тот же сайт будет работать на хосте А без единой проблемы?

CURL ответ хостинга B:

root@server:~# curl -v http://painel.xxxxxx.com/test.php
* About to connect() to painel.xxxxxx.com port 80 (#0)
*   Trying 10.0.0.2... connected
* Connected to painel.xxxxxx.com (10.0.0.2) port 80 (#0)
> GET /test.php HTTP/1.1
> User-Agent: curl/7.20.1 (i686-pc-linux-gnu) libcurl/7.20.1 OpenSSL/0.9.8n zlib/1.2.5 libidn/1.5
> Host: painel.xxxxxx.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 15 Sep 2011 11:55:33 GMT
< Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8n DAV/2 mod_python/3.3.1 Python/2.6.4 PHP/5.3.6 SVN/1.6.11 mod_fastcgi/2.4.6
< X-Powered-By: PHP/5.3.6
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=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">
<head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
áéíóíaed<body>
* Connection #0 to host painel.xxxxxx.com left intact
* Closing connection #0
<html>

FireBug, хостинг B с моего компьютера:

HTTP/1.1 200 OK
Date: Thu, 15 Sep 2011 12:06:21 GMT
Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8n DAV/2 mod_python/3.3.1 Python/2.6.4 PHP/5.3.6 SVN/1.6.11 mod_fastcgi/2.4.6
X-Powered-By: PHP/5.3.6
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Host    painel.xxxxxxx.com
User-Agent  Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip, deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection  keep-alive
Cookie  
Cache-Control   max-age=0

Пока пробовал:

  • изменена локаль операционной системы на en_US.UTF8
  • изменил кодировку по умолчанию на apache
  • установите для шафта utf-8 на php.ini
  • файлы сохраняются на UTF8
  • один и тот же файл тестируется на обоих планах хостинга и работает только на хостинге A.
  • в первой строке кода mb_internal_encoding("UTF-8");
  • в первой строке кода setlocale(LC_CTYPE, 'C');
  • 2 выше вместе
  • header('content-type: text/html; charset: utf-8'); и header('content-type: text/html; charset=utf-8');

Ответы [ 2 ]

2 голосов
/ 15 сентября 2011

Добавление следующей строки в файл php.ini и перезагрузка службы httpd сделали свое дело:

mbstring.internal_encoding=utf-8
2 голосов
/ 15 сентября 2011

Должно читаться:

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

Плюс, для вашего случая важны только две вещи - заголовок типа контента (если отсутствует соответствующий метатег) и фактическая кодировка, используемая в сущности,Забудь обо всем остальном.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...