प्रस्तावना

फ़्रंटएंड और बैकएंड के अलग होने के इस दौर में, हमारा जीवन अनगिनत अवसरों और चुनौतियों से भरा है——इनमें अचानक सामने आकर सिर चकरा देने वाले Bug भी शामिल हैं। आज हम जिस पर बात करेंगे, वह एक ऐसी पुरानी समस्या है जिसने अनगिनत डेवलपरों को हँसने और रोने के बीच अटका दिया है：बैकएंड Long टाइप ID बहुत लंबी होने से फ़्रंटएंड में संख्यात्मक सटीकता खो जाती है। इस समस्या की बात करें, तो यह सचमुच “सारी बुराइयों की जड़” है, आखिर JavaScript केवल सुरक्षित रूप से संसाधित कर सकता है Number.MAX_SAFE_INTEGER（अर्थात 9007199254740991）की सीमा के भीतर के मानों का क्या？

यदि आप कभी इस समस्या पर बहुत सिर खपा चुके हैं, तो चिंता न करें, आप अकेले नहीं हैं। आज हम इस “सदी की कठिन पहेली” को हास्यपूर्ण ढंग से समझेंगे ही नहीं, बल्कि इसे जड़ से हल करने में भी आपकी सहायता करेंगे, ताकि आपका कोड फिर “परिशुद्धता न खोए”।

समस्या की पृष्ठभूमि：क्यों Long इतना लंबा？

सबसे पहले, हमें यहाँ से शुरू करना होगा Long प्रकार से शुरू करें।Long，यानी Java में 64 बिट का पूर्णांक प्रकार, उन लोगों के लिए जिन्हें संसाधित करना पसंद हैविशाल डेटा、बड़ी संख्याओं वाले Java के लिए, यह प्रकार किसी वरदान से कम नहीं है। लेकिन फ़्रंटएंड की दुनिया कुछ “कम जानकार” है, वह केवल 53 बिट के भीतर आने वाले पूर्णांकों को संभालना जानती है। जी हाँ, आपने सही सुना, इस मामले में JavaScript यह मानो “आधा कदम पीछे” चलने वाला कोई बूढ़ा पंडित हो; बड़ी संख्याएँ सामने आते ही यह दशमलव बिंदु और घातांकों से खेलना शुरू कर देता है, और अंत में ऐसी संख्या उगलता है कि आप निराश हो जाएँ। फिर परिशुद्धता खोने की समस्या भूत की तरह आपके प्रोजेक्ट में भटकने लगती है।

पहली मुलाकात：परिशुद्धता खोने के किस्से

कहानी किसी दिन मिली एक बग रिपोर्ट से शुरू होती है：“डेवलपर भैया, ज़रा देखिए, यह ID कैसे बदल गई？यह तो मेरीडेटाबेस के अंदर वाला वह ID है！”आप भौंहें सिकोड़कर देखते हैं，हाँ，9223372036854775807 बदलकर हो गया 9223372036854776000，अरे, ये अतिरिक्त अंक तो बिल्कुल जादू जैसे हैं। बैकएंड से तो सही मान आया था! आप सिर खुजलाते हुए सोचते हैं：“यह पक्का फ़्रंटएंड की गलती है！”

गलती फ़्रंटएंड की है या बैकएंड की？——जड़ तक पहुँचना

सच कहूँ तो, इस समस्या का दोष फ्रंटएंड पर डालना भी पूरी तरह बेबुनियाद नहीं है। आइए देखें JavaScript संख्याओं को संभालने में “कमज़ोर कड़ी”।JavaScript का Number प्रकार IEEE 754 मानक पर आधारित दोहरी परिशुद्धता वाला फ़्लोटिंग-पॉइंट प्रारूप है, जो केवल 53 बाइनरी अंकों को सुरक्षित रूप से निरूपित कर सकता है, यानी Number.MAX_SAFE_INTEGER का मान——9007199254740991。

दूसरे शब्दों में，इस सीमा से बाहर के पूर्णांक，JavaScript की “सटीकता घटने” लगती है, उसकी “दिमागी क्षमता” अचानक कम पड़ जाती है। फिर, आपका Long प्रकार के ID उसकी नज़र में ऐसे अंकों का ढेर बन जाते हैं जो उतने “आकर्षक” नहीं हैं। इसी कारण, इन बेहिसाब लंबे ID को संभालते समय फ़्रंटएंड को थोड़ा “त्याग” करना पड़ता है, और नतीजा यह होता है कि आपका मूलतः सटीक ID कटकर एक “दिलचस्प” नई संख्या बन जाता है।

सदमे से संयम तक：समाधान की खोज

अब जब समस्या की जड़ मिल गई है, तो हम डेवलपरों के लिए अपना हुनर दिखाने की बारी है। आगे मैं आपको कई समाधानों को गहराई से समझाऊँगा और हर समाधान के फायदे और कमियाँ बताऊँगा, आखिर रोम पहुँचने के रास्ते कई हैं।

1. सीधे स्ट्रिंग में बदलें：सीधा और सरल, फिर भी प्रभावी

ऐसी समस्या सामने आने पर सबसे पहले हमारे मन में निश्चित ही सबसे सीधा और सरल तरीका आता है：सीधे Long प्रकार का डेटा रूपांतरण को स्ट्रिंग बना दें तो हो जाएगा! चूँकि JavaScript फ़्लोटिंग-पॉइंट संख्याओं का अंधभक्त है，तो चलिए समस्या उसी को वापस सौंपकर उससे कहें：“तुम्हें बस इसे एक स्ट्रिंग मानना है，इसकी लंबाई की चिंता मत करो！”

यह कैसे करें？दरअसल बहुत सरल है, उपयोग करें Jackson द्वारा प्रदान किया गया ToStringSerializer，हम आसानी से Long स्ट्रिंग में बदलें।

import com.fasterxml.jackson.databind.annotation.JsonSerialize;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;

public class UserDto {
    @JsonSerialize(using = ToStringSerializer.class)
    private Long id;
    // 其他字段
}

इस तरह, जब बैकएंड लौटाता है UserDto के समय，Long प्रकार का id स्ट्रिंग के रूप में सीरियलाइज़ होगा，और फ़्रंटएंड को भी स्ट्रिंग ही प्राप्त होगी，जिससे परिशुद्धता की समस्या आसानी से हल हो जाएगी।मानो JavaScript के माथे पर एक पर्ची चिपका दी हो：“यह एक स्ट्रिंग है，तुम्हें इसकी चिंता करने की ज़रूरत नहीं！”

2. फ़्रंटएंड में उपयोग BigInt：बड़ी संख्याओं की गणना भी सटीक बनाएँ

बेशक, सीधा-सादा तरीका हर परिस्थिति के लिए उपयुक्त नहीं होता। कल्पना कीजिए, यदि फ़्रंटएंड को इस ID पर कोई गणितीय संक्रिया करनी हो, तो उसे सीधे स्ट्रिंग में बदल देना ठीक नहीं होगा। तो फ़्रंटएंड इन “अत्यधिक लंबी” ID को कैसे संभाले？

सौभाग्य से，JavaScript पूरी तरह बेकार भी नहीं था। इसमें जोड़ा गया BigInt इसके बाद，JavaScript आख़िरकार अब वह केवल दशमलव बिंदुओं से खेलने वाला मूर्ख नहीं रहा।BigInt एक नया आदिम डेटा प्रकार है, जिसे विशेष रूप से मनचाही परिशुद्धता वाले पूर्णांकों को संभालने के लिए बनाया गया है। आप ऐसा कर सकते हैं：

const id = BigInt("9223372036854775807");
console.log(id + 1n); // 输出：9223372036854775808n

इस तरह, आप फ़्रंटएंड पर सटीक रूप से संभाल सकते हैं Long प्रकार के डेटा, जिससे सटीकता खोने की समस्या से बचा जा सके। बेशक, यहाँ एक छोटी-सी बात ध्यान रखें：BigInt सभी ब्राउज़र इसका समर्थन नहीं करते, इसलिए आपको सुनिश्चित करना होगा कि आपका अनुप्रयोग परिवेश इसके अनुकूल हो।

3. अनुकूलित सीरियलाइज़ेशन：जटिल समस्या को सरल बनाना

हालाँकि ऊपर दिए गए तरीके अधिकांश समस्याएँ हल कर सकते हैं, लेकिन कभी-कभी ऐसे परिदृश्य आते हैं जहाँ अधिक सूक्ष्म नियंत्रण की आवश्यकता होती है। ऐसे समय में，Jackson का अनुकूलित सीरियलाइज़र तब काम आता है।

हम एक कस्टम सीरियलाइज़र लिखकर आवश्यकता के अनुसार लचीले ढंग से नियंत्रित कर सकते हैं Long प्रकार के फ़ील्ड की सीरियलाइज़ेशन प्रक्रिया। उदाहरण के लिए, सीरियलाइज़ेशन करते समय हम तय कर सकते हैं कि क्या Long स्ट्रिंग में बदलें, या विशिष्ट परिस्थितियों के अनुसार अलग-अलग प्रसंस्करण करें：

import com.fasterxml.jackson.core.JsonGenerator;
import com.fasterxml.jackson.databind.JsonSerializer;
import com.fasterxml.jackson.databind.SerializerProvider;

import java.io.IOException;

public class CustomLongSerializer extends JsonSerializer<Long> {

    @Override
    public void serialize(Long value, JsonGenerator gen, SerializerProvider serializers) throws IOException {
        if (value != null) {
            gen.writeString(value.toString());
        }
    }
}

फिर जहाँ आवश्यकता हो, वहाँ इस कस्टम सीरियलाइज़र का उपयोग करें：

import com.fasterxml.jackson.databind.annotation.JsonSerialize;

public class UserDto {
    @JsonSerialize(using = CustomLongSerializer.class)
    private Long id;
    // 其他字段
}

इस तरह，आप पूरी सीरियलाइज़ेशन प्रक्रिया को नियंत्रित कर सकते हैं，और सुनिश्चित कर सकते हैं कि हर एक Long सभी को आपकी इच्छानुसार संसाधित किया जा सकता है। बेशक, यह तरीका लचीला तो है, लेकिन थोड़ा जटिल भी है, इसमें कोड की कुछ अतिरिक्त पंक्तियाँ लिखनी पड़ती हैं और रखरखाव की लागत भी बढ़ सकती है।

4. वैश्विक स्तर पर प्रबंधन：समय और मेहनत बचाने वाला समाधान

यदि आप हर फ़ील्ड पर एनोटेशन कॉन्फ़िगर करने की परेशानी से बचते हुए इस समस्या को वैश्विक स्तर पर हल करना चाहते हैं，तो वैश्विक कॉन्फ़िगरेशन पर विचार कर सकते हैं ObjectMapper। इसमें Spring Boot में वैश्विक रूप से कॉन्फ़िगर करें ObjectMapper，आप सभी को Long प्रकार वाले फ़ील्ड सभी अपने-आप स्ट्रिंग में बदल जाते हैं।

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.module.SimpleModule;

@Configuration
public class JacksonConfig {

    @Bean
    public ObjectMapper objectMapper() {
        ObjectMapper mapper = new ObjectMapper();
        SimpleModule module = new SimpleModule();
        module.addSerializer(Long.class, ToStringSerializer.instance);
        module.addSerializer(Long.TYPE, ToStringSerializer.instance);
        mapper.registerModule(module);
        return mapper;
    }
}

एक बार व्यवस्था कर देने पर हमेशा के लिए निश्चिंत हो सकते हैं। किसी फ़ील्ड के लिए सीरियलाइज़र कॉन्फ़िगर करना भूल जाने की चिंता नहीं रहती, और पूरा प्रोजेक्ट सटीकता खोए बिना काम करने का आनंद ले सकता है। बेशक, वैश्विक कॉन्फ़िगरेशन इस्तेमाल करते समय ध्यान रखें कि यह कुछ ऐसे Long फ़ील्ड, इसलिए सावधानी से विचार करना आवश्यक है।

वास्तविक उदाहरण：अनेक उतार-चढ़ाव के बीच Bug सुलझाने का सफ़र

इन समाधानों के वास्तविक प्रभाव को बेहतर ढंग से समझाने के लिए, मैं एक वास्तविक परियोजना की कहानी साझा करता हूँ। इस परियोजना में उपयोगकर्ता ID का प्रबंधन शामिल था। उपयोगकर्ताओं की संख्या बहुत अधिक होने के कारण, बैकएंड ने अपनाया Long प्रकार का अद्वितीय पहचानकर्ता। परियोजना के लाइव होने के कुछ ही दिनों में उपयोगकर्ताओं की प्रतिक्रिया आने लगी: “मेरी ID का रूप कैसे बदल गया?”।

पहला चरण：समस्या की जड़ का पता लगाना

हमने पहले फ़्रंटएंड कोड जाँचा और पाया JavaScript का Number प्रकार वास्तव में इस 19 अंकों की लंबी संख्या को सटीक रूप से व्यक्त नहीं कर सकता, जिससे सटीकता खो गई। फिर हमने बैकएंड का कोड देखा और पाया कि यद्यपि Long प्रकार का डेटा बैकएंड में सही होता है, लेकिन REST के माध्यम से API फ़्रंटएंड को लौटाते समय संख्या की परिशुद्धता खो गई।

दूसरा चरण：उपयुक्त समाधान चुनें

समस्या को जल्दी हल करने के लिए, हमने पहले इसे अपनाने का निर्णय लिया @JsonSerialize(using = ToStringSerializer.class) यह सरल और प्रभावी तरीका। इसके माध्यम से हमने फ़्रंटएंड को ऐसे अंक मिलने से सफलतापूर्वक रोका जिनकी परिशुद्धता खो चुकी हो।

लेकिन समस्या पूरी तरह हल नहीं हुई थी।आगे की आवश्यकताओं में，फ़्रंटएंड को ID पर कुछ संक्रियाएँ करनी थीं，जैसे उपयोगकर्ताओं की ID को क्रमबद्ध करना।ऐसे समय में स्ट्रिंग कुछ असमर्थ साबित होने लगी।

तीसरा चरण：उपयोग करें BigInt फ़्रंटएंड की गणना संबंधी समस्या हल करना

इसलिए, हमने फ्रंटएंड में शामिल करने का निर्णय लिया BigInt। उपयोग करके BigInt，फ़्रंटएंड इन अत्यंत लंबी ID को सटीक रूप से संग्रहीत करने के साथ आवश्यक गणितीय गणनाएँ भी कर सकता है। परीक्षण में यह तरीका सभी प्रमुख ब्राउज़रों पर अच्छा काम करता पाया गया, इसकी एकमात्र कमी कुछ पुराने ब्राउज़र संस्करणों के लिए कमजोर समर्थन है।

चौथा चरण：अंतिम वैश्विक कॉन्फ़िगरेशन

भविष्य में ऐसी समस्याएँ दोबारा होने से रोकने के लिए, हमने यह निर्णय लिया कि ToStringSerializer इसे वैश्विक रूप से प्रभावी करने के लिए कॉन्फ़िगर करें। इससे सभी Long प्रकार के डेटा को क्रमबद्ध करते समय स्वतः स्ट्रिंग में बदल दिया जाता है, जिससे फ़्रंटएंड के डेटा की सटीकता सुनिश्चित होती है और कोड में दोहराए गए कॉन्फ़िगरेशन भी घटते हैं।

समापन：परिशुद्धता हानि का अंत करने वाला

इस उदाहरण से देखा जा सकता है कि, हालाँकि Long प्रकार की परिशुद्धता खोने की समस्या देखने में सरल लगती है, लेकिन वास्तविक परियोजनाओं में कई छिपे जोखिम पैदा कर सकती है। विभिन्न समाधानों की तुलना और परीक्षण के बाद, अंततः हमें अपनी परियोजना के लिए सबसे उपयुक्त समाधान मिला।

आशा है कि यह हास्यपूर्ण और विस्तृत ब्लॉग आपको सँभालते समय Long प्रकार की परिशुद्धता खोने की समस्या आने पर अनावश्यक भटकाव से बच सकें। यदि आपका भी ऐसा कोई अनुभव है, तो टिप्पणी अनुभाग में अपनी कहानी साझा करें; शायद आपका अनुभव अन्य डेवलपरों को और प्रेरणा दे सके।

अंत में, याद रखें, कोड भी जीवन जैसा है। कभी-कभार कुछ “खो जाना” डरने की बात नहीं；ज़रूरी है सही “सीरियलाइज़र” ढूँढ़ना, जो उसे फिर सही राह पर ले आए। कामना है कि आपके कोड की “सटीकता” फिर कभी न खोए, वह सटीक रहे और बिना अड़चन चलता रहे！