संदर्भ: mod_rewrite, URL पुनर्लेखन और "सुंदर लिंक" समझाया गया


142

"सुंदर लिंक" अक्सर अनुरोधित विषय है, लेकिन यह शायद ही कभी पूरी तरह से समझाया गया है। mod_rewrite "सुंदर लिंक" बनाने का एक तरीका है, लेकिन यह जटिल है और इसका सिंटैक्स बहुत कठिन है, कठिन है, और प्रलेखन HTTP में एक निश्चित स्तर की दक्षता मानता है। क्या कोई सरल शब्दों में समझा सकता है कि "सुंदर लिंक" कैसे काम करते हैं और उन्हें बनाने के लिए mod_rewrite का उपयोग कैसे किया जा सकता है?

अन्य सामान्य नाम, उपनाम, स्वच्छ URL के लिए नियम: प्रतिष्ठित URL, उपयोगकर्ता के अनुकूल URL, SEO -friendly URL, स्लैगिंग और MVC URL (शायद एक मिथ्या नाम)


2
स्लग या स्लगिंग एक और सामान्य उपनाम है / सुंदर यूआरएल के लिए शब्द।
माइक बी

2
@ माइक क्रमबद्ध करें, लेकिन स्लग अक्सर सुंदर यूआरएल का एक हिस्सा होते हैं। एक स्लग बहुत विशेष रूप से तब होता है जब, उदाहरण के लिए, एक लेख का शीर्षक एक URL के अनुकूल रूप में बदल दिया जाता है जो तब उस लेख के पहचानकर्ता के रूप में कार्य करता है। तो reference-mod-rewrite-url-rewriting-explainedस्लग /questions/20563772/reference-mod-rewrite-url-rewriting-explainedहै, सुंदर यूआरएल है।
deceze

2
मुझे लगता है कि इस सवाल का लिंक शामिल करने के लिए टैग .htaccessऔर mod-rewriteटैग को अपडेट किया जाना चाहिए, क्योंकि यह नियमित आधार पर जो कुछ भी पूछा जाता है, उसमें से अधिकांश को शामिल करता है। विचार?
माइक रॉकएट

जवाबों:


110

Mod_rewrite को समझने के लिए आपको सबसे पहले यह समझने की जरूरत है कि वेब सर्वर कैसे काम करता है। एक वेब सर्वर HTTP अनुरोधों का जवाब देता है । इसके सबसे बुनियादी स्तर पर HTTP अनुरोध इस तरह दिखता है:

GET /foo/bar.html HTTP/1.1

यह एक वेब सर्वर के लिए एक ब्राउज़र का सरल अनुरोध है, जो URL /foo/bar.html से अनुरोध करता है। यह जोर देना महत्वपूर्ण है कि यह एक फ़ाइल का अनुरोध नहीं करता है , यह सिर्फ कुछ मनमाने यूआरएल का अनुरोध करता है। अनुरोध इस तरह दिख सकता है:

GET /foo/bar?baz=42 HTTP/1.1

यह एक URL के लिए एक अनुरोध के रूप में मान्य है, और इसमें फ़ाइलों के साथ अधिक स्पष्ट रूप से कुछ भी नहीं है।

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

अधिकांश वेब सर्वरों का डिफ़ॉल्ट कॉन्फ़िगरेशन एक फाइल की तलाश है जो हार्ड डिस्क पर URL से मेल खाता है। यदि सर्वर का डॉक्यूमेंट रूट सेट किया गया है, तो कहें /var/www, यह दिख सकता है कि क्या फ़ाइल /var/www/foo/bar.htmlमौजूद है और यदि ऐसा है तो सेवा करें। यदि फ़ाइल ".php" में समाप्त होती है, तो यह PHP दुभाषिया को आमंत्रित करेगी और फिर परिणाम लौटाएगी। यह सब एसोसिएशन पूरी तरह से विन्यास योग्य है; वेब सर्वर के लिए PHP दुभाषिया के माध्यम से चलाने के लिए एक फ़ाइल को ".php" में समाप्त नहीं करना पड़ता है, और कुछ होने के लिए URL को डिस्क पर किसी विशेष फ़ाइल से मेल नहीं खाता है।

mod_rewrite आंतरिक अनुरोध हैंडलिंग को फिर से लिखने का एक तरीका है । जब वेब सर्वर को URL के लिए एक अनुरोध प्राप्त होता है /foo/bar, तो आप उस URL को किसी अन्य चीज़ में फिर से लिख सकते हैं, इससे पहले कि वेब सर्वर उस पर मेल करने के लिए डिस्क पर एक फ़ाइल की तलाश करेगा। सरल उदाहरण:

RewriteEngine On
RewriteRule   /foo/bar /foo/baz

यह नियम कहता है कि जब भी कोई अनुरोध "/ foo / bar" से मेल खाता है, तो इसे "/ foo / baz" में फिर से लिखें। इसके बाद अनुरोध को संभाल लिया जाएगा जैसे /foo/bazकि इसके बजाय अनुरोध किया गया था। इसका उपयोग विभिन्न प्रभावों के लिए किया जा सकता है, उदाहरण के लिए:

RewriteRule (.*) $1.html

यह नियम कुछ भी ( .*) से मेल खाता है और इसे कैप्चर करता है ( (..)), फिर इसे ".html" में जोड़ने के लिए फिर से लिखता है। दूसरे शब्दों में, यदि /foo/barअनुरोधित URL था , तो इसे ऐसे ही हैंडल किया जाएगा जैसे कि /foo/bar.htmlअनुरोध किया गया था। नियमित अभिव्यक्ति मिलान, कैप्चरिंग और प्रतिस्थापन के बारे में अधिक जानकारी के लिए http:// अनियमित- expressions.info देखें ।

एक और अक्सर सामना किया गया नियम यह है:

RewriteRule (.*) index.php?url=$1

यह, फिर से, किसी भी चीज़ से मेल खाता है और इसे फ़ाइल इंडेक्स में फिर से लिखता है url। क्वेरी पैरामीटर में मूल रूप से अनुरोधित URL के साथ । यानी, आने वाले किसी भी और सभी अनुरोधों के लिए, फ़ाइल index.php निष्पादित किया जाता है और इस फ़ाइल में मूल अनुरोध तक पहुंच होगी $_GET['url'], इसलिए यह इसके साथ कुछ भी कर सकता है।

मुख्य रूप से आप इन पुनर्लेखन नियमों को अपनी वेब सर्वर कॉन्फ़िगरेशन फ़ाइल में रखते हैं । अपाचे भी * आप उन्हें .htaccessअपने दस्तावेज़ रूट (यानी आपके .php फ़ाइलों के बगल में) नामक एक फ़ाइल में डालने की अनुमति देता है ।

* यदि प्राथमिक अपाचे कॉन्फ़िगरेशन फ़ाइल द्वारा अनुमति दी गई है; यह वैकल्पिक है, लेकिन अक्सर सक्षम है।

Mod_rewrite क्या नहीं करता है

mod_rewrite जादुई रूप से आपके सभी URL को "सुंदर" नहीं बनाती है। यह एक सामान्य गलतफहमी है। यदि आपकी वेब साइट में यह लिंक है:

<a href="https://stackoverflow.com/my/ugly/link.php?is=not&amp;very=pretty">

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

  1. लिंक को सुंदर लिंक में बदलें:

    <a href="https://stackoverflow.com/my/pretty/link">
    
  2. /my/pretty/linkऊपर वर्णित विधियों में से किसी एक का उपयोग करके URL के अनुरोध को संभालने के लिए सर्वर पर mod_rewrite का उपयोग करें ।

(एक mod_substituteआउटगोइंग HTML पेज और उनके सम्‍मिलित लिंक को बदलने के लिए संयोजन का उपयोग कर सकता है । हालांकि यह केवल आपके निजी संसाधनों को अपडेट करने की तुलना में हमारे लिए अधिक प्रयास है।)

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

सभी संभावित झंडे और विकल्पों के लिए आधिकारिक दस्तावेज देखें ।


6
शायद एक डिस्पैचर को फिर से लिखने के पूर्व निर्धारित तरीके के रूप में संस्करण 2.2.16 में पेश किए गए FallbackResource निर्देश का उल्लेख करें ।
डारस्टार

78

छल के जवाब पर विस्तार करने के लिए , मैं कुछ उदाहरण और कुछ अन्य mod_rewrite कार्यक्षमता की व्याख्या करना चाहता था।

नीचे दिए गए सभी उदाहरण यह मानते हैं कि आपने पहले ही RewriteEngine Onअपनी .htaccessफ़ाइल में शामिल कर लिया है ।

पुनर्लेखन का उदाहरण

इस उदाहरण को लें:

RewriteRule ^blog/([0-9]+)/([A-Za-z0-9-\+]+)/?$ /blog/index.php?id=$1&title=$2 [NC,L,QSA]

नियम 4 खंडों में विभाजित है:

  1. RewriteRule - फिर से लिखना शुरू करता है नियम
  2. ^blog/([0-9]+)/([A-Za-z0-9-\+]+)/?$ - इसे पैटर्न कहा जाता है, हालांकि मैं इसे नियम के बाएं हाथ के रूप में संदर्भित करूंगा - आप इससे क्या लिखना चाहते हैं
  3. blog/index.php?id=$1&title=$2 - पुनर्स्थापन नियम का प्रतिस्थापन या दाहिना हाथ पक्ष - जिसे आप फिर से लिखना चाहते हैं
  4. [NC,L,QSA] पुनर्लेखन नियम के लिए झंडे, एक अल्पविराम द्वारा अलग किए गए हैं, जिसे मैं बाद में और अधिक समझाऊंगा

उपरोक्त फिर से लिखना आपको कुछ इस तरह से जोड़ने की अनुमति देगा /blog/1/foo/और यह वास्तव में लोड होगा /blog/index.php?id=1&title=foo

नियम का बायाँ हाथ

  • ^पृष्ठ नाम की शुरुआत इंगित करता है - इसलिए यह फिर से लिखना होगा example.com/blog/...लेकिन नहींexample.com/foo/blog/...
  • (…)कोष्ठक का प्रत्येक सेट एक नियमित अभिव्यक्ति का प्रतिनिधित्व करता है जिसे हम नियम के दाहिने हाथ में एक चर के रूप में पकड़ सकते हैं। इस उदाहरण में:
    • कोष्ठक का पहला सेट - ([0-9]+)- लंबाई में न्यूनतम 1 वर्ण के साथ और केवल संख्यात्मक मान (यानी 0-9) के साथ एक स्ट्रिंग से मेल खाता है। इसे $1नियम के दाहिने हाथ में संदर्भित किया जा सकता है
    • कोष्ठक का दूसरा सेट लंबाई में कम से कम 1 वर्ण के साथ एक तार से मेल खाता है, जिसमें केवल अल्फ़ान्यूमेरिक वर्ण (AZ, az, या 0-9) या -या +(नोट +बैकस्लैश के साथ भाग गया है, बिना भाग निकले यह एक रेगेक्स के रूप में निष्पादित होगा) दोहराव चरित्र )। इसे $2नियम के दाहिने हाथ में संदर्भित किया जा सकता है
  • ?अर्थ यह है कि पूर्ववर्ती चरित्र वैकल्पिक है, इसलिए इस मामले में दोनों /blog/1/foo/और /blog/1/fooएक ही जगह पर फिर से लिखने होगा
  • $ इंगित करता है कि यह उस स्ट्रिंग का अंत है जिसे हम मैच करना चाहते हैं

झंडे

ये विकल्प हैं जो कुछ शर्तों को निर्दिष्ट करने के लिए आपके पुनर्लेखन नियम के अंत में वर्ग कोष्ठक में जोड़े जाते हैं। फिर, बहुत सारे अलग-अलग झंडे हैं जिन्हें आप डॉक्यूमेंटेशन में पढ़ सकते हैं , लेकिन मैं कुछ और सामान्य झंडों से गुजरूंगा:

NC

कोई भी मामला ध्वज का अर्थ यह नहीं है कि पुनर्लेखन नियम असंवेदनशील है, इसलिए इसके ऊपर के उदाहरण के नियम का अर्थ यह होगा कि दोनों /blog/1/foo/और /BLOG/1/foo/(या इसके किसी भी रूपांतर) का मिलान किया जाएगा।

L

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

END

Apache 2.4 के बाद से आप [END]ध्वज का उपयोग भी कर सकते हैं । इसके साथ एक मेल नियम पूरी तरह से अन्य उपनाम / पुनर्लेखन प्रक्रिया को समाप्त कर देगा । (जबकि [L]फ्लैग कैन्टिम्स दूसरे राउंड को ट्रिगर करते हैं, उदाहरण के लिए जब सबडायरेक्टरीज में या फिर से लिखना।)

QSA

क्वेरी स्ट्रिंग परिशिष्ट ध्वज हमें अतिरिक्त चरों में निर्दिष्ट URL पर जाने की अनुमति देता है जो मूल प्राप्त मापदंडों में जोड़ा जाएगा। हमारे उदाहरण के लिए इसका मतलब है कि कुछ /blog/1/foo/?comments=15लोड होगा/blog/index.php?id=1&title=foo&comments=15

R

यह ध्वज वह नहीं है जिसका मैंने ऊपर उदाहरण में उपयोग किया है, लेकिन एक ऐसा है जो मैंने सोचा था कि उल्लेख के लायक है। यह आपको एक स्थिति कोड (जैसे R=301) को शामिल करने के विकल्प के साथ एक http पुनर्निर्देशित निर्दिष्ट करने की अनुमति देता है । उदाहरण के लिए यदि आप 301 / पर myblog / to / blog / करना चाहते हैं, तो आप इस तरह से एक नियम लिखेंगे:

RewriteRule ^/myblog/(*.)$ /blog/$1 [R=301,QSA,L]

पुन: स्थितियां

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

# if the host doesn't start with www. then add it and redirect
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

यह एक बहुत ही सामान्य अभ्यास है, जो आपके डोमेन को www.(अगर यह पहले से ही नहीं है) और 301 रीडायरेक्ट को निष्पादित करेगा। उदाहरण के लिए, http://example.com/blog/इसे लोड करना आपको अनुप्रेषित करेगाhttp://www.example.com/blog/

# if it cant find the image, try find the image on another domain
RewriteCond %{REQUEST_URI} \.(jpg|jpeg|gif|png)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*)$ http://www.example.com/$1 [L]

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

  • %{REQUEST_URI} \.(jpg|jpeg|gif|png)$ [NC] केवल jpg, jpeg, gif या png (केस असंवेदनशील) की फ़ाइल एक्सटेंशन वाली फ़ाइलों के लिए फिर से लिखना होगा।
  • %{REQUEST_FILENAME} !-f यह देखने के लिए जाँच करेगा कि क्या फ़ाइल वर्तमान सर्वर पर मौजूद है, और यदि यह नहीं है तो केवल फिर से निष्पादित करें
  • %{REQUEST_FILENAME} !-d यह देखने के लिए जाँच करेगा कि क्या फ़ाइल वर्तमान सर्वर पर मौजूद है, और यदि यह नहीं है तो केवल फिर से निष्पादित करें
  • फिर से लिखना उसी फाइल को दूसरे डोमेन पर लोड करने का प्रयास करेगा

39

संदर्भ

स्टैक ओवरफ्लो शुरू करने के लिए कई अन्य महान संसाधन हैं:

और नवागंतुक-अनुकूल रेगेक्स साक्षात्कार भी:

अक्सर उपयोग किए जाने वाले प्लेसहोल्डर

  • .*कुछ भी मेल खाता है, यहां तक ​​कि एक खाली स्ट्रिंग भी। आप हर जगह इस पैटर्न का उपयोग नहीं करना चाहते हैं, लेकिन अक्सर अंतिम कमबैक नियम में।
  • [^/]+अधिक बार पथ खंडों के लिए उपयोग किया जाता है। यह कुछ भी मेल खाता है लेकिन फॉरवर्ड स्लैश।
  • \d+ केवल संख्यात्मक स्ट्रिंग्स से मेल खाता है।
  • \w+अल्फ़ान्यूमेरिक वर्णों से मेल खाता है। यह मूल रूप से आशुलिपि है [A-Za-z0-9_]
  • [\w\-]+"स्लग" -स्टाइल पथ खंडों के लिए, अक्षरों, संख्याओं, डैश और का उपयोग करके- _
  • [\w\-.,]+अवधि और अल्पविराम जोड़ता है। चौराहों \-में एक बच गए डैश को […]प्राथमिकता दें।
  • \.एक शाब्दिक अवधि को दर्शाता है। अन्यथा किसी भी प्रतीक के लिए प्लेसहोल्डर .बाहर […]है।

इनमें से प्रत्येक प्लेसहोल्डर्स आमतौर पर (…)कैप्चर ग्रुप के रूप में कोष्ठक में लिपटे होते हैं । और पूरे पैटर्न अक्सर ^………$शुरू + अंत मार्करों में। "पैटर्न" उद्धृत करना वैकल्पिक है।

RewriteRules

