URL में यूनिकोड वर्ण


135

2010 में, क्या आप किसी बड़े वेब पोर्टल में UTF-8 अक्षरों वाले URL परोसेंगे?

URL पर RFC के अनुसार यूनिकोड वर्ण निषिद्ध हैं ( यहाँ देखें )। मानकों का अनुपालन करने के लिए उन्हें प्रतिशत एनकोडेड करना होगा।

मेरा मुख्य बिंदु, हालांकि, अच्छे दिखने वाले URL वाले एकमात्र उद्देश्य के लिए अनएन्कोड किए गए वर्णों की सेवा कर रहा है, इसलिए प्रतिशत एन्कोडिंग बाहर है।

सभी प्रमुख ब्राउज़र उन URL को पार्स करते प्रतीत होते हैं, ठीक है कोई फर्क नहीं पड़ता कि RFC क्या कहता है। हालाँकि, मेरा सामान्य प्रभाव यह है कि वेब ब्राउज़र के डोमेन को छोड़ते समय यह बहुत अस्थिर हो जाता है:

  • अलग-अलग एन्कोडिंग वाली पाठ साइटों, ई-मेल, यहां तक ​​कि वेब साइटों में कॉपी + पेस्ट किए जाने वाले URL
  • HTTP क्लाइंट लाइब्रेरी
  • विदेशी ब्राउज़र, आरएसएस के पाठक

क्या मेरी धारणा सही है कि मुसीबत की उम्मीद यहाँ की जानी चाहिए, और इस तरह यह एक व्यावहारिक समाधान नहीं है (अभी तक) यदि आप एक गैर-तकनीकी दर्शकों की सेवा कर रहे हैं और यह महत्वपूर्ण है कि आपके सभी लिंक ठीक से काम करें, भले ही उद्धृत और पारित हो जाएं?

क्या HTML में अच्छे दिखने वाले URL परोसने का कोई जादू है

http://www.example.com/düsseldorf?neighbourhood=Lörick

कि विशेष पात्रों के साथ कॉपी + चिपकाया जा सकता है, लेकिन पुराने ग्राहकों में फिर से उपयोग किए जाने पर सही ढंग से काम करते हैं?


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

जवाबों:


126

प्रतिशत एन्कोडिंग का उपयोग करें। आधुनिक ब्राउज़र डिस्प्ले और पेस्ट मुद्दों का ध्यान रखेंगे और इसे मानव-पठनीय बनाएंगे। ई। जी। http://ko.wikipedia.org/wiki/ 위키 백과: 대문

संपादित करें: जब आप फ़ायरफ़ॉक्स में इस तरह के एक यूआरएल को कॉपी करते हैं, तो क्लिपबोर्ड प्रतिशत-एन्कोडेड फॉर्म (जो आमतौर पर एक अच्छी बात है) को धारण करेगा, लेकिन यदि आप इसका केवल एक हिस्सा कॉपी करते हैं, तो यह अनएन्कोडेड रहेगा।


वाह, वास्तव में तुम सही हो! यदि आप एक%-URL URL को काटते हैं तो फ़ायरफ़ॉक्स इसे प्रदर्शन के लिए सही चीज़ में बदल देगा।
डीन हार्डिंग

वाह, मुझे इसकी जानकारी नहीं थी। संभावना है कि यह सबसे अच्छा समाधान है!
पेक्का

33
@Dean यह एक हालिया बदलाव है - 2005 में सभी अंतरराष्ट्रीय विकिपीडिया एक वास्तविक% 6D% 65% 73% 73 की तरह दिखे।
रोमन स्टार्कोव

2
आप अब तक HTML5 दस्तावेजों में बिना लाइसेंस वाले UTF-8 URL, अर्थात् IRI का उपयोग कर सकते हैं। यदि आप ऐसा करते हैं, तो सभी प्रमुख ब्राउज़र इसे समझेंगे और अपने एड्रेस बार में इसे सही ढंग से प्रदर्शित करेंगे।
ओलिवर

आधुनिक ब्राउज़र अनुरोध रेखाओं में सर्वरों को क्या भेजते हैं GET /images/logo.png HTTP/1.1? क्या वे URL को हमेशा प्रतिशत-एन्कोड करते हैं?
फ्लिम्प

87

क्या कहा Tgr पृष्ठभूमि:

http://www.example.com/düsseldorf?neighbourhood=Lörick

वह यूआरआई नहीं है। लेकिन यह है एक IRI

आप HTML4 दस्तावेज़ में IRI शामिल नहीं कर सकते; विशेषताओं के प्रकार hrefको URI के रूप में परिभाषित किया गया है न कि IRI के रूप में। कुछ ब्राउज़र वैसे भी यहाँ एक आईआरआई संभाल लेंगे, लेकिन यह वास्तव में एक अच्छा विचार नहीं है।

एक आईआरआई को एक यूआरआई में एनकोड करने के लिए, पथ और क्वेरी भागों को लें, UTF-8-उन्हें फिर से एनकोड करें गैर-ASCII बाइट्स को एनकोड करें:

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

यदि IRI के होस्टनाम भाग में गैर-ASCII वर्ण हैं, जैसे। http://例え.テスト/, वे बजाय Punycode का उपयोग कर एन्कोड किया गया है।

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

http://en.wikipedia.org/wiki/ɸ

एक ब्राउज़र जिसका व्यवहार अप्रत्याशित है और हमेशा सुंदर IRI संस्करण प्रदर्शित नहीं करता है ...

...अच्छा आप जानते हैं।


31
मुझे पता है। एक दिन, किसी को एक बड़ा क्लब लेना है और उन लिंक्स डेवलपर्स को सिर पर स्मैक देना है। उत्कृष्ट पृष्ठभूमि की जानकारी के लिए धन्यवाद।
पेकका

2
@bobince और एक बॉट (2013 के लिए तेजी से) जो गैर IRI URI को भी नहीं संभाल सकता है ... ... ठीक है, आप जानते हैं: bingbot! जाओ पता लगाओ।
टॉम हैरिसन

1
HTML5 अंततः IRIs का समर्थन करता है। संबंधित विषय पर अधिक जानकारी संबंधित प्रश्न के उत्तर में पाई जा सकती है ।
ओलिवर

5
पुन: IE हमेशा सुंदर IRI प्रदर्शित नहीं कर रहे हैं - वे होमोग्राफ आधारित फ़िशिंग हमलों से उपयोगकर्ताओं की रक्षा कर रहे हैं। की जाँच करें w3.org/International/articles/idn-and-iri (विशेष खंड 'डोमेन नाम-और फ़िशिंग') और blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
कोडिंगआउटलाउड

2
डोमेन नाम का इससे कोई लेना-देना नहीं है। फ़िशिंग को रोकने के लिए सभी ब्राउज़र वर्णों की एक विस्तृत श्रृंखला को अस्वीकार कर देते हैं। पथ या क्वेरी स्ट्रिंग भाग में गैर- ASCII वर्णों को प्रदर्शित करना एक समान जीवंतता नहीं बनाता है। IE बस इसे लागू करने के लिए परेशान नहीं किया। (और फ़ायरफ़ॉक्स केवल एक है जिसने इसे खंड भाग के लिए भी लागू किया है।)
Tgr

16

अपनी URL योजना के आधार पर, आप UTF-8 एन्कोडेड भाग को "महत्वपूर्ण नहीं" बना सकते हैं। उदाहरण के लिए, यदि आप स्टैक ओवरफ्लो URL देखते हैं, तो वे निम्न रूप हैं:

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

हालाँकि, सर्वर वास्तव में परवाह नहीं करता है यदि आपको पहचानकर्ता के गलत होने के बाद भाग मिलता है, तो यह भी काम करता है:

http://stackoverflow.com/questions/2742852/ こ れ は, こ れ を 日本語 の テ キ ス ト で す

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


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

ठीक है, यह अभी भी शब्द "प्रश्न" को अनियंत्रित छोड़ देता है, साथ ही हैश # के बाद सामान भी है, जो पूरे यूआरएल का अनुसरण करता है, हालांकि बहुत ही मुश्किल है !!
इवगेनी

4
自動翻訳機を使ってその日本語のयूआरएलを作ったね।
Glutexo

6

सुनिश्चित नहीं है कि यह एक अच्छा विचार है, लेकिन जैसा कि अन्य टिप्पणियों में उल्लेख किया गया है और जैसा कि मैंने इसकी व्याख्या की है, एचटीएमएल 5 यूआरएल में कई यूनिकोड चार्ट मान्य हैं

उदाहरण के लिए, hrefडॉक्स http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

एक और क्षेत्र के तत्वों पर href विशेषता का मान होना चाहिए जो रिक्त स्थानों से घिरा एक मान्य URL है।

फिर "वैध URL" की परिभाषा http://url.spec.whatwg.org/ की ओर इशारा करती है , जो URL कोड बिंदुओं को परिभाषित करता है :

ASCII अल्फ़ान्यूमेरिक, "!", "$", "&", "" "," (",") "," * "," + ",", "-", ",", "/"। , ":", ",", "=", "=", "@", "_", "~", और कोड अंक U + 00A0 से U + D7FF, U + E000 से U + FDCF , U + FDF0 से U + FFFD, U + 10000 से U + 1FFFD, U + 20000 से U + 2FFFD, U + 30000 से U + 3FFFD, U + 40000 से U + 4FFFD, U + 50000 से U + 5FFFD, U + +60000 से U + 6FFFD, U + 70000 से U + 7FFFD, U + 80000 से U + 8FFFD, U + 90000 से U + 9FFFD, U + A0000 से U + AFFDD, U + B0000 से U + BFFFD, U + C0000 U + CFFFD, U + D0000 to U + DFFFD, U + E1000 to U + EFFFD, U + F0000 to U + FFFFD, U + 100000 से U + 10FFFD।

"URL कोड पॉइंट्स" शब्द का उपयोग पार्सिंग एल्गोरिथ्म के कुछ हिस्सों में किया जाता है, उदाहरण के लिए सापेक्ष पथ स्थिति :

यदि c एक URL कोड बिंदु नहीं है और "%" नहीं है, तो पार्स त्रुटि है।

इसके अलावा सत्यापनकर्ता http://validator.w3.org/ जैसे "你好"URL के लिए पास करता है, और रिक्त स्थान जैसे वर्ण वाले URL के लिए पास नहीं होता"a b"

संबंधित: कौन से वर्ण URL को अमान्य बनाते हैं?


लेकिन HTTP अनुरोध को सही बनाते समय दोनों URL ( "你好"और "a b") को एन्कोडेड होना चाहिए?
उटकु

@Utku के लिए "a b"मुझे पूरा यकीन है कि हाँ ऊपर की अनुमति सूची में नहीं है। के लिए "你好", यह निश्चित रूप से प्रतिशत को सांकेतिक शब्दों में बदलना बेहतर है, लेकिन मुझे नहीं पता कि क्या यह सिर्फ "कार्यान्वयन पर्याप्त नहीं हैं" या "मानक ऐसा कहता है" का सवाल है। HTML मानक उन वर्णों को अनुमति देता है। लेकिन मुझे लगता है कि यह HTML नहीं, HTTP मानक द्वारा निर्दिष्ट किया गया है। इन्हें भी देखें: stackoverflow.com/questions/912811/…
Ciro Santilli 郝海东 flow flow flow flow 六四

हां, मैं एचटीएमएल नहीं, HTTP मानक के बारे में सोच रहा था।
उत्कर्ष Ut

5

इन सभी टिप्पणियों के सच होने के बाद, आपको ध्यान देना चाहिए कि जहाँ तक ICANN ने अरबी (फ़ारसी) और चीनी अक्षरों को डोमेन नाम के रूप में पंजीकृत करने की स्वीकृति दी है, सभी ब्राउज़र बनाने वाली कंपनियों (Microsoft, मोज़िला, Apple, आदि) के पास है। किसी भी एन्कोडिंग के बिना यूआरएल में यूनिकोड का समर्थन करें, और उन्हें Google द्वारा खोजा जाना चाहिए, आदि।

तो यह समस्या ASAP को हल कर देगी।


2
@Nasser: यह सच है - हम जर्मन डोमेन में विशेष वर्ण अब भी है - लेकिन उन का उपयोग कर ASCII वर्ण में इनकोड पनीकोड । हालांकि वे प्रमुख ब्राउज़रों में काम करने के लिए निश्चित हैं, यह हर HTTP क्लाइंट लाइब्रेरी से पहले एक लंबा समय होगा और विदेशी एप्लिकेशन अनएन्कोडेड यूनिकोड वर्णों से निपटने में सक्षम होगा।
पाइका

@Pekka, मुझे यकीन नहीं है लेकिन जैसा कि मैंने सुना है, सभी ब्राउज़रों को 2010 की चौथी तिमाही में यूनिकोड URL का समर्थन करना है। (I
am

समस्या इस तथ्य से जटिल है कि प्रत्येक उपयोगकर्ता एजेंट एक वेब ब्राउज़र नहीं है। सबसे बड़ा उदाहरण स्वयं Google है: यह क्रॉल करने के लिए आम वेब ब्राउज़र का उपयोग नहीं करता है। तो एपीआई इंटरेक्शन आदि के लिए कई लाइब्रेरी आदि - URL लगभग हर जगह हैं, न कि केवल WWW में। शायद अभी आपकी फाइल सिस्टम पर भी है।
कॉर्नेलियस

1

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

हालांकि, एक नकारात्मक पक्ष यह है कि प्रतिशत-एन्कोड किए गए वर्ण मूल लोगों की तुलना में लंबे होते हैं, इस प्रकार संभवतः लंबे URLs होते हैं। लेकिन बस इसे अनदेखा करने की कोशिश करें, या एक URL शॉर्टनर का उपयोग करें (मैं इस मामले में goo.gl की सिफारिश करूंगा , जो एक 13-वर्ण का URL बनाता है)। इसके अलावा, यदि आप Google खाते के लिए पंजीकरण नहीं करना चाहते हैं, तो बिट की कोशिश करें। (बिट.ली थोड़ा लंबा URL बनाता है, जिसकी लंबाई 14 वर्ण है)।


मैं अप्रचलित कंप्यूटरों का समर्थन क्यों करना चाहूंगा जो अभी भी विंडोज एक्सपी का उपयोग करते हैं?
मेटुस फेलिप

0

मेरे लिए यह सही तरीका है, यह सिर्फ काम किया है:

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

यह काम किया है, और अब लिंक ठीक से प्रदर्शित कर रहे हैं:

http://newspaper.annahar.com/article/121638 -معر - جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وتفرض-الوفف.

इस पर लिंक मिला:

http://www.galeriejaninerubeiz.com/newsite/news


2
"लिंक ठीक से प्रदर्शित होते हैं" - सिवाय इसके कि StackOverflow markdown parser URLs की व्याख्या नहीं करता है!
Mrhhite
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.