Как один скрытый символ в прайсе поставщика ломает импорт в PrestaShop

Я занимаюсь интеграцией каталогов для интернет-магазинов уже больше семи лет. За это время я научился искренне ненавидеть формат CSV. Казалось бы, обычный текстовый файл, где данные разделены запятыми. Что тут можно испортить? Но когда вам на почту падает очередной «грязный» прайс-лист от поставщика автозапчастей или сантехники на 50 000 позиций, а на выходе нужен чистый импорт товаров prestashop csv, начинается настоящая игра на выживание. Вы сталкиваетесь не просто с таблицей. Вы сталкиваетесь с хаосом, который кто-то выгрузил из старой самописной ERP-системы.

Я помню тот четверг. Мы запускали крупный магазин климатической техники. Клиент торопился, сезон горел, контекстная реклама была уже оплачена и ждала старта. Поставщик прислал «свежайшую» выгрузку. Я на автомате прогнал её через стандартный скрипт, запустил встроенный импортер PrestaShop и пошел пить кофе. Вернулся через двадцать минут. Сайт лежал. База данных MySQL была намертво забита мусором, а сервер выдавал ошибку 502. Процессор хостинга был загружен на все 100%.

Причина оказалась банальной до боли. В описании одного из кондиционеров за 42 180 рублей менеджер поставщика использовал дюймовые кавычки прямо внутри текстового поля. Без экранирования. Парсер споткнулся на этой строке, посчитал кавычку концом поля и сдвинул все последующие колонки вправо. Цены импортировались как артикулы. Описания превратились в HTML-теги. Половина каталога просто исчезла, заменившись кашей. Мы восстанавливали базу из бэкапа до пяти утра, вручную вычищая хвосты. С тех пор я не верю ни одному файлу от дистрибьюторов.

Почему стандартный импорт в PrestaShop всегда спотыкается

CSV — это не стандарт. Это иллюзия стандарта. У каждого разработчика на стороне поставщика свое видение того, как выгружать базу данных. В итоге мы получаем гремучую смесь из кривых разделителей, нечитаемых кодировок и битых строк. Встроенный импортер PrestaShop довольно чувствителен. Он ожидает идеальную структуру, а получает хаос.

Первая проблема — разделители полей. В рунете исторически прижилась точка с запятой (;). Всё из-за Excel, который по умолчанию сохраняет таблицы именно так. Но точка с запятой постоянно встречается в описаниях товаров и технических характеристиках. Например: «Мощность: 150W; Напряжение: 220V». Если ваш конвертер прайса в csv настроен на точку с запятой как разделитель колонок, движок PrestaShop решит, что «Напряжение» — это уже значение следующего столбца. В итоге цена уползет в категорию, а категория — в изображение. Покупатели увидят кондиционер по цене доставки. Это реальный риск потерять деньги за пару минут, пока вы не заметите ошибку.

Вторая беда — экранирование кавычек. По правилам хорошего тона, если внутри текста есть кавычки, всё поле должно быть обернуто в двойные кавычки, а внутренние — удвоены. Но в реальности менеджеры пишут описания руками. Они ставят кавычки-ёлочки, кавычки-лапки, дюймы и вообще всё, что найдут на клавиатуре. Для импортера PrestaShop любая неэкранированная кавычка — это сигнал закрытия поля. Всё, что идет дальше, ломает структуру строки. Строка разрывается, данные смешиваются, и на выходе мы получаем технический сбой.

Третья проблема — кодировка. PrestaShop жестко требует UTF-8 без BOM. Поставщики из начала двухтысячных упорно продолжают присылать файлы в старой кодировке Windows-1251. Если попытаться загрузить такой файл без предварительной конвертации, вы получите каталог, заполненный нечитаемыми символами. Автоматизация загрузки товаров просто невозможна без жесткого предварительного перекодирования файлов на лету.

Как навести порядок в хаосе данных

Я выработал для себя железное правило: никогда не доверять входящим данным. Нельзя просто взять прайс поставщика и скормить его CMS. Нужен промежуточный фильтр, который проверит каждую строчку на прочность. Мы должны сами пересобрать этот файл перед отправкой в систему.

Мы написали десятки регулярных выражений для валидации входящих файлов. Первое, что делает наш алгоритм — проверяет количество разделителей в каждой строке. Если в заголовке таблицы у нас 18 колонок, а в строке под номером 1450 их внезапно оказалось 19 — эта строка мгновенно отправляется в карантин для ручного разбора. Никакого автоматического импорта сломанных строк. Это спасает базу от замусоривания и экономит часы работы.

Второй шаг — нормализация артикулов (SKU). Поставщики обожают креативить. Один пишет артикул как «AB-123», второй — «AB 123», а третий — «АВ123», где буквы «А» и «В» написаны кириллицей. Для базы данных это три абсолютно разных товара. В итоге обновление каталога prestashop превращается в создание бесконечных дубликатов. Мы принудительно очищаем артикулы от лишних пробелов, приводим их к верхнему регистру и заменяем похожие русские буквы латинскими. Только так можно гарантировать, что остатки и цены обновятся у нужной позиции, а не создадут клон карточки товара.

Цены тоже требуют чистки. Забудьте про форматы вида «1 500,00 руб.». PrestaShop понимает только чистые числа с точкой в качестве разделителя копеек. Никаких пробелов-разделителей тысяч, никаких знаков валют внутри ячейки. Все эти «руб.», «usd» и «грн» должны безжалостно вырезаться еще до начала импорта. Иначе вы получите нулевые цены на сайте.

Перестаньте делать это вручную

Конечно, можно каждый раз открывать Excel, запускать поиск и замену, вручную вырезать кривые кавычки и пересохранять кодировку. Но когда у вас десять поставщиков, а цены меняются ежедневно, рутина быстро выжмет из вас все соки. Ошибки неизбежны. Один пропущенный символ — и вы снова восстанавливаете сайт из резервной копии в пять утра. Это не бизнес, это тушение пожаров.

Если вы хотите раз и навсегда решить проблему с кривыми файлами, доверьте это профессионалам. Наш Конвертер прайса поставщика в CSV для импорта в PrestaShop полностью автоматизирует этот процесс, забирая сырые данные от дистрибьютора, очищая их от мусора, дублей и синтаксических ошибок, и выдавая на выходе идеальный файл, готовый к загрузке в один клик.