проблемы с txt, html и ещё кое что об улучшении и оптимизации

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

Я недавно на библиотеке, но уже заметил глюки.
Возможно это уже где-то здесь обсуждалось, но я не нашел.

Например с двумя книгами
"сестрёнка из приисподни" А Белянина, и
"демоны в Ватикане" А Рудазова.
Когда скачиваешь txt, то он оборванный.
Полный текст только в fb2 или html. Я думаю, что причина в каких-то символах.

В текст конвертируеться не очень корректно переводы строк. Заметил в "невеста из преисподни", там части разбиты символами "* * *", так вот они оказались в конце последнего абзаца, а должны быть на отдельных строках, причём обрамлены несколькими пустыми.

Дальше, те html которые я видел, они не очень-то валидные. Логическая разметка ужасна. Например абзаци помечаны как заголовки.

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

Так же, у меня возникла проблема с оперативным переключением скачиваемого формата.
Я переключаю с txt на html, жму "скачать" и получаю txt.
Возможно старый вариант, с несколькими ссылками здесь был бы удобнее?

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

На странице автора ссылка на книгу, одна без "читать" и "скачать".
Эта ссылка на страницу книги, где анотация, рецензии, ссылки для чтения и скачиванья.
Но на этой странице ещё форма, которая продублирована в профиле пользователя.
А в форме можно выставить, что будет открываться по умолчанию по клику на книгу.

1. страница информации
2. чтение книги
3 скачать

Ну а формат, скачиваемого текста выбираем снизу, как это сейчас и сделано.

Я думаю, это немного облегчит нагрузку на сервер.

Далее, ещё хочу сказать про скачиванье сразу нескольких книг.
Как я понимаю сейчас это делаеться чуть ли не через консоль, какой-нибудь pkzip.
Естественно это кушает ресурсы, память, диск и т.д.

Может быть стоит подумать об склейке архивов налету?

Я имею в виду, то что ведь книги и так уже сжаты, зачем их ещё раз паковать?
Просто берём, делаем заголовок файла, а потом копируем в него выдранные, сжатые файлы, из уже имеющихся архивов.
Это нормально, и проц меньше грузит.

А если делать это на лету, в смысле в потоке, сразу отправляя клиенту, то обращения к диску на 66% будет меньше.

...про pkzip'ы и платформы, форматы архивных файлов, упаковку, нагрузку и прочее.

И, кстати, здесь принят русский язык. Нормальный и, по возможности, грамотный.

jno написал:
И, кстати, здесь принят русский язык. Нормальный и, по возможности, грамотный.

1. Зачем грубить людям?
2. Что вас не устраивает в его языке?

Bullfear написал:
jno написал:
И, кстати, здесь принят русский язык. Нормальный и, по возможности, грамотный.

1. Зачем грубить людям?
2. Что вас не устраивает в его языке?

Не знаю уж, что тут грубость, а неустраивает меня, в частности, слова, вроде "улудшении".

Это не грубость. Это хамство. IMO.

С таким подходом те же дети или люди только изучающие русский или страдающие дислексией и так далее и тому подобное форумами пользоваться не имеют права. Пока не выучат в совершенстве/не подрастут/не излечатся.

Мерзость какая.

Eric-S написал:
В текст конвертируеться не очень корректно переводы строк. Заметил в "невеста из преисподни", там части разбиты символами "* * *", так вот они оказались в конце последнего абзаца, а должны быть на отдельных строках, причём обрамлены несколькими пустыми.
Дальше, те html которые я видел, они не очень-то валидные. Логическая разметка ужасна. Например абзаци помечаны как заголовки.

Все это так. Конвертируется на лету из fb2, так что валидны там только они(да и то не все :)).
По поводу конвертеров... Где-то валялся движок... Я в этом не разбираюсь, но возможно там что-то найдете.

Eric-S написал:

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

Было бы очень хорошо, если бы Вы смогли улучшить конвертер.А сорсы открыты - см. "Движок (для установки на сервер)" вот тут: http://lib.rus.ec/allbooks

pkn постом выше я дал ему ссылку на этот самый движок.

Bullfear написал:
pkn постом выше я дал ему ссылку на этот самый движок.

(посмотрев) А... действительно, я не заметил. Э-э... ну и что? Я что-то нарушил?

Да нет. Просто внимательней надо быть. По крайней мере, если в теме три коротких поста, неплохо бы их прочесть, перед тем как отвечать.

Bullfear написал:
Просто внимательней надо быть.

Знаешь, я тебе могу сказать - просто ссылки надо давать более внятно.

Сам понял какую фигню сморозил? Ссылка выделяется синим цветом. Это намного более компактный и красивый вид ссылки, чем длинный кусок текста.

Bullfear написал:
Сам понял какую фигню сморозил? Ссылка выделяется синим цветом. Это намного более компактный и красивый вид ссылки, чем длинный кусок текста.

1. В моей цветовой схеме ссылка под текстом выделяется не очень ярко.
2. "По поводу конвертеров... Где-то валялся движок... Я в этом не разбираюсь, но возможно там что-то найдете." - это внятно?
3. У тебя сегодня плохое настроение? Так я тогда лучше пойду себе, чтобы ты и мне его не портил.

pkn написал:
В моей цветовой схеме ссылка под текстом выделяется не очень ярко.

Это проблемы твоей цветовой схемы, но никак не невнятности ссылки. Подобная практика ссылок является общепринятой.

Моя просить прощения за некорректный русский натуральный язык.
Моя стараться (пытаться) исправляться.

За ссылки спасибо, скачал, посмотрю.
Если пойму где собака зарыта, попытаюсь её откапать, но ничего не гарантирую.

А про матчасть... Имхо, всё правильно написал. Я в этом разбираюсь, может не очень хорошо, но что куда представляю.

Выводы делал, на счёт pkzip из того, как архив оформлен и сколько времени ушло на подготовку.
Ведь согласитесь, всё это не налету! А приходиться ждать.

Есть одна библиотечка zlib, так она жмёт именно в памяти, диск сдесь не участвует.

А теперь давайте считать.

старый вариант.
1. берём список книг для упаковки.
2. читаем их с диска, сжимаем и опять пишем на диск.
3. пользователю даёться ссылка для скачки, и архив опять читаеться с диска.

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

теперь то что предложил я.
1. список файлов для упаковки.
2. делаем заголовок архива.
3. читаем архив книги с диска, и выдераем сжатый файл.
4. сжатую книгу в ставляем в создаваемый архив.

Теперь замечания.
1. метод работать будет только для обычных архивов из "непрерывных" файл не выдрать.
2. работать с архивами придёться на низком уровне, т.е. заголовок и т.п. анализировать и генерировать самостоятельно.
4. отправка файла, тут может быть ещё одна сложность, php и другие сеансовые, имеют лимит по времени работы, а у некоторых пользователей инет бывает тормознутый и за 30 сек большой архив они не успеют выкачать.

А теперь считаем сколько раз обратились к диску? 1. По сравнению с 3 в старом варианте.

Ну а выводы и возможность реализации в конкретном случае... Это уж точно не про меня.

Наезда же про матчасть, всё ещё не понял. Я своё обосновал, хотелось бы получить ваше обоснование. Возможность моего заблуждения не исключена, но ошибки пока в рассуждениях не вижу.

Кстати, архивы txt, html и pdf генерируються при загрузке книги, делать их на лету это черезчур! Места они занимают не очень много. А генерировать их каждый раз накладно.

Eric-S написал:

Выводы делал, на счёт pkzip из того, как архив оформлен и сколько времени ушло на подготовку.

Я бы на Вашем месте делал выводы *после* анализа сорсов.

На всякий случай - и заранее извиняюсь за дидактику - библиотека написана Лариным (larin). Он здесь админ, бог, царь, и Пророк Его. Мы все тут - точно такие же юзеры, как и Вы, просто уже повозившиеся, в том числе и с сорсами... некоторое время.

Я знаю, что конвертер (из fb2 в другие форматы) глюкав, и если бы Вы его довели до ума - Вас бы тут залюбили до смерти.

А вот насчет зип-операций я не уверен. Ларин последнее время занимается именно снижением нагрузки на сервер. Я, честно говоря, не думаю, что оптимизация зип-операций актуальна. Но - честно - сорсы в этой части я не смотрел, да и даже если бы смотрел - вряд ли понял бы. Я - application programmer... когда мне не хватает ресурсов, я просто звоню начальству и говорю - добавьте процессоров, @#$%^&! ;-)

Цитата:

Я только на днях перебрался на либрусек и ещё тут почти ничего не знаю.
Да, вы правы смотреть нужно в сорцы, но у меня они только что появились.
А косвенные выводы... У меня был анологичный эфект, когда я пользовал консольный pkzip.exe.
При потоковом же скачка начинаеться сразу.

сейчас лезу в сорци, но сначала конвертер. К сожалению у меня времени крайне мало.

Тот архив, что я скачал по первой ссылке это именно движок сайта.
И я не нашел в нём конвертора.
Нашел место, которое предположительно вызывает конвертор и если я всё правильно понял, то делаеться это именно через консоль.
Причём конвертер, (как я опять же подозреваю) написан на perl, которым я почти не владею.

Лучшем вариантом может быть, только написание другого.

Eric-S написал:
Лучшем вариантом может быть, только написание другого.
:)

Насчет архивов: http://lib.rus.ec/node/103819#comment-9854.
Конвертер / fb2 парсер (parser.inc) использует php xml парсер.
Насчет лучшего варианта - не спорю :)

Для конверчения ФБ2 в текст можно, скажем, и вот этой приблудой воспользоваться - всё RAM-based (кроме свопа, понятно) :)

zlib - голый компрессор (gzip, фактически), а здесь архив собирается обычно из нескольких файлов.
при чём zip-формат выглядит предпочтительнее по соображениям переносимости (ага, InfoZip есть даже для VM/CMS).
эффективное сжатие - процедура CPU-intensive и не факт, что более короткий результирующий файл даст выигрыш на передаче на фоне затрат на сжатие.
а ещё для эффективного сжатия нужно много ОЗУ (для примера - можно поиграть в гуях с настройками форточного 7zip при открытом таск-манагере) и растёт риск "пошаркать свапом", что приведёт к росту количества дисковых операций.
и не зная состава оборудования, среды исполнения, ресурсных ограничений, типового профиля нагрузки и "соседних" программ я бы не рискнул делать заключения об эффективности реализации даже после чтения сорцов.

Да, zlib это голый gzip и не только.
Если коротко, то zlib использует тотже самый алгоритм сжатия, что и zip.
Вот только заголовки придёться делать самому, что делать было мне вломно.

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

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

Ссылка на fb2_tag... это не конвертор, а анализатор тегов.

Где-то помниться мне попадался конвертор, толи от Димы Грибова, толи ещё кого-то из той же тусы.

На данный момент лучший конвертор fb2Any
http://www.gribuser.ru/xml/fictionbook/2.0/software/FB2Any.exe
Но там нет html. В html хорошо конвертирует встроенный конвертор FBE:
http://rapidshare.com/files/127249582/FictionBook_Editor_2.0_beta_build_02_Jul.exe
Конверторы Cool Reader-а глючные, теряют структуру текста.
На сайтах Альдебарана и Фикшнбука были свои скрипты-конверторы, но, как понимаю, это "для своих".
UPD
fb2Any тоже не без глюков. Отлично понимая юникодовые символы, он не может расшифровать неразрывный дефис, заменяя квадратиком (нераспознанный символ).
И, если решите собирать свой конвертор, не повторяйте частую ошибку (странно, но сам Грибов ее тоже делал) – не применяйте курсив (italic) к другим стилям кроме emphasis.

sd написал:
не повторяйте частую ошибку [...] – не применяйте курсив (italic) к другим стилям кроме emphasis.
Не уловил - а в чём ошибка-то? Почему нельзя давать курсивом аннотацию, цитату, стихи?

Элементарно, Ватсон! (с) Если автор выделил слово курсивом в стихе, цитате, эпиграфе, то об этом никто не узнает - курсив на курсиве не виден.
"Стоял он, дум великих полн..."
превращается в
"Стоял он, дум великих полн..."

sd написал:
"Стоял он, дум великих полн..."
превращается в
"Стоял он, дум великих полн..."
Хм. А разве в таком случае не принято снимать курсивность? Примерно так:
"Стоял он, дум великих полн..."
UPD: проверил - таки да, ни одна читалка не поддерживает таког фокуса. Жаль. :(

Знаете в чём разница между fb2_any, прочими и теми которые нужны на сайте?
Эти конверторы делаються под разные платформы.
На сайте perl скрипт, что делает его платформанезависимым, а fb2_any под винду. Или есть версии под линух?

Как я уже писал, perl я не знаю, и написать конвертор на нём не способен.

Тут есть два варианта либо php, который говорят медленнее перла на некоторых операциях. Зато я его знаю.

Либо cgi, но тут другой вопрос, а можно ли будет скомпилировать мою прогу на серваке? Зато по скорости она будет гораздо быстрее аналогов на perl или php.

К томуже для написания конвертора нужно время....
Или заняться изучением жемчужины? Что тоже займёт какое-то время.

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

Остаёться качать fb2_any и пользовать его. А с html и txt распрощаться.

Но я немного о другом говорил, что видел конверторы. Хотя это ещё не факт. Они были именно на перле. Но тогда я послал их нафиг, а теперь не помню где они встретились.

Eric-S написал:
Либо cgi, но тут другой вопрос, а можно ли будет скомпилировать мою прогу на серваке? Зато по скорости она будет гораздо быстрее аналогов на perl или php.

CGI = Common Gateway Interface, при чём тут компиляция?
Это - то, через что, грубо говоря, работают c уеб-сервером и перл и пхп...

Угу... А ещё CGI-простейший способ прикрутить к веб-серверу двоичный (скомпилированный) исполняемый модуль.
Поскольку далеко не все хостеры позволяют такую самодеятельность, вопрос герра Эрика не лишен смысла.

Да, не совсем понял изначальную постановку задачи. Хотим-то мы что ? Конвертер fb2->txt ? Если да, изложите, плиз, требования, все равно сейчас примерно этим же занимаюсь. В настоящий момент отягощен следующими довесками - Poco, libxml2 (не я, конвертер отягощен). Язык программирования - С++. ANSI :)))

Ulenspiegel написал:
Хотим-то мы что ? Конвертер fb2->txt ? Если да, изложите, плиз, требования

Легко! Первое - чтобы конвертер не умирал на первом же не-ASCII символе. Второе - чтобы не умирал вообще никогда - то бишь, был способен скушать не просто невалидный по схеме, а откровенно кривой fb2-файл, и не подавиться (то бишь, никаких библиотечных XML парсеров, sorry). Третье - чтобы понимал все кодировки, возможные в fb2 - включая нестандарт (выдавая на выход UTF-8). Четвертое - чтобы если продуцирует html, то закрывал за собой теги, и желательно в нужном месте. Пятое - чтобы его можно было прикрутить к Либрусеку - perl, php, python, C/C++ - whatever, хоть sed, но чтобы можно было к CGI прицепить.

А дальше - ещё придумаем.

pkn написал:
Первое - чтобы конвертер не умирал на первом же не-ASCII символе.

fixed :)
pkn написал:
Второе - чтобы не умирал вообще никогда

Не бывает :)) Валидирующий парсер использоваться не будет, так что несоответствие схеме - прокатит.
Писать парсер совсем уж ручками... Морально не готов, да и файлы с очень грубыми нарушениями структуры (те же незакрытые теги) коректно не обработаешь. IMHO.
pkn написал:
Третье - чтобы понимал все кодировки, возможные в fb2

При условии их прописывания в encoding= и наличия в системе (доступности для iconv) Принято к исполнению.
pkn написал:
выдавая на выход UTF-8

На выход - в лог или в выходной файл ? Читателю не захорошеет Unicode - текст читать ?
pkn написал:
чтобы если продуцирует html, то закрывал за собой теги

Обижаешь, начальник, мокрое дело шьёшь.... :)
pkn написал:
Пятое - чтобы его можно было прикрутить к Либрусеку - <...> чтобы можно было к CGI прицепить.

Принято к исполнению.

Ulenspiegel написал:
pkn написал:
Первое - чтобы конвертер не умирал на первом же не-ASCII символе.

fixed :)

Гм... ну да, про не-ASCII символы это я загнул, извините. Я имел в виду вот это: http://lib.rus.ec/node/109354#comment-15627

Ulenspiegel написал:

pkn написал:
Второе - чтобы не умирал вообще никогда

Не бывает :))

(строгим голосом IBM) "Если возможно написать без ошибки одну строку, то почему нельзя написать без ошибок всю программу?" ;) (впрочем, см. ниже)

Ulenspiegel написал:

Валидирующий парсер использоваться не будет, так что несоответствие схеме - прокатит.
Писать парсер совсем уж ручками... Морально не готов, да и файлы с очень грубыми нарушениями структуры (те же незакрытые теги) коректно не обработаешь. IMHO.

Ну, я не знаю как работает парсер которым Вы пользуетесь. Тот, с которым я пробовал возиться (модуль Perl-а) умирал при малейшем намеке на не то что грубые, а любые нарушения. Причем умирал, гад, молча. Вот этого хотелось бы избежать. Хотелось бы, чтобы если уж произошла ошибка, то на выходе было бы осмысленное сообщение, помогающее ошибку в fb2 найти и исправить.

В конце концов я от использования парсера отказался. Возможно, что и Вы в конце концов откажетесь. Не так уж оно на самом деле сложно - переконвертировать тело fb2 в txt, если не гоняться за красивостями, а делать попроще и покрепче.

Ulenspiegel написал:

pkn написал:
Третье - чтобы понимал все кодировки, возможные в fb2

При условии их прописывания в encoding= и наличия в системе (доступности для iconv) Принято к исполнению.

Ага... так... вот: по состоянию fb2-книг Либрусека на 09 сент 2008, кодировки:

Total : 105061 files for directory E:\libr
windows-1252 : 364 files.
windows-1251 : 82687 files.
ISO-8859-1 : 6 files.
KOI8-R : 1 files.
UTF-8 : 21997 files.
Bad : 25 files.

Причем "плохих" файлов два вида:

1. Структура вообще порушена, encoding не извлекается - но все такие файлы (их всего 6) у автора Синюкова, и они либо уже исправлены, либо скоро будут.

2. Второй вид (19 файлов) интереснее. Encoding указан либо "windows-1252" либо "iso-8859-1" (только эти два), но текст представлен в виде типа:
"&#1057;&#1084;&#1077;&#1088;&#1090;&#1100; &#1084;&#1072;&#1092;&#1080;&#1080;!"
(что читается так: "Смерть мафии!")
Я, на самом деле, даже не знаю что это за кодировка и может она правильная (fb2-читалки её берут). Имею в виду, что конвертеру неплохо бы и такое уметь прожевывать.

Ulenspiegel написал:

pkn написал:
выдавая на выход UTF-8

На выход - в лог или в выходной файл ? Читателю не захорошеет Unicode - текст читать ?

