Microsoft SQL सर्वर में स्ट्रिंग्स से पहले हमें N लगाने की आवश्यकता क्यों है?

Question

मैं टी-एसक्यूएल सीख रहा हूं। मैंने जिन उदाहरणों को देखा है, एक varchar()सेल में टेक्स्ट डालने के लिए , मैं डालने के लिए सिर्फ स्ट्रिंग लिख सकता हूं, लेकिन nvarchar()कोशिकाओं के लिए, प्रत्येक उदाहरण एन अक्षर के साथ स्ट्रिंग्स को उपसर्ग करता है।

मैंने एक तालिका पर निम्नलिखित क्वेरी की कोशिश की जिसमें nvarchar()पंक्तियाँ हैं, और यह ठीक काम करती है, इसलिए उपसर्ग N की आवश्यकता नहीं है:

insert into [TableName] values ('Hello', 'World')

क्यों तार मैंने देखा है हर उदाहरण में एन के साथ उपसर्ग कर रहे हैं?

इस उपसर्ग का उपयोग करने के पेशेवरों या विपक्ष क्या हैं?

Comments

क्या एन केवल शाब्दिक तार के लिए आवश्यक नहीं है?

— वेन इन याक

पोलिश एक गैर-लैटिन आधारित भाषा है ????

— Heckflosse_230

Nनेशनल का मतलब है, "नेशनल वेरिंग कैरेक्टर" के रूप में, बराबर एएनएसआई SQL डेटा प्रकार देखें ।

— ErikE

मैं इस सवाल से सहमत हूं और किसी ने भी अभी तक इसका जवाब नहीं दिया है। शायद यह के रूप में "कारण है कि यह बुरा एसक्यूएल परोक्ष मेरी परिवर्तित करने देने के लिए है फिर से बताने से किया जा सकता है VARCHARके लिए NVARCHARजब मेरे स्ट्रिंग शाब्दिक ASCII है?"।

— बिंकी

यह प्रश्न पहले से ही पूछा गया था और यहां उत्तर दिया गया था: वरचर और नवरचचर में क्या अंतर है?

Answer 1

NVarchar का उपयोग यूनिकोड के लिए किया जाता है। यदि आपका डेटाबेस बहुभाषी डेटा संग्रहीत नहीं कर रहा है, तो आप वर्चर का उपयोग कर सकते हैं। एक उदाहरण के रूप में: N'abc'बस अपने स्ट्रिंग को यूनिकोड में परिवर्तित करता है।

Comments

फिर आपको N के बजाय U के साथ उपसर्ग क्यों नहीं करना है?

— अत्तिला कुन

U एक अनुमान के रूप में अहस्ताक्षरित के लिए भ्रमित हो सकता है

— जेबी किंग

U&'abc'यूनिकोड स्ट्रिंग्स को निर्दिष्ट करने का सही तरीका है। देखें एसक्यूएल 2003 BNF

— ceving

एन वास्तव में "राष्ट्रीय भाषा चरित्र" सेट के लिए है।

— माइक बॉवनलैंडर

Answer 2

डिफ़ॉल्ट रूप से SQL सर्वर varchar के लिए Windows-1252 वर्ण कोड का उपयोग करता है । इसमें लैटिन-आधारित भाषाओं (अंग्रेजी, जर्मन, फ्रेंच, आदि) के अधिकांश वर्ण शामिल हैं, लेकिन इसमें गैर-लैटिन आधारित भाषाओं (पोलिश, रूसी, आदि) के लिए वर्ण शामिल नहीं हैं। जैसा कि @ पीटर बी द्वारा कहा गया है, उस मुद्दे को घेरने के लिए nvarchar का उपयोग किया जाता है क्योंकि यह यूनिकोड के लिए है जिसमें उन गायब अक्षर होते हैं। यह एक लागत पर आता है, यह varchar की तुलना में nvarchar को स्टोर करने के लिए दोगुना जगह लेता है।

एन को अपनी स्ट्रिंग के सामने रखना यह सुनिश्चित करता है कि पात्रों को एक नवरचर्क कॉलम में रखे जाने से पहले यूनिकोड में बदल दिया गया है। ज्यादातर समय आप एन को छोड़कर ठीक हो जाएंगे, लेकिन मैं इसकी सिफारिश नहीं करूंगा। सॉरी से सुरक्षित रहना बहुत बेहतर है।

Comments

बस एक स्पष्टीकरण: "डिफ़ॉल्ट रूप से" SQL सर्वर वर्चर्स फ़ील्ड के कोलाजेशन के अनुरूप एन्कोडिंग का उपयोग करता है, जो कि फ़ील्ड के निर्माण के समय में अधिक उपयोग करने योग्य होता है, आमतौर पर आपके उदाहरण के लिए डिफ़ॉल्ट कोलाजेशन पर आधारित होता है। आपके उदाहरण के लिए डिफ़ॉल्ट टकराव को स्थापित समय पर सेट किया जा सकता है, लेकिन आमतौर पर सिस्टम डिफ़ॉल्ट लोकेल के CP_ACP से मेल खाता है। यह यूएस-इंग्लिश मशीन पर विंडोज 1252 होगा, लेकिन जापानी सिस्टम लोकेल के साथ मशीन पर 932, रूसी मशीन पर 1251, आदि कहानी का नैतिक है? NVarchar का प्रयोग करें :)

