Ada_Ru форум

Обсуждение языка Ада

AI-00285: пакеты поддержки кириллицы

Оставить новое сообщение

Сообщения

Vadim Godunko
AI-00285: пакеты поддержки кириллицы
2002-12-07 12:53:11

Здравствуйте!

 

В свете происходящего пересмотра нового стандарта языка предлагается внести предложение дополнить Appendix A спецификациями пакетов, содержащих определения символов кириллицы, константами для классификации символов и т.д.

 

Для начала предлагаю Вашему вниманию спецификацию пакета Ada.Characters.Wide_Cyrillic, определяющего коды букв кириллицы. В основе его лежит пакет Ada.Characters.Wide_Latin_1, но я предлагаю удалить из него все символы, не относящиеся к кириллическим буквам и использующимся в "кириллоязычных" странах специальных символов (например, таких как знак параграфа, знак номера и т.д.). Это позволит не вносить "перегрузки" имен символов при одновременном использовании в программе пакетов Wide_Latin_1 и Wide_Cyrillic.

 

Кроме этого хотелось-бы иметь стандартный пакет для классификации таких символов, преобразования заглавных/строчных букв. Предлагаемое в AI-00285 решение этой проблемы не совсем подходит в наших условиях. Определить пакет Ada.Characters.Cyrillic.Handling невозможно из-за необходимости определения пакета Ada.Characters.Cyrillic. Определить последний мешает целый ряд проблем:

- тип Character не представляет возможности использования иных наборов символов, кроме Latin_1, без мистического способа подстановки компилятором соответствующих пакетов Ada.Characters.Handling и Ada.Strings.Maps.Constants;

- отсутствие единого стандарта представления кириллических букв в 8-ми битных символах (мне известны по крайней мере следующие кодировки: ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac). Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной стороны просто глупо, а с другой стороны это только ухудшит переносимость программ.

 

Вадим Годунко

Hi !

 

Am Samstag, 7. Dezember 2002 13:53 schrieb Vadim Godunko:

 

- отсутствие единого стандарта представления кириллических букв в 8-ми битных символах (мне известны по крайней мере следующие кодировки: ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac). Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

 

UTF-8/UNICODE, остальное в мусорку.

К стыду своему, ничего в этом не понимаю. :((

 

Могу сказать только:

 

1. Выглядит солидно

2. Вещь крайне нужная

Ilja Wasiltschenko wrote:

 

- отсутствие единого стандарта представления кириллических букв в 8-ми

битных символах (мне известны по крайней мере следующие кодировки:

ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac).

Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной

стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

 

UTF-8/UNICODE, остальное в мусорку.

 

На мой взгляд, не стоит забывать и о UCS-2, UCS-4.

hi,

Vadim Godunko wrote:

Здравствуйте!

>

В свете происходящего пересмотра нового стандарта языка предлагается внести предложение дополнить Appendix A спецификациями пакетов, содержащих определения символов кириллицы, константами для классификации символов и т.д.

мысль оч даже хорошая!!!

только вот задачка эта не так проста как может показаться

на первый взгляд :(

Предлагаемое в

AI-00285 решение этой проблемы не совсем подходит в наших условиях.

почитал я это AI-00285...

тут, imho, "собака глубжее зарыта"...

опять же imho, к сожалению они рассматривают только часть проблемы: только то что касается символов и кодировок, а это только половина дела (правда, справедливо заметить, что довольно значительная).

более корректно это было бы обозвать проблемой поддержки локализации.

Определить пакет Ada.Characters.Cyrillic.Handling невозможно из-за необходимости определения пакета Ada.Characters.Cyrillic. Определить последний мешает целый ряд проблем:

эт точно :(

- тип Character не представляет возможности использования иных наборов символов, кроме Latin_1, без мистического способа подстановки

компилятором соответствующих пакетов Ada.Characters.Handling и

Ada.Strings.Maps.Constants;

- отсутствие единого стандарта представления кириллических букв в 8-ми битных символах (мне известны по крайней мере следующие кодировки: ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac).

есть, кажись, еще koi8-e/koi8-f...

"больше стандартов хороших и _разных_"

Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,

хотябы для взаимодействия с так называемыми "малыми системами"

>

>

Вадим Годунко

Alex

Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

 

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,

хотябы для взаимодействия с так называемыми "малыми системами"

 

Не уверен что нужно обязательно вводить все кирилические кодировки в стандарт.

Если в россии в кодировками бардак, это не значит что стандарт Ада должен тоже отражать этот бардак.

А кодировки других языков в стандарт вводят, кто нибудь в курсе ? И в каком виде это дело происходит с другими языками, где нибудь есть эта информация ?

Oleksandr Havva wrote:

 

Предлагаемое в

AI-00285 решение этой проблемы не совсем подходит в наших условиях.

 

 

почитал я это AI-00285...

тут, imho, "собака глубжее зарыта"...

опять же imho, к сожалению они рассматривают только часть проблемы:

только то что касается символов и кодировок, а это только половина дела

(правда, справедливо заметить, что довольно значительная).

более корректно это было бы обозвать проблемой поддержки локализации.

 

Похоже именно то, что называется "локализацией" они и хотят обойти. По большому счету я с ними согласен (пример. Записав текстовый файл с цифрами с плавающей точкой в локализации ru, я его не прочту в локализации en. Почему? Думаю все и сами догадались: у нас дробную часть отделяет запятая, а у них - точка. И это только цветочки.)

 

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

 

 

Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной

стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

 

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,

хотябы для взаимодействия с так называемыми "малыми системами"

 

именно наши "малые" системы и принесли этот хаос. И переносить хаос в стандарт не хотелось-бы. А вот разработать модули для поддержки этого бардака можно (а может и нужно). Если кому нужна будет связь со старыми системами - нет проблем, пожалуйста. А новые извольте строить по человечески.

 

В настоящее время у меня есть модули для работы в ГОСТ/ECMA/ISO-8859-5. Работает преобразование Character <=> Wide_Character, классификация буква, цифра. Но дело встало при попытке определить "базовые" символы. С русскими проблем нет. В "небазовые" входит только Ё и ее базовый аналог Е. А вот что делать с украинскими/белорусскими буквами - понятия не имею. Если кто знает - прошу помочь. Можно будет доделать и выложить на сайт.

 

Вадим

Dmitriy Anisimkov wrote:

 

А кодировки других языков в стандарт вводят, кто нибудь в курсе ?

И в каком виде это дело происходит с другими языками, где нибудь есть эта

информация ?

 

Все, что мне известно, это обозначенный AI. Там предлагается поддержка ISO-8859-15 (Latin9). Суть проста - Европа, объединившись, решила сделать единую валюту. Это-то ничего, да они придумали для обозначения её специяльный значок. Вот они и продвигают эту кодировку.

 

А я подумал, что под эту волну можно и кириллизацию протолкнуть...

hi,

Dmitriy Anisimkov wrote:

Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной стороны просто глупо, а с другой стороны это только ухудшит

переносимость программ.

>

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,

хотябы для взаимодействия с так называемыми "малыми системами"

>

Не уверен что нужно обязательно вводить все кирилические кодировки в стандарт.

Если в россии в кодировками бардак,

ежели б бардак был только с кирилличными кодировками,

то это было бы не так грустно

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

(это только то что мне известно!!!)

это не значит что стандарт Ада должен

тоже отражать этот бардак.

А кодировки других языков в стандарт вводят, кто нибудь в курсе ? И в каком виде это дело происходит с другими языками, где нибудь есть эта информация ?

более-менее полно проблемы локализации решаются

_только_ библиотеками поддержки языков линии С/С++

возможно именно поэтому они такие вездесущие :(

локализация в целом описывается стандартами ISO

Alex

hi,

Vadim Godunko wrote:

Похоже именно то, что называется "локализацией" они и хотят обойти.

imho, "половинность" решения не есть хорошее решение

По

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

локализации en. Почему? Думаю все и сами догадались: у нас дробную часть отделяет запятая, а у них - точка. И это только цветочки.)

эт точно :(

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

похоже, опять же imho, что достаточно компромиссным решением

является реализация поддержки локали в glibc

там все данные локализации располагаются отдельно от

самих алгоритмов, за счет чего все алгоритмы (подпрограммы)

унифицированы и едины. сменной частью являются сами данные

локализации, что кстати, позволяет добавлять/убирать различные

данные локализации не затрагивая самих бинарников библиотеки.

>

>Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной >стороны просто глупо, а с другой стороны это только ухудшит

>переносимость программ.

>

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,

хотябы для взаимодействия с так называемыми "малыми системами"

>

именно наши "малые" системы и принесли этот хаос. И переносить хаос в стандарт не хотелось-бы. А вот разработать модули для поддержки этого бардака можно (а может и нужно). Если кому нужна будет связь со старыми системами - нет проблем, пожалуйста. А новые извольте строить по человечески.

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

"воткнуть" полновесный юникод, и именно по причине "малости"

системы. примеров могу насыпать... прям со старта :)

В настоящее время у меня есть модули для работы в ГОСТ/ECMA/ISO-8859-5. Работает преобразование Character <=> Wide_Character, классификация буква, цифра. Но дело встало при попытке определить "базовые" символы. С русскими проблем нет. В "небазовые" входит только Ё и ее базовый аналог Е. А вот что делать с украинскими/белорусскими буквами - понятия не имею.

ага...

сюрпрайз: кириллицу не только в Беларуси/России/Украине пользують есть еще болгары и югославы... может и еще кто, не помню

Если кто знает - прошу помочь. Можно будет доделать и выложить на сайт.

пытался я с этими делами разбираться, да переключился

на писательство буки. разрываться на части - не хоц-ца,

да и производительность моя не безпредельна :(

...опять же, основную работу тоже надо работать.

в обчем так-с...

делал я себе на эту тему базу данных по символам и кодировкам

на Interbase. оно не так чтоб супер база, а скорее инструмент,

для проверки кодов, плюс была идея генерить sql-скриптами

файлы исходников с таблицами кодов символов

(кстати, можно было бы не только под Аду!).

данные я брал из исходников glibc с оглядкой на UNICODE

версии 2-с-чем-то.

ежели такая поделка сгодиться то могу этим "чудом"

поделиться, только мне на вспоминания/разборки

день два точно понадобиться

>

>

Вадим

Alex

Oleksandr Havva wrote:

 

Похоже именно то, что называется "локализацией" они и хотят обойти.

 

imho, "половинность" решения не есть хорошее решение

 

Полная локализация интересна и применима только для полновесных интернациональных программных продуктов. Большая же часть ПО писанного на Ada к таковым не относятся. И "половинность" решения здесь считай "полное" решение.

 

 

похоже, опять же imho, что достаточно компромиссным решением

является реализация поддержки локали в glibc

там все данные локализации располагаются отдельно от

самих алгоритмов, за счет чего все алгоритмы (подпрограммы)

унифицированы и едины. сменной частью являются сами данные

локализации, что кстати, позволяет добавлять/убирать различные

данные локализации не затрагивая самих бинарников библиотеки.

 

А вот и не угадали. Последние версии (glibc-2.2) библиотеки используют массу "подгружаемых" модулей для реализации различных функций. В Ada это невозможно (если, конечно не извращаться).

 

 

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

"воткнуть" полновесный юникод, и именно по причине "малости"

системы. примеров могу насыпать... прям со старта :)

 

"Огласите, пожалуйста, весь список."

 

Малость на мой взгляд - микроконтроллеры. Но и программировать их на Ada - глупость. А вот все остальное оборудование уже на сегодняшний день обладает достаточными резервами памяти всех пород. И, кстати, никто не требовал использовать UNICODE. Речь идет исключительно о действующем стандарте ISO. А он на данный момент остановился на 16-ти битном представлении символов. Я согласен, что UNICODE пошел дальше, но в последней своей инкарнации он "тяжел" и для рабочих станций.

 

в обчем так-с...

делал я себе на эту тему базу данных по символам и кодировкам

на Interbase. оно не так чтоб супер база, а скорее инструмент,

для проверки кодов, плюс была идея генерить sql-скриптами

файлы исходников с таблицами кодов символов

(кстати, можно было бы не только под Аду!).

данные я брал из исходников glibc с оглядкой на UNICODE

версии 2-с-чем-то.

ежели такая поделка сгодиться то могу этим "чудом"

поделиться, только мне на вспоминания/разборки

день два точно понадобиться

Наверное пока не стоит делиться "чудом". Проше скачать с www.unicode.org все необходимые (и не очень необходимые) таблицы.

 

Вадим

hi,

Vadim Godunko wrote:

Полная локализация интересна и применима только для полновесных интернациональных программных продуктов. Большая же часть ПО писанного на Ada к таковым не относятся. И "половинность" решения здесь считай "полное" решение.

так-то оно так, но может "оно" как раз и не относится

к "полновесным интернациональным программным продуктам"

ввиду того что полновесной поддержки нет?

с этим делом что-то типа замкнутого круга получается,

или мне это только кажется?

>

похоже, опять же imho, что достаточно компромиссным решением

является реализация поддержки локали в glibc

там все данные локализации располагаются отдельно от

самих алгоритмов, за счет чего все алгоритмы (подпрограммы)

унифицированы и едины. сменной частью являются сами данные

локализации, что кстати, позволяет добавлять/убирать различные

данные локализации не затрагивая самих бинарников библиотеки.

>

А вот и не угадали.

ну... угадывать, предположим, я не угадывал...

просто, (согласен, каюсь) я несколько идеализировал реализацию

самой идеи - отделение данных локализации от подпрограмм

которые от нее (локализации) зависят.

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

"воткнуть" полновесный юникод, и именно по причине "малости"

системы. примеров могу насыпать... прям со старта :)

>

"Огласите, пожалуйста, весь список."

>

Малость на мой взгляд - микроконтроллеры. Но и программировать их на Ada - глупость. А вот все остальное оборудование уже на сегодняшний день обладает достаточными резервами памяти всех пород.

в качестве примера:

ISDN-телефоны (уж звиняйте, но вот с техникой связи мне как раз

в настоящее время и приходится возиться)

одна из возможностей этой игрушки - отображение на ЖК индикаторе (для справедливости замечу, что ИЖК не все модели имеют)

кроме номера того _кто_ Вам звонит, или с кем Вы в текущий

момент разговариваете, еще и отображение имени/фамилии звонящего. кроме того, на этом же ИЖК отображается дата/время.

не трудно догадаться, что желательно чтобы все это

было в соответствии с национальными особенностями.

засунуть в это устройство весь юникод (даже только BMP)

не получиться. и это проблема даже не в наличии памяти,

дело в том, что телефон питается от станционного абонентского

комплекта. следовательно, дополнительные устройства внутри

телефона дополнительно "нагружают" абонентский комплект по питанию. посему подгрузить по D-каналу 8-битную кодировку в такое устройство и далее работать с ним используя 8-битную кодировку будет дешевле.

надеюсь суть идеи понятна.

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

к тому же это как раз тот класс систем, который называют

встроенными системами реального времени, то есть область

применения Ады.

И, кстати, никто не

требовал использовать UNICODE. Речь идет исключительно о действующем стандарте ISO. А он на данный момент остановился на 16-ти битном представлении символов. Я согласен, что UNICODE пошел дальше, но в последней своей инкарнации он "тяжел" и для рабочих станций.

на предмет того, что 16-битных Wide_Character хватит на 99,9999% приложений - тут я полностью согласен.

но вот полновесной поддержки даже этого BMP в Аде сейчас нет -

поддерживается ведь только подмножество Latin-1

Alex

Oleksandr Havva wrote:

 

Полная локализация интересна и применима только для полновесных

интернациональных программных продуктов. Большая же часть ПО писанного

на Ada к таковым не относятся. И "половинность" решения здесь считай

"полное" решение.

 

 

так-то оно так, но может "оно" как раз и не относится

к "полновесным интернациональным программным продуктам"

ввиду того что полновесной поддержки нет?

с этим делом что-то типа замкнутого круга получается,

или мне это только кажется?

 

И да и нет. Поясню. Предположим, хочется нам написать систему управления и контроля Тихоокеанским флотом. Нужна нам интернационализация? Вообще-то нет. Теперь предположим, хочется написать текстовый процессор. Нужна нам интернационализация? Уж точно не помешает.

 

Как видно - все зависит от круга конечных пользователей. Из-за ориентации в первую очередь на приложения первой группы, Ada не требуется поддержки интернационализации. Но это снижает её привлекательность для информационных систем, где некоторые части интернационализации _обязаны_ присутствовать (например, сравнение строк для сортировки, особенности представления десятичных чисел, валют).

 

 

в качестве примера:

ISDN-телефоны (уж звиняйте, но вот с техникой связи мне как раз

в настоящее время и приходится возиться)

одна из возможностей этой игрушки - отображение на ЖК индикаторе

(для справедливости замечу, что ИЖК не все модели имеют)

кроме номера того _кто_ Вам звонит, или с кем Вы в текущий

момент разговариваете, еще и отображение имени/фамилии звонящего.

кроме того, на этом же ИЖК отображается дата/время.

не трудно догадаться, что желательно чтобы все это

было в соответствии с национальными особенностями.

засунуть в это устройство весь юникод (даже только BMP)

не получиться. и это проблема даже не в наличии памяти,

дело в том, что телефон питается от станционного абонентского

комплекта. следовательно, дополнительные устройства внутри

телефона дополнительно "нагружают" абонентский комплект по питанию.

посему подгрузить по D-каналу 8-битную кодировку в такое устройство

и далее работать с ним используя 8-битную кодировку будет дешевле.

 

Согласен. Но просчитать сегодняшние затраты с учетом завтрашнего развития техники и, возможно, пойти по 16-ти битному пути, не помешает. Ведь перешли сотовые телефоны на UCS-2. И даже виртуальную машину Java в них впихнули. И вполне может оказать выгодным сегодня принимать и отображать в ISO/KOI/... а вот внутренние алгоритмы строить на UNICODE. А завтра выкинуть конвертор на входе/выходе и получить "современное" решение. И сбить за UNICODE-зацию очередную порцию финансов.

 

 

на предмет того, что 16-битных Wide_Character хватит на 99,9999%

приложений - тут я полностью согласен.

Я бы убрал одну девятку ;-)

 

но вот полновесной поддержки даже этого BMP в Аде сейчас нет -

поддерживается ведь только подмножество Latin-1

 

Тоже согласен. Но бороться надо. Если кто будет об этом кричать - все задумаются. А будут молчать - скажут, что это никому не требуется. А в обозначенном AI именно к этому все и свелось.

 

Вадим

hi,

Vadim Godunko wrote:

с этим делом что-то типа замкнутого круга получается,

или мне это только кажется?

>

И да и нет. Поясню. Предположим, хочется нам написать систему управления и контроля Тихоокеанским флотом. Нужна нам интернационализация?

...если для 6-го флота США, US Air Force... - точно не надо :)

достаточно ASCII, который уже со времен Ады-83 живет.

...а вот для Тихоокеанского, а потом еще Балтийского...

иметь _стандартные_ механизмы поддержки кириллицы

оч даже надо. иначе, при реализации:

для Тихоокеанского _будут_ написаны _тихоокеанские_

средства поддержки кириллицы (и прочих национальных

особенностей), а для Балтийского - _балтийские_.

ввод/вывод информации ведь на русском придется обеспечивать,

или любой матрос Тихоокеанского флота уже запросто на

английском speak-ает? ;)

Согласен. Но просчитать сегодняшние затраты с учетом завтрашнего развития техники и, возможно, пойти по 16-ти битному пути, не помешает. Ведь перешли сотовые телефоны на UCS-2.

мерзость в том, что сотовый телефон для такого примера

не совсем годиться, потому как батарейка у сотового - своя,

и ежели она каждые два часа у пользователя будет садиться,

то центральной системе это до лампочки.

подобными свойствами ISDN телефонов обладают устройства

консолей охранных систем, консоли управления/диагностики

на автоматизированных производственных линиях и тд и тп

И даже виртуальную машину Java в

них впихнули. И вполне может оказать выгодным сегодня принимать и отображать в ISO/KOI/... а вот внутренние алгоритмы строить на UNICODE.

imho, на N лет вперед достаточно построить внутренние алгоритмы

вокруг BMP (ISO-10646), с соответственной поддержкой

ввода/вывода. этого ведь в нынешнем стандарте Ады

(и не только Ады) нету :(

думаю, понятно _что_ я подразумеваю

А завтра выкинуть конвертор на входе/выходе и получить "современное" решение. И сбить за UNICODE-зацию очередную порцию финансов.

а с кого финансы будем "очередными порциями" сбивать?

я тожа хачу :)

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

>

на предмет того, что 16-битных Wide_Character хватит на 99,9999% приложений - тут я полностью согласен.

Я бы убрал одну девятку ;-)

э-э-э... надо же чего-нить оставить и "на всякий случай" :)))

но вот полновесной поддержки даже этого BMP в Аде сейчас нет -

поддерживается ведь только подмножество Latin-1

>

Тоже согласен. Но бороться надо. Если кто будет об этом кричать - все задумаются. А будут молчать - скажут, что это никому не требуется. А в обозначенном AI именно к этому все и свелось.

ага, вывешиваем баАальшущий лозунг:

"Все на _борьбу_ с локализацией/кириллизацией!!!" :)))

шутю, ес-сно

если серьезно, то - таки _да_, надо искать пути решения

этих проблем, потому как нас это гораздо сильнее касается

чем США/Европу - кириллица у нас

вообще, похоже что мы оба достаточно хорошо себе представляем

как необходимость решения этой проблемы, так и то, насколько

эта проблема не проста.

Alex

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти