टी एल; डॉ
कोलाज़ के "विक्रेता-अज्ञेयवादी" दृष्टिकोण के रूप में ऐसी कोई चीज नहीं है, न ही "संस्करण-अज्ञेयवादी", क्योंकि उनके कार्यान्वयन - जिसमें पहलुओं को असंवेदनशील बनाया जा सकता है और उनके नामकरण सम्मेलनों - समय के साथ विक्रेता-विशिष्ट और परिवर्तन होते हैं। ।
यहां मैंने जो कुछ भी पाया है उसका एक सारांश है, और विवरण पंक्ति के नीचे लंबे खंड में हैं:
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collations
जैसा कि आप चार्ट में देख सकते हैं, सात में से दो RDBMS मूल रूप से "केस-संवेदी और " का समर्थन करते हैं से Collations के माध्यम से एक्सेंट-असंवेदनशील" ऑपरेशन का , हालांकि उनके अलग-अलग नामकरण परंपराएं (और कई अन्य कार्यात्मक अंतर) हैं।
एक RDBMS - PostgreSQL - मूल रूप से इस संयोजन का समर्थन नहीं करता है, लेकिन आप unaccent()ऐड-ऑन फ़ंक्शन के साथ लहजे को अलग करके भी इसे प्राप्त कर सकते हैं ।
पिछले चार आरडीबीएमएस, जिनमें से दो विकल्पों के लिए एक समान नामकरण सम्मेलन है, न तो मूल रूप से इस संयोजन का समर्थन करते हैं और न ही इसे पूरा करने के साधन के रूप में दिखाई देते हैं ताकि आप लहजे / विशेषांक के निशान को हटाने के लिए अपने स्वयं के फ़ंक्शन को लिख सकें। MySQL अपने स्वयं के Collations बनाने के लिए अनुमति देता है, लेकिन इसके लिए आवश्यक है कि आप इसे स्रोत नियंत्रण में जोड़ें और इसे अपने परीक्षण और परिनियोजन प्रक्रिया में शामिल करें ताकि इसे सभी वातावरणों में सभी सर्वरों पर लागू किया जा सके (लेकिन फिर भी एक बहुत अच्छा और लचीला विकल्प) । एसएपी एएसई का उल्लेख है कि एसएपी अतिरिक्त यूनिकोड प्रकार के आदेशों की आपूर्ति कर सकता है , लेकिन वे आपूर्ति करने के लिए तैयार हो सकते हैं, इसका कोई उल्लेख नहीं है।
के साथ संबंध:
क्या इसके लिए एक अच्छा कारण है या मेरा केवल एक दुर्लभ उपयोग मामला है?
मैं कह सकता हूं कि इस उत्तर के लिए शोध करने के दौरान, मैं MySQL के लिए केस-असंवेदनशील और उच्चारण-संवेदनशील लोगों के बहुत सारे उदाहरणों पर आया, लेकिन कुछ, यदि कोई हो, तो आपके वांछित संयोजन के लिए पूछ रहा है।
मैं केस-संवेदी लेकिन उच्चारण-असंवेदनशील टकराव का उपयोग करने के लिए एक खोज स्थिति चाहता था, लेकिन एक नहीं मिल सका।
...
यह सवाल विक्रेता / संस्करण अज्ञेय का है
आप अपनी खोज में असफल थे क्योंकि यह वास्तव में Collation विनिर्देश के आधार पर RDBMS की तलाश करने का कोई मतलब नहीं है। यही नहीं, कैसे Collations काम करते हैं। और जब आप इसे वेंडर-अज्ञेयवादी के रूप में अप्रोच करना चाहते हैं, तो वास्तविकता यह है कि Coll Collations - कम से कम जिस हिस्से के साथ हम बातचीत करते हैं - वे बहुत अधिक विक्रेता-विशिष्ट हैं, और हमेशा उस योजना में फिट नहीं होते हैं जिसे आप खोज रहे थे ।
स्ट्रिंग की तुलना और छँटाई अत्यधिक जटिल है, और इन नियमों को निष्पादित करने के विभिन्न तरीके हैं। एक विधि में मैपिंग है जो एक या अधिक नियमों को ध्यान में रखती है। इसलिए केस और लहजे के लिए संवेदनशील और असंवेदनशील के चार संयोजन चार अलग-अलग मैपिंग के बराबर होंगे। उदाहरण के लिए, आपने SQL सर्वर Collation नाम के लिए उस MSDN पृष्ठ पर इसे देखा था । यदि आप नीचे स्क्रॉल करते हैं, तो आप देखेंगे कि चार्ट का बायां स्तंभ नीचे है Sort Order ID। प्रत्येक Collation की एक अलग ID होती है: SQL_Latin1_General_Cp1_CI_AS= 52 जबकि SQL_Latin1_General_Cp1_CS_AS= 51, भले ही केस-सेंसिटिविटी में एकमात्र अंतर हो।
या, यह नियम-आधारित हो सकता है, जैसे कि यूनिकोड यूनिकोड कॉलेशन एल्गोरिथ्म (UCA) के माध्यम से क्या प्रदान करता है। इस दृष्टिकोण में, प्रत्येक चरित्र को डिफ़ॉल्ट रूप से, एक या एक से अधिक वज़न दिया जाता है। फिर, प्रत्येक संस्कृति / लोकेल में उन भारों में से किसी को भी ओवरराइड करने या नियमों को हटाने या नियमों को जोड़ने का विकल्प होता है। एल्गोरिथ्म किसी भी स्थानीय-विशिष्ट नियमों को ध्यान में रखता है, और फिर संभावित रूप से चुने गए विकल्पों (संवेदनशीलता, जो केस-संवेदी प्रकार, आदि) करते समय पहली बार आता है, के आधार पर उन वज़न को हेरफेर करता है। यह एक कारण है कि यूनिकोड छँटाई करना गैर-यूनिकोड छँटाई की तुलना में थोड़ा धीमा है।
यह समझने के लिए कि वास्तव में कितने विकल्प हैं (यानी वास्तविक जटिलता), इस डेमो को ICU (यूनिकोड के लिए अंतर्राष्ट्रीय घटक) परियोजना से देखें:
ICU Collation Demo
वहाँ 8 अलग विकल्प निर्दिष्ट करने के लिए कर रहे हैं, और उनमें से कुछ मिलान नाम विनिर्देश के अनेक तत्वों है कि आप (जैसे की सोच रहे हैं में प्रतिनिधित्व मिल CS, CI, AS, AI, आदि)। यह देखते हुए कि मैपिंग फ़ाइल दृष्टिकोण के उपयोग से कितनी भिन्नताएं हैं, जहां प्रत्येक संयोजन की अपनी आईडी होती है, जिसके परिणामस्वरूप कई हजारों फाइलें होती हैं। जब भी उन विशेष भाषाओं में परिवर्तन होते हैं, या जब बग मिलते हैं, तो उन फ़ाइलों में से कई को अपडेट करने की आवश्यकता होती है। शायद यही कारण है कि SQL Server 2012 में उन प्रकार के Collations के केवल 75 हैं (अर्थात जिनके नाम वाले नाम हैं SQL_)। इसलिए कोई संयोजन नहीं _CS_AI।
और यही कारण है कि आप UCA- आधारित Collations के लिए उस संयोजन को नहीं ढूंढ सके? खैर, SQL सर्वर 2012 में 3810 Collations हैं जो शुरू नहीं होते हैं SQL_, इसलिए कुल 3885 Collations हैं। यह सूची किसी वेब पेज पर पूरी तरह से एनुमरेट होने के लिए बहुत लंबी लगती है। लेकिन यह पूरी तरह से स्पष्ट नहीं करता है कि आप अन्य विक्रेताओं के लिए इस संयोजन को क्यों नहीं ढूंढ सके।
जो पहले से ही उल्लेख किया गया है (यानी लागू करने के लिए बहुत सारे संयोजन, और सूची में बहुत अधिक कार्यान्वयन) से परे, आपको अभी भी विक्रेता-विशिष्ट कार्यान्वयन के साथ संघर्ष करने की आवश्यकता है। अर्थ: सभी विक्रेता उन सभी विकल्पों को पूरा करने की अनुमति नहीं देते हैं, और पहले स्थान पर Collations के लिए कोई मानक नामकरण सम्मेलन नहीं है। इसके अलावा, सभी विक्रेता कॉलिंग के एक भाग के रूप में छँटाई विकल्पों को नहीं देखते हैं: पोस्टग्रेज़क्यूएल कोलाज़ेशन चुने हुए लोकेल के लिए डिफ़ॉल्ट ऑर्डर कर रहे हैं, और आपको ILIKEकेस-असंवेदनशील तुलना प्राप्त करने के लिए उपयोग करने की आवश्यकता है । विक्रेता-विशिष्ट जानकारी के लिए नीचे देखें।
SQL सर्वर (Microsoft)
उन दो MSDN दस्तावेज़ीकरण पृष्ठों पर जो आप देख रहे हैं, उसके बीच का अंतर और प्रश्न पर एक टिप्पणी में @MartinSmith द्वारा प्रदान की गई क्वेरी (नीचे थोड़ा संशोधित):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
यह है कि उन दो MSDN पृष्ठ विशेष रूप से बहुत पदावनत SQL सर्वर Collations का उल्लेख कर रहे हैं, जबकि जो कोलाज उस क्वेरी के परिणामस्वरूप दिखाई देते हैं (उनमें से 888 SQL सर्वर 2012, SP3 के रूप में) Windows Collations हैं।
SQL सर्वर 2000 में शुरू, पुराने SQL सर्वर Collations (SQL सर्वर से पहले Windows Collations में टैप करने में सक्षम किया जा रहा है बनाया) पदावनत कर रहे हैं और नए नियमों या कार्यक्षमता के साथ अद्यतन नहीं किया जा रहा है। उदाहरण के लिए, SQL सर्वर 2012 में शुरू होने पर, Collations का एक सेट जोड़ा गया था जो पूरक वर्णों के लिए अंतर्निहित कार्यों (यानी "बेस" से परे शेष UTF-16 वर्णों के उचित हैंडलिंग का समर्थन करता है, जो शुरू में UCS-2 में परिभाषित 65,536 वर्णों से परे है) )। इन नए Collations में _SC(के रूप में एस अपरेटिव सी haracters)।
SQL सर्वर Collations का उपयोग न करने के लिए सबसे अच्छा है - जिन नामों के साथ शुरू हो रहा है SQL_। इसलिए आपके पास बहुत सारे Collations तक पहुंच है जो उन विकल्पों के संयोजन का समर्थन करते हैं जिन्हें आप खोज रहे हैं (यानी केस-सेंसिटिव और एक्सेंट-असंवेदनशील)। जब भी उपलब्ध हो, तब तक एक छोर का उपयोग करना सबसे अच्छा है _SCजब तक कि आपके पास अन्य सभी विकल्प हैं जो आप चाहते हैं।
जबकि SQL सर्वर _CS_AIनामकरण सम्मेलन का उपयोग करता है , सभी 3810 (SQL सर्वर 2012 के रूप में) Windows Collations की कोई सूची नहीं है। वहाँ सिर्फ Windows Collation नाम पृष्ठ है जो सभी स्थानों और संस्करणों को सूचीबद्ध करता है, और नामकरण सम्मेलन कैसे काम करता है, लेकिन यह बात है।
SQL सर्वर भी चौड़ाई और काना संवेदनशीलता दोनों का समर्थन करता है।
MySQL (Oracle द्वारा खरीदा गया)
MySQL संस्करण 5.7, प्रलेखन कहा गया है कि यह समर्थन नहीं करता _ai, _as, _ci, और _csप्रत्यय (और _binसंपूर्णता के लिए), लेकिन यह भी कहा गया है:
गैर-कोलेजन नामों के लिए जो उच्चारण संवेदनशीलता को निर्दिष्ट नहीं करते हैं, यह केस संवेदनशीलता द्वारा निर्धारित किया जाता है। यही है, अगर एक कोलाजेशन नाम शामिल नहीं है _aiया _as, _ciनाम में निहित है _aiऔर _csनाम में निहित है _as।
उदाहरण के लिए, latin1_general_ciमामला असंवेदनशील है (और असंवेदनशील, अव्यक्त रूप से), latin1_general_csमामला संवेदनशील है (और उच्चारण संवेदनशील, निहित रूप से)
यह निश्चित रूप से तात्पर्य है कि एक latin1_general_cs_aiCollation होना संभव है । हालांकि, MySQL 5.5.50 सर्वर है कि मैं करने के लिए उपयोग किया है और अधिक से अधिक एक प्रत्यय के साथ किसी भी collations नहीं है, और केवल प्रत्यय मैं देख रहा हूँ कर रहे हैं: _cs, _ci, और _bin198 कुल collations भर में। मैंने उन्हें सूचीबद्ध करने के लिए SHOW COLLATION कमांड का उपयोग किया ।
इसलिए, जब यह लगता है कि MySQL एक समान नामकरण सम्मेलन का उपयोग करता है (कम से कम जहाँ तक वे दो विकल्प चलते हैं), मैं एक Collation मिलान नहीं ढूँढ सकता जो आप देख रहे हैं। हालाँकि, यह लहजे (और अन्य विशिष्ट चिह्न) को बंद करना और _csजो आप चाहते हैं उसे प्राप्त करने के लिए एक कॉलेशन का उपयोग करना संभव हो सकता है ( पोस्टग्रेक्यूएल में आप इसे कैसे करेंगे - नीचे देखें)। लेकिन मैं इस विकल्प के बारे में निश्चित नहीं हूं और फिलहाल और शोध के लिए समय नहीं है।
या , आप वास्तव में आप क्या चाहते हैं करने के लिए अपने बहुत ही कोलाज बना सकते हैं। अन्य RDBMSs के विपरीत, MySQL को अपने स्वयं के Collations को जोड़ने के बजाय इसे सरल बनाना प्रतीत होता है, जिस स्थिति में आप प्रत्येक वर्ण के भार पर पूर्ण नियंत्रण में हैं। कृपया अधिक विवरण के लिए एक साधारण बिटेशन को 8-बिट कैरेक्टर सेट में जोड़कर और UCA Collation को एक यूनिकोड कैरेक्टर सेट में जोड़कर देखें।
MySQL विभिन्न प्रकार के Collations कैसे संभालता है, इस बारे में अधिक जानकारी के लिए, कृपया उनका Collation कार्यान्वयन प्रकार पृष्ठ देखें।
PostgreSQL
PostgreSQL में Collations बहुत कम लचीले लगते हैं। आप केवल संस्कृति / भाषा निर्दिष्ट: en_US, de_DE, आदि कृपया अपनी दस्तावेज़ीकरण पृष्ठ देखें मिलान समर्थन जानकारी के लिए। इसलिए, डिफ़ॉल्ट रूप से आप संस्कृति-विशिष्ट ओवरराइड प्राप्त करते हैं, लेकिन Collations अन्यथा सब कुछ संवेदनशील हैं (जो, वैसे, "बाइनरी" कॉलेशन के समान नहीं है)।
केस असंवेदनशीलता प्राप्त करने के लिए आप ILIKE (सेक्शन 9.7.1) का उपयोग कर सकते हैं , लेकिन उनके पास उच्चारण संवेदनशीलता के लिए समान ऑपरेटर नहीं है। हालांकि, मैंने पाया कि उनके पास एक अस्वीकार्य फ़ंक्शन है जिसका उपयोग लहजे और अन्य विशिष्ट चिह्न को हटाने के लिए किया जा सकता है। कृपया ध्यान दें कि यह फ़ंक्शन एक अतिरिक्त अनुपूरक मॉड्यूल है और इसलिए आवश्यक रूप से उपयोग करने के लिए किसी विशेष PostgreSQL सर्वर में मौजूद नहीं है । यह हाल ही में जुड़े प्रलेखन राज्यों:
स्रोत वितरण से निर्माण करते समय, ये घटक स्वचालित रूप से निर्मित नहीं होते हैं, जब तक कि आप "विश्व" लक्ष्य का निर्माण नहीं करते हैं
...
यदि आप PostgreSQL के पूर्व-पैक संस्करण का उपयोग कर रहे हैं, तो ये मॉड्यूल आमतौर पर एक अलग उप-पैकेज के रूप में उपलब्ध होते हैं, जैसे कि PostgreSQL-योगदान।
कृपया देखें कि अगर आपके पास यह नहीं है और इसे चाहते हैं तो उस फ़ंक्शन को कैसे प्राप्त करें, इसके निर्देशों के लिए दस्तावेज़ देखें।
अधिक जानकारी निम्नलिखित स्टैक ओवरफ्लो उत्तर में भी पाई जा सकती है:
क्या PostgreSQL "उच्चारण असंवेदनशील" टकरावों का समर्थन करता है?
DB2 (IBM)
Microsoft SQL सर्वर के समान, DB2 में दो प्रकार के Collations हैं:
"सिस्टम" Collations, जो निम्नलिखित प्रारूप का उपयोग कर निर्दिष्ट हैं SYSTEM_{codepage}_[optional-territory]:। ये बहुत लचीले नहीं होते हैं, और मामले, लहजे या किसी भी चीज़ के प्रति संवेदनशीलता के समर्थन में दिखाई नहीं देते हैं। आप यहां समर्थित Collations की सूची पा सकते हैं: समर्थित क्षेत्र कोड और कोड पृष्ठ
यूनिकोड कोलाज एल्गोरिथ्म (UCA) -बेड Collations। ये काफी हद तक टेलरिंग का समर्थन करते हैं। व्यवहार को कैसे कॉन्फ़िगर करें, नामकरण सम्मेलन और मान्य स्थानों की सूची के बारे में जानकारी के लिए कृपया उनका यूनिकोड कोलाज एल्गोरिथ्म आधारित कोलाज पृष्ठ देखें। कृपया ध्यान दें कि तालिका 1 में, तीसरी पंक्ति ("केस लेवल") में उदाहरण के साथ शुरू होता है:
केस स्तर की विशेषता को चालू करने और प्राथमिक स्तर को शक्ति विशेषता को सेट करने से उच्चारण की अनदेखी होगी लेकिन मामला नहीं।
यह वही है जो आप देख रहे थे। लेकिन, इसके लिए वाक्य रचना है
CLDR181_EO_S1:। और यही कारण है कि आपकी खोज में DB2 से संबंधित कुछ भी नहीं मिला।
आकाशवाणी
ओरेकल 10 जी ने उच्चारण असंवेदनशील तुलना और छँटाई करने के लिए समर्थन जोड़ा। तथापि:
- उनके पास केवल "असंवेदनशील" संचालन को निरूपित करने के विकल्प हैं:
_CIऔर_AI
- आप केवल एक समय में उन विकल्पों में से एक निर्दिष्ट कर सकते हैं
- केस-असंवेदनशील विकल्प -
_CI- अभी भी उच्चारण संवेदनशील है
- उच्चारण-असंवेदनशील विकल्प -
_AI- "हमेशा केस-असंवेदनशील भी होता है।" (उनके प्रलेखन से उद्धृत जो नीचे लिंक किया गया है)
कृपया अधिक विवरण और उदाहरणों के लिए उनके भाषाई क्रमबद्धता और स्ट्रिंग खोज दस्तावेज़ पृष्ठ देखें।
SAP ASE (पूर्व में Sybase ASE उर्फ Sybase)
ASE प्रत्येक स्थान / वर्ण सेट में संवेदनशीलता के निम्नलिखित संयोजनों में से एक या अधिक का समर्थन करता है:
- केस-संवेदी, उच्चारण-संवेदी
- केस-असंवेदनशील, उच्चारण-संवेदनशील
- मामले-असंवेदनशील, उच्चारण-संवेदनशील, वरीयता के साथ आदेश
- केस-असंवेदनशील, उच्चारण-असंवेदनशील
आप लोकल, कैरेक्टर सेट और उपलब्ध क्रमों के बीच के रिलेशन को उनके सेलेक्ट डिफॉल्ट सॉर्ट ऑर्डर पेज पर देख सकते हैं। और आप Collations की पूरी लिस्ट उनके Collation Names and IDs पेज पर देख सकते हैं ।
उनका Collation नामकरण सम्मेलन मनमाना है जिसमें वे सभी 4 - 8 वर्ण हैं और स्थानीय नाम या कोड पृष्ठ और कुछ छांटने की भावना को पकड़ने की कोशिश करते हैं। उदाहरण के लिए:
altnoacc== "CP 850 वैकल्पिक - कोई उच्चारण नहीं"
rusdict== "रूसी शब्दकोश आदेश"
dynix== "चीनी ध्वन्यात्मक आदेश"
उनके डिफ़ॉल्ट यूनिकोड सॉर्ट ऑर्डर पृष्ठ के चयन पर एक नोट है :
आप $/collate/Unicodeनिर्देशिका में बाहरी फ़ाइलों का उपयोग करके सॉर्ट ऑर्डर जोड़ सकते हैं । नाम और टकराव आईडी संग्रहीत हैं syscharsets। बाहरी यूनिकोड सॉर्ट ऑर्डर के नाम syscharsetsडिफ़ॉल्ट यूनिकोड सॉर्ट ऑर्डर सेट करने से पहले आपके पास नहीं होना चाहिए ।
...
SAP द्वारा बाहरी यूनिकोड सॉर्ट ऑर्डर दिए गए हैं। बाहरी यूनिकोड सॉर्ट क्रम बनाने का प्रयास न करें।
यह स्पष्ट नहीं है कि एसएपी केस-सेंसिटिव और एक्सेंट-इनसेंसिटिव के लिए अनुमति देने के लिए एक बाहरी सॉर्ट ऑर्डर की आपूर्ति करेगा या नहीं । शायद किसी दिन मैं उन्हें ईमेल करूंगा और पूछूंगा कि क्या कोई अनुरोध किया जा सकता है।
संवेदनाओं के वांछित संयोजन को प्राप्त करने के लिए, आपको उच्चारणों और अन्य विशिष्ट चिह्नों को हटाने के लिए एक स्केलर उपयोगकर्ता-परिभाषित फ़ंक्शन बनाने में सक्षम होना चाहिए ।
Informix (आईबीएम द्वारा खरीदा गया)
Informix ज्यादातर एक Collation के डिफ़ॉल्ट सॉर्टिंग और तुलना व्यवहार का समर्थन करने के लिए प्रकट होता है। इसलिए Collations सिर्फ लोकेल और कैरेक्टर सेट हैं। केस-सेंसिटिविटी को डेटाबेस-स्तर पर नियंत्रित किया जाता है, और डिफ़ॉल्ट रूप से वे केस-सेंसिटिव होते हैं। आप स्टेटमेंट में NLSCASE INSENSITIVE निर्दिष्ट करके केस-असंवेदनशील होने के लिए एक डेटाबेस (टेबल, या कॉलम, या क्वेरी, या यहां तक कि एक विधेय नहीं) सेट कर सकते हैं CREATE DATABASE।
जबकि डेटाबेस कोलेशन - लोकेल और कैरेक्टर सेट - को क्लाइंट कनेक्शन के अनुसार ओवरराइड किया जा सकता है, लेकिन केस-सेंसिटिविटी सेटिंग को ओवरराइड करने का कोई तरीका नहीं लगता है। और, NLSCASEविकल्प में एक कारण के लिए नाम में "एनएलएस" है: यह केवल प्रभावित करता है NCHARऔर NVARCHARडेटा; CHARऔर VARCHARहमेशा केस-संवेदी होते हैं।
एक्सेंट-सेंसिटिविटी को संबोधित नहीं किया जाता है, न ही एक्सेंट / डिआक्रिटिकल मार्क्स को स्ट्रिप करने के लिए बिल्ट-इन फंक्शन होता है।
Informix Collation नामकरण सम्मेलन है:
<lang>_<country>.<code set>
कहाँ पे:
<lang> = 2-अक्षर या 3-अक्षर भाषा कोड<country> = 2-अक्षर वाला देश या क्षेत्र कोड<code set> = 3 समान तरीकों में से एक में निर्दिष्ट कोड पृष्ठ:
- नाम: 8859-1
- IBM CCSID संख्या का दशमलव मान: 819
- IBM CCSID संख्या का हेक्साडेसिमल मान: 0333
इसलिए, निम्नलिखित तीन स्थानीय विनिर्देश सभी सटीक एक ही स्थान को संदर्भित करते हैं:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
अधिक जानकारी के लिए, कृपया देखें: