У меня есть веб-сервер с сотней приложений, разработанных на PHP 5.2.3, Apache 2.2.4, MySQL 5.0.37 (базы данных с utf8_general_ci
набор символов).
Я установил новую машину, на которую я буду портировать веб-сервер с PHP 5.5.12 (default_charset = UTF-8), Apache 2.4.9 (html head with content="text/html; charset=utf-8"
, MySQL 5.6.17 (тестовая база данных с utf8_general_ci
набор символов).
В сценариях PHP я использовал много раз htmlentities
функционировать в форме, как htmlentities ($ Var) (конечно, не лучший способ, но я был новичком), в котором $ var — это текст, извлеченный из MySQL и содержащий специальные символы, такие как «è» (когда я сохраняю в dbase, я использую set var = _utf8’è ‘).
Проблема в том, что на новом сервере htmlentities
функция ничего не возвращает (тот же код на старом сервере возвращает правильный è
).
После некоторого поиска в Google я нашел решение, которое переписать вызов как htmlentities (utf8_encode ($ Var)), но вы знаете, чтобы исправить сотню приложений …
Существует решение (с переменными .ini, модификацией кодировки базы данных и т. П.) Для поддержания «старой» функциональности htmlentities
функционировать?
mysql_set_charset
вызывается при подключении к БД (обычная функция).
Но проблема все еще остается для общего преобразования. Например, если я хочу напечатать символ евро, и я хочу использовать htmlentities
Функция вместо того, чтобы запомнить HTML-код.
В качестве другого примечания, если я использую htmlentities («è», ENT_QUOTES, ‘UTF-8’), результат будет ничем, если я использую htmlentities («è», ENT_QUOTES, ‘ISO-8859-1’) или htmlentities («è» , ENT_QUOTES, ») результат правильный.
PS:
Проблема та же, если я передаю строку со специальным символом, таким как «abcdè».
[РЕДАКТИРОВАТЬ] Я нашел решение для той же проблемы в соединении ODBC:Задача ещё не решена.
Других решений пока нет …