Работаем с CSV правильно

ох если бы)) еще и С и D - новой машине в момент импорта дается в 14 раз больше памяти и в 9 раз больше юнитов в облаке, иначе ниасиливает)

Коллеги подскажите, а есть ли какой-то изящный выход, когда клиент подсовывает файлы cp1251 на импорт на сайт в utf-8
Понятно, что битрикс отправляет клиента перекодировать файл вручную. Есть функции перекодирования строк, но не валиться ли импорт при этом на ощутимом кол-ве данных? Кто-то решал эту дилемму ?

А как парсер поведёт себя, когда встретит недопустимые символы? Если файл в кодировке cp1251, а сайт в UTF8, то при парсинге могут появится невалидные юникод-последовательности. Поэтому нужно сначала конвертировать строковые данные, а потом уже парсить.
С другой стороны, читать построчно тоже нельзя, потому что перевод строки может встретиться в экранированном виде (в кавычках), и функция построчного чтения неправильно прочтёт такую строку.
Получается, прежде чем парсить, нужно конвертировать кодировку, а чтобы считать одну строку, нужно распарсить. Выходит, чтобы считать одну строку, нужно сначала перекодировать весь файл, а уж потом его парсить.

Интересно, каким образом?

Спасибо, Антон!

Буквально сейчас понадобилось читать CSV, а тут ваш утренний пост.

Хороший и полезный пост, спасибо

Отличное решение!

Сделано как тут, из 40мб файла читаеть только 7мб и падает

полезный пост, круто!

Иван Плаксин, ну естественно, чего выделеyно под php, тем и пользуйтесь, вероятнее всего падает по переполнению памяти

Евгений Микулич, по итогу битриксовые средства были посланы и использована сторонняя библиотека SpreadsheetReader

Интересно, а зачем было создано подобное решение ? На мой взгляд оно повторяет работу штатных SPL средств.

Нативно более быстрый вариант на числом php (работает на чтение с php 5.2, на запись с php 5.4):

Тут я ошибся. На момент написания того коммента я не знал следующего: все символы, которые обычно используются в качестве разделителей в CSV: запятая, точка с запятой, двойные кавычки, горизонтальная табуляция — кодируются в UTF-8 точно так же, как и в CP1251, поскольку принадлежат ASCII, а вся ASCII в обеих этих кодировках кодируется одинаково.

Если бы парсер пытался каким-то образом интерпретировать другие символы в потоке ввода, помимо символов разделителей, которые ему нужно распарсить, то ошибка была бы следующая. Допустим, у Вас в файле всего два байта: ГL -- кириллическая Г, потом латинская L. Последовательность 1100 0011 (Г), 0100 1100 (L) является недопустимой в UTF-8, т. к. после 11xx xxxx должна всегда следовать 10xx xxxx.

Но, как я предполагаю (не проверял), битриксовый парсер CSV не интерпретирует никакие байты входящего потока, кроме тех, которые ему нужны для разделения строк и ячеек. Поэтому конкретно для сайта на UTF-8 и файла в CP1251 ошибки быть не должно, по идее.

Но такой алгоритм, несомненно, содержит в себе принципиальную, идеологическую ошибку, т. к. не для любых двух кодировок это верно. В частности, если бы сайт был на другой Unicode-кодировке, напр., UTF-16, (не поддерживается в Битрикс) то упомянутая мной проблема непременно могла бы иметь место при определённой последовательности входных символов CP1251 — поскольку в символы-разделители CSV в CP1251 представлены однобайтовыми последовательностями, а в UTF-16 — двухбайтовыми.

TLDR, это, по идее, рабочий лайфхак, который подходит не для любых кодировок.

лишняя ; перед закрывающей скобкой =)

Николаев Андрей, функции были еще в php5
http://php.net/manual/ru/function.fputcsv.php
которые по любому быстрее чем классы.

Semenov Roman, да никто же не спорит Тут вопрос скорее не "почему не использовали именно эту фичу", а "зачем понадобилось писать прослойку, да еще и не очень удобную"

Спасибо вам большое!

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

А как же частями считывать файл? Например по 100 строк за раз? и на следующем шаге уже со смещением считывать следующие?