Секция по информационным технологиям ИФЛА

Большой секционный проект


Проектирование и внедрение единого стандарта представления кирилловской информации в электронной форме

Обзорное исследование


Содержание

  1. Введение
  2. Обзор существующих представлений кириллицы
  3. Сравнение отдельных таблиц, их достоинства и недостатки
  4. Представление знаков кириллицы и Unicode/ISO 10646
  5. Проблемы представления кириллицы в российском Internet
  6. Последующие стадии реализации проекта
  7. Заключение

И сказал Господь: вот, один народ, и один у всех язык; и вот что начали они делать, и не отстанут они от того, что задумали делать.

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

Библия. Первая книга Моисеева. Бытие, гл. 11 (6-7).

1. Введение

Одно из величайших событий в славянской истории, оказавшее воздействие на все человечество, произошло в IX столетии, когда святые апостолы Кирилл и Мефодий распространили старо-болгарский (старо-славянский) язык и культуру повсюду в Восточной Европе, включая русские и румынские земли. В то время как Кирилл и Мефодий развили раннюю версию Славянского алфавита, названного Глаголицей, святой Климент Охрид разработал кириллический алфавит (Кириллицу), в форме, близкой к ныне используемой.

В сегодняшней практике в Болгарии используется 30 букв от А до Я, тогда как русский алфавит, например, имеет те же самые 30 букв плюс буквы Ы, Э и Ё (вместо последней буквы часто используется Е). В современном украинском алфавите есть дополнительные буквы ª, ², ¯, но нет символов Ё, Ъ, Ы, Э, а в белорусском алфавите в дополнение к русскому используются еще буквы ² и ¡, но не используются И, Ы, Ъ. Наконец, в сербском и македонском алфавитах в дополнение к русскому алфавиту присутствуют символы , € ½, £, , Š, Œ, Ž,  и отсутствуют буквы Ё, Й, Щ, Ъ, Ы, Ь, Э, Ю, Я.

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

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

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

В настоящее время существует несколько 8-ми битных расширений одновременно используемых для кодировок кириллических символов. В то же время, при работе в Internet с такой распространенной и богатой информационными возможностями службой как WWW переход от одного узла с кирилловской информацией к другому часто приводит к перенастройке пользовательских интерфейсов WWW-клиента или, в случае использования других сервисов Internet, может потребовать даже смены некоторых программных компонент рабочих станций. Разработчиками Internet-серверов, поддерживающих кириллические массивы информации, предложен ряд решений, позволяющих клиенту работать с ресурсами серверов в доступной ему кодировке. Однако каждое из найденных решений обладает тем или иным недостатком и не закрывает проблему в целом.

Кардинальным решением этой проблемы может послужить повсеместный переход на использование универсальной 16-ти битной кодировки (Unicode и ISO/IEC 10646). Однако реализация поддержки нескольких семейств языков в одном документе требует не только применения новых версий протокола HTTP и языка HTML, обеспечивающих требуемую мультиязычную поддержку,, но и новых средств поддержки информационных массивов (тексты, базы данных и т.д.) в Unicode, которые находятся на самой ранней стадии практического применения. При этом нельзя не понимать, что еще достаточно долго будет существовать огромное число наследуемых информационных систем, которые не будут поддерживать Unicode.

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

а) выработку рекомендаций по выбору базовой кодировки для хранения и предоставления информации в Internet-серверах

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

в) разработку технологий автоматического распознавания кодировки входящего клиента и его обслуживания в этой же кодировке.

2. Обзор существующих представлений кириллицы

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

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

Основная кодовая таблица ASCII и ее расширения. Наиболее широко применяемая в настоящее время основная кодовая таблица для представления латинского алфавита (см. рис. 1) использует десятичные коды от 0 до 127 (шестнадцатеричные коды от 00 до 7F). При этом первые 32 кода (от 00 до 1F) являются управляющими символами, которым соответствуют специальные графические изображения, зависящие, по сути дела, от знакогенератора дисплея. Другие коды основной таблицы ASCII используются для кодирования букв латинского алфавита, цифр, знаков препинания и математических символов. Всего для кодирования символов используется 7 битов.

Существующие 8-ми битные расширения основной таблицы ASCII в дополнение к первым 128 символам позволяют кодировать не только символы псевдографики или математические символы, но и буквы национальных алфавитов. Для этого используются десятичные коды от 129 до 256 (шестнадцатеричные коды - от 80 до FF).

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

История создания кодовых таблиц для кириллицы. В 70-е годы в СССР одними из первых были разработаны и утверждены в качестве государственного стандарта (ГОСТ 19768-74 [1]) сразу два стандарта: двоичный код для обмена и обработки информации (ДКОИ) - кодовая таблица СP-DKOI (рис. 2), и 8-битный код обмена и обработки информации (КОИ8) - кодовая таблица СP-KOI8 (рис. 3), которые вводились в действие с 01.01.1975 до 01.01.1980. К тому времени относится также использование нескольких (заслуженно забытых сегодня) внутриведомственных кодовых таблиц (пример - рис. 4).

В конце 80-х в связи с массовым внедрением персональных компьютеров была предложена [2] т.н. альтернативная кодировка, используемая при русскоязычной локализации IBM-совместимых ПК под управлением операционной системы DOS и принятая впоследствии корпорацией IBM в качестве одного из своих внутренних стандартов CP-866 (рис. 5). Примерно в это же время, в восточно-европейских странах получила распространение т.н. болгарская кодировка CP-Bulgarian (рис. 6), которая хорошо известна в Европе и продолжает там использоваться.

В 1988 году Международной организацией стандартов был утвержден стандарт ISO-8859-5 [3] кодового представления кириллицы (рис. 7) - единственного представления, поддерживаемого протоколом MIME и основными компаниями, использующими UNIX-платформы (такими как IBM, Sun Microsystems, DEC и т.д.).

Одновременно с широким использованием операционной системы UNIX и развитием российских компьютерных сетей происходило распространение еще одной кодовой таблицы CP KOI-8R (рис. 8), базирующейся на ГОСТе 19768-74 и претендующей сегодня на роль фактического стандарта для русскоязычной сетевой среды. В 1993 году эта кодовая таблица была предложена [4] сообществу пользователей Internet для обсуждения в качестве возможного стандарта (см. RFC-1489). Недавно эта кодовая таблица была также зарегистрирована корпорацией IBM в качестве еще одного из внутренних стандартов русскоязычной локализации под кодом СP-878.

В это время вместо советского стандарта ГОСТ 19768-74 был принят и введен в действие с 01.01.1995 межгосударственный стандарт новых независимых государств ГОСТ 19768-93 [5] для двух версий СP-DKOI-K1 (рис. 9) и СP-DKOI-K2 (рис. 10) двоичного кода обработки информации.

Появление и бурное внедрение графического интерфейса MS Windows в начале 90-х годов привело к массовому распространению новой кодовой таблицы CP-1251 (рис. 11), на которой базируется русскоязычная локализация этого программного продукта, используемая корпорацией Microsoft. Последняя (по времени) кодовая таблица была разработана в связи с выходом на российский компьютерной рынок компании Apple, которая для локализации рабочих станций Macintosh, работающих под операционной системой MacOS, ввела свою собственную кодовую таблицу CP-Mac (см. рис. 12). Самое печальное, что все это происходило всего несколько лет назад!

Сегодня в России наиболее активно используются кодовые таблицы CP-1251, CP-866, CP KOI-8R и СР-ISO-8859-5.

3. Сравнение отдельных кодовых таблиц, их достоинств и недостатков

Кодовые таблицы КОИ. Все таблицы, связанные с той или иной версией КОИ или ДКОИ предназначены только для русского/английского языков и охватывают лишь русские кириллическиесимволы, так что уже для украинского или белорусского языков эта кодовая таблица неприменима. Логика составителей данных стандартов была направлена на реализацию возможности использования графических символов латинского алфавита вместо сходных по написанию кириллических символов (как строчных, так и прописных). Это привело к тому, что буквы русского алфавита располагаются в КОИ-таблицах не по порядку, поэтому стандартные механизмы сортировки не действуют и организация сортировки требует дополнительных усилий от разработчиков программных средств.

Альтернативная кодовая таблица CP-866. Эта таблица также предназначена только для русского/английского языков и охватывает лишь русские кирилловские знаки. Расположение прописных букв русского алфавита организовано по принципу основной кодовой таблицы ASCII (за единственным исключением буквы Ё), тогда как нормальная последовательность строчных букв прерывается символами псевдографики, что вновь приводит к необходимости при локализации программных средств использовать нестандартные механизмы сортировки.

Международный стандарт ISO-8859-5. Данный стандарт позволяет осуществить кодирование не только для русского/английского языков, но и охватывает белорусский, болгарский, македонский, сербский и украинский. При этом порядок расположения букв русского алфавита организован в соответствии с принципом построения основной таблицы ASCII, когда все подряд идущие прописные буквы (как всегда за исключением буквы Ё) кодируются последовательными номерами, а коды строчных букв отличаются от кодов прописных букв на 32. Это позволяет легко организовать сортировку с использованием стандартных механизмов и не требует дополнительных усилий от разработчиков программных средств.

Кодовая таблица CP-1251. Это расширение построено в соответствии с принципами, применяемыми в международном стандарте ISO-8859-5 и используется не только для кодирования символов русского/английского алфавитов, но и содержит недостающие символы белорусского, болгарского, македонского, сербского и украинского алфавитов. Отличие от стандарта ISO-8859-5 заключается лишь в перемещении русских букв со столбцов B0-E0 в столбцы C0-F0 и несколько ином размещении остальных символов.

Кодовая таблица CP-Mac.Эта таблица близка по своим принципам построения к таблицам СР-ISO-8859-5 и CP-1251, но отличается от них совершенно изысканным выносом из общего ряда вперед строчной буквы "я" (!?)

Выводы. Проведенный анализ и сравнение убедительно показывают, что наиболее последовательным и удачным представляется построение кодовой таблицыСР-ISO-8859-5 Международной организации стандартов, не только решающей проблему 8-битного представления символов русского алфавита, но и допускающей кодировку еще нескольких кириллических алфавитов.

Более того, стандарт Unicode 2.0 [7], принятый в качестве подмножества стандарта ISO/IEC 10646 [8], построен по аналогичному принципу и для кириллических символов от U+040 до U+04FF (см. рис. 13) включает часть кодовой таблицы СР-ISO-8859-5 как начальный фрагмент со столбцами U+040 - U+045, что существенно облегчит в будущем миграцию с 8-битного на 16-битное кодовое представление символов.

4. Представление знаков кириллицы и UNICODE/ISO10646

Стандарт Unicode. Новый способ кодирования знаков, предназначенный для представления многоязычной информации в электронном виде, основан на в недавно завершенном (в основном)проекте Unicode, представляющем собой собственное подмножество стандарта ISO/IEC 10646. Проект стандарта Unicode не только основан на последовательном использовании существующей основной кодовой таблицы ASCII и ее расширения Latin-1, но и преодолевает ограничения по возможностям использования таблиц ASCII для кодирования только латинского алфавита. Unicode обеспечивает возможность кодировать все знаки, используемые для всех живых языков, имеющих письменность.

Чтобы закодировать тысячи знаков, используемых в мире, Unicode использует 16-битный код вместо 7-битного кода ASCII. Это расширение обеспечивает коды для более чем 65,000 знаков, что во много раз превышает возможности кодовой таблицы ASCII с ее 128 знаками. Чтобы осуществить простую и эффективную кодировку, Unicode присваивает каждому знаку уникальное 16-битное значение, и не использует сложные способы или Escape-коды для определения измененных знаков или специальных случаев. Эта простота и эффективность облегчает для компьютеров и программного обеспечения работу с текстовыми файлами в кодировке Unicode.

Стандарт Unicode и ISO 10646. До недавнего времени Unicode был одним из двух проектов международных стандартов кодировки наряду с другим, известным как ISO 10646. К счастью, недавнее соглашение между Консорциумом Unicode и Комитетом ISO 10646 установило слияние двух проектов: Unicode теперь является собственным подмножеством набора знаков ISO 10646.

Основные коды стандарта Unicode составляют первые 65,536 кодов стандарта ISO 10646 и содержат все знаки, в настоящее время определенные ISO 10646. Остальные коды ISO 10646 остаются незаполненными и зарезервированы для будущего расширения. Чтобы отразить знаки, имеющиеся в ISO 10646, стандарт Unicode включил более чем 3600 новых китайских, японских и корейских знаков и более чем 1000 других знаков.

Слияние стандартов Unicode и ISO 10646 зафиксировало только один развиваемый проект международного стандарта кодировок и остановило сражение между стандартами, что лишь на пользу конечным потребителям.

Какие знаки включает Unicode? Стандарт Unicode определяет коды для знаков, используемых во всех письменных языках, используемых сегодня. Это включает латинский алфавит, используемый для английского языка, кириллический алфавит, используемый для русского и других славянских языков, греческий, иврит и арабский алфавиты, другие алфавиты, используемые в странах Европы, Африки, Индокитая и Азии.

Unicode также включает алфавиты типа японского kana, корейского hangul, и китайского bopomofo. Самая большая часть стандарта Unicode посвящена тысячам обьединенных знаков для китайских, японских и корейских иероглифов.

Unicode включает много наборов символов, с кодами знаков пунктуации, математических символов, технических символов, стрелок и др. Это обеспечивает наличие кодов для диакритов, которые используются как модификации знаков типа тильды и появляются в соединении с другими знаками. Всего Unicode обеспечивает коды для более чем 29,000 знаков от мировых алфавитов, наборов иероглифов и символов.

Unicode содержит более чем 29,000 неиспользованных кодов для расширения, позволяющие включить новые знаки. В будущем это может позволить включить в стандарт исторические знаки типа иероглифов и возможные расширения существующих алфавитов и/или наборов символов. Кроме того, Unicode резервирует более чем 6,000 кодов для частного использования, которые разработчики программного обеспечения и аппаратных средств могут использовать для собственных знаков и символов.

Принципы построения Unicode. Для более легкого внедрения Unicode в качестве всемирного знакового стандарта, используемого для кодирования текста, в нем реализованы следующие принципы:

  • в Unicode используются фиксированные 16-ти битные коды для знаков и нет завимости от состояний или способов кодировки специальных знаков
  • Unicode включает наборы знаков многих существующих стандартов: например, Latin-1 как свои первые 256 знаков; кроме того, он включает репертуар знаков других общих, национальных и международных стандартов Unicode использует унификацию Хана для объединения китайских, корейских и японских иероглифов Unicode допускает создание отмеченных знаков: он кодирует каждый знак и диакрит или метку гласного отдельно, а также позволяет oбъединять знаки, чтобы создать отмеченные.

5. Проблемы представления кириллицы в российском Internet

5.1 Современная ситуация с использованием различных кодировок в российской части Internet

Статистика работы большинства российских серверов Internet показывает, что активно (не единично) используются кодировки CP-1251, KOI-8R, ISO-8859-5, CP-866, CP-Mac. При этом подавляющее число запросов направляется и обслуживается в кодировке CP-1251, то есть основной кодировке, использующаяся во всех версиях верcий Windows. По разным оценкам, число пользователей, использующих данную кодировку достигает 80-90 процентов от общего числа "кириллических" пользователей. На втором месте по частоте использования, по нашим данным, стоит "официальная" кодировка российской части Internet KOI-8R. В качестве примера мы приводим данные, полученные автоматическим сервером статистики Государственной публичной научно-технической библиотеки России за период март-июль 1997 г - таблица 1 и 2, рис 14.


 

Таблица1.

NPLS&T WWW server statistic

Browser Report.

#reqs

Browser

17148

Mozilla/2.0 (compatible; MSIE 3.0; Windows 95)

14995

Mozilla/3.01Gold (Win95; I)

14544

Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)

8511

Mozilla/3.0Gold (Win95; I)

6829

Mozilla/2.0 (compatible; MSIE 3.01; Windows 95)

6406

Mozilla/3.0 (Win95; I)

4104

Mozilla/3.01 (Win95; I)

2314

Harvest/1.4.pl2

2006

Mozilla/3.01 (Win16; I)

1649

Mozilla/3.01Gold (Win16; I)

1523

Mozilla/3.0 (Win16; I)

1477

Mozilla/3.0Gold (Win16; I)

1366

ia_archiver/1.6 (X11)

1219

Mozilla/4.01 [en] (Win95; I)

1099

Mozilla/4.0b5 [en] (Win95; I)

1060

Scooter/1.0 scooter@pa.dec.com (X11)

991

Mozilla/2.0 (compatible; MSIE 3.02; Windows NT)

882

Mozilla/2.0 (compatible; MSIE 3.01; Windows NT)

875

Mozilla/4.0b4 [en] (Win95; I)

850

Mozilla/4.0 (compatible; MSIE 4.0b1; Windows 95)

832

Mozilla/2.02 (Win16; I)

752

Mozilla/3.01 (X11; I; Linux 2.0.30 i586)

679

Mozilla/3.01 (X11; I; Linux 2.0.28 i586)

655

Mozilla/3.01Gold (Win95; I; 16bit)

651

Mozilla/2.0 (compatible; MSIE 3.0; Update B; Windows 95)

648

Mozilla/4.0 [en] (Win95; I)

611

Mozilla/2.0 (compatible; MSIE 3.0; AK; Windows 95)

583

Mozilla/2.0 (compatible; MSIE 3.0; Windows NT)

514

Mozilla/2.0 (compatible; MSIE 3.0B; Win32)

496

Mozilla/2.0 (compatible; MSIE 3.02; AK; Windows 95)

486

Mozilla/3.01Gold (X11; I; FreeBSD 2.2.1-RELEASE i386)

422

Mozilla/3.0Gold (WinNT; I)

416

Mozilla/2.02 (OS/2; I)

404

Mozilla/3.01Gold (WinNT; I)

403

Mozilla/4.0b5 [en] (WinNT; I)

401

Mozilla/2.0 (Win16; I)

400

Mozilla/3.01 (Win95; I; 16bit)

384

Mozilla/3.0 (WinNT; I)

372

Mozilla/2.0 (compatible; MSIE 3.01; AK; Windows 95)

366

Mozilla/2.0 (compatible; MSIE 3.0B; Windows 95)

350

Mozilla/3.0 (Win95; I; 16bit)

348

Mozilla/4.0b3 [en] (Win95; I)

344

Arachnoidea

331

Mozilla/2.02E-KIT (Win95; I)

329

Mozilla/3.01Gold (X11; I; Linux 2.0.27 i586)

326

Mozilla/3.01 (X11; I; Linux 2.0.29 i586)

319

Mozilla/3.01Gold (X11; I; Linux 2.0.29 i586)

311

Mozilla/4.0 (compatible; MSIE 4.0b1 Crawler; Windows 95)

309

Mozilla/2.0 (compatible; MSIE 3.02; Update a; Windows 95)

302

Mozilla/2.0 (compatible; MSIE 3.02; Win32)

282

Mozilla/2.01 (Win16; I)

254

Mozilla/3.01 (X11; I; Linux 2.0.0 i586)

247

Mozilla/2.0 (compatible; MSIE 3.01; Update B; Windows 95)

243

Mozilla/2.02E-KIT (Win16; I)

233

StackRambler/1.1

214

Mozilla/1.22 (Windows; I; 16bit)

200

Mozilla/3.01 (X11; I; Linux 2.1.42 i586)

197

Mozilla/2.01 (Win95; I; 16bit)

195

Mozilla/3.01 (X11; I; Linux 2.0.24 i586)

193

Mozilla/3.0Gold (X11; I; Linux 2.0.30 i586)

188

Mozilla/2.0 (compatible; MSIE 3.02; Windows 3.1)

182

Mozilla/3.01Gold (X11; I; Linux 2.0.30 i586)

178

Mozilla/3.01Gold (X11; I; Linux 2.0.18 i586)

170

Mozilla/3.0 (Win95; I) Modified

163

Mozilla/2.0 (compatible; MSIE 3.01; Windows 3.1)

159

SPRY_Mosaic/v7.36 (Windows 16-bit) SPRY_package/v4.00

159

Mozilla/2.02E (OS/2; I)

154

Mozilla/3.01 (WinNT; I)

151

Mozilla/3.01Gold (X11; I; Linux 2.0.29 i486)

147

Mozilla/4.01 [en] (WinNT; I)

146

Mozilla/4.0b3 [en] (WinNT; I)

145

Mozilla/3.0Gold (Win95; I) Modified

137

Mozilla/2.0 (Win95; I; 16bit)

134

Mozilla/4.0 (compatible; MSIE 4.0b1; Windows NT)

130

Gulliver/1.1

129

Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)

129

Mozilla/2.0 (compatible; MSIE 3.0a; Windows 3.1)

119

Mozilla/3.0 (X11; I; SunOS 5.5.1 sun4u)

119

Mozilla/4.0b5C (X11; I; Linux 2.0.30 i586)

116

Mozilla/2.01Gold (Win95; I)

116

Mozilla/4.0 [en] (WinNT; I)

109

Mozilla/3.01 (X11; I; HP-UX A.09.05 9000/715)

107

Mozilla/3.01Gold (Macintosh; I; PPC)

107

Mozilla/2.0 (compatible; MSIE 3.01; Update B; Windows NT)

100

Mozilla/3.0Gold (Win95; I; 16bit)

97

Mozilla/4.0b1 (Win95; I)

97

Mozilla/3.01 (X11; I; Linux 2.1.36 i586)

96

Mozilla/3.0 (X11; I; SunOS 5.5 sun4m)

94

