RFC 9839 और समस्याग्रस्त Unicode

• RFC 9839 सॉफ़्टवेयर डेवलपमेंट के दौरान टेक्स्ट फ़ील्ड में शामिल हो सकने वाले समस्याग्रस्त Unicode characters को स्पष्ट रूप से परिभाषित करता है
• यह RFC अलग-अलग भाषाओं और लाइब्रेरीज़ में इन characters को संभालने में एकरूपता की कमी से पैदा होने वाली समस्याओं पर बात करता है
• 9839 कम समस्याग्रस्त तीन subsets प्रस्तावित करता है, जिनका ज़रूरत के अनुसार चयनात्मक उपयोग किया जा सकता है
• मौजूदा PRECIS framework की तुलना में इसे लागू करना अधिक आसान और सरल है
• RFC 9839 के लिए Go language library भी जारी की गई है, जिससे व्यावहारिक उपयोग में मदद मिलती है

---

पृष्ठभूमि और RFC 9839 का अवलोकन

• Unicode लगभग सभी टेक्स्ट डेटा प्रोसेसिंग में एक मानक के रूप में इस्तेमाल होता है
• लेकिन वास्तविक डेटा संरचनाओं या प्रोटोकॉल डिज़ाइन में सभी Unicode characters को अनुमति देने से समस्याएँ पैदा होती हैं
• Paul Hoffman और लेखक ने बार-बार सामने आने वाली Unicode समस्याओं के लिए स्पष्ट मानदंड देने के उद्देश्य से IETF को individual draft जमा किया
• 2 वर्षों की चर्चा के बाद इसे आधिकारिक मानक के रूप में अपनाया गया और RFC 9839 के रूप में प्रकाशित किया गया
• यह दस्तावेज़ समस्याग्रस्त character types, वे क्यों समस्या हैं (तकनीकी और मानकीकरण कारण), और उपयोगकर्ता जिन तीन subsets में से चुन सकते हैं, उनका विस्तार से वर्णन करता है

RFC 9839 की मुख्य बातें

• सॉफ़्टवेयर और नेटवर्क वातावरण में text fields डिज़ाइन करते समय यह एक आवश्यक संदर्भ दस्तावेज़ है
• RFC 9839 10 पेज का है, इसलिए IETF मानक दस्तावेज़ों में यह अपेक्षाकृत संक्षिप्त है
• इसे मुख्य रूप से सॉफ़्टवेयर डेवलपर्स और नेटवर्क इंजीनियर्स को ध्यान में रखकर आसान भाषा में समझाया गया है

समस्याग्रस्त Unicode characters के उदाहरण

• उदाहरण के लिए JSON के username फ़ील्ड में नीचे जैसा string आ सकता है

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• हर code point की समस्या
  • U+0000 : अर्थहीन NULL character, जो कुछ programming languages के व्यवहार में बाधा डालता है
  • U+0089 : C1 control code (CHARACTER TABULATION WITH JUSTIFICATION), जिसका व्यवहार जटिल है और एकसमान नहीं है
  • U+DEAD : unpaired surrogate character, जो UTF-16 की सीमाओं से उत्पन्न समस्या है। इससे आदर्श न होने वाला डेटा बनता है
  • \uD9BF\uDFFF (वास्तविक U+7FFFF) : Noncharacter, जिसका आदान-प्रदान मानक के अनुसार निषिद्ध है
• ऐसे code points डेटा संरचनाओं और प्रोटोकॉल के भीतर consistent handling को असंभव बनाते हैं और अप्रत्याशित errors पैदा करते हैं
• RFC 9839 इन समस्याग्रस्त characters को औपचारिक रूप से परिभाषित करता है और किन प्रकारों को बाहर करना है, यह स्पष्ट रूप से बताता है

JSON का डिज़ाइन और उसकी सीमाएँ

• इसके लिए JSON के निर्माता Doug Crockford ज़िम्मेदार नहीं हैं
• यह ऐसे समय में डिज़ाइन किया गया था जब Unicode पर्याप्त परिपक्व नहीं था, इसलिए character set को कड़ाई से सीमित नहीं किया जा सका
• अब मानक बदला नहीं जा सकता, इसलिए अनुभव के आधार पर समस्याग्रस्त characters को बाहर रखने का तरीका आवश्यक है

IETF के PRECIS framework से अंतर

• 2025 के RFC 9839 से पहले भी IETF ने RFC 8264 (PRECIS Framework) जैसे विभिन्न मानक उपलब्ध कराए थे
  • यह framework internationalized strings की तैयारी, लागू करने और तुलना करने के तरीकों को विस्तार से बताता है
  • 43 पेज का यह दस्तावेज़ पृष्ठभूमि विवरण और समाधान दोनों में व्यापक है
• PRECIS की कमी यह है कि यह Unicode versions पर बहुत अधिक निर्भर है, और जटिल होने के कारण इसे लागू करना कठिन है
• RFC 9839 संक्षिप्त और व्यावहारिकता-केंद्रित है, इसलिए नए प्रोटोकॉल परिभाषित करते समय इसे तेज़ी से अपनाना आसान है

RFC 9839 के subsets और उपयोग के उदाहरण

• 9839 तीन व्यावहारिक subsets (scalars, XML, assignables) प्रस्तुत करता है
• हर subset में बाहर किए जाने वाले समस्याग्रस्त characters की सीमा थोड़ी अलग है
• नीचे प्रमुख data formats और RFC 9839 के subsets समस्याग्रस्त characters को कैसे संभालते हैं, उसका सार दिया गया है
  • CBOR, TOML, XML, YAML जैसे कुछ formats surrogate या control characters को आंशिक रूप से बाहर करते हैं
  • I-JSON surrogate और noncharacter को बाहर करता है
  • सामान्य JSON, Protobufs इन्हें बाहर नहीं करते
  • XML, YAML charset की विशेषताओं के कारण noncharacter/control codes को केवल आंशिक रूप से बाहर करते हैं
    • संदर्भ: XML और YAML Basic Multilingual Pane के बाहर के noncharacter को बाहर नहीं करते

Go language के लिए RFC 9839 लाइब्रेरी

• RFC 9839 के तीनों subsets के लिए character validation सपोर्ट करने वाली एक छोटी Go लाइब्रेरी जारी की गई है
• इसका पर्याप्त परीक्षण किया जा चुका है, हालांकि optimization अभी जारी है
• वास्तविक कार्यस्थल में testing और feedback का स्वागत है

RFC 9839 का महत्व और कार्य-प्रक्रिया

• RFC 9839 को सह-लेखकों और कई दौर के feedback के साथ 15 से अधिक draft revisions के बाद आधिकारिक रूप से प्रकाशित किया गया
• समुदाय के अनेक विशेषज्ञों की चर्चा और योगदान के जरिए यह प्रारंभिक मसौदे की तुलना में कहीं अधिक परिपक्व दस्तावेज़ बन गया
• योगदानकर्ताओं का उल्लेख “Acknowledgements” सेक्शन में किया गया है

RFC individual submission का अनुभव

• RFC 9839 को individual submission के रूप में आगे बढ़ाया गया
• Working Group के माध्यम से होने वाले पारंपरिक तरीके की तुलना में मेहनत और प्रक्रिया का बोझ अधिक है
• Working Group में भागीदारी के अनुभव की तुलना में पारंपरिक तरीका अधिक कुशल और अनुशंसित माना गया है