ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Kirill Frolov                        2:5030/827.2   26 Mar 2004  09:20:08
 To : Victor Wagner
 Subject : Re: book reader
 -------------------------------------------------------------------------------- 
 

 
 On Tue, 23 Mar 04 09:55:52 +0300, Victor Wagner wrote:
 
  KF>>   Чего?  Вначале В ЮHИКОДЕ заменяешь неугодные символы на правильные,
  VW> Чего-чего. Во первых, на входе у нас не юникод, а какая-то гадость вроде
  VW> rtf, парсер который добывает символы по одной штуке, причём эти символы
  VW> могут бы как юникодными, так и в более другой кодировке. Те из них,
  VW> которые не юникодные мы должны преобразовать в юникод. Вот тебе первый
  VW> вызов iconv на символ. 
 
   А собрать их по строкам?  Зачем на символ? Тут то iconv спотыкаться не должен?
 
  VW> Потом мы должны определить, угодный символ или неугодный. 
  VW> Есть два класса неугодных символов. Первый - это честные ASCII символы,
  VW> недопустимые в выходном формате, например \ в TeX или  <> в HTML.
  VW> Второй класс неугодных символов - символы, непредставимые в выходной
  VW> кодировке. Единственный способ их отличить - посмотреть в табличку
  VW> выходной кодировки. Если у нас нет таблички, отличной от iconv-овской,
  VW> значит надо попытаться эти символы преобразовать, и если не получилось,
  VW> то тогда они неугодные.
 
   Так табличку можно изначально построить. Взять все символы выходной
 кодировки, их 256 штук, и перевести iconv'ом в unicode. Будет тебе
 список допустимых символов выходной кодировки, представленных в unicode.
 Если текст содержит символы не входящие в данный набор -- они подлежат
 замене. В unicode-же и заменяется. Потом перекодируется без единой
 запинки.
 
  KF>> потом iconv() его в выходную кодировку. Таблички нужны... но не
  KF>> перекодировки, а только определяющие допустимые символы. И их можно
  KF>> автоматически построить из iconv() при старте программы.
  VW> Ты знаешь, распарсить 256 строк текстового файла может оказаться проще,
  VW> чем проверять все 65536 кодов Unicode при построении таблички средствами
 
    2^32 для glibc (sizeof(wchar_t)==sizeof(uint32_t)).
 
  VW> iconv. Потому как строка файла описания кодировки с ftp.unicode.org
  VW> занимает меньше 256 символов.
 
   Так я ж выше пишу, допустимость определяется не исходя из всех
 возможных символов unicode, а исходя из символов выходной кодировки.
 
  VW> Тем более что всё равно надо парсить сходные по структуре таблицы замен
  VW> неугодных символов.
 
   Ассоциативных массивов в C нет. Это беда... :-(
 
  VW> выходном формате по ограничениям формата, а не кодировки. И алгоритм
  VW> сильно теряет в эффективности если во входном формате символы подлежащие
  VW> преобразованию в основном представелены в виде esc-последовательностей, как
  VW> в rtf.
 
   То ли я что-то не понимаю, то ли ты как-то в неправильную сторону мыслишь.
 
  KF>>   В info написано, что в iconv не таблицы, а вроде как функция на каждый
  KF>> символ. Hо я не вникал особо. А почему-бы этих функций не расширить до
  KF>> того, чтобы оно умело заменять символы отсутствующие в выходной
  KF>> кодировке?
  VW> А потому что существует стандарт  POSIX. Все, проехали. Где ты был,
  VW> когда принимали POSIX-ные стандарты на функции i18n. Там ведь такого
  VW> наворотили. 
 
   Hу можно немножко наплевать на POSIX. Обратная совместимость-то
 останется.
 
 --- [ZX]
  * Origin: 0D00 1E54 41D1 9753 3F41 40F7 4BBA 050B 30E8 0E4E (2:5030/827.2)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор