Помилки даних під час імпорту CSV: чому виникають і як виправити
Ціни подвоїлися. «café» перетворилося на «café». Три копії кожного товару. Коли імпорт іде не так, перший інстинкт — звинуватити файл, але «поганий файл» майже ніколи не є причиною: дві системи мовчки розійшлися в тому, що означає кома, лапка чи число, і ніщо не сигналізувало про розбіжність, поки неправильні дані вже не опинилися перед вами.
Сім способів, якими файл, що виглядає охайно, бреше
Кожен із них надходить із правильною кількістю рядків і без жодного повідомлення про помилку.
Розбіжності кодування — файл, записаний у Windows-1252 і прочитаний як UTF-8 (або навпаки), перетворює «café» на «café», а тире — на три спотворені символи. Нічого не зламається; значення просто стають неправильними, у тих колонках, які ви не проглядаєте.
Роздільник насправді не кома — більшість континентальної Європи зберігає CSV із крапкою з комою, бо в цих регіонах кома використовується для десяткових дробів. Припустіть неправильний варіант — і отримаєте один суцільний нероздільний стовпець або десяткову кому ціни, розбиту на неіснуючі стовпці.
«Допомога» електронних таблиць перед експортом — Excel зберігає поштовий індекс, введений як 01234, у вигляді числа 1234, а 16-значний штрих-код показує в науковій нотації, округленим після 15 цифр. На момент запису CSV початкового значення більше ніде не існує.
Числа, які означають дві різні речі — 1.234,56 і 1,234.56 — та сама сума за двома регіональними умовностями. Прочитайте одне за припущенням іншого — і воно розпарситься без помилки: як 1.23 або як 1234560.
Заголовки, що рухаються — експорт додає чи переставляє стовпець, «postcode» стає «postal_code», і імпортер, що зіставляє за позицією, тихо записує описи в поля цін. У самому CSV нічого не гарантує, що стовпець 4 означає те саме двічі.
Повторний імпорт без стабільного ключа — виправте три рядки, завантажте заново 2000, і імпортер без стабільної ідентичності на запис створить 2000 дублікатів замість оновлення трьох. Назви змінюються; зовнішній референс, SKU чи номер замовлення — ні.
Символи, яких не видно — нерозривний пробіл, вставлений з вебсторінки, або "Blue " із пробілом наприкінці, виглядає ідентично до чистого значення і провалює будь-який точний збіг — тож та сама категорія створюється двічі, а перевірки на дублікати ніколи не спрацьовують.
Перед завантаженням: перевірка, яка вловлює більшість таких випадків
1
Відкрийте файл один раз як звичайний текст
Перш ніж довіряти попередньому перегляду будь-якого інструмента, відкрийте файл у звичайному текстовому редакторі, а не в табличному: таблиця переінтерпретує файл тієї ж миті, коли його відкриває, і приховує саме ті проблеми, які ви шукаєте. Подивіться на сирий початок першого рядка — чи немає там чогось перед іменем першого стовпця.
2
Переконайтеся, що роздільник саме той, який ви припускаєте
Перерахуйте роздільники очима на кількох різних рядках. Файл, який насправді розділений крапкою з комою, але прийнятий за розділений комами, не покаже жодної коми за межами самих значень — п'ятисекундна перевірка, яка відсікає цілий клас збоїв ще до того, як він почнеться.
3
Перевірте один рядок із комою, лапками та перенесенням рядка
Знайдіть або навмисно створіть тестовий рядок із комою всередині текстового поля, з лапкою та з багаторядковою нотаткою і переконайтеся, що імпортер зберігає кожне з них як одне поле, а не розбиває його. Цей один рядок перевіряє саме той механізм, який за неправильної обробки мовчки зсуває всі стовпці після нього.
4
Запустіть невелику партію перед усім файлом
Спершу десять або двадцять рядків, перевірених по одному, виявляють системну помилку зіставлення — переплутану колонку, не ту валюту, хибний формат дати, — поки виправляти треба десять рядків, а не десять тисяч.
5
Вирішуйте, що означає «готово», для кожного рядка, а не для файлу
Єдиний вердикт «пройшло/не пройшло» для всього файлу нічого не каже про те, які рядки виправляти. Вимагайте результат за кожним рядком — створено, оновлено, пропущено, не вдалося і чому, — перш ніж довіряти імпортеру щось важливе.
Майже завжди — розбіжність кодувань. Файл було записано в одному кодуванні символів — зазвичай Windows-1252 або Latin-1 — і прочитано як UTF-8, або навпаки. Перезбережіть вихідний файл явно в UTF-8 і перевірте, чи потрібно прибрати позначку порядку байтів, залежно від того, чого очікує імпортер.
Табличні редактори зберігають як число все, що виглядає як число, а числа не зберігають провідних нулів. Це сталося ще до запису CSV — у момент, коли значення ввели або автоматично відформатували, — і відновити його з самого лише CSV неможливо: вихідний стовпець потрібно відформатувати як текст, а не лагодити постфактум.
Імпортер не мав стійкого способу розпізнати рядок у новому файлі як «той самий запис», який він уже зберіг, — найімовірніше, тому що зіставлення відбувалося за назвою чи описом, а не за фіксованим ідентифікатором на кшталт зовнішнього посилання, номера замовлення або SKU. Без такого стійкого ключа кожен імпорт виглядає як перший.
Це так само проблема звітності, як і проблема даних: хороший імпортер повідомляє результат щодо кожного рядка, а не лише щодо файлу загалом. Якщо ваш інструмент видає лише одне «успішно/помилка» на все завантаження, сприймайте це як сигнал тестувати невеликими партіями, доки не побачите результати за кожним рядком.
Майже завжди це плутанина між десятковим роздільником і роздільником розрядів. 1.234,56 і 1,234.56 — це два припустимі записи одного й того самого числа в різних регіональних конвенціях, і читання одного за правилами іншого не спричиняє помилки: просто виходить хибне значення. З'ясуйте, яку конвенцію використовує ваш експорт, і явно вкажіть її імпортеру, а не залишайте на здогад.
Обережно: відкрити й перезберегти CSV у табличному редакторі — це саме той крок, який породжує кілька описаних на цій сторінці проблем: провідні нулі, автоматичне перетворення дат, експоненційний запис. Якщо треба вручну виправити кілька рядків, звичайний текстовий редактор безпечніший, ніж повне коло через табличний редактор.
Як це влаштовано в Olmira
Конектор імпорту файлів Olmira побудований саме проти цього списку: строгий парсер RFC 4180, що обробляє коми в лапках і вбудовані переноси рядків, автоматичне видалення провідного UTF-8 BOM, а завеликі файли відхиляються повністю, а не тихо обрізаються. Рядок, кількість стовпців якого не збігається із заголовком, провалюється сам по собі, не перериваючи решту, а ключ дедуплікації означає, що повторне завантаження того самого файлу оновлює або пропускає наявні записи — за обраною вами політикою — а не дублює їх.
Для каталогів товарів і послуг імпорт через CSV додає попередній перегляд по рядках — включно з будь-якими полями, заповненими ШІ, чітко позначеними — перед тим, як буде збережено хоча б один рядок. Повна платформа конекторів, із запланованими вивантаженнями та підписаними вебхуками поряд з імпортом файлів, — на сторінці «Інтеграції».