Author Topic: Кодировка KOI8  (Read 26021 times)

0 Members and 2 Guests are viewing this topic.

Offline alexi

  • Newbie
  • *
  • Posts: 26
  • Karma: +0/-0
Кодировка KOI8
« Reply #40 on: February 10, 2005, 17:02:25 »
Quote
Упорядочена как? По алфавиту или по частоте использования?
Если первое, то никакой выгоды не вижу...
[snapback]920[/snapback]

По алфавиту.
Выгода первая
Сортировка по алфавиту вверх или вниз выполняется простым сравнением.
(Меньше-больше) Соответственно скорость сортировки недостижимая для кои8
Выгода вторая.
Чтобы в тексте сделать все буквы большими или наоборот маленькими надо просто прибавить или отнять 33 из кода буквы. Скорость опять же для кои8 недостижимая.

Помоему этого достаточно.

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #41 on: February 10, 2005, 23:46:37 »
Quote
Это условия кодировки. В UTF-8 и UTF-16   тоже есть пробелы которые ничего не кодируют.
И еще много сделано для совместимости с UTF-8
[snapback]913[/snapback]

гм...неужто  мой склероз мне изменяет... faq читал как раз перед тем, как ответить. и там английским по белому было написано, что как раз все символы. иначе зачем там символы, для которых надо 6 байт.

Quote
Это привдет к тому, что в языке программирования, например в томже с, появится номальный класс, позволяющий по человечески работать со строками. А не так как это сделано сейчас. При правильной реализации, потерь производительности не будет.
[snapback]913[/snapback]
гм... это как так? на utf-8. даже в новейшем сишарпе оставили доступ к символу строки по индексу... на чтение. на utf-8 его нельзя реализовать за константное время.
убрать произвольный доступ вообще? они и более слабые решения не могут в стандарт пропихнуть... не будет такого, короче.

кстати, кто-нибудь знает, где взять стандарт С++ от 2003 года? там куча багов пофиксено, и найти не могу его никак... а то они денег просят за него. безобразие.

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

Мне кажется что использование виндовозной кодировки лучше как минимум по двум причинам:
1. Она упорядочена по алфавиту. По русскому алфавиту.
[snapback]914[/snapback]

спорное преимущество.

Quote
2. Линух использующий эту кодировку прозрачно и без проблем работает в виндовозных сетях. Нет проблем с переносом файлов из системы в систему и русскими названиями техже файлов.
[snapback]914[/snapback]
линух? использующий винду? нет проблем с переносом файлов из системы в систему?
не смешите мои тапочки :)
даже винда не может перенести файлы на другую винду, например, по фтп!
чего говорить о линухе... он этот маразм исправить ну никак не может... при всём желании.
(хинт: в 1251 буква 'я' имеет код 0xFF, который съедается ftp-серверами (или должен съедаться), потому что служебный.)

Quote
Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.
Ничего смешного в том, что некоторая операционная система управляет подавляющим большинством домашних и офисных компьютеров во всем мире, и базовой кодировкой для русского языка в ней считается Windows-1251. Вот и де-факто, получается.
[snapback]916[/snapback]
ещё раз. а для консольных приложений - 866. это что за ботва? предлагаем от неё отказаться?
агащазблин. используем, например, какие-нибудь общие модули в двух программах, обе, допустим, в 1251. пишем, например, в IDE. в гуе - нормально. в консоли же - кракозябры. из одного и того же модуля. переводим в 866 проект - в гуе кракозябры. какого хрена?
вот уж блин за...сь продуманное отношение. стратегия, мать её.
прикручивать костыли типа iconv не предлагать. хотя можно. но идеологически неправильно.

Quote
Если не изменяет память то по умолчанию в ОЕ именно кои8 в откправке писем стоит, а не ср1251.
[snapback]918[/snapback]

не изменяет. в это в MS Outlook Express!

Quote
По поводу  прозрачности в виндовых сетях - так и так все нормально работает - самба на лету все переводит.  И проблем с русскими названиями тоже следовательно нет.
[snapback]920[/snapback]
угу. в отличие от 1251. см. выше про фтп.

Quote
По алфавиту.
Выгода первая
Сортировка по алфавиту вверх или вниз выполняется простым сравнением.
(Меньше-больше) Соответственно скорость сортировки недостижимая для кои8
[snapback]921[/snapback]
и Вам такой "сортировки" достаточно?
нда... и зачем народ придумывает всяческие collationы и прочее в этом роде. есть же гениальная мысль использовать 1251 и сортировать там по кодам символов!

хинт для тех, кто не в курсе: косвенная сортировка ничуть не медленнее. и без неё обычно один хрен не обойтись при сортировке реальных данных по алфавиту. разве что в никому не нужных поделках, которые делают на лабораторных работах на первом курсе...

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

Quote
Выгода вторая.
Чтобы в тексте сделать все буквы большими или наоборот маленькими надо просто прибавить или отнять 33 из кода буквы. Скорость опять же для кои8 недостижимая.
[snapback]921[/snapback]

Мсье извращенец?
мало того, что так завязываться на кодировку - вредительство, за которое расстреливать - это слишком мягкое наказание, так ещё и утверждение о "недостижимости" скорости для кои8 - враньё.

вот :)

Offline alexi

  • Newbie
  • *
  • Posts: 26
  • Karma: +0/-0
Кодировка KOI8
« Reply #42 on: February 11, 2005, 10:19:35 »
Quote
гм...неужто  мой склероз мне изменяет... faq читал как раз перед тем, как ответить. и там английским по белому было написано, что как раз все символы. иначе зачем там символы, для которых надо 6 байт.
[snapback]933[/snapback]
Это в стандарте UTF8 длина символа может быть хоть 100 байт. В UTF32 длина символа жестко задана 4 байтами. Соответсвенно он не может представить те символы которые может представить UTF8.

Quote
гм... это как так? на utf-8. даже в новейшем сишарпе оставили доступ к символу строки по индексу... на чтение. на utf-8 его нельзя реализовать за константное время.
убрать произвольный доступ вообще? они и более слабые решения не могут в стандарт пропихнуть... не будет такого, короче.
[snapback]933[/snapback]

Произвольный доступ на чтение есть свойства внутренней реализации класса.
Разработчики просто оставили его доступным для ужеров этого класса. Авось пригодится. Главное это то, что доступ на запись ограничен. А читать строку вы можете как хотите.

Quote
кстати, кто-нибудь знает, где взять стандарт С++ от 2003 года? там куча багов пофиксено, и найти не могу его никак... а то они денег просят за него. безобразие.
[snapback]933[/snapback]

Нмм... Какой смысл читать стандарт на язык программирования. Читать нужно мануал на компилятор которым пользуетесь. А его описание обычно идет в поставке с компилятором. Или Вы разработчик компилятора?

спорное преимущество.
линух? использующий винду? нет проблем с переносом файлов из системы в систему?
не смешите мои тапочки :)

Quote
даже винда не может перенести файлы на другую винду, например, по фтп!
чего говорить о линухе... он этот маразм исправить ну никак не может... при всём желании.
(хинт: в 1251 буква 'я' имеет код 0xFF, который съедается ftp-серверами (или должен съедаться), потому что служебный.)
[snapback]933[/snapback]
Я не говорю что виндовозная кодировка такая хорошая и панацея. Я лишь предлагаю обсудить пути решения возникшей ситуации когда для русского я зыка существует 5 кодировок из которых только одна (виндовозная) используется на 99% компьютеров. И разумным выходом было бы использование уникода.
Во первых стандарт к которому рано или поздно перейдет таже микрософт, во вторых в ней учтен опыт предыдущих багов.

Quote
ещё раз. а для консольных приложений - 866. это что за ботва? предлагаем от неё отказаться?
[snapback]933[/snapback]

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

Quote
и Вам такой "сортировки" достаточно?
нда... и зачем народ придумывает всяческие collationы и прочее в этом роде. есть же гениальная мысль использовать 1251 и сортировать там по кодам символов!
[snapback]933[/snapback]
Согласен. Это не самое хорошее решение. Однако процессор все равно сравнивает циферки, а не буковки. Если кодовая таблица отсортирована по алфавиту, она самодостаточна. Иначе вы храните еще один массив в котором хранится использемая кодовая таблица отсортированная по алфавиту. Для кои8 это нужно. Для уникода нет.
Quote
Мсье извращенец?
[snapback]933[/snapback]

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

Offline SinClaus

  • Sr. Member
  • ****
  • Posts: 453
  • Karma: +6/-2
Кодировка KOI8
« Reply #43 on: February 11, 2005, 13:39:43 »
Однако мосье что-то путает. Жесткое реальное время - это когда детерминированное время реакции системы исчисляется в микросекундах. И причем здесь тогда бухгалтера?
И что - бухгалтера и прочие манагеры у Вас сидят под Линуксом? Тогда две таблички по 256 байт более чем достаточно для любой перекодировки KOI8, любых ограниченных ресурсов хватит, даже на ХТ-шке.
Самый страшный вирус называется юзер.

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #44 on: February 11, 2005, 14:18:59 »
Quote
Это в стандарте UTF8 длина символа может быть хоть 100 байт. В UTF32 длина символа жестко задана 4 байтами. Соответсвенно он не может представить те символы которые может представить UTF8.
[snapback]937[/snapback]
ОК. я неправильно прочитал исходную фразу.

Quote
Произвольный доступ на чтение есть свойства внутренней реализации класса.
Разработчики просто оставили его доступным для ужеров этого класса. Авось пригодится. Главное это то, что доступ на запись ограничен. А читать строку вы можете как хотите.
[snapback]937[/snapback]
так тот факт, что на разных кодировках одни и те же операции имеют разную временнУю сложность - это настоящая проблема.
и если программа работает со строками в стиле char a = s[12345], то у неё будут большие проблемы с переносимостью на utf-8. и то, что доступ на запись ограничен, при этом совершенно не принципиально.

Quote
Нмм... Какой смысл читать стандарт на язык программирования. Читать нужно мануал на компилятор которым пользуетесь. А его описание обычно идет в поставке с компилятором. Или Вы разработчик компилятора?
[snapback]937[/snapback]
гм... а переносимость? иногда она нафиг не нужна, но бывает полезна.
кроме того, стандарт именно C++ - весьма неплохо написан.
я когда плотно писал под STL, писал как раз со стандартом под рукой, и не пожалел, что использовал его (раньше смотрел в MSDN, получалось хуже).
и вообще, в мануалах на компиляторы многие тонкости не описаны. а в C++ этих тонкостей - как грязи :)

Quote
спорное преимущество.
линух? использующий винду? нет проблем с переносом файлов из системы в систему?
не смешите мои тапочки :)
[snapback]937[/snapback]
это, между прочим, я писал :)
там ещё дальше самое главное было, про фтп.

Quote
Я не говорю что виндовозная кодировка такая хорошая и панацея. Я лишь предлагаю обсудить пути решения возникшей ситуации когда для русского я зыка существует 5 кодировок из которых только одна (виндовозная) используется на 99% компьютеров. И разумным выходом было бы использование уникода.
[snapback]937[/snapback]
ничего вообще не имею против уникода.
просто кучу программ ещё надо допинывать и допинывать.

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

Quote
Во первых стандарт к которому рано или поздно перейдет таже микрософт, во вторых в ней учтен опыт предыдущих багов.
Микросовт уже лет этак 5 назад сказала, что отказывается поддерживать в своих системах консольные приложения.
[snapback]937[/snapback]
не знаю. может, конечно, это и так. не слышал. но в таком случае на хрена они сами добавили в xp такую кучу консольных приложений, что просто ваще... сетевые интерфейсы теперь можно из батников поднимать, как в любом юниксе. кучу всего другого делать. более того, в недрах их хелпа это подробно описано.

Quote
И если вы их используете это целиком ваши проблемы.  Консоль оставлена для системных нужд.  А все системные нужды обслуживаются на английском. Простой юзер туда не полезет, а админ знает английский.
К тому же 866 кодировка ИБМовская а не мирософтовская.
[snapback]937[/snapback]

какая разница чья? дело-то в том, что она до сих пор используется в микрософтовских же продуктах.

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

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

и люди должны уметь автоматизировать выполнение своей работы, обычные пользователи, а не только администраторы. а с микрософтом странно получается: отказаться-отказались, а вменяемой альтернативы не предложили... сопоставимой по трудоёмкости.

