django.urls ユーティリティ関数Link to this heading#reverse()Link to this heading#コード内で url テンプレートタグと似たような機能を使用する必要がある場合、Django は次の関数を提供しています:
viewname は URL パターン名 または呼び出し可能なビューオブジェクトのいずれかを指定できます。例えば、以下の url を見てください:
from news import views\n\npath("archive/", views.archive, name="news-archive")\nURL を逆引きするために、以下の方法を使用できます：
\n# using the named URL\nreverse("news-archive")\n\n# passing a callable object\n# (This is discouraged because you can't reverse namespaced views this way.)\nfrom news import views\n\nreverse(views.archive)\nURLが引数を受け入れる場合は、 args にそれらを渡すことができます。例えば：
from django.urls import reverse\n\n\ndef myview(request):\n return HttpResponseRedirect(reverse("arch-summary", args=[1945]))\nkwargs を args の代わりに渡すこともできます。例えば：
>>> reverse("admin:app_list", kwargs={"app_label": "auth"})\n'/admin/auth/'\nargs と kwargs を同時に reverse() に渡すことはできません。
一致するものが見つからない場合、reverse() は NoReverseMatch 例外を発生させます。
reverse() 関数は、URLの正規表現パターンの多くを逆引きできますが、すべてを逆引きできるわけではありません。現時点での主な制限は、パターンに垂直バー (“|”) 文字を使用して選択肢を含めることができないということです。そのようなパターンを使用して受信URLに対してマッチングし、それらをビューに送ることは問題なく行えますが、そのようなパターンを逆引きすることはできません。
current_app 引数は、現在実行中のビューが属しているアプリケーションを指示するヒントをリゾルバに提供することを可能にします。この current_app 引数は、特定のアプリケーションインスタンス上のURLに対してアプリケーションの名前空間を解決するためのヒントとして使用されます。これは、 名前空間化された URL の解決順序 に従っています。
urlconf 引数は、リバースに使用する URL パターンを含む URLconf モジュールです。デフォルトでは、現在のスレッドのルート URLconf が使用されます。
reverse_lazy()Link to this heading#reverse() の遅延評価バージョンです。
\nプロジェクトの URLConf がロードされる前に、URL 反転を使用する必要がある場合に役立ちます。この関数が必要となる一般的なケースには以下のようなものがあります：
\nクラスベースのジェネリックビューの url 属性に逆引きURLを提供する場合。
デコレータ（たとえば django.contrib.auth.decorators.permission_required() デコレータの login_url 引数など）への URL の逆引きを提供する場合。
関数のシグネチャでパラメータのデフォルト値として逆引きURLを提供する場合。
resolve()Link to this heading#resolve() 関数は、URL パスを対応するビュー関数に解決するために使用できます。次のシグネチャを持っています:
path は解決したい URL パスです。 reverse() と同じように、 urlconf パラメータについて心配する必要はありません。この関数は、解決された URL に関するさまざまなメタデータにアクセスを許可する ResolverMatch オブジェクトを返します。
URL が解決しない場合、その関数は Resolver404 例外を発生させます（ Http404 のサブクラスです）。
URL を提供するために使用されるビュー関数
\nURL からパースされた、ビュー関数に渡される引数。
\nビュー関数に渡されるであろうすべてのキーワード引数、すなわち captured_kwargs と extra_kwargs です。
URL から解析された、ビュー関数に渡されるキーワード引数がキャプチャされます。
\nビュー関数に渡される追加のキーワード引数。
\nURL に一致する URL パターンの名前。
\n一致するURLパターンのルート。
\n例えば、path('users/<id>/', ...) がマッチするパターンである場合、 route には 'users/<id>/' が含まれます。
URL が一致するか利用可能なパターンが尽きる前に試みられた URL パターンのリストです。
\nURLに一致するURLパターンのアプリケーション名前空間です。
\nURL にマッチする URL パターンの完全なアプリケーション名前空間内の個別の名前空間コンポーネントのリストです。例えば、もし app_name が 'foo:bar' である場合、app_names は ['foo', 'bar'] になります。
対応するURLのURLパターンのインスタンス名前空間。
\nURL がマッチする URL パターンの完全なインスタンス名前空間内の個々の名前空間コンポーネントのリストです。つまり、名前空間が foo:bar である場合、namespaces は ['foo', 'bar'] になります。
URL にマッチするビューの名前で、名前空間が存在する場合はその名前空間を含みます。
\nその後、 ResolverMatch オブジェクトを調査して、URL に一致する URL パターンに関する情報を提供できます。
# Resolve a URL\nmatch = resolve("/some/path/")\n# Print the URL pattern that matches the URL\nprint(match.url_name)\nResolverMatch オブジェクトは、3値タプルに代入することもできます:
func, args, kwargs = resolve("/some/path/")\nresolve() の可能な使用例の一つは、リダイレクトする前にビューが Http404 エラーを発生させるかどうかをテストすることです。
from urllib.parse import urlparse\nfrom django.urls import resolve\nfrom django.http import Http404, HttpResponseRedirect\n\n\ndef myview(request):\n next = request.META.get("HTTP_REFERER", None) or "/"\n response = HttpResponseRedirect(next)\n\n # modify the request and response as required, e.g. change locale\n # and set corresponding locale cookie\n\n view, args, kwargs = resolve(urlparse(next)[2])\n kwargs["request"] = request\n try:\n view(*args, **kwargs)\n except Http404:\n return HttpResponseRedirect("/")\n return response\nget_script_prefix()Link to this heading#通常、アプリケーション内でURLを定義する際には、常に reverse() を使用すべきです。しかし、アプリケーションがURL階層の一部を自身で構築する場合、時々URLを生成する必要があります。その場合、DjangoプロジェクトのベースURLをそのWebサーバー内で見つける必要があります（通常、 reverse() がこれを処理します）。そのような場合、 get_script_prefix() を呼び出すことができます。これは、DjangoプロジェクトのURLのスクリプトプレフィックス部分を返します。あなたのDjangoプロジェクトがWebサーバーのルートにある場合、これは常に "/" です。