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 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 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 09:01:04PM +0400, Иван Лох wrote: А зачем там редактор? Ну вместо редактора я vim использую. Но то что сломали - факт. При чем сломано и для неюникодных локалей. -- WBR, Dmitry signature.asc Description: Digital signature
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 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]
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: что-то интересное с кодировками
Таки да! Все заработало с 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: что-то интересное с кодировками
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: что-то интересное с кодировками
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 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
