Django 遵從 MVC 模型，並將其特色化為 MTV 模型。模型的核心是通過用戶訪問的 url 來指向處理的函數，而函數處理後返回相應的結果。所以url決定了用戶訪問的入口，另外表單處理的提交地址也需要指定的url。url是所有功能的入口，所以url的編寫就變得非常重要。 Django 的 ur ...
Django 遵從 MVC 模型，並將其特色化為 MTV 模型。模型的核心是通過用戶訪問的 url 來指向處理的函數，而函數處理後返回相應的結果。所以url決定了用戶訪問的入口，另外表單處理的提交地址也需要指定的url。url是所有功能的入口，所以url的編寫就變得非常重要。
Django 的 url 編寫涉及了 python 的 re 模塊，也就是正則表達式，這部分內容需要提前掌握。
本篇的內容將結合官方的1.8.2的文檔進行說明，如果有說明不清的地方可以相應參照官方的文檔，我這裡提供一個進行中文翻譯後的：戳這裡
在進行編寫的說明前，我先介紹一下django是如何處理一個請求的：
1.用戶發來一個請求。Django將用戶的請求報文等信息封裝成HttpRequest對象，然後經過各種中間件處理後，抵達 url 模塊進行處理函數的選擇。
2.Django要決定使用哪個模塊用作匹配，這個通常由 settings.py 中的 ROOT_URLCONF 的值決定，例如：ROOT_URLCONF = 'test_web.urls' 。就表示將使用 test_web（項目同名app） 這個 app 下的 urls 這個模塊文件( 這個模塊也稱為url的根模塊，可修改 )。但如果進來的HttpRequest對象具有一個 urlconf 屬性（通過中間件 request processing 設置），則使用這個值來替換 ROOT_URLCONF 設置。（可能會存在版本差異）
3.Django 載入該 Python 模塊並尋找可用的 urlpatterns 變數。它是一個 Python 列表，裡面的元素是 django.conf.urls.url() 的實例。
4.Django 按照正則匹配的方式，依次匹配每個URL 模式，在第一個與請求的URL 匹配的地方停下來(下麵也符合的會被忽視)。
5.一旦其中的一個正則表達式匹配上，Django 將導入並調用給出的視圖，它是一個簡單的Python 函數（或者一個基於類的視圖）。視圖將獲得如下參數:
a) 一個HttpRequest 實例（這也是為什麼 view 函數的第一個參數要是 request，該實例封裝了所有的 http 請求報文的信息）
b) 如果正則匹配的 url 中使用了括弧分組，但卻沒有為分組進行命名，則使用位置參數的模式為view函數傳參。
c) 如果是命名的分組，則使用關鍵字傳參的方式。但是可以被django.conf.urls.url()的可選參數kwargs覆蓋。
6.如果沒有匹配到正則表達式，或者如果過程中拋出一個異常，Django 將調用一個適當的錯誤處理視圖。
7.函數處理完畢，返回處理後的結果。
官方手冊的例子：
from django.conf.urls import url from . import views urlpatterns = [ url(r'^articles/2003/$', views.special_case_2003), url(r'^articles/([0-9]{4})/$', views.year_archive), url(r'^articles/([0-9]{4})/([0-9]{2})/$', views.month_archive), url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.article_detail), ]
分析：
1.若要從 URL 中捕獲一個值，只需要在它周圍放置一對圓括弧。（即正則中的分組匹配）
2.不需要添加一個前導的反斜杠，因為每個URL 都有。例如，應該是^articles 而不是 ^/articles。(django自動在功能變數名稱後添加了/,這個預設行為可以進行改寫)
3.每個正則表達式前面的'r' 是可選的但是建議加上。它告訴Python 這個字元串是“原始的” —— 字元串中任何字元都不應該轉義。參見Dive Into Python 中的解釋。
一些請求的例子：
/articles/2005/03/ 請求將匹配列表中的第三個模式。Django 將調用函數views.month_archive(request, '2005', '03')。
/articles/2005/3/ 不匹配任何URL 模式，因為列表中的第三個模式要求月份應該是兩個數字。
/articles/2003/ 將匹配列表中的第一個模式不是第二個，因為模式按順序匹配，第一個會首先測試是否匹配。請像這樣自由插入一些特殊的情況來探測匹配的次序。
/articles/2003 不匹配任何一個模式，因為每個模式要求URL 以一個斜線結尾。
/articles/2003/03/03/ 將匹配最後一個模式。Django 將調用函數views.article_detail(request, '2003', '03', '03')。
命名組
上面的例子中，雖然實現了參數的傳遞，但是並沒有我們熟知的關鍵字傳參。要使用關鍵字傳參，只有為分組命名就行了。例如：(?P<name>\d+),這個分組表示匹配一個或多個任意的數字，並以 name = 匹配到的數字，如 name = '123' 的方式傳給view 函數。
但是，要註意一點，url 捕獲的所以參數都是字元串類型，雖然 \d 在正則中表示匹配數字，但傳參的時候，傳的是字元串。例如，正則捕獲的 123 ，但傳參是 '123'。
官方例子
from django.conf.urls import url from . import views urlpatterns = [ url(r'^articles/2003/$', views.special_case_2003), url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive), url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive), url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.article_detail),
]
分析：
/articles/2005/03/ 請求將調用views.month_archive(request, year='2005', month='03')函數，而不是views.month_archive(request, '2005', '03')。
/articles/2003/03/03/ 請求將調用函數views.article_detail(request, year='2003', month='03', day='03')。
匹配/分組演算法
下麵是URLconf 解析器使用的演算法，針對正則表達式中的命名組和非命名組：
1.如果有命名參數，則使用這些命名參數，忽略非命名參數。
2.否則，它將以位置參數傳遞所有的非命名參數。
根據傳遞額外的選項給視圖函數（下文），這兩種情況下，多餘的關鍵字參數也將傳遞給視圖。
註意：
1.一條 url 中，分組不能同名，否則報錯。（初步測試）
2.所謂的有命名分組就使用命名參數，忽略非命名參數是下麵這樣的：
url(r'add/(\d+)/(?P<num1>\d+)/(?P<num2>\d+)/', add, name='add'),
def add(request, num1, num2): num1 = int(num1) num2 = int(num2) return HttpResponse(num1 + num2)
在這裡，request 是 Httprequest，是 django 自動傳遞的，我們只要看 num1 和 num2 兩個參數就可以的。這裡我的處理函數除了 request 之外還需要 2 個參數，但是我在 url 中使用了三個分組，理論上應該會捕獲 3 個參數。
但是，當我訪問 http://127.0.0.1:8000/add/666/321/123/ 時，我得到的結果是：
另外，因為捕獲的參數是字元串類型， 所以我使用了 int() 函數進行類型轉換，如果不這樣的話：
def add(request, num1, num2): return HttpResponse(num1 + num2)
得到的結果就是：
字元串的拼接，所以說，捕獲的參數都是字元串。
好了，回到正題。我的函數需要除了 request 之外的 2 個參數，但是我在 url 中捕獲了三個，得到的結果是後面的兩個命名組的參數，也就是多出來的被忽略了。
這就是所謂的當命名組存在的時候，非命名組會被忽略。
但是，我的 url 是這樣寫的：
url(r'add/(\d+)/(?P<num2>\d+)/', add, name='add'),
我希望前面的未命名組按位置傳給 num1 而 num2 使用關鍵字參數。
現在，我訪問： http://127.0.0.1:8000/add/321/123/
報錯的信息是，函數需要 3 個參數，而我們給了 2 個，其中，去除自動傳遞的 request，也就是我們只捕獲到了 1 個參數。
此時，再看看這句活：當命名組存在時，會忽略非命名組。
因為非命名組捕獲的參數被忽略了，所以才導致我們少傳了一個參數。
這個時候，你應該知道這裡的忽略是什麼意思了吧。
URLconf 在什麼上查找
請求的URL被看做是一個普通的Python 字元串， URLconf在其上查找並匹配。進行匹配時將不包括GET或POST請求方式的參數以及功能變數名稱。
例如，http://www.example.com/myapp/請求中，URLconf 將查找myapp/。
在http://www.example.com/myapp/?page=3 請求中，URLconf 仍將查找myapp/。
URLconf 不檢查使用了哪種請求方法。換句話講，所有的請求方法 —— 即，對同一個URL的無論是POST請求、GET請求、或HEAD請求方法等等 —— 都將匹配到相同的函數。
但是，我們能限制某個函數只能由某種方式訪問，但這裡不是 url 這裡的內容了，以後再講。
捕獲的參數永遠是字元串
關於這句話我在剛纔的 num1 和 num2 相加的示例中已經演示過了，這裡記住這句話就行了。
指定視圖參數的預設值
這並不是 django 特有的用法，這是 python中 的函數預設參數的內容。但是django這裡能處理一些特殊的情況：
from django.conf.urls import url from . import views urlpatterns = [ url(r'^blog/$', views.page), url(r'^blog/page(?P<num>[0-9]+)/$', views.page),
]
def page(request, num="1"): ...... return .....
在上面的例子中，兩個URL模式指向同一個視圖views.page —— 但是第一個模式不會從URL 中捕獲任何值。如果第一個模式匹配，page() 函數將使用num參數的預設值"1"。如果第二個模式匹配，page() 將使用正則表達式捕獲的 num 值。
性能
urlpatterns 中的每個正則表達式在第一次訪問它們時被編譯。這使得系統相當快。
urlpatterns 變數的語法
urlpatterns 應該是一個 python 列表，列表中存放的都是 url() 的實例。
錯誤處理
當Django 找不到一個匹配請求的 URL 的正則表達式時，或者當拋出一個異常時，Django 將調用一個錯誤處理視圖。
這些情況發生時使用的視圖通過4個變數指定。它們的預設值應該滿足大部分項目，但是通過賦值給它們以進一步的自定義也是可以的。
完整的細節請參見自定義錯誤視圖。
這些值可以在你的根URLconf 中設置。在其它URLconf 中設置這些變數將不會生效果。
它們的值必須是可調用的或者是表示視圖的Python 完整導入路徑的字元串，可以方便地調用它們來處理錯誤情況。
這些值是：
handler404 —— 參見django.conf.urls.handler404。
handler500 —— 參見django.conf.urls.handler500。
handler403 —— 參見django.conf.urls.handler403。
handler400 —— 參見django.conf.urls.handler400。
關於這部分我目前也在研究中，以後研究出結果再分享出來。
