कौन से मुद्दे लोगों को यूनिकोड के बजाय जापानी-विशिष्ट एन्कोडिंग का उपयोग करने के लिए प्रेरित करते हैं?

24

काम के दौरान मैं Shift-JIS और अन्य एन्कोडिंग में बहुत सारी जापानी पाठ फ़ाइलों पर आता हूं। यह सभी कंप्यूटर उपयोगकर्ताओं के लिए कई मोज़िबेक (अपठनीय चरित्र) समस्याओं का कारण बनता है । यूनिकोड का उद्देश्य सभी भाषाओं के लिए एकल वर्ण को परिभाषित करके इस तरह की समस्या को हल करना था, और इंटरनेट पर उपयोग के लिए UTF-8 क्रमांकन की सिफारिश की जाती है। तो हर कोई जापानी-विशिष्ट एन्कोडिंग से UTF-8 पर स्विच क्यों नहीं करता है? UTF-8 के साथ क्या समस्याएं हैं या लोगों को वापस पकड़ रही हैं?

संपादित करें: W3C यूनिकोड के साथ कुछ ज्ञात समस्याओं को सूचीबद्ध करता है , क्या यह भी एक कारण हो सकता है?

legacy unicode character-encoding

— निकोलस राउल
स्रोत

वास्तव में अधिक से अधिक लोकप्रिय साइटें यूटीएफ -8 में हैं, एक उदाहरण コニコ動画 sites और な sites は है

— केन ली

8

हर कोई ISO-8851-1 से UTF-8 पर स्विच क्यों नहीं करता है?

— ysdx

1

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

— काइल स्ट्रैंड

@KyleStrand देखें support.microsoft.com/en-us/help/170559/…

— लुडविग शुल्ज़

@LudwigSchulze धन्यवाद अभी भी बहुत विस्तार नहीं है, लेकिन कम से कम एक आधिकारिक स्रोत ...

— काइल स्ट्रैंड

28

एक शब्द में: विरासत।

यूनिकोड उपलब्ध / लोकप्रिय होने से पहले शिफ्ट-जेआईएस और अन्य एन्कोडिंग का उपयोग किया गया था, क्योंकि यह जापानी को पूरी तरह से एनकोड करने का एकमात्र तरीका था। कंपनियों ने बुनियादी ढांचे में निवेश किया है जो केवल Shift-JIS का समर्थन करता है। यहां तक कि अगर है कि बुनियादी ढांचे अब यूनिकोड का समर्थन करता है, वे अभी भी विभिन्न से लेकर कारणों के लिए Shift-JIS के साथ फंस रहे हैं यह काम करता है-तो-इसे स्पर्श-यह अधिक एन्कोडिंग-क्या? करने के लिए पलायन-सभी मौजूदा-दस्तावेजों-है के लिए भी महंगा ।

कई पश्चिमी कंपनियां हैं जो अभी भी एएससीआईआई या लैटिन -1 का उपयोग एक ही कारणों से कर रही हैं, केवल कोई भी नोटिस नहीं करता है क्योंकि यह कभी भी समस्या पैदा नहीं करता है।

— deceze
स्रोत

8

जापानी सॉफ्टवेयर उद्योग ... नए सॉफ्टवेयर / मानकों का उपयोग करने में गंदगी की तुलना में धीमी।

— मार्क होसांग

2

@ मार्कर ट्रूअर शब्द बोले गए थे! (मैं जापानी आईटी के साथ / में काम कर रहा हूँ ... -_- ;;)

— deceze

5

यह सच है, लेकिन पश्चिमी कंपनियों का बहाना है कि हमारी विरासत सॉफ्टवेयर हार्ड-कोडित मान्यताओं से भरी है, जो 1 बाइट = 1 वर्ण है, जो लंबे समय से एमबीसीएस-क्लीन कोड लिखने के लिए यूटीएफ -8 के लिए संक्रमण को कठिन बनाता है।

— dan04

@ मार्खोसंग मैं पुष्टि करता हूं कि आपका कथन 100% सही है (मैं टोक्यो में जापानी कंपनी के लिए काम करता हूं)

— हसन तारेक

9

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

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

जाहिरा तौर पर, यह तर्क जापानी उपयोगकर्ताओं द्वारा उतना ही हास्यास्पद माना जाता है जितना कि अंग्रेजी पाठकों को यह तर्क देना होगा कि, क्योंकि लैटिन वर्णमाला ग्रीक वर्णमाला से विकसित हुई है, यह ग्रीक अल्फ़ा के लिए केवल एक ही कोड बिंदु होना पर्याप्त है। α "और लैटिन" ए ", और उपयोग में फ़ॉन्ट द्वारा उपस्थिति का फैसला किया जाए। ("Same" = "बी", "=" = "जी", आदि के लिए समान)

(ध्यान दें कि मैं स्टेक्सएक्सचेंज पर यहां ग्रीक वर्णों को शामिल नहीं कर पाऊंगा अगर ऐसा होता।)

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

और भी कारण दिए गए होंगे जो मुझे अब याद नहीं हैं।

— लुडविग शूल्ज़े
स्रोत

ऐसा प्रतीत होता है कि 2.0 के रूप में रूबी ने यूटीएफ -8 को डिफ़ॉल्ट के रूप में अपनाया। लेकिन हान एकीकरण यूनिकोड की दुनिया में एक बहुत ही महत्वपूर्ण शिकन (और काफी विवादास्पद मुद्दा ) प्रतीत होता है जो कि स्पष्ट रूप से पर्याप्त ध्यान नहीं देता है, क्योंकि मैंने इसके बारे में पहले कभी नहीं सुना है।

— काइल स्ट्रैंड

और यहाँ हान एकीकरण मुद्दे पर एक विकिपीडिया लेख है: en.wikipedia.org/wiki/Han_unification यह वास्तव में एक वैध मुद्दा है, बहुत अच्छा लगता है! इसके अलावा, तारीख का नुकसान एक अच्छा कारण होगा।

— 13-22

8

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

— बस मेरा सही विकल्प है
स्रोत

7

हालांकि यह सच है, वहाँ हमेशा UTF-16 का विकल्प होता है, जो Shift-JIS की तरह कुशल हो सकता है। मैं यह भी तर्क दूंगा कि अलग-अलग एनकोडिंग से निपटने का सिरदर्द इस दिन और उम्र में आकार में मामूली वृद्धि को दर्शाता है। इसे दूसरे तरीके से रखने के लिए, मैंने कभी भी शिफ्ट-जेआईएस के लिए दक्षता का तर्क कभी नहीं सुना है। ;-)

— deceze

5

मैंने सुस्ती और जड़ता के बहाने के रूप में इस्तेमाल की जाने वाली दक्षता के मुद्दे को सुना है, हालांकि।

— JUST MY सही OPINION

1

UTF-16 बुनियादी ASCII वर्ण बनाता है [जिनमें से HTML में एक बड़े आकार की संख्या है] दो बार बड़े के रूप में। जैसा कि मैंने इसे समझा, यह वास्तव में UTF-16 को जापानी वेबपृष्ठों के लिए UTF-8 से भी बदतर बना रहा है।

— 138

2

@ जस्ट माय सही ओपिनियन: "सोर्स देखें" या समकक्ष की कोशिश करें। सभी वास्तविक पाठ जापानी में हैं, यह मानते हुए कि बहुत सारे कीवर्ड हैं और जैसे कि अंग्रेजी से प्राप्त किए गए हैं, और ASCII में दर्शाए गए हैं।

— डेविड थॉर्नले

4

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

— जुलिएन गुर्टाल्ट

2

प्राथमिक कारणों के बीच स्ट्रिंग आकार / स्मृति उपयोग की गणना करें।

UTF-8 में, पूर्व-एशियाई भाषाओं को अक्सर अपने पात्रों के लिए 3 या अधिक बाइट्स की आवश्यकता होती है। UTF-16 का उपयोग करने की तुलना में औसतन उन्हें 50% अधिक मेमोरी की आवश्यकता होती है - जिनमें से पहले से ही देशी एन्कोडिंग की तुलना में कम कुशल है।

अन्य मुख्य कारण विरासत के रूप में, धोखे से इंगित किया जाएगा।

— डेनिस डी बर्नार्डी
स्रोत

2

विरासत और भंडारण आकार, जैसा कि अन्य ने कहा, लेकिन एक और बात है: कटकाना पात्र।

शिफ्ट-जेआईएस में कटकाना वर्णों का प्रतिनिधित्व करने के लिए केवल एक बाइट लगती है, इसलिए कटकाना सहित जापानी पाठ में प्रति वर्ण 2 बाइट्स (1.5 (50/50 मिश्रण के लिए 1.5) से कम समय लगता है, जिससे शिफ्ट-जेआईएस UTF-16 (2 बाइट्स) की तुलना में कुछ अधिक कुशल हो जाता है / char), और UTF-8 (3 बाइट्स / चार) की तुलना में बहुत अधिक कुशल है।

सस्ते भंडारण ने इसे बहुत छोटी समस्या बना दिया है, लेकिन स्पष्ट रूप से नहीं।

— azheglov
स्रोत