dtcDev 10 мар 2012 в 20:26

Работа с большими файлами экселя

5 мин

55K

.NET *

+20

Комментарии 43

ComodoHacker 10 мар 2012 в 20:31

> какой то из них отвалился по причине опостылевшей уже на тот момент OutOfMemory

Конечно же DOM.

Anderwonder 11 мар 2012 в 09:54

«О, сколько нам открытий чудных готовит..» фирма Microsoft!

dtcDev 11 мар 2012 в 10:02

Я по работе сталкивался с IDE Mono Develop, Zend, Flash Develop, Eclipse, и еще парочкой. При всей «открыто-чудности» мелкомягких, Visual Studio — это лучшая IDE, и за это им большое спасибо. Их можно за многое любить и ненавидеть, и вообще тема для очередного холивара, который начинать как то не хочется, но некоторые их решения достойны уважения, как ни крути.

Anderwonder 11 мар 2012 в 10:20

Ну зачем расточаться «большим спасибо», они же не шкуродеры. Достаточно 450$).
Всё-всё — no hollywar.

ComodoHacker 11 мар 2012 в 11:39

В данном случае Microsoft не при чем.

Eternalko 11 мар 2012 в 23:53

О сколько тайн прекрасных, Вам предстоит еще познать.
Фирма Майкрософт тут ни при чем.

Ну какой интеллектуал запихивает такие данные в эксель?

ComodoHacker 10 мар 2012 в 20:33

> работать с файлами на 600-800 тыс строк кода

Ошибки тут нет? VBA-код что ли?

s0L 10 мар 2012 в 20:40

Рошаль тут непричем, -x документы мсофиса это ZIP архивы

dtcDev 10 мар 2012 в 20:49

Сорри, конечно Вы правы. Поправлю

noonesshadow 10 мар 2012 в 23:26

Стандарт, если шо, тут…
msdn.microsoft.com/en-us/library/dd922181(v=office.12).aspx

radislav 10 мар 2012 в 23:44

Я тут вообще мимо проходил, но можно из листингов убрать пустые строки?

Meroving 11 мар 2012 в 08:08

Эхх, это ж Source Code Highlighter. Он когда-то работал хорошо, но после очередного обновления Хабра стала выдаваться такая фигня, а поправить некому.

faiwer 11 мар 2012 в 08:27

Тест.
<source lang="c#">

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.IO;
using System.Linq;

<code>

using System;

using System.Collections.Generic;

using System.Data;

using System.Data.OleDb;

using System.IO;

using System.Linq;

Просто для проверки. В предпросмотре всё Ok. Никаких лишних строк, не знаю как получится в итоге :)

dtcDev 11 мар 2012 в 09:08

Сам не в восторге, знать бы еще как…

faiwer 11 мар 2012 в 17:00

попробуйте <source lang="c#">. Или вы его и используете?

DeeKey 11 мар 2012 в 00:37

Где-то полгода назад искал решения для экспорта-импорта файлов Excel на сервере.
Наткнулся на EPPlus и просто пищал от радости: не требует установки Офиса, простой API, не попалось ни единого бага (ну, на наших задачах — несколько worksheet'ов, несложное форматирование).

Проект пятилетний, много серверных модулей и клиентских приложений. К тому времени мы реально использовали в разных местах Interop, OLEDB, CSV и генерацию на основе XML-templates. У всех решений свои проблемы. Мы смотрели в сторону VSTO или Add-in Express'а, но EP+ очень удачно попался под руку.

Производительность EP+ заявляют сравнимую с тем что у вас получается — «Can now load 50 000 cells in seconds».

Да, конкретно у OLEDB — помимо естественных ограничений представления данных как реляционных и установки офисных DLL-ек (чего нам хотелось избежать на сервере), была еще заморочка с автоматическим распознованием типа данных по первым N (default 8) строкам. Если в первых строках в колонке шли цифры, то появление потом цифро-буквенного значения передавалось как DBNull и надо бвло лезть в реестр чтобы это исправить.

zzeneg 11 мар 2012 в 03:14

Я для работы с xlsx-файлами пользовался этим кодом. Правда с такими большими файлами не работал, не знаю насчет производительности.

gibson_dev 11 мар 2012 в 07:03

Юзаю библитеку libxl — офиса не надо, написана на си, работает под все чем можно (iOS даж есть) — весьма шустрая ошибок не встречал.
Вообщем рекомендую к использованию.

FractalizeR 11 мар 2012 в 08:02

А как у нее насчет сотен тысяч строк?

gibson_dev 11 мар 2012 в 08:58

Если дадите пример — проверю, сколько времени уйдет на чтение

dtcDev 11 мар 2012 в 09:07

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

gibson_dev 11 мар 2012 в 09:12

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

Valery35 11 мар 2012 в 08:50

А если в access перенести? Для него такие объемы не проблема.

dtcDev 11 мар 2012 в 09:02

А если File->SaveAs->CSV, то жизнь вообще прекрасна: StreamReader stmReader=File.OpenText(.....);
Такая бредовая идея во время мытарств кстати проскакивала :)))) Но негоже было заставлять залезать и пересохранять документы.

