# Django 6.0.7 documentation

# `django.urls` verktygsfunktioner

## `reverse()`

Funktionen `reverse()` kan användas för att returnera en absolut sökvägsreferens för en given vy och valfria parametrar, på liknande sätt som taggen `url`:

reverse(viewname, urlconf=None, args=None, kwargs=None, current_app=None, *, query=None, fragment=None)

`viewname` kan vara ett URL-mönsternamn eller det anropsbara vyobjekt som används i URLconf. Till exempel:, med följande `url`:

    from news import views

    path("archive/", views.archive, name="news-archive")

kan du använda något av följande för att vända URL:en:

    # using the named URL
    reverse("news-archive")

    # passing a callable object
    # (This is discouraged because you can't reverse namespaced views this way.)
    from news import views

    reverse(views.archive)

Om URL:en accepterar argument kan du skicka dem i `args`. Till exempel:

    from django.urls import reverse

    def myview(request):
        return HttpResponseRedirect(reverse("arch-summary", args=[1945]))

Du kan också skicka `kwargs` i stället för `args`. Till exempel:

    >>> reverse("admin:app_list", kwargs={"app_label": "auth"})
    '/admin/auth/'

`args` och `kwargs` kan inte skickas till `reverse()` samtidigt.

Om ingen matchning kan göras, ger `reverse()` upphov till ett `NoReverseMatch` undantag.

Funktionen `reverse()` kan vända ett stort antal reguljära uttrycksmönster för webbadresser, men inte alla möjliga. Den största begränsningen för närvarande är att mönstret inte kan innehålla alternativa val med hjälp av det vertikala strecket (`"|"`). Du kan mycket väl använda sådana mönster för att matcha mot inkommande webbadresser och skicka dem till visningar, men du kan inte vända sådana mönster.

Med argumentet `current_app` kan du ge en ledtråd till resolvern som anger vilken applikation den vy som körs för tillfället tillhör. Detta `current_app`-argument används som en ledtråd för att lösa upp applikationsnamnrymder till URL:er på specifika applikationsinstanser, enligt namespaced URL resolution strategy.

Argumentet `urlconf` är URLconf-modulen som innehåller de URL-mönster som ska användas för reversering. Som standard används rot-URLconf för den aktuella tråden.

Nyckelordsargumentet `query` anger parametrar som ska läggas till i den returnerade URL:en. Det kan acceptera en instans av `QueryDict` (t.ex. `request.GET`) eller ett värde som är kompatibelt med `urllib.parse.urlencode()`. Den kodade frågesträngen läggs till den upplösta URL:en, med en `?` som prefix.

Nyckelordsargumentet `fragment` anger en fragmentidentifierare som ska läggas till i den returnerade URL:en (dvs. efter sökvägen och frågesträngen, föregånget av `#`).

Till exempel:

    >>> from django.urls import reverse
    >>> reverse("admin:index", query={"q": "biscuits", "page": 2}, fragment="results")
    '/admin/?q=biscuits&page=2#results'
    >>> reverse("admin:index", query=[("color", "blue"), ("color", 1), ("none", None)])
    '/admin/?color=blue&color=1&none=None'
    >>> reverse("admin:index", query={"has empty spaces": "also has empty spaces!"})
    '/admin/?has+empty+spaces=also+has+empty+spaces%21'
    >>> reverse("admin:index", fragment="no encoding is done")
    '/admin/#no encoding is done'

Observera

Den sträng som returneras av `reverse()` är redan urlquoted. Till exempel:

    >>> reverse("cities", args=["Orléans"])
    '.../Orl%C3%A9ans/'

Att tillämpa ytterligare kodning (t.ex. `urllib.parse.quote()`) på utdata från `reverse()` kan ge oönskade resultat.

Omvända klassbaserade åsikter genom att visa objekt

View-objektet kan också vara resultatet av anropet `as_view()` om samma view-objekt används i URLConf. I enlighet med det ursprungliga exemplet kan vyobjektet definieras som:

`nyheter/views.py`

     from django.views import View

     class ArchiveView(View): ...

     archive = ArchiveView.as_view()

Kom dock ihåg att namespaced-vyer inte kan vändas av view-objekt.

## `omvänd_lazy()`

En lättsamt utvärderad version av reverse().

reverse_lazy(viewname, urlconf=None, args=None, kwargs=None, current_app=None, *, query=None, fragment=None)

Den är användbar när du behöver använda en URL-reversering innan projektets URLConf har laddats. Några vanliga fall där denna funktion är nödvändig är:

- tillhandahålla en omvänd URL som `url`-attribut för en generisk klassbaserad vy.

- tillhandahålla en omvänd URL till en dekorator (t.ex. argumentet `login_url` för dekoratorn `django.contrib.auth.decorators.permission_required()`).

- tillhandahålla en omvänd URL som standardvärde för en parameter i en funktions signatur.

## `resolve()`

Funktionen `resolve()` kan användas för att lösa upp URL-sökvägar till motsvarande vyfunktioner. Den har följande signatur:

resolve(path, urlconf=None)

`path` är den URL-sökväg du vill lösa. Precis som med `reverse()` behöver du inte oroa dig för parametern `urlconf`. Funktionen returnerar ett `ResolverMatch`-objekt som gör att du kan komma åt olika metadata om den upplösta URL:en.

Om URL:en inte kan lösas, ger funktionen upphov till ett `Resolver404`-undantag (en underklass till `Http404`) .

class ResolverMatch
  func

    Den vyfunktion som ska användas för att betjäna URL:en

  args

    De argument som ska skickas till view-funktionen, som de tolkats från URL:en.

  kwargs

    Alla nyckelordsargument som ska skickas till vyfunktionen, dvs `captured_kwargs` och `extra_kwargs`.

  captured_kwargs

    De fångade nyckelordsargument som skulle skickas till visningsfunktionen, som de tolkats från URL:en.

  extra_kwargs

    De ytterligare nyckelordsargument som ska skickas till view-funktionen.

  url_name

    Namnet på det URL-mönster som matchar URL:en.

  route

    Rutten för det matchande URL-mönstret.

    Om till exempel `path('users/<id>/', ...)` är det matchande mönstret kommer `route` att innehålla `'users/<id>/'`.

  tried

    Listan över URL-mönster som provades innan URL:en antingen matchade ett eller uttömde tillgängliga mönster.

  app_name

    Applikationens namnrymd för det URL-mönster som matchar URL:en.

  app_names

    Listan över enskilda namnrymdskomponenter i hela applikationens namnrymd för det URL-mönster som matchar URL:en. Om t.ex. `app_name` är `'foo:bar`, kommer `app_names` att vara `['foo', 'bar']`.

  namespace

    Instansnamnrymden för det URL-mönster som matchar URL:en.

  namespaces

    Listan över enskilda namnrymdskomponenter i den fullständiga instansens namnrymd för det URL-mönster som matchar URL:en. dvs. om namnrymden är `foo:bar` kommer namnrymderna att vara `['foo', 'bar']`.

  view_name

    Namnet på den vy som matchar URL:en, inklusive namnrymden om det finns en sådan.

Ett `ResolverMatch`-objekt kan sedan förfrågas för att ge information om det URL-mönster som matchar en URL:

    # Resolve a URL
    match = resolve("/some/path/")
    # Print the URL pattern that matches the URL
    print(match.url_name)

Ett `ResolverMatch`-objekt kan också tilldelas en trippel:

    func, args, kwargs = resolve("/some/path/")

En möjlig användning av `resolve()` skulle vara att testa om en vy skulle ge upphov till ett `Http404`-fel innan den omdirigeras till den:

    from urllib.parse import urlsplit
    from django.urls import resolve
    from django.http import Http404, HttpResponseRedirect

    def myview(request):
        next = request.META.get("HTTP_REFERER", None) or "/"
        response = HttpResponseRedirect(next)

        # modify the request and response as required, e.g. change locale
        # and set corresponding locale cookie

        view, args, kwargs = resolve(urlsplit(next).path)
        kwargs["request"] = request
        try:
            view(*args, **kwargs)
        except Http404:
            return HttpResponseRedirect("/")
        return response

## `get_script_prefix()`

get_script_prefix()

Normalt bör du alltid använda `reverse()` för att definiera webbadresser i din applikation. Men om din applikation konstruerar en del av URL-hierarkin själv, kan du ibland behöva generera webbadresser. I så fall måste du kunna hitta bas-URL:en för Django-projektet i dess webbserver (normalt tar `reverse()` hand om detta åt dig). I så fall kan du anropa `get_script_prefix()`, som returnerar skriptprefixdelen av URL:en för ditt Django-projekt. Om ditt Django-projekt ligger i roten på webbservern är detta alltid `"/"`.

Varning

Denna funktion kan inte** användas utanför request-response-cykeln eftersom den förlitar sig på värden som initieras under den cykeln.