?? Ну мы же читаем? Имеющийся либрусечный конвертер выводит именно UTF-8. В stdout выводит, если я правильно понимаю как оно привинчено.

Ulenspiegel написал:

pkn написал:
чтобы если продуцирует html, то закрывал за собой теги

Обижаешь, начальник, мокрое дело шьёшь.... :)

Ну эта... Имеющийся либрусечный конвертер имеет нехорошую привычку при каких-то неясных условиях не закрывать H3, вот я и упомянул.

pkn написал:
?? Ну мы же читаем? Имеющийся либрусечный конвертер выводит именно UTF-8. В stdout выводит, если я правильно понимаю как оно привинчено.

Оно не привинчено, а выросло изнутри.
В основном из файла parser.inc
Там достаточно плотная интеграция - выковиривается обложка и оглавление для страницы книги, суётся в базу, аннотация, ещё кое-что анализируется. Внешний парсер не так просто прикрутить будет, лучше встроенный починить попробывать. А ещё лучше - переписать его без пхпшной обработки хмля, потому как ошибки она не обрабатывает, а молча падает. Неудобно.

Вот эта хрень, будучи запущена с ключиком -t, выводит текст всех тэгов, которые сыщет в ФБ2-файле. От букв, вроде ещё не мёрла. На питоне, правда, не ANSI C. За то - на чистом питоне, только штатная библиотека поюзана. Специально под ЦГИ не заточена - а надо? Можно и допилить - добавить ключик --CGI и парсить стандартный вход и т.п. Чё все какие-то "решения" ищут?...

pkn написал:
никаких библиотечных XML парсеров

не "библиотечных", а "валидирующих".
тот же expat - невалидирующий библиотечный парсер.
толжен работать.

jno написал:
pkn написал:
никаких библиотечных XML парсеров

не "библиотечных", а "валидирующих".
тот же expat - невалидирующий библиотечный парсер.
толжен работать.

Он никому ничего не должен. Наверное поэтому и не работает.

pkn написал:
Наверное поэтому и не работает.

Странно, а у меня работает...
Что я делаю не так?

ЗЫ Да, скрипт разные кодировки понимает...

jno написал:
pkn написал:
Наверное поэтому и не работает.

Странно, а у меня работает...
Что я делаю не так?

Вы скармливаете ему корректные XML-файлы. Скормите некорректный - и будет Вам Счастье. :P

pkn написал:
Вы скармливаете ему корректные XML-файлы. Скормите некорректный - и будет Вам Счастье. :P

Дык, кормил...
Не знаю, правда, что вообще с ними делать-то?
Сейчас, если ничего не путаю, ругается.
Default encoding is 'cp1251'
Language is ('Russian_Russia', '1251')
< book1.fb2
Error: mismatched tag: line 21, column 4 in book1.fb2
= total 1 files for 0.02" (62.50FPS)
= 0 files rejected; 0 files skipped

Как-то фантазма не хватает - так и так на ручной разбор отправлять надо.
Или нет?

jno написал:
pkn написал:
Вы скармливаете ему корректные XML-файлы. Скормите некорректный - и будет Вам Счастье. :P

Дык, кормил...
Не знаю, правда, что вообще с ними делать-то?
Сейчас, если ничего не путаю, ругается.
Error: mismatched tag: line 21, column 4 in book1.fb2


Гм... тогда не знаю. У меня XML-парсер, реализованный как модуль Перл-а, и, насколько я знаю, являющийся тем же самым expat-ом, на ошибках умирал молча. За что я его и послал.

pkn написал:
Гм... тогда не знаю. У меня XML-парсер, реализованный как модуль Перл-а, и, насколько я знаю, являющийся тем же самым expat-ом, на ошибках умирал молча. За что я его и послал.

expat - вообще-то бинарная библиотека (древняя, как дерьмо мамонта - как бы не первая открытая в этом деле), невалидирующий парсер XML.
Само по себе оно довольно стабильное.
Питоновый вариант - даже работает :)
X