[image]

Может файл книги в FB2 быть меньше ТХТ?

 

ttt

аксакал


Взялся наводить порядок в библиотеке - много пар - одна книга в разных форматах

FB2 для чтения несомненно лучше ТХТ, но обычно больше. Но иногда наоборот.

Не решаюсь стирать - может пропущена часть текста?

Пример - "Дурман" Гамильтона. ТХТ 663 Кб, FB2 с картинкой 445 Кб

Не очень понимаю - может одна и та же книга в формате FB2 быть меньше ТХТ?

За счет чего? В FB2 ведь нет никакого сжатия, зато есть картинки и форматирование?
   50.050.0
+
+1
-
edit
 

Balancer

администратор
★★★★★
ttt> За счет чего? В FB2 ведь нет никакого сжатия, зато есть картинки и форматирование?

Если оба файла в одной кодировке и без сжатия (т.е. .fb2, а не .fb2.zip), то fb2 всегда будет больше.

Возможна ситуация, когда .txt в кодировке utf-8 (два байта на русскую букву), а .fb2 — в windows-1251 (1 байт на символ). Тогда txt будет больше :)
   44
BY V.Stepan #30.11.2016 10:41  @Balancer#30.11.2016 10:13
+
-
edit
 

V.Stepan

аксакал
★★☆
Balancer> Возможна ситуация, когда .txt в кодировке utf-8

А бывает такое? И если бывает, то нафуа?

Balancer> а .fb2 — в windows-1251

Для точности добавь "или в аналогичной" :)
   
RU Серокой #30.11.2016 12:16  @ttt#29.11.2016 01:03
+
+1
-
edit
 

Серокой

координатор
★★★★
ttt> За счет чего? В FB2 ведь нет никакого сжатия, зато есть картинки и форматирование?

Переносы строк могут быть убраны из TXT. Там ещё пробелы любят вставлять лишние и тире из двух дефисов.
   
RU Balancer #30.11.2016 12:56  @V.Stepan#30.11.2016 10:41
+
-
edit
 

Balancer

администратор
★★★★★
Balancer>> Возможна ситуация, когда .txt в кодировке utf-8
V.Stepan> А бывает такое?

Например, у меня все .txt именно такие :)

V.Stepan> И если бывает, то нафуа?

А зачем иначе? utf-8 сегодня стандарт де факто для любого обмена информацией.

Balancer>> а .fb2 — в windows-1251
V.Stepan> Для точности добавь "или в аналогичной" :)

Полагаю, что fb2 в cp866 или koi8-r нет в природе. Когда этот формат появился, эти кодировки уже ушли с рынка.
   44
RU Balancer #30.11.2016 12:57  @Серокой#30.11.2016 12:16
+
-
edit
 

Balancer

администратор
★★★★★
Серокой> Переносы строк могут быть убраны из TXT. Там ещё пробелы любят вставлять лишние и тире из двух дефисов.

Это копейки. Единицы процента. Более того, переводы строк не компенсируются в fb2. На каждый символ перевод строки будет, как минимум, 7 символов параграфа и его закрытия.
   44
BY V.Stepan #30.11.2016 13:00  @Balancer#30.11.2016 12:56
+
-
edit
 

V.Stepan

аксакал
★★☆
Balancer> Например, у меня все .txt именно такие :)

А смысл?

Balancer> А зачем иначе? utf-8 сегодня стандарт де факто для любого обмена информацией.

Да ну его в пень! Медленнее обрабатывается, и если не нужна многоязыковость, то я не понимаю, нафига он вообще нужен.
   
+
-
edit
 

Sandro
AXT

инженер вольнодумец
★☆
Balancer>> А зачем иначе? utf-8 сегодня стандарт де факто для любого обмена информацией.
V.Stepan> Да ну его в пень! Медленнее обрабатывается, и если не нужна многоязыковость, то я не понимаю, нафига он вообще нужен.

Справочно сообщаю: utf-8 без многоязыковости — это ASCII7 :D
Сделано умышленно из соображений совместимости. И с чего ты взял, что он медленно обрабатывается?
   50.050.0
+
-
edit
 

V.Stepan

аксакал
★★☆
Sandro> И с чего ты взял, что он медленно обрабатывается?

Специально у себя в проекте тестили с какой скоростью обрабатываются строки в UTF-8, а с какой в KOI8-R. Разница оказалась заметной.
   
RU Серокой #30.11.2016 14:00  @Balancer#30.11.2016 12:57
+
-
edit
 

Серокой

координатор
★★★★
Balancer> Более того, переводы строк не компенсируются в fb2.
Имеется в виду, что перенос в fb2 - в конце абзаца. А в TXT обычно - в конце каждой строки.
   
+
-
edit
 

Sandro
AXT

инженер вольнодумец
★☆
Sandro>> И с чего ты взял, что он медленно обрабатывается?
V.Stepan> Специально у себя в проекте тестили с какой скоростью обрабатываются строки в UTF-8, а с какой в KOI8-R. Разница оказалась заметной.

И вот тут я хочу подробностей. Что у вас там было такое, что работало медленнее диска? По моему опыту, скорость обработки текста практически всегда и везде упираются в ввод/вывод, если это не так, то вас там какой-то жуткий вычислительный монстр.
Или речь именно про диск?
   50.050.0
+
-
edit
 

V.Stepan

аксакал
★★☆
Sandro> И вот тут я хочу подробностей.

А какие подробности? Запись в БД, извлечение из БД, поиск по БД, обработка строк в памяти — на всех этапах UTF-8 оказывался медленнее по сравнению с KOI8-R. Поэтому мы на него плюнули и оставили всё, как есть.
   

ttt

аксакал


Balancer> Возможна ситуация, когда .txt в кодировке utf-8 (два байта на русскую букву), а .fb2 — в windows-1251 (1 байт на символ). Тогда txt будет больше :)

Роман, ты гений!

Посмотрел онлайн декодером - тхт определился как UTF-8, а в начале FB2 (открыл блокнотом) стоит

encoding="windows-1251"

Спасибо, могу теперь со спокойной душой одни FB2 оставить :)
   50.050.0
RU Balancer #30.11.2016 19:58  @V.Stepan#30.11.2016 13:00
+
-
edit
 

Balancer

администратор
★★★★★
Balancer>> Например, у меня все .txt именно такие :)
V.Stepan> А смысл?

Потому что стандарт. Потому что однобайтовые кодировки крайне ограничены.

V.Stepan> Да ну его в пень!

Это реальность.

V.Stepan> Медленнее обрабатывается

Сегодня это не актуально.

V.Stepan> и если не нужна многоязыковость, то я не понимаю, нафига он вообще нужен.

Спецсимволы. От табличной графики до формул и эмотиконов. Да и мультиязычность в любой момент может всплывать.

...

Вообще, удивительный спор. Такие шли 12-15 лет назад. И лет 10 назад практически прекратились :) Ты бы ещё поспорил о том, что 32 битные процессоры не нужны, так как 16 битные справляются :)
   44
RU Balancer #30.11.2016 19:59  @Серокой#30.11.2016 14:00
+
-
edit
 

Balancer

администратор
★★★★★
Серокой> Имеется в виду, что перенос в fb2 - в конце абзаца. А в TXT обычно - в конце каждой строки.

Один фиг, разница будет в проценты.
   44
RU Balancer #30.11.2016 20:00  @V.Stepan#30.11.2016 15:05
+
-
edit
 

Balancer

администратор
★★★★★
V.Stepan> на всех этапах UTF-8 оказывался медленнее по сравнению с KOI8-R. Поэтому мы на него плюнули и оставили всё, как есть.

Так у вас ещё и КОИ-8? :eek: Там же даже литературных символов нет, типа тире и кавычек-«ёлочек» :D
   44
BY V.Stepan #30.11.2016 20:12  @Balancer#30.11.2016 19:58
+
+4
-
edit
 

V.Stepan

аксакал
★★☆
Balancer> Потому что стандарт.

И что? Сейчас мода стандарт, к примеру, везде XML, тыкать для обмена информацией. Надо 5 чисел передать в структурированном формате — всё равно XML лепят. И удивляются, когда спрашиваешь про альтернативу: "А что, разве можно как-то по другому?"

Balancer> Потому что однобайтовые кодировки крайне ограничены.

Если не хватает, то тогда, конечно, два. Но везде лепить два — это перебор.

Balancer> Вообще, удивительный спор.

Balancer> Ты бы ещё поспорил о том, что 32 битные процессоры не нужны, так как 16 битные справляются :)

Ну, во-первых, там, где 16 за глаза, действительно 32 ставить смысла нет. Ты же не будешь меня убеждать, что микроконтроллер клавиатуры обязан быть 32-хразрядным? Во-вторых, программные решения и аппаратные это несколько разные вещи — если выпускать 16-битные процы при малом их потреблении накладно, то поддержка 8-битных кодовых таблиц ничего не стоит — она уже давным-давно написана и переписана n-цать раз.
   
RU Balancer #30.11.2016 21:04  @V.Stepan#30.11.2016 20:12
+
+1
-
edit
 

Balancer

администратор
★★★★★
Balancer>> Потому что стандарт.
V.Stepan> И что?

То.

V.Stepan> Сейчас мода стандарт, к примеру, везде XML

Опять ты в 10-летней давности живёшь.

XML остался практически только в legacy, а для хранения/обмена данными сейчас используют JSON :)

Только это не имеет отношения к делу, т.к. это вопрос передачи данных, а не кодировки хранения.

V.Stepan> Надо 5 чисел передать в структурированном формате — всё равно XML лепят.

Уже давно — нет :)

Balancer>> Потому что однобайтовые кодировки крайне ограничены.
V.Stepan> Если не хватает, то тогда, конечно, два. Но везде лепить два — это перебор.

Вот, в итоге тебе придётся изобретать, развивать и поддерживать несколько разных способов обработки данных. Вместо одной кодировки с единым форматом хранения и обоработки, будет зоопарк. При чём, например, зарубежные разработчики будут снова тупо забивать на всех остальных и снова в зарубежных инструментах будут вопросики и кракозябры вместо русских букв. Оно сегодня надо? :)

V.Stepan> Ну, во-первых, там, где 16 за глаза, действительно 32 ставить смысла нет.

И нужно поддерживать две платформы? :D

V.Stepan> Ты же не будешь меня убеждать, что микроконтроллер клавиатуры обязан быть 32-хразрядным?

У меня отсылка вполне однозначная по контексту к периоду перехода с AT на 386 :)

V.Stepan> поддержка 8-битных кодовых таблиц ничего не стоит — она уже давным-давно написана и переписана n-цать раз.

И поэтому, пока не прижился UTF-8, нам постоянно приходилось сталкиваться с проблемами кодировок. Спасибо, я этим наелся досыта :D
   44
BY V.Stepan #30.11.2016 21:12  @Balancer#30.11.2016 21:04
+
+2
-
edit
 

V.Stepan

аксакал
★★☆
Balancer> XML остался практически только в legacy, а для хранения/обмена данными сейчас используют JSON :)

У нас везде требуют для обмена XML. Задолбали!!!!!

Balancer> Только это не имеет отношения к делу, т.к. это вопрос передачи данных, а не кодировки хранения.

А это как пример ненормального программного решения. Использование пушки там, где хватает воздушки.

Balancer> И поэтому, пока не прижился UTF-8, нам постоянно приходилось сталкиваться с проблемами кодировок.

И какие-такие проблемы? Я только одну помню — когда почтовики перекодировали n-цать раз приаттаченный текстовый файл.

Balancer> У меня отсылка вполне однозначная по контексту к периоду перехода с AT на 386 :)

Я уже про некорректность этого сравнения написал.
   
RU Balancer #30.11.2016 21:20  @V.Stepan#30.11.2016 21:12
+
-
edit
 

Balancer

администратор
★★★★★
V.Stepan> У нас везде требуют для обмена XML. Задолбали!!!!!

Видимо, legacy :) Или кто-то у вас остался на уровне обмена данных в прошлом веке :)

V.Stepan> А это как пример ненормального программного решения. Использование пушки там, где хватает воздушки.

Нет, пример некорректный. Из пушки не постреляешь в тире, а UTF-8 обеспечивает функциональность однобайтовых кодировок всюду.

V.Stepan> И какие-такие проблемы?

:facepalm:

Наша РАКЕТОМОДЕЛЬНАЯ страничка [algor17#10.02.02 20:24]

… Нет ничего более постоянного, чем временное. Если делать, то СРАЗУ и КАК НАДО. Потому как потом руки вряд ли у кого-то дойдут. Вся практика Авиабазы (и не только) говорит об этом. … 10Мб на книжку - слишком дорогой траффик получится … Есть такой специальный графический формат для книг, рукописей и т.п. Жмёт очень сильно и с высоким качеством - фактически вырезается текст с фона и запоминается в таком виде. (тьфу, varban, твой хранцузский привёл к кракозябрам - хорошо ещё, что текст в буфер…// Ракетомодельный
 


для Balancer [Balancer#03.04.03 07:16]

… Гм. Ну, поскольку я русский Апач не ставил, то можно и явно будет теперь прописать. Только нафига? Автоопределение кодировок всё равно в Рунете кривое, у меня треть сайтов в кракозябрах выходит, например, Yandex.ru - на вьетнамском всегда Поэтому кодировка всегда строго Windows-1251 в браузерах выставлена.// Авиационный
 


Книги по .NET [Voennich#25.04.03 01:25]

ВАУ ! ! ! вопрос в подпапке (не знаю что за подпапка у меня отображается кракозябрами) лежит Wrox Professional C# - она на английском или как ?? и еще - как долго к этой радости доступ будет открыт ?// Компьютерный
 


Какой выбрать сотовый? [Balancer#16.08.03 17:42]

Вот, прикол. Если с Нокии шлю заметку на КПК - русский отлично доходит. Хотя, например, поле "дополнительно" не передаётся. А вот с КПК на Нокию - кракозябры... Гм.// Компьютерный
 


Погода... [BrAB#05.02.04 14:24]

Balancer, 05.02.2004 14:11:34: Фиг знает, как я понимаю, с weather.com инфу тянет. Для Москвы - весьма похоже с тем, что я за окном вижу вот и сейчас на градуснике ~-2°, а в трее -3°   а вот вопрос - а она русские символы отображает нормально? а то у меня кракозябры наблюдаются, хотя шрифты кирилические поставил// Компьютерный
 


Помогите справиться! Крякозябры на кнопках [Zeus#05.04.04 04:43]

КАК?? (Тест: загрузить в GSPlayer мелодию с русским названием в ID3. Должен показывать нормально, не кракозябрами - как в главном окне, так и в плейлисте. Но при этом штатная дата на столе должна быть по-английски, и в штатной телефонной книжке алфавит должен быть английский).// Компьютерный
 


dat файлы [Eronak#18.12.05 16:55]

… поставил и у меня не скилы а кракозябры,как я понимаю это кодировка,где это можно исправить?// Инструментарий
 


Ладно проехали :)
   44
LT Bredonosec #01.12.2016 00:35  @Balancer#30.11.2016 21:04
+
-
edit
 
Balancer> Опять ты в 10-летней давности живёшь.
Balancer> Вот, в итоге тебе придётся изобретать, .. зарубежные разработчики будут снова тупо забивать на всех остальных
Balancer> И поэтому, пока не прижился UTF-8, нам постоянно приходилось сталкиваться с проблемами кодировок.

У вас просто разные workaround-ы. У тебя нужна совместимость с всякими забугорниками, какое-то кроссплатформенное решение для того, чтоб быстро струячить аппликации или что там. Вычислительными мощностями при этом не ограничен, бо клиенты платежеспособны, бла-бла-бла.
У Вадима, как понимаю, есть какое-то старое оборудование, которое прекрасно работает для решения каких-то сугубо внутренних задач. И менять его в угоду моде "вы чё, как не стыдно на таком старье работать?!?" - нет смысла от слова совсем.
Соответственно и диалог "сытый голодного не понимает" :)
   26.026.0
BY V.Stepan #01.12.2016 07:48  @Bredonosec#01.12.2016 00:35
+
-
edit
 

V.Stepan

аксакал
★★☆
Bredonosec> У Вадима, как понимаю, есть какое-то старое оборудование

1) У Виталия
2) Оборудование тут совсем не при чём. Разговор о программных решениях.
   
RU Balancer #01.12.2016 10:02  @Bredonosec#01.12.2016 00:35
+
-
edit
 

Balancer

администратор
★★★★★
Bredonosec> У Вадима, как понимаю, есть какое-то старое оборудование

Так про всякое legacy никто не спорит. У меня до сих пор есть фрагменты с KOI8-R, только потому что туда страшно влезать и переделывать :D

Но он-то полез делать глобальные выводы о текущем состоянии дел в целом. И вот тут он не прав, поскольку utf-8 стал массовым стандартом и решил большое число давних проблем.
   44
BY V.Stepan #01.12.2016 13:50  @Balancer#01.12.2016 10:02
+
+2
-
edit
 

V.Stepan

аксакал
★★☆
Balancer> Но он-то полез делать глобальные выводы о текущем состоянии дел в целом.

Угу, полез. Я уже как-то из-за одного клиента Питона пощупал — до сих пор нервно вздрагиваю, вспоминая. А шуму-то было: "если вы не юзаете Python, вы отсталое дерьмо собачье!".

Balancer> решил большое число давних проблем.

Добавив новых. А если старое решение (мы в нашем облачном решении до сих пор KOI8-R юзаем и не видим смысла на UTF-8 переходить) не давало и не даёт головной боли, то зачем его менять на новое, лишь по той простой причине, что "это модный стандарт"?
   
RU Balancer #01.12.2016 19:09  @V.Stepan#01.12.2016 13:50
+
-
edit
 

Balancer

администратор
★★★★★
V.Stepan> А шуму-то было: "если вы не юзаете Python, вы отсталое дерьмо собачье!".

Это тебе на каких-то неадекватов везло, значит. Питон никогда не занимал сколь-нибудь заметной доли рынка, чтобы делать такие необоснованные заявления.

А вот utf-8, в отличие от Питона, сегодня реально практически повсеместен.

V.Stepan> Добавив новых.

Какие-то проблемы были лет 10-15 назад, но это было очень давно :)

V.Stepan> А если старое решение ...

Про Legacy я писал выше. Только уже работающее старое решение не даёт тебе права наезжать на новые.

V.Stepan> лишь по той простой причине, что "это модный стандарт"?

utf-8 победил не потому что он «модный стандарт». А потому что это единственный компромиссный стандарт в этой области.

В общем, повторюсь, ты сильно припозднился. Спорить надо было где-то в эти времена :)

Будущее за UTF-8?

Как думаете, какие перспективы у UTF-8? В последнее время он всё чаще и чаще вылезает... // Компьютерный
 
   44

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru