Кодировка KOI8

[alexi]

Как обычно, правильным порядком перехода от используемых стандартов к новым является выбор в пользу последних при развертывании новых систем, и то если все остальные условия равны, и не накладываются ограничения совместимости. Вполне очевидно, что переход осуществляется постепенно, безо всяких революций "давайте откажемся".

[snapback]843[/snapback]

Да никогда мы обычным порядком не откажемся. Пока гром не грянет будем работать по старинке. А потом придет ктото вроде микросовта и будем носиться и в авральном порядке все исправлять и переделовать.
Вот у меня до сих пор RH-7.3 стоит на серваке и работает. Душа ноет обнови, но нужды в этом особой нет. И потом система работает же. А начну обновление там будет столько гемора с настройками и неизвестно как еще оно будет. Вот и стоит.

А отказываться от старой КОИ в раз я не советовал. Я просто предлагаю выработать какое-то решение позволяющее отказаться от этой кодировки постепенно. И рекомендовать его для разработчиков разного рода русификаторов и дистрибутивов.
Например, можно просто сказать, что использование кодировки КОИ8 признано морально устаревшим и не рекомендуется к использованию. Вместо нее применять, например, уникод.

Сейча все равно приходится жить под кодировкой отличной от виндовозной и решать кучу проблем когда нужно работать в смешанных системах.
Так какая разница в какую кодировку перекодировать. Зато в рамках одной системы будет порядок и согласованность со стандартами.

А то сейчас даже кде и гном по разному русифицированны.
     

   

[Dimmus]

блокнот там самое что есть лучшее, на UNIX - vim и mcedit

[Egor]

Как непонятно? блокнот - это удобно??

Чтобы исправить два слова ("элементарное исправление двух слов в текстовом редакторе") - да, вполне удобный.

не говоря уже о том, что он концы строк 0x0A не воспринимает...

Во-первых, признаком конца строки не только в Windows является сочетание 0x0d+0x0a (CR+LF), а не 0x0a. Это оптимизация Unix - использовать только один байт вместо положенных двух.
Во-вторых, если возникла необходимость править такие "оптимизированные" файлы в Windows - существует Wordpad.

[demiurg]

Чтобы исправить два слова ("элементарное исправление двух слов в текстовом редакторе") - да, вполне удобный.

Во-первых, признаком конца строки не только в Windows является сочетание 0x0d+0x0a (CR+LF), а не 0x0a. Это оптимизация Unix - использовать только один байт вместо положенных двух.
Во-вторых, если возникла необходимость править такие "оптимизированные" файлы в Windows - существует Wordpad.

[snapback]855[/snapback]

Э.... а может это придумка Билли использовать два символа для обозначения конца строки. Unix, то по старее винды будет.

А я даже под виндой gvim пользую. Так что проблем с такой оптимизацией у меня вообще нет. Vim же позволяет сохранять файлы и в том и в другом виде

[Egor]

Э.... а может это придумка Билли использовать два символа для обозначения конца строки.

Нет, конечно.
http://www.ietf.org/rfc/rfc0020.txt

RFC 20            ASCII format for Network Interchange      October 1969


      LF (Line Feed): A format effector which controls the movement of
   the printing position to the next printing line.  (Applicable also to
   display devices.) Where appropriate, this character may have the
   meaning "New Line" (NL), a format effector which controls the
   movement of the printing point to the first printing position on the
   next printing line.  [span style=\'font-size:12pt;line-height:100%\']Use of this convention requires agreement
   between sender and recipient of data.[/span]
   ...
      CR (Carriage Return): A format effector which controls the
   movement of the printing position to the first printing position on
   the same printing line.  (Applicable also to display devices.)

Как видно из цитаты, управляющий символ LF служит для смещения места печати вниз на одну строчку, а CR служит для перемещения на начало строки. Вместе CRLF как раз и дает NL (New Line, новая строка), означающее смещение вниз на одну строку и перемещение на начало строки.
LF также может сам по себе означать NL, только если это было заранее оговорено, но это не является стандартным значением LF.
Получается, что Windows следует RFC#20, а Unix нет.

[Victor Snezhko]

Получается, что Windows следует RFC#20, а Unix нет.

[snapback]859[/snapback]

сам виндовс, может, и следует, а вот его блокнот, нет. если бы он следовал, то при просмотре таких юниксных файлов должен был бы показывать только последнюю строку (и, возможно, ошмётки от предыдущих строк, если они длиннее). этого не происходит.
все вменяемые редакторы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто.
а блокнот - и стандартам не соответствует, и по-человечески не показывает.

P.S.: для редактирования конфигов он, может быть, и был бы хоть как-нибудь применим, если бы в нём был инкрементный поиск.

[Syncro]

самое интересное то, что обычный UTF-8 это не предел мечтаний и надежд:)) это переходый этап переходного этапа:). Щастье наступит никак не раньше тотального перехода на UCS4 (32 бита на символ). Некоторый софт уже использует его как внутреннюю кодировку, так что это все вопрос времени. А по поводу совместимости, ну вобщем при программировании с использовании качественных современных инстументов и последующем их использовании проблем не возникает, а недостойные умрут естественным путем:))
Хотя письма от пользователей аутлука, особенно злоупотребляющих творчеством это действительно ужас, но не столько из-за кодировки, а из-за собственного представления о стандартах. Вот с этим надо действительно бороться

[Victor Snezhko]

самое интересное то, что обычный UTF-8 это не предел мечтаний и надежд:)) это переходый этап переходного этапа:). Щастье наступит никак не раньше тотального перехода на UCS4 (32 бита на символ).

[snapback]890[/snapback]

Гм... UTF-8 неплохо экономит память.
а если ещё и не использовать произвольный доступ к строкам (который всё равно есть зло), то больше него ничего и не надо.

я вот не понимаю, зачем нужен UCS4 (ака UTF-32 , когда есть UTF-8... AFAIK, нет в UCS4 таких символов, которые нельзя было бы представить в UTF-8.

[Unit]

Хотя письма от пользователей аутлука, особенно злоупотребляющих творчеством это действительно ужас, но не столько из-за кодировки, а из-за собственного представления о стандартах. Вот с этим надо действительно бороться

Ага, мало того, что MIME любят, дак ещё и HTML по умолчанию  :angry:

[alexi]

Гм... UTF-8 неплохо экономит память.
а если ещё и не использовать произвольный доступ к строкам (который всё равно есть зло), то больше него ничего и не надо.

я вот не понимаю, зачем нужен UCS4 (ака UTF-32 , когда есть UTF-8... AFAIK, нет в UCS4 таких символов, которые нельзя было бы представить в UTF-8.

[snapback]891[/snapback]

Я так понял из описания стандарта что UTF-16 исторически первый стандарт от которого предлагают отказаться.
UTF-8 описывает кодировку всех современных письменных языков, а UTF-32 кроме современных языков включает в себя и письмо на мертвых или искуственных языках.
Кроме того UTF-8 совместим со всеми и вся и рекомендуется для использования в интернете.
Я думаю что для русского языка и в сложившихся условиях это хороший выход.

[Syncro]

Ага, мало того, что MIME любят, дак ещё и HTML по умолчанию  :angry:

[snapback]894[/snapback]

да ладно еще если бы там стандартный хтмл был ... аутлуковское мракобесие которое мне тут недавно прислали кхтмлный движок Kmail'a показать нормльно не смог, а он местами правильней мозиллы рендерит.
// открыл опенофис и экспортировал документ в HTML, получилось:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
   <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1251">
   <TITLE></TITLE>
   <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.1  (Win32)">
   <META NAME="CREATED" CONTENT="20050209;11325457">
   <META NAME="CHANGED" CONTENT="20050209;11330935">
   <STYLE>
   <!--
  @page { size: 21cm 29.7cm; margin: 2cm }
  P { margin-bottom: 0.21cm }
   -->
   </STYLE>
</HEAD>
<BODY LANG="ru-RU" DIR="LTR">
<P STYLE="margin-bottom: 0cm">uyiotyiugjhi</P>
</BODY>
</HTML>

вот это я называю следованием стандартам, попробуйте тоже самое сделать в ворде:))

[Victor Snezhko]

Я так понял из описания стандарта что UTF-16 исторически первый стандарт от которого предлагают отказаться.
UTF-8 описывает кодировку всех современных письменных языков, а UTF-32 кроме современных языков включает в себя и письмо на мертвых или искуственных языках.

[snapback]895[/snapback]

неа, в UTF-8 представим весь юникод, включая все эти мёртвые языки. просто для US-ASCII место расходуется байт на символ, для более редких символов - 2 байта, и так до 6 байт для совсем извращенских языков.
а UTF-32, кстати, насколько я вычитал в кембриджском UTF-8 FAQ, не весь юникодный набор символов может представить. есть там ограничения почему-то...

Кроме того UTF-8 совместим со всеми и вся и рекомендуется для использования в интернете.

[snapback]895[/snapback]

некоторые просто работают со строками через задницу - обращаются к символам строки по индексу, для таких программ UTF-8 может привести к нефиговым потерям производительности. потому что разное количество байт на символ тратится в зависимости от символа.
не так с UTF-16/UTF-32: в них всегда 2/4 байта на символ соответственно. поэтому проще. с другой стороны, не все UTF16/UTF32-строки можно запихать в сишную строку обычную.

[Dimmus]

в итоге вывод один, что пока весь софт не будет нормально работать с utf-8, русские так и останутся на koi8-r

[alexi]

неа, в UTF-8 представим весь юникод, включая все эти мёртвые языки. просто для US-ASCII место расходуется байт на символ, для более редких символов - 2 байта, и так до 6 байт для совсем извращенских языков.
а UTF-32, кстати, насколько я вычитал в кембриджском UTF-8 FAQ, не весь юникодный набор символов может представить. есть там ограничения почему-то...

[snapback]911[/snapback]

Это условия кодировки. В UTF-8 и UTF-16   тоже есть пробелы которые ничего не кодируют.
И еще много сделано для совместимости с UTF-8 Все что можно представить в нем, в нем и должно быть представлено.

некоторые просто работают со строками через задницу - обращаются к символам строки по индексу, для таких программ UTF-8 может привести к нефиговым потерям производительности. потому что разное количество байт на символ тратится в зависимости от символа.
не так с UTF-16/UTF-32: в них всегда 2/4 байта на символ соответственно. поэтому проще. с другой стороны, не все UTF16/UTF32-строки можно запихать в сишную строку обычную.

[snapback]911[/snapback]

Это привдет к тому, что в языке программирования, например в томже с, появится номальный класс, позволяющий по человечески работать со строками. А не так как это сделано сейчас. При правильной реализации, потерь производительности не будет. А все что нельзя запихать в строку в стандарте заране оговорено. И потом если линух уже может работать с уникодом, значит проблемы так или иначе решили. Просто надо документацию читать, и использовать предлагаемые возможности, а не по старинке.
Кстати, прекрасный повод к совершенствованию.

[alexi]

в итоге вывод один, что пока весь софт не будет нормально работать с utf-8, русские так и останутся на koi8-r

[snapback]912[/snapback]

Объясните мне. Чем KOI8-R лучше тойже win1251?

Мне кажется что использование виндовозной кодировки лучше как минимум по двум причинам:
1. Она упорядочена по алфавиту. По русскому алфавиту.
2. Линух использующий эту кодировку прозрачно и без проблем работает в виндовозных сетях. Нет проблем с переносом файлов из системы в систему и русскими названиями техже файлов.

[Unit]

КОИ-8 была раньше придумана, вообще-то.

А то, что навязали винды, считать как за "де факто", простите, смешно.

[Egor]

КОИ-8 была раньше придумана, вообще-то.

А то, что навязали винды, считать как за "де факто", простите, смешно.

Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.
Ничего смешного в том, что некоторая операционная система управляет подавляющим большинством домашних и офисных компьютеров во всем мире, и базовой кодировкой для русского языка в ней считается Windows-1251. Вот и де-факто, получается.

[Unit]

Ладно, спорить не буду. Давным-давно я негативно к КОИ относился. Потом начал знакомиться с unix-миром и понял, что там оно всё ещё да что-то значит.

Но, боюсь, в ближайшее время маловероятно, что она исчезнет. Если не изменяет память то по умолчанию в ОЕ именно кои8 в откправке писем стоит, а не ср1251.

[stranger]

Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.
Ничего смешного в том, что некоторая операционная система управляет подавляющим большинством домашних и офисных компьютеров во всем мире, и базовой кодировкой для русского языка в ней считается Windows-1251. Вот и де-факто, получается.

[snapback]916[/snapback]

Ладно другой аргумент ... KOI8-R считалась и считается стандартом для юникс систем и передачи данных в Интернет.

Плюс ко всему, если винда не могет коректно работать с кои я не виноват. Или точнее я не виноват, что кто-то не может работать в винде с линуксом.
А то, что на домашних и офисных компах стоит винда - это тоже не аргумент - зато на серверах стоят юникс-подобные в основном.

Я например, спокойно работаю с файлами расположенными на линухе в винде и меня это не беспокоит. Как по самбе, так и по фтп.

[stranger]

Объясните мне. Чем KOI8-R лучше тойже win1251?

Мне кажется что использование виндовозной кодировки лучше как минимум по двум причинам:
1. Она упорядочена по алфавиту. По русскому алфавиту.
2. Линух использующий эту кодировку прозрачно и без проблем работает в виндовозных сетях. Нет проблем с переносом файлов из системы в систему и русскими названиями техже файлов.

[snapback]914[/snapback]

Упорядочена как? По алфавиту или по частоте использования?
Если первое, то никакой выгоды не вижу...

По поводу  прозрачности в виндовых сетях - так и так все нормально работает - самба на лету все переводит.  И проблем с русскими названиями тоже следовательно нет.