Pull to refresh

Comments 23

Думаю, дело в финансовой стороне проблемы. Unicode требует в 2 раза больше памяти, а память стоит денег (и дисковая и ОЗУ)

Тут зависит от типа Unicode кодировки. UTF-8 совместима с 7ми битными символами, а остальные могут занимать от 2 до 6 байт(используется правда только до 4х).
Тут ИМХО больше дело с сложности обработки, да и возможно не думали обо всё этом когда первые компьютеры/OS делали. А вот когда это по миру расползаться начало вот тут и возникли проблемы.
А разве кириллические символы в UTF-8 не по два байта занимают? Возможно, для некоторых языков могла получиться экономия, но, действительно, повышенная сложность алгоритмов ее нивелировала бы. Те же «простые англоязычные читатели» не поймут — для них не изменится память, но изменятся прошивки всех телефонов.
В UTF-8 кириллица занимает 2 байта, откуда взялось сомнение?
Unicode <...> поэтому нет необходимости перекодировать
почему это нету? юникод это просто [виртуальная] таблица символов, в компьютере остаются тоже «кодировки» (utf-8 или там utf-16, например).
(подробнее об Unicode см следующую запись в журнале)
ой, как неловко спалился кросспостинг)
А вот меня давно мучает такой ламерский вопросик) Извиняюсь, если немного не в тему.
Храню матричный принтер 1994 года Epson LX1050+, рабочий. Есть комп с XP и LPT-портом.
Принтер с этого компьютера печатает только в графическом режиме. А можно ли заставить его печатать из-под windows именно в текстовом, не загружаясь в DOS?
Думаю можно если печатать «мимо» драйвера, то есть открыть LPT порт и слать туда текст+управляющие символы.
Именно так, см его встроенные шрифты, и команды всякие esc/pos, табуляторы и прочее… Там весьма хитро все накручено… Я так со старым HP баловался… тумблерами набирая байты!
Стандарт EPSON ESC/P вам в помощь. Ну и прямой доступ к lpt обязательно потребуется. Кстати, в режиме 9pin (как правило это нулевой шрифт в памяти) ваш матричник будет фигачить с первой комической скоростью, чего нельзя сказать о «красивых» вшитых шрифтах (всякие Sans и Times ) — на них производительность падает ниже плинтуса.
Ее особенностью было то, что если у русского символа пропадал 8-й бит, то получившийся в результате «обрезания» английский символ будет созвучен исходному русскому

Этот трюк КОИ-8 позаимствовала из 5-битного телеграфного кода МТК-2.

Мне тут недавно пришло письмо в семибитном US-ASCII с обрезанным 8-м битом. К сожалению, исходная кодировка была Windows-1251, и все русские буквы превратились в тыкву — стали совершенно нечитаемы. Адресат уже ушел домой, и пришлось писать скрипт для восстановления бита (-:
Можно обойтись и без скрипта :)

$ echo ophber | iconv -f koi-7 -t koi-8 | iconv -f cp1251
привет
C KOI7/8 дело имел, читал статьи Чижова, а про МТК-2, к сожалению, не слышал. Возможно, он «дедушка» семейства KOI… Спасибо.
Во как — на улице 21-й век, Unicode шагает по миру,
а кто-то всерьёз задумывается о судьбе самого дорогого способа передачи 140 байт.
ASCII вообще-то появился еще в 60-х и был предназначен для телетайпа. Отсюда такие экзотические кода как раздельные CR и LF — первый смещает каретку к началу строки, а второй прокручивает бумагу на одну строчку вниз, это совершенно логично на механической печатной машинке. Еще пример — Rubout (127), поскольку стереть символ с бумаги невозможно, его при необходимости просто забивали черным квадратиком. Из 32 управляюших символов сейчас используется только четыре, остальные были нужны именно для телетайпа с механической клавиатурой. Оттуда же кстати контроль четности по 8-му биту, видимо помехи на линии были серьезной проблемой.
Мне изложение этого материала показалось очень странным, потому что с одной стороны, он претендует на ретроспективу, то есть на обзор исторического развития ситуации, а с другой — повествование часто перескакивает с одного на другое. И это не единственная проблема.

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

Кроме того, в тексте не до конца однозначно прояснен вопрос с различиями между кодовыми страницами (code page), наборами символов (character set) и кодировками (encoding). Набор символов — это просто символы, без указания того, как их следует хранить. Кодовая страница — это таблица соответствия набора символов, их кодов и способа хранения этих кодов. А кодировка — это, строго говоря, способ хранения этих кодов сам по себе.
Так например, набор символов Unicode может быть записан в кодовой странице 65001 (по версии Microsoft) с использованием кодировки UTF-8.

Ну и последний «детский» вопрос о том, почему сразу не использовать Unicode, весьма странен, как и ответ на него. В шестидесятых годах не было никакого Unicode, а идея об общем наборе символов получила первую практическую реализацию только в конце восьмидесятых, став официальным стандартом только в 1991-м. Невозможно использовать то, чего нет.
Кроме того, нельзя забывать о серьезном «телеграфном наследии» компьютеров, использовавших текстовый режим и о том, что многоязычность и по сей день не так уж и востребована в общем случае, так что в том, чтобы на дисплее (и на принтерах, которые тоже весьма долго были, главным образом, текстовыми) сразу отображались символы на многих языках, практической нужды не было, а сделать эту возможность «довеском» было бы, действительно, слишком дорого.
Спасибо все читателям за проявленный интерес (на LiveJournal статья пролежала 3 года практически без откликов). Я хотел написать не научный трактат, а популярную статью о кодировках с балансом между точностью, объемом и незанудностью. Насколько это [не] удалось — судить Вам, уважаемые читатели.

Не могу согласиться с формулировкой: «Кодовая страница — это таблица соответствия набора символов, их кодов и способа хранения этих кодов. А кодировка — это, строго говоря, способ хранения этих кодов сам по себе». Мне ближе формулировка из Википедии: "Кодовая страница (англ. code page) — таблица, сопоставляющая каждому значению байта некоторый символ (или его отсутствие)". В этом случае термины «Кодировка» и «кодовая страница» по сути синонимы (не абсолютные, но очень близкие). Мне кажется, важнее понимать, что это такое и с чем это едят, чем спорить о том, какая формулировка правильная.

Насчет некорректности «детского» вопроса «Почему не использовали Unicode» я соглашусь. Но вопрос «почему в персональных ОС не использовали 16-битную кодировку, ведь их предполагалось продавать по всему миру?» меня интересовал. Свою точку зрения я написал, но если кто знает «почему» из более авторитетных источников, напишите, пожалуйста — я буду только рад.
Мне ближе формулировка из Википедии: «Кодовая страница (англ. code page) — таблица, сопоставляющая каждому значению байта некоторый символ (или его отсутствие)».
Википедия — не шибко авторитетный источник. Тут сразу, например, возникает вопрос — причём тут байт? Особенно в свете упомянутых кои-7, utf-8 итд. В той же английской википедии уже несколько по-другому: «a code page is a table of values that describes the character set used for encoding a particular set of glyphs», что более правильно, и ближе всё же к первой процитированной формулировке.

Кодовая страница — это, опять же, виртуальная таблица номер-символ. А кодировка уже переводит эти номера в байты(числа). Например, обычно 8-битные кодировки являются простым сопоставлением этого номера символа в число 0..255. Но это не обязательно, примеры есть и в самой статье.
Не хочу погружаться дебри и спорить о тонкостях и точности перевода. Читатель, если захочет, может без труда найти тот вариант, который ему больше нравится.
По поводу кодировки и кодовой страницы вам уже написали, что англоязычная Википедия отражает суть лучше, потому что это не синонимы (хотя и употребляются в синонимичном значении многими). Я не зря в своем комментарии привел и соответствующие англоязычные термины: они употребляются обычно в более точном строгом значении, а в русском языке при заимствовании смысл был «размыт». Повторю: encoding, кодировка — это способ хранения номеров символов. Например, можно сказать: «семибитная кодировка» или «двухбайтовая кодировка», «мультибайтовая кодировка» — это все способы хранения номеров символов кодовой страницы. Так что чтобы «понимать, что это такое», нужно понимать сразу точно — это не добавляет сложности, зато добавляет ясность и избавляет от разночтений и недопониманий.

