Кодировка внешнего JavaScript-файла

Чтобы генерируемый JavaScript-сценарием текст в кодировке, отличной от кодировки страницы, куда этот текст выводится, отображался корректно (это актуально, например, для Google Maps), достаточно добавить к соответствующему элементу script атрибут charset , явно указывающий на кодировку JS-файла:

Способ применим в случаях, когда сервер не отдаёт явным образом кодировку JS-файла в HTTP-заголовке ответа Content-Type , который для браузера имеет более высокий приоритет, чем атрибут charset .

Большое спасибо! Помогло! =3

Это прекрасно, чуть было не подумал, что все потеряно и придется отказаться от русского языка в букмарлете

Спасибо! Помогло! =5

Страница в win1251, внешний js-файл — в utf-8. При подключении как

кириллицу внутри скрипта выдает так:
(?:вoзьмитe|выберите) пepвый нoмep кoшeлькa|удалить из\\sсписка первый кошелёк|первый кошелёк из списка|необходимо отправить на каждый|(?:Отправить на эти|НА КАЖДЫЙ ИЗ ЭТИХ|надо послать по \\d+ руб\\.? на) \\d\\s?.*?кошельков|внесите

Павел, есть два предположения:

1. либо вы просматриваете соответствующий внешний JS-файл напрямую, на что способ его подключения к странице, разумеется, никак не влияет;
2. либо сервер явным образом отдаёт для JS-файла неправильную кодировку в HTTP-заголовке ответа сервера вида Content-Type: text/javascript; charset=windows-1251 , который для браузера приоритетнее HTML-атрибута. Атрибут charset работает в случаях, когда кодировку JS-файла сервер не сообщает. Дополнил заметку.

Во втором случае следует изменить заголовок Content-Type , удалив из него кодировку или заменив на соответствующую действительности. Если изменение заголовка Content-Type недоступно, но есть возможность повлиять на выводимый JS-код, то в качестве полумеры можно заменить кириллические символы как таковые на соответствующие Escape-коды вида \u0430 , представленные символами ANSI, которые в Windows-1251 и UTF-8 одинаковы.

В целом же имеет смысл просто перейти на использование UTF-8 — сейчас уже нет никакой необходимости использовать другую кодировку. Если же ограничение обусловлено платформой (например, используется CGI-приложение 10-15-летней давности), то такая платформа, увы, безнадёжно устарела, и проблема с подключением внешнего JS-файла является одним из многочисленных неизбежных последствий.

Перепечатка любых материалов сайта в любом объёме запрещена

Форум

Справочник

Кодировка: русский текст

При использовании Google Closure Compiler, как впрочем и других аналогичных упаковщиков, основанных на Rhino, возникают некоторые проблемы с русским текстом.

Эта статья содержит рецепты, как их легко преодолеть.

Сжатие в кодировке: windows-1251

Если вы попробуете сжать javascript, в котором присутствуют русские буквы в кодировке windows-1251, то на выходе вместо русского текста получите «кракозяблы». Это нормально.

Для того, чтобы произвести правильную обработку, необходимо для начала перевести файл в промежуточный ASCII-формат. Это умеет делать утилита native2ascii , которая распространяется вместе с JDK.

То есть, обычной JRE (Java Runtime Environment) не хватит, нужно поставить JDK, и там, в директории bin, будет лежать эта утилита.

На входе: file.js

Теперь полученный файл в формате ASCII можно смело передавать компилятору:

На выходе: file.ascii.compiled.js

И теперь — возвращаем файл из промежуточного формата обратно, в родной windows-1251:

Получили результат — сжатый файл в кодировке windows-1251.

Пакетный файл

Вот небольшой пакетный файл под windows для сжатия. Предполагается, что путь к native2ascii (к директории bin в JDK) у вас в переменной PATH .

Использование для файла file.js :

Готовый файл будет file.compiled.js .

Сжатие в кодировке UTF-8

C кодировкой UTF-8 все немного проще. Мы можем скормить файл компилятору сразу же. Единственно, результат будет такой:

То есть, вместо UTF-символов мы имеем их запись в виде ASCII.

Для приведения такого файла к нормальному виду достаточно пропустить его через native2ascii без указания кодировки:

После этого полученный файл будет в кодировке UTF-8.

На этом проблемы с кодировкой должны быть исчерпаны.

native2ascii работает только в составе пакета или нет? Если нет? скиньте файл или ссылку на него на мыло, спасибо.

А где взять этот native2asci?

Перефразирую свой вопрос: есть ли аналоги native2ascii? Совершенно не хочется на сервере ставить JDK из-за этой приблуды.

Вот простенький заменитель native2ascii на javascript под Windows Script Host.
Запуск: cscript.exe native2ascii.js

Оказалось, что текст сохраняется в Windows-1251. Вот исправленный скрипт:

Я так понимаю, что можно еще конвертировать скрипты в UTF-8, обрабатывать упаковщиком и переконвертировать обратно в Win-1251?

Кстати, native2ascii входит в состав дефолтных команд Apache Ant. Так что если вы юзаете ант для сжатия js, это может выглядеть примерно так:

Пример для скриптов в UTF-8.

Если JDK не установлен, на задании native2ascii билдер будет вылетать с ошибкой.

То есть нет никакого значка чтоб java-всемогущий понял следующий текст как записанный пользователем уже в unicode? без скармливания каким-то программам? грошёвый продукт, если так

Хм, у меня по-умолчанию при написании:
native2ascii -reverse
он кодируется в win-1251.
Чтобы в utf-8 получить, необходимо написать:
native2ascii -reverse -encoding utf-8

для сжатия win-1251 достаточно указать ключ —charset WINDOWS-1251, а для UTF-8, соответственно —charset UTF-8 без всяких прыжков с переворотом.

Это действительно работает, неплохо бы автор исправил статью, чтобы не вводить новичков вроде меня в заблуждение %)

Форум

Справочник

Опции темы

Искать в теме

Сообщение от Deff Загружаю UTF-8 Сообщение от danik.js не вижу в упор UTF-8

Открой в браузере ссылку http://hostjs-mybb2011.narod.ru/js/asdsa.js
сохрани на рабочий стол — открой в блокноте, — файл сохранить как — внизу покажет текущую кодировку

Имхо по умолчанию скрипты грузятся в UTF-8 и трансформируются в кодинг страницы, вот для ANSI — точно нужно прописывать

Для UTF-8 — пофег походу атрибут charsetcharset=»windows-1251″

Сообщение от Deff Имхо по умолчанию скрипты грузятся в UTF-8

Похоже на то. Ибо у твоего скрипта нигде не указана кодировка явно, причем дефолтная кодировка для текстового содержимого — windows-1251. А для скриптов видимо utf-8

Так или иначе, атрибут charset (на который я давал ссылку выше) решает проблему ТС.

Встроенные сюда примеры не будут работать корректно. Кодировка html-документов один фиг utf-8, несмотря на тег meta

Сообщение от Deff Для UTF-8 — пофег походу атрибут charset=»windows-1251″

не пофиг .

«Windows-1251 выгодно отличается от других 8‑битных кириллических кодировок (таких как CP866, KOI8-R и ISO 8859-5) наличием практически всех символов, использующихся в русской типографике для обычного текста . она также содержит все символы для близких к русскому языку языков: украинского, белорусского, сербского, македонского и болгарского.

Имеет два недостатка. «

Кодировка страницы windows-1251, кодировка скрипта utf-8, но она явно нигде не указывается. В итоге кракозябры:
http://new-era63.ru/hello-windows1251.php

Кодировка страницы windows-1251, кодировка скрипта utf-8, об этом сообщается через атрибут charset скрипта, в итоге все ок:
http://new-era63.ru/hello-utf8.php

Жать Ctr+F5, иначе (хром как минимум) кодировка кэшируется.

AJAX и проблемы с кодировками.

Главная » Блог » AJAX и проблемы с кодировками.

Очень часто разработчики в тех или иных ситуациях сталкиваются с проблемами, связанными с кодировками. Особенно те, кто работает в кодировке windows-1251. Сегодня хотел рассмотреть эту проблему, посмотреть разные примеры и возможные решения.

AJAX (Asynchronous Javascript and XML, асинхронный Javascript и XML) очень тесно вошел в обиходе, и сложно представить себе современный сайт без использования этой технологии. По сути, аякс это фоновый обмен данными, что позволяет получать данные без перезагрузки страницы. Различные «живые поиски», регистрации, формы обратной связи и т.д.

Через AJAX мы можем передавать данные методом POST и GET. Давайте разберемся, какие могут быть проблемы в передачи этих данных.

Начем с GET.

Когда мы передаем данные через GET – это значит мы посылает скрипту URL, в котором русский текст должен быть закодирован, в определенной последовательности. Называется она escape-последовательностью.

В этом GET запросе, query передает фразу «русский текст». Но escape-последовательности отличаются друг от друга, в зависимости от используемой кодировки. Для того что бы перевести русский текст в последовательность, W3C рекомендует использовать функцию «encodeURIComponent()», которая автоматически переводит текст в utf-8 и создает escape-последовательность. Поэтому при передаче текста через Jquery, Prototype, и другие фреймворки, на выходе мы получаем текст в UTF-8 кодировке. Если вы работаете в кодировке Windows-1251, то придется вначале текст перевести из utf-8 в Windows-1251 ( это можно сделать через iconv, например: $_GET[‘query’] = iconv(‘utf-8’, ‘Windows-1251’, $_GET[‘query’])).

С теорией закончили, теперь давайте рассмотрим примеры. Есть один интересный нюанс, который я обнаружил. Я работал с фреймворком Jquery, сайт работает в utf-8, обработчик ajax запросов работает в utf-8, база данных работает в utf-8, короче все узлы сайта построены в этой кодировке. Рассчитывая на то, что Jquery посылает запрос через encodeURIComponent(), я его не стал использовать. Да и в принципе никаких проблем не было, пока не стали приходить запросы с «каказябрами», при том что Firefox, Chrome и Opera корректно присылали запросы в utf-8, но вот Internet Explorer, как самый выдающийся браузер, умудрялся присылать запросы в windows-1251.

Я решил провести тест, и разобраться при каких ситуациях IE посылает неверную кодировку.

Так вот, проверив оба, я выяснил что в $.ajax IE посылает не UTF-8, а Windows-1251. Решение этой проблемы – добавить encodeURIComponent() и все будет хорошо.

Хорошо, с GET запросами разобрались.

Теперь рассмотрим коротко POST.

В отличие от GET запросов, в POST передается Content-type, который сообщает серверному скрипту информацию, о том с какими данными он работает и возможность указания кодировки. Например, в Jquery по умолчанию AJAX передает «application/x-www-form-urlencoded; charset=UTF-8», но даже если вы укажите “text/html; charset=windows-1251”, то данные приходящие будут в utf-8, так как при передачи данных, Jquery формирует escape-последовательность, функцией, о которой писалось выше.

Но это не так страшно, потому что у нас есть всегда возможность перевести кодировку и уже работать с данными. При этом отдавать результаты мы можем в нашей любимой кодировке, главное не забывайте ставить заголовок, с указанием кодировки, если вдруг вы обратно получаете «каказябры».

Вывод: для того что бы не было проблем с кодировками, при передачи данных через AJAX, нужно использовать encodeURIComponent(). Если ваш серверный скрипт, который принимает запросы, работает в другой кодировке, отличной от utf-8, то надо пользоваться php функцией iconv и устанавливать заголовок header.

blob with conversion to 8bit cp1251 or cp1252

I need a solution with encoding utf to 8-bit cp1251 or cp1252 using blob

I managed to change the https://github.com/b4stien/js-csv-encoding including windows 1251, but there are insoluble problems:

Unfortunately noscript does not allow loading external javascript on a page with scripts turned off via it.

Therefore, it is impossible to use js-csv-encoding in the bookmarker, as well as to load jquery! Disabling noscript, especially after meltdown and specter is simply not secure.

Therefore, only the version of a small script written in native javascript is left. If you find an alternative way to run jquery with noscript off, then finding a solution will be easier although I doubt it’s possible.

A good solution would be https://www.npmjs.com/package/windows-1251 or https://www.npmjs.com/package/windows-1252 However, it does not succeed to transcode two-byte text into a single-byte text through these scripts. For example:

There have been many attempts to use windows1251, for example these:

Using encode or decode from windows-1251 does not translate the script into a 8-bit format. In js-csv-encoding, csvContentEncoded is used for transcoding:

Attempts to use something like that have failed. Perhaps you need some kind of hack, just put windows-1251 is not enough, since js stores in utf8, then most likely you need to add the conversion to 1251 at the very end. Part of the code: js-csv-encoding.

I also tried to use conversions using charcode, saving not to the server but to the computer, so using urlencode .. is not the right solution, because in this case I have to encode the text into the readable one.

Of course, it’s hard to find a solution of no more than 4000-5000 characters for a bookmarklet, and my knowledge is not enough. If there is a solution with the help of other scripts, for example, recoding by the value table, this can also be a solution.