Parser CSV/TSV

CSV (Comma-Separated Values) to prosty format dla danych tabelarycznych, szeroko obsługiwany przez arkusze kalkulacyjne i bazy danych. To narzędzie parsuje pliki CSV i TSV, automatycznie wykrywa separatory, obsługuje pola w cudzysłowach i wyświetla dane w sformatowanej tabeli.

Specyfikacje

• RFC 4180 - CSV Format

Typowe zastosowania

• Podgląd eksportów CSV przed importem do bazy danych
• Konwersja CSV do JSON do wykorzystania w API
• Walidacja eksportów danych z arkuszy kalkulacyjnych
• Szybka inspekcja plików logów i zrzutów danych

Funkcje

• Automatyczne wykrywanie separatora (przecinek, tabulator, średnik, kreska pionowa)
• Wyświetlanie jako sformatowana tabela z nagłówkami
• Konwersja do tablicy obiektów JSON
• Interaktywny widok drzewa dla reprezentacji JSON
• Kopiowanie jako tabela HTML
• Transpozycja wierszy i kolumn

Przyklady

name,email,role
Alice,alice@example.com,admin
Bob,bob@example.com,user
Charlie,"charlie@example.com",user

Wskazowki

• Pierwszy wiersz jest zazwyczaj traktowany jako nagłówki.
• Pola zawierające przecinki lub znaki nowej linii umieszczaj w podwójnych cudzysłowach.
• Podwójne cudzysłowy wewnątrz pól w cudzysłowach są escapowane jako "".
• TSV (rozdzielany tabulatorami) unika wielu problemów z cytowaniem.

Zrozumienie Parser CSV/TSV

CSV (Comma-Separated Values) to jeden z najstarszych i najszerzej obsługiwanych formatów wymiany danych. Pomimo swojej prostoty, CSV ma wystarczająco dużo niejednoznaczności, aby powodować uporczywe problemy z interoperacyjnością. RFC 4180 definiuje standard, ale wielu producentów odbiega od niego, prowadząc do problemów z parsowaniem dotyczących separatorów, cytowania, kodowania i końców linii.

Podstawowa struktura to jeden rekord na linię z polami rozdzielonymi przecinkami. Gdy pole zawiera przecinek, znak nowej linii lub podwójny cudzysłów, musi być ujęte w podwójne cudzysłowy. Podwójne cudzysłowy wewnątrz pola w cudzysłowach są escapowane przez podwojenie (""). Pierwszy rekord jest zwykle traktowany jako wiersz nagłówkowy, choć jest to konwencja, a nie wymóg.

Warianty separatorów są powszechne. TSV (Tab-Separated Values) używa tabulatorów, unikając większości problemów z cytowaniem. Europejskie lokalizacje używające przecinków jako separatorów dziesiętnych często używają średników jako separatorów pól. Pliki rozdzielane kreską pionową pojawiają się w systemach starszego typu. Dobry parser CSV automatycznie wykrywa separator, analizując kilka pierwszych linii.

Kodowanie znaków to kolejne częste źródło problemów. Excel na Windowsie zapisuje CSV w lokalnym kodowaniu systemowym zamiast UTF-8. Otwarcie pliku CSV w UTF-8 w Excelu może wyświetlić zniekształcone znaki. Dodanie BOM (byte order mark) UTF-8 na początku pliku sygnalizuje Excelowi, że plik jest zakodowany w UTF-8. Przy wymianie plików CSV między systemami zawsze weryfikuj kodowanie znaków.

Gdy dane CSV wyglądają źle w Excelu, dwie najczęstsze przyczyny to niezgodność kodowania i niezgodność separatora. Plik UTF-8 otwarty przez Excel zakładający lokalne kodowanie wyświetli zniekształcone znaki, a dodanie BOM zazwyczaj to naprawia. Problemy z separatorem pojawiają się w europejskich lokalizacjach, gdzie Excel oczekuje średników zamiast przecinków. Użycie kreatora Dane > Tekst zamiast dwukrotnego kliknięcia pliku daje jawną kontrolę nad kodowaniem i separatorem.

Zgodnie z RFC 4180, każde pole zawierające przecinek, znak nowej linii lub podwójny cudzysłów musi być ujęte w podwójne cudzysłowy. Podwójne cudzysłowy wewnątrz pola w cudzysłowach są escapowane przez podwojenie. Większość bibliotek CSV obsługuje to poprawnie, ale problemy pojawiają się, gdy pliki są edytowane ręcznie lub parsowane naiwnym podziałem ciągów zamiast właściwego parsera CSV. TSV (Tab-Separated Values) unika większości tych komplikacji z cytowaniem, ponieważ tabulatory rzadko pojawiają się w danych, co czyni go popularnym wyborem w bioinformatyce, nauce o danych i kontekstach, gdzie wartości pól często zawierają przecinki.

CSV i JSON służą różnym potrzebom wymiany danych. CSV jest idealny dla płaskich danych tabelarycznych ze spójnymi kolumnami — jest uniwersalnie obsługiwany przez arkusze kalkulacyjne i narzędzia do danych i pozostaje kompaktowy dla dużych zbiorów danych. JSON jest lepszym wyborem dla zagnieżdżonych lub hierarchicznych danych i jest standardowym formatem dla API. Dla eksportów z baz danych, raportowania i obiegów pracy z arkuszami kalkulacyjnymi, CSV pozostaje praktycznym domyślnym formatem.