Egy rendelésazonosító helyesnek látszik a szerver exportjában, a böngészőből visszaküldött változatban mégis más számjeggyel végződik. Az egyik lehetséges ok, hogy az azonosítót számként adták át, és a fogadó rendszer számtípusa már nem képes minden szomszédos egész értéket pontosan megkülönböztetni.
Az azonosítóval általában nem összeadást vagy átlagolást végzel. Egyezést keresel, rekordot nyitsz meg, vagy más rendszerhez kapcsolod. Ezért a mező adatmodelljében előre el kell dönteni, számítási érték vagy megőrzendő jelölés szerepel-e benne.
A JavaScript biztonságos egész határa
A JavaScript általános Number típusánál a legnagyobb biztonságos egész érték 9 007 199 254 740 991, azaz 2⁵³ − 1. Az MDN hivatalos leírása a pontos megkülönböztetés korlátját is bemutatja.
Nézzünk két saját azonosítót: 9007199254740992 és 9007199254740993. Szövegként különböznek. Ha mindkettőt Number értékként értelmezed, ugyanahhoz a reprezentálható számhoz juthatnak. Egy ilyen átalakítás után az eredeti különbség már elveszett.
A JSON-dokumentum ettől még lehet szabályos. A formátumellenőrző azt vizsgálja, hogy a dokumentum megfelel-e a nyelvtannak; a mező üzleti szerepét és a későbbi fogyasztó pontosságát külön adatminőségi szabály biztosítja.
A megőrzendő azonosítót szövegként add át
A saját interfészszerződésedben megadhatod, hogy a rendelésazonosító szöveg, kizárólag számjegyeket tartalmaz, és legfeljebb meghatározott hosszúságú. A két példa így idézőjelek között kerül a JSON-ba, és szövegként érkezik a feldolgozóhoz.
Ugyanez a döntés megőrzi a kezdő nullát is. A 00123 és 123 üzletileg különböző jelölés lehet; számmá alakítva mindkettő 123 lesz. A kezdő nullák utólagos visszapótlása csak ismert, rögzített hosszúsági szabály mellett egyértelmű.
A JSON-összehasonlító segíthet észrevenni a mezőtípus és a szöveges érték változását. A veszélyes számmá alakítás előtti eredeti exportot is őrizd meg, mert egy már kerekített érték összehasonlítása nem állítja helyre az elveszett számjegyet.
Az út minden lépését ellenőrizd
A megőrzési szerződésnek az adatbázisra, a szerveroldali kódra, a JSON-ra, a böngészőre és a következő exportra egyaránt ki kell terjednie. Elég egyetlen köztes lépés, amely automatikusan számmá alakítja a szöveget, és a probléma visszatérhet.
Készíts próbát egy rövid azonosítóval, egy kezdő nullás értékkel, a biztonságos határértékkel és a fenti két szomszédos hosszú értékkel. A visszaolvasásnál az eredeti szövegek pontos egyezését ellenőrizd. A darabszám egyezése önmagában kevés: két azonosító összeomlása mellett a sorok száma még változatlan maradhat.
A CSV–JSON átváltó használatakor különösen figyeld az oszloptípusokat. Egy táblázatkezelőben előzőleg már átformázott CSV-ből a hiányzó számjegy rendszerint nem következtethető vissza egyértelműen.
Számítási mennyiségeknél más döntés kell
A szöveges tárolás nem általános helyettesítője minden számtípusnak. Összeg, mennyiség és mérési adat esetén meg kell határozni a pontosságot, a mértékegységet és a számítási módot. Egy pénzösszeghez például külön rögzíthető a legkisebb elszámolási egység és a megengedett tartomány.
A JavaScript BigInt más feladatokra megoldás lehet, de a szokásos JSON-kódolásban külön átadási megállapodást kíván. Ne válts rá egyoldalúan, miközben a fogadó rendszer továbbra is Number értéket vár. Az interoperabilitásról a JSON szabvány számtípusokra vonatkozó része is szól.
Gyakori kérdések
A 16 számjegy mindig veszélyes?
A konkrét érték és a feldolgozó számtípusa számít. Az azonosító megőrzéséhez egyszerűbb a dokumentált szöveges szerződés, mint a számjegyszámra épített találgatás.
A formázás után látható számjegyek bizonyítják a pontosságot?
Nem. A formázó a már feldolgozott értéket is kiírhatja. Az eredeti adat és a visszaolvasott szöveg egyezését kell vizsgálni.
A hosszú azonosítókat törölni kell az importból?
Nem szükséges. Megfelelő mezőtípussal és végpontok közötti megőrzési teszttel biztonságosan átadhatók.