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 ECMAScript nyelvi szabvány a Number.MAX_SAFE_INTEGER értékeként rögzíti ezt a határt.
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ó azonos számmá alakítá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.
Hat sor marad, de két azonosítópár már nem különböztethető meg
Próbáld végig ezt a hat szöveges azonosítót: 00123, 123, 9007199254740991, 9007199254740992, 9007199254740993 és 9007199254740994. A kiindulás hat sor és hat különböző azonosító. A kezdő nullás értéket a JSON-ban is szövegként kell átadni; a 00123 önálló JSON-számliterálként nem szabályos.
Ha egy köztes lépés mindegyiket a JavaScript Number típusára alakítja, a 00123 és 123 összeesik. A 9007199254740992 és 9007199254740993 szintén ugyanahhoz a számhoz jut. Így továbbra is hat sorod, de már csak négy egyedi számod lehet. A sorok darabszámát ellenőrző importteszt ezt a hibát nem találja meg.
A 9007199254740992 önmagában pontosan ábrázolható, mégis kívül van a biztonságos egész tartományon: a mellette álló egész már nem különíthető el tőle. Az, hogy egy kiválasztott hosszú számot helyesen visszaír a program, gyengébb állítás annál, hogy minden megengedett azonosítót egyértelműen megőriz. A JSON-szabvány számtartományról szóló része az átjárhatóságot éppen a fogadó számtípus pontosságához köti.
Az ellenőrző tábládban szerepeljen az eredeti szöveg, a visszakapott szöveg és a pontos egyezés eredménye. Ennél a mintánál az elvárt eredmény hat különböző szöveg és hat sikeres visszaegyezés. Ha a kezdő nulla vagy a hosszú azonosító megváltozik, még a rekordkapcsolás előtt javítsd a típust átalakító lépést, és az eredeti exportból ismételd meg a próbát.
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.
Záró tudáspróba
Válassz kérdésenként egy választ. A megoldások ellenőrzése után minden helyes válaszért 1 pontot adj magadnak; a hibás, kihagyott vagy több válasszal megjelölt kérdés 0 pont. Összesen 0–3 pont szerezhető.
1. Melyik igaz a 9007199254740992 értékre a JavaScript Number típusánál?
- A) Pontos lehet, miközben nem biztonságos egész, mert a szomszédjától nem mindig különíthető el.
- B) Semmilyen formában nem adható át JSON-ban.
- C) Minden nála nagyobb egész is pontosan megkülönböztethető.
2. A hat szöveges próba Number típusra alakítása után hány különböző érték marad?
- A) 6
- B) 4
- C) 2
3. Melyik próba igazolja az azonosítók megőrzését?
- A) Az export szintaktikailag szabályos.
- B) A sorszám változatlan.
- C) Minden visszaolvasott azonosító pontosan egyezik az eredeti szöveggel.
Megoldások és pontszám
1. A. A 2⁵³ ábrázolható, de a 2⁵³ + 1 ugyanarra az értékre kerekedhet. A biztonságos tartomány felső határa ezért 2⁵³ − 1.
2. B. Két pár összeesik: a 00123 a 123-mal, a 9007199254740993 pedig a 9007199254740992-vel. A sorok száma ettől még hat.
3. C. A szintaxis és a darabszám szükséges ellenőrzés lehet, de az eredeti karakterlánccal való pontos egyezés mutatja meg a számjegy és a kezdő nulla megmaradását.
3 pont: A számtípus határát és a rekordazonosság próbáját is alkalmaztad. Az interfész minden lépésén vezesd végig a hatértékes mintát.
2 pont: Az 1. kérdéshez a pontos és biztonságos egész különbségét, a 2.-hoz a két összeeső párt, a 3.-hoz a visszaolvasási táblát nézd át.
0–1 pont: Indulj a 00123 és 123 szövegpárból, majd próbáld ki a két szomszédos hosszú azonosítót. Rögzítsd, melyik átalakításnál tűnik el a különbség.