जब डेटाबेस कॉन्फ़िगरेशन की बात आती है तो क्या यूटीएफ -8 में लैटिन -1 का उपयोग किया जाना चाहिए?

Question

हम जिस कंपनी के लिए काम करते हैं उसमें MySQL का उपयोग कर रहे हैं, और हम रूबी ऑन रेल्स का उपयोग करके क्लाइंट-फेसिंग और आंतरिक अनुप्रयोगों दोनों का निर्माण करते हैं।

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

मेरे मालिक इन "खराब चरित्रों" को कॉल करते हैं क्योंकि उनमें से अधिकांश गैर-मुद्रण योग्य वर्ण हैं, और कहते हैं कि हमें उन्हें बाहर निकालने की आवश्यकता है। मुझे ऐसा करने के कुछ तरीके मिले हैं, लेकिन आखिरकार हम एक ऐसी परिस्थिति में समाप्त हो गए हैं, जहां एक UTF-8 चरित्र की आवश्यकता थी। इसके अलावा यह एक परेशानी का एक सा है, खासकर जब से यह एकमात्र समाधान की तरह लगता है जो मैंने कभी इस मुद्दे के बारे में पढ़ा है, बस डेटाबेस को UTF-8 पर सेट करना है (मुझे समझ में आता है)।

एकमात्र तर्क जो मैंने लेटिन -1 के साथ चिपके रहने के लिए सुना है, वह है गैर-मुद्रण योग्य UTF-8 वर्णों को अनुमति देना MySQL में पाठ / पूर्ण-पाठ खोजों को गड़बड़ कर सकता है। क्या यह वास्तव में सच है?

क्या यूटीएफ -8 पर लैटिन -1 का उपयोग करने के अन्य कारण हैं? यह मेरी समझ है कि यह श्रेष्ठ है और अधिक सर्वव्यापी बन रहा है।

Comments

@ जोन लेटिन -1 अंग्रेजी विशिष्ट नहीं है । स्पैनिश पूरी तरह से वहाँ निहित है, साथ ही साथ फ्रेंच अगर मैं गलत नहीं हूँ।

— डार्कहॉग

@ दार्ख: लैटिन 1 वास्तव में अंग्रेजी के लिए विशिष्ट नहीं है, लेकिन यह अनिवार्य रूप से पश्चिम-यूरोपीय वर्णमाला के लिए प्रतिबंधित है।

— बार्ट वैन इनगेन शानौ

आधुनिक प्रणाली में UTF-8 के बजाय लैटिन 1 का उपयोग करने से एकमात्र संभावित लाभ तोड़फोड़ है। बेशक यह सबोटूर के लिए केवल एक लाभ है, और जो भी उनकी निष्ठाएँ हैं, वे सिस्टम के मालिकों या डेवलपर्स के लिए नहीं हैं।

— जॉन हन्ना

बहुत बुरा है आपका डेटाबेस यूरो प्रतीक, या यहां तक ​​कि मेरा नाम (databaseותן) धारण करने में सक्षम नहीं होगा।

— dotancohen

उपयोगकर्ता "कॉपी और पेस्ट" गैर-लैटिन -1 वर्ण? यूनिकोड को किसी ऐसी अप्रासंगिक वस्तु के रूप में न मानें, जिसके बारे में केवल शरारती लोग ही ध्यान रखते हों। हम में से बहुत से ऐसे अक्षर टाइप करते हैं जो लैटिन 1 में नियमित रूप से फिट नहीं होंगे - मैंने बहुत से लोगों को गैर-यूरोपीय भाषाएं बोलते हुए सुना है, यहां तक ​​कि ♥

— Eevee

Answer 1

यूनिकोड निश्चित रूप से कठिन है, और UTF-8 एन्कोडिंग में कुछ असुविधाजनक गुण हैं। हालाँकि, UTF-8 ASCII, लैटिन -1, UCS-2 और UTF-16 को पार करते हुए वेब पर वास्तविक मानक एन्कोडिंग बन गया है। बस हर जगह UTF-8 का उपयोग करें ।