Проблема всех проектов (а на самом деле норма), что нам приходится работать с тем, что дают, и никуда от этого не денешься.

Valery35 11 мар 2012 в 09:06

Посмотрите возможности импорта в access. Там такие полезные вещи есть как вынос ошибок вставки в отдельную таблицу, настройки шаблона при импорте.
И кодировать не надо (для меня это плюс) :)

dtcDev 11 мар 2012 в 09:12

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

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

meta4 11 мар 2012 в 08:55

Не подумайте что лезу не в свое дело, просто действительно интересно откуда могут взяться такие большие Exel файлы и почему именно в этом формате, раз они явно не для чтения/редактирования человеком?

Valery35 11 мар 2012 в 09:00

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

dtcDev 11 мар 2012 в 09:03

Отчеты по продажам одной компании. Отчет за месяц весит примерно 250 метров (по одной стране)

dtcDev 11 мар 2012 в 09:06

Итаки да, дополню. Такие файлы — настолько удивительная редкость, что большинство попросту не столкнется с такими объемами. Но данная задача позволила нам узнать новое: не только то, что такие файлы существуют в природе, но и то, как написать более быстрый и менее ресурсоемкий загрузчик из экселя. Пока что на других своих проектах я не хочу возращаться к Interop

Valery35 11 мар 2012 в 09:09

Это обычный вопрос при переносе данных между системами.
Не бакап же отдавать :)

Dyr 11 мар 2012 в 12:07

Вот если честно, то за такое канделябром по морде, ИМХО, надо, поскольку ничего Excel-специфичного там не используется, а значит, вполне можно было бы обойтись обычным и кросс-платформенным CSV.

HomoLuden 24 июл 2012 в 09:50

Бывают логи в XML и по несколько гигов.

ruikarikun 11 мар 2012 в 10:20

Я обычно в таких случаях сохранял как CSV, а дальше — по старинке.

dtcDev 11 мар 2012 в 10:26

про CSV отписался выше — стояла задача «одну кнопочку, чтобы было красиво»

f0b0s 11 мар 2012 в 10:23

Когда мне нужно было такое, я просто распарсил SpreadsheetML. Стандарт — открытый. Опыт у меня уже был (так парсил и ворд и ООо документ). Писать — пара тыщ строк кода, пара дней.

dtcDev 11 мар 2012 в 10:27

Это был последний вариант, если бы выложенный не сработал

to_climb 11 мар 2012 в 10:50

Provider=Microsoft.ACE.OLEDB.12.0 — ещё хорошо бы упомянуть, откуда есть берётся этот провайдер БД (стандарный, с офисом ставится, отдельный).

to_climb 11 мар 2012 в 10:47

4Гб оперативки и OutOfMemory никак не связаны — заканчивается 2Гб виртуального адресного пространства процесса.
Функция NewProcent очень порадовала =)

А Interop — штука для неторопливых, но иногда это единственный вариант. Делал через неё раскраску файлов (regexp'ами) — за несколько часов 40k строк отчёта переварила.

m_a_d 15 мар 2012 в 15:04

Когда дело доходит до форматирования — большинство сторонних открытых решений действительно не подходят. Мы в нашем софте в итоге, устав от ~~тормозов и глюков~~ особенностей Interop, обзавелись вот этой штукой. В работе с ней тоже есть нюансы, но в целом всё сильно упростилось.

orionll 11 мар 2012 в 13:18

А пробовали Open XML SDK?

alon 11 мар 2012 в 17:10

В сторону NPOI не смотрели? Установки не требует, пара длл-ок и все. По скорости все устраивает (60к строк в xls пишет моментально), хотя настолько большие файлы как у автора обрабатывать не приходилось.

Sharomank 11 мар 2012 в 20:11

>>text +=
конкатенация строк в цикле зло!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий