Кстати, работа по «унификации» иероглифов для таблицы символов Unicode сейчас ведётся тоже не консорциумом Unicode, а ISO — специальным комитетом IRG при JTC1/SC02/WG02. И это при том, что в оригинальной версии UCS (в черновике ISO DIS-10646.1:1990) было чётко определено, что «базовая» (первая «внутренняя») таблица вообще не предназначена для иероглифов. При этом работа по «унификации» продолжается до сих пор, хотя в одной из более поздних версий системы Unicode было объявлено, что таблица символов будет расширена до примерно 1000000 позиций (с помощью использования специальных «расширений», которые в первоначальной версии Unicode не планировались — см. выше).
В дополнение к всему уже сказанному об Unicode нужно отметить ещё некоторые обстоятельства. Для того, чтобы сделать её хотя бы частично совместимой с ранее существовавшим ПО (а возможно, и чтобы не тратить денег на серьёзную переделку своего ПО, находящегося в стадии разработки), членами консорциума были разработаны различные методы представления (номеров) символов таблицы Unicode: UTF-8, UTF16, UTF16LE и UTF16BE. Отсюда возникает необходимость в реализации в ПО поддержки каждого из них, что определённо порождает новый виток путаницы. С этим обстоятельством связано, вероятно, большинство проблем, существующих в конкретных реализациях поддержки работы с системой кодирования Unicode в различном ПО.
Отметим, что консорциум Unicode держит «про запас» методы UTF32, UTF32LE, UTF32BE, в которых для кодирования (номера) каждого символа предусматривается использование уже 32-битных последовательностей (что, однако, «автоматически» не означает, что таблица символов будет расширена до 4,3 миллиардов позиций). Однако их применение чрезвычайно расточительно с точки зрения расходования системных ресурсов, и представители Unicode прямо указывают, что в ближайшее время промышленность (читай — корпорации-члены Unicode) не планирует переходить на применение этих методов.
У системы Unicode есть и другие нерешённые проблемы, наличие которых для международного стандарта просто неприлично, но мы не будем на них останавливаться отдельно. Интересующиеся могут ознакомиться с этой информацией на web-сайте проекта TRON[9].
Зададимся теперь вопросом: почему же всё-таки не возник единый международный стандарт, в таблице символов которого были бы последовательно занесены символы всех существующих естественных языков[10], притом одинаково удобный для применения во всех странах мира? Почему, напротив, в качестве международных принимались и принимаются заведомо несовершенные стандарты, часто недоработанные, и появилось большое количество несовместимых таблиц символов? Попробуем оценить основные причины.
1. корпорациям-производителям ПО, очевидно, весьма выгодно продавать разные «национальные» версии операционных систем, офисных пакетов и т. д. за отдельные деньги. Так, Microsoft продавала «американскую», «панъевропейскую», «восточно-азиатскую», «ближневосточную» и «тайскую» версии Windows 95, а IBM — стандартную, «арабскую», «израильскую», «японскую», «корейскую», «китайскую» и «тайваньскую» версии PC DOS. Отсюда возникновение несовместимых таблиц символов, содержащих 256 позиций каждая.
Кроме того, как уже говорилось, это, очевидно, позволило корпорациям в дальнейшем нажиться на продажах ПО, соответствующего стандарту Unicode — кому оно было бы нужно, не существуй «проблема кодировок»?! — а также на продаже самогó текста этого стандарта.
2. поскольку «проблема кодировок» теперь не касается английского языка, у ANSI и правительства США не было повода вмешиваться в её решение, как это было в 1963-м.
Более того, «проблема кодировок», не касающаяся английского языка, стратегически выгодна для США. Она обеспечивает лидерство США и его крупнейшего англоязычного партнёра по НАТО — Великобритании (и Австралии) — в сфере ИТ, и отставание других стран, так как «проблема кодировок» препятствует информационному обмену между людьми, работающими с данными не на английском языке.
Особенно это заметно на примере важнейшей сферы ИТ, относящейся к сети Internet:
• использование для представления различных символов различных языков одних и тех же двоичных последовательностей (при этом «угадать», которую из таблиц символов нужно использовать, ПО без дополнительных данных не может) делает их употребление в именах файлов[11] и Internet-ресурсов если не невозможным, то, как минимум, нефункциональным и потому нежелательным. Символам английского языка, напротив, всегда «горит зелёный свет»;
10
По данным японских учёных, символы всех известных языков мира, как используемых сейчас, так и ныне «мёртвых», можно уместить в таблицу символов, насчитывающую 2^24 = 16777216 позиций.
11
Эта проблема так или иначе освещена в трудах практически всех русских авторов «компьютерных» книг, включая бестселлеры Левина и Фигурнова, и официально признана (но не решена, заметим…) Microsoft в стандартной документации к ОС Windows 9X — см. например, WINDIR\general.txt, секция «Pan-European: known issues». Существенные проблемы создаёт «проблема кодировок» и во многих других случаях, к примеру, при запароливании архивов (и передаче их между компьютерами, на которых используются разные таблицы символов), если при этом в пароле используются буквы национального языка. Что касается Internet-адресов, то возможность использования в них букв русского (например) языка была «санкционирована» практически только через 10 лет после возникновения сети (см., например, http://www.625-net.ru/news/2001/20010227.htm#1 (реклама РБК))… При этом гарантии качества работы данной «услуги», если не ошибаюсь, не предоставляется, что с учётом сказанного выше (а также того, что далеко не всё ПО для работы с Internet, в том числе провайдерское, способно обеспечить её поддержку) и неудивительно.