अनुकूल url के लिए सुरक्षित वर्ण [बंद]

Question

मुझे एक वेबसाइट बनाने की ज़रूरत है जिसमें लेख होंगे, और मैं इसके लिए अनुकूल URL बनाना चाहता हूँ, उदाहरण के लिए पृष्ठ का URL

शीर्षक: अनुच्छेद परीक्षण

हो जाना चाहिए: http://www.example.com/articles/article_test।

बेशक मैं जैसे शीर्षक से कुछ पात्रों को हटाने की जरूरत ?है या #है, लेकिन मुझे यकीन है कि कौन सा दूर करने के लिए नहीं कर रहा हूँ।

क्या कोई मुझे बता सकता है कि कौन से पात्र रखना सुरक्षित है?

Comments

एक ऐसी ही सवाल ही नहीं था, यहाँ । इसे देखें, आपको वहां कुछ उपयोगी उत्तर भी मिल सकते हैं (उनमें से बहुत से थे)।

— रूक

Answer 1

RFC 3986 की धारा 2.3 को उद्धृत करने के लिए :

"वर्ण जिन्हें एक URI में अनुमति दी जाती है लेकिन एक आरक्षित उद्देश्य नहीं होता है उन्हें अनारक्षित कहा जाता है। इनमें अपरकेस और लोअरकेस अक्षर, दशमलव अंक, हाइफ़न, अवधि, अंडरस्कोर और टिल्ड शामिल हैं।"

ALPHA  DIGIT  "-" / "." / "_" / "~"

ध्यान दें कि RFC 3986 पुराने RFC 2396 की तुलना में कम आरक्षित विराम चिह्न को सूचीबद्ध करता है ।

Comments

@Skip हेड, "वर्ण" में लैटिन एन्कोडेड वर्ण जैसे çऔर शामिल हैं õ?

— मोहम्मद

@ मोहम्मद: नहीं, केवल ASCII, हालांकि UTF-8 का समर्थन बेहतर हो रहा है।

— डायट्रीच एप्प

@ डिट्रिक एप, धन्यवाद। मुझे लगता है कि URL को सजावट और एसईओ उद्देश्यों के लिए कोई फर्क नहीं पड़ता, जैसे: www.mysite.com/.postIdiding/post-title-with-ç-and-õ

— Mohamad

@ मोहम्मद: आखिरी हिस्सा हुड के तहत बदल जाएगा post-title-with-%C3%A7-and-%C3%B5, लेकिन यह अभी भी उपयोगकर्ता के स्थान बार में प्रदर्शित होगा post-title-with-ç-and-õ।

— डायट्रिच एप्प

आपके पाठक पुर्तगाली हैं, इसलिए पुर्तगाली पात्रों का उपयोग करें।

— डायट्रिच एप्प

Answer 2

वर्णों के दो सेट हैं जिन्हें आपको देखने की आवश्यकता है: आरक्षित और असुरक्षित ।

आरक्षित चरित्र:

• एम्परसैंड ("और")
• डॉलर ("$")
• धन चिह्न ("+")
• अल्पविराम (",")
• फ़ॉर्वर्ड स्लैश ("/")
• बृहदान्त्र (":")
• अर्ध-उपनिवेश ("?")
• बराबर ("=")
• प्रश्न चिन्ह ("?")
• 'एट' सिंबल ("@")
• पाउंड ("#")।

आमतौर पर असुरक्षित माने जाने वाले पात्र हैं:

• अंतरिक्ष ("")
• से कम और इससे अधिक ("<>")
• कोष्ठक खोलें और बंद करें ("[]")
• खुले और बंद ब्रेसेस ("{}")
• पाइप ("|")
• बैकस्लैश ("\")
• कैरेट ("^")
• प्रतिशत ("%")

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

Comments

#एक विशिष्ट पृष्ठ पर बुकमार्क के लिए उपयोग किया जाने वाला एक आरक्षित वर्ण है, जो एक HTML तत्व से मेल खाते नाम-विशेषता या आईडी-विशेषता (sans #-symbol) के साथ बनाया गया है।

— TheLonelyGhost 14

धन्यवाद - मैंने उत्तर अपडेट कर दिया है।

— गैरी.रे

प्रश्नचिह्न यहां आरक्षित और असुरक्षित दोनों के रूप में दिखाई देता है - मैं इसे केवल आरक्षित के रूप में समझता हूं, लेकिन मैं गलत हो सकता हूं

— जोनाथन बेसिल

दूसरे की यह असहमति प्रतीत होती है कि टिल्ड ~असुरक्षित है। क्या आपको यकीन है कि यह है?

— डीआरएस

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

— पतंजलि

Answer 3

आप कुछ पात्रों (ब्लैकलिस्ट) को हटाने के बजाय केवल कुछ वर्ण (श्वेतसूची) रख रहे हैं।

आप किसी भी चरित्र को तकनीकी रूप से अनुमति दे सकते हैं, जब तक आप इसे ठीक से एनकोड करते हैं। लेकिन, सवाल की भावना का जवाब देने के लिए, आपको केवल इन पात्रों की अनुमति देनी चाहिए:

1. लोअर केस लेटर्स (अपर केस को लोवर में बदलें)
2. संख्या, ० ९ के माध्यम से
3. एक पानी का छींटा - या अंडरस्कोर _
4. टिल्डे ~

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

अन्य टिप्पणियों के साथ, पूर्ण विवरण के लिए मानकों और विनिर्देशों की जांच करें।

Comments

एक प्रीडियो, जो मैंने आज खोजा है, URL-सुरक्षित Base64 एनकोडर के लिए उपयोग करने के लिए चरित्र का एक बुरा विकल्प है, क्योंकि ऐसे दुर्लभ मामले होंगे जहां आपके एन्कोड किए गए डेटा लगातार दो डॉट्स ("..") का उत्पादन कर सकते हैं, जो महत्वपूर्ण है यह मूल निर्देशिका को संदर्भित करता है।

— पोहल

@pohl: यह केवल एक समस्या है अगर आपके URL का उपयोग फ़ाइल पथ के रूप में किया जाता है, या तो आपके कोड में या यदि आपका वेब सर्वर वास्तव में स्क्रिप्ट के लिए अनुरोध भेजने से पहले URL को फाइलों में मैप करने की कोशिश करता है (दुर्भाग्य से बहुत ही सामान्य)।

— एंड्रे कारन

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

— पोहल

भगवान का शुक्र है कि किसी ने बिना ज्यादा भड़काने के साथ एक सूची पोस्ट की। डॉट के लिए (।) के रूप में - @pohl ने कहा, इसका उपयोग न करें! यहां IIS पर एक और अजीब मामला है (यह नहीं पता कि क्या यह अन्य वेब सर्वर पर होता है): यदि यह आपके URL के अंत में है तो आपको सबसे अधिक 404 त्रुटि मिलेगी (यह [/ pagename] के लिए खोज करने का प्रयास करेगा) पृष्ठ)

— nikib3ro

Answer 4

हमेशा सुरक्षित

ये सुरक्षित हैं (सिद्धांत / कल्पना में), मूल रूप से डोमेन नाम को छोड़कर कहीं भी।
प्रतिशत-सूचीबद्ध कुछ भी सूचीबद्ध नहीं है, और आप जाने के लिए अच्छे हैं।

    A-Z a-z 0-9 - . _ ~ ( ) ' ! * : @ , ;

कभी-कभी सुरक्षित

केवल विशिष्ट URL घटकों के भीतर उपयोग किए जाने पर सुरक्षित; देखभाल के साथ उपयोग करें।

    Paths:     + & =
    Queries:   ? /
    Fragments: ? / # + & =
    

कभी सुरक्षित नहीं

URI युक्ति (RFC 3986) के अनुसार, अन्य सभी वर्णों को प्रतिशत-एन्कोडेड होना चाहिए। यह भी शामिल है:

    <space> <control-characters> <extended-ascii> <unicode>
    % < > [ ] { } | \ ^
    

यदि अधिकतम अनुकूलता एक चिंता है, तो AZ az 0-9 - _ के लिए चारसेट को सीमित करें।
(केवल फ़ाइल नाम एक्सटेंशन के लिए अवधि के साथ)।

ध्यान में रखें

भले ही प्रति मान्य मान्य हो, संदर्भ के आधार पर, एक URL अभी भी "असुरक्षित" हो सकता है। जैसे फ़ाइल: /// URL में अमान्य फ़ाइल नाम वर्ण या ""? "," = ", और" & "युक्त अंश घटक जब सीमांकक के रूप में उपयोग नहीं किया जाता है। इन मामलों की सही हैंडलिंग आम तौर पर आपकी लिपियों तक होती है और इन पर काम किया जा सकता है, लेकिन यह ध्यान में रखने वाली चीज़ है।

Comments

