यूनिकोड समतुल्यता
यूनिकोड एक जटिल जानवर है। इसकी कई अजीबोगरीब विशेषताओं में से एक यह है कि कोडपॉइंट के विभिन्न क्रम समान हो सकते हैं। लीगेसी एन्कोडिंग में ऐसा नहीं है। उदाहरण के लिए, लैटिन 1 में, केवल एक चीज जो 'ए' के बराबर है, वह है 'ए' और केवल एक चीज जो 'ए' के बराबर है, वह है 'ए'। यूनिकोड में, हालांकि, विशेषक चिह्नों वाले वर्णों को अक्सर (विशेष वर्ण के आधार पर) अलग-अलग तरीकों से एन्कोड किया जा सकता है:या तो एक पूर्वनिर्मित चरित्र के रूप में, जैसा कि LATIN1 जैसे विरासत एन्कोडिंग में किया गया था, या विघटित, जिसमें आधार वर्ण शामिल है। ' यहाँ विशेषक चिह्न ◌̈ के बाद। इसे विहित तुल्यता . कहा जाता है . इन दोनों विकल्पों के होने का लाभ यह है कि आप एक ओर, विरासती एनकोडिंग से वर्णों को आसानी से परिवर्तित कर सकते हैं और दूसरी ओर, यूनिकोड में प्रत्येक उच्चारण संयोजन को एक अलग वर्ण के रूप में जोड़ने की आवश्यकता नहीं है। लेकिन यह योजना यूनिकोड का उपयोग करने वाले सॉफ़्टवेयर के लिए चीजों को और अधिक कठिन बना देती है।
जब तक आप केवल परिणामी चरित्र को देख रहे हैं, जैसे कि ब्राउज़र में, आपको कोई अंतर नहीं दिखना चाहिए और यह आपके लिए कोई मायने नहीं रखता। हालांकि, एक डेटाबेस सिस्टम में जहां स्ट्रिंग्स को खोजना और छांटना मौलिक और प्रदर्शन-महत्वपूर्ण कार्यक्षमता है, चीजें जटिल हो सकती हैं।
सबसे पहले, उपयोग में आने वाले कोलेशन लाइब्रेरी को इसके बारे में पता होना चाहिए। हालांकि, ग्लिबक सहित अधिकांश सिस्टम सी पुस्तकालय नहीं हैं। तो ग्लिब में, जब आप 'ä' खोजते हैं, तो आपको 'ä' नहीं मिलेगा। देखो, वहां मैंने क्या किया था? दूसरा अलग तरह से एन्कोड किया गया है लेकिन शायद आपको पढ़ने के लिए वही दिखता है। (कम से कम मैंने इसे ऐसे ही दर्ज किया है। हो सकता है कि इसे आपके ब्राउज़र के रास्ते में कहीं बदल दिया गया हो।) भ्रमित करने वाला। यदि आप संयोजन के लिए आईसीयू का उपयोग करते हैं, तो यह काम करता है और पूरी तरह से समर्थित है।
दूसरा, जब PostgreSQL समानता के लिए स्ट्रिंग्स की तुलना करता है, तो यह केवल बाइट्स की तुलना करता है, यह इस संभावना को ध्यान में नहीं रखता है कि एक ही स्ट्रिंग को विभिन्न तरीकों से दर्शाया जा सकता है। यूनिकोड का उपयोग करते समय यह तकनीकी रूप से गलत है, लेकिन यह एक आवश्यक प्रदर्शन अनुकूलन है। उस पर काम करने के लिए, आप गैर-निर्धारक कोलाज . का उपयोग कर सकते हैं , PostgreSQL 12 में पेश की गई एक सुविधा। इस तरह से घोषित एक संयोजन नहीं . होगा बस बाइट्स की तुलना करें
लेकिन अलग-अलग तरीकों से एन्कोड किए जा सकने वाले स्ट्रिंग्स की तुलना या हैश करने में सक्षम होने के लिए कोई भी आवश्यक प्रीप्रोसेसिंग करेगा। उदाहरण:
CREATE COLLATION ndcoll (provider = icu, locale = 'und', deterministic = false);
सामान्यीकरण फ़ॉर्म
इसलिए जबकि कुछ यूनिकोड वर्णों को एन्कोड करने के लिए अलग-अलग वैध तरीके हैं, कभी-कभी उन सभी को एक सुसंगत रूप में परिवर्तित करना उपयोगी होता है। इसे सामान्यीकरण . कहा जाता है . दो सामान्यीकरण फ़ॉर्म हैं :पूरी तरह से रचित , जिसका अर्थ है कि हम सभी कोडपॉइंट अनुक्रमों को यथासंभव पहले से तैयार वर्णों में परिवर्तित करते हैं, और पूरी तरह से विघटित , जिसका अर्थ है कि हम जितना संभव हो सके सभी कोडपॉइंट्स को उनके घटक टुकड़ों (अक्षर प्लस उच्चारण) में परिवर्तित करते हैं। यूनिकोड शब्दावली में, इन रूपों को क्रमशः एनएफसी और एनएफडी के रूप में जाना जाता है। इसमें कुछ और विवरण हैं, जैसे सभी संयोजन वर्णों को एक विहित क्रम में रखना, लेकिन यह सामान्य विचार है। मुद्दा यह है कि, जब आप यूनिकोड स्ट्रिंग को सामान्यीकरण रूपों में से एक में परिवर्तित करते हैं, तो आप एन्कोडिंग वेरिएंट के बारे में चिंता किए बिना उनकी तुलना या हैश कर सकते हैं। आप किसका उपयोग करते हैं, इससे कोई फर्क नहीं पड़ता, जब तक कि पूरी प्रणाली एक पर सहमत होती है।
व्यवहार में, अधिकांश विश्व एनएफसी का उपयोग करता है। और इसके अलावा, कई प्रणालियाँ इस कारण दोषपूर्ण हैं कि वे गैर-एनएफसी यूनिकोड को सही ढंग से नहीं संभालती हैं, जिसमें अधिकांश सी पुस्तकालयों की संयोजन सुविधाएं, और यहां तक कि डिफ़ॉल्ट रूप से पोस्टग्रेएसक्यूएल भी शामिल है, जैसा कि ऊपर उल्लेख किया गया है। इसलिए यह सुनिश्चित करना कि सभी यूनिकोड को एनएफसी में बदल दिया जाए, बेहतर इंटरऑपरेबिलिटी सुनिश्चित करने का एक अच्छा तरीका है।
PostgreSQL में सामान्यीकरण
PostgreSQL 13 में अब यूनिकोड सामान्यीकरण से निपटने के लिए दो नई सुविधाएं शामिल हैं:सामान्यीकरण के लिए परीक्षण करने के लिए एक फ़ंक्शन, और एक सामान्यीकरण रूप में कनवर्ट करने के लिए। उदाहरण के लिए:
SELECT 'foo' IS NFC NORMALIZED;
SELECT 'foo' IS NFD NORMALIZED;
SELECT 'foo' IS NORMALIZED; -- NFC is the default
SELECT NORMALIZE('foo', NFC);
SELECT NORMALIZE('foo', NFD);
SELECT NORMALIZE('foo'); -- NFC is the default (वाक्यविन्यास SQL मानक में निर्दिष्ट है।)
एक विकल्प यह है कि इसे किसी डोमेन में उपयोग किया जाए, उदाहरण के लिए:
CREATE DOMAIN norm_text AS text CHECK (VALUE IS NORMALIZED);
ध्यान दें कि मनमाना पाठ का सामान्यीकरण पूरी तरह से सस्ता नहीं है। इसलिए इसे समझदारी से और केवल वहीं लागू करें जहां यह वास्तव में मायने रखता है।
यह भी ध्यान दें कि संयोजन के तहत सामान्यीकरण बंद नहीं होता है। इसका मतलब है कि दो सामान्यीकृत तारों को जोड़ने से हमेशा सामान्यीकृत स्ट्रिंग नहीं होती है। इसलिए यदि आप इन कार्यों को सावधानीपूर्वक लागू करते हैं और यह भी जांचते हैं कि आपका सिस्टम केवल सामान्यीकृत स्ट्रिंग्स का उपयोग करता है, तब भी वे वैध संचालन के दौरान "रेंगना" कर सकते हैं। तो बस यह मानते हुए कि गैर-सामान्यीकृत तार नहीं हो सकते विफल हो जाएंगे; इस मुद्दे से ठीक से निपटा जाना चाहिए।
संगतता वर्ण
सामान्यीकरण के लिए एक और उपयोग का मामला है। विभिन्न विरासत और संगतता उद्देश्यों के लिए यूनिकोड में अक्षरों और अन्य वर्णों के कुछ वैकल्पिक रूप शामिल हैं। उदाहरण के लिए, आप Fraktur लिख सकते हैं:
SELECT '𝔰𝔬𝔪𝔢𝔫𝔞𝔪𝔢';
अब कल्पना करें कि आपका एप्लिकेशन उपयोगकर्ता नाम या ऐसे अन्य पहचानकर्ता निर्दिष्ट करता है, और 'somename' नाम का एक उपयोगकर्ता है और दूसरा नाम '𝔰𝔬𝔪𝔢𝔫𝔞𝔪𝔢' . है . यह कम से कम भ्रमित करने वाला होगा, लेकिन संभवतः एक सुरक्षा जोखिम होगा। ऐसी समानताओं का उपयोग अक्सर फ़िशिंग हमलों, नकली URL और इसी तरह की चिंताओं में किया जाता है। तो यूनिकोड में दो अतिरिक्त सामान्यीकरण रूप हैं जो इन समानताओं को हल करते हैं और ऐसे वैकल्पिक रूपों को एक विहित आधार पत्र में परिवर्तित करते हैं। इन रूपों को एनएफकेसी और एनएफकेडी कहा जाता है। वे अन्यथा क्रमशः एनएफसी और एनएफडी के समान हैं। उदाहरण के लिए:
=> select normalize('𝔰𝔬𝔪𝔢𝔫𝔞𝔪𝔢', nfkc);
normalize
-----------
somename
फिर से, चेक बाधाओं का उपयोग करना शायद एक डोमेन के हिस्से के रूप में उपयोगी हो सकता है:
CREATE DOMAIN username AS text CHECK (VALUE IS NFKC NORMALIZED OR VALUE IS NFKD NORMALIZED);
(वास्तविक सामान्यीकरण संभवतः यूजर इंटरफेस फ्रंटएंड में किया जाना चाहिए।)
ऐसी चिंताओं को दूर करने के लिए स्ट्रिंग्स के उपचार के लिए RFC 3454 भी देखें।
सारांश
यूनिकोड तुल्यता के मुद्दों को अक्सर बिना परिणाम के नजरअंदाज कर दिया जाता है। कई संदर्भों में, अधिकांश डेटा NFC रूप में होता है, इसलिए कोई समस्या नहीं होती है। हालांकि, इन मुद्दों को अनदेखा करने से अजीब व्यवहार हो सकता है, स्पष्ट रूप से लापता डेटा, और कुछ स्थितियों में सुरक्षा जोखिम हो सकते हैं। इसलिए डेटाबेस डिजाइनरों के लिए इन मुद्दों के बारे में जागरूकता महत्वपूर्ण है, और इस लेख में वर्णित उपकरणों का उपयोग उनसे निपटने के लिए किया जा सकता है।
