Публикация специальных символов ajax [duplicate]

В дополнение к настройке default_charset в php.ini вы можете отправить правильную кодировку с помощью header() из вашего кода перед любым выходом:

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

Работа с Unicode в PHP легко, если вы понимаете, что большинство строковых функций не работают с Unicode, а некоторые могут полностью блокировать строки. PHP считает, что «символы» имеют длину 1 байт. Иногда это нормально (например, explode() ищет только последовательность байтов и использует его как разделитель - так что неважно, какие фактические персонажи вы ищете). Но в других случаях, когда функция фактически предназначена для работы с символами , PHP не знает, что ваш текст имеет многобайтовые символы, которые находятся в Unicode.

Хорошая библиотека для проверки есть phputf8 . Это перезаписывает все «плохие» функции, чтобы вы могли безопасно работать с строками UTF8. Существуют расширения, такие как расширение mbstring, которые тоже пытаются это сделать для вас, но я предпочитаю использовать библиотеку, потому что она более переносимая (но я пишу продукты массового рынка, так что это важно для меня). Но phputf8 может использовать mbstring за кулисами, во всяком случае, для повышения производительности.

Поддержка Unicode в PHP по-прежнему огромна. Хотя он способен преобразовывать строку ISO8859 (которая используется внутри нее) в utf8, ей не хватает возможности работать с строками unicode изначально, что означает, что все функции обработки строк будут искажать и повреждать ваши строки. Таким образом, вам нужно либо использовать отдельную библиотеку для правильной поддержки utf8, либо самостоятельно переписать все функции обработки строк.

. Легкая часть - это просто указать кодировку в заголовках HTTP и в базе данных и т. Д., Но нет что имеет значение, если ваш PHP-код не выводит допустимый UTF8. Это сложная часть, и PHP практически не помогает. (Я думаю, что PHP6 должен исправить худшее из этого, но это все еще вдалеке)

Главный ответ отличный. Вот что я должен был на обычной установке debian / php / mysql:

// storage
// debian. apparently already utf-8

// retrieval
// the mysql database was stored in utf-8, 
// but apparently php was requesting iso. this worked: 
// ***notice "utf8", without dash, this is a mysql encoding***
mysql_set_charset('utf8');

// delivery
// php.ini did not have a default charset, 
// (it was commented out, shared host) and
// no http encoding was specified in the apache headers.
// this made apache send out a utf-8 header
// (and perhaps made php actually send out utf-8)
// ***notice "utf-8", with dash, this is a php encoding***
ini_set('default_charset','utf-8');

// submission
// this worked in all major browsers once apache
// was sending out the utf-8 header. i didnt add
// the accept-charset attribute.

// processing
// changed a few commands in php, like substr,
// to mb_substr

, которая была всем!

Я хотел бы добавить одну вещь к отличному ответу chazomaticus :

Не забудьте также тег META (например, или HTML4 или XHTML-версия этого файла ):

<meta charset="utf-8">

Это кажется тривиальным, но IE7 дал мне проблемы с этим раньше.

Я делал все правильно; база данных, соединение с базой данных и HTTP-заголовок Content-Type были настроены на UTF-8, и она отлично работала во всех других браузерах, но Internet Explorer по-прежнему настаивал на использовании «западноевропейской» кодировки.

It оказалось, что на странице отсутствует метка META. Добавление этого решения проблемы.

Правка:

У W3C фактически есть довольно большой раздел , посвященный I18N . У них есть ряд статей, связанных с этой проблемой & ndash; описывая HTTP, (X) HTML и CSS сторону вещей:

• FAQ: Изменение (X) кодирования HTML-страницы в UTF-8
• Объявление символьных кодировок в HTML
• Учебное пособие: наборы символов и amp; кодировки в XHTML, HTML и CSS
• Настройка параметра charset HTTP

Они рекомендуют использовать как HTTP-заголовок, так и HTML метатег (или объявление XML в случае XHTML служил XML).

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

Предполагается, что у мистического PHP6 все это выпрямилось, правда?

Вы можете в значительной степени установить utf-8 в качестве глобальной кодировки по умолчанию для mysql на уровне сервера, и она по умолчанию будет правильно соответствовать более гранулированных уровней.

Я только что прошел ту же проблему и нашел хорошее решение в руководствах PHP.

Я изменил всю свою кодировку файла на UTF8, а затем по умолчанию на мое соединение. Это решило все проблемы.

if (!$mysqli->set_charset("utf8")) {
    printf("Error loading character set utf8: %s\n", $mysqli->error);
} else {
   printf("Current character set: %s\n", $mysqli->character_set_name());
}

Просмотреть источник

Старая тема, я знаю. Нашел проблему с кем-то, использующим PDO, и ответ заключался в том, чтобы использовать это для строки подключения PDO:

$pdo = new PDO(
    'mysql:host=mysql.example.com;dbname=example_db',
    "username",
    "password",
    array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));

Сайт, на котором я взял это, отключен, смог получить его с помощью кеша google.

В моем случае я использовал mb_split, который использует регулярное выражение. Поэтому мне также пришлось вручную убедиться, что кодировка регулярного выражения была utf-8, выполнив mb_regex_encoding('UTF-8');

. В качестве побочной заметки я также обнаружил, запустив mb_internal_encoding(), что внутренняя кодировка не была utf-8 , и я изменил это, выполнив mb_internal_encoding("UTF-8");.

В PHP вам нужно либо использовать функции multibyte , либо включить mbstring.func_overload . Таким образом, такие вещи, как strlen, будут работать, если у вас есть символы, которые принимают более одного байта.

Вам также потребуется определить набор символов ваших ответов. Вы можете использовать AddDefaultCharset, как указано выше, или написать PHP-код, который возвращает заголовок. (Или вы можете добавить тег META в свои HTML-документы.)

Недавно я обнаружил, что использование strtolower() может вызвать проблемы, когда данные усекаются после специального символа.

Решение заключалось в использовании

mb_strtolower($string, 'UTF-8');

mb_ использует MultiByte. Он поддерживает больше символов, но в целом немного медленнее.

Если вы хотите, чтобы сервер MySQL решал набор символов, а не PHP как клиент (старое поведение, предпочтительнее, на мой взгляд), попробуйте добавить skip-character-set-client-handshake к вашему my.cnf в [mysqld] и перезапустить mysql.

Это может вызвать проблемы, если вы используете что-либо, кроме UTF8.