निम्नलिखित उदाहरण PHP-केंद्रित और थोड़े अधिक वृद्धिशील हैं, समान मामलों के लिए अनुकूलित करना आसान है। वे सिर्फ सारांश हैं, अक्सर अधिक भिन्नता या विस्तृत प्रश्नोत्तर के लिंक।

  • स्थैतिक मानचित्रण
    /contact,/about

    आंतरिक फ़ाइल योजनाओं में कुछ पृष्ठ नामों को छोटा करना सबसे सरल है:

     RewriteRule ^contact$  templ/contact.html
     RewriteRule ^about$    about.php
    
  • सांख्यिक पहचानकर्ता
    /object/123

    http://example.com/article/531मौजूदा PHP स्क्रिप्ट की तरह शॉर्टकट पेश करना भी आसान है। संख्यात्मक प्लेसहोल्डर को केवल एक $_GETपैरामीटर पर रीमेक किया जा सकता है :

     RewriteRule ^article/(\d+)$    article-show.php?id=$1
     #                      └───────────────────────────┘
    
  • स्लग-शैली के प्लेसहोल्डर
    /article/with-some-title-slug

    आप /article/title-stringप्लेसहोल्डर्स के लिए अनुमति देने के लिए उस नियम को आसानी से बढ़ा सकते हैं :

     RewriteRule ^article/([\w-]+)$    article-show.php?title=$1
     #                       └────────────────────────────────┘
    

    ध्यान दें कि उन स्क्रिप्ट को डेटाबेस-आईडी में वापस करने के लिए आपकी स्क्रिप्ट सक्षम (या अनुकूलित) होनी चाहिए। अकेले रिवरट्रूल्स पतली हवा से बाहर की जानकारी नहीं बना सकते हैं या अनुमान नहीं लगा सकते हैं।

  • सांख्यिक उपसर्गों के साथ स्लग
    /readable/123-plus-title

    इसलिए आप /article/529-title-slugअभ्यास में अक्सर मिश्रित रास्तों को देखेंगे :

     RewriteRule ^article/(\d+)-([\w-]+)$    article.php?id=$1&title=$2
     #                      └───────────────────────────────┘
    

    अब आप किसी title=$2भी तरह से गुजरना छोड़ सकते हैं , क्योंकि आपकी स्क्रिप्ट आम तौर पर वैसे भी डेटाबेस-आईडी पर निर्भर करेगी। -title-slugऐच्छिक URL सजावट बन गया है।

  • वैकल्पिक सूचियों के साथ एकरूपता
    /foo/… /bar/… /baz/…

    यदि आपके पास कई वर्चुअल पेज पथों के लिए समान नियम हैं, तो आप उन्हें |वैकल्पिक सूचियों के साथ मेल और कॉम्पैक्ट कर सकते हैं । और फिर से उन्हें आंतरिक GET मापदंडों पर पुनः असाइन करें:

     #                               ┌─────────────────────────┐
     RewriteRule ^(blog|post|user)/(\w+)$  disp.php?type=$1&id=$2
     #               └───────────────────────────────────┘
    

    आप उन्हें अलग-अलग में विभाजित कर सकते हैं RewriteRuleयह बहुत जटिल होना चाहिए।

  • अलग-अलग बैकेंड से संबंधित URL भेजना
    /date/SWITCH/backend

    वैकल्पिक सूचियों का अधिक व्यावहारिक उपयोग अलग-अलग लिपियों के लिए अनुरोध पथों की मैपिंग कर रहा है। उदाहरण के लिए पुराने और नए वेब एप्लिकेशन के लिए समान URL प्रदान करने के लिए तारीखों के आधार पर:

     #                   ┌─────────────────────────────┐
     #                   │                 ┌───────────┼───────────────┐
     RewriteRule ^blog/(2009|2010|2011)/([\d-]+)/?$ old/blog.php?date=$2
     RewriteRule ^blog/(\d+)/([\d-]+)/?$  modern/blog/index.php?start=$2
     #                          └──────────────────────────────────────┘
    

    यह बस एक स्क्रिप्ट पर 2009-2011 के पदों को याद करता है, और अन्य सभी वर्षों में दूसरे हैंडलर के लिए निहित है। पहले आने वाले अधिक विशिष्ट नियम पर ध्यान दें । प्रत्येक स्क्रिप्ट अलग GET परम का उपयोग कर सकती है।

  • केवल /पथ स्लेश की तुलना में अन्य सीमांकक
    /user-123-name

    आप एक आभासी निर्देशिका संरचना का अनुकरण करने के लिए सबसे अधिक देख रहे हैं। लेकिन आप बिना सोचे समझे मजबूर न हों। आप -सेगमेंट या संरचना के लिए हाइफ़न का उपयोग कर सकते हैं ।

     RewriteRule ^user-(\d+)$    show.php?what=user&id=$1
     #                   └──────────────────────────────┘
     # This could use `(\w+)` alternatively for user names instead of ids.
    

    आम /wiki:section:Page_Nameयोजना के लिए भी :

     RewriteRule ^wiki:(\w+):(\w+)$  wiki.php?sect=$1&page=$2 
     #                   └─────┼────────────────────┘       │
     #                         └────────────────────────────┘
    

    कभी-कभी यह /-delimiters और :या .एक ही नियम में भी वैकल्पिक करने के लिए उपयुक्त है । या फिर अलग-अलग स्क्रिप्ट्स पर वेरिएंट्स को मैप करने के लिए फिर से दो रिवेरिट्यूल्स हैं।

  • वैकल्पिक अनुगामी /स्लैश
    /dir=/dir/

    जब निर्देशिका-शैली पथों के लिए चयन किया जाता है, तो आप इसे अंतिम के साथ और उसके बिना पहुंच योग्य बना सकते हैं /

     RewriteRule ^blog/([\w-]+)/?$  blog/show.php?id=$1
     #                         ┗┛
    

    अब इस हैंडल दोनों http://example.com/blog/123और /blog/123/। और /?$दृष्टिकोण किसी भी अन्य RewriteRule पर संलग्न करना आसान है।

  • आभासी रास्तों के लिए लचीले खंड
    .*/.*/.*/.*

    अधिकांश नियम आपको /…/व्यक्तिगत GET मापदंडों के लिए संसाधन पथ खंडों के विवश सेट का सामना करेंगे । कुछ लिपियाँ हालाँकि विकल्पों की एक परिवर्तनीय संख्या को संभालती हैं । Apache regexp इंजन उनमें से एक मनमानी संख्या को वैकल्पिक करने की अनुमति नहीं देता है। लेकिन आप इसे आसानी से एक नियम के रूप में विस्तारित कर सकते हैं:

     Rewriterule ^(\w+)/?$                in.php?a=$1
     Rewriterule ^(\w+)/(\w+)/?$          in.php?a=$1&b=$2
     Rewriterule ^(\w+)/(\w+)/(\w+)/?$    in.php?a=$1&b=$2&c=$3
     #              └─────┴─────┴───────────────────┴────┴────┘
    

    यदि आपको पाँच पथ खंडों की आवश्यकता है, तो इस योजना को पाँच नियमों में कॉपी करें। आप निश्चित रूप से [^/]+प्रत्येक अधिक विशिष्ट प्लेसहोल्डर का उपयोग कर सकते हैं। यहां ऑर्डर करना उतना महत्वपूर्ण नहीं है, जितना कि ओवरलैप करना। इसलिए सबसे पहले इस्तेमाल किए जाने वाले रास्ते ठीक हैं।

    वैकल्पिक रूप से आप PHP ?p[]=$1&p[]=$2&p[]=3स्ट्रिंग मापदंडों का उपयोग क्वेरी स्ट्रिंग के माध्यम से कर सकते हैं - यदि आपकी स्क्रिप्ट केवल उन्हें पूर्व-विभाजन पसंद करती है। (हालांकि यह केवल एक कैच-ऑल नियम का उपयोग करने के लिए अधिक सामान्य है, और स्क्रिप्ट को REQUEST__I से बाहर सेगमेंट का विस्तार करने दें।)

    यह भी देखें: मैं अपने URL पथ खंडों को क्वेरी स्ट्रिंग कुंजी-मूल्य जोड़े में कैसे बदलूं?

  • वैकल्पिक खंड
    prefix/opt?/.*

    एक सामान्य भिन्नता एक नियम के भीतर वैकल्पिक उपसर्ग है । यह आमतौर पर समझ में आता है कि आपके पास स्थैतिक स्ट्रिंग्स या अधिक विवश प्लेसहोल्डर हैं:

      RewriteRule ^(\w+)(?:/([^/]+))?/(\w+)$  ?main=$1&opt=$2&suffix=$3
    

    अब और अधिक जटिल पैटर्न (?:/([^/])+)?केवल एक गैर-कैप्चरिंग (?:…) समूह को लपेटता है , और इसे वैकल्पिक बनाता है )?। निहित प्लेसहोल्डर ([^/]+)प्रतिस्थापन पैटर्न होगा $2, लेकिन बीच का कोई /…/रास्ता नहीं होने पर खाली हो ।

  • शेष पर कब्जा
    /prefix/123-capture/…/*/…whatever…

    जैसा कि पहले कहा गया है, आप अक्सर बहुत सामान्य रीराइट पैटर्न नहीं चाहते हैं। हालांकि यह .*कभी-कभी स्थिर और विशिष्ट तुलनाओं को संयोजित करने के लिए समझ में आता है ।

     RewriteRule ^(specific)/prefix/(\d+)(/.*)?$  speci.php?id=$2&otherparams=$2
    

    इसने किसी भी /…/…/…अनुगामी पथ खंड को वैकल्पिक किया । जो तब निश्चित रूप से उन्हें अलग करने के लिए हैंडलिंग स्क्रिप्ट की आवश्यकता होती है, और स्वयं वैरबल-इफ्ती निकाले गए पैरामीटर (जो कि वेब- "एमवीसी" फ्रेमवर्क करते हैं)।

  • अनुगामी फ़ाइल "एक्सटेंशन"
    /old/path.HTML

    URL में वास्तव में फ़ाइल एक्सटेंशन नहीं हैं। यह संपूर्ण संदर्भ क्या है (= URL वर्चुअल लोकेटर हैं, जरूरी नहीं कि एक सीधी फाइल सिस्टम छवि हो)। हालाँकि यदि आपके पास पहले 1: 1 फ़ाइल मैपिंग थी, तो आप सरल नियमों को पूरा कर सकते हैं:

     RewriteRule  ^styles/([\w\.\-]+)\.css$  sass-cache.php?old_fn_base=$1
     RewriteRule  ^images/([\w\.\-]+)\.gif$  png-converter.php?load_from=$2
    

    अन्य सामान्य उपयोग .htmlनए .phpसंचालकों के लिए अप्रचलित पथों को हटा रहे हैं , या केवल व्यक्तिगत (वास्तविक / वास्तविक) फ़ाइलों के लिए केवल निर्देशिका नाम का उपनाम कर रहे हैं।

  • पिंग-पोंग (रीडायरेक्ट्स और पुनर्लेखन एक साथ)।
    /ugly.html/pretty

    तो कुछ बिंदु पर आप अपने HTML पृष्ठों को केवल सुंदर लिंक ले जाने के लिए फिर से लिख रहे हैं, जैसा कि छल द्वारा उल्लिखित है । इस बीच आप अभी भी पुराने रास्तों के लिए अनुरोध प्राप्त करेंगे , कभी-कभी बुकमार्क से भी। वर्कअराउंड के रूप में , आप नए URL प्रदर्शित / स्थापित करने के लिए पिंग-पोंग ब्राउज़र कर सकते हैं।

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

     # redirect browser for old/ugly incoming paths
     RewriteRule ^old/teams\.html$ /teams [R=301,QSA,END]
    
     # internally remap already-pretty incoming request
     RewriteRule ^teams$ teams.php        [QSA,END]
    

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

  • पैटर्न में रिक्त स्थान
    /this+that+

    यह ब्राउज़र पता बार में बहुत सुंदर नहीं है , लेकिन आप URL में रिक्त स्थान का उपयोग कर सकते हैं। फिर से लिखना पैटर्न के लिए बैकस्लैश-एस्कैप्ड \␣रिक्त स्थान का उपयोग करें । केवल "पूरे पैटर्न या प्रतिस्थापन का चयन करें:

     RewriteRule  "^this [\w ]+/(.*)$"  "index.php?id=$1"  [L]
    

    ग्राहक URL के साथ +या %20रिक्त स्थान के लिए क्रमबद्ध करते हैं। फिर भी रिवरराइट्स में वे सभी रिश्तेदार पथ खंडों के लिए शाब्दिक वर्णों के साथ व्याख्या करते हैं।

बार-बार डुप्लिकेट:

प्रचलित .htaccessदोष

अब इसे नमक के दाने के साथ लें। हर सलाह को सभी संदर्भों के लिए सामान्यीकृत नहीं किया जा सकता है। यह प्रसिद्ध और कुछ नायाब ठोकर का एक सरल सारांश है:

  • सक्षम करें mod_rewriteऔर.htaccess

    वास्तव में प्रति-निर्देशिका कॉन्फ़िगरेशन फ़ाइलों में आपको ReriteRules का उपयोग करना चाहिए:

    • जांचें कि आपका सर्वर AllowOverride Allसक्षम है । अन्यथा आपकी प्रति-डायरेक्ट्री .htaccessनिर्देशों को अनदेखा कर दिया जाएगा, और RewriteRules काम नहीं करेगा।

    • जाहिर है mod_rewriteसक्षम अपने में httpd.confमॉड्यूल अनुभाग।

    • RewriteEngine Onअभी भी नियमों की प्रत्येक सूची तैयार करें । जबकि mod_rewrite अंतर्निहित <VirtualHost>और <Directory>अनुभागों में सक्रिय रूप से सक्रिय है , प्रति-निर्देशिका .htaccessफ़ाइलों को व्यक्तिगत रूप से तलब करने की आवश्यकता होती है।

  • अग्रणी स्लैश ^/का मिलान नहीं होगा

    आपको सामान्य रूप से अपना .htaccessरीवेरिएट पैटर्न शुरू नहीं करना चाहिए ^/:

     RewriteRule ^/article/\d+$  …
                  ↑
    

    यह अक्सर पुराने ट्यूटोरियल में देखा जाता है। और यह प्राचीन Apache 1.x संस्करणों के लिए सही हुआ करता था। आजकल अनुरोध पथ आसानी से कर रहे हैं पूरी तरह से निर्देशिका-सापेक्ष में .htaccessRewriteRules। बस अग्रणी को छोड़ दें /

    · ध्यान दें कि प्रमुख स्लैश अभी भी <VirtualHost>वर्गों में सही है । यही कारण है कि आप अक्सर इसे ^/?नियम समता के लिए वैकल्पिक रूप से देखते हैं ।
    · या जब एक का उपयोग कर RewriteCond %{REQUEST_URI}आप अभी भी एक प्रमुख मेल था /Webmaster.SE
    भी देखें : mod_rewrite पैटर्न में प्रमुख स्लैश (/) की आवश्यकता कब होती है?

  • <IfModule *> रैपर भिखारी!

    आपने शायद इसे कई उदाहरणों में देखा है:

    <IfModule mod_rewrite.c>
       Rewrite… 
    </IfModule>
    
    • यह करता है में बना भावना <VirtualHost>वर्गों - अगर यह इस तरह के ScriptAliasMatch के रूप में एक और वापस आने विकल्प, के साथ संयुक्त किया गया था। (लेकिन कभी कोई ऐसा नहीं करता)।
    • और यह आमतौर पर .htaccessकई खुले स्रोत परियोजनाओं के साथ डिफ़ॉल्ट नियमों के लिए वितरित किया जाता है । वहाँ इसका मतलब केवल कमबैक है, और "बदसूरत" URL डिफ़ॉल्ट रूप से काम करता है।

    हालाँकि आप नहीं चाहते हैं कि आमतौर पर आपकी अपनी .htaccessफ़ाइलों में।

    • सबसे पहले, mod_rewrite बेतरतीब ढंग से विघटन नहीं करता है। (अगर यह किया, तो आपको बड़ी समस्याएं होंगी)।
    • क्या यह वास्तव में अक्षम थे, आपके RewriteRules अभी भी वैसे भी काम नहीं करेंगे।
    • यह HTTP 500त्रुटियों को रोकने के लिए है । यह आमतौर पर जो पूरा करता है वह आपके उपयोगकर्ताओं को HTTP 404त्रुटियों के बजाय ग्रेड कर रहा है । ( यदि आप इसके बारे में सोचते हैं तो इतना अधिक उपयोगकर्ता के अनुकूल नहीं है।)
    • व्यावहारिक रूप से यह सिर्फ अधिक उपयोगी लॉग प्रविष्टियों, या सर्वर अधिसूचना मेल को दबाता है। आप कोई भी समझदार नहीं होंगे कि आपके रिवेट्रूल्स कभी काम क्यों नहीं करते हैं।

    सामान्यीकृत रक्षोपाय के रूप में जो मोहक लगता है, वह अक्सर व्यवहार में एक बाधा बन जाता है।

  • RewriteBaseजब तक उपयोग न करें

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

    यह गहरी उपनिर्देशिकाओं में व्यक्तिगत वेब अनुप्रयोगों के साथ उपयोग करने के लिए समझ में आता है। यह इस तरह के मामलों में रेवेरिएट पैटर्न को छोटा कर सकता है। आम तौर पर प्रति-निर्देशिका नियम सेट में सापेक्ष पथ विनिर्देशक को प्राथमिकता देना सबसे अच्छा है।

    यह भी देखें कि रीवाइटबेस कैसे काम करता है

  • MultiViewsवर्चुअल पथ ओवरलैप होने पर अक्षम करें

    URL पुनर्लेखन मुख्य रूप से आभासी आने वाले रास्तों का समर्थन करने के लिए उपयोग किया जाता है। आमतौर पर आप केवल एक डिस्पैचर लिपि (है index.php) या कुछ व्यक्तिगत संचालकों ( articles.php, blog.php, wiki.php, ...)। बाद हो सकता है टकराव समान आभासी RewriteRule रास्तों के साथ।

    /article/123उदाहरण के लिए एक अनुरोध article.phpएक /123PATH_INFO के साथ मैप कर सकता है । आप या तो साथ आम फिर अपने नियमों की रक्षा के लिए होगा RewriteCond !-f+ !-d, और / या अक्षम PATH_INFO समर्थन, या शायद सिर्फ अक्षम Options -MultiViews

    जो कहने के लिए नहीं है कि आपको हमेशा करना है । सामग्री-बातचीत केवल आभासी संसाधनों के लिए एक स्वचालितता है।

  • आदेश देना महत्वपूर्ण है

    देखें सब कुछ आप कभी भी mod_rewrite के बारे में जानना चाहता था अगर आप पहले से ही नहीं है। मल्टीपल रिवाइटरट्रूल्स को मिलाकर अक्सर इंटरेक्शन होता है। यह आदतन रूप से प्रति [L]ध्वज को रोकने के लिए कुछ नहीं है , लेकिन एक योजना जिसे आप एक बार पार कर लेंगे। आप कर सकते हैं फिर से फिर से फिर से लिखना एक नियम से आभासी पथ दूसरे करने के लिए, जब तक यह एक वास्तविक लक्ष्य हैंडलर तक पहुँचता है।

    फिर भी आप अक्सर शुरुआती नियमों में सबसे विशिष्ट नियम (निश्चित स्ट्रिंग /forum/…पैटर्न, या अधिक प्रतिबंधक प्लेसहोल्डर [^/.]+) चाहते हैं। जेनेरिक स्लप-सभी नियम ( ) बाद के लोगों के लिए बेहतर हैं। (एक अपवाद प्राथमिक ब्लॉक के रूप में एक गार्ड है।).*RewriteCond -f/-d

  • शैलियाँ और चित्र काम करना बंद कर देते हैं

    जब आप वर्चुअल निर्देशिका संरचना का परिचय देते हैं तो /blog/article/123यह HTML (जैसे <img src=mouse.png>) में सापेक्ष संसाधन संदर्भों को प्रभावित करता है । जिसे हल किया जा सकता है:

    • केवल सर्वर-निरपेक्ष संदर्भ href="https://stackoverflow.com/old.html"या का उपयोग करsrc="/logo.png"
    • अक्सर <base href="https://stackoverflow.com/index">अपने HTML <head>अनुभाग में जोड़कर । यह स्पष्ट रूप से उन संदर्भों को संदर्भित करता है जो वे पहले थे।

    आप वैकल्पिक रूप से अपने मूल स्थानों को रिवाइंड .cssया .pngपथ करने के लिए रिवरराइट्स को आगे शिल्प कर सकते हैं । लेकिन यह दोनों अनावश्यक है, या अतिरिक्त रीडायरेक्ट और हैम्पर्स कैचिंग को जन्म देता है।

    इसे भी देखें: सीएसएस, जेएस और छवियां सुंदर यूआरएल के साथ प्रदर्शित नहीं होती हैं

  • RewriteConds सिर्फ एक RewriteRule का मुखौटा लगाता है

    एक आम गलतफहमी यह है कि एक RewriteCond कई RewriteRules ब्लॉक करता है (क्योंकि वे नेत्रहीन एक साथ व्यवस्थित होते हैं):

     RewriteCond %{SERVER_NAME} localhost
     RewriteRule ^secret  admin/tools.php
     RewriteRule ^hidden  sqladmin.cgi
    

    यह प्रति डिफ़ॉल्ट नहीं है। आप झंडे का उपयोग करके उन्हें चेन कर सकते हैं [S=2]। और आपको उन्हें दोहराना होगा। जबकि कभी-कभी आप एक "उल्टे" प्राथमिक नियम को [END] को फिर से लिखने की प्रक्रिया को जल्द से जल्द तैयार कर सकते हैं।

  • QUERY_STRING को RewriteRules से छूट मिली

    आप मिलान नहीं कर सकते RewriteRule index.php\?x=y, क्योंकि mod_rewrite की तुलना प्रति डिफ़ॉल्ट सापेक्ष पथ से की जाती है। आप उन्हें अलग से मिलान कर सकते हैं:

     RewriteCond %{QUERY_STRING} \b(?:param)=([^&]+)(?:&|$)
     RewriteRule ^add/(.+)$  add/%1/$1  # ←──﹪₁──┘
    

    यह भी देखें कि मैं mod_rewrite के साथ क्वेरी स्ट्रिंग चर कैसे मेल कर सकता हूं?

  • .htaccess बनाम <VirtualHost>

    यदि आप प्रति-डायरेक्टरी कॉन्फ़िगर फ़ाइल में RewriteRules का उपयोग कर रहे हैं, तो regex प्रदर्शन के बारे में चिंता करना व्यर्थ है। Apache एक सामान्य रूटिंग फ्रेमवर्क के साथ PHP प्रक्रिया की तुलना में लंबे समय तक संकलित PCRE पैटर्न रखता है। एक बार युद्ध-परीक्षण हो जाने के बाद, उच्च-ट्रैफ़िक साइटों के लिए, आपको vhost सर्वर कॉन्फ़िगरेशन में चलते हुए नियमों पर विचार करना चाहिए।

    इस स्थिति में, वैकल्पिक ^/?निर्देशिका विभाजक उपसर्ग को प्राथमिकता दें । यह PerDir और सर्वर कॉन्फिग फाइलों के बीच फ्री में RewriteRules को स्थानांतरित करने की अनुमति देता है।

  • जब भी कुछ काम नहीं करता है

    खीजो नहीं।

    • तुलना access.logऔरerror.log

      अक्सर आप यह पता लगा सकते हैं कि कैसे एक रिवेरिट्यूल आपके error.logऔर को देखने से दुर्व्यवहार करता है access.log। यह देखने के लिए कि कौन सा अनुरोध पथ मूल रूप से आया है, और कौन सा पथ / फ़ाइल अपाचे (404/500 त्रुटि) को हल नहीं कर सका, सहसंबंधी पहुंच समय।

      यह आपको नहीं बताता है कि कौन सा रेवराट्यूल अपराधी है। लेकिन दुर्गम अंतिम रास्तों की तरह /docroot/21-.itle?index.phpआगे का निरीक्षण करने के लिए दूर दे सकते हैं। अन्यथा नियमों को अक्षम करें जब तक कि आपको कुछ अनुमानित पथ न मिलें।

    • RewriteLog सक्षम करें

      Apache RewriteLog डॉक्स देखें । डिबगिंग के लिए आप इसे vhost वर्गों में सक्षम कर सकते हैं:

      # Apache 2.2
      RewriteLogLevel 5
      RewriteLog /tmp/rewrite.log
      
      # Apache 2.4
      LogLevel alert rewrite:trace5
      #ErrorLog /tmp/rewrite.log
      

      प्रत्येक नियम से आने वाले अनुरोध पथ को कैसे संशोधित किया जाए, इसका एक विस्तृत सारांश देता है:

      [..] applying pattern '^test_.*$' to uri 'index.php'
      [..] strip per-dir prefix: /srv/www/vhosts/hc-profi/index.php -> index.php
      [..] applying pattern '^index\.php$' to uri 'index.php'
      

      जो पीढ़ी के सामान्य नियमों और रेगेक्स मिसैपेस को कम करने में मदद करता है।

      इन्हें भी देखें:
      · .htaccess काम नहीं कर रही है (mod_rewrite)
      · डिबगिंग के लिए टिप्स ।htaccess rewrite rules

    • अपना सवाल पूछने से पहले

      जैसा कि आप जानते होंगे कि mod_rewrite पर सवाल पूछने के लिए Stack Overflow बहुत उपयुक्त है। पूर्व अनुसंधान और प्रयासों (अनावश्यक जवाबों से बचें) को शामिल करके उन्हें विषय पर बनाएं , बुनियादी प्रदर्शित करें समझ, और:

      • इनपुट URL के पूर्ण उदाहरणों को शामिल करें, लक्ष्य मार्ग को फिर से लिखें, आपकी वास्तविक निर्देशिका संरचना।
      • पूरा रिवरराइट सेट, लेकिन प्रकल्पित दोषपूर्ण को भी एकल कर दिया।
      • $_SERVERयदि यह एक पैरामीटर बेमेल के बारे में है तो Apache और PHP संस्करण, OS प्रकार, फाइल सिस्टम, DOCUMENT_ROOT, और PHP वातावरण।
      • आपके access.logऔर error.logमौजूदा नियमों का समाधान करने के लिए एक अंश का सत्यापन। बेहतर अभी तक, एक rewrite.logसारांश।

      यह जल्दी और अधिक सटीक उत्तर देता है, और उन्हें दूसरों के लिए अधिक उपयोगी बनाता है।

  • अपनी टिप्पणी दें .htaccess

    यदि आप कहीं से उदाहरणों की नकल करते हैं, तो एक को शामिल करने का ध्यान रखें # comment and origin link। हालांकि यह केवल अशिष्टता को छोड़ने के लिए खराब शिष्टाचार है, यह अक्सर बाद में रखरखाव को नुकसान पहुंचाता है। किसी भी कोड या ट्यूटोरियल स्रोत का दस्तावेज़। विशेष रूप से, जबकि एकतरफा आपको जादू ब्लैकबॉक्स की तरह व्यवहार नहीं करना चाहिए।

  • यह "SEO" -URL नहीं है

    डिस्क्लेमर: बस एक पालतू जानवर का पेशाब। आपने अक्सर सुंदर URL पुनर्लेखन योजनाएं "एसईओ" लिंक या कुछ और के रूप में संदर्भित की हैं। जबकि यह गुगली के उदाहरण के लिए उपयोगी है, यह एक दिनांकित मिथ्या नाम है।

    आधुनिक खोज इंजनों में से कोई भी वास्तव में .htmlऔर .phpपथ खंडों में परेशान नहीं है , या ?id=123उस मामले के लिए क्वेरी तार। इस तरह के अल्ताविस्ता के रूप में वर्ष के खोज इंजन, किया था संभावित ambigious पहुंच पथ के साथ वेबसाइटों को क्रॉल से बचने के। आधुनिक क्रॉलर अक्सर गहरे वेब संसाधनों के लिए तरस रहे हैं।

    "सुंदर" URL को वैचारिक रूप से उपयोग किया जाना चाहिए जो वेबसाइटों को उपयोगकर्ता के अनुकूल बना रहा है

    1. पठनीय और स्पष्ट संसाधन योजनाएँ होना।
    2. सुनिश्चित करने वाले URL लंबे समय तक जीवित रहते हैं (AKA permalinks )।
    3. के माध्यम से खोजनीयता प्रदान करना /common/tree/nesting

    हालांकि अनुरूपता के लिए अद्वितीय आवश्यकताओं का त्याग नहीं करते।

उपकरण

अधिकांश GET- पैरामीटर URL के लिए RewriteRules उत्पन्न करने के लिए विभिन्न ऑनलाइन टूल हैं:

ज्यादातर सिर्फ [^/]+सामान्य प्लेसहोल्डर्स आउटपुट , लेकिन संभावना तुच्छ साइटों के लिए पर्याप्त है।


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

3
लंबे समय तक एक उत्तर की ऐसी सुंदरता नहीं देखी! इसे पढ़ते हुए मेरी आँखें चमक रही हैं। कृपया ऐसे उत्तर पोस्ट करना बंद न करें :)
Rizier123

1
बहुत बढ़िया पोस्ट। मुझे mod_rewrite की मूल अवधारणाओं को बहुत जल्दी समझ में आया!
बृज

6

Mod_rewrite के लिए विकल्प

कई बुनियादी आभासी URL योजनाएँ बिना ReriteRules का उपयोग किए हासिल की जा सकती हैं। Apache PHP स्क्रिप्ट को बिना .phpएक्सटेंशन के, और एक आभासी PATH_INFOतर्क के साथ लागू करने की अनुमति देता है।

  1. PATH_INFO , ल्यूक का उपयोग करें

    आजकल AcceptPathInfo Onअक्सर डिफ़ॉल्ट रूप से सक्षम है। जो मूल रूप से .phpवर्चुअल तर्क रखने के लिए अन्य संसाधन URL की अनुमति देता है:

    http://example.com/script.php/virtual/path
    

    अब यह /virtual/pathPHP में दिखाता है $_SERVER["PATH_INFO"]जहाँ आप अपनी पसंद के किसी भी अतिरिक्त तर्क को संभाल सकते हैं।

    इस में अपाचे अलग इनपुट पथ के सेगमेंट होने के रूप में के रूप में सुविधाजनक नहीं है $1, $2, $3और उन्हें अलग रूप में गुजर $_GETपीएचपी करने के लिए चर। यह केवल कम विन्यास प्रयास के साथ "सुंदर यूआरएल" का अनुकरण कर रहा है।

  2. एक्सटेंशन को छिपाने के लिए MultiViews सक्षम करें.php

    .phpURL में "फ़ाइल एक्सटेंशन" को एचीव करने का सबसे सरल विकल्प सक्षम है:

    Options +MultiViews
    

    यह मिलान बेसन के कारण article.phpHTTP अनुरोधों के लिए अपाचे का चयन करता है /article। और यह पूर्वोक्त PATH_INFO सुविधा के साथ अच्छी तरह से काम करता है। तो आप जैसे URL का उपयोग कर सकते हैं http://example.com/article/virtual/title। जो समझ में आता है यदि आपके पास कई PHP आह्वान बिंदुओं / लिपियों के साथ एक पारंपरिक वेब अनुप्रयोग है।

    ध्यान दें कि हालांकि MultiViews का एक अलग / व्यापक उद्देश्य है। यह एक बहुत ही मामूली प्रदर्शन दंड देता है, क्योंकि अपाचे हमेशा मैचिंग बेसनेम वाली अन्य फाइलों की तलाश करता है। यह वास्तव में के लिए है सामग्री-निगोसिएशन , तो ब्राउज़रों (जैसे उपलब्ध संसाधनों के बीच सबसे अच्छा विकल्प प्राप्त article.en.php, article.fr.php, article.jp.mp4)।

  3. विस्तार .phpस्क्रिप्ट्स के लिए SetType या SetHandler

    .phpURL में प्रत्ययों को ले जाने से बचने के लिए अधिक निर्देशित दृष्टिकोण अन्य फ़ाइल योजनाओं के लिए PHP हैंडलर को कॉन्फ़िगर कर रहा है । सबसे सरल विकल्प डिफ़ॉल्ट MIME / हैंडलर प्रकार को ओवरराइड कर रहा है .htaccess:

    DefaultType application/x-httpd-php
    

    इस तरह से आप अपनी article.phpस्क्रिप्ट को सिर्फ article(बिना विस्तार के) नाम बदल सकते हैं , लेकिन फिर भी इसे PHP स्क्रिप्ट के रूप में संसाधित किया जाता है।

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

    <Files article>
      SetHandler application/x-httpd-php
      # or SetType 
    </Files>
    

    यह कुछ हद तक आपके सर्वर सेटअप और प्रयुक्त PHP SAPI पर निर्भर है। आम विकल्पों में शामिल हैं ForceType application/x-httpd-phpया AddHandler php5-script

    फिर से ध्यान दें कि ऐसी सेटिंग्स एक .htaccessसे सबफ़ोल्डर्स में फैलती हैं । आपको हमेशा स्थैतिक संसाधनों के लिए स्क्रिप्ट निष्पादन ( SetHandler Noneऔर Options -Execया php_flag engine offआदि) को अक्षम करना चाहिए , और अपलोड / निर्देशिका आदि करना चाहिए।

  4. अन्य अपाचे पुनर्लेखन योजनाएं

    इसके कई विकल्पों में से, अपाचे ने mod_aliasसुविधाएँ प्रदान की हैं - जो कभी-कभी सिर्फ mod_rewriteरीराइट्रूल्स के रूप में भी काम करती हैं । ध्यान दें कि उनमें से अधिकांश को एक <VirtualHost>सेगमेंट में सेट किया जाना चाहिए , न कि प्रति-डायरेक्टरी .htaccessकॉन्फिग फाइलों में।

    • ScriptAliasMatchमुख्य रूप से CGI लिपियों के लिए है, लेकिन PHP के लिए भी काम करना चाहिए। यह किसी भी तरह regexps की अनुमति देता है RewriteRule। वास्तव में यह शायद सबसे मजबूत विकल्प है जो कैच-ऑल फ्रंट कंट्रोलर को कॉन्फ़िगर करता है।

    • और एक सादा Aliasकुछ सरल पुनर्लेखन योजनाओं के साथ भी मदद करता है।

    • यहां तक ​​कि एक सादे ErrorDocumentनिर्देश का इस्तेमाल PHP स्क्रिप्ट को आभासी रास्तों को संभालने के लिए किया जा सकता है। ध्यान दें कि यह एक कठिन काम है, लेकिन कुछ भी प्राप्त करने पर प्रतिबंध लगाता है, और त्रुटि को रोक देता है। परिभाषा के अनुसार।

    आगे की टिप्स के लिए http://httpd.apache.org/docs/2.2/urlmapping.html देखें ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.