Кодировка: русский текст
При использовании Google Closure Compiler, как впрочем и других аналогичных упаковщиков, основанных на Rhino, возникают некоторые проблемы с русским текстом.
Эта статья содержит рецепты, как их легко преодолеть.
Если вы попробуете сжать javascript, в котором присутствуют русские буквы в кодировке windows-1251, то на выходе вместо русского текста получите "кракозяблы". Это нормально.
Для того, чтобы произвести правильную обработку, необходимо для начала перевести файл в промежуточный ASCII-формат. Это умеет делать утилита native2ascii , которая распространяется вместе с JDK.
То есть, обычной JRE (Java Runtime Environment) не хватит, нужно поставить JDK, и там, в директории bin, будет лежать эта утилита.
На входе: file.js
function()
var a = "тест"
return a
}
Запускаем:
native2ascii -encoding windows-1251 file.js file.ascii.js
Получаем file.ascii.js
function func() {
a = "\u0442\u0435\u0441\u0442"
return a
}
Теперь полученный файл в формате ASCII можно смело передавать компилятору:
java -jar compiler.jar --js file.ascii.js --js_output_file file.ascii.compiled.js
На выходе: file.ascii.compiled.js
function func(){return a="\u0442\u0435\u0441\u0442"};
И теперь - возвращаем файл из промежуточного формата обратно, в родной windows-1251:
native2ascii -reverse -encoding windows-1251 file.ascii.compiled.js file.compiled.js
Получили результат - сжатый файл в кодировке windows-1251.
Вот небольшой пакетный файл под windows для сжатия. Предполагается, что путь к native2ascii (к директории bin в JDK) у вас в переменной PATH .
native2ascii -encoding windows-1251 "%1.js" "%1.tmp.js"
java -jar compiler.jar --js "%1.tmp.js" --js_output_file "%1.compiled.tmp.js" %2 %3 %4 %5 %6 %7
native2ascii -reverse -encoding windows-1251 "%1.compiled.tmp.js" "%1.compiled.js"
del /q "%1.tmp.js"
del /q "%1.compiled.tmp.js"
Использование для файла file.js :
c.bat file --compilation_level ADVANCED_OPTIMIZATIONS
Готовый файл будет file.compiled.js .
C кодировкой UTF-8 все немного проще. Мы можем скормить файл компилятору сразу же. Единственно, результат будет такой:
function func(){return a="\u0442\u0435\u0441\u0442"};
То есть, вместо UTF-символов мы имеем их запись в виде ASCII.
Для приведения такого файла к нормальному виду достаточно пропустить его через native2ascii без указания кодировки:
native2ascii -reverse <откомпилированный файл> <итоговый файл>
После этого полученный файл будет в кодировке 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, это может выглядеть примерно так:
<jscomp compilationlevel="simple" debug="false" output="ascii/scripts.min.js">
<sources dir="/">
<file name="script1.js" />
<file name="script2.js" />
</sources>
</jscomp>
<native2ascii src="ascii" dest="/" reverse="true" />
<delete dir="ascii" />
Пример для скриптов в 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 без всяких прыжков с переворотом.
Это действительно работает, неплохо бы автор исправил статью, чтобы не вводить новичков вроде меня в заблуждение %)