Quote
Согласен. Это не самое хорошее решение. Однако процессор все равно сравнивает циферки, а не буковки. Если кодовая таблица отсортирована по алфавиту, она самодостаточна. Иначе вы храните еще один массив в котором хранится использемая кодовая таблица отсортированная по алфавиту. Для кои8 это нужно. Для уникода нет.
[snapback]937[/snapback]
юникод сам по себе ничем не плох. ещё программ только мало. речь идёт о том, что если не завязываться на юникод, один хрен нельзя полагаться на то, что будет одна кодировка (почти всегда, кроме ограниченного круга задач). потому что при расширении системы запросто можно натолкнуться на трудно преодолеваемые грабли.

Quote
Месье пишет программы работающие в режиме жесткого реального времени в условиях ограниченных ресурсов.
Существующий сейчас реальный и быстрый выход - отказаться от использования русского языка в таких системах.
Только вот у него есть свора бухгалтеров и других менегеров которые в англиской раскладке клавиатуры печатают по одному символу в 3 минуты.
[snapback]937[/snapback]
ой... прямо таки жёсткого? ещё и на винде? :) (сужу по тому, что предлагается 1251, в этом могу быть неправ).
и вообще, интересная связка: жесткое реальное время + бухгалтеры.


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

Offline alexi

  • Newbie
  • *
  • Posts: 26
  • Karma: +0/-0
Кодировка KOI8
« Reply #45 on: February 11, 2005, 14:21:25 »
Quote
Однако мосье что-то путает. Жесткое реальное время - это когда детерминированное время реакции системы исчисляется в микросекундах.
[snapback]939[/snapback]

Жесткое реальное время это когда реакция системы достаточно быстра для обработки запросов. При этом не должно возникать ситуаций когда запрос может быть потерян или не хватит времени на его обработку.
Это время может исчисляться секундами.

Quote
И причем здесь тогда бухгалтера?
И что - бухгалтера и прочие манагеры у Вас сидят под Линуксом? Тогда две таблички по 256 байт более чем достаточно для любой перекодировки KOI8, любых ограниченных ресурсов хватит, даже на ХТ-шке.
[snapback]939[/snapback]

Бухгалтера сидят под виндой. Но их я привел для примера. В целом при создании интерфейса с пользователем необходимо использовать русский язык.  Или создавать отчеты о неполадках на томже русском языке (ну это может делать и система повыше и помощнее). Но интерфейс все равно должен быть русский. Вот тут и вылазеет, что линух русифицирован через кои8, а на верху система работает с виндой и в другой кодировке.
А теперь представьте себе, например, киоск по продаже билетов. Центральный сервер под  MSSQL, рабочие места под виндой. Служба расписаний под виндой. все это под виндой потому, что бухгалтерия работает в 1С.  Потомучто программисты работают в Делфи, и нормального юникса в глаза не видели или не умеют писать для него программы.
А вот киоск работает на 486 проце. Но он должен общаться со всей сетью в реале и говорить с пользователем по русски.
Это пример когда русский язык критичен, и критична схема кодирования.
При наличии единого стандарта на кодировку проблем не будет. А сейчас везде  эту проблему надо решать. Везде использовать перекодировку.

----------------------------
Мы живем в мире, который вокруг нас.
Давайте попробуем сделать его чуточку лучше.

Offline mars

  • Sr. Member
  • ****
  • Posts: 302
  • Karma: +0/-0
Кодировка KOI8
« Reply #46 on: February 11, 2005, 15:15:05 »
Насколько я помню, кои8 создавалась с расчетом на то, что не все программы поддерживали 8-битный алфавит (некоторые тупо записывали в 8-ой бит 0), а если в кои8 поставить 8-ой бит в 0, то получается нормальный транслит, все можно и так прочитать

Offline SinClaus

  • Sr. Member
  • ****
  • Posts: 453
  • Karma: +6/-2
Кодировка KOI8
« Reply #47 on: February 11, 2005, 15:43:10 »
Quote
А вот киоск работает на 486 проце. Но он должен общаться со всей сетью в реале и говорить с пользователем по русски.
Ну зачем же из-за киоска затевать передел мира? Такой флейм породили!
Есть два решения проблемы:
1. Киоски и даже банкоматы работают на NT4 без проблем.
2. Генерите себе для киоска Линух (если уж так хочется) хоть с китайским языком в ЛЮБОЙ кодировке - благо это крайне просто.

Но причем тут все сообщество линуксоидов?
Кстати, если 486 машина - это ограниченные ресурсы, то как назвать технологические машины на 8086, которые весьма успешно управляли процессами в реальном времени!?
Самый страшный вирус называется юзер.

