Здравствуйте, Аноним, Вы писали:

А>Скажите, пожалуйста, как сделать так, чтобы русские символы в properies файлах, при вывод их на jsp страницы отображались нормально. Как решить проблему с кодировокой? Наверняка проблема уже поднималась, решения не нашел.

А>Спасибо

Если ты под виндой notepda++ -> Convert to UTF-8 without BOM, должно все решить

Скажите, пожалуйста, как сделать так, чтобы русские символы в properies файлах, при вывод их на jsp страницы отображались нормально. Как решить проблему с кодировокой? Наверняка проблема уже поднималась, решения не нашел.

Спасибо

Здравствуйте, Аноним, Вы писали:

А>Скажите, пожалуйста, как сделать так, чтобы русские символы в properies файлах, при вывод их на jsp страницы отображались нормально. Как решить проблему с кодировокой? Наверняка проблема уже поднималась, решения не нашел.

Сконвертить properties файл утилитой native2ascii

Здравствуйте, MayB, Вы писали:

MB>Если ты под виндой notepda++ -> Convert to UTF-8 without BOM, должно все решить
Угу, только Java при чтении файла будет использовать кодировку ОС — cp1251

Здравствуйте, Blazkowicz, Вы писали:

B>Сконвертить properties файл утилитой native2ascii
Или еще вариант, если Java версии 5.0 и выше — использовать Properties в формате XML, кодировку Unicode.

B>Угу, только Java при чтении файла будет использовать кодировку ОС — cp1251
Ну можно ведь её попросить использовать другую кодировку

Здравствуйте, Baudolino, Вы писали:

B>>Угу, только Java при чтении файла будет использовать кодировку ОС — cp1251
B>Ну можно ведь её попросить использовать другую кодировку
Можно. Но страдает переносимость кода. Теперь для запуска проекта на той или иной платформе надо узнавать какая же кодировка у текстовых файлов и явно прописывать её при запуске JVM. Хочешь новый контейнер? Будь добр править batch скрипты. Девелопер забыл сохранить в UTF-8? Будь добр найди эту багу, разберись что причина именно а файле, и проведи семинар для всей команды на тему почему текстовые файлы надо сохранять в UTF-8. Экономическая выгода ещё не очевидна?

Здравствуйте, von Zeppelin, Вы писали:

B>>Сконвертить properties файл утилитой native2ascii
VZ>Или еще вариант, если Java версии 5.0 и выше — использовать Properties в формате XML, кодировку Unicode.
Unicode это стандарт, а не кодировка. UTF это кодировка. XML может быть удобно если вам считать\сохранить. Но хранить в нем локализируемые строки, как-то не очень.

Мне кажется, вы сильно преувеличиваете масштаб проблемы. Хотя, конечно, от команды зависит и организации проекта. Мне как-то повезло — ни разу не приходилось объяснять коллегам, что всегда работать с UTF-8 лучше, чем с cp1251. Тем более, что в приличных IDE кодировка по умолчанию настраивается за минуту, а для локализации проектов сложнее, чем приветмир, лучше всего использовать специальные инструменты, а не notepad.exe.

Здравствуйте, Baudolino, Вы писали:

B>Мне кажется, вы сильно преувеличиваете масштаб проблемы. Хотя, конечно, от команды зависит и организации проекта.
Возможность ошибки лучше исключить полностью, чем оставлять какую-либо, пусть и редкую, возможность её возникновения.

B>Мне как-то повезло — ни разу не приходилось объяснять коллегам, что всегда работать с UTF-8 лучше, чем с cp1251.
Смотря что значит "лучше работать". ИМХО, лучше в ASCII чем в UTF.

B>Тем более, что в приличных IDE кодировка по умолчанию настраивается за минуту,
Ошибочно предполагать что об этом знают все люди, которые когда либо притронутся к проекту. Включая внешних разработчиков, менеджеров и может даже переводчиков.

B>а для локализации проектов сложнее, чем приветмир, лучше всего использовать специальные инструменты, а не notepad.exe.
Вот и я о том же. Лучше использовать предписаный общеизвестный процесс локализации проектов, чем прописывать кодировку для каждого экземпляра установленого проекта и следить за кодировкой файлов в репозитории.

B>Лучше использовать предписаный общеизвестный процесс локализации проектов
Если вы о native2ascii, то юзабилити у такого процесса на уровне плинтуса, и знакомы с ним тоже далеко не все — значит, надо документировать, значит, ничем оно не лучше соглашения об использовании фиксированной кодировки.

Здравствуйте, Baudolino, Вы писали:

B>Если вы о native2ascii, то юзабилити у такого процесса на уровне плинтуса,
Что не так с юзабилити?

B>и знакомы с ним тоже далеко не все — значит, надо документировать, значит, ничем оно не лучше соглашения об использовании фиксированной кодировки.
Не надо его документировать, он уже и так документирован в статьях и мануалах от Sun.

B>Что не так с юзабилити?
Для редактирования надо гонять n2a туда-обратно. Для того же Eclipse есть плагин, который делает то же самое, но не входит в стандартную поставку — надо ставить, надо рассказывать другим, как это делается.

B>Не надо его документировать, он уже и так документирован в статьях и мануалах от Sun.
Все переводчики и все разработчики читают все мануалы и статьи от Sun? Это несколько смелое утверждение. Даже использование каких-то стандартов необходимо документировать и доводить до сведения команды.

