Найкращий спосіб обробки файлів з розмежуванням

Отже, як правило, у файлі CSV використовується символ із комою та символом повернення, оскільки це розділювачі поля та рядка.

Це стикається з очевидними проблемами з текстом, який може містити обидва ці символи.

Очевидно, що є варіанти (уникнути їх), але як люди впораються з цим? Використовуєте різні символи - труби чи тильди? Врятуватися від них? Не використовуйте файли з розмежуванням, адже це 2010 рік, і тепер у нас є XML?

Потрібні хоча б зусилля на гідний шанс не бачити проблем.

(Просто для того, щоб бути зрозумілим, це питання з цікавості, а не чогось більш твердого - це те, з чим я стикався час і знову, граючи з даними, завжди його обминаю, але це нормально трохи, добре, брудно, і цікавився, який досвід інших людей).

За даними Вікіпедії :

Поля із вбудованими комами повинні бути укладені у символи подвійної лапки.

І ще:

Поля із вбудованими символами з подвійною цитатами повинні бути вкладені в символи подвійної цитати, а кожен із вбудованих символів подвійної цитати повинен бути представлений парою символів з подвійною цитатами.

Я не знаю, хто це вигадав, але це ефективно показує, що зрештою вам потрібно втекти. Це єдине міцне рішення. Все інше - це просто клейка стрічка на вершині клейкої стрічки: можливо, вона працює і зараз, але зрештою ви натрапите на випадок, коли вам потрібен виняток, за винятком винятку, і це не займе багато часу, перш ніж ваш грязьовий правила спосіб складніший, ніж просте рішення про втечу символів.

Здається, що творці CSV спершу намагалися уникнути уникнення коми, створивши спеціальний синтаксис з подвійним котируванням, який дозволив зберегти коми, але потім хтось теж захотів зберегти символи з подвійним цитуванням, тому їм довелося втекти в цьому пункті - весело використовуючи подвійна цитата як символ втечі. Якби вони вирішили втекти належним чином, синтаксис був би простішим.

Я припускаю, що у вас є щось подібне:

Foo,Baz,,,"Foo,Baz"

Якщо рядки, що містять роздільник, не цитуються та не використовуються, у вас немає реального надійного способу розбору файлу.

Однак ви можете вивчити дані для розбору та зробити висновки на зразок:

• Поплавці, відокремлені комами, слід розглядати як рядок
• Якщо рядок до або після цього містить менше роздільників, пропустіть їх розбір і введіть його
• Поводитись "як"

Вам потрібно написати аналізатор, щоб обробляти подібні речі, але це не повинно бути складним.

На мій досвід, імпорт масивних смітників із чогось подібного Excel завжди призводить до того, що потрібно повернутися назад і переглянути деякі дивні кульки. Ваше завдання полягає в тому, щоб дати вашій програмі тільки досить здорового глузду в відношенні даних , так що він не робить божевільні вставки. Потім перегляньте те, що було зареєстровано, і вимийте / промийте / повторіть.

Я колись обробляв внутрішній FAQ для невеликої компанії, яка використовувала всі робочі станції Ubuntu. Частина поширених запитань давала "ярлики оболонок", і мені це було розмежовано. Ну, відповіді також були типово обмеженими (тобто grep foo | щось), а не цитувались і не уникали. Я відчуваю цей біль :)

З CSV до певного моменту нічого поганого

CSV добре працює для жорстко визначених даних, які навряд чи змінять формат і не проводять багато сюрпризів на аналізаторі одержувача.

Ось зручний список великих ґатухів:

1. Уникнення "" s всередині "" s (поле містить роздільник поля)
2. містить "CRLF" (поле містить роздільник рядків)
3. Unicode (базовий текстовий формат може бути недостатнім)
4. Різні лінійні термінатори для різних ОС (це CR або CRLF або LF або NUL?)
5. Вбудовані коментарі (рядок з префіксом #, //, -,; тощо)
6. Управління версіями (остання версія файлу містить більш-менш поля)
7. Розмежування між NULL та порожніми даними (, "" є порожнім, але ,, null?)

Ви можете звернутися до цього за допомогою заголовка метаданих, який описує, як слід розбирати поля, але тоді ви можете просто використовувати XML. Саме завдяки такому безладному формату CSV було винайдено. Підхід XML просто здається надто важким для того, що, зважаючи на це, може бути простою проблемою.

Популярною альтернативою є стратегія "дивний роздільник символів". Це дозволяє вирішити безліч проблем, що витікають вище, тому що ви використовуєте щось на зразок | (труба) символ для розмежування поля та CRLF для припинення запису. Це не обходить проблему з багаторядковим полем (якщо ви не використовуєте лічильник поля), але ви отримуєте чітко відформатовані лінії для людей.

Загалом, якщо ви просто шукаєте простий спосіб обробки такого файлу, то в світі Java ви можете просто кинути на нього OpenCSV . Таким чином ви абстрагуєте всі проблеми в усталених рамках.

CSV все ще є дійсним форматом у багатьох ситуаціях, тим більше, що клієнтові все-таки найпростіший спосіб записувати дані, які потрібно імпортувати у вашу програму. Мало хто з наших клієнтів любить мати справу з XML, можливо, тому що він дуже багатослівний і має всі ці «страшні» кутові дужки. Їм набагато простіше обернути мізки навколо простого списку предметів, розділених узгодженим символом, а також погоджуються, що той самий символ не буде дозволений у вмісті поля.

З цього приводу, вам все одно належить правильно обробляти дані та перевіряти ситуації, коли вони використовують недійсні символи. Я почав використовувати FileHelpers для мого розбору CSV.

я звичайно дотримуюся стандарту і рятуюся від них. у більшості мов програмування є хороша вбудована підтримка або хороша бібліотека.

це залежить від ситуації, який формат буде використовуватися і CSV - розумний формат для обміну простими структурами формату даних.

Забудьте про CSV, використовуйте JSON . Легко писати, легко розбирати. XML - це так 2005 рік .

Зазвичай, я вважаю, що я отримую TSV (значення, розділені на вкладки), а не файл CSV, перетягуйте файл у Emacs і дивіться, який з небагатьох символів він НІКОЛИ не використовує ($ зазвичай тут хороший вибір), а потім я конвертую всі вкладки в $.

Звідти GNU AWK можна сказати використовувати $ як роздільник поля, а Боб - ваш дядько.