Offline Egor

  • Sr. Member
  • ****
  • Posts: 251
  • Karma: +0/-0
Кодировка KOI8
« Reply #48 on: February 11, 2005, 18:54:54 »
Quote
(хинт: в 1251 буква 'я' имеет код 0xFF, который съедается ftp-серверами (или должен съедаться), потому что служебный.)
Разве он служебный для протокола ftp? Если нет, то сервер его должен передать. Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".

Quote
ещё раз. а для консольных приложений - 866. это что за ботва?...
Это, вероятнее всего, недальновидная стратегия сохранения совместимости со старыми msdos приложениями.
Для изменения кодовой страницы используется команда chcp.
Затем нужно выбрать шрифт TrueType (вместо растрового) для использования cmd.exe: Заголовок окна->свойства->шрифт->Lucida console, например.
Quote
>type 1.txt
юфэр Є√ё ўр фтхёЄш я Є№фхё Є юфшэ
>chcp 1251
Текущая кодовая страница: 1251

>type 1.txt
одна тысяча двести пятьдесят один
« Last Edit: February 11, 2005, 19:07:06 by Egor »

Offline stranger

  • Hero Member
  • *****
  • Posts: 922
  • Karma: +0/-0
    • http://
Кодировка KOI8
« Reply #49 on: February 11, 2005, 19:55:34 »
Quote
Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".
[snapback]945[/snapback]
В том-то и дело, что не научились, и потом получается, что файлы содержащие "я" получаются изковеркованными.

По поводу 486 как терминал киоска на линухе... Тут вполне можно посадить перекодировку. Так как там скорее всего будет все-равно консольное приложение, с применением ncurses (так как на другое система скорее всего непотянет) то консоль легко можно настроить на отображение нужной кодировки.  И еще MSSQL случайно не может делать перекодировку на лету... Там же есть возможность настройки кодировок... Проходил курс администрирования этого зверя, но так как в последнее время им не пользуюсь все вылетело из башки.
В  том же постгресе - перекодировку можно на базу взвалить...

А переходить из-за этого на cp1251 не вижу смысла...
[span style='font-family:Geneva'][span style='font-size:8pt;line-height:100%'][span style='color:gray']Единственное условие, от которого зависит успех, есть терпение.   Л.Н.Толстой
[/span][/span][/span]

Offline stranger

  • Hero Member
  • *****
  • Posts: 922
  • Karma: +0/-0
    • http://
Кодировка KOI8
« Reply #50 on: February 11, 2005, 19:57:55 »
Quote
Насколько я помню, кои8 создавалась с расчетом на то, что не все программы поддерживали 8-битный алфавит (некоторые тупо записывали в 8-ой бит 0), а если в кои8 поставить 8-ой бит в 0, то получается нормальный транслит, все можно и так прочитать
[snapback]943[/snapback]
Именно так он и был разработан... Очень удобно было в свое время, так как не все проги поддерживали 8 бит.
[span style='font-family:Geneva'][span style='font-size:8pt;line-height:100%'][span style='color:gray']Единственное условие, от которого зависит успех, есть терпение.   Л.Н.Толстой
[/span][/span][/span]

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #51 on: February 12, 2005, 11:09:30 »
Quote
Разве он служебный для протокола ftp? Если нет, то сервер его должен передать. Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".
Это, вероятнее всего, недальновидная стратегия сохранения совместимости со старыми msdos приложениями.
Для изменения кодовой страницы используется команда chcp.
Затем нужно выбрать шрифт TrueType (вместо растрового) для использования cmd.exe: Заголовок окна->свойства->шрифт->Lucida console, например.


>type 1.txt
юфэр Є√ё ўр фтхёЄш я Є№фхё Є юфшэ
>chcp 1251
Текущая кодовая страница: 1251

>type 1.txt
одна тысяча двести пятьдесят один
[snapback]945[/snapback]

а теперь, уважаемая публика, фокус!

> type файл.txt
русские буквы
> chcp 1251
Active code page: 1251
> type файл.txt
The system cannot find the file specified.

это не говоря уже о том, что при этом процедура ввода слова "файл" c клавиатуры превращается в настоящее издевательство.


ну и, чтоб два раза не вставать...
хорошее поведение koi8 при обрезании седьмого бита - это давно не преимущество. хотя и не недостаток. хватает других преимуществ :)

