Artykuł
Konwersja między CSV, XML, JSON i YAML: praktyczny przewodnik
CSV, JSON, XML i YAML to cztery formaty, z którymi programiści stykają się najczęściej w potokach danych, plikach konfiguracyjnych i API. Konwersja między nimi jest prosta, gdy modele danych są zgodne, i zaskakująco stratna, gdy tak nie jest. Ten przewodnik omawia, co każdy format może, a czego nie może reprezentować, gdzie informacje znikają podczas konwersji oraz pułapki kodowania, które powodują cichą korupcję danych. Narzędzie data-converter na tej stronie obsługuje trzy z czterech formatów (CSV, JSON i YAML) w całości w przeglądarce; sekcje o XML służą tu jako tło, gdy przenosisz dane ręcznie lub innym narzędziem.
Cztery formaty i ich modele danych
CSV organizuje dane jako płaską siatkę wierszy i kolumn. Pierwszy wiersz zazwyczaj nazywa kolumny; każdy kolejny wiersz to jeden rekord. Nie ma zagnieżdżania, informacji o typach ani standardu dla czegokolwiek poza zwykłym tekstem w komórkach. Każda wartość jest ciągiem znaków, chyba że aplikacja odbierająca narzuca typ. JSON modeluje dane jako drzewo obiektów (map klucz-wartość) i tablic. Wartościami mogą być ciągi znaków, liczby, wartości logiczne, null, zagnieżdżone obiekty lub tablice dowolnej głębokości. Pozwala to jedynemu dokumentowi JSON reprezentować rekord klienta z osadzonymi obiektami adresu, tablicami pozycji i typowanymi sumami numerycznymi. XML modeluje dane jako drzewo elementów. Każdy element może mieć nazwane atrybuty i zawierać elementy podrzędne lub treść tekstową. Nie ma wbudowanego typu numerycznego ani logicznego; wszystko jest tekstem. Schematy takie jak XSD mogą wymuszać typy podczas walidacji, ale format przewodowy to zawsze dane znakowe. YAML używa wcięć do wyrażenia tego samego modelu obiektów i tablic co JSON, z bardziej czytelną dla człowieka składnią. YAML jest nadzbiorem JSON: każdy poprawny dokument JSON jest również poprawnym YAML. Dodaje ciągi wieloliniowe, komentarze i referencje kotwica-alias dla powtarzających się bloków. YAML jest powszechny w plikach konfiguracyjnych; JSON jest powszechny w odpowiedziach API.
Stratne konwersje: spłaszczanie i niejednoznaczność XML
Najczęstszą stratną konwersją jest spłaszczanie zagnieżdżonego JSON lub XML do CSV. Obiekt JSON z zagnieżdżonym polem adresu nie może zostać czysto odwzorowany na wiersz CSV. Typowym obejściem są nazwy kolumn z notacją kropkową: customer.address.city staje się osobną kolumną. Działa to dla jednego poziomu zagnieżdżenia, ale całkowicie zawodzi, gdy pojawia się tablica. Klient z trzema numerami telefonów wymaga albo trzech osobnych kolumn (na twardo zakodowana maksymalna liczba), podziału na drugi plik CSV lub zakodowania tablicy jako ciągu rozdzielanego w jednej komórce. Żadna z tych opcji nie wraca do oryginalnego JSON bez dodatkowych metadanych. XML wprowadza osobną niejednoznaczność: wybór między atrybutem a elementem podrzędnym. Wartość Paris może być przechowywana jako atrybut (<city name="Paris">) lub jako element podrzędny (<city><name>Paris</name></city>). Gdy konwerter odczytuje XML i tworzy JSON, musi zdecydować, jak mapować atrybuty. Powszechne konwencje obejmują poprzedzanie kluczy atrybutów znakiem @ lub umieszczanie ich pod kluczem "_attributes". Wybór nie jest zestandaryzowany, co oznacza, że dwa konwertery odczytujące ten sam XML mogą produkować strukturalnie różny JSON. Jeśli planujesz cyklicznie przetwarzać dane przez XML i JSON, ustal konwencję przed rozpoczęciem.
Pułapki CSV: ograniczniki, cudzysłowowanie i kodowanie
CSV nie ma jednego formalnego standardu, jedynie RFC 4180 jako szeroko cytowany punkt odniesienia. Najczęstszym ogranicznikiem jest przecinek, ale średniki (powszechne w europejskich lokalizacjach, gdzie przecinki służą jako separatory dziesiętne), tabulatory (TSV) i kreski pionowe pojawiają się w praktyce. Plik o rozszerzeniu .csv może używać dowolnego z nich bez sygnalizowania, którego. Gdy wartość pola zawiera sam ogranicznik, RFC 4180 wymaga ujęcia pola w podwójne cudzysłowy: "San Francisco, CA". Podwójny cudzysłów wewnątrz cytowanego pola musi być eskejpowany przez jego podwojenie: "He said ""hello""". Pole zawierające dosłowny znak nowej linii musi być również cytowane. Parsery, które pomijają ten krok, generują błędy liczby wierszy trudne do śledzenia. Kodowanie to osobna pułapka. Pliki CSV z narzędzi Windows często zawierają UTF-8 BOM (znacznik kolejności bajtów: trzy bajty EF BB BF na początku pliku). BOM pomaga Excelowi zidentyfikować kodowanie, ale wiele parserów języków programowania traktuje BOM jako część nazwy pierwszej kolumny, generując kolumnę o nazwie "id" zamiast "id". Psuje to każdy kod poniżej, który wyszukuje kolumny po nazwie. Czytając plik CSV programowo, usuń BOM przed parsowaniem lub użyj biblioteki, która obsługuje go wprost.
Wybór formatu: konfiguracja, wymiana danych i arkusze kalkulacyjne
Wybór formatu jest zazwyczaj zdeterminowany przez kontekst, a nie preferencje. JSON jest domyślnym wyborem dla REST API i wymiany danych między przeglądarką a serwerem. Jest kompaktowy, natywnie parsowany w każdym języku programowania i niesie informacje o typach dla liczb i wartości logicznych. Jego słabością jest brak komentarzy, co czyni go nieodpowiednim do plików, które programiści czytają i edytują ręcznie. YAML jest preferowany w plikach konfiguracyjnych (manifesty Kubernetes, definicje potoków CI, playbooki Ansible), ponieważ umożliwia komentarze inline i jest łatwiejszy do odczytu niż JSON z wieloma poziomami wcięć. Jego głównym ryzykiem jest to, że błędy wcięć są ciche: błędnie wcięty klucz przenosi się do innego zakresu bez żadnego błędu parsowania. XML pozostaje standardem w starszych systemach korporacyjnych, usługach internetowych SOAP, formatach dokumentów (DOCX, SVG, RSS) i kontekstach wymagających walidacji schematu lub ujednoznacznienia przestrzeni nazw. Jest rozwlekły, ale narzędzia XPath i XSLT są dojrzałe. CSV jest właściwym wyborem, gdy dane są naprawdę płaskie, a odbiorcą jest aplikacja arkusza kalkulacyjnego lub analityk danych. Nie nadaje się do konfiguracji ani wymiany przez API, ponieważ nie ma systemu typów ani zagnieżdżania.
Lokalnie z data-converter
Narzędzie data-converter na tej stronie parsuje i konwertuje między CSV, JSON i YAML w całości w przeglądarce; nie odczytuje ani nie zapisuje XML. W żadnym momencie dane nie są przesyłane na serwer. Konwersja działa w lokalnym środowisku uruchomieniowym JavaScript, a wynik jest dostępny do pobrania lub kopiowania bez opuszczania urządzenia. Ma to znaczenie dla danych, którymi nie możesz się swobodnie dzielić: odpowiedzi API zawierające dane osobowe, pliki konfiguracyjne z wewnętrznymi nazwami hostów lub eksporty CSV z wewnętrznych baz danych. Wklejanie takich danych do internetowego konwertera działającego na serwerze oznacza, że treść jest przesyłana przez sieć i przetwarzana na sprzęcie, nad którym nie masz kontroli. W przypadku data-converter karta przeglądarki jest środowiskiem przetwarzania. Narzędzie stosuje cytowanie RFC 4180 przy odczycie lub zapisie CSV i oczekuje płaskiej tablicy obiektów przy konwersji JSON lub YAML do CSV: zagnieżdżony obiekt lub wartość tablicowa pod danym kluczem nie są automatycznie spłaszczane notacją kropkową, więc jeśli potrzebujesz tych pól jako osobnych kolumn, spłaszcz je samodzielnie przed konwersją. Jeśli musisz przenieść dane do lub z XML, najpierw przekonwertuj je do JSON lub YAML dedykowanym narzędziem XML, a następnie wklej wynik tutaj.
Narzędzia w tym artykule
Najczęściej zadawane pytania
Czy mogę cyklicznie przetworzyć JSON przez CSV i odzyskać oryginał?
Tylko jeśli JSON jest płaską tablicą obiektów bez zagnieżdżonych pól i bez tablic jako wartości. W momencie, gdy pojawia się zagnieżdżony obiekt lub wartość tablicowa, reprezentacja CSV wymaga decyzji strukturalnej (kolumny z notacją kropkową, wiele wierszy lub zakodowane ciągi), której nie można automatycznie odwrócić. Jeśli dane mają zagnieżdżanie, JSON, XML lub YAML przetworzy się cyklicznie poprawnie; CSV nie.
Dlaczego mój plik CSV wygląda nieprawidłowo w Excelu po wyeksportowaniu z europejskiej aplikacji?
Europejskie lokalizacje często używają średników jako ogranicznika CSV, ponieważ przecinki są zarezerwowane dla notacji dziesiętnej. Excel w europejskiej lokalizacji oczekuje średników. Jeśli plik używa przecinków, Excel traktuje cały wiersz jako jedną kolumnę. Rozwiązaniem jest zmiana ogranicznika w ustawieniach eksportu lub użycie kreatora importu danych Excela, który pozwala ręcznie określić ogranicznik. Problem UTF-8 BOM jest osobny: bez BOM Excel może również błędnie odczytać znaki akcentowane jako nieczytelny tekst.
Jaka jest różnica między YAML a JSON w praktyce?
Oba reprezentują ten sam podstawowy model danych: obiekty, tablice, ciągi znaków, liczby, wartości logiczne i null. YAML dodaje komentarze (linie zaczynające się od #), literały ciągów wieloliniowych i referencje kotwic dla powtarzających się bloków. JSON jest ściśle podzbiorem prawidłowego YAML, ale parsery JSON nie odczytują YAML. Praktyczna zasada: używaj JSON do ładunków API i przechowywania danych; używaj YAML do plików konfiguracyjnych, które edytują ludzie i które korzystają z komentarzy inline.