— जेसन ट्रू

अब तक यह एकमात्र उत्तर है जो प्रश्न को संबोधित करता है "एसक्यूएल ट्रांसकोड के बाद से शाब्दिक तार पर एन उपसर्ग का उपयोग क्यों करें?"। अन्य उत्तर सभी एक अलग प्रश्न के लिए हैं "नवरच बनाम वर्चर के बीच अंतर क्या है?"

— टिम्बो

Answer 3

क्योंकि MS SQL Server को UTF-8 के लिए अन्य RDBMS की तुलना में खराब समर्थन प्राप्त है।

एमएस SQL ​​सर्वर, विंडोज के भीतर ही उपयोग किए जाने वाले कन्वेंशन का अनुसरण करता है, जो कि "संकीर्ण" स्ट्रिंग्स ( charC ++, CHARया VARCHARSQL में) एक विरासत "कोड पेज" में एन्कोडेड हैं । कोड पृष्ठों के साथ समस्या यह है कि उनके पास सीमित संख्या में वर्ण हैं (अधिकांश एकल-बाइट एन्कोडिंग हैं, जो रिपोर्टोअर को 256 वर्णों तक सीमित करता है) और एक ही भाषा (या समान वर्णमाला वाली भाषाओं के समूह) के आसपास डिज़ाइन किए गए हैं। इससे बहुभाषी डेटा संग्रहीत करना कठिन हो जाता है। उदाहरण के लिए, आप रूसी और हिब्रू दोनों डेटा संग्रहीत नहीं कर सकते क्योंकि रूसी कोड पृष्ठ 1251 का उपयोग करता है और हिब्रू कोड पृष्ठ 1255 का उपयोग करता है ।

यूनिकोड एक लाख से अधिक पात्रों के लिए कमरे के साथ सेट किए गए एक विशालकाय कोडित चरित्र का उपयोग करके इस समस्या को हल करता है, जो दुनिया की हर भाषा का प्रतिनिधित्व करने के लिए पर्याप्त है। कई यूनिकोड एन्कोडिंग योजनाएं हैं; माइक्रोसॉफ्ट के उपयोग का चुनाव UTF-16 , के लिए ऐतिहासिक कारणों से । क्योंकि UTF-16 पारंपरिक 8-बिट के बजाय 16-बिट कोड इकाइयों के अनुक्रम के रूप में तार का प्रतिनिधित्व करता है, एक अलग चरित्र प्रकार की आवश्यकता है। MSVC ++ में, यह है wchar_t। और MS SQL में, यह NCHARया है NVARCHAR। N"राष्ट्रीय" के लिए खड़ा है , जो मेरे लिए पीछे की ओर लगता है क्योंकि यूनिकोड के बारे में है अंतर -nationalization, लेकिन यह आईएसओ शब्दावली है।

अन्य SQL कार्यान्वयन आपको स्तंभ में UTF-8 पाठ संग्रहीत करने देते हैं VARCHAR। UTF-8 एक चर-लंबाई (प्रति वर्ण 1-4 बाइट्स) एन्कोडिंग है जो उस स्थिति के लिए अनुकूलित होता है जब आपका डेटा ज्यादातर बेसिक लैटिन रेंज में होता है (जो कि ASCII के अनुसार प्रति वर्ण 1 बाइट के रूप में दर्शाया जाता है), लेकिन प्रतिनिधित्व कर सकते हैं कोई भी यूनिकोड वर्ण। इस प्रकार, आप bwalk2895 द्वारा उल्लिखित "दो बार जितना स्थान" समस्या से बचेंगे।

दुर्भाग्य से, MS SQL सर्वर UTF-8 का समर्थन नहीं करता हैVARCHAR , इसलिए इसके बजाय आपको या तो UTF-16 का उपयोग करना होगा (और ASCII पाठ के लिए अपशिष्ट स्थान), एक गैर-यूनिकोड कोड पृष्ठ का उपयोग करें (और विदेशी वर्णों का प्रतिनिधित्व करने की क्षमता खो दें) या किसी BINARYस्तंभ में UTF-8 को संग्रहीत करें (और SQL स्ट्रिंग फ़ंक्शंस जैसी असुविधाओं से निपटें जो ठीक से काम नहीं कर रही हैं, या आपके GUI DB प्रबंधक में हेक्स डंप के रूप में डेटा को देखने के लिए)।

Comments

पहले SQL Server 2012 के संस्करणों में, वे UCS-2 एन्कोडिंग का उपयोग करके वेयर करते हैं, जो कड़ाई से 2byte है। नए संस्करणों में, वे UTF-16 का उपयोग कर रहे हैं, जो प्रति वर्ण 4bytes के लिए चर लंबाई मैपिंग है (UTF-8 के समान लेकिन 2 बाइट्स से शुरू)।

— j123b567