django URL路由基础
URL是Web服務的入口，用戶通過瀏覽器發(fā)送過來的任何請求，都是發(fā)送到一個指定的URL地址，然后被響應。
在Django項目中編寫路由，就是向外暴露我們接收哪些URL的請求，除此之外的任何URL都不被處理，也沒有返回。通俗地理解，不恰當?shù)男稳?#xff0c;URL路由是你的Web服務對外暴露的API。
Django奉行DRY主義，提倡使用簡潔、優(yōu)雅的URL，沒有.php或.cgi這種后綴，更不會單獨使用0、2097、1-1-1928、00這樣無意義的東西，讓你隨心所欲設計你的URL，不受框架束縛。
一、概述
URL路由在Django項目中的體現(xiàn)就是urls.py文件，這個文件可以有很多個，但絕對不會在同一目錄下。實際上Django提倡項目有個根urls.py，各app下分別有自己的一個urls.py，既集中又分治，是一種解耦的模式。
隨便新建一個Django項目，默認會自動為我們創(chuàng)建一個/project_name/urls.py文件，并且自動包含下面的內容，這就是項目的根URL：
"""mysite URL ConfigurationThe `urlpatterns` list routes URLs to views. For more information please see: https://docs.djangoproject.com/en/1.11/topics/http/urls/ Examples: Function views 1. Add an import: from my_app import views 2. Add a URL to urlpatterns: url(r'^$', views.home, name='home') Class-based views 1. Add an import: from other_app.views import Home 2. Add a URL to urlpatterns: url(r'^$', Home.as_view(), name='home') Including another URLconf 1. Import the include() function: from django.conf.urls import url, include 2. Add a URL to urlpatterns: url(r'^blog/', include('blog.urls')) """ from django.conf.urls import url from django.contrib import admin urlpatterns = [ url(r'^admin/', admin.site.urls), ]前面一堆幫助性的文字，我們不用管，關鍵是默認導入了url和admin，然后有一條指向admin后臺的url路徑。
我們自己要編寫的url路由，基本也是這個套路。
二、Django如何處理請求
當用戶請求一個頁面時，Django根據(jù)下面的邏輯執(zhí)行操作：
三、簡單示例
下面是一個簡單的 URLconf：
from django.conf.urls import urlfrom . 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), ]我們要編寫的就是上面urlpatterns列表中的一條條url，每條url，都是urlpatterns列表的一個元素。先后順序有重要關系，不能隨意擺放。最后一條的末尾建議添加一個逗號。
urlpatterns中的每條正則表達式在第一次訪問時被自動編譯，因此其匹配速度是非常快的。
注意：
- 若要從URL中捕獲一個值，只需要在它周圍放置一對圓括號。
- 不需要添加前導的反斜杠，因為每個URL都有。 例如，應該是^articles而不是^/articles。
- 每個正則表達式前面的'r'是可選的但是建議加上。它告訴Python這個字符串是“原始的” —— 字符串中任何字符都不應該轉義。
根據(jù)上面的urlconf，下面是一些請求的例子，以及它們將匹配到的url：
- /articles/2005/03/將匹配列表中的第三個模式。Django將調用函數(shù)views.month_archive(request, '2005', '03')。
- /articles/2005/3/不匹配任何URL模式，因為列表中的第三個模式要求月份是兩個數(shù)字。
- /articles/2003/將匹配列表中的第一個模式不是第二個，因為模式按順序從上往下匹配，第一個會首先被匹配。Django會調用函數(shù)views.special_case_2003(request)
- /articles/2003不匹配任何一個模式，因為每個模式都要求URL以一個斜杠結尾。
- /articles/2003/03/03/將匹配最后一個模式。Django將調用函數(shù)views.article_detail(request, '2003', '03', '03')。
四、命名組
很多時候，我們需要獲取URL中的一些片段，作為參數(shù)，傳遞給處理請求的視圖。
上面的示例使用簡單的、沒有命名的正則表達式組（通過圓括號）來捕獲URL中的值并以位置參數(shù)的形式傳遞給視圖。
可以使用命名的正則表達式組來捕獲URL中的值并以關鍵字參數(shù)傳遞給視圖。
在Python的正則表達式中，命名組的語法是(?P<name>pattern)，其中name是組的名稱，pattern是要匹配的模式。
下面是以上URLconf使用命名組的重寫：
from django.conf.urls import urlfrom . 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), ]這個實現(xiàn)與前面的示例完全相同，只有一個細微的差別：捕獲的值作為關鍵字參數(shù)而不是位置參數(shù)傳遞給視圖函數(shù)。 像這樣：
- /articles/2005/03/請求將調用views.month_archive(request, year='2005', month='03')函數(shù)，而不是views.month_archive(request, '2005', '03')。
- /articles/2003/03/03/請求將調用函數(shù)views.article_detail(request, year='2003', month='03', day='03')。
在實際應用中，這讓你的URLconf更加明晰且不容易產生參數(shù)順序問題的錯誤。當然，這不是強制性的，也犧牲了一些簡潔性。
針對命名組和非命名組：
- 如果有命名參數(shù)，則使用這些命名參數(shù)，忽略非命名參數(shù)。
- 否則，它將以位置參數(shù)傳遞所有的非命名參數(shù)。
五、URLconf匹配請求URL中的哪些部分
請求的URL被看做是一個普通的Python字符串，URLconf在其上查找并匹配。進行匹配時將不包括GET或POST請求方式的參數(shù)以及域名。
例如，在https://www.example.com/myapp/的請求中，URLconf將查找myapp/。
在https://www.example.com/myapp/?page=3的請求中，URLconf也將查找myapp/。
URLconf不檢查使用何種HTTP請求方法，所有請求方法POST、GET、HEAD等都將路由到同一個URL的同一個視圖。在視圖中，才根據(jù)具體請求方法的不同，進行不同的處理。
六、URL中捕獲的參數(shù)為字符串類型
每個捕獲的參數(shù)都作為一個普通的Python字符串傳遞給視圖，即便被捕獲的‘100’看起來像個整數(shù)，但實際上是個字符串‘100’。 例如，下面這行URLconf中：
url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),傳遞給views.year_archive()的year參數(shù)將是一個字符串，不是整數(shù)，即使[0-9]{4}只匹配整數(shù)字符串。
七、指定視圖參數(shù)的默認值
有一個小技巧，我們可以指定視圖參數(shù)的默認值。 下面是一個URLconf和視圖的示例：
# URLconf from django.conf.urls import urlfrom . import views urlpatterns = [ url(r'^blog/$', views.page), url(r'^blog/page(?P<num>[0-9]+)/$', views.page), ] # View (in blog/views.py) def page(request, num="1"): # Output the appropriate page of blog entries, according to num. ...在上面的例子中，兩個URL模式指向同一個視圖views.page。但是第一個模式不會從URL中捕獲任何值。 如果第一個模式匹配，page()函數(shù)將使用num參數(shù)的默認值"1"。 如果第二個模式匹配，page()將使用捕獲的num值。
八、自定義錯誤頁面
當Django找不到與請求匹配的URL時，或者當拋出一個異常時，將調用一個錯誤處理視圖。錯誤視圖包括400、403、404和500，分別表示請求錯誤、拒絕服務、頁面不存在和服務器錯誤。它們分別位于：
- handler400 —— django.conf.urls.handler400。
- handler403 —— django.conf.urls.handler403。
- handler404 —— django.conf.urls.handler404。
- handler500 —— django.conf.urls.handler500。
這些值可以在根URLconf中設置。在其它app中的二級URLconf中設置這些變量無效。
Django有內置的HTML模版，用于返回錯誤頁面給用戶，但是這些403，404頁面實在丑陋，通常我們都自定義錯誤頁面。
首先，在根URLconf中額外增加下面的條目：
# URLconf from django.conf.urls import urlfrom . import views urlpatterns = [ url(r'^blog/$', views.page), url(r'^blog/page(?P<num>[0-9]+)/$', views.page), ] # 增加的條目 handler400 = views.bad_request handler403 = views.permission_denied handler404 = views.page_not_found handler500 = views.page_error然后在，views.py文件中增加四個處理視圖：
def page_not_found(request):return render(request, '404.html') def page_error(request): return render(request, '500.html') def permission_denied(request): return render(request, '403.html') def bad_request(request): return render(request, '400.html')再根據(jù)自己的需求，創(chuàng)建404.html、400.html等四個頁面文件，就可以了。
轉載于:https://www.cnblogs.com/navysummer/p/10200191.html
總結
以上是生活随笔為你收集整理的django URL路由基础的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【poj1006-biorhythms】
- 下一篇： 团队作业-项目答辩