यूनिकोड का समर्थन करने का सबसे महत्वपूर्ण कारण यह है कि आपको उपयोगकर्ता इनपुट के बारे में अनावश्यक अनुमान नहीं लगाना चाहिए। मुझे नहीं पता कि आपका डोमेन क्या है, लेकिन हिब्रू उपयोगकर्ता नाम, चीन के बारे में एक ब्लॉग पोस्ट, इमोजी के साथ एक टिप्पणी, या बस अच्छी तरह से स्टाइल किए गए पाठ - जैसे "यह" - संभव होना चाहिए ... ओह, वे टाइपोग्राफिक रूप से सही उद्धरण चिह्न थे। “”इसके बजाय ""), एन-वाइड डैश, और एक दीर्घवृत्त, जो ऐसे अक्षर हैं जो अंग्रेजी पाठ में आम हैं, लेकिन एएससीआईआई या लैटिन -1 द्वारा समर्थित नहीं हैं। तो अन्य लिपियों का समर्थन नहीं करना केवल अन्य संस्कृतियों के लिए एक बड़ा f * ck नहीं है, लेकिन लैटिन -1 से चिपके रहना भी आपको उचित अंग्रेजी लिखने की अनुमति नहीं देता है।

यह धारणा कि यूनिकोड केवल "खराब वर्ण" की अनुमति देता है, गलत है। हां, पाठ वास्तव में जटिल है, और यूनिकोड आपसे यह नहीं छिपाएगा। आपका बॉस रचित पात्रों के बारे में सोच रहा होगा, जहां एक आधार कोडपाइंट जैसे aबाद के कोडपाइंट द्वारा संशोधित किया जाता है, जैसे कि एक दृश्य चरित्र जैसे बनाने के लिए डायक्ट्रीक्स का प्रतिनिधित्व करते हैं á। जब आप किसी तरह का सामान्यीकरण करते हैं तो यह खोज करने की कोशिश करने पर वास्तव में आपके रास्ते में नहीं आता है। उदाहरण के लिए, आप एनएफसी फॉर्म के सभी पाठों को संग्रहीत कर सकते हैं जो ऐसी रचनाओं को उनके पूर्व-निर्धारित रूप में ढँक देते हैं यदि कोई उपलब्ध हो। खोज करते समय, आप पाठ से सभी कंपोजिंग वर्णों को भी हटा सकते हैं, लेकिन इससे कुछ भाषाओं में उनका अर्थ काफी हद तक बदल सकता है।

यूनिकोड में बहुत सारे अनपेक्षित वर्ण भी जोड़े जाते हैं - लेकिन यहां तक ​​कि ASCII में भी उनका भार होता है। क्या आप एक स्ट्रिंग के बीच में एनयूएल को संभालेंगे? कैसे के बारे में 0x1C, एक "फ़ाइल विभाजक"? मैंने उनमें से आधे को कभी नहीं देखा । लैटिन -1 एक नरम हाइफ़न जोड़ता है जो वर्ड ब्रेक के अवसरों को इंगित करता है, लेकिन अन्यथा अदृश्य है। क्या यह भी आपके पूर्ण-पाठ खोज को तोड़ता है? दूसरे शब्दों में, यहां तक ​​कि ASCII और लैटिन -1 आपको अपने इनपुट को पूरी तरह से तोड़ने की अनुमति देते हैं यदि आप मानते हैं कि यह सब सिर्फ मुद्रण योग्य पाठ है!

Comments

डेटाबेस के नजरिए से, उन वर्णों में से कुछ पाठ प्रकार के क्षेत्र (पाठ / varchar / char / etc) में अनुमति नहीं है / नहीं होनी चाहिए। MySQL करता है इन डेटा प्रकार में अशक्त वर्णों की अनुमति है, लेकिन PostgreSQL की तरह अन्य डेटाबेस नहीं है। यदि आप ऐसे पात्रों को संग्रहीत करने में सक्षम होना चाहते हैं, तो आप BLOB (MySQL) या BYTEA (PostgreSQL) का उपयोग करने वाले हैं।

— साइमन

"लातिन -1 से चिपके रहना भी आपको उचित अंग्रेजी लिखने की अनुमति नहीं देता है" यह एक अच्छी बात है, अन्यथा यूनिकोड का और भी मजबूत विरोध किया जाएगा। ;-)

— डेडुप्लिकेटर

@ Pa @loEbermann एंबेडेड NUL वर्णों का अर्थ है कि आपका डेटा एक बाइनरी बूँद है, न कि केवल एक स्ट्रिंग। NULs एक अजीब उदाहरण था, क्योंकि मेरा मानना ​​है कि UTF-8 \0एक बहु-बाइट एन्कोडिंग के हिस्से के रूप में कभी भी एक बाइट का उपयोग करने से बचता है , यह सुनिश्चित करने के लिए कि गैर-UTF8-जागरूक कोड एक स्ट्रिंग के बीच में बंद न हो।

— पीटर कोर्ड्स

सभी यूनिकोड वर्ण प्रिंट करने योग्य हैं - आपको बस सही फ़ॉन्ट की आवश्यकता है :-)

— जेम्स एंडरसन

@JamesAnderson फ़ॉन्ट तब गलत और टूट जाएगा। en.wikipedia.org/wiki/Unicode_control_characters

— djechlin

Answer 2

मुझे लगता है कि तकनीकी प्रश्न से परे, आपके बॉस के पास वर्तमान मानकों पर अद्यतित रहने का समय नहीं हो सकता है।

चूंकि उनका रुख पूरी तरह से दोपहर के भोजन के लिए नहीं है, बस आउट-डेटेड है, इस मामले पर चर्चा करते समय अपनी स्थिति का सम्मान करें (और आपको चर्चा करने के लिए याद रखने की जरूरत है , बहस नहीं), और उन चिंताओं के माध्यम से काम करने की कोशिश करें, जो यूटीएफ -8 के संबंध में हैं। मुझे संदेह है कि अंतर्निहित समस्या एक तकनीकी समस्या नहीं है और इसके लिए कुछ हद तक नरम-कौशल वार्ता की आवश्यकता हो सकती है।

Comments

मैं और मंजूर नहीं कर सका। वास्तव में मुझे खेद है कि अपने स्वयं के उत्तर में मैंने "मानवीय पक्ष" को पूरी तरह से अनदेखा कर दिया, जो इस मुद्दे में अच्छी तरह से सर्वोपरि हो सकता है। काश मैं एक से अधिक बार

— उत्थान कर पाता

लैटिन -1 के बाहर सब कुछ बुला bad characterऔर सोच ये हैं non-printableहै just out-datedआप के लिए?

— njzk2

असली मुद्दा यह है, "क्या यह एक तकनीकी मुद्दा है जिससे हम निपट रहे हैं?" मुझे विश्वास नहीं हो रहा है कि ओपी का बॉस स्कूल गया और उसे यह पढ़ाया गया, या कुछ तकनीकी मैनुअल / पत्रिका पढ़ी और उस निष्कर्ष पर पहुंचा। मुझे यह समझ में नहीं आता है कि समाधान सख्ती से तकनीकी समाधान है। विडंबना यह है कि टिप्पणी वास्तव में इस मुद्दे का दिल दिखाती है; अनुचित तरीके से किए जाने पर इस मुद्दे को संबोधित करना बेहद अपमानजनक हो सकता है।

— नेल्सन

Answer 3

हममें से कौन सही है?

एक बार की बात है, आपका बॉस था। लेकिन जैसे-जैसे समय बीतता है, चीजें बदल जाती हैं। आजकल, आप हैं (लेकिन अपने बॉस को चलाने से पहले, नेल्सन के उत्तर को भी अवश्य पढ़ें )।

MySQL के पुराने संस्करण, और ज्यादातर सब कुछ के पुराने संस्करण , UTF8 की तुलना में पुराने लैटिन 1 / ISO-8859-1 (5) के साथ बहुत बेहतर हैं।

एक कारण है कि UTF8 बनाया गया है, विकसित किया गया है, और ज्यादातर हर जगह धकेल दिया गया है: यदि ठीक से लागू किया जाता है, तो यह बहुत बेहतर काम करता है । कुछ प्रदर्शन और भंडारण मुद्दे हैं जो इस तथ्य से उपजा है कि एक लैटिन 1 वर्ण 8 बिट्स है, जबकि UTF8 वर्ण 8 से 32 बिट लंबा हो सकता है। इसलिए योजना बनाते समय VARCHARआपको इसे ध्यान में रखना होगा। और आपकी खोज रूटीन एक धीमी गति होगी। वे और अधिक काम करने के लिए सक्षम हो जाएगा (साथ जैसे खोजें लहजे संवेदनशीलता या बिना । व्यापक काम के बिना लेटिन 1 में उन लोगों के नहीं कर सकते हैं), लेकिन वे होगा थोड़ा और समय लगेगा।

लेकिन दूसरी ओर, भंडारण सस्ता है , फ़ाइल आकार पर यथार्थवादी ओवरहेड 2-3% से कम है, कंप्यूटिंग शक्ति भी सस्ती है और मूर के कानून के साथ अच्छे समझौते में सस्ता हो रहा है; जबकि आपका समय और आपके ग्राहकों की उम्मीदें निश्चित रूप से नहीं हैं ।

यदि आप ऐसे उपकरण विकसित करने वाले थे, तो आपको खोज उपकरणों आदि के लिए चिंता करनी पड़ सकती है । लेकिन आप शायद नहीं हैं। आप उन उपकरणों का उपयोग करते हैं; यहां तक ​​कि जो कल पूरी तरह से UTF8 के अनुरूप नहीं थे (जैसा कि पहले MySQLs नहीं थे), आज हैं, या जल्द ही होंगे (जैसे utf8mb4 समर्थन के साथ MySQL)।

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

इसलिए जब वे आपको यूटीएफ 8 डेटा भेजना शुरू करते हैं, तो आपको लैटिन 1 को बदलने और बदलने के लिए एक जटिल बातजामिग स्थापित करना होगा और अनचाहे मामलों से निपटना होगा।

जब आप बजट में फैक्टर को बुरे मोजिबेक नन्जेस के खिलाफ कई झड़पों का कारण बनाते हैं , और विचार करें कि वे दूर नहीं जा रहे हैं - जैसा कि आप पहले से ही खोज चुके हैं - तब आपको पता चलेगा कि यूटीएफ 8 जाना केवल सरल नहीं है, यह होने जा रहा है साथ ही सस्ता ।

Answer 4

कुछ परिस्थितियां जहां केवल ASCII पर निर्धारित चरित्र को सीमित करना हो सकता है, सीमित विकल्प फ़ील्ड, जैसे स्थिति फ़ील्ड्स के लिए समझ में आता है, क्योंकि आप कड़ाई से उन मानों को नियंत्रित कर सकते हैं जो हो सकते हैं, और बाहरी सिस्टम के लिए विदेशी कुंजी / संदर्भ, क्योंकि शायद ही कोई कारण हैं। उनके पास अल्फ़ान्यूमेरिक वर्णों और कुछ प्रतीकों के अलावा कुछ भी नहीं है।

किसी भी अन्य ग्रंथों के लिए, बस यूटीएफ -8 का उपयोग करें।

Comments

क्या MySQL में दुश्मनी नहीं है?

— raptortech97

और चूंकि ASCII UTF8 का सबसेट है, बस तब भी UTF8 का उपयोग करें।

— रेमकोगर्लिच