क्या आप अपने दूसरे दावे ("कभी-कभी सुरक्षित") के लिए कोई स्रोत प्रदान कर सकते हैं? विशेष रूप से, मेरा मानना ​​है कि आप यह कहना गलत है कि =प्रश्नों के लिए सुरक्षित नहीं है। उदाहरण के लिए, FIQL समान संकेतों को स्वीकार करता है और खुद को "URI के अनुकूल" और "क्वेरी घटक में उपयोग के लिए अनुकूलित और इच्छित" होने के रूप में वर्णन करता है। मेरी व्याख्या में, RFC 3986 स्पष्ट रूप से "=", "और", "+" और अन्य को प्रश्नों में अनुमति देता है।

— डैनियलएम

@DanielM "?", "=", और "&" प्रति प्रश्न क्वेरी में मान्य हैं, हालांकि व्यवहार में वे व्यापक रूप से क्वेरी के भीतर नाम-मूल्य जोड़े को पार्स करने के लिए उपयोग किए जाते हैं। इसलिए वे स्वयं नामों / मूल्यों के हिस्से के रूप में असुरक्षित हो सकते हैं। यह "असुरक्षित" बनता है या नहीं, यह राय का विषय हो सकता है।

— बीजर

कुछ स्रोत, अनुरोध के रूप में। (1) RFC 3986, Sec 3.4: "[...] क्वेरी घटकों का उपयोग अक्सर 'कुंजी = मान' जोड़े [...] के रूप में जानकारी की पहचान करने के लिए किया जाता है।" (2) WhatWG URL Spec, Sec। ६.२: "URLSearchParams ऑब्जेक्ट का निर्माण और कड़ाई करना काफी सरल है: [...] params.toString() // "key=730d67"" (3) PHP मैनुअल, http-build-query: "URL-एन्कोडेड क्वेरी स्ट्रिंग उत्पन्न करें। [...] उपरोक्त उदाहरण आउटपुट होगा। 0=foo&1=bar[...]"(4) जे। स्टारर, पेरिशबल प्रेस:" वेब पेज बनाते समय, अक्सर उन लिंक को जोड़ना आवश्यक होता है, जिनके लिए पैरामीटर क्वेरी स्ट्रिंग्स की आवश्यकता होती है। "

— बीजर

@Beejor: मैं एक URL का निर्माण कर रहा हूं और मैं '-' और ';' निर्माण के दौरान। यह एक वेब ऐप नहीं बल्कि एक मोबाइल ऐप है। यदि कोई वेब डेवलपर नहीं है और इसलिए, क्या मैं पथ संपत्ति में उपरोक्त दो वर्णों का उपयोग करूंगा? docs.microsoft.com/en-us/dotnet/api/…

— karsnen

@karsnen वे मान्य URL वर्ण हैं। यद्यपि यदि किसी स्थानीय फ़ाइल सिस्टम पर पथों को संदर्भित करने के लिए उपयोग किया जाता है, तो ध्यान रखें कि कुछ सिस्टम फ़ाइल नाम में कुछ वर्णों को अस्वीकार करते हैं। उदाहरण के लिए, "फ़ाइल: /// पथ / to / my: file.ext" मैक पर अमान्य होगा।

— बीजर

Answer 5

को देखते हुए RFC3986 - यूनिफ़ॉर्म रिसोर्स पहचानकर्ता (URI): जेनेरिक सिंटेक्स , चारों ओर अपने प्रश्न घूमता पथ यूआरआई के घटक।

    foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

अनुभाग 3.3 का हवाला देते हुए, URI के लिए मान्य वर्ण segmentप्रकार हैं pchar:

pchar = अनारक्षित / pct- एन्कोडेड / सब-डेलिम्स / ":" / "@"

जो टूट जाता है:

ALPHA / DIGIT / "-" / "." / "_" / "~"

pct-encoded

"!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

":" / "@"

या दूसरे शब्दों में: आप से किसी भी (गैर नियंत्रण) चरित्र का उपयोग कर सकते ASCII तालिका , सिवाय / , ?, #, [और ]।

यह समझ RFC1738 - यूनिफ़ॉर्म रिसोर्स लोकेटर (URL) द्वारा समर्थित है ।

Comments

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

— डेल्टामाइंड106

@ deltamind106 क्या आप उदाहरण और / या संदर्भ प्रदान कर सकते हैं ताकि यह स्पष्ट किया जा सके कि कौन से अक्षर RFC के अनुसार सुरक्षित हैं? मैं अपने उत्तर में मानकों द्वारा समर्थित तथ्यों से चिपके रहना पसंद करूंगा, और अगर आप किसी भी तथ्य की उपेक्षा कर सकते हैं तो मैं अपने उत्तर को अपडेट करने के लिए खुश हूं।

— फिलजीन डिक

@ deltamind106 मेरा सुझाव है कि हम उत्पादों को मानकों का पालन करने के बजाय देवों को नहीं बताने की कोशिश करेंगे। मुझे लगता है कि आपकी चेतावनी को मेरिट में शामिल किया गया है, लेकिन यदि आवश्यक हो तो विक्रेताओं को गैर-अनुपालन की रिपोर्ट करने में हमें अपनी भागीदारी करनी चाहिए।

— लो-टैन

@Philzen: मैं एक URL का निर्माण कर रहा हूं और मैं '-' और ';' निर्माण के दौरान। यह एक वेब ऐप नहीं बल्कि एक मोबाइल ऐप है। यदि कोई वेब डेवलपर नहीं है और इसलिए, क्या मैं पथ संपत्ति में उपरोक्त दो वर्णों का उपयोग करूंगा? docs.microsoft.com/en-us/dotnet/api/…

— karsnen

@karsnen हाँ, निश्चित रूप से -और ;सुरक्षित हैं, यही मेरा जवाब है और RFC स्पष्ट रूप से बताता है।

— फिलाजेन

Answer 6

अनारक्षित = अल्फा / DIGIT / "-" / "।" / "_" / "~"

Comments

क्या "अल्फा" का अर्थ "DIGIT" नहीं है? मेरा मानना ​​है कि अल्फा "अल्फ़ान्यूमेरिक" के लिए छोटा है, और अल्फ़ान्यूमेरिक का अर्थ अपरकेस, लोअरकेस और अंक है।

— लुक

वास्तव में अल्फा का अर्थ अल्फ़ान्यूमेरिक नहीं है। अल्फा और न्यूमेरिक 2 अलग चीजें हैं और अल्फान्यूमेरिक उन चीजों का संयोजन है। वह अपना उत्तर इस तरह लिख सकता था: ALPHANUMERIC / "-" / "।" / "_" / "~"

— मैक्रोमैन

RFC 3986 में 'अनारक्षित' के लिए ABNF अंकन उन्हें अलग से सूचीबद्ध करता है।

— पतंजलि

Answer 7

आपके द्वारा वर्णित संदर्भ से, मुझे संदेह है कि जो आप वास्तव में बनाने की कोशिश कर रहे हैं उसे कुछ 'एसईओ स्लग' कहा जाता है। उन लोगों के लिए सबसे अच्छा सामान्य ज्ञात अभ्यास है:

1. लोअर-केस में कनवर्ट करें
2. Az और 0-9 के अलावा वर्णों के पूरे दृश्यों को एक हाइफ़न (-) में बदलें (अंडरस्कोर नहीं)
3. URL से 'स्टॉप वर्ड्स' निकालें, अर्थात 'ए', 'ए', और 'द' जैसे सार्थक-इंडेक्सेबल शब्द नहीं; व्यापक सूचियों के लिए Google 'स्टॉप वर्ड्स'

इसलिए, एक उदाहरण के रूप में, "द यूज ऑफ़! @% $ * का प्रतिनिधित्व करने के लिए" कॉमिक्स में शपथ ग्रहण करने वाले "शीर्षक वाले लेख को" उपयोग-प्रतिनिधित्व-शपथ ग्रहण-कॉमिक्स "का एक स्लग मिलेगा।

Comments

क्या वास्तव में इन "रोक शब्दों" को url से निकालना एक अच्छा तरीका है? क्या खोज इंजन इस वजह से किसी वेबसाइट को दंडित करेंगे?

— पाउलो

माना जाता है कि खोज इंजन आमतौर पर केवल URL के कुछ हिस्से को स्वीकार करते हैं और / या बाद के हिस्सों को कम महत्व देते हैं, इसलिए आप जो भी काम कर रहे हैं, उन्हें रोककर, अपने URL में आपके द्वारा एम्बेड किए गए कीवर्ड की संख्या को अधिकतम कर रहे हैं, जो आपके पास एक मौका है वास्तव में रैंकिंग पर।

— अराजकता

@chaos क्या आप अभी भी स्टॉपवार्ड को अलग करने की सलाह देते हैं, यदि आप इस बात को ध्यान में रखते हैं: seobythesea.com/2008/08/google-stopword-patent इसके अलावा, क्या आप स्टॉपवार्ड की एक अच्छी सूची की सिफारिश कर सकते हैं? यह मेरी अब तक की सबसे अच्छी सूची है - link-assistant.com/seo-stop-words.html

