В PHPExcel даже простой var_dump превышает max_execution_time. Хотя файл небольшой, около 3000 строк.
spreadsheet-reader вроде бы читает, даже порядок количества строк совпадает, но при этом print_r как в примере на гитхабе, выводит какую-то ерунду. Такое ощущение, что он читает XLSX файл не распаковывая. Также, в выводимом мусоре мелькает что-то про CSV, как будто он пытается открыть файл как CSV.
Вариант с CSV неудобен, поэтому хотелось бы узнать про другие варианты.
Оказывается, spreadsheet-reader определяет тип по расширению. А я пытался ему скормить временный файл без move_uploaded_file() и он действительно пытался распознать его как CSV. После указания расширения файл успешно распознается в UTF-8. https://github.com/nuovo/spreadsheet-reader
PHPExcel крайней прожорлив.
Запускать большие файлы только в CLI режиме без лимита execution time.
И еще слишком большие выжрут всю оперативку, так что все равно размер будет ограничен максимально возможный пределами свободной рамы.
Александр Аксентьев: Формат простой, таблица, фиксированное количество строк. Никаких объединенных ячеек и формул. Но PHPExcel не справился с тестовым файлом в 3000 строк и 800 кБ и это только вывод через var_dump из примера.
Александр Аксентьев: Maximum execution time of 30 seconds exceeded. Увеличивать максимальное время, когда другой скрипт считывает тот же файл за пару секунд. кажется неправильным решением.
Если Excel 2007+ версии, то для начала можете разархивировать этот файл (excel файл это обычный zip архив). Далее, вы найдете там множество xml файлов, которые содержат как настройки так и ваши данные. Вот этот xml файл и можете парсить по-частям. Все это делается средствами PHP
100 лет назад была проблема с xml, не то чтобы очень большие файлы или ресурсоемкая задача для современных ЭВМ. Железо было слабеньким :)
Стояла задача импорта информации в каталог. Мы сделали следующим образом:
В БД в таблицу с колонками "путь к файлу", "позиция"делали запись. изначально позиция 0;
Потом читаем файл с позиции указанной в этой таблице и читаем порциями по N байт. Проверяем наличие открывающего тега "" и закрывающего через ф-ции работы с подстроками. как только нашли X закрытых тегов (к примеру 30 элементов) и столько же открытых - обрезаем лишнее и получаем разметку для X продуктов. Помещаем это в тело валидного XML документа, делаем DOMDocument, парсим и подготавливаем массив данных.
Потом в транзакции сохраняем обработанное количество строк и проставляем позицию с какой остановились. И тут коммит. Это все дело должно быть в цикле. Если проблемы с max_execution_time и нет возможности его убрать - то тогда такую процедуру можно и на аякс повесить! Ведь она сохраняет текущий прогресс операции.
Для XML конечно же есть свои ф-кции которые позволяют работать с огромными файлами, но мы их трогать не стали.