|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Smirnov 2:5020/400 15 Feb 2002 03:10:36
To : Victor Wagner
Subject : Re: генерация NLS
--------------------------------------------------------------------------------
ru>
From: Denis Smirnov <mithraen@freesource.info>
Victor Wagner <vitus@45.free.net> wrote:
DS>> Я несколько не понимаю -- получается что 3-я таблица
DS>> действует уже после перекодировки, а значит должна
DS>> задаваться в формате результирующей кодировки? У тебя это
VW> Hет. Третья таблица вступает в действие тогда, когда перекодировка
VW> данного символа _не удалась_. И на входе имеет то же самое,
VW> что имела вторая таблица.
Я имею в виду не это. Эта таблица соответствия юникодных символов
последовательностям символов. Если я правильно тебя понял, то у тебя
эта самая результирующая последовательность идёт в исходящий поток
напрямую.
DS>> проходит нормально, но если добавить в качестве
DS>> результирующей таблицы, скажем, EBCDIC, то всё должно
DS>> сломаться, я правильно понимаю?
VW> Абсолютно неправильно. У меня все будет ломаться только при
VW> указании в качестве результирующей кодировки какой-нибудь big-5
VW> или EUC-JP, в силу особенностей реализации 2-й таблицы, которая
VW> устроена по принципу "символ в байт".
Пошёл ещё раз более внимательно читать твои исходники
VW>>> А в качестве второй (и нулевой - преобразования из
VW>>> исходной кодировки в Unicode) используем файлик с
VW>>> ftp.unicode.org _как_есть_ считывая его в некую структуру
VW>>> данных runtime.
DS>> Это я понял. Хотя я предпочёл компилировать их изначально в
DS>> массивы, и прилинковывать.
VW> Чтобы бедному юзеру, которому понадобилась вдруг какая-то cp1125,
VW> о которой ты в момент написания и не подозревал, пришлось бы
VW> программу перекомпилировать. А также чтобы при загрузке программы
VW> в память попадали все известные ей таблицы, когда нужны-то всего две.
Просто у меня была изначально чуть другая цель -- не программа, а
библиотека. Таблицы эти всё равно занимают считаные килобайты (я не
надеюсь пытаться запустить это под чем-то 16-и битным. А если
пользователю нужна какая-то извращённая таблица, то ему проще
пересобрать. Я осознаю, что это не unix-way, но мне кажется, что в таком
случае скорость критичнее.
--
С уважением, Denis
http://freesource.info
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