Mozilla/2.0 (compatible; BiDi MSIE 3.02; Windows 95)

89

Arkanavt/1.03.005 (compatible; Win16; I)

86

StackRambler/1.0

83

Mozilla/3.01Gold (X11; I; Linux 2.0.30 i486)

82

Mozilla/2.0 (compatible; MSIE 3.0; Windows 3.1)

82

Mozilla/3.01Gold (X11; I; Linux 2.0.0 i586)

80

Mozilla/2.01KIT (Win95; I; 16bit)

76

Mozilla/2.0 (Win95; I)

76

ArchitextSpider

75

Mozilla/3.0Gold (WinNT; U)

75

Mozilla/3.01 (X11; I; Linux 2.0.27 i586)

74

Mozilla/3.01Gold (X11; I; Linux 2.1.43 i586)

 

 

Таблица 2.

 

Brouser code page

#reqs

CP-1251

102589

KOI-8r

7335

ISO-8859-5

810

CP-866

575

CP-Mac

107



Рис. 14.



Наглядно представленное доминирующее положение одной системы кодировки (CP-1251), может быть легко объяснено, если проанализировать структуру компьютерного парка используемого в России. Архитектура WinIntel, то есть совокупность персонального компьютера на базе Intel-процессоров и различных версий Windows, наиболее популярна как в государственных и некоммерческих организациях, так и в бизнес-секторе и сфере домашних приложений. Основным фактором наличия такой популярности этих систем является доступность как по ценовым характеристикам, так и по легкости освоения и использования. Можно сказать, что массовым стала только лишь эта архитектура. Все остальные используются лишь в узкоспециализированных секторах рынка Однако, в последнее время, в том числе и в результате "взрывного" роста интереса к Internet, резко возросло применение и популярность малых Unix систем. Такие системы чаще всего используют компьютеры на базе все того же Intel-процессора, особенно в странах бывшего СССР, но в качестве операционной системы в таких системах применяются различные свободнораспространяемые версии UNIX. Наиболее часто применяемые - различные версии Linux и FreeBSD.

В совокупности с коммерческими версиями UNIX работающих на мощных платформах, вышеуказанные системы используются в качестве базовых платформ для серверов Internet. Большинство серверов российской и FSU части Internet используют такие системы и, следовательно, внутренние кодировки KOI-8R и ISO.

Это приводит к пародоксальной ситуации - несмотря на подавляющее превосходство использования кодировки CP-1251 у клинетов, запрашиваемые данные которые им направляются от выбранных Internet-серверов имеют другую кодировку! Это одна из причин, которая делает работу по унификации представления кириллической информации жизненно необходимой для российского и FSU Internet community, но не только для них, а в целом, для пользователей кириллической информации через Internet. Возникает необходимости либо дублирования данных в различных кодировках, что при увеличении объемов предоставляемой информации становится практически невозможным, либо их автоматического конвертирования, что резко увеличивает заргузку серверов и приводит к замедлению в обслуживании.

Еще более сложная систуация сложилась при проектировании и реализации Internet-серверов в российских и fSU библиотеках. Здесь к вышеперечиленным проблемам добавляется то, что исторически, большинство массивов библиографических баз данных и электронных каталогов, было сгенерировано и продолжает поддерживаться в кодировке CP-866, поскольку большинство установленных библиотечных систем работает под управлением различных версий MS-DOS. Это приводит к тому, что при выполнении запроса на поиск в библиографических базах данных возникает целая цепочка преобразований и перекодировок. Типичный пример - клиент работает как Windows-клиент (кодировка CP-1251), сервер использует для статической информации кодировку KOI-8R, а базы данных хранятся в кодировке CP-866. В этом случае при выполнении только одной транзакции доступа к базам данных происходит 4 перекодировки).

К сожалению, ни общем случае Internet-серверов ни в случае библиотечных серверов невозможно использовать оптимизацию процессов перекодировки на базе ввода наиболее часто используемой CP-1251 как базовой. При таком подходе администратороы серверов неминуемо сталкиваются с по крайней мере 2 проблемами:

1. При доступе с Unix машин даже при использовании средств автоматического распознавания кодировки входящего клиента, существует значительная вероятность необходимости работы с базовой кодировкой. Однако обеспечение работы Unix-терминалов и рабочих станций с кодировкой CP-1251 значительно более нетривиальная задача, часто и вовсе невыполнимая, чем обратная

2. Использовании кодировки CP-1251 как базовой на Unix-серверах приводит к значительным трудностям при работе любых приложений связанных с сортировкой и индексированием.

Таким образом де-факто сложилась неудобная и затратная по отношению к аппаратно-программным ресурсам ситуация - Internet-сервера либо расходуют дисковое пространство для поддержки нескольких кодировок, либо постоянно загружаются процессами перекодировки.

5.2 Методы преодоления проблем, связанных с наличием нескольких кодовых схем в основных Internet-сервисах

По вышеуказанным причинам, российские разработчики Internet-серверов были вынуждены разрабатывать и вводить различные дополнительные программно-технологические методы обслуживания входящих запросов в различных кодировках.

В наиболее общем случае можно выделить, как было указано выше, два метода решения этих проблем:

  • Поддержка документов во всех кодировках
  • Автоматическое распознавание кодировки входящего клиента и последующая перекодировка пересылаемых документов и получаемых запросов

Эти методы могут реализовываться и в настоящее время реализуются на различных серверах несколькими способами.

Также существует очень распространенный (к сожалению) метод нерешения (принципиального игнорирования)проблемы существования различных кодировок. Такой подход, к сожалению, распространен на многих серверах (в большинстве случаев единственно поддерживаемой кодировкой выбирается KOI-8R). В этом случае на сервере хранятся документы лишь в одной кодировке. Администраторы таких серверов часто оправдывают свое нежелание что-либо менять в своей системе для обеспечения более удобного интерфейса тем, что во-первых KOI-8R декларируется ими как стандарт кодировки для российского Internet, а во-вторых, что другие системы можно приспособить к KOI-8R, а вот системы использующие эту кодировку к другим нет. На самом деле и то и другое не лишено оснований. Однако, как было показано выше, такой подход не учитывает сложившуюся в российском Internet ситуацию.

Такой метод является крайне неудобным для пользователя не Unix-систем. Более или менее подготовленный пользователь, работающий с Windows-системами имеет возможность найти в Internet сервера на которых он может получить информацию о том как добавить поддержку KOI-8R в свою систему и загрузить необходимые фонты, которые не поставляются Microsoft ни в одной из версий Windows. Для пользователей других платформ эта задача может оказаться весьма сложной.

Среди методов наиболее часто используемых в российской части Internet можно выделить следующие:

1. Предоставить пользователю выбрать кодировку, в которой он желает (а конфигурация его программы-клиента позволяет) просматривать документы. Выбор кодировки осуществляется чаще всего через менюориентированную систему при первом обращении к серверу и, реже, на всех страницах, которые могут быть вероятными входами при "скольжении" пользователей в Internet). При этом возникает техническая проблема - как сохранить или перекодировать направляемый клиенту документ (второй этап). Проблема второго этапа может решаться либо путем хранения информации во всех 4 кодировках (при этом на сервере запускаются несколько HTTPD на разных портах для каждой из кодировок), либо путем хранения информации в одной кодировке (при этом работа сервера организована так, что перекодировка документа осуществляется согласно порту на который пришел запрос). Этот метод решения представляется не очень удобным и весьма расточительным с точки зрения расходования ресурсов. Этот способ и способ автоматического определения кодировки являются единственными, которые обеспечивают корректное обслуживание при обращении в любую точку дерева страниц WWW сервера и при обращении к базам данных, включая библиографические.

2. Автоматическое определение кодировки, в которой можно просматривать документы, путем анализа информации, передаваемой клиентом в заголовке НТТР запроса. Этот способ широко применяется, например, на WWW серверах сети FREEnet и проекта LibWeb. На сервере данные хрянятся в выбранной базовой кодировке и затем перекодируются (при необходимости) при обращении клиента.

При применении указанного способа, даже если есть хорошо проработанные алгоритмы разбора заголовков, нельзя избежать вероятности неправильного определения кодировки входящего запроса. Поэтому вопрос о базовой кодировке остается открытым. Выбор наиболее оптимальной по отношению к снижению загрузки сервера базовой кодировки CP-1251 может привести к невозможности обслуживания клиента, а выбор KOI-8R - к необходимости перекодировки практически всех данных и следовательно к снижению эффективности системы. По этой причине тормозится использование кодировки ISO в качестве базовой. Кроме того, усложнение алгоритмов разбора заголовков приводит к дополнительной загрузке сервера.

Однако, этот способ в настоящее время является самым удобным для пользователей и более эффективным, чем работа по портам.

5.3 Перспективы унификации представления кириллической информации в российском Internet.

