Большое спасибо за объяснение!
Честно говоря, когда я разбирался с данной библиотекой, я так глубоко не копал, и вопрос кодировок не изучал — стояла задача как можно скорее сделать что-то, что будет работать.
Ваш комментарий позволил ответить на вопрос "почему так, а не иначе".
Вообще, благодаря таким комментариям, начинаешь ценить хабр еще больше)
Как раз про опыт ее использования планирую рассказать в следующей статье. Действительно, хорошая, еще и кросплатформенная, библиотека, но со своими приколами)
Очень интересная информация на счет предела в количестве ошибок — я, честно говоря, даже не знал, что такие есть. И то, что такое количество пользователей у Excel я как-то тоже не задумывался)
На счет дополнительно установленных пакетов — их нет. Использую только OpenXML и все.
Мне вот тоже сейчас стало интересно, а какой максимальный размер файла удастся обработать, но у меня сейчас под рукой только ноут с 16 Гб оперативы.
Кстати, на счет обработки огромных файлов xlsx со сложным содержимым, возможно, имеет смысл как раз использовать Interop, так как файл в таком случае будет открываться и обрабатываться непосредственно в среде Excel, что, теоретически, поможет избежать каких-нибудь не очевидных ошибок.
Функционал обработки файла по частям не реализован. Честно говоря, я, на данный момент, очень слабо себе представляю, как можно разбить xlsx на части. Если с отдельной обработкой листов еще можно что-то придумать, то с разбивкой листов по строкам — все нет так однозначно. Тем более, если задача стоит разбить документ без предварительной его загрузки в оперативную память.
Изобретения нет, но, тот, кому понадобится сделать нечто подобное, не будет убиваться гуглингом, а сможет открыть данную статью и сделать вывод относительно перспектив найти бесплатное решение указанной задачи и, в случае крайней необходимости, воспользоваться этим решением.
Или, по Вашему мнению, туториалы по использованию библиотек вообще не нужны потому, что кто-то берет "готовые бесплатные библиотеки" и использует?
К тому же, библиотека RtfPipe не отличается особой популярностью, а теперь кто-то узнает, что она есть — разве это плохо?
А откуда у Вас информация, что "такой ужас" делают в Позитивных технологиях?
Я в Позитивных технологиях не работаю, Вы, по всей видимости, тоже (иначе вопрос не был бы задан), но упрекаете действительно крутую компанию в строительстве "квадратноколесных велосипедов"? Как-то это не хорошо — единственным криворуким разрабом являюсь я, и мне крайне не хотелось бы, что бы мои личные косяки и "неоптимальные" решения ассоциировались с какой-либо компанией.
Более того, приведенный в данной статье, равно как и в другой моей статье, код в том виде, в котором его видят читатели, в компании, сотрудником которой я являюсь, не используется. Иначе, это было бы, как минимум, не этично по отношению к работодателю предоставлять в открытый доступ результат, полученный в течении рабочего дня.
А теперь, по существу. Я думаю, никто не будет оспаривать тот факт, что существуют разные it-компании, в которых также реализуются разные проекты как по задачам, которые они призваны решать, так и по подходу к разработке. Где-то, менеджеры жестко придерживаются скрама, почти каждая строчка кода проходит код-ревью, активно пишется документация, а архитектура будущего решения планируется несколько месяцев. Но есть и другие компании, которые решают не такие глобальные задачи, которые не стыдятся "говнокодинга", забивают на документацию и архитектуру, но "выкатывают" свои продукты в очень короткие сроки. Можно долго спорить и осуждать второй тип компаний, но раз они до сих пор на плаву и приносят прибыль, то такая бизнес-модель, как минимум, имеет право на существование.
А теперь, представьте, что Вы работает в такой компании (ни в коем случае не буду говорить, что компания, в которой я работаю, относится ко второму типу). И Вам поставили задачу достать текст из текстовых файлов и структурировать его определенным образом. При этом, вы знаете примерное содержание документов, которые вы будете обрабатывать, потому что все эти документы однотипные (документы, например, скачиваются с сайтов гос органов). Задача должна быть решена в максимально короткие сроки (в таких компаниях всегда так), а закупка специализированного софта, как минимум, здорово сдвинет дату релиза: я пока не встречал ни одной компании, где хотелка работника, требующая проведения процедуры закупки, удовлетворялась хотя бы в течении рабочей недели. А так как речь идет о покупке продуктов Aspose, цены на которые начинаются от 2999$ встает вопрос о целесообразности приобретения такого продукта для решения далеко не самой трудной (естественно в глазах менеджмента) задачи.
В результате, разработчик должен будет подготовить обоснование необходимости приобретения такой библиотеки, пободаться с менеджерами, утвердить решение, только после чего запуститься бюрократическая машина, чтобы произвести покупку данного софта. В результате, с момента "мне надо" до момента "я начинаю использовать библиотеку", может пройти реально ощутимый промежуток времени.
В чем ценность моего решения? В том, что получать xml из rtf вы можете уже сегодня. В результате, вы можете:
продолжать прототипировать продукт, не упираясь в необходимость поиска конвертера
использовать это решение для каких-то внутренних задач, которые не предъявляют высоких требований к надежности и точности (хотя на данный момент, нареканий на работу данного решения еще не было).
Вместе с тем, не могу не отметить тот факт, что в каждой из своих статей я обращаю внимание на то, что:
Найденное решение является бесплатным (непонятно, зачем после этого говорить, что платное решение лучше и упрекать в отказе от его использования — очевидно же, что, если можно было бы использовать годную платную либу — ее использовали бы).
Решение является плодом "костылезации" и представляет собой велосипед.
PS В любом случае, я благодарен за критику, но вот чему бы я был по настоящему рад, так это критике, после которой последует дельное предложение, которое удовлетворяло бы условиям поставленной задачи.
Спасибо, если это не сарказм) Посмотрел темы Ваших статей — видно, что вы уже давно и плотно в it! Мне вот эта статья понравилась — даже повторить захотелось)
Если по теме вопроса, то на самом деле размер файла Excel с большой долей вероятности может быть ограничен спецификацией. Так, для 32-битных систем он не может быть больше 500-700Мб, а для online-версии предельный размер файла и вовсе составляет 250Мб. То что касается 64 разрядных систем, фактически ограничения накладываются только железом. Со спецификацией можно ознакомиться здесь
Отсюда можно сделать следующие выводы:
Вероятность того, что кто-то создаст файла такого огромного размера крайне мала.
Есть очень высокая вероятность упереться в технические ограничения (банальная нехватка памяти). Поясню. Вся информация в документе xlsx хранится в zip-архиве, что означает, что закрытый файл размером 5-7 Гб занимает ощутимо меньше памяти на дисковом пространстве, нежели этот же файл, но загруженный и открытый в программе, особенно, если осуществляется какая-то обработка хранимой в нем информации. Думаю, тот кто в студенчестве писал какой-нибудь архиватор типа Хафмана, сейчас прекрасно может представить примерную разницу между двумя этими состояниями файлов.
В общем, я хочу сказать, что, если речь идет о таких огромных файлах, то для работы с ними необходимо иметь как минимум соответствующее железо, а программа, которая будет использовать предложенное решение должна быть скомпилирована под 64-х разрядную систему и тогда, скорее всего, файл будет обработан и сконвертирован.
Однако, не стоит упускать из виду высокую вероятность неожиданного поведения GB при работе с такими объемами файлов, а также непредсказуемого поведения операционной системы, которая может принудительно кильнуть разожравшийся процесс.
Вот принимая во внимание все перечисленное, можно сказать, что ограничений на объемы обработки документов нет, и, при наличии соответствующего железа, файл объемом 5-7 Гб (а это около 16-20 Гб оперативы на хосте) должен будет быть обработан.
Но, скажу честно, такие кейсы я сам не тестил.
Шикарная и простая библиотека!
Но, к сожалению, у нее ограничения(
Соберусь с силами и выложу пост про конвертацию xls и doc — вот там вообще жара, конечно!
И, самое паршивое, ну очень сложно было найти решение под .Net, зато под линухом на питончике делается одной командной строкой в терминале)
Почему? Аналогичное решение, в настоящий момент, используется на внутреннем продукте компании (как раз парсер) и пока, тьфу-тьфу-тьфу, все работает.
Если подскажете, с каким парсером можно поиграться и проверить работоспособность приведенного решения, то буду искренне очень признателен.
Спасибо! Это решение тоже было рассмотрено, но было найден бесплатный вариант для всех перечисленных форматов. В течении сегодняшнего дня планирую выложить пост о конвертации rtf в xml. Потом расскажу про doc и xls, а дальше про odt и ods (но с ними все довольно тривиально).
Сейчас перепроверил — все успешно собирается. Прилагаю скрин:
На счет предложенных Вами вариантов сборки xml я ничего возразить не могу. Они вполне могли бы использоваться. Просто в данном случае, мне показалось ограничиться StringBuilder'ом логичным решением в силу его компактности и полного удовлетворения имеющихся потребностей в рамках решения конкретной задачи. Конечно, если бы использовались более разнообразные теги с большим количеством атрибутов, логичным было бы подключение дополнительных библиотек.
Да, все верно, именно через StringBuilder собирается xml. Если нам необходимо вставить угольные скобки, то вставляем их как любой другой символ, если нам нужно вставить кавычки, то просто экранируем их.
Однако, как таковой проблемы нет, так как мы заведомо знаем где и какие теги будут вставлены (мы же их сами в коде и расставляем).
Если есть сомнения, можете попробовать скачать код с репозитория и попробовать потестить у себя. Если вдруг заметите неадекватное поведение программы, буду рад комментариям.
Данный выбор обусловлен «традициями компании» — у других сотрудников был опыт работ OpenXML и, когда я разрабатывал данное решение, то знал, что в случае возникновения вопросов могу обратиться к старшим товарищам. Да и в целом, мне показалось логичным использовать нативное решение от Microsoft.
Спасибо! Я, честно говоря, о таком подходе даже не задумывался.
Большое спасибо за объяснение!
Честно говоря, когда я разбирался с данной библиотекой, я так глубоко не копал, и вопрос кодировок не изучал — стояла задача как можно скорее сделать что-то, что будет работать.
Ваш комментарий позволил ответить на вопрос "почему так, а не иначе".
Вообще, благодаря таким комментариям, начинаешь ценить хабр еще больше)
Как раз про опыт ее использования планирую рассказать в следующей статье. Действительно, хорошая, еще и кросплатформенная, библиотека, но со своими приколами)
Очень интересная информация на счет предела в количестве ошибок — я, честно говоря, даже не знал, что такие есть. И то, что такое количество пользователей у Excel я как-то тоже не задумывался)
На счет дополнительно установленных пакетов — их нет. Использую только OpenXML и все.
Мне вот тоже сейчас стало интересно, а какой максимальный размер файла удастся обработать, но у меня сейчас под рукой только ноут с 16 Гб оперативы.
Кстати, на счет обработки огромных файлов xlsx со сложным содержимым, возможно, имеет смысл как раз использовать Interop, так как файл в таком случае будет открываться и обрабатываться непосредственно в среде Excel, что, теоретически, поможет избежать каких-нибудь не очевидных ошибок.
Функционал обработки файла по частям не реализован. Честно говоря, я, на данный момент, очень слабо себе представляю, как можно разбить xlsx на части. Если с отдельной обработкой листов еще можно что-то придумать, то с разбивкой листов по строкам — все нет так однозначно. Тем более, если задача стоит разбить документ без предварительной его загрузки в оперативную память.
Изобретения нет, но, тот, кому понадобится сделать нечто подобное, не будет убиваться гуглингом, а сможет открыть данную статью и сделать вывод относительно перспектив найти бесплатное решение указанной задачи и, в случае крайней необходимости, воспользоваться этим решением.
Или, по Вашему мнению, туториалы по использованию библиотек вообще не нужны потому, что кто-то берет "готовые бесплатные библиотеки" и использует?
К тому же, библиотека RtfPipe не отличается особой популярностью, а теперь кто-то узнает, что она есть — разве это плохо?
А откуда у Вас информация, что "такой ужас" делают в Позитивных технологиях?
Я в Позитивных технологиях не работаю, Вы, по всей видимости, тоже (иначе вопрос не был бы задан), но упрекаете действительно крутую компанию в строительстве "квадратноколесных велосипедов"? Как-то это не хорошо — единственным криворуким разрабом являюсь я, и мне крайне не хотелось бы, что бы мои личные косяки и "неоптимальные" решения ассоциировались с какой-либо компанией.
Более того, приведенный в данной статье, равно как и в другой моей статье, код в том виде, в котором его видят читатели, в компании, сотрудником которой я являюсь, не используется. Иначе, это было бы, как минимум, не этично по отношению к работодателю предоставлять в открытый доступ результат, полученный в течении рабочего дня.
А теперь, по существу. Я думаю, никто не будет оспаривать тот факт, что существуют разные it-компании, в которых также реализуются разные проекты как по задачам, которые они призваны решать, так и по подходу к разработке. Где-то, менеджеры жестко придерживаются скрама, почти каждая строчка кода проходит код-ревью, активно пишется документация, а архитектура будущего решения планируется несколько месяцев. Но есть и другие компании, которые решают не такие глобальные задачи, которые не стыдятся "говнокодинга", забивают на документацию и архитектуру, но "выкатывают" свои продукты в очень короткие сроки. Можно долго спорить и осуждать второй тип компаний, но раз они до сих пор на плаву и приносят прибыль, то такая бизнес-модель, как минимум, имеет право на существование.
А теперь, представьте, что Вы работает в такой компании (ни в коем случае не буду говорить, что компания, в которой я работаю, относится ко второму типу). И Вам поставили задачу достать текст из текстовых файлов и структурировать его определенным образом. При этом, вы знаете примерное содержание документов, которые вы будете обрабатывать, потому что все эти документы однотипные (документы, например, скачиваются с сайтов гос органов). Задача должна быть решена в максимально короткие сроки (в таких компаниях всегда так), а закупка специализированного софта, как минимум, здорово сдвинет дату релиза: я пока не встречал ни одной компании, где хотелка работника, требующая проведения процедуры закупки, удовлетворялась хотя бы в течении рабочей недели. А так как речь идет о покупке продуктов Aspose, цены на которые начинаются от 2999$ встает вопрос о целесообразности приобретения такого продукта для решения далеко не самой трудной (естественно в глазах менеджмента) задачи.
В результате, разработчик должен будет подготовить обоснование необходимости приобретения такой библиотеки, пободаться с менеджерами, утвердить решение, только после чего запуститься бюрократическая машина, чтобы произвести покупку данного софта. В результате, с момента "мне надо" до момента "я начинаю использовать библиотеку", может пройти реально ощутимый промежуток времени.
В чем ценность моего решения? В том, что получать xml из rtf вы можете уже сегодня. В результате, вы можете:
Вместе с тем, не могу не отметить тот факт, что в каждой из своих статей я обращаю внимание на то, что:
PS В любом случае, я благодарен за критику, но вот чему бы я был по настоящему рад, так это критике, после которой последует дельное предложение, которое удовлетворяло бы условиям поставленной задачи.
Спасибо, если это не сарказм) Посмотрел темы Ваших статей — видно, что вы уже давно и плотно в it! Мне вот эта статья понравилась — даже повторить захотелось)
Если по теме вопроса, то на самом деле размер файла Excel с большой долей вероятности может быть ограничен спецификацией. Так, для 32-битных систем он не может быть больше 500-700Мб, а для online-версии предельный размер файла и вовсе составляет 250Мб. То что касается 64 разрядных систем, фактически ограничения накладываются только железом. Со спецификацией можно ознакомиться здесь
Отсюда можно сделать следующие выводы:
В общем, я хочу сказать, что, если речь идет о таких огромных файлах, то для работы с ними необходимо иметь как минимум соответствующее железо, а программа, которая будет использовать предложенное решение должна быть скомпилирована под 64-х разрядную систему и тогда, скорее всего, файл будет обработан и сконвертирован.
Однако, не стоит упускать из виду высокую вероятность неожиданного поведения GB при работе с такими объемами файлов, а также непредсказуемого поведения операционной системы, которая может принудительно кильнуть разожравшийся процесс.
Вот принимая во внимание все перечисленное, можно сказать, что ограничений на объемы обработки документов нет, и, при наличии соответствующего железа, файл объемом 5-7 Гб (а это около 16-20 Гб оперативы на хосте) должен будет быть обработан.
Но, скажу честно, такие кейсы я сам не тестил.
Шикарная и простая библиотека!
Но, к сожалению, у нее ограничения(
Соберусь с силами и выложу пост про конвертацию xls и doc — вот там вообще жара, конечно!
И, самое паршивое, ну очень сложно было найти решение под .Net, зато под линухом на питончике делается одной командной строкой в терминале)
Почему? Аналогичное решение, в настоящий момент, используется на внутреннем продукте компании (как раз парсер) и пока, тьфу-тьфу-тьфу, все работает.
Если подскажете, с каким парсером можно поиграться и проверить работоспособность приведенного решения, то буду искренне очень признателен.
Спасибо! Это решение тоже было рассмотрено, но было найден бесплатный вариант для всех перечисленных форматов. В течении сегодняшнего дня планирую выложить пост о конвертации rtf в xml. Потом расскажу про doc и xls, а дальше про odt и ods (но с ними все довольно тривиально).
Сейчас перепроверил — все успешно собирается. Прилагаю скрин:
На счет предложенных Вами вариантов сборки xml я ничего возразить не могу. Они вполне могли бы использоваться. Просто в данном случае, мне показалось ограничиться StringBuilder'ом логичным решением в силу его компактности и полного удовлетворения имеющихся потребностей в рамках решения конкретной задачи. Конечно, если бы использовались более разнообразные теги с большим количеством атрибутов, логичным было бы подключение дополнительных библиотек.
Однако, как таковой проблемы нет, так как мы заведомо знаем где и какие теги будут вставлены (мы же их сами в коде и расставляем).
Если есть сомнения, можете попробовать скачать код с репозитория и попробовать потестить у себя. Если вдруг заметите неадекватное поведение программы, буду рад комментариям.