Я недавно установил Запрос песни Winamp, который представляет собой плагин для запроса веб-песен Winamp со встроенным минимальным HTTP-сервером CGI.
Что делает плагин, так это то, что он запускает веб-сервер, обслуживает html-страницу с некоторыми специальными переменными, которые он заменяет фактическими данными по запросу (список воспроизведения, очередь запросов, время, оставшееся в песне и т. д.).
Я увидел в этом интересный и хороший проект по изучению jQuery, поэтому я начал подключать свой собственный js-код для замены, исправления и jaxify обслуживаемого веб-сайта из плагина, но теперь у меня возникла проблема с кодировкой символов.
На странице вы получите ссылки на все песни в плейлисте. Когда вы нажимаете на одну из ссылок, я подключал свою собственную функцию щелчка jQuery. Поэтому вместо перезагрузки всей страницы, когда вы запрашиваете песню, я использую $.get($(this).attr('href', function(response) {... code ...}), а затем использую replaceWith для замены текущей очереди новой сгенерированной очередью с вашим запросом, добавленным на лету. Я делаю то же самое, чтобы показать / обновить текущее воспроизведение и при поиске, чтобы все было извлечено в фоновом режиме, а затем заменено на лету с добавлением некоторых анимаций.
Все jQuery / Ajax отлично работают, но у меня большая проблема с кодировкой и названиями песен в очереди / плейлисте. Специальные символы (åäöé и т. д.) В именах вообще не работают.
Плагин выводит все в формате iso-8859-1 / latin1, а мой метатег в разметке сообщает браузеру, что эта страница является latin1. При обычном обновлении страницы в браузере это работает хорошо, и специальные символы отображаются как обычно. Но когда я использую jQuery и $.get() для замены блоков кода на лету, специальные символы отображаются только как?.
Я думаю, что проблема заключается в том, что jQuery по умолчанию считает, что ответ $.get() - это UTF-8, если в заголовке не указано иное. Плагин вообще не устанавливает заголовок для кодирования / кодировки, и поскольку у меня нет никакого контроля над серверной частью и тем, какие заголовки устанавливаются, я не могу это изменить.
Единственные заголовки, которые я получаю в ответе от плагина:
Server: WinampServer
Connection: close
Content-Type: text/html
Надеюсь, вы понимаете мою проблему. У меня есть страница, на которой у меня нет никакого контроля над серверной частью, и все, с чем мне нужно работать, - это сгенерированный HTML. Я не могу изменять или добавлять заголовки в ответы. Мне нужно сообщить jQuery, что ответ на самом деле находится в latin1, а не в UTF-8, чтобы не нарушалась кодировка специальных символов. Я пробовал scriptCharset: 'iso-8859-1' в jQuerys ajaxSetup, но он работает только с типом script / json, и я работаю с ответами HTML.
Есть идеи, возможно ли это или какой-либо другой обходной путь, о котором вы могли бы подумать?

редактировать: хорошо, я думаю, это работает (по крайней мере, это сработало в моей тестовой среде, см. Изменения для предыдущей попытки)
$.ajaxSetup({
'beforeSend' : function(xhr) {
xhr.overrideMimeType('text/html; charset=UTF-8');
},
});
$('#stuff').load('/yourresource.file'); // your ajax load
у меня был основной набор файлов в UTF-8 и набор файлов данных в ISO-8859-1. без приведенного выше кода я получил кучу мусора для тестовой строки åäöé, как и ожидалось. с приведенным выше кодом он загрузил åäöé правильно закодированный.
Ого, большое спасибо. Это работает как шарм. Я был готов сдаться и признать, что мою проблему невозможно решить. Потратил много времени на пробу разных вещей и поиск в Google решения. Ваш beforeSend отлично работал, когда я установил кодировку на iso-8859-1.
К сожалению, это не работает для IE. Лучшие решения в сообщении SO: связь
Сначала было бы лучше, если бы вы использовали более общую функцию $ .ajax ().
Согласно документация есть опция scriptCharset, однако она применима только к определенным типам данных. Также указано, что это необходимо только в том случае, если кодировка вызывающей страницы отличается.
Это просто для того, чтобы указать, что, хотя метод overrideMimeType () доступен в браузерах на основе Gecko (Firefox, ...), он НЕ находится в IE (по крайней мере <= 7), и, похоже, нет обходного пути. (Я не знаю о доступности в других браузерах.)
Я тоже пробовал это, но, похоже, это не помогает. Я думаю, что это устанавливает только кодировку отправляемых вами данных, а не кодировку данных, полученных обратно в ответ.