— nikib3ro

@ kape123 जो मुझे एक बहुत अच्छी सूची की तरह नहीं लगती है। "c" और "d" प्रोग्रामिंग भाषाएं हैं, और उनमें से कई अन्य शब्द भी महत्वपूर्ण लगते हैं। मैं शायद सिर्फ मूल लोगों को पट्टी करूँगा: एक, और, पर, या, के, साथ, है।

— mpen

Answer 8

URI के लिए प्रारूप RFC 3986 में परिभाषित किया गया है । विवरण के लिए अनुभाग 3.3 देखें।

Answer 9

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

Answer 10

मुझे भी ऐसी ही समस्या थी, मैं चाहता था कि मेरे पास बहुत से यूआरएल हों और मैं इस नतीजे पर पहुँचूँ कि मुझे केवल अक्षरों, अंकों, - और _ urls में ही अनुमति देनी है। यह ठीक है, फिर मैंने कुछ अच्छे रेगेक्स लिखे और मैंने महसूस किया कि यह पहचानता है कि सभी UTF8 वर्ण .NET में अक्षर नहीं हैं और खराब हो गए थे। यह .NET रेगेक्स इंजन के लिए एक ज्ञात समस्या प्रतीत होती है। तो मैं इस समाधान के लिए मिला:

private static string GetTitleForUrlDisplay(string title)
{
    if (!string.IsNullOrEmpty(title))
    {
        return Regex.Replace(Regex.Replace(title, @"[^A-Za-z0-9_-]", new MatchEvaluator(CharacterTester)).Replace(' ', '-').TrimStart('-').TrimEnd('-'), "[-]+", "-").ToLower();
    }
    return string.Empty;
}


/// <summary>
/// All characters that do not match the patter, will get to this method, i.e. useful for unicode chars, because
/// .NET impl of regext do not handle unicode chars. So we use char.IsLetterOrDigit() which works nicely and we 
/// return what we approve and return - for everything else.
/// </summary>
/// <param name="m"></param>
/// <returns></returns>
private static string CharacterTester(Match m)
{
    string x = m.ToString();
    if (x.Length > 0 && char.IsLetterOrDigit(x[0]))
    {
        return x.ToLower();
    }
    else
    {
        return "-";
    }
}

Comments

.NET regexes वास्तव में काफी अच्छी तरह से यूनिकोड का समर्थन करता है। आपको सभी पत्रों के लिए यूनिकोड वर्ण वर्गों जैसे \ p {L} का उपयोग करना होगा। देखें msdn.microsoft.com/en-us/library/20bw873z.aspx#CategoryOrBlock

— TheCycoONE

Answer 11

मुझे अपने url को एक सुरक्षित करने के लिए एन्कोड करने के लिए बहुत उपयोगी लगा जब मैं ajax / php के माध्यम से एक url पर मान लौटा रहा था जिसे बाद में पृष्ठ द्वारा फिर से पढ़ा गया।

विशेष चरित्र और के लिए url एनकोडर के साथ PHP उत्पादन

//PHP returning the sucess info of ajax request
echo "".str_replace('&','%26',$_POST['name'])." category was changed";

//javascript sending the value to url
window.location.href='time.php?return=updated&val='+msg;

//javascript/php executing the function printing the value of the url,
//now with the text normally lost in space because of the reserved & character.

setTimeout("infoApp('updated','<?php echo $_GET['val'];?>');",360);

आशा है कि किसी को भी मेरे छोटे कोड अर्क उपयोगी लगता है! :)

Answer 12

मुझे लगता है कि आप "URL एनकोडिंग" जैसी किसी चीज़ की तलाश कर रहे हैं - एक URL एन्कोडिंग ताकि यह वेब पर उपयोग करने के लिए "सुरक्षित" हो:

यहाँ उस के लिए एक संदर्भ है। यदि आप कोई विशेष वर्ण नहीं चाहते हैं, तो URL एन्कोडिंग की आवश्यकता वाली कोई भी सामग्री निकालें:

http://www.w3schools.com/TAGS/ref_urlencode.asp

Answer 13

3-50 अक्षर के बीच। लोअरकेस अक्षर, संख्या और विशेष वर्ण - डॉट (।), डैश (-), अंडरस्कोर (_) और दर (@) शामिल कर सकते हैं।

Comments

उसके लिए कोई संदर्भ?

— dakab