perl आधुनिक पर्ल डिफ़ॉल्ट रूप से यूटीएफ-8 से क्यों बचता है?




unicode utf-8 (5)

यूनिकोड टेक्स्ट को प्रोसेस करने के दो चरण हैं। पहला यह है कि "मैं इसे कैसे इनपुट कर सकता हूं और जानकारी खोए बिना इसे आउटपुट कर सकता हूं"। दूसरा यह है कि "मैं स्थानीय भाषा सम्मेलनों के अनुसार पाठ का इलाज कैसे करूं"।

tchrist की पोस्ट दोनों को कवर करती है, लेकिन दूसरा भाग वह है जहां उसकी पोस्ट में 99% टेक्स्ट आता है। अधिकांश कार्यक्रम I / O को सही तरीके से संभाल भी नहीं लेते हैं, इसलिए यह समझना महत्वपूर्ण है कि इससे पहले कि आप सामान्यीकरण और संयोजन के बारे में भी चिंता करें।

इस पोस्ट का उद्देश्य उस पहली समस्या को हल करना है

जब आप पर्ल में डेटा पढ़ते हैं, तो यह परवाह नहीं करता कि यह एन्कोडिंग क्या है। यह कुछ स्मृति आवंटित करता है और वहां बाइट को दूर करता है। यदि आप print $str कहते हैं, तो यह केवल उन बाइट्स को आपके टर्मिनल पर छोड़ देता है, जो संभवतः यूटीएफ -8 है जो सब कुछ मानने के लिए सेट है, और आपका टेक्स्ट दिखाता है।

अद्भुत।

इसके अलावा, यह नहीं है। यदि आप डेटा को टेक्स्ट के रूप में पेश करने का प्रयास करते हैं, तो आप देखेंगे कि कुछ बुरा हो रहा है। आपको यह देखने के लिए length से आगे नहीं जाना चाहिए कि पर्ल आपकी स्ट्रिंग के बारे में क्या सोचता है और आप अपनी स्ट्रिंग असहमत के बारे में क्या सोचते हैं। एक-लाइनर लिखें जैसे: perl -E 'while(<>){ chomp; say length }' perl -E 'while(<>){ chomp; say length }' और टाइप करें 文字化け और आपको 12 मिलते हैं ... सही उत्तर नहीं, 4।

ऐसा इसलिए है क्योंकि पर्ल मानता है कि आपकी स्ट्रिंग टेक्स्ट नहीं है। आपको यह बताना होगा कि इससे पहले कि यह आपको सही जवाब देगा इससे पहले कि यह टेक्स्ट है।

यह काफी आसान है; एनकोड मॉड्यूल में ऐसा करने के लिए कार्य हैं। सामान्य प्रविष्टि बिंदु Encode::decode (या निश्चित use Encode qw(decode) )। यह कार्य बाहरी दुनिया से कुछ स्ट्रिंग लेता है (जिसे हम "ऑक्टेट्स" कहते हैं, "8-बिट बाइट्स" कहने का तरीका है), और इसे कुछ पाठ में बदल देता है जिसे पर्ल समझ जाएगा। पहला तर्क एक वर्ण एन्कोडिंग नाम है, जैसे "यूटीएफ -8" या "ASCII" या "ईयूसी-जेपी"। दूसरा तर्क स्ट्रिंग है। वापसी मूल्य पर्ल स्केलर है जिसमें पाठ होता है।

( Encode::decode_utf8 भी है, जो एन्कोडिंग के लिए यूटीएफ -8 मानता है।)

अगर हम अपने एक लाइनर को फिर से लिखते हैं:

perl -MEncode=decode -E 'while(<>){ chomp; say length decode("UTF-8", $_) }'

हम 文字 化 け टाइप करते हैं और परिणाम के रूप में "4" प्राप्त करते हैं। सफलता।

वह, ठीक है, पर्ल में 99% यूनिकोड समस्याओं का समाधान है।

कुंजी यह है कि, जब भी कोई प्रोग्राम आपके प्रोग्राम में आता है, तो आपको इसे डीकोड करना होगा। इंटरनेट अक्षर प्रेषित नहीं कर सकता है। फ़ाइलें पात्रों को स्टोर नहीं कर सकती हैं। आपके डेटाबेस में कोई वर्ण नहीं हैं। केवल ऑक्टेट्स हैं, और आप पर्ल में वर्णों के रूप में ऑक्टेट्स का इलाज नहीं कर सकते हैं। आपको एनकोड मॉड्यूल के साथ पर्ल अक्षरों में एन्कोडेड ऑक्टेट को डीकोड करना होगा।

समस्या का दूसरा आधा आपके प्रोग्राम से डेटा प्राप्त कर रहा है। यह आसान है; आप बस use Encode qw(encode) , यह तय करें कि आपके डेटा में एन्कोडिंग क्या होगा (यूटीएफ -8 टर्मिनल जो यूटीएफ -8, यूटीएफ -16 को विंडोज़ पर फाइलों के लिए समझते हैं), और फिर encode($encoding, $data) के परिणाम आउटपुट encode($encoding, $data) केवल $data आउटपुट करने के बजाय।

यह ऑपरेशन पर्ल के पात्रों को परिवर्तित करता है, जो आपके प्रोग्राम पर चल रहा है, जो ऑक्टेट्स के लिए बाहरी दुनिया द्वारा उपयोग किया जा सकता है। यह बहुत आसान होगा अगर हम सिर्फ इंटरनेट पर या हमारे टर्मिनल पर अक्षर भेज सकते हैं, लेकिन हम नहीं कर सकते: केवल ऑक्टेट्स। इसलिए हमें अक्षरों को ऑक्टेट में परिवर्तित करना है, अन्यथा परिणाम अपरिभाषित हैं।

संक्षेप में: सभी आउटपुट एन्कोड करें और सभी इनपुट डीकोड करें।

अब हम तीन मुद्दों के बारे में बात करेंगे जो इसे थोड़ा चुनौतीपूर्ण बनाते हैं। पहला पुस्तकालय है। क्या वे पाठ को सही तरीके से संभालते हैं? जवाब है ... वे कोशिश करते हैं। यदि आप एक वेब पेज डाउनलोड करते हैं, तो एलडब्लूपी आपको अपना परिणाम टेक्स्ट के रूप में वापस देगा। यदि आप परिणाम पर सही विधि कहते हैं, तो यह है (और यह decoded_content होता है, content नहीं, जो कि सर्वर से प्राप्त ऑक्टेट स्ट्रीम है।) डेटाबेस ड्राइवर flaky हो सकता है; यदि आप केवल पर्ल के साथ डीबीडी :: एसक्यूएलसाइट का उपयोग करते हैं, तो यह काम करेगा, लेकिन अगर किसी अन्य टूल ने आपके डेटाबेस में यूटीएफ -8 के अलावा कुछ एन्कोडिंग के रूप में टेक्स्ट को संग्रहीत किया है ... अच्छा ... यह सही ढंग से संभाला नहीं जा रहा है जब तक आप इसे सही तरीके से संभालने के लिए कोड लिखते हैं।

आउटपुट डेटा आमतौर पर आसान होता है, लेकिन यदि आप "प्रिंट में विस्तृत वर्ण" देखते हैं, तो आप जानते हैं कि आप कहीं भी एन्कोडिंग को गड़बड़ कर रहे हैं। उस चेतावनी का अर्थ है "अरे, आप बाहरी दुनिया में पर्ल पात्रों को रिसाव करने की कोशिश कर रहे हैं और इससे कोई अर्थ नहीं आता है"। आपका प्रोग्राम काम करने लगता है (क्योंकि दूसरा अंत आमतौर पर कच्चे पर्ल अक्षरों को सही तरीके से संभालता है), लेकिन यह बहुत टूटा हुआ है और किसी भी समय काम करना बंद कर सकता है। इसे एक स्पष्ट Encode::encode साथ ठीक करें!

दूसरी समस्या यूटीएफ -8 एन्कोडेड स्रोत कोड है। जब तक आप प्रत्येक फ़ाइल के शीर्ष पर use utf8 नहीं करते हैं, तो पर्ल यह नहीं मान पाएगा कि आपका स्रोत कोड यूटीएफ -8 है। इसका मतलब यह है कि हर बार जब आप my $var = 'ほげ' तरह कुछ कहते हैं, तो आप अपने प्रोग्राम में कचरा इंजेक्शन दे रहे हैं जो पूरी तरह से सबकुछ तोड़ देगा। आपको "utf8 का उपयोग करने" की आवश्यकता नहीं है, लेकिन यदि आप नहीं करते हैं, तो आपको अपने प्रोग्राम में किसी भी गैर-ASCII वर्णों का उपयोग नहीं करना चाहिए

तीसरी समस्या यह है कि पर्ल ने अतीत को कैसे संभाला। बहुत समय पहले, यूनिकोड जैसी कोई चीज़ नहीं थी, और पर्ल ने माना कि सबकुछ लैटिन -1 टेक्स्ट या बाइनरी था। तो जब डेटा आपके प्रोग्राम में आता है और आप इसे टेक्स्ट के रूप में पेश करना शुरू करते हैं, तो पर्ल प्रत्येक ऑक्टेट को लैटिन -1 वर्ण के रूप में मानता है। यही कारण है कि, जब हमने "文字 化 け" की लंबाई मांगी, तो हमें 12 मिल गया। पर्ल ने माना कि हम लैटिन -1 स्ट्रिंग "æååã" (जो 12 वर्ण हैं, जिनमें से कुछ गैर-प्रिंटिंग हैं) पर काम कर रहे थे।

इसे "निहित अपग्रेड" कहा जाता है, और यह करने के लिए एक पूरी तरह से उचित बात है, लेकिन यह नहीं है कि आप क्या चाहते हैं यदि आपका टेक्स्ट लैटिन -1 नहीं है। यही कारण है कि इनपुट को स्पष्ट रूप से डीकोड करना महत्वपूर्ण है: यदि आप ऐसा नहीं करते हैं, तो पर्ल होगा, और यह गलत हो सकता है।

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

यहां एक उदाहरण दिया गया है: आपके पास एक प्रोग्राम है जो यूटीएफ -8-एन्कोडेड टेक्स्ट फ़ाइल पढ़ता है, आप प्रत्येक लाइन PILE OF POO यूनिकोड PILE OF POO पर काम करते हैं, और आप इसे प्रिंट करते हैं। आप इसे लिखते हैं:

while(<>){
    chomp;
    say "$_ 💩";
}

और फिर कुछ यूटीएफ -8 एन्कोडेड डेटा पर चलाएं, जैसे:

perl poo.pl input-data.txt

यह यूटीएफ -8 डेटा को प्रत्येक पंक्ति के अंत में एक पू के साथ प्रिंट करता है। बिल्कुल सही, मेरा कार्यक्रम काम करता है!

लेकिन नहीं, आप बस बाइनरी concatenation कर रहे हैं। आप फाइल से ऑक्टेट्स पढ़ रहे हैं, \n chomp के साथ हटा रहे हैं, और उसके बाद PILE OF POO चरित्र के PILE OF POO UTF-8 प्रतिनिधित्व में बाइट्स पर काम कर रहे हैं। जब आप फ़ाइल से डेटा को डीकोड करने और आउटपुट को एन्कोड करने के लिए अपने प्रोग्राम को संशोधित करते हैं, तो आप देखेंगे कि आपको पू के बजाय कचरा ("ð ©") मिलता है। इससे आपको विश्वास होगा कि इनपुट फ़ाइल को डीकोड करना गलत काम है। यह।

समस्या यह है कि पू को पूर्ण रूप से लैटिन -1 के रूप में अपग्रेड किया जा रहा है। यदि आप बाइनरी के बजाय शाब्दिक पाठ बनाने के use utf8 का use utf8 , तो यह फिर से काम करेगा!

(यूनिकोड के साथ लोगों की मदद करते समय यह पहली समस्या है। उन्होंने सही हिस्सा दिया और उन्होंने अपना कार्यक्रम तोड़ दिया। यह अनिर्धारित परिणामों के बारे में दुखद है: आप लंबे समय तक एक कामकाजी कार्यक्रम कर सकते हैं, लेकिन जब आप इसे सुधारना शुरू करते हैं, यह टूटता है। चिंता न करें; यदि आप अपने कार्यक्रम में एन्कोड / डिकोड स्टेटमेंट जोड़ रहे हैं और यह टूट जाता है, तो इसका मतलब है कि आपके पास और अधिक काम है। अगली बार, जब आप शुरुआत से यूनिकोड के साथ डिजाइन करते हैं, तो यह होगा बहुत आसान!)

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

यूनिकोड को संभालने का आसान हिस्सा एन्कोडिंग आउटपुट और डिकोडिंग इनपुट है। कठिन हिस्सा आपके सभी इनपुट और आउटपुट को ढूंढ रहा है, और यह निर्धारित करना कि यह कौन सी एन्कोडिंग है। लेकिन यही कारण है कि आप बड़ी कमाई करते हैं :)

मुझे आश्चर्य है कि पर्ल का उपयोग करके बनाए गए अधिकांश आधुनिक समाधान डिफ़ॉल्ट रूप से UTF-8 सक्षम नहीं करते हैं।

मैं समझता हूं कि मूल पर्ल स्क्रिप्ट के लिए कई विरासत समस्याएं हैं, जहां यह चीजों को तोड़ सकती है। लेकिन, मेरे दृष्टिकोण से, 21 वीं शताब्दी में, बड़ी नई परियोजनाओं (या एक बड़े परिप्रेक्ष्य वाली परियोजनाओं) को अपने सॉफ्टवेयर यूटीएफ -8 प्रमाण को खरोंच से बनाना चाहिए। फिर भी मुझे यह नहीं दिख रहा है। उदाहरण के लिए, Moose सख्त और चेतावनियां सक्षम करता है, लेकिन Unicode नहीं। Modern::Perl बॉयलरप्लेट भी कम कर देता है, लेकिन कोई यूटीएफ -8 हैंडलिंग नहीं।

क्यूं कर? क्या वर्ष 2011 में आधुनिक पर्ल परियोजनाओं में यूटीएफ -8 से बचने के कुछ कारण हैं?

@ क्रिस्टिस्ट को टिप्पणी करना बहुत लंबा हो गया, इसलिए मैं इसे यहां जोड़ रहा हूं।

ऐसा लगता है कि मैंने खुद को स्पष्ट नहीं किया। मुझे कुछ चीजों को जोड़ने की कोशिश करें।

tchrist और मैं स्थिति को समान रूप से देखते हैं, लेकिन हमारे निष्कर्ष पूरी तरह से विपरीत सिरों में हैं। मैं मानता हूं, यूनिकोड की स्थिति जटिल है, लेकिन यही कारण है कि हम (पर्ल उपयोगकर्ताओं और कोडर्स) को कुछ परत (या प्रज्ञा) की आवश्यकता होती है जो यूटीएफ -8 हैंडलिंग को आजकल जितना आसान हो सके उतना आसान बनाता है।

tchrist कवर करने के लिए कई पहलुओं की ओर इशारा किया, मैं उनके बारे में दिन या यहां तक ​​कि हफ्तों के लिए पढ़ और सोचेंगे। फिर भी, यह मेरा मुद्दा नहीं है। tchrist यह साबित करने का प्रयास करता है कि "यूटीएफ -8 सक्षम करने के लिए" एकमात्र तरीका नहीं है। मेरे पास बहस करने के लिए इतना ज्ञान नहीं है। तो, मैं उदाहरण उदाहरण के लिए चिपक गया।

मैंने Rakudo और यूटीएफ -8 के साथ खेला जहां मुझे जरूरी था । मुझे कोई समस्या नहीं थी, यह अभी काम किया। हो सकता है कि कुछ सीमा कहीं गहरी हो, लेकिन शुरुआत में, मैंने परीक्षण की सभी कामों की अपेक्षा की थी।

क्या यह आधुनिक पर्ल 5 में भी एक लक्ष्य नहीं होना चाहिए? मैं इसे और अधिक तनाव देता हूं: मैं कोर पर्ल के लिए डिफ़ॉल्ट चरित्र सेट के रूप में यूटीएफ -8 का सुझाव नहीं दे रहा हूं, मैं सुझाव देता हूं कि नई परियोजनाओं को विकसित करने वालों के लिए इसे स्नैप के साथ ट्रिगर करने की संभावना है।

एक और उदाहरण, लेकिन एक और नकारात्मक स्वर के साथ। ढांचे को विकास को आसान बनाना चाहिए। कुछ साल पहले, मैंने वेब ढांचे की कोशिश की, लेकिन उन्हें दूर फेंक दिया क्योंकि "यूटीएफ -8 सक्षम करना" इतना अस्पष्ट था। मुझे नहीं मिला कि यूनिकोड समर्थन कैसे और कहाँ हुक करें। यह इतना समय लेने वाला था कि मुझे पुराने तरीके से जाना आसान लगता था। अब मैंने देखा कि Mason 2 के साथ एक ही समस्या से निपटने के लिए एक बक्षीस था : Mason 2 यूटीएफ -8 को साफ कैसे करें? । तो, यह बहुत नया ढांचा है, लेकिन यूटीएफ -8 के साथ इसका उपयोग करने से इसकी आंतरिक जानकारी का गहरा ज्ञान है। यह एक बड़े लाल संकेत की तरह है: बंद करो, मुझे उपयोग न करें!

मुझे वास्तव में पर्ल पसंद है। लेकिन यूनिकोड से निपटना दर्दनाक है। मैं अभी भी दीवारों के खिलाफ चल रहा है। कुछ तरह से tchrist सही है और मेरे सवालों का जवाब देता है: नई परियोजनाएं यूटीएफ -8 को आकर्षित नहीं करती हैं क्योंकि यह पर्ल 5 में बहुत जटिल है।


🌴 🐪🐫🐪🐫🐪 🌞 𝕲𝖔 𝕿𝖍𝖔𝖚 𝖆𝖓𝖉 𝕯𝖔 𝕷𝖎𝖐𝖊𝖜𝖎𝖘𝖊 🌞 🐪🐫🐪 🐁

𝓔𝓭𝓲𝓽: 𝙎𝙞𝙢𝙥𝙡𝙚𝙨𝙩 : 𝟕 𝘿𝙞𝙨𝙘𝙧𝙚𝙩𝙚 𝙍𝙚𝙘𝙤𝙢𝙢𝙚𝙣𝙙𝙖𝙩𝙞𝙤𝙣𝙨

  1. AS अपने PERL_UNICODE कराएं। इससे सभी पर्ल स्क्रिप्ट्स @ARGV -8 स्ट्रिंग्स के रूप में @ARGV को डीकोड कर @ARGV हैं, और यूटीएफ -8 में सभी तीन @ARGV और @ARGV के एन्कोडिंग को सेट करती हैं। ये दोनों वैश्विक प्रभाव हैं, न कि व्याख्यात्मक।

  2. अपनी स्रोत फ़ाइल (प्रोग्राम, मॉड्यूल, लाइब्रेरी, हिकी) के शीर्ष पर, मुख्य रूप से जोर देकर कहते हैं कि आप perl संस्करण 5.12 चला रहे हैं या इसके माध्यम से बेहतर हैं:

    use v5.12; # minimal for unicode string feature

    use v5.14; # optimal for unicode string feature

  3. चेतावनियां सक्षम करें, क्योंकि पिछली घोषणा केवल सख्तताओं और विशेषताओं को सक्षम करती है, चेतावनी नहीं। मैं यूनिकोड चेतावनियों को अपवादों में बढ़ावा देने का भी सुझाव देता हूं, इसलिए इन दोनों पंक्तियों का उपयोग करें, न केवल उनमें से एक। ध्यान दें कि v5.14 के तहत, utf8 चेतावनी कक्षा में तीन अन्य सबवर्निंग शामिल हैं जिन्हें सभी अलग से सक्षम किया जा सकता है: nonchar , surrogate , और non_unicode । ये आप अधिक नियंत्रण करना चाहते हैं।

    use warnings;

    use warnings qw( FATAL utf8 );

  4. घोषणा करें कि इस स्रोत इकाई को यूटीएफ -8 के रूप में एन्कोड किया गया है। यद्यपि एक बार एक बार इस प्रज्ञा ने अन्य चीजें की, लेकिन अब यह अकेले इस एकमात्र उद्देश्य की सेवा करता है और कोई अन्य नहीं:

    use utf8;

  5. इस व्याख्यात्मक दायरे में फ़ाइलहैंड खोलने वाली किसी भी चीज को घोषित करें, लेकिन कहीं और नहीं यह मानना ​​है कि उस स्ट्रीम को यूटीएफ -8 में एन्कोड किया गया है जबतक कि आप इसे अन्यथा नहीं बताते। इस तरह आप अन्य मॉड्यूल या अन्य प्रोग्राम के कोड को प्रभावित नहीं करते हैं।

    use open qw( :encoding(UTF-8) :std );

  6. \N{CHARNAME} माध्यम से नामित वर्ण सक्षम करें।

    use charnames qw( :full :short );

  7. यदि आपके पास DATA हैंडल है, तो आपको स्पष्ट रूप से इसके एन्कोडिंग को सेट करना होगा। यदि आप इसे यूटीएफ -8 होना चाहते हैं, तो कहें:

    binmode(DATA, ":encoding(UTF-8)");

निश्चित रूप से अन्य मामलों का कोई अंत नहीं है जिसके साथ आप अंततः खुद को चिंतित कर सकते हैं, लेकिन इन शर्तों के कुछ हद तक कमजोर भावना के बावजूद, "सब कुछ सिर्फ यूटीएफ -8 के साथ काम करने" के लिए राज्य के लक्ष्य को अनुमानित करने के लिए पर्याप्त होगा।

एक अन्य प्रगति, हालांकि यह यूनिकोड से संबंधित नहीं है, है:

      use autodie;

इसकी दृढ़ता से अनुशंसा की जाती है।

🎅 𝕹 𝖔 𝕸 𝖆 𝖌 𝖎 𝖈 𝕭 𝖚 𝖑 𝖑 𝖊 𝖙 🎅

यह कहकर कि "पर्ल [ किसी भी तरह से चाहिए ! ] यूनिकोड को डिफ़ॉल्ट रूप से सक्षम करें "कुछ भी दुर्लभ और अलग मामले में भी मामूली रूप से उपयोगी होने के लिए पर्याप्त कहने के बारे में सोचने के लिए शुरू करना शुरू नहीं होता है। यूनिकोड सिर्फ एक बड़े चरित्र प्रदर्शन से कहीं अधिक है; यह भी है कि उन पात्रों में से कई कई तरीकों से कैसे बातचीत करते हैं।

यहां तक ​​कि सरल-दिमागी न्यूनतम उपाय भी (कुछ) लोगों को लगता है कि वे चाहते हैं कि वे कोड की लाखों लाइनों को बुरी तरह से तोड़ने की गारंटी दे रहे हैं, जिनके पास आपके स्पिफी न्यू ब्रेव न्यू वर्ल्ड आधुनिकता में "अपग्रेड" करने का कोई मौका नहीं है।

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

Un यूनिकोड को आसान बनाने के अपने रास्ते से बाहर चला गया है, जो मैंने कभी भी इस्तेमाल किया है उससे कहीं ज्यादा है। अगर आपको लगता है कि यह बुरा है, तो थोड़ी देर के लिए कुछ और कोशिश करें। फिर वापस आओ 🐪: या तो आप एक बेहतर दुनिया में लौट आएंगे, अन्यथा आप इसके साथ ज्ञान लाएंगे ताकि हम इन चीजों पर बेहतर बनाने के लिए अपने नए ज्ञान का उपयोग कर सकें।

💡 𝕴𝖉𝖊𝖆𝖘 𝖋𝖔𝖗 𝖆 𝖀𝖓𝖎𝖈𝖔𝖉𝖊 ⸗ 𝕬𝖜𝖆𝖗𝖊 🐪 𝕷𝖆𝖚𝖓𝖉𝖗𝖞 𝕷𝖎𝖘𝖙 💡

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

  1. सभी 🐪 स्रोत कोड डिफ़ॉल्ट रूप से यूटीएफ -8 में होना चाहिए। आप इसे use utf8 साथ प्राप्त कर सकते हैं या export PERL5OPTS=-Mutf8 कर सकते हैं।

  2. 🐪 DATA हैंडल यूटीएफ -8 होना चाहिए। आपको इसे प्रति-पैकेज आधार पर करना होगा, जैसे कि binmode(DATA, ":encoding(UTF-8)")

  3. 🐪 स्क्रिप्ट को प्रोग्राम तर्क डिफ़ॉल्ट रूप से यूटीएफ -8 समझा जाना चाहिए। export PERL_UNICODE=A , या perl -CA export PERL5OPTS=-CA , या export PERL5OPTS=-CA

  4. मानक इनपुट, आउटपुट और त्रुटि स्ट्रीम को यूटीएफ -8 में डिफ़ॉल्ट होना चाहिए। उन सभी के लिए export PERL_UNICODE=S करें, या I , O , और / या E उनमें से कुछ के लिए। यह perl -CS तरह है।

  5. 🐪 द्वारा खोले गए किसी अन्य हैंडल को अन्यथा घोषित किए जाने तक यूटीएफ -8 माना जाना चाहिए; export PERL_UNICODE=D या इनमें से विशेष के लिए i और o export PERL_UNICODE=D ; export PERL5OPTS=-CD काम करेगा। इससे सभी के लिए -CSAD बनाता है।

  6. दोनों आधारों को कवर करें और export PERL5OPTS=-Mopen=:utf8,:std साथ खुली सभी धाराओं को कवर करें export PERL5OPTS=-Mopen=:utf8,:stduniquote देखें।

  7. आप यूटीएफ -8 एन्कोडिंग त्रुटियों को याद नहीं करना चाहते हैं। export PERL5OPTS=-Mwarnings=FATAL,utf8 प्रयास करें। और सुनिश्चित करें कि आपकी इनपुट स्ट्रीम हमेशा binmode डी हैं :encoding(UTF-8) , न केवल :utf8

  8. 128-255 के बीच कोड बिंदुओं को Un द्वारा समेकित बाइनरी मानों के अनुरूप, यूनिकोड कोड बिंदुओं के रूप में समझा जाना चाहिए। use feature "unicode_strings" या export PERL5OPTS=-Mfeature=unicode_strings । इससे uc("\xDF") eq "SS" और "\xE9" =~ /\w/ एक साधारण export PERL5OPTS=-Mv5.12 या बेहतर भी यह प्राप्त होगा।

  9. नामांकित यूनिकोड वर्ण डिफ़ॉल्ट रूप से सक्षम नहीं हैं, इसलिए export PERL5OPTS=-Mcharnames=:full,:short,latin,greek या कुछ जोड़ें। uninames और tcgrep देखें।

  10. आपको मानक Unicode::Normalize मॉड्यूल के विभिन्न प्रकार के अपघटनों के कार्यों को लगभग हमेशा तक पहुंच की आवश्यकता होती है। export PERL5OPTS=-MUnicode::Normalize=NFD,NFKD,NFC,NFKD , और फिर export PERL5OPTS=-MUnicode::Normalize=NFD,NFKD,NFC,NFKD और आउटबाउंड सामान के माध्यम से हमेशा आने वाली सामग्री चलाते हैं। इनके लिए अभी तक कोई I / O परत नहीं है जिसे मैं जानता हूं, लेकिन nfc , nfd , nfkd , और nfkc

  11. eq , ne , lc , cmp , sort , और c & cc का उपयोग करके 🐪 में स्ट्रिंग तुलना हमेशा गलत होती है। तो @a = sort @b बजाय, आपको @a = Unicode::Collate->new->sort(@b) । साथ ही साथ अपने export PERL5OPTS=-MUnicode::Collate जोड़ सकते हैं। आप बाइनरी तुलना के लिए कुंजी कैश कर सकते हैं।

  12. 🐪 printf जैसे अंतर्निहित और write यूनिकोड डेटा के साथ गलत काम करता है। आपको पूर्व के लिए Unicode::GCString मॉड्यूल का उपयोग करने की आवश्यकता है, और दोनों और Unicode::LineBreak मॉड्यूल के साथ-साथ बाद के लिए भी। uwc और unifmt देखें।

  13. यदि आप उन्हें पूर्णांक के रूप में गिनना चाहते हैं, तो आपको Unicode::UCD::num फ़ंक्शन के माध्यम से अपने \d+ कैप्चर करना होगा क्योंकि 🐪 का अंतर्निहित atoi (3) वर्तमान में पर्याप्त चालाक नहीं है।

  14. आपके पास 👽 फाइल सिस्टम पर फाइल सिस्टम समस्याएं हैं। कुछ फाइल सिस्टम चुपचाप एनएफसी में रूपांतरण लागू करते हैं; अन्य चुपचाप एनएफडी में एक रूपांतरण लागू करते हैं। और दूसरों को कुछ और अभी भी करते हैं। कुछ इस मामले को पूरी तरह से अनदेखा करते हैं, जिससे इससे भी अधिक समस्याएं होती हैं। तो आपको साझे रखने के लिए अपना स्वयं का एनएफसी / एनएफडी हैंडलिंग करना है।

  15. आपके सभी 🐪 कोड में az या AZ और इस तरह से बदलना चाहिए , जिसमें m// , s/// , और tr/// । यह एक चिल्लाना लाल झंडा के रूप में खड़ा होना चाहिए कि आपका कोड टूटा हुआ है। लेकिन यह स्पष्ट नहीं है कि इसे कैसे बदला जाना चाहिए। सही गुण प्राप्त करना, और उनके केसफॉल्ड को समझना, आपके विचार से कठिन है। मैं हर दिन unichars और uniprops उपयोग करें।

  16. कोड जो \p{Lu} का उपयोग करता है वह कोड के रूप में लगभग गलत है जो [A-Za-z] का उपयोग करता है। आपको इसके बजाय \p{Upper} का उपयोग करने की आवश्यकता है, और कारण बताएं। हां, \p{Lowercase} और \p{Lower} \p{Ll} और \p{Lowercase_Letter}

  17. कोड [a-zA-Z] का उपयोग करता है और भी बदतर है। और यह \pL या \p{Letter} उपयोग नहीं कर सकता; इसे \p{Alphabetic} का उपयोग करने की आवश्यकता है। सभी वर्णमाला पत्र नहीं हैं, आप जानते हैं!

  18. यदि आप /[\$\@\%]\w+/ चर /[\$\@\%]\w+/ साथ चर के लिए देख रहे हैं, तो आपको एक समस्या है। आपको /[\$\@\%]\p{IDS}\p{IDC}*/ और यहां तक ​​कि यह विराम चिह्न चर या पैकेज चर के बारे में सोचने की आवश्यकता नहीं है।

  19. यदि आप व्हाइटस्पेस की जांच कर रहे हैं, तो आपको निर्भर करते हुए \h और \v बीच चयन करना चाहिए। और आपको कभी भी इसका उपयोग नहीं करना चाहिए, क्योंकि यह लोकप्रिय विश्वास के विपरीत [\h\v] है।

  20. यदि आप लाइन सीमा के लिए \n का उपयोग कर रहे हैं, या यहां तक ​​कि \r\n , तो आप इसे गलत कर रहे हैं। आपको \R का उपयोग करना होगा, जो वही नहीं है!

  21. यदि आपको पता नहीं है कि Unicode::Stringprep को कब और कब कॉल Unicode::Stringprep , तो आप बेहतर सीख सकते थे।

  22. केस-असंवेदनशील तुलनाओं की जांच करने की आवश्यकता है कि क्या दो चीजें एक ही अक्षरों हैं, चाहे उनकी विशिष्टता और ऐसी कोई फर्क नहीं पड़ता। ऐसा करने का सबसे आसान तरीका मानक यूनिकोड :: कोलेट मॉड्यूल के साथ है। Unicode::Collate->new(level => 1)->cmp($a, $b)eq विधियों और ऐसे भी हैं, और आपको शायद match और substr विधियों के बारे में भी सीखना चाहिए। इन्हें 🐪 बिल्ट-इन्स पर अलग-अलग फायदे हैं।

  23. कभी-कभी यह अभी भी पर्याप्त नहीं है, और आपको यूनिकोड :: कोलेट :: लोकेल मॉड्यूल की आवश्यकता है, जैसे Unicode::Collate::Locale->new(locale => "de__phonebook", level => 1)->cmp($a, $b) इसके बजाए। ध्यान दें कि Unicode::Collate::->new(level => 1)->eq("d", "ð") सत्य है, लेकिन Unicode::Collate::Locale->new(locale=>"is",level => 1)->eq("d", " ð") गलत है। इसी प्रकार, "एई" और "æ" eq यदि आप eq उपयोग नहीं करते हैं, या यदि आप अंग्रेजी का उपयोग करते हैं, लेकिन वे आइसलैंडिक लोकेल में अलग हैं। अब क्या? यह कठिन है, मैं आपको बताता हूं। इन चीजों में से कुछ का परीक्षण करने के लिए आप unifmt साथ खेल सकते हैं।

  24. स्ट्रिंग " निनो " में पैटर्न सीवीसीवी (व्यंजन, स्वर, व्यंजन, स्वर) से मिलान करने के तरीके पर विचार करें। इसका एनएफडी फॉर्म - जिसे आपने अच्छी तरह से बेहतर ढंग से डाला था उसे याद रखने के लिए याद किया गया है - "nin \ x {303} o" बन जाता है। अब आप क्या करने जा रहे हो? यह भी दिखाते हुए कि एक स्वर [aeiou] (जो गलत है, वैसे भी), आप कुछ ऐसा करने में सक्षम नहीं होंगे (?=[aeiou])\X) या तो, क्योंकि एनएफडी में भी एक कोड बिंदु ' ø ' विघटन नहीं करता है ! हालांकि, यह यूसीए तुलना का उपयोग करके 'ओ' के बराबर परीक्षण करेगा जो मैंने आपको दिखाया था। आप एनएफडी पर भरोसा नहीं कर सकते हैं, आपको यूसीए पर भरोसा करना है।

💩 𝔸 𝕤 𝕤 𝕦 𝕞 𝕖 𝔹 𝕣 𝕠 𝕜 𝕖 𝕟 𝕟 𝕖 𝕤 𝕤 𝕤

और अभी यह समाप्त नहीं हुआ है। लाखों टूटी धारणाएं हैं जो लोग यूनिकोड के बारे में बताते हैं। जब तक वे इन चीजों को समझ नहीं लेते, उनका 🐪 कोड टूटा जाएगा।

  1. कोड जो मानता है कि यह एन्कोडिंग निर्दिष्ट किए बिना टेक्स्ट फ़ाइल खोल सकता है।

  2. कोड जो डिफ़ॉल्ट एन्कोडिंग मानता है वह कुछ प्रकार का देशी प्लेटफ़ॉर्म एन्कोडिंग टूटा हुआ है।

  3. कोड जो मानता है कि यूटीएफ -8 की तुलना में जापानी या चीनी में वेब पेज यूटीएफ -16 में कम जगह लेते हैं, गलत है।

  4. कोड जो मानता है कि पर्ल यूटीएफ -8 का आंतरिक रूप से उपयोग करता है वह गलत है।

  5. कोड जो मानता है कि एन्कोडिंग त्रुटियां हमेशा अपवाद उठाएंगी गलत है।

  6. कोड जो मानता है कि पर्ल कोड बिंदु 0x10_FFFF तक सीमित हैं गलत है।

  7. कोड जो मानता है कि आप किसी भी वैध लाइन विभाजक के साथ काम करने वाले किसी चीज़ को $/ सेट कर सकते हैं वह गलत है।

  8. कोड जो केसफॉल्डिंग पर राउंडट्रिप समानता मानता है, जैसे lc(uc($s)) eq $s या uc(lc($s)) eq $s , पूरी तरह से टूटा हुआ है और गलत है। ध्यान दें कि uc("σ") और uc("ς") दोनों "Σ" , लेकिन lc("Σ") संभवतः उन दोनों को वापस नहीं कर सकता है।

  9. कोड जो हर लोअरकेस कोड बिंदु मानता है, एक अलग अपरकेस होता है, या इसके विपरीत, टूट जाता है। उदाहरण के लिए, "ª" कोई अपरकेस वाला कोई लोअरकेस अक्षर नहीं है; जबकि दोनों "ᵃ" और "ᴬ" अक्षर हैं, लेकिन वे छोटे अक्षरों नहीं हैं; हालांकि, वे संबंधित अपरकेस संस्करणों के बिना दोनों लोअरकेस कोड बिंदु हैं। समझ गया? \p{Letter} और \p{Lowercase} दोनों होने के बावजूद वे \p{Lowercase}

  10. कोड जो केस को बदलता है मानता है स्ट्रिंग की लंबाई बदल नहीं जाती है।

  11. कोड जो मानता है कि केवल दो मामले टूट गए हैं। शीर्षक भी है।

  12. कोड जो केवल अक्षरों को मानता है, मामला टूटा हुआ है। सिर्फ अक्षरों से परे, यह पता चला है कि संख्याओं, प्रतीकों, और यहां तक ​​कि अंकों के मामले भी हैं। वास्तव में, मामले को बदलने से कुछ मुख्य बदलाव भी हो सकता है, जैसे \p{Mark} एक \p{Letter} में बदलना। यह इसे एक स्क्रिप्ट से दूसरे में भी स्विच कर सकता है।

  13. कोड जो मानता है कि मामला कभी लोकल-निर्भर नहीं है।

  14. कोड जो यूनिकोड मानता है उसे पॉज़िक्स लोकेशंस के बारे में एक अंजीर देता है।

  15. कोड जो मानता है कि आप आधार ASCII अक्षरों को प्राप्त करने के लिए विशिष्टता को हटा सकते हैं, बुराई, अभी भी, टूटा हुआ, मस्तिष्क-क्षतिग्रस्त, गलत, और मौत की सजा के लिए औचित्य है।

  16. कोड जो मानता है कि diacritics \p{Diacritic} और अंक \p{Mark} वही बात टूट जाती है।

  17. कोड जो \p{GC=Dash_Punctuation} को उतना ही कवर करता है जितना \p{Dash} टूट जाता है।

  18. कोड जो डैश, हाइफ़न और माइनस मानता है, एक दूसरे के समान ही है, या प्रत्येक में से केवल एक ही टूटा हुआ है और गलत है।

  19. कोड जो हर कोड बिंदु मानता है, एक से अधिक प्रिंट कॉलम टूट जाता है।

  20. कोड जो मानता है कि सभी \p{Mark} अक्षर शून्य प्रिंट कॉलम लेते हैं तोड़ दिया जाता है।

  21. कोड जो मानता है कि एक जैसे दिखने वाले पात्र समान रूप से टूटे हुए हैं।

  22. संहिता जो मानती है कि जो वर्ण समान दिखते नहीं हैं वे समान नहीं हैं।

  23. कोड जो मानता है कि एक पंक्ति में कोड बिंदुओं की संख्या की सीमा है जो केवल एक \X मिलान कर सकता है गलत है।

  24. कोड जो मानता है \X \p{Mark} चरित्र से शुरू नहीं हो सकता है गलत है।

  25. कोड जो मानता है कि \X कभी भी दो गैर- \p{Mark} वर्णों को पकड़ नहीं सकता है।

  26. कोड जो मानता है कि यह "\x{FFFF}" का उपयोग नहीं कर सकता है गलत है।

  27. कोड जो एक गैर-बीएमपी कोड बिंदु मानता है जिसके लिए दो यूटीएफ -16 (सरोगेट) कोड इकाइयों की आवश्यकता होती है, दो अलग-अलग यूटीएफ -8 वर्णों को एन्कोड किया जाएगा, एक प्रति कोड इकाई, गलत है। यह नहीं करता है: यह एकल कोड बिंदु पर एन्कोड करता है।

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

  29. कोड जो सीईएसयू -8 मानता है वह वैध यूटीएफ एन्कोडिंग गलत है। इसी प्रकार, कोड जो यू "\xC0\x80" को "\xC0\x80" रूप में एन्कोडिंग करता है वह यूटीएफ -8 टूट गया है और गलत है। ये लोग भी पलक उपचार के लायक हैं।

  30. कोड जो अक्षरों को मानता है > हमेशा दाईं ओर इंगित करता है और < हमेशा बाईं ओर इंगित करता है गलत है - क्योंकि वास्तव में वे नहीं करते हैं।

  31. कोड जो मानता है कि क्या आप पहली बार चरित्र X और फिर चरित्र Y आउटपुट करते हैं, जो कि XY गलत होने के कारण दिखाई देंगे। कभी-कभी वे नहीं करते हैं।

  32. कोड जो मानता है कि एएससीआईआई अंग्रेजी लिखने के लिए पर्याप्त है, वह बेवकूफ, शॉर्ट्स, अशिक्षित, टूटा, बुराई और गलत है। उनके सिर के साथ बंद! यदि यह बहुत चरम लगता है, तो हम समझौता कर सकते हैं: अब से वे केवल एक पैर से अपने बड़े पैर की अंगुली के साथ टाइप कर सकते हैं (शेष अभी भी डकटा हुआ है)।

  33. कोड जो मानता है कि सभी \p{Math} कोड बिंदु दृश्यमान वर्ण गलत हैं।

  34. कोड जो मानता है \w में केवल अक्षर, अंक और अंडरस्कोर गलत है।

  35. कोड जो मानता है कि ^ और ~ विराम चिह्न हैं गलत है।

  36. कोड जो मानता है कि ü में एक उमलॉट गलत है।

  37. संहिता जो मानती है कि things जैसी चीजें हैं उनमें कोई भी पत्र गलत है।

  38. कोड जो मानता है \p{InLatin} \p{Latin} रूप में समान रूप से टूटा हुआ है।

  39. कोड जो विश्वास करता है कि \p{InLatin} लगभग हमेशा उपयोगी है लगभग निश्चित रूप से गलत है।

  40. कोड जो मानता है कि कुछ वर्णमाला में $LAST_LETTER को कुछ वर्णमाला में $LAST_LETTER और $LAST_LETTER को उसी वर्णमाला में अंतिम अक्षर के रूप में दिया गया है, कि [${FIRST_LETTER}-${LAST_LETTER}] का कोई अर्थ है जो लगभग हमेशा टूटा हुआ और गलत होता है और व्यर्थ।

  41. कोड जो मानता है कि किसी के नाम में केवल कुछ वर्ण ही बेवकूफ, आक्रामक और गलत हो सकते हैं।

  42. कोड जो यूनिकोड को ASCII तक कम करने की कोशिश करता है वह केवल गलत नहीं है, इसके अपराधी को प्रोग्रामिंग में फिर से काम करने की अनुमति नहीं दी जानी चाहिए। अवधि। मैं भी सकारात्मक नहीं हूं उन्हें फिर से देखने की इजाजत दी जानी चाहिए, क्योंकि जाहिर है कि अब तक उन्हें बहुत अच्छा नहीं किया है।

  43. कोड जो मानता है कि टेक्स्टफाइल एन्कोडिंग का नाटक करने का कोई तरीका मौजूद नहीं है, वह टूटा और खतरनाक है। साथ ही साथ दूसरी आंख भी पोक कर सकते हैं।

  44. कोड जो अज्ञात वर्णों को परिवर्तित करता है ? टूट गया है, बेवकूफ, ब्राइंडेड, और मानक सिफारिश के विपरीत चलता है, जो ऐसा नहीं करता है! आरटीएफएम क्यों नहीं।

  45. कोड जो मानता है कि यह विश्वसनीय रूप से अनुमान लगा सकता है कि एक अनमार्क किए गए टेक्स्टफाइल के एन्कोडिंग को हब्रिस और नाइटवे के घातक मेलेेंज का दोषी माना जाता है कि ज़ीउस से केवल एक बिजली बोल्ट ठीक हो जाएगा।

  46. कोड जो मानता है कि आप पैड के लिए 🐪 printf चौड़ाई का उपयोग कर सकते हैं और औचित्य मान सकते हैं यूनिकोड डेटा टूटा हुआ है और गलत है।

  47. कोड जो विश्वास करता है कि एक बार जब आप किसी दिए गए नाम से फ़ाइल सफलतापूर्वक बनाते हैं, तो जब आप अपनी संलग्न निर्देशिका पर ls या readdir चलाते हैं, तो आपको वास्तव में उस फ़ाइल के साथ उस फ़ाइल के साथ मिल जाएगा जिसे आपने बनाया है वह छोटी, टूटा हुआ और गलत है। इससे आश्चर्यचकित होना बंद करो!

  48. कोड जो यूटीएफ -16 मानता है एक निश्चित चौड़ाई एन्कोडिंग बेवकूफ, टूटा हुआ और गलत है। अपने प्रोग्रामिंग लाइसेंस को रद्द करें।

  49. संहिता जो कोड के बिंदुओं को किसी एक विमान से अलग करती है, किसी अन्य विमान से अलग की तुलना में एक सफेद अलग-अलग आईपीओ वास्तव में टूटा और गलत है। वापस पाठशाला को जाओ।

  50. कोड जो मानता है कि /s/i जैसे सामान केवल "S" या "s" "S" मेल खाते हैं और गलत हैं। आप चौंक जाएंगे।

  51. कोड जो \X \PM\pM* का उपयोग करने के बजाय \X \PM\pM* का उपयोग करने के लिए grapheme क्लस्टर का उपयोग करने के लिए टूटा हुआ है और गलत है।

  52. जो लोग एएससीआईआईआई दुनिया में वापस जाना चाहते हैं उन्हें पूरी तरह से ऐसा करने के लिए प्रोत्साहित किया जाना चाहिए, और उनके गौरवशाली अपग्रेड के सम्मान में उन्हें अपनी सभी डेटा-प्रविष्टि आवश्यकताओं के लिए प्री-इलेक्ट्रिक मैनुअल टाइपराइटर के साथ मुफ्त प्रदान किया जाना चाहिए। उन्हें भेजे गए संदेश प्रति पंक्ति 40 वर्णों पर एक ᴀʟʟᴄᴀᴘs टेलीग्राफ के माध्यम से भेज सकते हैं और एक कूरियर द्वारा हाथ से वितरित किया जाना चाहिए। रूक जा।

🎁 🐪 𝕭𝖔𝖎𝖑𝖊𝖗⸗𝖕𝖑𝖆𝖙𝖊 𝖋𝖔𝖗 𝖀𝖓𝖎𝖈𝖔𝖉𝖊⸗𝕬𝖜𝖆𝖗𝖊 𝕮𝖔𝖉𝖊 🐪 🎁

इन दिनों मेरा खुद का बॉयलरप्लेट इस तरह दिखता है:

use 5.014;

use utf8;
use strict;
use autodie;
use warnings; 
use warnings    qw< FATAL  utf8     >;
use open        qw< :std  :utf8     >;
use charnames   qw< :full >;
use feature     qw< unicode_strings >;

use File::Basename      qw< basename >;
use Carp                qw< carp croak confess cluck >;
use Encode              qw< encode decode >;
use Unicode::Normalize  qw< NFD NFC >;

END { close STDOUT }

if (grep /\P{ASCII}/ => @ARGV) { 
   @ARGV = map { decode("UTF-8", $_) } @ARGV;
}

$0 = basename($0);  # shorter messages
$| = 1;

binmode(DATA, ":utf8");

# give a full stack dump on any untrapped exceptions
local $SIG{__DIE__} = sub {
    confess "Uncaught exception: @_" unless $^S;
};

# now promote run-time warnings into stackdumped exceptions
#   *unless* we're in an try block, in which 
#   case just generate a clucking stackdump instead
local $SIG{__WARN__} = sub {
    if ($^S) { cluck   "Trapped warning: @_" } 
    else     { confess "Deadly warning: @_"  }
};

while (<>)  {
    chomp;
    $_ = NFD($_);
    ...
} continue {
    say NFC($_);
}

__END__

😱 𝕾 𝖀 𝕸 𝕸 𝕬 𝕽 𝖄 😱

मुझे नहीं पता कि मैंने "डिफ़ॉल्ट यूनिकोड 🐪" में जो कुछ लिखा है उससे आप प्राप्त कर सकते हैं। खैर, हाँ मैं करता हूं: आपको Unicode::LineBreak और Unicode::LineBreak भी उपयोग करना चाहिए। और शायद अधिक।

जैसा कि आप देखते हैं, वहां बहुत अधिक यूनिकोड चीजें हैं जिन्हें आपको वास्तव में चिंता करने की ज़रूरत है कि "यूनिकोड के लिए डिफ़ॉल्ट" जैसी कोई भी चीज़ मौजूद है।

आप जो खोज रहे हैं, वैसे ही जैसे हमने .8 5.8 में वापस किया था, कि इन सभी चीजों को कोड पर लगाया जाना असंभव है, जिसे शुरुआत से ही उनके लिए खाते में नहीं बनाया गया है। आपकी अच्छी तरह से स्वार्थी स्वार्थ ने पूरी दुनिया को तोड़ दिया।

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

आपको इसे सीखना है। अवधि। यह इतना आसान कभी नहीं होगा कि "सबकुछ बस काम करता है", क्योंकि इससे गारंटी मिलेगी कि बहुत सी चीजें काम नहीं करतीं - जो इस धारणा को अमान्य करती है कि कभी भी "इसे सब काम करने" का कोई तरीका हो सकता है।

आप बहुत कम और बहुत सीमित संचालन के लिए कुछ उचित डिफ़ॉल्ट प्राप्त करने में सक्षम हो सकते हैं, लेकिन चीजों के बारे में सोचने के बिना मुझे लगता है कि आपके पास बहुत कुछ नहीं है।

केवल एक उदाहरण के रूप में, कैनोलिक ऑर्डरिंग कुछ वास्तविक सिरदर्द का कारण बनने जा रही है। 😭 "\x{F5}" 'õ' , "o\x{303}" 'õ' , "o\x{303}\x{304}" 'ȭ' , और "o\x{304}\x{303}" 'ō' सभी 'õ' से मेल खाना चाहिए, लेकिन दुनिया में आप ऐसा करने जा रहे हैं? यह दिखने से कठिन है, लेकिन ऐसा कुछ है जिसके लिए आपको खाते की आवश्यकता है। 💣

अगर पर्ल के बारे में मुझे एक बात पता है, तो यह यूनिकोड बिट्स करता है और नहीं करता है, और यह बात मैं आपको वादा करता हूं: "ᴛʜᴇʀᴇ ɪs ɴᴏ Uɴɪᴄᴏᴅᴇ ᴍᴀɢɪᴄ ʙᴜʟʟᴇᴛ" 😞

आप केवल कुछ डिफ़ॉल्ट नहीं बदल सकते हैं और चिकनी नौकायन प्राप्त कर सकते हैं। यह सच है कि मैं "SA" सेट PERL_UNICODE साथ PERL_UNICODE , लेकिन यह सब कुछ है, और यहां तक ​​कि यह अधिकतर कमांड लाइन सामग्री के लिए है। वास्तविक काम के लिए, मैं उपर्युक्त सभी चरणों के माध्यम से जाता हूं, और मैं इसे बहुत ** ** ** सावधानी से करता हूं।

😈 ¡ƨdləɥ ƨᴉɥʇ ədoɥ puɐ'λɐp əɔᴉu ɐ əʌɐɥ'ʞɔnl poo⅁ 😈


I think you misunderstand Unicode and its relationship to Perl. No matter which way you store data, Unicode, ISO-8859-1 , or many other things, your program has to know how to interpret the bytes it gets as input (decoding) and how to represent the information it wants to output (encoding). Get that interpretation wrong and you garble the data. There isn't some magic default setup inside your program that's going to tell the stuff outside your program how to act.

You think it's hard, most likely, because you are used to everything being ASCII. Everything you should have been thinking about was simply ignored by the programming language and all of the things it had to interact with. If everything used nothing but UTF-8 and you had no choice, then UTF-8 would be just as easy. But not everything does use UTF-8. For instance, you don't want your input handle to think that it's getting UTF-8 octets unless it actually is, and you don't want your output handles to be UTF-8 if the thing reading from them can handle UTF-8. Perl has no way to know those things. That's why you are the programmer.

I don't think Unicode in Perl 5 is too complicated. I think it's scary and people avoid it. There's a difference. To that end, I've put Unicode in Learning Perl, 6th Edition , and there's a lot of Unicode stuff in Effective Perl Programming . You have to spend the time to learn and understand Unicode and how it works. You're not going to be able to use it effectively otherwise.


While reading this thread, I often get the impression that people are using " UTF-8 " as a synonym to " Unicode ". Please make a distinction between Unicode's "Code-Points" which are an enlarged relative of the ASCII code and Unicode's various "encodings". And there are a few of them, of which UTF-8, UTF-16 and UTF-32 are the current ones and a few more are obsolete.

Please, UTF-8 (as well as all other encodings ) exists and have meaning in input or in output only. Internally, since Perl 5.8.1, all strings are kept as Unicode "Code-points". True, you have to enable some features as admiringly covered previously.


हम सभी इस समझौते में हैं कि कई कारणों से यह एक कठिन समस्या है, लेकिन यह बिल्कुल सही है कि इसे हर किसी पर आसान बनाने का प्रयास करें।

सीपीएएन, utf8::all पर एक हालिया मॉड्यूल है, जो "यूनिकोड चालू करने" का प्रयास करता है।

As has been pointed out, you can't magically make the entire system (outside programs, external web requests, etc.) use Unicode as well, but we can work together to make sensible tools that make doing common problems easier. That's the reason that we're programmers.

If utf8::all doesn't do something you think it should, let's improve it to make it better. Or let's make additional tools that together can suit people's varying needs as well as possible.

`





utf-8