Что касается того, почему нельзя было пользоваться сразу шестнадцатибитной кодировкой — я уже также сказал об этом. В те времена, когда все это только возникало, балом правили не производители софта, а производители железа. Вот была микросхема контроллера дисплея, например — Motorola MC6845 или Rockwell 6545, и для них таблица символов знакогенератора была зашита в ПЗУ, его изменить без смены ПЗУ было просто нельзя. Вокруг этого и плясали производители софта. Вот например, г-н Фролов, автор популярной в девяностые учебной литературы по персональным компьютерам, пишет:
У видеоадаптера CGA таблицы знакогенератора, определяющие символы, которые можно отобразить на экране дисплея в текстовых режимах, находятся в ПЗУ, расположенном вне адресного пространства процессора. Программы не имеют возможности изменить или даже считать информацию из этих таблиц. Поэтому для русификации текстовых режимов видеоадаптера CGA необходимо перепрограммировать ПЗУ знакогенератора. Единственной возможностью отобразить на CGA русские буквы, не перепрограммируя ПЗУ, является использование графических режимов работы адаптера. В графических режимах вы можете сами определить образы символов с ASCII кодами от 128 до 255. Образы символов с ASCII кодами от 0 до 127 нельзя изменить, не перепрограммируя ПЗУ.

И это написано, между прочим, через десять лет после появления CGA, когда над стандартом Unicode работа уже шла.
А вот когда появился EGA (1984-1985), таблица знакогенератора стала доступна софту, и вот тогда уже можно было говорить о смене кодовой страницы.
Соображения для этого были практические: людям реально весьма редко было нужно одновременно показывать на экране, скажем, текст на русском и греческом. А иметь базовый латинский набор символов и собственный алфавит (Кириллицу, например) тогдашние фокусы с переключением кодовых страниц вполне позволяли. По той же приблизительно причине в разном прикладном софте, например — в MySQL, полная поддержка Unicode появилась весьма недавно.
Давайте еще раз расставим точки над i.
1. По поводу кодировки и кодовой страницы вам уже написали, что англоязычная Википедия отражает суть лучше, потому что это не синонимы (хотя и употребляются в синонимичном значении многими).
Я не спорил ни с этим высказыванием ни с английской википедией, речь шла о вашей русскоязычной формулировке. Если Вам понятнее — мне не нравится ваш перевод (или толкование): «Кодовая страница — это таблица соответствия набора символов, их кодов и способа хранения этих кодов. А кодировка — это, строго говоря, способ хранения этих кодов сам по себе»
2. Не надо превращать популярную (не требующую от читателя глубоких специлизированных знаний) статью в занудство.
3. Я отмечал, что понятия кодовой страницы и кодировки близки, но не абсолютные синонимы, но выяснять различия выходит за рамки статьи. Прочитайте первое предложение статьи и название раздела.
4. Сами это понятия менялись с течением времени и понятие кодовой страницы в момент ее первого появления отличается от сегодняшнего. Тогда не было мультибайтовых кодировок (еще раз — статья опубликована в разделе история ИТ).

Вы делаете упор на железо — Ваше право. Я делаю упор на экономику. Почему железо было сделано таким? Потому, что память была очень дорогая и для англоязычных потребителей смысла удорожать железо не было (дешевле было использовать фокусы). Если у вас есть ссылки на более авторитетные источники — поделитесь ими, иначе спорить бесполезно.

Что касается переключения кодовых страниц, то на практике переключать их туда-сюда в процессе работы особой нужды не было: просто при запуске ДОС вместо зашитой в адаптер загружалась альтернативная (чаще всего) и все — дальше работа шла только с ней. С СGA я не работал, а вот с VGA работал довольно активно на уровне железа.
Я отмечал, что понятия кодовой страницы и кодировки близки, но не абсолютные синонимы, но выяснять различия выходит за рамки статьи.
Тут просто небольшая путаница произошла. code page вообще несколько специфический (даже «проприетарный», скажем так) термин и стоит в стороне от character set и encoding, про которые в основном должна идти речь. И которые, разумеется, вообще нисколько не близки в статье любого уровня «популярности» про кодировки. НО при этому всё же code page ближе по контексту к термину character set. Хотя обычно он означает и способ кодирования (раньше одно другому соответствовало, т.к. вариантов особо не было). Видимо, про это имел в виду Moskus в своей формулировке о code page (которая мне тоже кажется несколько запутанной).
Only those users with full accounts are able to leave comments. Log in, please.