@RemcoGerlich: मैं असहमत हूं कि आप उन लोगों के लिए UTF8 का उपयोग कर सकते हैं। मेरे विचार में, बाहरी संदर्भ पाठ नहीं बल्कि बाइट्स का अपारदर्शी अनुक्रम है। उनके पास कोई सुविधा नहीं है सिवाय तर्कसंगत सुविधा के। यदि बाइट्स के अनुक्रम में कुछ गड़बड़ी की व्याख्या है, तो वह बाहरी सिस्टम या एप्लिकेशन का डोमेन है, न कि डेटाबेस का।

— रेयान

@ लिरियन: मैं उस बिंदु को देख रहा हूं, लेकिन फिर यह ASCII भी नहीं होना चाहिए, शायद कुछ बाइनरी ब्लॉब प्रारूप या तो।

— रेमकोगर्लिच

Answer 5

उत्तर के साथ शुरू करने के लिए, यह कोई फर्क नहीं पड़ता कि आपका सर्वर कैसे कॉन्फ़िगर किया गया है। MySQL में वर्ण एन्कोडिंग को प्रति कॉलम कॉन्फ़िगर किया जा सकता है (मतलब, एक ही तालिका कई एन्कोडिंग में वर्णों को पकड़ सकती है, आसान)। यानी मेरा सर्वर (और इसमें कई विरासत डेटाबेस) पुराने ग्राहकों के लिए डिफ़ॉल्ट रूप से cp1251 के लिए कॉन्फ़िगर किया गया है जो कनेक्ट (अलग हार्डवेयर क्लाइंट) पर सही टकराव सेट करने में असमर्थ हैं, लेकिन उत्पादन में मुख्य डेटाबेस सभी UTF-8 का उपयोग कर रहे हैं।

"बर्बाद अंतरिक्ष" की बात करते हुए - आप वास्तविक रूप से महत्वपूर्ण डेटा को बेकार नहीं कह सकते, क्या आप कर सकते हैं? संग्रहण स्थान वृद्धि, हालाँकि, आपके डेटा में मौजूद भाषा के आधार पर अलग-अलग होगी। यदि आपकी साइट मुख्य रूप से अंग्रेजी में है और 100% तक कम है, तो यदि यह ASCII रेंज के बाहर के वर्णों का उपयोग करके मेलानी है, तो महत्वहीन है। । और इससे भी अधिक, यदि आप पूर्व की ओर फिराते हैं। बाद में UTF-8 (तथाकथित UTF8mb4) विनिर्देश प्रति कोड बिंदु तक 4 बाइट्स की अनुमति देते हैं।

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

Comments

MySQL स्तंभ एन्कोडिंग में परिवर्तित करने से पहले डेटाबेस एन्कोडिंग में डेटा परिवर्तित करने का प्रयास करेगा। यदि आपके पास utf8 क्लाइंट, latin1 डेटाबेस और utf8 कॉलम है, तो टेक्स्ट डेटा खो सकता है।

— इवान सोलेंटसेव

इवान, यह एक पूरी तरह से अलग सवाल है। कैरेक्टर-सेट-क्लाइंट, कैरेक्टर-सेट-सर्वर, कैरेक्टर-सेट-कनेक्शन, कैरेक्टर-सेट-रिजल्ट के बीच का अंतर MySQL प्रलेखन में एक लंबा लेख है। और प्रति-कॉलम समतलीकरण सेटिंग्स के मामले में, "डेटाबेस कोलाजेशन" कॉलम कोलेशन है, और यह डेटाबेस कोलाज को अनदेखा करते हुए सीधे चरित्र-सेट-परिणाम में बदल जाता है।

— अरादमन

Answer 6

बस उसे समझाएँ कि UTF-8 वेब ट्रैफ़िक के लिए डिफ़ॉल्ट है। और कोई भी उपयोगकर्ता अपने ब्राउज़र में किसी भी वैध यूनिकोड चरित्र को दर्ज कर सकता है।

Utf-8-> latin-1-> utf-8 से उत्पन्न होने वाले कई और विभिन्न मुद्दों से निपटने के लिए फ्रंट-एंड से बैक-एंड तक सभी तरह से यूएफ -8 / यूनिकोड होना बहुत आसान है।