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

На самом деле это секрет. Для многих секрет. И многие не понимают почему это так.
Внутреннее представление строк (и регулярных выражений) в JavaScript для всех не-ASCII последовательностей как раз UTF-8.
Отсюда и проистекает т.н. “проблема” – если кодировка не указана явно и используется нелатиница, она будет интерпретирована как utf-8 последовательность.

Update 29.11 Свежий воздух и Давид Мзареулян остудили пыл, поэтому спешу уточнить о чём именно будет идти речь ниже.
Итак – у вас есть некий ресурс в однобайтовой кодировке (к гадалке не ходи это будет windows-1251) и вы озаботились освоить новый buzzword по имени AJAX. Немного почитав, вы делаете первые робкие шаги в этом направлении и тут же наступаете на “детские грабли”, а затем, немного отдышавшись, мчитесь на форумы с криком о помощи. И вам эту помощь окажут – переделай мол, свой ресурс на utf-8… Конечно-конечно скажете вы и пойдёте переделывать…
Я же хочу остеречь от таких опрометчивых шагов.

Cтандартное решение, которое наперебой советуют все – “используй utf-8 и нет проблем”.

И советчики правы – проблем действительно не будет.

Просто трафик увеличится “вдвое”. Те же данные, тот же результат, а трафика “в два раза” больше. Ага?

Что вы там говорите насчёт порошка?!?

Если вам этот фактор кажется мало***щим, то на этом чтение надо прекратить и начать переделывать свой проект на использование UTF-X,
остальным же оставлю несколько рецептов, которые помогут избежать проблем при использовании однобайтовых кодировок в т.н. AJAX-приложениях:

• Первое, оно же главное – ВСЕГДА указывайте кодировку контента. В любом ответе сервера с текстовым контентом обязан быть заголовок Content-Type: your/type; charset=your-charset.
  Дешевле всего это сделать, настроив сервер (например в php через default_charset)
• Указывайте charset при включении javascript в тело документа (<script type="text/javascript" charset="your-charset"> )
• Указывайте ПРАВИЛЬНЫЙ charset
  

  предварительно установив соответствующий заголовок – “Content-Type: text/html; charset=cp1251″

  В данном конкретном взятом за жопу случае fxposter сам себе злобный буратина.

  Any registered IANA charset may be used, but UTF-8 is preferred.

  Ну нету среди any registered кодировки с названием cp1251…

Для полноты картины приведу пару проблемных моментов, с которыми столкнуться прийдётся:

• Не позволяйте AJAX-ответам, которые содержат “нелатиницу” оставаться в кеше браузера (при 304 Not Modified ответ поднимется из кеша, но в качестве charset “некоторые браузеры” используют utf-8)

• JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

  Этим правилом НАГЛО пользуются производители различных библиотек для json_[en|de]code, но браузерам (как мы выяснили ранее) главное кодировку указать, а там всё разрулится.
  Отсюда и “проблема” – кодировать данные в JSON нужно вручную, распространнёные библиотечные функции на входе ожидают utf-8.

Мораль сей басни я жду от вас в комментариях.

Моя задача состояла в следующем – на ресурсах-сателитах необходимо разместить сложную форму. “Сложность” формы заключается в том, что данные подгружаются с главного ресурса и не могут быть загружены единовременно(при загрузке ресурса) или доставлены на ресурс-сателит заранее (так-так данных очень много и они достаточно быстро устаревают). Всевозможные API для доступа к информации основного ресурса в настоящий момент разрабатывать нецелесообразно, поэтому было решено для сателитов предоставлять некий готовый комплекс (аля plug-n-play).

Ещё до начала разработки я тщательно изучил уже имеющиеся механизмы для межсайтового обмена данными. Первым и самым перспективным был вариант использования flash-плеера, но единственный вменяемый пример FlashXmlHttpRequest был только лишь примером, а не законченным куском кода, которым бы можно было воспользоваться. jQuery на тот момент даже не содержала функции $.getScript, JSHttpRequest с созданием тега script удачно справлялся, но POST по понятным причинам делать не мог.

Данные с главного ресурса могут подгружатся посредством динамического создания тега script jQuery.getScript, с этим казалось бы проблемы нет. Но! Но последним шагом в указанной форме нужно отправить на основной сервер внушительный объём данных, которые могут не влезть в GET (тоже кстати говоря весьма интересный вопрос – а каково ограничение на длину URL в разных браузерах? в различных веб-серверах,прокси и фильтрах? – в RFC2616 об этом не сказано). Можно конечно изобрести какие-либо механизмы, например отправлять данные небольшими порциями GET-ом, но скорости такая схема явно не прибавит, поэтому такие варианты оставлены другим изобретателям.

В первом рабочем варианте проблема решалась php-скриптом на сервере-сателите, через который данные POST-ом прокачивались на головной сайт. Но такая схема имела ряд недостатков, основным из которых опять же является скорость работы и дополнительное требование к ПО на сервере (наличие PHP) или требование к нам, разработчикам – создать прокси-скрипт для других распространнёных серверных платформ.

И вот относительно недавно я наткнулся на занимательную библиотеку flxhr. Автор довёл до конца идею и наваял интерфейс, который может прозрачно заменять XMLHttpRequest используя flash. Использовать flxhr легко и просто – заменяете стандартный XMLHTTPRequest и дальше всё почти как обычно.

В дополнение ко всему, флеш-плеер решает ещё одно требование к разрабатываемому проекту – необходимо пресечь бесконтрольное распространение клиентского модуля(который устанавливается на сайт-сателит). Дело в том что в флеш-плеер от рождения встроен механизм контроля над внешними данными. Ранее это был ресурс crossdomain.xml в корне веб-сервера, содержащего скачиваемые данные. В нём описывалось откуда и что можно скачать. В новом плеере (а для использования flxhr необходим плеер версии не ниже 9.0.0.124) появился более удобный механизм – можно указать путь к ресурсу с политиками policyURL.

Кстати о версии плеера: автор flxhr предусмотрел не только проверку версии плеера, но и возможность его апгрейдить не отходя от кассы (тот самый expressinstall из swfobject).

Думаю стоит ещё раз упомянуть тот факт, что данная схема не позволит обратиться js-скрипту с произвольного сайта A на произвольный ресурс B без согласия его владельца. “Согласие” выражается в виде правил, описываемых в файле crossdomain.xml(или указанным в loadPolicyFile), который располагается на сервере B. Другими словами данные, которые вы желаете публиковать, не должны быть “ворованными”.

Единственным неудобством, с которым пока довелось столкнуться в ходе обкатки flxhr, является тот факт, что данные в кодировке отличной от UTF-8 безвозвратно портятся. В остальном это самый лёгкий и удобный способ обмениваться данными между разными доменами уже сейчас, не дожидаясь появления сверхновых версий браузеров, в которых реализуют XMLHttpRequest Level 2, и скоропостижной смерти всех старых.