""Проблема кодировок": стечение обстоятельств или стратегический замысел?" - читать интересную книгу автора (Кармышев Павел)

"Проблема кодировок": стечение обстоятельств или стратегический замысел?

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

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

В современном мире сложилась ситуация, когда положение той или иной страны в мировом сообществе напрямую зависит от того, какое положение она занимает в мировой сфере ИТ. И понятно, что поскольку участие страны в существующей мировой сфере ИТ в огромной степени определяется тем, как в этой сфере реализована поддержка работы с информацией на национальном языке, на котором говорит народ этой страны, «проблема кодировок» является чрезвычайно, даже стратегически, важной, как будет показано ниже.

К сожалению, в подавляющем большинстве материалов на тему «проблемы кодировок» их авторы (как русские, так и зарубежные) погружаются исключительно в одну тему – в описание многочисленных технических «внутренностей» различных стандартов, из-за которых при работе с тем или иным языком возникают проблемы. Если даже они и предлагают свои собственные варианты решения данной проблемы, то делают это, «не видя за деревьями леса» и не поднимая ряда нетехнических вопросов, которые имеют более глобальный характер. В результате ничего не меняется – несовместимые стандарты лишь продолжают множиться, и «проблема кодировок» остаётся нерешённой.

Для того, чтобы на практике приблизиться к решению «проблемы кодировок», нужно иметь представление о том,

– каким образом она возникла;

– кто её создал и продолжает поддерживать;

– кто несёт от неё наибольший ущерб, а кто – выигрывает.

Собственно, рассмотрению этих вопросов и посвящена статья.

К началу 1960-х годов мировая сфера производства компьютерной техники контролировалась рядом крупнейших транснациональных корпораций, головные отделения которых располагались, преимущественно, в одной стране – США. И сложилась ситуация, когда каждая корпорация в своих устройствах предлагала свою собственную систему для кодирования символов естественных языков, несовместимую с таковой системой конкурентов. Каждая корпорация таким образом хотела заставить покупателей приобретать исключительно свою «линейку оборудования», в рамках которой совместимость различных устройств была обеспечена.

Подобная ситуация не устраивала покупателей компьютерной техники и шла вразрез с национальными интересами США – ведь буквы английского языка в каждой из указанных систем кодировались по-своему, и это тормозило развитие национальной сферы ИТ в США. Поэтому американскому национальному стандартизирующему органу – ASA (позднее – ANSI) – была поставлена задача решить проблему путём разработки единого государственного стандарта на систему кодирования символов естественных языков в машинно-читаемом виде.

Был организован специальный комитет (X3.4 Committee), для работы в котором были приглашены представители крупнейших корпораций-производителей компьютерной техники. Некоторые согласились принять участие в этой работе, поскольку на тот момент путаница в области систем кодирования достигла такой степени, что, очевидно, стала причинять проблемы уже и им самим. Ведь речь шла уже о том, что из-за использования разных систем кодирования символов стал невозможен обмен информацией даже между двумя компьютерами, произведёнными одной и той же корпорацией, но принадлежащих к разным «линейкам» или семействам.

«У нас существовало более 60 различных систем, использовавшихся для кодирования символов естественных языков в компьютерах. Это было самое настоящее 'вавилонское столпотворение'»[1] – констатировал в интервью американскому журналу «ComputerWorld» Боб Бемер (Bob Bemer), с 1956-го по 1962-й годы – работник корпорации IBM и один из главных разработчиков системы ASCII, которая в 1963-м году была принята ANSI в качестве государственного стандарта США на кодирование символов естественных языков в машинно-читаемом виде. При этом принята она была в недоработанном виде; окончательная версия системы ASCII была утверждена в 1968-м году.

Заметим, что корпорация IBM – бесспорный лидер в производстве компьютерной техники в 1960-х – 1970-х гг. – тем не менее без каких-либо последствий для себя нарушала государственный стандарт ASCII на протяжении многих лет после его официального принятия (вплоть до августа 1981-го года, когда она выпустила первые компьютеры серии PC). IBM использовала в своих «мэйнфреймах» System/360, которые впервые поступили в продажу в 1964-м году, свою собственную, несовместимую с ASCII, патентованную систему кодирования символов – EBCDIC, – которая существовала в 57 различных версиях, в том числе «национальных». При этом получить от IBM документацию по версиям EBCDIC было чрезвычайно сложно.

В 1967-м году ISO[2] выпускает рекомендацию ISO 646, которая фактически сделала систему ASCII уже международным стандартом. И это при том, что система ASCII заведомо не удовлетворяла самым очевидным требованиям, предъявляемым к системе кодирования символов, пригодной для международного применения.

Как известно, количество одних только ныне используемых естественных языков, используемых в мире, превышает 2500. Общее количество символов, используемых только в одном из них – японском, к примеру, – превышает 65000.

В системе ASCII же для кодирования каждого символа использовалось 7 бит, а её таблица символов содержала 128 позиций (из которых 32 были отведены под управляющие последовательности, а собственно под символы было отведено, соответственно, 96). Среди этих 96 позиций 52 были уже забронированы за заглавными и строчными буквами английского алфавита, 10 – за арабскими цифрами, прочие – за различными знаками препинания и специальными символами. Для изображения символов и букв «всех прочих» национальных языков, кроме английского, ISO определила в этой таблице «открытые позиции», общим количеством… 10 штук.

Чтобы обеспечить «поддержку» работы с другими языками, кроме английского – не «работу», а именно «поддержку», рассматриваемую ISO, таким образом, как нечто опциональное! – предлагалось использовать технические ухищрения – управляющие последовательности (escape-последовательности). После того, как компьютер встречал в тексте специальную управляющую последовательность, считалось, что произошла смена стандартной таблицы символов, используемой в ASCII, на одну из «дополнительных», содержащую символы того или иного «дополнительного» языка. Таких «дополнительных» таблиц ISO было утверждено в общей сложности более 180!

Затем систему кодирования ASCII пересмотрели, и для кодирования каждого символа стали использовать не 7, а 8 бит (этот 8-й бит существовал и ранее, но использовался не для представления данных, а для осуществления контроля чётности). Заметим, что в тексте стандарта ASCII такое «расширение» никак не регламентировано. Это привело к многочисленным проблемам, так как существующее на тот момент ПО работало с ASCII в его оригинальном виде[3].

Объём таблицы символов возрос до 256 позиций. Это позволяло отказаться от использования управляющих последовательностей для обеспечения работы с некоторыми языками, символы которых можно было уместить в появившееся место[4]. ISO выпускает стандарты ISO 2022 и серию стандартов ISO 8859-X (X – цифра от 1 до 15), описывающие, как следует задействовать новую возможность.

Серия стандартов ISO 8859-X по заказу ISO разрабатывалась с середины 1980-х гг. ассоциацией крупнейших европейских производителей компьютерной техники (ECMA, European Computer Manufacturer's Association). В каждом из этих стандартов были определены 15 разных таблиц символов, каждая из которых содержала 256 позиций.

При этом оговаривалось, что первые 128 символов каждой таблицы должны обязательно быть теми же самыми, что в стандартной 128-символьной таблице системы ASCII (и рекомендации ISO 646). Таким образом, в каждой из этих таблиц вновь обеспечивалась неприкосновенность для символов английского языка. Для представления символов других языков отводились остающиеся позиции, во вторых половинах этих 256-символьных таблиц.

Совершенно очевидно, что определённая в ISO 8859-X схема заведомо неприемлема, так как в ней символы разных языков обозначаются одними и теми же двоичными последовательностями, и определить, какую именно таблицу символов использовать для их прочтения – ISO 8859-1 или же, например, ISO 8859-5, – невозможно, если не знать этого заранее.

Однако это – только половина проблемы. Дело в том, что американские корпорации не соблюдали стандарты ISO серии 8859-X. В «национальных» версиях своего программного обеспечения они использовали расширенную до 8 бит систему кодирования ASCII и таблицы символов, содержащие 256 позиций; первые 128 символов в которых соответствовали стандартной 128-символьной таблице 7-битной системы ASCII (то есть вновь английский язык не затронут), а расположение символов национальных языков во второй половине таблицы не соответствовало расположению, определённому ISO в стандартах серии 8859-X[5].

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

Возьмём в качестве примера многострадальный русский язык. Для кодирования больших и малых букв русского алфавита используются следующие несовместимые или не полностью совместимые между собой таблицы (и это не полный список; см. http://czyborra.com/charsets/ http://czyborra.com/charsets/cyrillic.html#Unicode):

– ISO использует таблицу «Cyrillic», описанную в стандарте ISO 8859-5;

– корпорации IBM и Microsoft в своих ОС PC DOS и MS DOS использует таблицу CP866. CP866 – это один из представителей целой серии таблиц, используемых для «поддержки национальных языков» различными производителями DOS (CP437, CP850, CP852 и т.д., вплоть до CP874. Интересно, что ISO 8859-5 в этом наборе есть и упоминается как CP915). Очевидно, эта серия таблиц была составлена разработчиками и региональными продавцами компьютерной техники (Microsoft называет её «OEM charsets»), но из приведённых в документации ОС PC DOS 2000 ( (tm) of IBM Corp. ) данных ясно, что она как-то между прочим и фактически тайком была стандартизирована ISO – в документе ISO 9241-3, описывающем параметры мониторов[6] – «в дополнение» к уже определённой ранее серии стандартов 8859-X;

– корпорация Apple в русскоязычной версии своей ОС Mac OS использует свою таблицу X-Mac-Cyrillic;

корпорация Microsoft в своих ОС Windows 3.X и Windows 9X использует таблицу CP-1251. CP-1251 – это также представитель целой серии таблиц (CP-125X, где X – от 0 до 8), использованных Microsoft в различных «национальных» версиях Windows. При этом в документации к Windows 3.X Microsoft называет их «ANSI charsets», и вполне возможно, что они действительно были где-то и когда-то стандартизированы ANSI;

– советский (теперь – русский) национальный стандартизирующий орган ГОСТ определяет таблицу КОИ-8 (ГОСТ 19768-74; в этом стандарте определяется также 128-символьная таблица КОИ-7), затем – таблицу, известную как «основная кодировка ГОСТ» (ГОСТ 19768-87). (Впоследствии, правда, ГОСТ принял «альтернативную кодировку», таблица которой соответствовала, за малым исключением, таблице CP866 – только было уже поздно).

На практике в аппаратном обеспечении компьютерных систем[7] и в ОС для работы с текстами на разных языках использовались и по сей день используются 8-битная система кодирования символов вкупе с вышеописанными различными таблицами символов, объёмом в 256 позиций каждая. Однако американские компьютерные корпорации IBM и Xerox ещё в первой половине 1980-х начали работу над созданием новой «многоязычной» системы кодирования, в которой для представления символов используются двоичные последовательности длиною в 16 бит, а также единая большая таблица символов объёмом в 65536 позиций.

Впоследствии к этим корпорациям присоединились другие, и был начат проект, названный представителями американской компьютерной индустрии «Unification Code», или Unicode. Причём, дошло до того, что в 1991-м году эти корпорации (в их числе также Adobe, Microsoft и др.) для продвижения Unicode в качестве международного стандарта создали одноимённый транснациональный консорциум[8].

Главной задачей Unicode официально было объявлено сведение существующих в мире символов естественных языков в указанную большую таблицу и обеспечение одновременной и «равноправной» работы с ними. То есть, очевидно, когда количество недовольных «проблемой кодировок» пользователей превысило некоторую «критическую массу», указанные корпорации решили «обнародовать» систему Unicode и представить её как решение данной проблемы, делая намучившимся операторам ПК заманчивое, на первый взгляд, предложение – покупать поддерживающее её ПО.

Однако на самом деле и система Unicode является не окончательным решением проблемы кодирования символов, а лишь паллиативом. Дело в том, что метод кодирования, используемый в оригинальной версии Unicode, не предусматривал использования управляющих последовательностей для переключения между «базовой» и возможными «дополнительными» таблицами символов (как в ISO 646), поэтому максимальное количество символов, которые можно было представить, пользуясь Unicode, равнялось объёму одной-единственной («базовой») таблицы символов, используемой в этой системе – 65536.

А поскольку мы знаем, что в одном только японском языке используется около 65000 символов, можно понять заранее, что метод и таблица символов Unicode на самом деле малы для представления всех символов языков мира.

Таблица символов, используемая в Unicode, устроена следующим образом. Она разбита на 256 рядов. Первые ряды содержат некоторые из старых таблиц символов (объёмом в 128 или 256 позиций каждая) , определённых для некоторых языков. Самый первый ряд (под номером 0) представляет из себя таблицу ISO 8859-1 (в свою очередь, она содержит 128 символов из таблицы 7-битной системы ASCII, а также некоторые символы, используемые в языках стран Западной Европы).

Последующие ряды таблицы отведены под некоторые новые символы (например, математические), но преимущественно – под иероглифы. Однако поскольку используемой в Unicode таблицы объёмом в 65536 символов заведомо недостаточно для представления всех иероглифов, используемых в китайском, японском и корейском языках – хотя официально корпорации-разработчики Unicode заявляют об их поддержке как об одной из главных положительных черт своей системы, – иероглифы, которые, по мнению корпораций, «похожи» друг на друга, было решено «унифицировать» – то есть оставить только такое их начертание, которое принято в китайском языке.

В общей сложности в таблице символов системы Unicode (на данный момент, то есть в версии 3.0 – см. ниже) насчитывается около 28000 иероглифов. Как видно, многие иероглифы – в частности те, что в Японии используются для написания имён людей, названий местностей, а также в исторических текстах – вообще были оставлены «за бортом». При этом «похожие» и действительно одинаковые символы европейских языков, например, букв «A», «унификации» подвергнуты не были, поэтому в то же самое время масса места в таблице символов Unicode используется, по сути, впустую.

Как следствие, жители стран Юго-Восточной Азии, за которых американские корпорации пытаются решить, какие символы им «разрешается» использовать в компьютерной технике, а какие – «запрещается», уже в течение нескольких лет борются с системой Unicode. Она совершенно не соответствует самым первоочерёдным требованиям, предъявляемым к ней в этих странах, – вопреки рекламным заявлениям корпораций-членов консорциума.

Уместно рассмотреть теперь, какие агрессивные шаги предпринимают корпорации для утверждения Unicode в качестве международного стандарта.

В начале 1990-х в ISO для решения проблемы кодировок рассматривалась другая, более совершенная чем Unicode, система кодирования символов – UCS (Universal Coded Character Set). Объём её таблицы символов составляет примерно 4,3 миллиарда символов (а точнее, 2^32=4294967296). Эта таблица разбита на 65536 «внутренних» таблиц по 65536 символов каждая, и разбивка этих «внутренних» таблиц (256x256 рядов) совпадает с разбивкой таблицы, используемой в системе Unicode. Для переключения между «внутренними» таблица ми в UCS предлагалось использовать управляющие последовательности.

Система UCS была описана в «черновике» ISO DIS-10646.1:1990, подготовленном ISO/IEC JTC1/SC02/WG02. Её поддержали европейские и японские исследователи. Однако американские корпорации UCS не устраивала. А поскольку ISO, как она сама указывает в своих документах, «выпускает только те стандарты, которые нужны рынку», а также потому, что многие нанимаемые ISO «эксперты» – это работники американских компьютерных корпораций, то неудивительно, что вскоре черновик ISO DIS-10646.1:1990 тихо прекратил своё существование.

«Зато» появился – уже в качестве не черновика, а стандарта – документ ISO/IEC 10646 Version 2, позднее названный ISO/IEC 10646-1: 1993. Он был обозначен как «ISO/IEC 10646 Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane», и в качестве его базовой таблицы символов (т.е. первой из «внутренних» 65536-символьных таблиц) была утверждена… правильно, таблица системы Unicode, со всеми вытекающими отсюда последствиями.

Заметим, что по мере изменения и пополнения таблицы символов системы Unicode и выхода новых версий этой системы – а эта работа ведётся постоянно, поскольку изначально система Unicode была представлена в ISO в недоработанном виде – выходят и новые документы ISO. Система Unicode существует в общей сложности в следующих версиях: 1.1 (соответствует стандарту ISO/IEC 10646-1: 1993), 2.0, 2.1 (тот же стандарт ISO/IEC 10646-1: 1993 плюс дополнения: «Amendments» с 1-го по 7-е и «Technical Corrigenda» 1 и 2), 3.0 (стандарт ISO/IEC 10646-1:2000). В начале 2002-го года планируется выход Unicode 3.2, а в 2003-м – Unicode 4.0.

Кстати, работа по «унификации» иероглифов для таблицы символов 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-ресурсов если не невозможным, то, как минимум, нефункциональным и потому нежелательным. Символам английского языка, напротив, всегда «горит зелёный свет»;

– существование «проблемы кодировок» препятствует навигации по не англоязычным текстовым материалам в сети Internet, так как оно значительно увеличивает требования к вычислительным мощностям и программному обеспечению компьютерных систем, на базе которых строятся поисковые серверы Internet. Кроме того, заметим, что на важнейшей – начальной – стадии развития Internet, когда на серверы выкладывались данные, ни клиентского, ни серверного ПО, которое позволяло бы удовлетворительным образом решить «проблему кодировок», практически не было. Тем, кто не согласен, предлагаю вспомнить, сколько таблиц символов и с каким качеством «понимали» ранние версии, ну, хотя бы www-броузеров Netscape Navigator и Internet Explorer… Поэтому можно с полной ответственностью заявить, что это воспрепятствовало равноправному участию всех стран в построении международного информационного пространства. «Проблема кодировок» не дала шансов вырваться в этой важнейшей области ИТ в лидеры ни одной из не англоязычных стран, так как не позволила своевременно разместить в сети Internet их национальное культурное достояние и обеспечить его общедоступность;

– проявление «проблемы кодировок» в сервисах www, e-mail и news оказало колоссальное влияние не только на поставщиков информации, но и на её конечных потребителей: во-первых, увеличивается общее время пребывания людей в Internet (что выгодно провайдерам, в конечном итоге приносящим доход экономике США), во-вторых, большинство непрофессионалов таким образом вынуждается пользоваться для работы с Internet теми программами, в которых поддерживается наибольшее количество таблиц символов и методов кодирования. Как правило, такое ПО относится к одной из двух категорий – произведённое корпорациями в соответствии с их интересами (вероятно, нет необходимости лишний раз перечислять здесь его, мягко говоря, недостатки) или же предлагаемое за отдельные деньги. ПО, принадлежащее к последней категории, скорее всего, будет загружено нуждающимися из Internet, что вытянет из их карманов ещё больше денег в карманы провайдеров.

Наконец, существование «проблемы кодировок», вкупе с чрезвычайно низким качеством перевода «национальных» версий многочисленных программных продуктов (да и всей относящейся к ИТ терминологии, запутанной даже в оригинальных, преимущественно англоязычных, источниках), а то и полным отсутствием таковых, послужило серьёзным толчком к «англификации» мира.

Получается, что сложившиеся (или всё же кем-то намеренно сложенные?) обстоятельства в сфере ИТ фактически в принудительном порядке заставляют всё больше и больше людей изучать английский язык и даже переходить на использование его алфавита, отказываясь от алфавитов своих национальных языков – вспомните-ка так часто вынужденно используемую в www и e-mail транслитерацию! Ажиотаж вокруг этого уже сейчас активно подогревают некоторые псевдонаучные деятели, ненавязчиво убеждающие, в частности, русскоязычную общественность в том, что «лет через 30-40 она естественным образом перейдёт на использование латиницы»…

Чем это грозит накапливаемому в течение веков национальному информационно-культурному потенциалу, вероятно, не менее очевидно, чем стратегический характер «проблемы кодировок». И то, что направлена она не только на отдельно взятый «великий и могучий» русский язык… Уместно обратить внимание на то, что наибольший вред «проблема кодировок» имеет тенденцию причинять именно государствам с наиболее богатыми культурными традициями, таким как Япония, Китай (Тайвань) и Южная Корея. При этом отметим, что данные государства являются преуспевшими в развитии не только культурной, но и, по совместительству технологической базы. Высокотехнологическая промышленность («hi-tech») в этих странах является единственным реальным конкурентом таковой промышленности США. Не правда ли, интересное совпадение?!

В завершение статьи хотелось бы привести несколько фактов без комментариев.

В таблице символов японского национального стандарта JIS X 0208-1990 предусмотрено место не только для иероглифов японского языка, но также для букв греческого алфавита и кириллицы; в то же время аналогичные советско-росийские ГОСТы, как было показано выше, не дают пользоваться не то что японскими, но даже собственными, русскими, буквами. Не менее уместно заметить, что ГОСТ уже много лет как нарушает собственные стандарты, и даже сайт этого ведомства выдаёт страницы с использованием таблицы символов CP-1251[12].

В 1991-м году в Испанию была завезена крупная партия западных компьютеров, на которых использовалась таблица символов, не содержащая одной из букв алфавита национального языка (а именно буквы «N под тильдой»). В результате этого произошёл скандал на государственном уровне: «возмущённые возможностью искажения испанских слов (в том числе и ESPAN~A) парламентарии обязали торговых посредников оплатить стоимость адаптации партии компьютеров, а впредь на таможнях осуществлять 'входной контроль'»[13]. Что касается русского ГОСТа, в ряде своих вышеперечисленных творений стандартизировал на государственном уровне отсутствие в таблице символов одной из букв национального алфавита (Ё)…

Несмотря на то, что в российских научных кругах имеется ряд интересных предложений по решению «проблемы кодировок»[14], о серьёзной поддержке их на государственном уровне речи не идёт. Подавляющей части русскоязычной широкой общественности эти предложения вообще неизвестны. Какой уж тут разговор о «национальных интересах»?

На этом разрешите окончить статью. Надеюсь, мне удалось предоставить читателям достаточно пищи для размышлений…