Народ, что вы думаете по поводу добровольного отказа от кодировки КОИ8?Ну уж нет... Пусть кои8 остается... Вообще-то кои8 появилось раньше - это потом винда приперлась со своими стандартами...
Я понимаю очень сложно отказаться от накопленных текстов и прочее, но приведение русификации линуха к стандарту предполагает соглашение между всем участниками процесса - и разработчиками, и пользователями. А КОИ8 во многих случаях неудобна.[snapback]802[/snapback]
Ну уж нет... Пусть кои8 остается... Вообще-то кои8 появилось раньше - это потом винда приперлась со своими стандартами...
Да и сейчас какже я начинаю материться когда какой-нибудь юзверь присылает почту в юникоде с какого-нибудь ненастроенного аутлука...[snapback]806[/snapback]
Ну так вот чтобы не материться в таких случаях и придумали стандарты.А ты представляешь если сейчас весь спам будут посылать в юникоде... Как ты думаешь что будет с сетями?
КОИ8 можно заменить на уникод. К нему и виндовозная кодировка близка, и перенос файлов между системами можно будет легко производить.
И потом а чем собственно так хороша КОИ8? Помоему таже виндовозная кодировка удобнее в разы. Я не говорю об уникоде который вроде как тянет на стандарт, а юникс вроде как тоже жестко стандартизованная система.
С сегодняшнего дня ни строчки не пошлю по емайлу в КОИ8.[snapback]807[/snapback]
а у меня UTF-8 - проблем много, зато более удобна, чем KOI8И в чем енто удобство выражается?[snapback]815[/snapback]
а у меня UTF-8 - проблем много, зато более удобна, чем KOI8Странное удобство. :blink:[snapback]815[/snapback]
И потом а чем собственно так хороша КОИ8? Помоему таже виндовозная кодировка удобнее в разы.[snapback]807[/snapback]
С сегодняшнего дня ни строчки не пошлю по емайлу в КОИ8.Лично я уже давно письма отправляю _только_ в кои8 ;)[snapback]807[/snapback]
Лично я пользуюсь только двумя языками - русским и английским, и меня вполне устраивает KOI8-R для работы с русским. Автору видимо заняться нечем...Флейм http://www.sysadmin.tomsk.ru/index.php?showtopic=96 (http://www.sysadmin.tomsk.ru/index.php?showtopic=96) как-то сам собой затих. (После того как все высказались по второму кругу ;))[snapback]829[/snapback]
Флейм http://www.sysadmin.tomsk.ru/index.php?showtopic=96 (http://www.sysadmin.tomsk.ru/index.php?showtopic=96) как-то сам собой затих. (После того как все высказались по второму кругу ;))Это разве флейм ...
И вот новая тем для холивара, теперь уже на почве кодировок. :angry:[snapback]830[/snapback]
Это разве флейм ...Да если все было бы так просто, то я за UTF-8. Но при переходе на UTF-8 вылезает такая куча проблем, что лучше уж оставаться на koi8-r.
А UTF это что ни говори шаг вперед и шаг к примирению (разных систем). Причем гдето читал, у англоязычных разработчиков вызывает недоумение, что те, из-за кого всю эту байду с внедрением юникода и заварили не особо торопятся его внедрять ;)[snapback]832[/snapback]
Винда "не впереди планеты всей".Windows NT, начиная с NT4, работает на Unicode. Все поддерживающие Unicode программы win32 не испытывают проблем с кодировками.
... работать с этими файлами под виндой не удобно (элементарное исправление двух слов в текстовом редакторе) ...Поставляющийся с Windows 2000 текстовый редактор "Блокнот" превосходно работает и с UTF-8 и с Unicode. Что "не удобно" -- не понятно.
Резюме. UTF -- это хорошо, но еще рано.Не только "переходный" UTF-8, но и Unicode (UCS) уже давно и успешно используются.
Для перехода на UTF нужно чтобы все ПО могло с этой кодировкой работать, и в этом отношении Винда "не впереди планеты всей".[snapback]835[/snapback]
Как видите винда присутствует в чистом виде.В том-то и дело что с win1251, а уникод здесь причем. Что еще печальнее, так это
А вообщето я немного програмлю под винду. Так вот там по умолчанию все стоит в уникоде. Чтобы написать прогу без поддержки этого самого уникода надо постараться.
Кстати, если компьютер включен в сеть с виндовозными машинами, а не стоит отдельно, разве половина служб (а то и все) на нем не работают с win1251?[snapback]840[/snapback]
В том-то и дело что с win1251, а уникод здесь причем. Что еще печальнее, так этоM$ придумали новый протокол, CIFS называется. Все винды начиная с w2k по нему общаются. Там всё в unicode.
client code page = 866 в самбе. Т.к. этот протокол до сих пор пользует 866.
В общем-то свое мнение я высказал... Я еще немного подожду, пока дествительно подавляющее большинство приложение не будут работать с уникодом нормально.[snapback]841[/snapback]
...Я еще немного подожду, пока дествительно подавляющее большинство приложение не будут работать с уникодом нормально.Не стоит также забывать о проблеме курицы/яйца: если все будут ждать, то в Unicode не будет потребности, если не будет потребности, то разработчики откажутся от поддержки Unicode, если разработчики откажутся от поддержки Unicode, то пользователи не будут использовать Unicode.
Поставляющийся с Windows 2000 текстовый редактор "Блокнот" превосходно работает и с UTF-8 и с Unicode. Что "не удобно" -- не понятно.[snapback]838[/snapback]
Как обычно, правильным порядком перехода от используемых стандартов к новым является выбор в пользу последних при развертывании новых систем, и то если все остальные условия равны, и не накладываются ограничения совместимости. Вполне очевидно, что переход осуществляется постепенно, безо всяких революций "давайте откажемся".[snapback]843[/snapback]
Как непонятно? блокнот - это удобно?? :)Чтобы исправить два слова ("элементарное исправление двух слов в текстовом редакторе") - да, вполне удобный.
не говоря уже о том, что он концы строк 0x0A не воспринимает...Во-первых, признаком конца строки не только в Windows является сочетание 0x0d+0x0a (CR+LF), а не 0x0a. Это оптимизация Unix - использовать только один байт вместо положенных двух.
Чтобы исправить два слова ("элементарное исправление двух слов в текстовом редакторе") - да, вполне удобный.Э.... а может это придумка Билли использовать два символа для обозначения конца строки. Unix, то по старее винды будет.
Во-первых, признаком конца строки не только в Windows является сочетание 0x0d+0x0a (CR+LF), а не 0x0a. Это оптимизация Unix - использовать только один байт вместо положенных двух.
Во-вторых, если возникла необходимость править такие "оптимизированные" файлы в Windows - существует Wordpad.[snapback]855[/snapback]
Э.... а может это придумка Билли использовать два символа для обозначения конца строки.Нет, конечно.
RFC 20 ASCII format for Network Interchange October 1969Как видно из цитаты, управляющий символ LF служит для смещения места печати вниз на одну строчку, а CR служит для перемещения на начало строки. Вместе CRLF как раз и дает NL (New Line, новая строка), означающее смещение вниз на одну строку и перемещение на начало строки.
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.)
Получается, что Windows следует RFC#20, а Unix нет.[snapback]859[/snapback]
самое интересное то, что обычный UTF-8 это не предел мечтаний и надежд:)) это переходый этап переходного этапа:). Щастье наступит никак не раньше тотального перехода на UCS4 (32 бита на символ).[snapback]890[/snapback]
Хотя письма от пользователей аутлука, особенно злоупотребляющих творчеством это действительно ужас, но не столько из-за кодировки, а из-за собственного представления о стандартах. Вот с этим надо действительно боротьсяАга, мало того, что MIME любят, дак ещё и HTML по умолчанию :angry:
Гм... UTF-8 неплохо экономит память.
а если ещё и не использовать произвольный доступ к строкам (который всё равно есть зло), то больше него ничего и не надо.
я вот не понимаю, зачем нужен UCS4 (ака UTF-32 :)), когда есть UTF-8... AFAIK, нет в UCS4 таких символов, которые нельзя было бы представить в UTF-8.[snapback]891[/snapback]
Ага, мало того, что MIME любят, дак ещё и HTML по умолчанию :angry:да ладно еще если бы там стандартный хтмл был ... аутлуковское мракобесие которое мне тут недавно прислали кхтмлный движок Kmail'a показать нормльно не смог, а он местами правильней мозиллы рендерит.[snapback]894[/snapback]
<!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>
Я так понял из описания стандарта что UTF-16 исторически первый стандарт от которого предлагают отказаться.
UTF-8 описывает кодировку всех современных письменных языков, а UTF-32 кроме современных языков включает в себя и письмо на мертвых или искуственных языках.[snapback]895[/snapback]
Кроме того UTF-8 совместим со всеми и вся и рекомендуется для использования в интернете.некоторые просто работают со строками через задницу - обращаются к символам строки по индексу, для таких программ UTF-8 может привести к нефиговым потерям производительности. потому что разное количество байт на символ тратится в зависимости от символа.[snapback]895[/snapback]
неа, в UTF-8 представим весь юникод, включая все эти мёртвые языки. просто для US-ASCII место расходуется байт на символ, для более редких символов - 2 байта, и так до 6 байт для совсем извращенских языков.Это условия кодировки. В UTF-8 и UTF-16 тоже есть пробелы которые ничего не кодируют.
а UTF-32, кстати, насколько я вычитал в кембриджском UTF-8 FAQ, не весь юникодный набор символов может представить. есть там ограничения почему-то...[snapback]911[/snapback]
некоторые просто работают со строками через задницу - обращаются к символам строки по индексу, для таких программ UTF-8 может привести к нефиговым потерям производительности. потому что разное количество байт на символ тратится в зависимости от символа.Это привдет к тому, что в языке программирования, например в томже с, появится номальный класс, позволяющий по человечески работать со строками. А не так как это сделано сейчас. При правильной реализации, потерь производительности не будет. А все что нельзя запихать в строку в стандарте заране оговорено. И потом если линух уже может работать с уникодом, значит проблемы так или иначе решили. Просто надо документацию читать, и использовать предлагаемые возможности, а не по старинке.
не так с UTF-16/UTF-32: в них всегда 2/4 байта на символ соответственно. поэтому проще. с другой стороны, не все UTF16/UTF32-строки можно запихать в сишную строку обычную.[snapback]911[/snapback]
в итоге вывод один, что пока весь софт не будет нормально работать с utf-8, русские так и останутся на koi8-r ;)[snapback]912[/snapback]
КОИ-8 была раньше придумана, вообще-то.Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.
А то, что навязали винды, считать как за "де факто", простите, смешно.
Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.Ладно другой аргумент ... KOI8-R считалась и считается стандартом для юникс систем и передачи данных в Интернет.
Ничего смешного в том, что некоторая операционная система управляет подавляющим большинством домашних и офисных компьютеров во всем мире, и базовой кодировкой для русского языка в ней считается Windows-1251. Вот и де-факто, получается.[snapback]916[/snapback]
Объясните мне. Чем KOI8-R лучше тойже win1251?Упорядочена как? По алфавиту или по частоте использования?
Мне кажется что использование виндовозной кодировки лучше как минимум по двум причинам:
1. Она упорядочена по алфавиту. По русскому алфавиту.
2. Линух использующий эту кодировку прозрачно и без проблем работает в виндовозных сетях. Нет проблем с переносом файлов из системы в систему и русскими названиями техже файлов.[snapback]914[/snapback]
Упорядочена как? По алфавиту или по частоте использования?
Если первое, то никакой выгоды не вижу...[snapback]920[/snapback]
Это условия кодировки. В UTF-8 и UTF-16 тоже есть пробелы которые ничего не кодируют.
И еще много сделано для совместимости с UTF-8[snapback]913[/snapback]
Это привдет к тому, что в языке программирования, например в томже с, появится номальный класс, позволяющий по человечески работать со строками. А не так как это сделано сейчас. При правильной реализации, потерь производительности не будет.гм... это как так? на utf-8. даже в новейшем сишарпе оставили доступ к символу строки по индексу... на чтение. на utf-8 его нельзя реализовать за константное время.[snapback]913[/snapback]
Объясните мне. Чем KOI8-R лучше тойже win1251?
Мне кажется что использование виндовозной кодировки лучше как минимум по двум причинам:
1. Она упорядочена по алфавиту. По русскому алфавиту.[snapback]914[/snapback]
2. Линух использующий эту кодировку прозрачно и без проблем работает в виндовозных сетях. Нет проблем с переносом файлов из системы в систему и русскими названиями техже файлов.линух? использующий винду? нет проблем с переносом файлов из системы в систему?[snapback]914[/snapback]
Аргумент "раньше придумана" не является значимым, поскольку преимущества ранее придуманных над позднее придуманными не очевидны.ещё раз. а для консольных приложений - 866. это что за ботва? предлагаем от неё отказаться?
Ничего смешного в том, что некоторая операционная система управляет подавляющим большинством домашних и офисных компьютеров во всем мире, и базовой кодировкой для русского языка в ней считается Windows-1251. Вот и де-факто, получается.[snapback]916[/snapback]
Если не изменяет память то по умолчанию в ОЕ именно кои8 в откправке писем стоит, а не ср1251.[snapback]918[/snapback]
По поводу прозрачности в виндовых сетях - так и так все нормально работает - самба на лету все переводит. И проблем с русскими названиями тоже следовательно нет.угу. в отличие от 1251. см. выше про фтп.[snapback]920[/snapback]
По алфавиту.и Вам такой "сортировки" достаточно?
Выгода первая
Сортировка по алфавиту вверх или вниз выполняется простым сравнением.
(Меньше-больше) Соответственно скорость сортировки недостижимая для кои8[snapback]921[/snapback]
Выгода вторая.
Чтобы в тексте сделать все буквы большими или наоборот маленькими надо просто прибавить или отнять 33 из кода буквы. Скорость опять же для кои8 недостижимая.[snapback]921[/snapback]
гм...неужто мой склероз мне изменяет... faq читал как раз перед тем, как ответить. и там английским по белому было написано, что как раз все символы. иначе зачем там символы, для которых надо 6 байт.Это в стандарте UTF8 длина символа может быть хоть 100 байт. В UTF32 длина символа жестко задана 4 байтами. Соответсвенно он не может представить те символы которые может представить UTF8.[snapback]933[/snapback]
гм... это как так? на utf-8. даже в новейшем сишарпе оставили доступ к символу строки по индексу... на чтение. на utf-8 его нельзя реализовать за константное время.
убрать произвольный доступ вообще? они и более слабые решения не могут в стандарт пропихнуть... не будет такого, короче.[snapback]933[/snapback]
кстати, кто-нибудь знает, где взять стандарт С++ от 2003 года? там куча багов пофиксено, и найти не могу его никак... а то они денег просят за него. безобразие.[snapback]933[/snapback]
даже винда не может перенести файлы на другую винду, например, по фтп!Я не говорю что виндовозная кодировка такая хорошая и панацея. Я лишь предлагаю обсудить пути решения возникшей ситуации когда для русского я зыка существует 5 кодировок из которых только одна (виндовозная) используется на 99% компьютеров. И разумным выходом было бы использование уникода.
чего говорить о линухе... он этот маразм исправить ну никак не может... при всём желании.
(хинт: в 1251 буква 'я' имеет код 0xFF, который съедается ftp-серверами (или должен съедаться), потому что служебный.)[snapback]933[/snapback]
ещё раз. а для консольных приложений - 866. это что за ботва? предлагаем от неё отказаться?[snapback]933[/snapback]
и Вам такой "сортировки" достаточно?Согласен. Это не самое хорошее решение. Однако процессор все равно сравнивает циферки, а не буковки. Если кодовая таблица отсортирована по алфавиту, она самодостаточна. Иначе вы храните еще один массив в котором хранится использемая кодовая таблица отсортированная по алфавиту. Для кои8 это нужно. Для уникода нет.
нда... и зачем народ придумывает всяческие collationы и прочее в этом роде. есть же гениальная мысль использовать 1251 и сортировать там по кодам символов![snapback]933[/snapback]
Мсье извращенец?[snapback]933[/snapback]
Это в стандарте UTF8 длина символа может быть хоть 100 байт. В UTF32 длина символа жестко задана 4 байтами. Соответсвенно он не может представить те символы которые может представить UTF8.ОК. я неправильно прочитал исходную фразу.[snapback]937[/snapback]
Произвольный доступ на чтение есть свойства внутренней реализации класса.так тот факт, что на разных кодировках одни и те же операции имеют разную временнУю сложность - это настоящая проблема.
Разработчики просто оставили его доступным для ужеров этого класса. Авось пригодится. Главное это то, что доступ на запись ограничен. А читать строку вы можете как хотите.[snapback]937[/snapback]
Нмм... Какой смысл читать стандарт на язык программирования. Читать нужно мануал на компилятор которым пользуетесь. А его описание обычно идет в поставке с компилятором. Или Вы разработчик компилятора?гм... а переносимость? иногда она нафиг не нужна, но бывает полезна.[snapback]937[/snapback]
спорное преимущество.это, между прочим, я писал :)
линух? использующий винду? нет проблем с переносом файлов из системы в систему?
не смешите мои тапочки :)[snapback]937[/snapback]
Я не говорю что виндовозная кодировка такая хорошая и панацея. Я лишь предлагаю обсудить пути решения возникшей ситуации когда для русского я зыка существует 5 кодировок из которых только одна (виндовозная) используется на 99% компьютеров. И разумным выходом было бы использование уникода.ничего вообще не имею против уникода.[snapback]937[/snapback]
Во первых стандарт к которому рано или поздно перейдет таже микрософт, во вторых в ней учтен опыт предыдущих багов.не знаю. может, конечно, это и так. не слышал. но в таком случае на хрена они сами добавили в xp такую кучу консольных приложений, что просто ваще... сетевые интерфейсы теперь можно из батников поднимать, как в любом юниксе. кучу всего другого делать. более того, в недрах их хелпа это подробно описано.
Микросовт уже лет этак 5 назад сказала, что отказывается поддерживать в своих системах консольные приложения.[snapback]937[/snapback]
И если вы их используете это целиком ваши проблемы. Консоль оставлена для системных нужд. А все системные нужды обслуживаются на английском. Простой юзер туда не полезет, а админ знает английский.
К тому же 866 кодировка ИБМовская а не мирософтовская.[snapback]937[/snapback]
Согласен. Это не самое хорошее решение. Однако процессор все равно сравнивает циферки, а не буковки. Если кодовая таблица отсортирована по алфавиту, она самодостаточна. Иначе вы храните еще один массив в котором хранится использемая кодовая таблица отсортированная по алфавиту. Для кои8 это нужно. Для уникода нет.юникод сам по себе ничем не плох. ещё программ только мало. речь идёт о том, что если не завязываться на юникод, один хрен нельзя полагаться на то, что будет одна кодировка (почти всегда, кроме ограниченного круга задач). потому что при расширении системы запросто можно натолкнуться на трудно преодолеваемые грабли.[snapback]937[/snapback]
Месье пишет программы работающие в режиме жесткого реального времени в условиях ограниченных ресурсов.ой... прямо таки жёсткого? ещё и на винде? :) (сужу по тому, что предлагается 1251, в этом могу быть неправ).
Существующий сейчас реальный и быстрый выход - отказаться от использования русского языка в таких системах.
Только вот у него есть свора бухгалтеров и других менегеров которые в англиской раскладке клавиатуры печатают по одному символу в 3 минуты.[snapback]937[/snapback]
Однако мосье что-то путает. Жесткое реальное время - это когда детерминированное время реакции системы исчисляется в микросекундах.[snapback]939[/snapback]
И причем здесь тогда бухгалтера?
И что - бухгалтера и прочие манагеры у Вас сидят под Линуксом? Тогда две таблички по 256 байт более чем достаточно для любой перекодировки KOI8, любых ограниченных ресурсов хватит, даже на ХТ-шке.[snapback]939[/snapback]
А вот киоск работает на 486 проце. Но он должен общаться со всей сетью в реале и говорить с пользователем по русски.Ну зачем же из-за киоска затевать передел мира? Такой флейм породили!
(хинт: в 1251 буква 'я' имеет код 0xFF, который съедается ftp-серверами (или должен съедаться), потому что служебный.)Разве он служебный для протокола ftp? Если нет, то сервер его должен передать. Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".
ещё раз. а для консольных приложений - 866. это что за ботва?...Это, вероятнее всего, недальновидная стратегия сохранения совместимости со старыми msdos приложениями.
>type 1.txt
юфэр Є√ё ўр фтхёЄш я Є№фхё Є юфшэ
>chcp 1251
Текущая кодовая страница: 1251
>type 1.txt
одна тысяча двести пятьдесят один
Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".В том-то и дело, что не научились, и потом получается, что файлы содержащие "я" получаются изковеркованными.[snapback]945[/snapback]
Насколько я помню, кои8 создавалась с расчетом на то, что не все программы поддерживали 8-битный алфавит (некоторые тупо записывали в 8-ой бит 0), а если в кои8 поставить 8-ой бит в 0, то получается нормальный транслит, все можно и так прочитатьИменно так он и был разработан... Очень удобно было в свое время, так как не все проги поддерживали 8 бит.[snapback]943[/snapback]
Разве он служебный для протокола ftp? Если нет, то сервер его должен передать. Не в обиду перефразирую "все вменяемые ftp-серверы давно научились корректно обрабатывать эту ситуацию согласно существующим стандартам де-факто".
Это, вероятнее всего, недальновидная стратегия сохранения совместимости со старыми msdos приложениями.
Для изменения кодовой страницы используется команда chcp.
Затем нужно выбрать шрифт TrueType (вместо растрового) для использования cmd.exe: Заголовок окна->свойства->шрифт->Lucida console, например.
>type 1.txt
юфэр Є√ё ўр фтхёЄш я Є№фхё Є юфшэ
>chcp 1251
Текущая кодовая страница: 1251
>type 1.txt
одна тысяча двести пятьдесят один[snapback]945[/snapback]
что за другие преимущества? если не секретэто общепризнанный стандарт де-факто для электронной почты, например :)
а то я давно не слежу за подобными вещами ;)[snapback]954[/snapback]
а теперь, уважаемая публика, фокус!Не ясно, в чем фокус, конечно...:) У ntfs5, с именами файлов в unicode, не должно возникать подобных проблем с кодировками. Опишите, пожалуйста, шаги и вашу среду.
> type файл.txt
русские буквы
> chcp 1251
Active code page: 1251
> type файл.txt
The system cannot find the file specified.
...
это не говоря уже о том, что при этом процедура ввода слова "файл" c клавиатуры превращается в настоящее издевательство.В чем издевательство-то? Я предупредил о необходимости использования TT-шрифта (растровый "некорректно отображает"), возможно, дополнительно необходимо использовать MUI.
Не ясно, в чем фокус, конечно...:) У ntfs5, с именами файлов в unicode, не должно возникать подобных проблем с кодировками. Опишите, пожалуйста, шаги и вашу среду.[snapback]972[/snapback]
В чем издевательство-то? Я предупредил о необходимости использования TT-шрифта (растровый "некорректно отображает")действительно.[snapback]972[/snapback]
Интересная битва получается из-за такого мелкой (но основополагающей :) ) вещи как кодировка. Много слов о том что мало программ использующих Unicode and UTF8,16,32. Прошу обратить внимание на топик: автор и предлагает расширить круг таких приложений.а кто будет переписывать все эти программы?[snapback]1047[/snapback]
Я так полагаю что основные программы которые должны поддерживать аля уникод - это компилятор вашего языка, и строковая библиотека ОС. А все остальные программы (ничего не поделаешь) используют ее транспоретно, как это происходит когда вы сегодня пишите гуишную, консольную, еще какую-нибудь программу.а причём тут быстродействие железа? речь-то идёт о том, что во многих программах строки рассматриваются как массивы, и обращение идёт по номеру, и в кодировке UTF-8 при этом сложность такого обращения возрастает от константной до линейной, то есть для того, чтобы произвести обращение, надо всю строку просмотреть до этого места.
У о вопросах быстродействия вам предлагаю не задумываться, так как быстродействие железа не компетенция программистов (в специальных случаях не используют шир.-потреб.)[snapback]1047[/snapback]