ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Victor Wagner                        2:5020/400     27 Mar 2004  11:51:18
 To : Kirill Frolov
 Subject : Re: book reader
 -------------------------------------------------------------------------------- 
 

 Kirill Frolov <Kirill.Frolov@p2.f827.n5030.z2.fidonet.org> wrote:
 
  KF>>>   Чего?  Вначале В ЮHИКОДЕ заменяешь неугодные символы на правильные,
  VW>> Чего-чего. Во первых, на входе у нас не юникод, а какая-то гадость вроде
  VW>> rtf, парсер который добывает символы по одной штуке, причём эти символы
  VW>> могут бы как юникодными, так и в более другой кодировке. Те из них,
  VW>> которые не юникодные мы должны преобразовать в юникод. Вот тебе первый
  VW>> вызов iconv на символ. 
 
  KF>   А собрать их по строкам?  Зачем на символ? Тут то iconv спотыкаться не
  KF> должен?
 
 А как я их соберу по строкам, если нету в форматах текстовых процессоров
 понятия строки. Есть понятие абзаца, ячейки таблицы и прочих логических
 кусков текста. А кто сказал что разделитель этих кусков всегда можно
 проверить ДО перекодирвоки в UNICODE?
 
  VW>> Потом мы должны определить, угодный символ или неугодный. 
  VW>> Есть два класса неугодных символов. Первый - это честные ASCII символы,
  VW>> недопустимые в выходном формате, например \ в TeX или  <> в HTML.
  VW>> Второй класс неугодных символов - символы, непредставимые в выходной
  VW>> кодировке. Единственный способ их отличить - посмотреть в табличку
  VW>> выходной кодировки. Если у нас нет таблички, отличной от iconv-овской,
  VW>> значит надо попытаться эти символы преобразовать, и если не получилось,
  VW>> то тогда они неугодные.
 
  VW>> Ты знаешь, распарсить 256 строк текстового файла может оказаться проще,
  VW>> чем проверять все 65536 кодов Unicode при построении таблички средствами
 
  KF>   Так я ж выше пишу, допустимость определяется не исходя из всех
  KF> возможных символов unicode, а исходя из символов выходной кодировки.
 
 Особенно, если выходная кодировка utf-8.
 
  VW>> Тем более что всё равно надо парсить сходные по структуре таблицы замен
  VW>> неугодных символов.
 
  KF>   Ассоциативных массивов в C нет. Это беда... :-(
 
 Hу так ассоциативный/не ассоциативный, а какую-то структуру данных нужно
 реализовывать. В catdoc используется двухуровневое 256-ричное дерево.
 
 А раз она реализована, iconv превращается всего лишь в yet another
 источник информации о таблицах кодировок. Причём не самый удобный и не
 самый переносимый. 
 -- 
 Снился мне Фрейд. Что бы это значило?
        --- С.Е. Лец
 --- ifmail v.2.15dev5.3
  * Origin: Free Net of Leninsky,45 (2:5020/400)
 
 

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