腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

軟件下載

android MAC 驅(qū)動(dòng)下載字體下載 DLL

源碼下載

PHP ASP.NET ASP JSP

軟件編程

C# JAVA C 語言 Delphi Android

網(wǎng)絡(luò)編程

PHP ASP.NET ASP JavaScript

在線工具

CSS格式化 JS格式化 Html轉(zhuǎn)化為Js

數(shù)據(jù)庫

MYSQL MSSQL oracle DB2 MARIADB

CMS

PHPCMS DEDECMS 帝國CMS WordPress

常用工具

PHP開發(fā)工具 python Photoshop 必備軟件

Python的Django框架中從url中捕捉文本的方法

更新時(shí)間：2015年07月20日 09:54:12 投稿：goldensun

這篇文章主要介紹了Python的Django框架中從url中捕捉文本的方法,以及URLconf搜索的一些相關(guān)情況,需要的朋友可以參考下

每個(gè)被捕獲的參數(shù)將被作為純Python字符串來發(fā)送，而不管正則表達(dá)式中的格式。舉個(gè)例子，在這行URLConf中：

(r'^articles/(?P<year>\d{4})/$', views.year_archive),

盡管 \d{4} 將只匹配整數(shù)的字符串，但是參數(shù) year 是作為字符串傳至 views.year_archive() 的，而不是整型。

當(dāng)你在寫視圖代碼時(shí)記住這點(diǎn)很重要，許多Python內(nèi)建的方法對于接受的對象的類型很講究。許多內(nèi)置Python函數(shù)是挑剔的（這是理所當(dāng)然的）只接受特定類型的對象。一個(gè)典型的的錯(cuò)誤就是用字符串值而不是整數(shù)值來創(chuàng)建 datetime.date 對象：

>>> import datetime
>>> datetime.date('1993', '7', '9')
Traceback (most recent call last):
  ...
TypeError: an integer is required
>>> datetime.date(1993, 7, 9)
datetime.date(1993, 7, 9)

回到URLconf和視圖處，錯(cuò)誤看起來很可能是這樣：

# urls.py

from django.conf.urls.defaults import *
from mysite import views

urlpatterns = patterns('',
  (r'^articles/(\d{4})/(\d{2})/(\d{2})/$', views.day_archive),
)

# views.py

import datetime

def day_archive(request, year, month, day):
  # The following statement raises a TypeError!
  date = datetime.date(year, month, day)

因此， day_archive() 應(yīng)該這樣寫才是正確的：

def day_archive(request, year, month, day):
  date = datetime.date(int(year), int(month), int(day))

注意，當(dāng)你傳遞了一個(gè)并不完全包含數(shù)字的字符串時(shí)， int() 會(huì)拋出 ValueError 的異常，不過我們已經(jīng)避免了這個(gè)錯(cuò)誤，因?yàn)樵赨RLconf的正則表達(dá)式中已經(jīng)確保只有包含數(shù)字的字符串才會(huì)傳到這個(gè)視圖函數(shù)中。
決定URLconf搜索的東西

當(dāng)一個(gè)請求進(jìn)來時(shí)，Django試著將請求的URL作為一個(gè)普通Python字符串進(jìn)行URLconf模式匹配（而不是作為一個(gè)Unicode字符串）。這并不包括 GET 或 POST 參數(shù)或域名。它也不包括第一個(gè)斜杠，因?yàn)槊總€(gè)URL必定有一個(gè)斜杠。

例如，在向 http://www.example.com/myapp/ 的請求中，Django將試著去匹配 myapp/ 。在向 http://www.example.com/myapp/?page=3 的請求中，Django同樣會(huì)去匹配 myapp/ 。

在解析URLconf時(shí)，請求方法（例如， POST ， GET ， HEAD ）并不會(huì) 被考慮。換而言之，對于相同的URL的所有請求方法將被導(dǎo)向到相同的函數(shù)中。因此根據(jù)請求方法來處理分支是視圖函數(shù)的責(zé)任。

您可能感興趣的文章: