Форум

Справочник

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

При использовании 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 без всяких прыжков с переворотом.

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

Изменить кодировку в nodejs. CP1251/1252 в UTF-8

Никак не получается изменить кодировку, у меня есть парсер, выводит информацию в консоль в нормальном виде (кодировка либо CP1251, либо CP1252), но эту информацию мне надо отправлять в телеграмм по API. Мне вылазит ошибка, что кодировка должна быть UTF-8.

Если делать так:

то выводит иероглифы

2 ответа 2

Вот простой пример для iconv-lite

Ответ, отмеченный, как принятый — полный привет логике, и полное досвидание производительности.

Проблема решается неочевидно. Помимо кодировки исходника (исходные данные на источнике), многое зависит от того, каким инструментом забираете источник: node-fetch , request , axios , unirest . В случае, если данные читаются из файла, там данное решение тоже пройдет, но. там отдельная история.

Суть проблемы в том, что Привет может прилететь и из заголовков ( headers ) ответа ( response ) и даже из содержимого ответа (в случае XML — обязательно). Я двое суток смотрел на буквы э на местах всех кириллических знаков, пока не расковырял исходники всех этих фетчей и реквестов, которые думать не думают о других кодировках, кроме utf8 и других форматах данных, кроме json , и то — JSON обязательно должен быть utf8 , даже Unicode ему нельзя быть. Как в песенке про папу, который может быть кем угодно, но мамой не может быть. Хуже всего, если все-таки — думают, но полагают, что все решено.

Далее, важно в какой консоли вы смотрите ответы Ноды: Windows (XP, Vista, 7|8, 10 — ждут сюрпризы), xterm? У Вас LINUX! О! Как хорошо, что Вы не знаете, что такое KOI-8, а Ваши учителя даже про KOI-7. Относительно ровно предсказать вывод без танцев с большим шаманским бубном можно в консолях RHEL^7(CentOs^7, Fedora^17), Ubuntu^12, MacOs^X. С другими не знаком, либо неоднозначно.

Еще вопрос — удалённо если смотрите на терминал, то какой протокол, какой терминальный клиент? Допустим, что с терминалом и кодировками на терминале хорошо.

Ожидаемое решение можно получить только ручками через нативный http или node-fetch, и только тогда, когда входные данные обрабатываются как буфер.

Вот рабочий макет для песочницы. Просто поиграйтесь с вариантами (ответы функции cnw8 ), которых на просторах интернетов вагон. Почти все они — неправильные, работают только два: один здесь, а другой у Майкла Джексона.

TextDecoder и TextEncoder

Что если бинарные данные фактически являются строкой? Например, мы получили файл с текстовыми данными.

Встроенный объект TextDecoder позволяет декодировать данные из бинарного буфера в обычную строку.

Для этого прежде всего нам нужно создать сам декодер:

• label – тип кодировки, utf-8 используется по умолчанию, но также поддерживаются big5 , windows-1251 и многие другие.
• options – объект с дополнительными настройками:
  • fatal – boolean, если значение true , тогда генерируется ошибка для невалидных (не декодируемых) символов, в ином случае (по умолчанию) они заменяются символом \uFFFD .
  • ignoreBOM – boolean, если значение true , тогда игнорируется BOM (дополнительный признак, определяющий порядок следования байтов), что необходимо крайне редко.

…и после использовать его метод decode:

• input – бинарный буфер ( BufferSource ) для декодирования.
• options – объект с дополнительными настройками:
  • stream – true для декодирования потока данных, при этом decoder вызывается вновь и вновь для каждого следующего фрагмента данных. В этом случае многобайтовый символ может иногда быть разделён и попасть в разные фрагменты данных. Это опция указывает TextDecoder запомнить символ, на котором остановился процесс, и декодировать его со следующим фрагментом.

Мы можем декодировать часть бинарного массива, создав подмассив:

TextEncoder

TextEncoder поступает наоборот – кодирует строку в бинарный массив.

Имеет следующий синтаксис:

Поддерживается только кодировка «utf-8».

Кодировщик имеет следующие два метода:

• encode(str) – возвращает бинарный массив Uint8Array , содержащий закодированную строку.
• encodeInto(str, destination) – кодирует строку ( str ) и помещает её в destination , который должен быть экземпляром Uint8Array .

Кодировка внешнего 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-файла является одним из многочисленных неизбежных последствий.

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