On Fri, 31 May 2002, Ilya Anfimov wrote:
Сорри за тормоза с ответом..
> On Fri, May 31, 2002 at 04:55:27PM +0500, Vlad Harchev wrote:
> > On Fri, 31 May 2002, Ilya Anfimov wrote:
> > Ну во-первых это не винда - API расширять произвольно не принято.
>
> А молча впихивать новые свойства в стандартные видимо уже вошло в привычку.
А разве в стандарте написано, имена каких registry должны пониматься
iconv'ом?
>
> >
> > А что должен выдавать этот API (что на входе, что на выходе) - какие
> > соображения?
>
>
> Как один из вариантов:
> На входе -- исходное registry (строка, из списка вроде IANA,
> system/locale, system/iconv, Adobe, X, только чуть более
> официальные названия. попавшие в этот список регистрируются у
> разработчиков библиотеки), и точное название charset из этого
> registry, выходное registry. Всего, вероятно, можно придумать
> несколько десятков таких имён.
>
>
> На выходе -- название charset в выходном registry, процент
> соответствия, комментарии.
>
> Как ещё один из вариантов -- библиотека перекодировки, на выходе
> кроме названия, опционально -- указатели на структуры
> перекодировки. Тогда логично будет добавить ещё API, с получением
> структуры работы с символами исходного charset как таковыми.
> Впрочем, второе уже не факт, что будет минимальным для создания
> полного API перекодировок и работы с разнонациональными
> символами. Возможно, что это надо выносить в отдельные
> библиотеки. Собственно, одна из таких библиотек уже есть.
>
> Кроме того, в такой API нужно будет изначально включить функции
> для его расширения подключёнными библиотеками или самой
> программой. Через callbacks, я думаю.
имхо все это слишком общо и в реальной жизни не пригодится практически
никому. Уж если расширять API - то лучше сделать портабельную библиотеку (не
то чтобы linux-specific, а даже не unix-specific) с единственной ф-ией -
iconv_ex_open(char* in,char* out)
которая полазает по своим таблицам схожести и таблицам псевдонимов и вернет
iconv_t от системного iconv. Хотя еще можно впихнуть функциональность для
перечисления всех канонических имен чарсетов (чтобы перечислять их в менюшке
Вид-Кодировка). Ну и можно еще впихнуть информацию о том, какой чарсет
используют для данного языка на данной платформе для текста и для названий
файлов (типа для ru и текста: win => cp251, linux=>koi8-r, dos=> cp866) - это
нужно в редакторах например (сохранить как текст DOS) и при импорте/экспорте
из форматов, в которых текст хранится не в unicode и не в utf. Такие таблицы
(для какого языка в какой системе какая кодировка для текста) мне пришлось
ручками вставлять в код gnumeric'а и abiword'а когда я добавлял к ним i18n
support.
По-любому, этому не место в glibc, а в какой-то универсальной библиотеке.
Best regards,
-Vlad
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
