Django的URL路由基礎

隨便新建個django專案，缺省會自動建立乙個/project_name/urls.py檔案，並自動包含一些內容，這就是專案的根url。

如果要自己編寫url路由，基本也是這個套路。

當使用者請求乙個頁面時，django根據下面的邏輯執行操作：

1、決定要使用的根urlconf模組。通俗地講，就是你可以自定義專案入口url是哪個檔案！

2、載入該模組並尋找可用的urlpatterns。它是django.urls.path()或django.urls.re_path()例項的乙個列表。

3、依次匹配每個url模式，在與請求的url相匹配的第乙個模式停下來。也就是說，url匹配是從上往下的短路操作，所以url在列表中的位置非常關鍵。

4、匯入並呼叫匹配行中給定的檢視，該檢視是乙個簡單地python函式，或基於類的檢視。檢視將獲得如下引數：

（1）.乙個httprequest例項

（2）.如果匹配的表示式返回了未命名的組，那麼匹配的內容將作為位置引數提供給檢視。

（3）.關鍵字引數由表示式匹配的命名組組成，但是可以被django.urls.path()的可選引數kwargs覆蓋。

（4）.若沒有匹配到任何表示式，或者過程中丟擲異常，將呼叫乙個適當的錯誤處理檢視。

注：1.要捕獲一段url中的值，需要使用尖括號，而不是圓括號；

2.可以轉換捕獲到的值為指定型別，例如例子中的int。預設情況下，捕獲到的結果儲存為字串型別，不包含/這個特殊字元；

3.匹配模式的最開頭不需要新增/，因為預設情況下，每個url都帶乙個最前面的/，既然是都有的部分，就不用特別寫乙個了。

每當urls.py檔案被第一次載入的時候，urlpatterns裡的表示式們都將被預先編譯，這會大大提高系統處理路由的速度。

預設情況下，django內建下面的路徑轉換器：

·str：匹配任何非空字串，但不含/，如果沒有專門指定轉換器，那麼這個是預設使用的。

·int：匹配0和正整數，返回乙個int型別。

·path：匹配任何非空字串，重點是可以包含路徑分隔符『/』。這個轉換器可以幫助匹配整個url而不是一段一段的url字串。（要區分path轉換器和path()方法）。

·uuid：匹配乙個uuid格式的物件。為了防止衝突，規定必須使用破折號，所有字母必須小寫。返回乙個uuid物件。

·slug：可理解為注釋、字尾、附屬等概念，是url拖在最後的一部分解釋性字元。該轉換器匹配任何ascii字元以及連線符和下劃線。

django2.0之後的url雖然改配置了，但它依然向老版本相容。而這個相容的辦法，就是用re_path()方法代替path()方法。

與path()方法不同的在於兩點：

·re_path()由於是用正則進行匹配的，則只能匹配到正則指定的長度或規則。

·傳遞給檢視的所有引數都是字串型別。而不像path()方法可以指定轉換成某種型別。在檢視中接收引數時一定要小心。

請求的url被看做是乙個普通的python字串，urlconf在其上查詢並匹配。進行匹配時將不包括get或post請求方式的引數以及網域名稱。

urlconf不檢查使用何種http請求方法，所有請求方法post、get、head等都將路由到同乙個url的同乙個檢視。在檢視中，才根據具體請求方法的不同，進行不同的處理。

有乙個小技巧，我們可以指定檢視引數的預設值。下面是乙個urlconf和檢視的示例：

在上面的例子中，兩個url模式指向同乙個檢視。但是第乙個模式不會從url中捕獲任何值。如果第乙個模式匹配，page()函式將使用num引數的預設值「1」。如果第二個模式匹配，page()將使用捕獲的num值。

當django找不到與請求匹配的url時，或者當丟擲乙個異常時，將呼叫乙個錯誤處理檢視。django預設的自帶的錯誤檢視包括400、403、404和500，分別表示請求錯誤、拒絕服務、頁面不存在和伺服器錯誤。它們分別位於：

·handler400 —— django.conf.urls.handler400。

·handler403 —— django.conf.urls.handler403。

·handler404 —— django.conf.urls.handler404。

·handler500 —— django.conf.urls.handler500。

django有內建的html模板，用於返回錯誤頁面給使用者，但是這些頁面實在醜陋，通常都自定義錯誤頁面。

首先，在根urlconf中額外增加下面的條目，並匯入views模組：

再根據自己的需求，建立對應的400、403、404、500.html四個頁面檔案，就可以了（要注意好模板檔案的引用方式，檢視的放置位置等等）。