Re: что-то интересное с кодировками
Pavel Ammosov wrote: java внутри себя работает в unicode. Когда она общается с внешним миром, юникодные символы преобразуются в символы текущей локали. Если быть совсем точным, то в file.encoding system property, которая по умолчанию устанавливается в кодировку локали. Соответственно, можно ее устанавливать с помощью java -Dfile.encoding=UTF-8 Автору исходного поста: раз уж вы пишете в XML-заголовке кодировку UTF-8, то и явно кодируйте поток ей же, используя OutputStreamWriter(OutputStream os, String charset), не надеясь на локаль и прочее окружение. -- Alexei Grigorovich <[EMAIL PROTECTED]> Shamrock Technologies -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On Sun, Jul 16, 2006 at 09:01:04PM +0400, Иван Лох wrote: > > А зачем там редактор? > Ну вместо редактора я vim использую. Но то что сломали - факт. При чем сломано и для неюникодных локалей. -- WBR, Dmitry signature.asc Description: Digital signature
Re: что-то интересное с кодировками
On Sun, Jul 16, 2006 at 07:34:55PM +0300, Dmitry Nezhevenko wrote: > > Тот, что в unstable уже живет. > > Угу.. Зато отломали перекодировку текста в просмотрщике/редакторе. А зачем там редактор? -- Иван Лох -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On Sun, Jul 16, 2006 at 03:10:54PM +0400, Иван Лох wrote: > On Sat, Jul 15, 2006 at 12:37:31AM +0400, Victor Wagner wrote: > > On 2006.07.14 at 23:05:59 +0300, Pavel wrote: > > Кроме mc. Этот по-моему, с utf-8 без сторонних патчей не живет. > > Тот, что в unstable уже живет. > Угу.. Зато отломали перекодировку текста в просмотрщике/редакторе. -- WBR, Dmitry signature.asc Description: Digital signature
Re: что-то интересное с кодировками
On Sat, Jul 15, 2006 at 12:37:31AM +0400, Victor Wagner wrote: > On 2006.07.14 at 23:05:59 +0300, Pavel wrote: > Кроме mc. Этот по-моему, с utf-8 без сторонних патчей не живет. Тот, что в unstable уже живет. -- Иван Лох -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On Fri, Jul 14, 2006 at 09:48:41PM +0300, Pavel wrote: > Приложение тестировалось на тестовом сервере по дебианом, всё было > замечательно. Перенеся на продакшн, еще один дебиан, обнаружилось что > файлы записанные на диск невозможно прочесть, вместо русских букв там > крякозябли. java внутри себя работает в unicode. Когда она общается с внешним миром, юникодные символы преобразуются в символы текущей локали. Если локаль семибитная (C), то вместо русских букв получаются либо знаки вопроса (в норме), либо какой-то ужыс (иногда). Надо просто выставить LC_CTYPE в правильную кодировку (LC_CTYPE=ru_RU.KOI8-R) в стартовом скрипте. LC_ALL трогать не надо. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On Fri, Jul 14, 2006 at 11:05:59PM +0300, Pavel wrote: > Таки да! Все заработало с LC_ALL=<пусто> > > Отпишу на всякий случай, может кому > пригодится... > > Обычно я делал так: > Логинюсь по ssh на прод. сервер. Первую > команду которую выполняю - LC_ALL=C ибо mc и psql > без этого плющит. Собираю проект, деплою. > Дальше стартую jboss и получаю знаки > вопроса в текстовых файлах. > mc будет плющить если он собран без юникодного патча или если кодировка терминала не UTF-8. -- WBR, Dmitry signature.asc Description: Digital signature
Re: что-то интересное с кодировками
On 2006.07.14 at 23:05:59 +0300, Pavel wrote: > Таки да! Все заработало с LC_ALL=<пусто> > > Отпишу на всякий случай, может кому пригодится... > > Обычно я делал так: > Логинюсь по ssh на прод. сервер. Первую команду которую выполняю - > LC_ALL=C ибо mc и psql без этого плющит. Собираю проект, деплою. Дальше Странно. Что-то не помню, чтобы psql плющило от таких вещей. Вот неудобочитаемые сообщения у него бывают. Лечится это выставлением LC_MESSAGES в C. Остальные категории локали можно не трогать. (LC_ALL, как следует из названия, выставляет их все разом в одно значение). А преобразованием символов ведает категория LC_CTYPE. Кстати, есть ещё вариант - выставлять в подобных случаях локаль в en_US.UTF-8. Тогда сообщения будут по-английски, а кодировка UTF-8. В случае языков с внутренним представлением в unicode (а нынче это не только Java и Tcl, но и Perl с PYthon) может решить все проблемы разом. Кроме mc. Этот по-моему, с utf-8 без сторонних патчей не живет. Вот у psql при правильно выставленной локали и PGCLIENTENCODING проблем не будет. А вообще, логинясь по ssh на сервер, локаль надо выставлять в соотвесттвии с тем, как русские буквы будет отображать клиент. Если это виндовый клиент, то, вероятно, ru_RU.CP1251 будет оптимальной. Естественно, это касается интерактивно запускаемых программ, а не серверных процессов. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On 2006.07.14 at 22:35:37 +0300, Pavel wrote: > Victor Wagner wrote: > > >Кракозябли бывают разные. Какие именно? И какая локаль была у процесса, > >которым файлы читали. И вообще в какой операционной системе их читали? > > Генерились xml файлы. с encoding='UTF-8' в заголовке. Читает их > настольное приложение на winxp (cp1251). Так же, естественно, пробую > читать их вьювером kate у себя, по одной пытаясь применить ту или иную > кодировки, увы без результата. Везде где русский текст вижу > вопросительные знаки. Ну если сплошные вопросительные знаки, то дело явно в библиотеках JAVA. То есть оно пытается при записи сконвертировать из внутреннего представления JAVA (которое по-моему UCS2) в кодировку текущей локали, и все символы, которые не нашло в этой кодировке, заменяет на вопросительные знаки. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
Таки да! Все заработало с LC_ALL=<пусто> Отпишу на всякий случай, может кому пригодится... Обычно я делал так: Логинюсь по ssh на прод. сервер. Первую команду которую выполняю - LC_ALL=C ибо mc и psql без этого плющит. Собираю проект, деплою. Дальше стартую jboss и получаю знаки вопроса в текстовых файлах. Если оставить дефолтное значение в LC_ALL (пустое) - то всё работает как следует. Вот дефолтная locale на сервере: LANG=ru_RU.UTF-8 LC_CTYPE="ru_RU.UTF-8" LC_NUMERIC="ru_RU.UTF-8" LC_TIME="ru_RU.UTF-8" LC_COLLATE="ru_RU.UTF-8" LC_MONETARY="ru_RU.UTF-8" LC_MESSAGES="ru_RU.UTF-8" LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL= Виктор, спасибо за наводку! Павел. Victor Wagner wrote: Кракозябли бывают разные. Какие именно? И какая локаль была у процесса, которым файлы читали. И вообще в какой операционной системе их читали? Генерились xml файлы. с encoding='UTF-8' в заголовке. Читает их настольное приложение на winxp (cp1251). Так же, естественно, пробую читать их вьювером kate у себя, по одной пытаясь применить ту или иную кодировки, увы без результата. Везде где русский текст вижу вопросительные знаки. Стал сравнивнивать окружение на тестовом и прод. серверах и выяснил что на тестовом сервере у процесса сервера LC_ALL=ru_RU.UTF-8, а на продакшн - LC_ALL=C. Для пробы изменил LC_ALL на продашн - русские буквы стали отображаться нормально. Вообще по хорошему счету LC_ALL вообще выставлять не надо. Если выставить LANG, то можно потом поменять отдельные категории, скажем LC_NUMERIC. А LC_ALL имеет более высокий приоритет. Сейчас попробую сделать LC_ALL пустой. Отпишу что из этого вышло. Спасибо за ответ! Павел. Вот что хочу спросить, где проблема? В моём коде который генерит UTF-8 текст и пишет его на диск или это потому что процесс у которого LC=C не может по определению писать на диск UTF-8 текст? Скорее всего - ни там, ни там. Между твоим кодом и системным вызовом write имеется куча промежуточных слоев - всякие библиотеки классов, собственно JRE, libc и т.д. Если в файле действительно НЕ русские буквы, в чем следует убедиться просмотрев файлы на системе с заведомо известной локалью, посредством наиболее примитивного вьюера, вроде less, а то и просмотром шестнадцатиричного дампа файла (хотя не люблю читать utf-8 в шестнадцатиричном виде. UTF-16 еще куда ни шло), то проблема скорее всего в каких-нибудь промежуточных библиотеках. Еще может быть что файлы пишутся в каком-нибудь формате, предусматривающем явное указание кодировки, например XML. И из-за неверной локали стандартная функция библиотеки, формирующая файл, может залепить туда например iso8859-1 в качестве кодировки, после чего написать честные русские буквы в utf-8. Тогда честный вьюер, учитывающий информацию из заголовков, покажет то, что обычно называют "крокозяблики" - латинские буквы со всякими надчерками и крышечками. А при просмотре в текстовом вьюере вроде less в правильной локали русские буквы будут видны. Спасибо! Павел. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
Victor Wagner wrote: Кракозябли бывают разные. Какие именно? И какая локаль была у процесса, которым файлы читали. И вообще в какой операционной системе их читали? Генерились xml файлы. с encoding='UTF-8' в заголовке. Читает их настольное приложение на winxp (cp1251). Так же, естественно, пробую читать их вьювером kate у себя, по одной пытаясь применить ту или иную кодировки, увы без результата. Везде где русский текст вижу вопросительные знаки. Стал сравнивнивать окружение на тестовом и прод. серверах и выяснил что на тестовом сервере у процесса сервера LC_ALL=ru_RU.UTF-8, а на продакшн - LC_ALL=C. Для пробы изменил LC_ALL на продашн - русские буквы стали отображаться нормально. Вообще по хорошему счету LC_ALL вообще выставлять не надо. Если выставить LANG, то можно потом поменять отдельные категории, скажем LC_NUMERIC. А LC_ALL имеет более высокий приоритет. Сейчас попробую сделать LC_ALL пустой. Отпишу что из этого вышло. Спасибо за ответ! Павел. Вот что хочу спросить, где проблема? В моём коде который генерит UTF-8 текст и пишет его на диск или это потому что процесс у которого LC=C не может по определению писать на диск UTF-8 текст? Скорее всего - ни там, ни там. Между твоим кодом и системным вызовом write имеется куча промежуточных слоев - всякие библиотеки классов, собственно JRE, libc и т.д. Если в файле действительно НЕ русские буквы, в чем следует убедиться просмотрев файлы на системе с заведомо известной локалью, посредством наиболее примитивного вьюера, вроде less, а то и просмотром шестнадцатиричного дампа файла (хотя не люблю читать utf-8 в шестнадцатиричном виде. UTF-16 еще куда ни шло), то проблема скорее всего в каких-нибудь промежуточных библиотеках. Еще может быть что файлы пишутся в каком-нибудь формате, предусматривающем явное указание кодировки, например XML. И из-за неверной локали стандартная функция библиотеки, формирующая файл, может залепить туда например iso8859-1 в качестве кодировки, после чего написать честные русские буквы в utf-8. Тогда честный вьюер, учитывающий информацию из заголовков, покажет то, что обычно называют "крокозяблики" - латинские буквы со всякими надчерками и крышечками. А при просмотре в текстовом вьюере вроде less в правильной локали русские буквы будут видны. Спасибо! Павел. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: что-то интересное с кодировками
On 2006.07.14 at 21:48:41 +0300, Pavel wrote: > Приложение тестировалось на тестовом сервере по дебианом, всё было > замечательно. Перенеся на продакшн, еще один дебиан, обнаружилось что > файлы записанные на диск невозможно прочесть, вместо русских букв там > крякозябли. Кракозябли бывают разные. Какие именно? И какая локаль была у процесса, которым файлы читали. И вообще в какой операционной системе их читали? > Стал сравнивнивать окружение на тестовом и прод. серверах и выяснил что > на тестовом сервере у процесса сервера LC_ALL=ru_RU.UTF-8, а на продакшн > - LC_ALL=C. Для пробы изменил LC_ALL на продашн - русские буквы стали > отображаться нормально. Вообще по хорошему счету LC_ALL вообще выставлять не надо. Если выставить LANG, то можно потом поменять отдельные категории, скажем LC_NUMERIC. А LC_ALL имеет более высокий приоритет. > Вот что хочу спросить, где проблема? В моём коде который генерит UTF-8 > текст и пишет его на диск или это потому что процесс у которого LC=C не > может по определению писать на диск UTF-8 текст? Скорее всего - ни там, ни там. Между твоим кодом и системным вызовом write имеется куча промежуточных слоев - всякие библиотеки классов, собственно JRE, libc и т.д. Если в файле действительно НЕ русские буквы, в чем следует убедиться просмотрев файлы на системе с заведомо известной локалью, посредством наиболее примитивного вьюера, вроде less, а то и просмотром шестнадцатиричного дампа файла (хотя не люблю читать utf-8 в шестнадцатиричном виде. UTF-16 еще куда ни шло), то проблема скорее всего в каких-нибудь промежуточных библиотеках. Еще может быть что файлы пишутся в каком-нибудь формате, предусматривающем явное указание кодировки, например XML. И из-за неверной локали стандартная функция библиотеки, формирующая файл, может залепить туда например iso8859-1 в качестве кодировки, после чего написать честные русские буквы в utf-8. Тогда честный вьюер, учитывающий информацию из заголовков, покажет то, что обычно называют "крокозяблики" - латинские буквы со всякими надчерками и крышечками. А при просмотре в текстовом вьюере вроде less в правильной локали русские буквы будут видны. > Спасибо! > Павел. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