Как было показано выше, в настоящее время, отсутствует единая технология использования различных кодировок для реализации Internet-серверов. Однако, все у большей части специалистов не вызывает сомнений, что унификация - необходимое условие дальнейшего развития российского Internet. Наиболее эффективным для решения большинства задач информационного обслуживания пользователей Internet-серверов может стать поэтапный переход на единую базовую кодировку (то есть кодировку хранения документов) с обязательным сохранением технологий автоматического перекодирования на достаточно долгий период времени. При этом наиболее удобной для большинства типовых прикладных задач является кодировка ISO-8859-5. Немаловажно, что эта кодировка либо поддерживается практически всеми ведущими производителями (и является общепринятым стандартом ISO) программного обеспечения, либо ее поддержка планируется. Например, последние версии Netscape Navigator обеспечивают стандартную настройку трех кодировок CP-1251, KOI-8R и ISO 8859-5. Однако, выбор либо CP-1251 либо KOI-8R приводит в ряде случаев к несовместимости. С другой стороны, применение ISO 8859-5 на первом этапе увеличит загрузку серверов процессами перекодировки.

Более активному применению ISO 8859-5 мешает недоступность public domain фонтов для наиболее распространенных платформ.

Одновременно, выбор этого стандарта как базового является в долговременном плане наиболее перспективным в связи с дальнейшим переходом на UNICODE, который направлен на практически полное решение задачи преставления различных языков в электронной форме.

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

6. Этапы дальнейшего развития работ

Стадия 2

  • Сбор и анализ статистики работы Internet-серверов, работающих с кириллической информацией
  • Опрос экспертов и пользователей с целью подготовки ранжированных позиций относительно выбора базовой кодировки кириллицы
  • Окончательный выбор базовой кодировки и постановка задачи создания public domain фонтов.
  • Начало работ по разработке технологии автоматического распознавания вида кириллической кодировки входящего клиента

Стадия 3

Завершения всех работ, начатых в стадии 2.

Размещение разработанных public domain на специально организованном Internet-сервере и на сервере IflaNet

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

7. Заключение

Смеем надеяться, что в настоящей работе проведен достаточно полный обзор существующих разнообразных способов кодирования кириллических символов для представления информации в электронном виде. Анализ показывает, что на ближайшую перспективу наиболее последовательным и удачным представляется использование 8-битной кодовой страницы СР-ISO-8859-5 Международной организации стандартов с учетом всех вышеуказанных соответствующих технологий.

Намечены мероприятия, которые необходимо осуществить для унификации стандарта и технологии представления кириллических символов в практику работы пользователей кириллической информации в Internet.

Литература

[1] Государственный стандарт Союза ССР ГОСТ 19768-74. Машины вычислительные и системы обработки данных. Государственный комитет стандартов СМ СССР. Москва, 1974, 9 с.

[2] Брябрин В.М., Ландау И.Я., Неменман М.Е. О системе кодирования для персональных ЭВМ. Микропроцессорные средства и системы. - 1986, № 4, с. 61-63.

[3] ISO_8859-5 code page. 1988.

URL: http://www.alis.com:8085/langues/codage/iso8859/8859-5.gif

[4] Chernov, A., "Registration of a Cyrillic Character Set", RFC-1489, RELCOM Development Team, July 1993. KOI8-R code page,
URL: http://www.alis.com:8085/langues/codage/iso8859/koi8-r.gif

[5] Межгосударственный стандарт ГОСТ 19768-93. Информационная технология. Наборы 8-битных кодированных символов. Двоичный код обработки информации. Межгосударственный Совет по стандартизации, метрологии и сертификации. Минск, 1995. 9 с.

[6] WWW Cyrillization.
URL: http://www.web.ru/docs/Rus/Diskuss/CP1251/intro.html

[7] MultiWeb - WWW сервер с поддержкой множества языков и кодировок.
URL: http://multiweb.urc.ac.ru/demo.html

[8] The Unicode Consortium Home Page, URL: http://www.unicode.org, The Unicode Standard, Second Edition. (ISBN: 0-201-48345-9). URL: http://www.stonehand.com/unicode.html.

[9] ISO/IEC JTC2/SC2/WG2. Multi-Octet Coded Character Set. Roadmap to the BMP of ISO 10646. Unofficial, revised HTML version.
URL: http://www.indigo.ie/egt/standards/iso10646/bmp-roadmap.html


© Разработчики проекта, 1997 г.