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.
A fejléc szóközeit is vizsgáld meg: az „ár” és az „ár ”, vagyis a végén szóközt tartalmazó változat eltérő szöveg. A DG megőrzi ezeket, így a két fejléc a pontos szövegegyezést vizsgáló duplikációellenőrzésen külön névként mehet át. A fogadó rendszer ettől még csak az egyik kulcsot várhatja. A fejléc javítását a megállapodott mezőnevekhez igazítsd, majd az egyediséget újra ellenőrizd. Az összes adatmező elejéről és végéről ne törölj automatikusan karaktereket: az RFC 4180 szerint a szóköz a mező része, és egyes azonosítóknál jelentése lehet.
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.
Visszafordítható minta a hiányzó, null és üres szöveghez
Ha a különbség üzletileg számít, egy külön állapotmező megoldhatja a jelölést. Saját átadási szabályunkban minden színadat két CSV-oszlopot kap: szin_allapot és szin_ertek. Az állapot csak hianyzik, null vagy ertek lehet. Ezek ebben a példában egyeztetett címkék, nem beépített CSV-szabványok.
| Eredeti JSON jelentése | szin_allapot | szin_ertek tartalma |
|---|---|---|
| A szin kulcs nincs jelen | hianyzik | üres mező |
| A szin kulcs értéke JSON null | null | üres mező |
| A szin kulcs értéke üres szöveg | ertek | üres mező |
| A szin kulcs a „null” szöveget tartalmazza | ertek | null betűsor |
A visszaalakító a hianyzik címkénél elhagyja a kulcsot, a null címkénél valódi JSON null értéket állít elő. Az ertek címkénél szöveget olvas vissza, akkor is, ha a mező üres vagy éppen a null betűsor szerepel benne. Ismeretlen állapotcímkét és a szabállyal ellentétes kitöltést hibaként jelez, hogy a jelentés ne alakuljon át észrevétlenül.
A négy sort alakítsd oda-vissza próbaként, és az eredeti objektumok kulcsainak jelenlétét, értékét és típusát is hasonlítsd össze. A DG általános átváltója ezt a saját adatmodellt nem találja ki és nem állítja vissza automatikusan; a jelzőoszlopok értelmezését a fogadó folyamatban kell megvalósítani. Ugyanez az elv más mezőkre is alkalmazható, amennyiben a jelölést a küldő és a fogadó rendszer közösen rögzíti.
É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.
A jó végösszeg mellett is lehet rossz az adatcsere
Az összeg és a rekordszám hasznos gyors ellenőrzés, de nem bizonyítja, hogy az értékek a megfelelő azonosítóhoz kerültek. Vegyük a korábbi három mennyiséget, és rendeljük őket három cikkszámhoz. Egy hibás átalakítás csak az első két mennyiséget cserélje fel:
| Cikkszám, szövegként | Eredeti mennyiség | Hibásan visszakapott mennyiség |
|---|---|---|
| 00124 | 12,5 | 7,25 |
| 00125 | 7,25 | 12,5 |
| 00126 | 0,75 | 0,75 |
| Összeg | 20,5 | 20,5 |
Mindkét állomány három rekordot és három különböző azonosítót tartalmaz. A mennyiségek összege is azonos. Mégis két termék készlete hibás. Az összehasonlítást ezért az egyedi azonosító alapján összepárosított rekordokon is el kell végezni.
A JSON-összehasonlításról szóló útmutatóban végigkövetheted a rendelési sorok azonosító szerinti párosítását és a tömbsorrendből eredő eltérések értelmezését.
Előbb ellenőrizd, hogy az azonosító valóban egyedi-e. Ha ugyanaz a cikkszám többször szerepelhet, további kulcs kellhet, például raktár vagy változat. A többszörös kulcsokat ne tüntesd el automatikusan azzal, hogy csak az első vagy az utolsó sort tartod meg: előbb tisztázni kell, melyik rekord mit jelent.
Ezután ugyanazon kulcsnál nézd meg a mezőértékeket és a típusszabályt. A mennyiségnél előre rögzített tizedesátváltást alkalmazhatsz; a cikkszámnál a kezdő nullákat tartalmazó teljes szöveg egyezzen. A megjegyzésnél a sortörések és idézőjelek is az adat részei lehetnek. A különbséget csak akkor hagyd figyelmen kívül, ha az adatszerződés ezt kifejezetten megengedi.
A visszaalakítás önmagában szintén kevés lehet. Ha mindkét irány ugyanazt a tévesen kiválasztott típusszabályt használja, a hiba tartósan továbbélhet. A visszakapott adatot az eredeti, változatlan exporthoz és annak jelentéséhez hasonlítsd, ne csak a köztes fájl másik formátumához.
Egy ellenőrizhető átadási jegyzet így négy kérdésre válaszol: egyezik-e a rekordszám, megmaradt-e a kulcsok készlete és egyedisége, egyeznek-e a kulcsonkénti mezők, és egyeznek-e a megfelelően értelmezett összesítések. A JSON-összehasonlító segíthet a szerkezet vizsgálatában, de a különböző sorrendű listák üzleti kulcs szerinti összepárosítását és a mezők jelentését előbb tisztázd.
Ha eltérést találsz, őrizd meg a problémás rekord kis mintáját az eredeti és a fogadó alakban. Ebből pontosan megmutatható, hogy a nullák, a tizedesjel, a típus vagy a rekordhoz rendelés sérült-e. A javított átalakításon ugyanezt a mintát futtasd újra, majd a teljes állomány ellenőrzését is ismételd meg.
Á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.
Záró tudáspróba
Kérdésenként egy választ jelölj meg, majd a megoldások alapján pontozd magad. Ez a három kérdés a cikkben bemutatott összefüggéseket ellenőrzi.
1. A 00124 ügyfélazonosítót JSON-ban is pontosan meg kell őrizni. Milyen típus illik hozzá?
- A) Szöveg, a kezdő nullákkal együtt.
- B) Logikai érték.
- C) Szám, mert csak számjegyekből áll.
2. A három összeg átalakítás előtt és után is 20,50. Bizonyítja ez, hogy jó ügyfélhez került minden tétel?
- A) Nem; a mezőket az egyedi azonosítóhoz rendelve is össze kell hasonlítani.
- B) Igen, ha ugyanannyi fizikai sor van a fájlban.
- C) Igen, az azonos végösszeg minden adatcserét igazol.
3. A hiányzó tulajdonságot, a JSON nullt, az üres szöveget és a „null” szöveget CSV-n keresztül is megőriznéd. Mi a cikk visszafordítható megoldása?
- A) Mindet üres mezőre cseréled.
- B) Külön állapotmező és értékmező, előre rögzített értelmezéssel.
- C) Mindet 0-ra cseréled.
Megoldások és pontozás
1. A. Az azonosító nem mennyiség. A számmá alakítás eltüntetné a kezdő nullákat, ezért az adatcsere megállapodásában szövegként kell kezelni. Ismétléshez: A 00124 azonosító maradjon azonosító.
2. A. Két összeg felcserélése változatlan végösszeget ad. Az azonosító, az érték és az adattípus összetartozását külön ellenőrzés fogja meg. Ismétléshez: A jó végösszeg mellett is lehet rossz az adatcsere.
3. B. A CSV üres cellája önmagában nem nevezi meg a négy eredeti állapotot. Az állapotmező jelzi a hiányt, a nullt vagy az értéket; az értékmező a tényleges szöveget őrzi. Ismétléshez: Visszafordítható minta a hiányzó, null és üres szöveghez.
Minden helyes válasz 1 pont; a hibás vagy kihagyott válasz 0 pont. Az összpontszám 0–3 lehet.
- 0 pont: dolgozd végig újra a három megoldásban megjelölt részt, és írd le a példák kiinduló feltételeit.
- 1 pont: a két elhibázott kérdésnél vezesd le a helyes választ; külön írd mellé, melyik feltétel vagy számolási lépés maradt ki.
- 2 pont: térj vissza az egyetlen elhibázott kérdéshez kapcsolt részhez, majd egy bemenet megváltoztatásával ellenőrizd újra az eredményt.
- 3 pont: a három összefüggést ebben a feladatsorban helyesen alkalmaztad. Próbáld ki a cikk egyik ellenőrzését saját adatokkal, a feltételeket és a mértékegységeket is feljegyezve.