A CSV-ből JSON lesz – és ami ebből következik
A CSV-fájlok állnak a leggyakrabban azokon a rendszereken, amelyekben adatot exportálnak egy adatbázisból, egy táblázatkezelőből vagy egy üzleti alkalmazásból. A sorokat valamilyen elválasztó karakter – jellemzően vessző, pontosvessző vagy tabulátor – tagolja oszlopokra, minden cella pedig egy darab szöveg. Amikor ebből a formátumból JSON-t kell készíteni, a konverzió látszólag egyenes út: minden sorból egy objektum lesz, minden oszlopból egy kulcs-érték pár. A gyakorlatban azonban több buktató is kikényszeríti, hogy a felhasználó pontosan értse, mit csinál az eszköz.
Az a CSV-JSON konverter, amelyről ez a cikk szól, egy olyan online eszköz, amely a böngészőben, szerverre feltöltés nélkül végzi el az átalakítást. A felhasználó kiválaszt egy CSV-fájlt, beállítja a megfelelő határolót, és a program elkészíti a JSON-t, előtte megjeleníti az eredmény előnézetét, illetve kiírja a sorok és oszlopok számát valamint a kimeneti fájl méretét. Az egész művelet néhány másodperc alatt lezajlik. A lényeg azonban nem a sebesség, hanem az, hogy mit tesz – és mit nem tesz – az eszköz az adatokkal.
Ezen az oldalon három sajátosság különbözteti meg a konvertálót a hasonló szolgáltatásoktól. Először: a CSV minden mezőjét szövegként kezeli, és a kimeneti JSON-ban is szöveg marad. Nincs automatikus számfelismerés, dátumkonverzió vagy logikai érték feltételezés. Másodszor: a CSV táblázatos szerkezetéből nem lehet beágyazott JSON-objektumokat előállítani – az eredmény minden esetben egy objektumokból álló lapos tömb. Harmadszor: a határoló kiválasztása nem opcionális eldöntendő kérdés, hanem magának a fájlnak a belső szerkezete dönti el.
A határoló kritikus szerepe és a CSV formátum buktatói
A CSV rövidítés ellenére a vessző csak az egyik lehetséges elválasztó karakter. Magyarországi környezetben például a pontosvessző használata gyakori, mert a tizedesvesszőt tartalmazó számok miatt a vessző nem alkalmas határolónak. Az eszköz három lehetőséget kínál: vessző, pontosvessző, tabulátor. Ha a felhasználó rossz határolót választ, az egész táblázat összecsúszik: a sorok darabszáma megegyezik az eredetivel, de az oszlopok tartalma teljesen keveredik. Az eszköz ilyenkor nem feltétlenül ad hibát – egyszerűen értelmetlen JSON-t készít.
A CSV formátum azonban ennél is törékenyebb. A szabvány szerint az olyan cellák értékeit, amelyek maguk is tartalmaznak határoló karaktert vagy sortörést, idézőjelek közé kell tenni. A gyakorlatban viszont sok exportáló rendszer nem tartja be ezt a szabályt, mások keverik az idézőjelek típusait, és vannak olyan CSV-k, amelyekben az idézőjelek párosítatlanok maradnak. Ha a konverter ilyen fájlt talál, a következő üzenet jelenik meg: "This CSV could not be parsed." – magyarul: ezt a CSV-t nem sikerült elemezni.
Egy másik gyakori probléma a sortörések kezelése. Ha egy CSV-oszlopban sortörés van – például egy szállítási cím második sora –, akkor azt a fájlban idézőjelek közé kell tenni. A konverter ezeket a sortöréseket megtartja, és a JSON-ban \n-ként reprezentálja. Ez helyes működés, de sok felhasználó számára meglepetés, amikor a JSON-fájlban hirtelen többsoros sztringeket talál, ahelyett, hogy a sortörés eltűnt volna.
A típusok hiánya: minden szám is szöveg marad
Amikor valaki egy CSV-t JSON-ná alakít, gyakran várja, hogy a számok automatikusan szám típusúvá váljanak, az üres cellák null-ként jelenjenek meg, és a logikai értékek true vagy false alakot öltsenek. Ezen az eszközön semmi ilyen nem történik. Minden CSV-mező szöveg marad, függetlenül attól, hogy a tartalom "42", "2024-01-15" vagy "TRUE" – mindegyik sztringként kerül a JSON-ba.
Ez a viselkedés nem hiba, hanem szándékos döntés. A CSV-nek nincs típusrendszere – minden adat karakterlánc. Ha a konverter elkezdené kitalálni, hogy melyik mezőt milyen típusra alakítsa, akkor számos esetben tévedne. Egy "00123" formátumú termékkódot például 123-ra konvertálna, ami a vezető nullák elvesztését jelentené. A születési dátumoknál a "2024-01-15" sztring marad, nem alakul át dátum-objektummá. A legtöbb JSON-felhasználó számára ez elfogadható, sőt előnyös, mert a típuskényszerítést a célalkalmazásban lehet szabályozni.
A vezető nullák esete az egyik leggyakoribb buktató. A CSV-fájlokban az olyan mezők, mint az irányítószámok ("01234"), a termékkódok ("00567") vagy a telefonszámok előhívói, elveszítenék a formátumukat, ha a konverter számmá alakítaná őket. Mivel az itt tárgyalt eszköz ezt nem teszi, a nullák megmaradnak. Ha viszont a felhasználó a letöltött JSON-t egy olyan környezetbe tölti be, amely automatikusan típuskonverziót végez (például egy JavaScript-könyvtár), akkor a nullák utólag is eltűnhetnek.
Hibakezelés és korlátok: mit tehet, ha a fájl nem dolgozható fel
A konverter több előre meghatározott hibaüzenettel rendelkezik, amelyek mindegyike egy-egy jól körülhatárolt problémára utal. Ha a felhasználó nem választ ki fájlt, és mégis megpróbál konvertálni, az üzenet: "Choose one file first." Ha rossz fájltípust ad meg – tehát nem CSV-t, JSON-t vagy XLSX-t –, akkor ezt írja ki: "Choose a CSV, JSON or XLSX file."
A fájlméretre és a táblázat méretére vonatkozó korlátok is be vannak építve. Ha a CSV több sort vagy oszlopot tartalmaz, mint amennyit az eszköz kezelni tud, akkor a következő üzenetek valamelyike jelenik meg: "This table has more than ‹max› rows." vagy "This table has more than ‹max› columns." A kapacitás pontos értéke nem kerül nyilvánosságra a forrásanyagban, de a lényeg, hogy a korlát túllépésekor a konverzió nem indul el. Ugyanígy, ha a fájl mérete meghalad egy bizonyos határt, az üzenet: "This file is too large. Use a file under ‹max›."
Az időkorlát is létezik: ha a konverzió túl sokáig tart – például egy nagyon nagy fájl esetén, amely éppen a határon van –, akkor a program ezt közli: "This conversion is taking too long. Try a smaller file." Végül, ha a CSV üres adatsorokat tartalmaz – tehát nincs olyan sor, amely legalább egy kitöltött cellával rendelkezne –, a következőt kapja: "This file has no table rows." Egyik üzenet sem technikai részletezést ad, hanem gyakorlati tanácsot, hogy a felhasználó mit tegyen.
Kliensoldali feldolgozás: az adatok nem hagyják el a gépét
Az egyik legfontosabb tulajdonság, hogy a teljes konverzió a böngészőben fut, szerver nélkül. Ez azt jelenti, hogy a CSV-fájl tartalma soha nem kerül fel egy távoli számítógépre. A fájl beolvasása, a feldolgozás és a JSON előállítása mind a felhasználó gépén történik. Ez különösen fontos olyan adatok esetében, amelyek érzékenyek: ügyféladatok, pénzügyi kimutatások, személyes azonosítók. Mivel nincs feltöltés, nincs adatforgalom sem – a fájl ugyanazon a gépen marad, ahonnan kiválasztották.
Ugyanez a kliensoldali megközelítés azonban azt is jelenti, hogy a konverter nem tud típusfelismerést vagy adattisztítást végezni. Az összes olyan funkció, amelyhez adatbázis-kapcsolat vagy külső szolgáltatás kellene, nem érhető el. A felhasználónak magának kell gondoskodnia arról, hogy a CSV megfelelő formátumú legyen, és ha a JSON-ban szüksége van típusokra, akkor utólag kell azokat beállítania.
Kinek való ez a konverzió – és mit várhat tőle
A fejlesztők a legnyilvánvalóbb célcsoport. Egy adatbázisból vagy táblázatkezelőből exportált CSV-fájlt kell JSON formátumba alakítaniuk, hogy egy JavaScript-alkalmazás vagy egy API be tudja olvasni. A konverter gyors, nem igényel telepítést, és a böngésző offline módban is működik.
Az adatelemzők is használhatják, különösen ha olyan CSV-t kell feldolgozniuk, amely vezető nullákat tartalmaz. Egy latin-amerikai irányítószám-listában minden öt számjegyű kód nullával kezdődik – a legtöbb JSON-parser ezeket a nullákat automatikusan eltüntetné. Ezen az eszközön a nullák megmaradnak, mert minden adat szöveg marad.
A csapatok, akikben vannak nem technikai munkatársak és fejlesztők is, szintén profitálnak belőle. Az Excel-felhasználók exportálnak egy CSV-t, a fejlesztők pedig egy JSON-t kapnak – minden olyan adatátvitel nélkül, amely érzékeny információt vinne ki a szervezetből.
Gyakran Ismételt Kérdések (FAQ)
Miért marad minden érték szöveg a JSON-ban? Mert a CSV-nek nincs típusrendszere. A konverter nem tudja, hogy egy adott mezőben szám, dátum vagy azonosító van – mindegyiket sztringként kezeli. Ez megőrzi a vezető nullákat és elkerüli a téves típuskonverziót.
Mit jelentenek a "This CSV could not be parsed" hibaüzenet esetén? A CSV fájlban az idézőjelek vagy határolók olyan hibát okoznak, amelyet a konverter nem tud feloldani. Ilyenkor érdemes a CSV-t egy egyszerű szövegszerkesztőben megnyitni, ellenőrizni az idézőjelezést és a határolók konzisztenciáját.
Miért kell külön kiválasztani a határolót? Mert a CSV nem egyetlen szabványt követ. A vessző, a pontosvessző és a tabulátor mind gyakori, és a konverter nem tudja automatikusan eldönteni, hogy melyiket használja a fájl. A helytelen határoló összekeveri az oszlopokat.
Hová kerülnek a fájladatok a konverzió során? Sehová. Az egész folyamat a böngészőben, a felhasználó gépén fut. A fájl soha nem hagyja el a számítógépet.
Mit tegyek, ha a fájl túl nagy a konverter számára? A konverter egy fájlméret-korláttal és sor/oszlop korlátokkal működik. Ha túllépi ezeket, a program hibát jelez. Ilyenkor ossza több részre a CSV-t, vagy használjon más eszközt, amely nagyobb fájlokat is kezel.
Miért nem válnak a számok automatikusan szám típusúvá a JSON-ban? Mert a számértékek – például a "00123" – vezető nullákat tartalmazhatnak, amelyek elvesznének a konverzió során. A konverter minden adatot sztringként hagy meg, és a típuskényszerítést a felhasználóra bízza.