Здравствуйте, Baudolino, Вы писали:

B>Для редактирования надо гонять n2a туда-обратно. Для того же Eclipse есть плагин, который делает то же самое, но не входит в стандартную поставку — надо ставить, надо рассказывать другим, как это делается.
Не надо рассказывать. Это всё уже подробно описано. Ваша аргументация сводится к подобному: String класс плохой и
медленный надо же по нему мануалы читать, знать про сравнение и конкатенацию. Поэтому мы все используем char[]

Не надо и обратно гонять. Конвертацию проводить при сборке. И если вдруг кто не так файл сохранил это сразу вылезет. Может даже при сборке проекта.

B>>Не надо его документировать, он уже и так документирован в статьях и мануалах от Sun.
B>Все переводчики и все разработчики читают все мануалы и статьи от Sun? Это несколько смелое утверждение. Даже использование каких-то стандартов необходимо документировать и доводить до сведения команды.
Я вам говорю про то что этот подход позволяет выявить проблему раньше и его не надо документировать, он общеизвестен. И исключает проблему внесения ошибки людми которые не читали мануал. Это не значит что они все обязаны его читать. Вы не те выводы делаете из прочитаного.

B>Не надо рассказывать. Это всё уже подробно описано. Ваша аргументация сводится к подобному: String класс плохой и
B>медленный надо же по нему мануалы читать, знать про сравнение и конкатенацию. Поэтому мы все используем char[]
Не сводится ни разу. Одно дело знание платформы разработчиком, другое — знание довольно специфического инструментария всеми, кто участвует в проекте, включая не-программистов.

B>Не надо и обратно гонять. Конвертацию проводить при сборке. И если вдруг кто не так файл сохранил это сразу вылезет. Может даже при сборке проекта.
Ну да. Теперь еще и инструмент сборки нужно конфигурировать. И как-то учитывать ситуацию, когда кто-то делает коммит в cp1251, кто-то еще как-то.

B>Я вам говорю про то что этот подход позволяет выявить проблему раньше
Раньше чем изначально правильно сконфигурированная среда разработки/редактор? Это уже меньше нуля получается. Вообще, почему вы считаете, что "общеизвестный" подход всегда правилен? В мире Java много всяких "общеизвестных" вещей, которыми лучше не пользоваться.

>Вы не те выводы делаете из прочитаного.
А какие надо делать выводы?

Baudolino пишет:
>
> Не сводится ни разу. Одно дело знание платформы разработчиком, другое —
> знание довольно специфического инструментария всеми, кто участвует в
> проекте, включая не-программистов.
Извините что вмешиваюсь в вашу беседу, но это properties файлы —
"довольно специфический инструментарий" ?

> B>Не надо и обратно гонять. Конвертацию проводить при сборке. И если
> вдруг кто не так файл сохранил это сразу вылезет. Может даже при сборке
> проекта.
> Ну да. Теперь еще и инструмент сборки нужно конфигурировать. И как-то
> учитывать ситуацию, когда кто-то делает коммит в cp1251, кто-то еще как-то.
Если в проекте используются любые символы кроме latin-1 — все должны
делать коммиты только в utf-8 и никак иначе. Иначе помимо properties вас

может ожидать куча сюрпризов при сравнении констант и чтении
комментариев. Нарушители подлежат депремированию и публичному наказанию
плетьми.

Конвертацию надо делать при сборке проекта, все современные сборщики
(Ant,Maven) это умеют.

--
WBR,
Serge.

H>Извините что вмешиваюсь в вашу беседу, но это properties файлы —
H>"довольно специфический инструментарий" ?
А вы бы с начала почитали. Речь идет об утилите native2ascii.

H>Конвертацию надо делать при сборке проекта, все современные сборщики
H>(Ant,Maven) это умеют.
Зачем делать конвертацию (и во что?), если в репозитории по вашим заветам все и так хранится в utf-8?

Baudolino пишет:
>
> H>Извините что вмешиваюсь в вашу беседу, но это properties файлы —
> H>"довольно специфический инструментарий" ?
> А вы бы с начала почитали. Речь идет об утилите native2ascii.
Это понятно, непонятно зачем пытаться идти против древней и
документированной технологии в работе с этими файлами.

> H>Конвертацию надо делать при сборке проекта, все современные сборщики
> H>(Ant,Maven) это умеют.
> Зачем делать конвертацию (и во что?), если в репозитории по вашим
> заветам все и так хранится в utf-8?
Вы наверняка смотрели в сконвертированный утилитой properties файл. Так
что вопросы будем считать риторическими

--
WBR,
Serge.

H>Это понятно, непонятно зачем пытаться идти против древней и
H>документированной технологии в работе с этими файлами.
Вы видимо так и не ознакомились с содержанием дискуссии. И, что забавно, приводите аргументы именно против этой "древней и документированной технологии".

H>Вы наверняка смотрели в сконвертированный утилитой properties файл.
Ошибаетесь. Вам подсказать, как выставляется кодировка по умолчанию в IDE?

Baudolino пишет:
>
> H>Вы наверняка смотрели в сконвертированный утилитой properties файл.
> Ошибаетесь. Вам подсказать, как выставляется кодировка по умолчанию в IDE?

Может ещё подскажете какая у меня IDE ?
Что не смотрели — я уже понял.

--
WBR,
Serge.