2008-11-18 18 views
14

यह ज्यादातर सैद्धांतिक प्रश्न है जो मैं बहुत उत्सुक हूं। (मैं इसे स्वयं या कुछ भी कोडिंग करके ऐसा करने की कोशिश नहीं कर रहा हूं, मैं पहियों को पुनर्निर्मित नहीं कर रहा हूं।)यूनिकोड में स्ट्रिंग्स को अपरकेस/लोअरकेस में कैसे सेट करते हैं?

मेरा प्रश्न यह है कि समकक्ष की अपरकेस/लोअरकेस तालिका यूनिकोड के लिए कैसे काम करती है।

उदाहरण के लिए, अगर मुझे इसे एएससीआईआईआई में करना है, तो मैं एक चरित्र लेता हूं, और यदि यह [ए-जेड] रेंज के साथ आता है, तो मैं ए और ए के बीच का अंतर जोड़ूंगा।

यदि यह उस सीमा पर नहीं आता है, तो मेरे पास 10 या इतने उच्चारण वाले वर्णों के लिए एक छोटी समकक्ष तालिका होगी।

हालांकि, मेरा अनुमान है कि वहाँ यूनिकोड में equivalences निर्दिष्ट करने के लिए एक बेहतर तरीका है कि (या, मैं सिर्फ 256 प्रविष्टियों, जिनमें से अधिकांश इनपुट के रूप में ही होगा के साथ एक पूर्ण तुल्यता सरणी हो सकता था), यह देखते हुए कि सैकड़ों हजार वर्ण हैं, और सैद्धांतिक रूप से, एक नई भाषा या पात्रों के सेट को जोड़ा जा सकता है (और मुझे उम्मीद है कि जब ऐसा होता है तो आपको खिड़कियों को पैच करने की आवश्यकता नहीं होगी)।

क्या विंडोज के पास प्रत्येक चरित्र के लिए एक बड़ी हार्ड-कोडेड समतुल्य तालिका है? या यह कैसे लागू किया जाता है?

एक संबंधित प्रश्न यह है कि SQL सर्वर यूनिकोड-आधारित उच्चारण-असंवेदनशील और केस-असंवेदनशील प्रश्नों को कैसे लागू करता है। क्या इसमें एक आंतरिक तालिका है जो बताती है कि è è ई È और Ë सभी "ई" के बराबर हैं?

तारों की तुलना करने की बात आने पर यह बहुत तेज नहीं लगता है।

यह इंडेक्स को जल्दी से कैसे एक्सेस करता है? क्या यह पहले से ही उस क्षेत्र के संयोजन के अनुरूप उनके "आधार" वर्णों में परिवर्तित मूल्यों को सूचीबद्ध करता है?

क्या कोई इन चीजों के लिए आंतरिक जानता है?

धन्यवाद!

+0

मुझे उम्मीद है कि यदि आप यूनिकोड में एक नया चरित्र सेट जोड़ते हैं तो आपको विंडोज़ पैच करने की आवश्यकता होगी, लेकिन यह बहुत कम प्राथमिकता पैच होगा, क्योंकि शुरुआत में कोई भी उन पात्रों का उपयोग नहीं करेगा। –

+0

"10 या उससे अधिक उच्चारण वाले पात्रों के लिए एक छोटी समतुल्य तालिका" - आपको यह समझना होगा कि "छोटा" का मतलब है कि इसका मतलब यह है कि इसका मतलब 100 गुना बड़ा है। –

+1

मुझे पूरी तरह से यकीन नहीं है कि मैं समझता हूं कि ई पर सभी प्रकार क्यों हैं कि मैं अपने कीबोर्ड के साथ आसानी से सभी बराबर "ई" टाइप नहीं कर सकता। मैं इसे डेटाबेस बिंदु दृश्य से समझ सकता हूं (विशेष उच्चारणों को अनदेखा करने के लिए खोजना) लेकिन एक भाषा परिप्रेक्ष्य से वे सभी अलग-अलग वर्ण हैं ... –

उत्तर

11

एक मैपिंग फ़ाइल है जिसमें सभी केस मैपिंग्स हैं जिनमें 1: 1 मैपिंग अनुपात है। आम तौर पर ऑपरेटिंग सिस्टम/फ्रेमवर्क/लाइब्रेरी यूनिकोड के एक विशिष्ट संस्करण का समर्थन करते हैं, और चूंकि इस मामले में मैपिंग्स फ़ाइल का संस्करण होता है, इसलिए आपको यूनिकोड के अपने संस्करण के लिए मैपिंग्स मिलेंगे जो आपके विशेष ओएस/फ्रेमवर्क/लाइब्रेरी/जो भी समर्थन के लिए हुआ था।

यूनिकोड मामले मैपिंग के बारे में अधिक जानकारी के लिए देखें: http://www.unicode.org/faq/casemap_charprop.html

3

अधिकांश लेखन प्रणालियों अलग अपरकेस और लोअरकेस वर्णों की जरूरत नहीं है। विकिपीडिया के अनुसार, अपवादों में "रोमन, ग्रीक, सिरिलिक और अर्मेनियाई वर्णमाला" शामिल हैं।

तो चिंता करने के लिए कई पत्र नहीं हैं। दिखाता है कि वर्णों की बड़ी श्रृंखला लोअरकेस समतुल्य प्राप्त करने के लिए अपरकेस वर्ण में 1 जोड़ने की एक सरल योजना का पालन करती है (हालांकि निश्चित रूप से कुछ अपवाद हैं)।

16

मैं इस प्रश्न के एमएस एसक्यूएल सर्वर भाग को संबोधित करने जा रहा हूं, लेकिन "सही" उत्तर वास्तव में भाषा (ओं) समर्थित और एप्लिकेशन पर निर्भर करता है।

जब आप SQL सर्वर में कोई तालिका बनाते हैं, तो प्रत्येक टेक्स्ट फ़ील्ड में या तो एक स्पष्ट या स्पष्ट रूप से निर्दिष्ट संयोजन होता है। यह क्रमबद्ध क्रम और तुलना व्यवहार दोनों को प्रभावित करता है। अधिकांश अंग्रेजी (यूएस) लोकेशंस के लिए डिफ़ॉल्ट, लैटिन 1_General_CI_AS, या लैटिन 1, केस-असंवेदनशील, एक्सेंट-सेंसिटिव है। इसका मतलब है कि, उदाहरण के लिए, ए = ए, लेकिन एक! = Ä और ए! = Ä।आप उच्चारण-असंवेदनशील (लैटिन 1_General_CI_AI) का भी उपयोग कर सकते हैं जो "ए" के सभी समेकित भिन्नताओं को बराबर मानता है।

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

आप प्रति डेटाबेस, प्रति तालिका, प्रति फ़ील्ड, और कुछ लागत, यहां तक ​​कि प्रति-क्वेरी के साथ संयोजन को बदल सकते हैं। मेरी समझ यह है कि इंडेक्स निर्दिष्ट कॉलेशन ऑर्डर के अनुसार सामान्यीकृत होते हैं, जिसका अर्थ है कि मूल रूप से सूचकांक मूल स्ट्रिंग का एक फ़्लैटेड संस्करण रखता है। उदाहरण के लिए, केस-असंवेदनशील कॉलेशन के साथ, ऐप्पल और सेब को सेब के रूप में संग्रहीत किया जाता है। खोज से पहले एक ही संयोजन के साथ क्वेरीज़ चपटे हैं।

जापानी में, सामान्यीकरण की एक और श्रेणी है, जहां पूर्णविड्थ और अर्धविड्थ वर्ण जैसे ア = ア, और कुछ मामलों में, दो अर्धविड्थ वर्ण एकल, अर्थात् समकक्ष चरित्र (バ = バ) तक चपटे होते हैं। अंत में, कुछ भाषाओं के लिए, समग्र पात्रों के साथ मोम की एक और गेंद होती है, जहां पृथक डाइक्रिटिक वर्ण अन्य पात्रों के साथ बनाये जा सकते हैं (उदाहरण के लिए umlaut एक चरित्र है, जो सरल रूप से बना है)। वियतनामी, थाई और कुछ अन्य भाषाओं में इस श्रेणी के बदलाव हैं। यदि एक कैनोलिक रूप है, तो यूनिकोड सामान्यीकरण रचनाकृत और विघटित रूपों को बराबर माना जाता है। यूनिकोड सामान्यीकरण आमतौर पर किसी भी तुलना किए जाने से पहले लागू होता है।

संक्षेप में, केस-असंवेदनशील तुलना के लिए, आप कुछ ऐसा करते हैं जैसे आप ASCII-range स्ट्रिंग की तुलना करते समय: "कम केस" (उदाहरण के लिए) की तुलना के बाएं और दाएं तरफ फ़्लैट करें, फिर तुलना करें एक बाइनरी सरणी के रूप में सरणी। अंतर यह है कि आपको 1) स्ट्रिंग को समान यूनिकोड फॉर्म (केसी या केडी) 2 पर सामान्यीकृत करें) उसी लोकल के नियमों के अनुसार स्ट्रिंग को सामान्य करें 3) उच्चारण के अनुसार उच्चारण को सामान्य करें संवेदनशीलता नियम 4) बाइनरी तुलना 4 के अनुसार तुलना करें) यदि लागू हो, तो सॉर्टिंग के मामले में, अतिरिक्त माध्यमिक और टर्नरी सॉर्टिंग नियमों का उपयोग करके तुलना करें, जिसमें "एम" से पहले "मैक" जैसी चीजों के समान चीजें शामिल हैं। कुछ भाषाओं में।

और हाँ, विंडोज इन सभी नियमों के लिए टेबल स्टोर करता है। आप सभी इंस्टॉलेशन में डिफ़ॉल्ट रूप से उन सभी को प्राप्त नहीं करते हैं, जब तक कि आप नियंत्रण पैनल से पूर्व एशियाई भाषा समर्थन और जटिल स्क्रिप्ट समर्थन के साथ उनके लिए समर्थन नहीं जोड़ते।

+1

वाह। काश मैं आपको अधिक वोट दे सकता हूं। धन्यवाद!! –

1

सही उत्तर थोड़ा और जटिल है, जो आप करने की कोशिश कर रहे हैं उसके आधार पर।

जब चरित्र तार की तुलना, छँटाई या अनुप्रयोगों खोज के लिए, का उपयोग करने के UTS #10: "Unicode Collation Algorithm". केस असंवेदनशीलता में निर्दिष्ट किया जाता सही एल्गोरिथ्म मिश्रण का हिस्सा है, लेकिन वहाँ एक कई पात्रों का प्रतिनिधित्व करने के विभिन्न तरीके हैं, और अनुप्रयोगों अक्सर इलाज के लिए की जरूरत है बराबर के रूप में विभिन्न प्रतिनिधित्व।

सॉर्टिंग नियम लोकेल-निर्भर हैं। यह मुख्य रूप से एक मुद्दा है जब आप किसी उपयोगकर्ता को प्रदर्शन के लिए परिणाम सॉर्ट कर रहे हैं। नियमों को अनदेखा करने से उपयोगकर्ताओं को निराशा हो सकती है और यहां तक ​​कि सुरक्षा भेद्यता भी हो सकती है।

यदि आप प्रदर्शन उद्देश्यों के लिए शब्दों को कैपिटल करने की कोशिश कर रहे हैं, तो नियम भी मुश्किल हो सकते हैं; एक से कई रूपांतरण और अन्य मुद्दे हैं। लोकेल के आधार पर, वही पत्र अलग-अलग पूंजीकरण कर सकता है। किसी शब्द में अक्षर की स्थिति एक अंतर डाल सकती है। "शीर्षक केस" की एक अलग धारणा भी है, जहां आप बस प्रत्येक शब्द के पहले अक्षर को कैपिटल करना चाहते हैं। कभी-कभी चरित्र का शीर्षक-मामला इसके ऊपरी मामले के समान नहीं होता है।

संबंधित मुद्दे