Offline mars

  • Sr. Member
  • ****
  • Posts: 302
  • Karma: +0/-0
Кодировка KOI8
« Reply #52 on: February 13, 2005, 17:33:19 »
что за другие преимущества? если не секрет
а то я давно не слежу за подобными вещами ;)

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #53 on: February 13, 2005, 18:17:43 »
Quote
что за другие преимущества? если не секрет
а то я давно не слежу за подобными вещами ;)
[snapback]954[/snapback]
это общепризнанный стандарт де-факто для электронной почты, например :)
даже в аутлуке по умолчанию.

Offline Egor

  • Sr. Member
  • ****
  • Posts: 251
  • Karma: +0/-0
Кодировка KOI8
« Reply #54 on: February 14, 2005, 16:08:25 »
Quote
а теперь, уважаемая публика, фокус!

> type файл.txt
русские буквы
> chcp 1251
Active code page: 1251
> type файл.txt
The system cannot find the file specified.
...
Не ясно, в чем фокус, конечно...:) У ntfs5, с именами файлов в unicode, не должно возникать подобных проблем с кодировками. Опишите, пожалуйста, шаги и вашу среду.
Quote
это не говоря уже о том, что при этом процедура ввода слова "файл" c клавиатуры превращается в настоящее издевательство.
В чем издевательство-то? Я предупредил о необходимости использования TT-шрифта (растровый "некорректно отображает"), возможно, дополнительно необходимо использовать MUI.

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #55 on: February 14, 2005, 23:26:36 »
Quote
Не ясно, в чем фокус, конечно...:) У ntfs5, с именами файлов в unicode, не должно возникать подобных проблем с кодировками. Опишите, пожалуйста, шаги и вашу среду.
[snapback]972[/snapback]

гм... нда, на FAT32 ломается...
и на шрифте по умолчанию тоже.

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

Quote
В чем издевательство-то? Я предупредил о необходимости использования TT-шрифта (растровый "некорректно отображает")
[snapback]972[/snapback]
действительно.

Offline netme

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
Кодировка KOI8
« Reply #56 on: February 18, 2005, 21:46:57 »
Интересная битва получается из-за такого мелкой (но основополагающей :) ) вещи как кодировка. Много слов о том что мало программ использующих Unicode and UTF8,16,32. Прошу обратить внимание на топик: автор и предлагает расширить круг таких приложений.
Я так полагаю что основные программы которые должны поддерживать аля уникод - это компилятор вашего языка, и строковая библиотека ОС. А все остальные программы (ничего не поделаешь) используют ее транспоретно, как это происходит когда вы сегодня пишите гуишную, консольную, еще какую-нибудь программу.
У о вопросах быстродействия вам предлагаю не задумываться, так как быстродействие железа не компетенция программистов (в специальных случаях не используют шир.-потреб.)

Offline Victor Snezhko

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +0/-0
Кодировка KOI8
« Reply #57 on: February 19, 2005, 17:22:14 »
Quote
Интересная битва получается из-за такого мелкой (но основополагающей :) ) вещи как кодировка. Много слов о том что мало программ использующих Unicode and UTF8,16,32. Прошу обратить внимание на топик: автор и предлагает расширить круг таких приложений.
[snapback]1047[/snapback]
а кто будет переписывать все эти программы?

Quote
Я так полагаю что основные программы которые должны поддерживать аля уникод - это компилятор вашего языка, и строковая библиотека ОС. А все остальные программы (ничего не поделаешь) используют ее транспоретно, как это происходит когда вы сегодня пишите гуишную, консольную, еще какую-нибудь программу.
У о вопросах быстродействия вам предлагаю не задумываться, так как быстродействие железа не компетенция программистов (в специальных случаях не используют шир.-потреб.)
[snapback]1047[/snapback]
а причём тут быстродействие железа? речь-то идёт о том, что во многих программах строки рассматриваются как массивы, и обращение идёт по номеру, и в кодировке UTF-8 при этом сложность такого обращения возрастает от константной до линейной, то есть для того, чтобы произвести обращение, надо всю строку просмотреть до этого места.
в этом смысле UTF-8 принципиально отличается от UTF16/UTF32.
но она хоть заставляет писать правильно :)
а во всех остальных кодировках на правильность можно класть.