unicode - यूनिकोड में हम सब कुछ क्यों नहीं करते?




internationalization (12)

यह देखते हुए कि यूनिकोड 18 साल से आसपास रहा है , फिर भी ऐसे ऐप्स क्यों हैं जिनके पास यूनिकोड समर्थन नहीं है? यहां तक ​​कि कुछ ऑपरेटिंग सिस्टम और यूनिकोड के साथ भी मेरे अनुभव कम से कम कहने के लिए दर्दनाक रहे हैं। जैसा कि 2003 में जोएल स्पॉस्की ने बताया, यह मुश्किल नहीं है। तो सौदा क्या है? हम इसे एक साथ क्यों नहीं मिल सकते हैं?


कुछ प्रश्नों से शुरू करें

कितनी बार...

  • क्या आपको ऐसे एप्लिकेशन को लिखने की ज़रूरत है जो एएससीआई से कुछ और संबंधित है?
  • क्या आपको बहु भाषा आवेदन लिखने की ज़रूरत है?
  • क्या आप एक ऐसा एप्लिकेशन लिखते हैं जिसे अपने पहले संस्करण से बहु भाषा होनी चाहिए?
  • क्या आपने सुना है कि यूनिकोड का उपयोग गैर-असीसी वर्णों का प्रतिनिधित्व करने के लिए किया जाता है?
  • क्या आपने पढ़ा है कि यूनिकोड एक वर्णमाला है? वह यूनिकोड एक एन्कोडिंग है?
  • क्या आप लोगों को यूटीएफ -8 एन्कोडेड बाइटस्टरींग और यूनिकोड डेटा को भ्रमित करते हुए देखते हैं?

क्या आप एक संयोजन और एन्कोडिंग के बीच अंतर जानते हैं?

आपने पहली बार यूनिकोड के बारे में सुना था?

  • विद्यालय में? ( वास्तव में? )
  • काम पर?
  • एक आधुनिक ब्लॉग पर?

क्या आपने कभी अपने युवा दिनों में, लोकेल ए में एक सिस्टम से लोकल बी में एक सिस्टम से चलने वाली स्रोत फ़ाइलों को अनुभव किया है, सिस्टम बी पर एक टाइपो संपादित किया है, फाइलों को सहेजा है, सभी गैर-असीसी टिप्पणियों को b0rking और ... समाप्त हो रहा है क्या हुआ यह समझने की कोशिश कर बहुत समय बर्बाद कर रहा था? (क्या आपका संपादक चीजों को मिलाता है? कंपाइलर? सिस्टम? ...?)

क्या आप यह निर्णय लेते हैं कि गैर-असीसी वर्णों का उपयोग करके आप कभी भी अपने कोड पर टिप्पणी नहीं करेंगे?

कहीं और क्या किया जा रहा है पर एक नज़र डालें

अजगर

क्या मैंने एसओ पर उल्लेख किया कि मुझे पाइथन पसंद है? नहीं? खैर मुझे पाइथन पसंद है।

लेकिन Python3.0 तक, इसके यूनिकोड समर्थन चूसा। और उन सभी रूकी प्रोग्रामर थे, जो उस समय एक लूप लिखने के लिए मुश्किल से जानते थे, गैर- UnicodeEncodeError से निपटने की कोशिश करते समय UnicodeEncodeError UnicodeDecodeError और UnicodeEncodeError कहीं भी नहीं मिला। वैसे वे मूल रूप से यूनिकोड राक्षस द्वारा जीवन-पीड़ित हो गए, और मुझे बहुत सारे कुशल / अनुभवी पायथन कोडर्स पता हैं जो आज भी यूनिकोड डेटा से निपटने के विचार के बारे में डरते हैं।

और पायथन 3 के साथ, यूनिकोड और बाइटस्टरीज़ के बीच एक स्पष्ट अलगाव है, लेकिन ... देखें कि पाइथन 2.x से पायथन 3.x तक किसी एप्लिकेशन को पोर्ट करना कितना परेशानी है यदि आपने पहले अलगाव / यदि आप वास्तव में समझ नहीं पाते कि यूनिकोड क्या है।

डेटाबेस, पीएचपी

क्या आप एक लोकप्रिय वाणिज्यिक वेबसाइट जानते हैं जो यूनिकोड के रूप में अपना अंतर्राष्ट्रीय पाठ संग्रहीत करता है?

आप (शायद) यह जानकर आश्चर्यचकित होंगे कि विकिपीडिया बैकएंड यूनिकोड का उपयोग करके अपना डेटा संग्रहीत नहीं करता है। सभी पाठ यूटीएफ -8 में एन्कोड किए गए हैं और डेटाबेस में बाइनरी डेटा के रूप में संग्रहीत हैं।

यहां एक महत्वपूर्ण मुद्दा यह है कि यदि आप इसे यूनिकोड कोडपॉइंट्स के रूप में संग्रहीत करते हैं तो टेक्स्ट डेटा को सॉर्ट करना है। यहां यूनिकोड कॉलेशन आता है, जो यूनिकोड कोडपॉइंट्स पर सॉर्टिंग ऑर्डर को परिभाषित करता है। लेकिन डेटाबेस में collations के लिए उचित समर्थन गायब है / सक्रिय विकास में है। (शायद कई प्रदर्शन मुद्दे भी हैं। - IANADBA) इसके अलावा, अभी तक collations के लिए कोई व्यापक रूप से स्वीकार्य मानक नहीं है: कुछ भाषाओं के लिए, लोग इस बात से सहमत नहीं हैं कि शब्दों / अक्षरों / शब्द समूह को कैसे हल किया जाना चाहिए।

क्या आपने यूनिकोड सामान्यीकरण के बारे में सुना है? (मूल रूप से, आपको इसे संग्रहीत करने से पहले अपने यूनिकोड डेटा को एक कैनोलिक प्रतिनिधित्व में परिवर्तित करना चाहिए ) बेशक यह डाटाबेस स्टोरेज, या स्थानीय तुलना के लिए महत्वपूर्ण है। लेकिन उदाहरण के लिए PHP केवल 5.2.4 के बाद सामान्यीकरण के लिए समर्थन प्रदान करता है जो अगस्त 2007 में सामने आया था।

और वास्तव में, PHP अभी तक यूनिकोड का पूरी तरह से समर्थन नहीं करता है। हमें यूनिकोड-संगत कार्यों को हर जगह प्राप्त करने के लिए PHP6 का इंतजार करना होगा।

तो, यूनिकोड में हम सब कुछ क्यों नहीं करते?

  1. कुछ लोगों को यूनिकोड की आवश्यकता नहीं है।
  2. कुछ लोग परवाह नहीं करते हैं।
  3. कुछ लोग समझ में नहीं आते कि उन्हें बाद में यूनिकोड समर्थन की आवश्यकता होगी
  4. कुछ लोग यूनिकोड को नहीं समझते हैं।
  5. कुछ अन्य लोगों के लिए, यूनिकोड वेबपैप्स के लिए पहुंच की तरह थोड़ा सा है: आप बिना शुरू करते हैं, और बाद में इसके लिए समर्थन जोड़ देंगे
  6. बहुत से लोकप्रिय पुस्तकालयों / भाषाओं / अनुप्रयोगों में उचित कमी है, पूर्ण यूनिकोड समर्थन, संयोजन और सामान्यीकरण मुद्दों का उल्लेख नहीं करना। और जब तक आपके विकास स्टैक में सभी आइटम यूनिकोड का पूरी तरह समर्थन नहीं करते हैं, तो आप एक स्वच्छ यूनिकोड एप्लिकेशन नहीं लिख सकते हैं।

इंटरनेट स्पष्ट रूप से यूनिकोड प्रवृत्ति फैलाने में मदद करता है। और यह एक अच्छी बात है। पाइथन 3 ब्रेकिंग परिवर्तन जैसी पहल लोगों को इस मुद्दे के बारे में शिक्षित करने में मदद करती हैं। लेकिन हमें हर जगह यूनिकोड देखने के लिए धैर्यपूर्वक इंतजार करना होगा और नए प्रोग्रामर सहज रूप से स्ट्रिंग्स के बजाय यूनिकोड का उपयोग कर सकते हैं जहां यह महत्वपूर्ण है।

उपेक्षा के लिए, क्योंकि फेडेक्स स्पष्ट रूप से अंतरराष्ट्रीय पते का समर्थन नहीं करता है, Google ग्रीष्मकालीन कोड '0 9 छात्रों को सभी ने Google द्वारा शिपिंग के लिए एक असीमित नाम और पता प्रदान करने के लिए कहा है। यदि आपको लगता है कि अधिकांश व्यावसायिक अभिनेता यूनिकोड समर्थन के पीछे हिस्से को समझते हैं, तो आप गलत हैं। FedEx समझ में नहीं आता है, और उनके ग्राहकों को वास्तव में परवाह नहीं है। फिर भी।


अधिक ओवरहेड, अंतरिक्ष आवश्यकताओं।


एक बड़ा कारक प्रोग्रामिंग भाषा समर्थन है, जिनमें से अधिकांश एक चरित्र सेट का उपयोग करते हैं जो 8 बिट्स (जैसे ASCII) में स्ट्रिंग के लिए डिफ़ॉल्ट के रूप में फिट बैठता है। जावा की स्ट्रिंग क्लास यूटीएफ -16 का उपयोग करती है, और ऐसे कुछ भी हैं जो यूनिकोड के रूपों का समर्थन करते हैं, लेकिन कई भाषाएं सादगी का विकल्प चुनती हैं। अंतरिक्ष इन दिनों चिंता का इतना छोटा है कि "अंतरिक्ष कुशल" तारों से चिपकने वाले कोडर को थप्पड़ मारना चाहिए। अधिकांश लोग बस एम्बेडेड डिवाइस पर नहीं चल रहे हैं, और यहां तक ​​कि सेल फोन जैसे डिवाइस (निकट भविष्य की बड़ी कंप्यूटिंग लहर) आसानी से 16-बिट चरित्र सेट को संभाल सकते हैं।

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

इसके लायक होने के लिए, मुझे नहीं लगता कि यूनिकोड मानक की जटिलता प्रोग्रामर के लिए एक योगदान कारक का बड़ा नहीं है, बल्कि उन लोगों के लिए जो भाषा समर्थन को लागू करना चाहते हैं। एक ऐसी भाषा में प्रोग्रामिंग करते समय जहां कड़ी मेहनत पहले से ही हो चुकी है, हाथों में उपकरणों का उपयोग न करने का भी कम कारण है। C'est la vie, पुरानी आदतें मर जाती हैं।


क्योंकि 99% अनुप्रयोगों के लिए, यूनिकोड समर्थन ग्राहक के उत्पाद तुलना मैट्रिक्स पर एक चेकबॉक्स नहीं है।

समीकरण में जोड़ें:

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

परंपरा और रवैया। ASCII और कंप्यूटर दुखद रूप से कई लोगों के समानार्थी हैं।

हालांकि, यह सोचने के लिए भद्दा होगा कि यूनिकोड का रोल, यूरेशिया और दुनिया के अन्य हिस्सों से विदेशी भाषाओं का मामला है। एक समृद्ध टेक्स्ट एन्कोडिंग में "सादे" अंग्रेजी पाठ को लाने के लिए बहुत अधिक अर्थ है। कभी-कभी एक किताब में देखो।


मुझे संदेह है क्योंकि यह पश्चिम में ऐसी मजबूत जड़ें है। यदि आप अमेरिका में रहते हैं तो यूटीएफ -8 एक अच्छा, कॉम्पैक्ट प्रारूप है। लेकिन यदि आप एशिया में रहते हैं तो यह इतना गर्म नहीं है। ;)


मैं व्यक्तिगत रूप से यह पसंद नहीं करता कि यूनिकोड के कुछ प्रारूप इसे कैसे तोड़ते हैं ताकि आप तीसरे चरित्र को प्राप्त करने के लिए स्ट्रिंग [3] नहीं कर सकें। निश्चित रूप से यह समझा जा सकता है, लेकिन कल्पना करें कि तारों के साथ एक बड़ी परियोजना कितनी धीमी है, जैसे जीसीसी होगा अगर उसे एनएच चरित्र को समझने के लिए एक स्ट्रिंग को पार करना पड़ा। एकमात्र विकल्प कैशिंग है जहां "उपयोगी" स्थितियां हैं और फिर भी यह धीमी है, और कुछ प्रारूपों में अब आप प्रति चरित्र 5 बाइट्स ले रहे हैं। मेरे लिए, यह सिर्फ हास्यास्पद है।


यह आसान है। क्योंकि हमारे पास हमारे कीबोर्ड पर केवल ASCII वर्ण हैं, हम कभी भी उन लोगों के अलावा अन्य पात्रों का सामना क्यों करेंगे या उनकी परवाह नहीं करेंगे? यह इतना रवैया नहीं है क्योंकि ऐसा तब होता है जब किसी प्रोग्रामर को इस मुद्दे के बारे में कभी सोचना नहीं पड़ता है, या कभी इसका सामना नहीं किया जाता है, शायद यह भी नहीं पता कि यूनिकोड क्या है।

संपादित करें: एक और तरीका रखो, यूनिकोड ऐसा कुछ है जिसके बारे में आपको सोचना है, और सोच ऐसा कुछ नहीं है जो अधिकांश लोग करने में रुचि रखते हैं, यहां तक ​​कि प्रोग्रामर भी।


यूनिकोड को अधिक काम (सोचने) की आवश्यकता होती है, आमतौर पर आपको केवल वही भुगतान किया जाता है जो आपको आवश्यक है, ताकि आप सबसे तेज़ कम जटिल विकल्प के साथ जाएं।

वैसे यह मेरे दृष्टिकोण से है। मुझे लगता है कि अगर आप std::wstring hw(L"hello world") का उपयोग करने के लिए कोड की अपेक्षा करते हैं तो आपको यह समझाना होगा कि यह कैसे काम करता है कि wcout प्रिंट करने के लिए यह सब काम करता है आपको wcout आवश्यकता है: std::wcout << hw << std::endl; (मुझे लगता है), (लेकिन endl ठीक लगता है ..) ... ऐसा लगता है कि मेरे लिए और अधिक काम है - बेशक अगर मैं अंतरराष्ट्रीय ऐप लिख रहा था तो मुझे इसे समझने में निवेश करना होगा, लेकिन तब तक मैं नहीं (जैसा कि मुझे ज्यादातर डेवलपर्स पर संदेह है)।

मुझे लगता है कि यह पैसे वापस चला जाता है, समय पैसा है।


शायद क्योंकि लोग ASCII के लिए उपयोग किए जाते हैं और बहुत सारे प्रोग्रामिंग देशी अंग्रेजी बोलने वालों द्वारा किया जाता है।

आईएमओ, यह सचेत विकल्प की बजाय सामूहिक आदत का एक कार्य है।


हाल ही में सभी ऑपरेटिंग सिस्टम इस धारणा पर बनाए गए थे कि एक चरित्र बाइट था। यह एपीआई इस तरह बनाया गया था, उपकरण इस तरह बनाया गया था, भाषाओं को इस तरह बनाया गया था।

हां, यह बेहतर होगा अगर मैंने जो कुछ भी लिखा था वह पहले से ही था ... गलती ... यूटीएफ -8? UTF-16? UTF-7? UTF-32? एर ... mmm ... ऐसा लगता है कि जो कुछ भी आप चुनते हैं, आप किसी को परेशान करेंगे। और, वास्तव में, यह सच है।

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

और, फिर यूटीएफ -32 ... अच्छा, यह चार बाइट्स है। 10 साल पहले औसत हार्ड ड्राइव आकार या स्मृति आकार क्या था? यूटीएफ -32 बहुत बड़ा था!

इसलिए, एकमात्र समाधान सबकुछ बदलना है - सॉफ़्टवेयर, उपयोग, ऑपरेटिंग सिस्टम, भाषाएं, टूल्स - साथ ही i18n-aware होने के लिए। कुंआ। "एक ही समय में" के साथ शुभकामनाएँ।

और अगर हम एक ही समय में सबकुछ नहीं कर सकते हैं, तो हमें हमेशा सामानों के लिए नजर रखना होगा जो i18n नहीं है। जो एक दुष्चक्र का कारण बनता है।

मिडलवेयर या मूल सॉफ्टवेयर की तुलना में अंतिम उपयोगकर्ता अनुप्रयोगों के लिए यह आसान है, और कुछ नई भाषाओं को इस तरह बनाया जा रहा है। लेकिन ... हम अभी भी 60 के दशक में लिखे गए फोरट्रान पुस्तकालयों का उपयोग करते हैं। वह विरासत, यह दूर नहीं जा रहा है।


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

नीचे की रेखा - लागत।





internationalization