Digitális és informatikai

CSV és JSON átalakítása adatvesztés nélkül: tizedesjel, azonosító és ékezetek

Gyakorlati ellenőrzések terméklistához, kérdőíves exporthoz és rendszerközi adatcseréhez. Megnézzük, mi marad szöveg, hogyan őrizd meg a kezdő nullákat, és miért kell a képletként értelmezhető mezőkre is figyelni.

Dajka Gábor5 perc olvasás

Az adatcsere akkor sikeres, ha az átalakítás után ugyanazt jelentik a mezők, mint előtte. Egy fájl hibátlan megnyitása ehhez kevés. A 00124 cikkszám, a 12,5 mennyiség és az üres megjegyzés három eltérő értelmezési feladat. A CSV és a JSON közötti átalakítás előtt ezért érdemes röviden leírni az oszlopok jelentését, típusát és megengedett értékeit. Ezzel több későbbi javítást előzhetsz meg, mint az export újbóli próbálgatásával.

A CSV szerkezetet ad, a mezőtípusokat külön kell tisztázni

A CSV sorokból és elválasztott mezőkből áll. Az RFC 4180 a vesszővel elválasztott változat idézőjelezését írja le. A gyakorlatban pontosvesszős és tabulátoros változatokkal is találkozol. Az importálásnál a tényleges elválasztót válaszd ki, és nézd meg, hogy minden rekord ugyanannyi mezőre bomlott-e.

A JSON megkülönbözteti többek között a szöveget, a számot, a logikai értéket és a null értéket. Az RFC 8259 szerint a JSON-szám tizedesjele pont, a rendszerek közötti szövegcsere kódolása pedig UTF-8. Egy idézőjelek közé tett 12,5 ettől még szabályos szöveg lehet; számként más reprezentációt igényel.

A DG CSV–JSON átváltója a CSV-ből kiolvasott mezőket szövegként őrzi meg. Így a rendszer nem dönti el helyetted, hogy egy számszerű adat valóban mennyiség-e. A későbbi típuskonverzió a fogadó rendszer szabályai szerint történjen.

A 00124 azonosító maradjon azonosító

Tegyük fel, hogy a termék cikkszáma 00124, a készlet 12, a szélesség 7,5 cm. A cikkszámnál az első két nulla az azonosító része lehet. Számmá alakításkor ezek elvesznének, és a visszaírt 124 már más szöveges azonosító lenne.

A telefonos körzetszámot, az irányítószámot és a hosszú rendelésazonosítót is a feladat szerinti típusban kezeld. Attól, hogy egy adat csak számjegyeket tartalmaz, még nem szükséges vele összeadást végezni. A CSV importbeállításában ezek az oszlopok szövegként rögzíthetők.

Egy ellenőrző mintába ezért tegyél kezdő nullás azonosítót is. Ha a próbaátalakítás után ugyanaz a karaktersor marad, az adott eset rendben van. Az első és az utolsó sor mellett a leghosszabb azonosítót is nézd meg, mert a hosszfüggő hibák egy rövid mintából nem látszanak.

Tizedesvessző és elválasztó: két külön döntés

Egy magyar környezetből származó sorban szerepelhet 12,5 tizedesérték, miközben a mezőket pontosvessző választja el. Ekkor a két jel nem ütközik. Vesszős CSV-ben ugyanez a szöveges mező idézőjelezést igényel, különben a vessző mezőhatárként értelmeződhet.

Ne cserélj ki minden vesszőt pontra a teljes fájlban. Ezzel a szöveges megjegyzéseket és a szerkezeti elválasztókat is módosíthatod. Ha a fogadó rendszer számot vár, a kijelölt oszlop értékeit kell tudatosan átalakítani, ellenőrzött tizedes- és ezreselválasztási szabály alapján.

Szemléltető próbaadatként legyen három mennyiség: 12,5, 7,25 és 0,75. A megfelelő számmá alakítás után az ellenőrző összeg 20,5. A tizedesjelet tévesen eltávolító import egészen más eredményt adhat. A darabszám és egy ilyen összeg együtt már két, egymást kiegészítő ellenőrzést biztosít.

Az idézőjel és a sortörés lehet az adat része

Egy megjegyzés tartalmazhat vesszőt, pontosvesszőt vagy sortörést. Emiatt a fájl sorainak puszta megszámlálása eltérhet a tényleges rekordok számától. Az idézőjelezett mezőn belüli sortörés egyetlen mező folytatása lehet.

A mezőn belüli idézőjelet CSV-ben általában megkettőzéssel kell jelölni. Az átváltó ezt a szerkezeti feldolgozást kezeli, ezért egyszerű szöveges keresés-cserével ne próbáld kiváltani. Különösen az ügyfélmegjegyzések és a több soros leírások alkalmasak hibakereső mintának.

Az oszlopnevek legyenek egyediek és kitöltöttek. Ha két fejléc egyformán „ár”, a fogadó objektumban már nem egyértelmű, melyik érték melyik mezőt jelenti. A DG eszköze az üres és az ismétlődő fejlécet elutasítja. A jobb elnevezés például nettó_ár és szállítási_ár lehet, a saját adatszerződésednek megfelelően.

Az üres mező, a nulla és a hiányzó adat

A nulla mennyiség, az üres szöveg és az ismeretlen érték eltérő információ. Egy készletnyilvántartásban a 0 azt jelentheti, hogy nincs raktáron termék. Az üres cella jelentése lehet „még nem töltötték ki”, de ezt a CSV formátum önmagában nem mondja meg.

Mielőtt átalakítasz, rögzítsd, hogyan jelölitek a hiányzó adatot. JSON-ból CSV-be alakítva a hiányzó kulcs és a null érték egyszerű exportban egyaránt üres mezőként jelenhet meg. A DG átváltó ilyen lapos táblázatot készít, ezért a különbség megőrzéséhez külön jelzőoszlop vagy előzetes adatmodell szükséges.

A beágyazott objektumok és listák szintén több információt hordoznak egy egyszerű cellánál. Az eszköz ezeket JSON-szövegként írhatja a CSV-mezőbe. Visszaalakításkor ettől még szöveg marad a mező; az eredeti összetett szerkezet automatikus helyreállítását ne feltételezd.

Ékezetek és nagy számok ellenőrzése

Az „Árvíztűrő tükörfúrógép” jól használható magyar próbaszöveg, mert több ékezetes karaktert tartalmaz. Ha az import után hibás jeleket látsz, először a kódolási beállítást ellenőrizd. A látszólagos javulás egy másik betűkészlet választásától még nem feltétlenül oldja meg a hibás dekódolást.

A JavaScript alapértelmezett számtípusánál a biztonságosan pontos egész tartomány felső határa 9 007 199 254 740 991. Az ennél nagyobb számértékű azonosítókat szövegként add meg. A JSON-formázó a támogatott pontosságon kívüli egész számokat hibával jelzi, így segít az észrevétlen kerekítés megelőzésében.

Egy pénzösszegnél is meg kell határozni a pontos adattípust és a mértékegységet. Ha fillérben vagy más legkisebb egységben tárolsz egész számot, ezt a fejléc vagy a séma tegye egyértelművé. A puszta 1250 adatból a fogadó fél nem tudja, hogy forintot, fillért vagy más mennyiséget lát.

Képletként értelmezhető mezők

Az OWASP CSV-injection leírása arra figyelmeztet, hogy egy táblázatkezelő bizonyos kezdőjeleket képletként értelmezhet. Ez a megnyitó program viselkedéséhez kapcsolódik, ezért a biztonságos megjelenítés és a pontos adatmegőrzés között külön döntésre lehet szükség.

A DG átváltó alapértelmezett védelme aposztrófot tesz a veszélyes kezdőjel elé. Ez módosítja a cella szövegét, és nem jelent minden táblázatkezelőre, későbbi mentésre és újbóli megnyitásra érvényes garanciát. Ismeretlen eredetű adatnál kontrollált importot és a célprogramban végzett ellenőrzést használj. A pontos adatmegőrzést csak megbízható adatfolyamnál válaszd tudatosan.

Átadási ellenőrzés néhány perc alatt

Először egy kis, változatos mintát alakíts át: legyen benne ékezet, kezdő nulla, tizedesérték, üres mező és idézőjeles szöveg. Hasonlítsd össze a rekordszámot, a kulcsmezőket és az ellenőrző összegeket. A JSON-összehasonlítóval a két JSON-változat szerkezeti eltéréseit is áttekintheted.

A teljes átadáshoz mellékeld az elválasztót, a kódolást, az oszlopok jelentését és a hiányzó értékek szabályát. Őrizd meg az eredeti exportot külön fájlként. Így egy későbbi eltérésnél eldönthető, hogy a forrásadat, az átalakítás vagy a fogadó rendszer értelmezése változott.

További cikkek

Kapcsolódó olvasnivalók

Gyorskereső

Kalkulátorok és útmutatók keresése

↑↓ választásEnter megnyitásEsc bezárás