Кодировка (языковая)
Если Вы используете только UTF-8 - пропустите эту секцию.Все идущие на сервер параметры GET/POST, кроме случая multipart/form-data, кодируются в UTF-8. Не в кодировке страницы, а именно в UTF-8. Поэтому, например, в PHP их нужно при необходимости перекодировать функцией iconv.
// ajax.php
$name = iconv('UTF8','CP1251',$_GET['name']);С другой стороны, ответ с сервера браузер воспринимает именно в той кодировке, которая указана в заголовке ответа Content-Type. Т.е, опять же, в PHP, чтобы браузер воспринял ответ в windows-1251 и нормально отобразил данные на странице в windows-1251, нужно послать заголовок с кодировкой в php-коде, например так:
// ajax.php
header('Content-Type: text/plain; charset=windows-1251');
Или же, такой заголовок должен добавить сервер. Например, в apache автоматически добавляется кодировка опцией:# в конфиге апача
AddDefaultCharset windows-1251
Вот у мну, такое ощущение, что дело тут не в UTF-8, а в настройках сервера в формате ответа на Аякс запрос
Собственно вопрос приспичил с думой о более шустрой реализации прикрепления Первого Сообщения к теме. (Если посмотреть, есть еще Пару востребованных скриптов, которые портит именно отсутствие правильности в кодировке.
Т.е есть версия - что заголовок ответа UTF-8, а кодирование в windows-1251, или наоборот
браузер ожидает-воспринимает данные в соответствии с исходным кодом текущей страницы windows-1251, а сервер отсылает в UTF-8, без перекодировки русских символов( поскольку все не_латинские символы - отражаются одним и тем же кодом - символ �
Ps: (Периодически, изредка, - самый первый запрос, иногда получается в верной кодировке
Т.е нормальная реализация есть и возможна!
Вот, к примеру, в данном тесте(в Opere 11), был замечен такой эффект,
(*только на новой вкладке и только при первой загрузке, изредка,
id пользователя надо менять на каждой новой вкладке,т.к. страницы - кэшируетсяЗаказ новых скриптов пост №926
Отредактировано Deff (Ср, 19 Окт 2011 10:30:01)