лекции (1998) (Буров), страница 9

Возникает вопрос. Например, Java поддерживает UNICODE, насколько просто создавать многоязыковые приложения на Java? К сожалению, нет. Почему? Это мы и попытаемся сейчас разобрать.

Строго говоря, тема создания многоязыковых приложений к теме ЯП не относится. Но виноваты в возникновении этой проблемы, как раз ЯП. В свое время было очень мало уделено значения представлению данных с точки зрения ЯП. Создателям ЯП казалось, что достаточно ввести понятие некоторого символьного типа данных, либо как числовое (C/C++), либо как отдельный тип (Pascal, Modula, Ada). Вопросы представления и кодировки совершенно не учитывались. Создатели были больше озабочены лексикой своих языков, то есть отображением данных на уровне стандартных устройств ввода-вывода, нежели на уровне программ. И это, вообще говоря, явилось недочетом.

Аналогию можно провести с языком Algol-60, он по сравнению с Fortran и другими языками обладал несколькими недостатками. Первый, наиболее важный - то, что у него отсутствовала стандартная библиотека ввода-вывода. Создатели отдали это на откуп реализаторам. В результате, в каждой реализации Algol-60 приходилось изучать новую библиотеку. Это не только препятствовало переносимости программ, но и препятствовало переносимости программистов - проще было изучить Fortran, где средства ввода-вывода были стандартизованы в достаточной мере, нежели переходить с системы на систему, изучая все с нуля.

Примерно такая же ситуация сложилась с вопросом представления символьных данных в ЯП, то есть он был попросту проигнорирован. Вообще говоря, многие грамотные вещи из ЯП были перенесены и в ОС и в архитектуры ЭВМ. Например, в первых ЭВМ не было стека, он был введен после того, как стало ясно, что очень удобно реализовывать программы с его помощью. Также было и с разделением программ на кодовый сегмент и сегмент данных с запрещением записи в кодовый сегмент - это пришло из языков высокого уровня. К сожалению, с символьным типом данных такого не случилось, и программистам приходится выкручиваться из сложившейся ситуации через изучение некоторых концепций ОС.

Чем обусловлены сложности создания многоязыковых приложений? Исключительно историческими причинами - тем, что изначально ОС создавались для моноязыковой среды. То есть почти все ОС являются восьмибитными с точки зрения представления данных, они так или иначе ориентированы на то, что символьные данные представлены в восьми битах. Типичными примерами являются, как MS Windows95, так и Unix. Но несмотря на то, ЯП пытаются поддерживать и другие концепции данных. Например, в C с помощью средств развития появляются типы W_CHAR (он эквивалентен unsigned short), то есть если мы переходим к типу W_CHAR, то программирование становится похожим на Java за исключением некоторых тонких моментов, да и в Java это происходит автоматически, а здесь - «ручками».

Концепция 8 битов давным-давно перестала устраивать разработчиков. Поэтому было введено понятие charset. Вместо одного универсального набора символов (типа unicode) были введены наборы символов для английского и западно-европейских, восточно-европейских стран. Опять же, все они в 8 бит не умещались и были разделены (SBCS - single byte character set). Кроме этого, появилось понятие языков с многобайтным представлением символов. Например, китайский, японский, корейский, арабские языки имеют более мощные наборы символов, которые не умещаются в 8 бит. В результате появляется MBCS (multi byte character set). Это нечто типа UTF-8. Не случайно UTF-8 похож на японский стандарт Shift-JIS. Опять же, в этом коде если старший бит равен 0, то символ из ASCII-7, если же старший бит - 1, то это означает, что оставшиеся 7 бит плюс следующий байт кодируют символ из японского алфавита.

В результате возникает три варианта -

1. однобайтная система, причем, какой charset она отображает определяется с помощью понятия кодовой страницы (codepage), они есть для базовых языков, если codepage русская, то символы старше 127 кодируют русские буквы, если, например, codepage-1252, то эти коды относятся к западноевропейским языкам и т.д.

2. многобайтные последовательности (для кодирования, например, восточных языков с большим набором символов)

3. Unicode.

Теперь понятны сложности программирования в таких 8 битных средах. Это тесно связано с понятием шрифта. Каждый шрифт должен отображать некоторый charset. Если шрифт ориентирован на отображение восьмибитных символов, то он может только один charset. Если нам надо отображать информацию из различных charset (например, английский, русский и японский одновременно), то это - проблема. Чисто 8 битные системы этой проблемы не решают. Некоторый механизм предоставляет создание соответствующих библиотек. Например, в Windows 95, в принципе, можно писать unicode программы. Можно использовать W_CHAR, откомпилировать текст так, чтобы он мог использовать только кодировку Unicode и самим вставить некоторые преобразования. То есть в Win32 есть соответствующие функции:

MultiByteToWideChar (CP,... )

WideCharToBultyByte (CP,... )

(Заметим, что и Shift-JIS и ANSI charset могут рассматриваться как multibyte.) Интересно, что первым параметром (остальные - это всякие буферы и флаги) является номер кодовой страницы. То есть интерпретация идет: если multibyte, то берется либо русская кодовая страница, либо японская и, исходя из этого, происходит перекодировка в Unicode. Аналогично, в Unicode каждый символ уникален и однозначно определяет язык и charset. Однако multibyte с этой точки зрения меньший, так как в Shift-JIS, например, мы не можем одновременно увидеть английский и французский языки (английский и японский - можем). Поэтому там тоже стоит параметр кодовой страницы - в какую кодовую страницу кодировать соответствующий символ из Unicode.

И поэтому, если у нас есть элементы «окна», которые поддерживают только 8 битные шрифты, то есть шрифты, ориентированные на один charset, то даже такие функции, которые есть во всех версиях Windows (Win95/98/NT) (заметим, что большинство элементов управления Windows: однострочный Edit, заголовок окна и др. поддерживают только один шрифт), то в таких элементах мы не можем использовать различные языки. Немного спасает ситуацию наличие элемента управления RichEdit, который допускает множество шрифтов, а следовательно и множество charset’ов. Используя его, можно как-то реализовать в программе многоязыковость. Однако, это все же не распространяется на заголовки окон, простые элементы управления, типа списков и т.д.

Та же самая проблема возникает и в Unix. Однако, вспомним, что в Unix изначально использовалась для графическово интерфейса система X Window, которая стала стандартом для построения графических пользовательских систем.

X Window - система построенная по архитектуре Client<->Server. Есть, собственно XClient. X Window - с одной стороны стандартизует протокол между клиентом и сервером, а с другой стороны есть соответствующая библиотека с привязкой к конкретным языкам (например, C и Lisp), которая позволяет писать клиентские программы. Библиотека, которая осуществляет привязку к языку C называется Xlib. Это нижайший уровень для программирования X Window. Ниже ничего не может быть. Одновременно с Xlib была разработана система Xt (X toolkit), которая стандартизовала некий подход (заметим, что Win API стандартизует не только подход, но и сами элементы управления - они зашиты в ОС и если в Windows зашит однобайтный список, то мы ничего с точки зрения многоязычности, кроме как переписать элемент управления, сделать не можем) к интерфейсу. Организация же системы Xt значительно более гениальна с этой точки зрения, хотя появилась она до Windows (увы, увы...), она стандартизует событийную ориентированность, вводит понятие Widget, понятие обобщающие элементы управления, и в то же время не накладывает никаких ограничений на визуальность соответствующего интерфейса.

Конечно, над Xt также надстраиваются какие-то системы прикладных widget’ов. Например, Athena. Или Motif, который является реальным единственным стандартом. Это система widget с конкретным стандартом на пользовательский интерфейс (очень напоминает Presentation Manager из OS/2). Интересно, что в Motif все строки уже не есть тип char, т.к. создатели были достаточно умны, чтобы понять, что рано или поздно придется и по-китайски писать. Естественно, типа char на это бы не хватило, и строке имеют тип XmString, у которого есть такие свойства, как шрифт, charset и т.д. Таким образом XmString пригоден для отображения произвольных типов символов. Проблемы 8 битности в Unix были решены за счет создания адекватной библиотеки графических примитивов: Xlib, Xtoolkit, Motif. Окончательно вопросы интернационализации были решены только на уровне Motif, причем версия Motif 1.2 была посвящена добавлению межязыковых возможностей на 90%.

То есть создавать межнациональные приложения под Unix на Motif можно. Но заметим, что это опять же явилось результатом довольно долгой и сложной надстройки над ОС и ЯП. Вообще говоря, Microsoft - одна из первых больших фирм, которая осознала неадекватность такой ситуации. И нужно сказать, что подход Windows NT, а это первая ОС, созданная Microsoft (MS-DOS - это не ОС, а некий «пускач» программ, Windows 3.1 - оболочка, Windows 95 - вообще не пойми что) оказался очень грамотным. Интересно, что для создания Windows NT Билл Гейтс пригласил команду чужаков, то есть людей, которые никакого отношения к Microsoft до этого не имели.

Windows NT с момента своего создания полностью поддерживала Unicode. Давайте разберемся, что это значит. Ведь писать интернациональные приложения под Windows NT стало не легче, однако это следствие отставания средств разработки и только их. Сама ОС в этом плане честна - все символьные данные внутри Windows NT хранятся в формате Unicode. Например, формат Windows Registry - Unicode, формат файловой системы - Unicode (а ведь это тоже немалая проблема). Более того, все тексты внутри ОС передаются исключительно в Unicode формате. Но учитывая то, что люди сейчас в Unicode не работают, да и для создания англоязычных (и русскоязычных) приложений он, вообще говоря, не нужен, в Windows NT предусмотрены внутренние перекодировщики на уровне Win32 API, которые преобразовывают текст из Unicode в ANSI charset с соответствующими кодовыми страницами и обратно. Сделано это для удобства программирования и совместимости. И интересен тот факт, что под Windows NT программировать в Unicode эффективнее, так как в этом случае текстовые данные не подвергаются постоянному перекодированию, с этой точки зрения большинство программ под Windows NT работают сейчас медленнее, чем могли бы. Заметим также, что две системы под NT общаются между собой по сети через Unicode.

Возникает вопрос - создавать многоязыковые приложения просто? Ответ - нет. Единственным, к большому сожалению, адекватным инструментом создания многоязыковых приложений является Visual C++. Все вышеуказанные тонкости Win32 API зашиты на нижний уровень. Программировать на Win32 API малоинтересно. Для написания приложений используется обычно библиотека MFC (Microsoft Foundation Classes). И на VC++ и MFC можно программировать интернациональные приложения под NT. Для этого достаточно установить шрифт, который поддерживает все charset’ы (а хоть один такой шрифт есть - Lucida Unicode), перекомпилировать программу с «#define unicode». Тогда все символьные переменные станут типа w_char, правда, в случае если вместо char используется tchar, тогда tchar будет заменен либо на char, multichar или w_char. Кроме этого, версия MFC, которая поддерживает Unicode позволяет использовать все возможности, связанные с Unicode, то есть при посылке окну некоторого текста в Unicode, оно правильно его интерпретирует. И, хотя MFC по концептуальности уступает многим другим библиотекам, тем не менее некоторые ее свойства, такие как интернационализация, делают ее порою более привлекательной. Интересно, что система Delphi, которая является вобщем-то наиболее быстрой системой разработки приложений, до сих пор Unicode не поддерживает.

На этом мы закончим с символьным типом данных, да и вообще с типами данных.

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

int f(char);

если к этому приписать typedef, да и еще обозначить:

typedef int (*f)(char);

то данное описание описывает функции или процедуры. Точнее говоря, значениями данного типа являются указатели на соответствующие объекты. Если у нас описана переменная:

f g;

то ее можно вызывать двумя способами:

(*g)(‘A’);

g(‘A’);

Аналогично, в других ЯП, например, Modula-2:

type PRC=PROCEDURE (X: INTEGER);

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

В двух языках, которые мы также рассматриваем, процедурного типа нет, а именно - стандартный Pascal (в Turbo Pascal такой тип есть) и язык Ada83. Для того, чтобы понять «почему?», давайте сначала посмотрим, а зачем они вообще нужны?