सरलीकृत चीनी इनपुट की अनुमति

Question

जिस कंपनी के लिए मैं काम करता हूं वह उस परियोजना पर बोली लगा रहा है जिसके लिए हमारे ईकामर्स समाधान को सरलीकृत चीनी इनपुट स्वीकार करने की आवश्यकता होगी। अनुसंधान के एक बिट करने के बाद, ऐसा लगता है कि ASP.net भूमंडलीकरण विन्यास आसान बनाता है:

<configuration> 
    <system.web> 
    <globalization 
     fileEncoding="utf-8" 
     requestEncoding="utf-8" 
     responseEncoding="utf-8" 
     culture="zh-Hans" 
     uiCulture="en-us" /> 
    </system.web> 
</configuration> 

सवाल:

1. यह वास्तव में सभी ASP.net में यह करने के लिए नहीं है है? यह सच होना अच्छा लगता है।
2. क्या SQL सर्वर 2005 के साथ कोई डीबी विचार है? डीबी अतिरिक्त कॉन्फ़िगरेशन के बिना सरलीकृत चीनी स्वीकार करेगा?

Answer 1

विज्ञापन 1. असली सवाल यह है कि आप अंतर्राष्ट्रीयकरण के साथ कितना दूर जाना चाहते हैं। क्योंकि i18n न केवल यूनिकोड इनपुट की इजाजत दे रहा है। आपको स्थानीय तिथि, समय और संख्या प्रारूपों, स्थानीय संयोजन (ज्यादातर सॉर्टिंग से संबंधित) का समर्थन करने की आवश्यकता है और सुनिश्चित करें कि आपका एप्लिकेशन स्थानीयकृत ऑपरेटिंग सिस्टम पर सही ढंग से चलता है (जब तक कि आप क्लाउड उर्फ ​​होस्टेड समाधान विकसित नहीं कर रहे हों)। आप here विषय पर और अधिक पढ़ना चाहेंगे।

चीनी चरित्र इनपुट के लिए समर्थन के रूप में, यदि आप चीन में सॉफ्टवेयर पेश करने जा रहे हैं, तो आपको कम से कम GB18030-2000 का समर्थन करना होगा। ऐसा करने के लिए, आपको उचित नेट फ्रेमवर्क संस्करण का उपयोग करने की आवश्यकता है - वह यूनिकोड 3.0 का समर्थन करता है। मेरा मानना ​​है कि यह नेट फ्रेमवर्क 2.0 के बाद से समर्थित था।
हालांकि, यदि आप एक कदम आगे जाना चाहते हैं (जो प्रतिस्पर्धी किनारे प्राप्त करने के लिए आवश्यक हो सकता है), तो आप GB18030-2005 का समर्थन करना चाहेंगे। एकमात्र समस्या यह है कि, इन पात्रों के लिए पूर्ण समर्थन (सीजेके एकीकृत विचारधारा एक्सटेंशन बी) बाद में हुआ (मुझे वास्तव में यकीन नहीं है कि यह यूनिकोड 6.0 या यूनिकोड 6.1 है) प्रक्रिया में। इसलिए आपको नवीनतम नेट फ्रेमवर्क का उपयोग करने के लिए मजबूर होना पड़ सकता है और फिर भी यह सुनिश्चित नहीं है कि इसमें सबकुछ शामिल है या नहीं।
आप Unicode FAQ on Han characters पढ़ना चाहेंगे।

विज्ञापन 2. मैं दृढ़ता से सलाह देता हूं कि आप चीनी वर्णों के साथ SQL सर्वर 2005 का उपयोग न करें। कारण यह है कि पुराने SQL सर्वर इंजन यूटीएफ -16 के बजाय केवल यूसीएस -2 का समर्थन करता है। यह मामूली अंतर के रूप में प्रतीत हो सकता है, लेकिन वास्तव में 4-बाइट हान विचारधाराओं के साथ समस्या उत्पन्न होती है। असल में, आप उन्हें प्रश्नों में उपयोग करने में सक्षम होना चाहते हैं (यानी जैसे या कहां खंड) - आपको सभी रिकॉर्ड्स प्राप्त होंगे। यह वैसे काम करता है। और उनका समर्थन करने के लिए, आपको बहुत विशिष्ट चीनी संयोजन स्थापित करना होगा, जो कि अन्य भाषाओं के लिए समर्थन तोड़ देगा।
असल में, चीनी विचारधाराओं के साथ SQL सर्वर 2005 का उपयोग खराब विचार है।

Answer 2

सबसे पहले, मुझे आश्चर्य है कि क्या आप सुनिश्चित हैं कि आपने zh-Hans के साथ सही संस्कृति पहचानकर्ता चुना है, जो neutral culture है। शायद यह एक विशिष्ट संस्कृति को लक्षित करने के लिए आपके लिए उपयुक्त होगा, जैसे कि zh-CN (चीन में चीनी का उपयोग किया जा रहा है) यदि वह बाजार है जिसका आप समर्थन करना चाहते हैं।

दूसरा, संस्कृति सेट करने के लिए web.config फ़ाइल का उपयोग करना ठीक है यदि आप इस संस्कृति को विशेष रूप से लक्षित करने वाली तैनाती की योजना बना रहे हैं। अक्सर आप एक ही तैनाती को अंतिम उपयोगकर्ता की संस्कृति के लिए गतिशील रूप से अनुकूलित करने के लिए चाहते हैं, इस मामले में आप URL12 योजना (उदाहरण के लिए www.myapp) पर उदाहरण के लिए Thread.CurrentCulture (और Thread.CurrentUICulture भी स्थानीय संसाधन प्रदान कर रहे हैं) प्रोग्रामेटिक रूप से सेट करेंगे। कॉम एन-यूएस का उपयोग करेगा और www.myapp.com/china zh-CN का उपयोग करेगा) या स्वीकार्य-भाषा शीर्षलेख या इन-ऐप भाषा चयनकर्ता।

Paweł संदर्भित यूनिकोड सीमाओं के अलावा (जिसका अर्थ है कि आपको वास्तव में नवीनतम .NET Framework/SQL सर्वर का उपयोग करने की आवश्यकता हो सकती है), सरल चीनी के लिए आपको कुछ विशिष्ट करने की आवश्यकता नहीं है - अगर आप मानक internationalization guidelines का पालन करते हैं, आपको सभी सेट होना चाहिए। शायद आपको इस तरह के हिस्से के रूप में चीनी में अपने ऐप को स्थानीयकरण (अनुवाद) पर विचार करना चाहिए।

SQL सर्वर के बारे में, Paweł के अंक बहुत स्पष्ट लगते हैं। उस ने कहा, जब तक आप nvarchar डेटाटाइप (यूनिकोड) का उपयोग करते हैं और आप इन कॉलम पर क्वेरी नहीं चलाते हैं या डीबी पक्ष पर इन कॉलम के आधार पर उन्हें सॉर्ट नहीं करते हैं, तो मुझे आश्चर्य होगा अगर आपको SQL Server 2005 पर कोई समस्या है। तो यह वास्तव में निर्भर करता है कि आप इस डेटा के साथ क्या करते हैं।