यूनिकोड वर्णों को एन्कोड करने का उचित तरीका क्या है?

Question

मुझे गैर मानक% uxxxx योजना के बारे में पता है लेकिन यह एक बुद्धिमान विकल्प की तरह प्रतीत नहीं होता है क्योंकि योजना डब्ल्यू 3 सी द्वारा खारिज कर दी गई है।

कुछ रोचक उदाहरण:

हृदय चरित्र। अगर मैं अपने ब्राउज़र में इस टाइप करें:

http://www.google.com/search?q=♥ 

फिर कॉपी और पेस्ट करें, मैं इस URL

http://www.google.com/search?q=%E2%99%A5 

यह फ़ायरफ़ॉक्स (या सफारी) की तरह लग इस कर रही है बनाता है जो देखते हैं।

urllib.quote_plus(x.encode("latin-1")) 
'%E2%99%A5' 

जो समझ में आता है, चीजें हैं जो लैटिन -1 में इनकोडिंग नहीं किया जा सकता, ट्रिपल डॉट चरित्र की तरह के अलावा

।

… 

अगर मैं यूआरएल

http://www.google.com/search?q=… 

अपने ब्राउज़र में

तो कॉपी और पेस्ट टाइप करें, मैं

http://www.google.com/search?q=%E2%80%A6 

वापस मिलता है। ऐसा लगता है कि

urllib.quote_plus(x.encode("utf-8")) 

जो समझ में आता है ... लैटिन -1 के साथ एन्कोड नहीं किया जा सकता है।

लेकिन तब मेरे लिए अपनी स्पष्ट नहीं कैसे ब्राउज़र जानता है UTF-8 या लैटिन -1 के साथ डिकोड करने के लिए है या नहीं।

इस के बाद से अस्पष्ट प्रतीत हो रहा है:

In [67]: u"…".encode('utf-8').decode('latin-1') 
Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6' 

काम करता है, इसलिए मैं नहीं जानता कि कैसे ब्राउज़र है कि क्या पता लगा लेता डिकोड करने के लिए है कि UTF-8 या लैटिन -1 के साथ।

उन विशेष पात्रों के साथ क्या करने की ज़रूरत है, जिनसे मुझे निपटने की ज़रूरत है?

Answer 1

मैं हमेशा यूटीएफ -8 में एन्कोड करता हूं। से Wikipedia page on percent encoding:

सामान्य url सिंटैक्स जनादेश कि नए URI योजनाओं है कि एक यूआरआई में चरित्र डेटा के प्रतिनिधित्व के लिए प्रदान करनी चाहिए, प्रभाव में, अनारक्षित सेट में अधिकतम वर्ण अनुवाद के बिना प्रतिनिधित्व करते हैं, और अन्य सभी पात्रों को परिवर्तित करना चाहिए यूटीएफ -8 के अनुसार बाइट्स के लिए, और फिर उन मानों को प्रतिशत-एन्कोड करें। यह आवश्यकता जनवरी 2005 में RFC 3986 के प्रकाशन के साथ पेश की गई थी। इस तिथि से पहले पेश की गई यूआरआई योजनाएं प्रभावित नहीं हैं।

ऐसा लगता है क्योंकि वहाँ अतीत में URL एन्कोडिंग करने का अन्य स्वीकृत तरीके थे लगता है, ब्राउज़रों यूआरआई डिकोडिंग के कई तरीके का प्रयास, लेकिन अगर आप एन्कोडिंग कर एक हैं आप UTF-8 का उपयोग करना चाहिए।

Answer 2

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

तो UTF-8 का उपयोग जब तक आप एक बाध्यकारी कारण कई अन्य एन्कोडिंग योजनाओं में से एक का उपयोग करने के लिए है।

Answer 3

सामान्य नियम यह प्रतीत होता है कि ब्राउज़र उस पृष्ठ के सामग्री-प्रकार के अनुसार फॉर्म प्रतिक्रियाओं को एन्कोड करता है, जिस फ़ॉर्म से फ़ॉर्म परोसा गया था। यह एक अनुमान है कि अगर सर्वर हमें "टेक्स्ट/एक्सएमएल; charset = iso-8859-1" भेजता है, तो वे प्रतिक्रियाओं को उसी प्रारूप में वापस उम्मीद करते हैं।

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

दुखद सच्चाई AFAIK क्या चरित्र एक क्वेरी स्ट्रिंग में कोई भी वर्ण URL में, के रूप में व्याख्या की जानी चाहिए मूल्यों को निर्धारित, या वास्तव में के लिए कोई मानक नहीं है कि है। कम से कम क्वेरी स्ट्रिंग में मानों के मामले में, यह मानने का कोई कारण नहीं है कि वे वर्णों से मेल खाते हैं।

यह एक ज्ञात समस्या है जिसे आपको अपने सर्वर ढांचे को बताना है कि आप किस चरित्र सेट को क्वेरी स्ट्रिंग को एन्कोड किए जाने की अपेक्षा करते हैं --- उदाहरण के लिए, टॉमकैट में, आपको request.setEncoding() (या कुछ समान विधि) से पहले आप किसी भी अनुरोध को कॉल करते हैं .getParameter() विधियों। इस विषय पर दस्तावेज़ीकरण की कमी शायद कई डेवलपर्स के बीच समस्या के बारे में जागरूकता की कमी को दर्शाती है। (मैं नियमित रूप से जावा साक्षात्कार देने पूछना क्या एक रीडर और एक InputStream के बीच अंतर है, और नियमित रूप से खाली दिखता मिलता है)

Answer 4

IRI (RFC 3987) नवीनतम मानक है कि URI/URL (RFC 3986 और पुराने) मानकों को बदल देता है। यूआरआई/यूआरएल मूल रूप से यूनिकोड का समर्थन नहीं करता है (अच्छी तरह से, RFC 3986 इसका समर्थन करने के लिए भविष्य में यूआरआई/यूआरएल-आधारित प्रोटोकॉल के प्रावधान जोड़ता है, लेकिन पिछले आरएफसी अपडेट नहीं करता है)। "% UXXXX" योजना कुछ स्थितियों में यूनिकोड को अनुमति देने के लिए एक गैर-मानक विस्तार है, लेकिन सार्वभौमिक रूप से सभी द्वारा लागू नहीं किया जाता है। दूसरी तरफ, आईआरआई यूनिकोड का पूरी तरह से समर्थन करता है, और उस पाठ को प्रतिशत-एन्कोडेड होने से पहले यूटीएफ -8 के रूप में एन्कोड किया जाना आवश्यक है।

Answer 5

आईरिस यूआरआई की जगह नहीं है, क्योंकि केवल URI (प्रभावी ढंग से, ASCII) कुछ संदर्भों में अनुमति है - HTTP भी शामिल है।

इसके बजाय, आप एक IRI निर्दिष्ट और जब तार पर बाहर जा रहा है कि यह एक यूआरआई के रूप में तब्दील हो जाता है।