---
title: "Validering av formulär och fält"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/ref/forms/validation/
canonical: https://djangodocs.dev/sv/6.1/ref/forms/validation/
---
# Validering av formulär och fält

Formulärvalidering sker när data rensas. Om du vill anpassa den här processen finns det olika platser där du kan göra ändringar, var och en med olika syften. Tre typer av rengöringsmetoder körs under formulärbehandlingen. Dessa körs normalt när du anropar metoden `is_valid()` på ett formulär. Det finns andra saker som också kan utlösa rengöring och validering (åtkomst till attributet `errors` eller direkt anrop av `full_clean()`)), men normalt sett behövs de inte.

I allmänhet kan varje rengöringsmetod höja `ValidationError` om det finns ett problem med de data den bearbetar, och skicka relevant information till `ValidationError`-konstruktören. [Se nedan](#raising-validation-error) för bästa praxis för att höja `ValidationError`. Om inget `ValidationError` uppstår bör metoden returnera de rensade (normaliserade) data som ett Python-objekt.

Den mesta valideringen kan göras med hjälp av [validatorer](#validators) \- hjälpare som kan återanvändas. Validerare är funktioner (eller anropsbara) som tar ett enda argument och ger upphov till `ValidationError` vid ogiltig indata. Validerare körs efter att fältets metoder `to_python` och `validate` har anropats.

Valideringen av ett formulär är uppdelad i flera steg, som kan anpassas eller åsidosättas:

- Metoden `to_python()` på en `Field` är det första steget i varje validering. Den tvingar värdet till en korrekt datatyp och ger upphov till `ValidationError` om det inte är möjligt. Den här metoden tar emot det råa värdet från widgeten och returnerar det konverterade värdet. Till exempel: kommer en `FloatField` att omvandla data till en Python `float` eller ge upphov till ett `ValidationError`.
- Metoden `validate()` för en `Field` hanterar fältspecifik validering som inte lämpar sig för en validerare. Den tar ett värde som har tvingats till en korrekt datatyp och ger upphov till `ValidationError` vid eventuella fel. Den här metoden returnerar ingenting och bör inte ändra värdet. Du bör åsidosätta den för att hantera valideringslogik som du inte kan eller vill lägga in i en validator.
- Metoden `run_validators()` på ett `Field` kör alla fältets validatorer och aggregerar alla fel till ett enda `ValidationError`. Du ska inte behöva åsidosätta den här metoden.
- Metoden `clean()` i en subklass av `Field` är ansvarig för att köra `to_python()`, `validate()` och `run_validators()` i rätt ordning och sprida deras fel. Om någon av metoderna vid något tillfälle ger upphov till `ValidationError`, stoppas valideringen och det felet anges. Denna metod returnerar de rena uppgifterna, som sedan infogas i formulärets ordbok `cleaned_data`.
- Metoden `clean_<fieldname>()` anropas på en formulärunderklass – där `<fieldname>` ersätts med namnet på formulärfältets attribut. Denna metod utför all rengöring som är specifik för det specifika attributet, oberoende av vilken typ av fält det är. Den här metoden får inga parametrar. Du måste leta upp värdet på fältet i `self.cleaned_data` och komma ihåg att det kommer att vara ett Python-objekt vid denna tidpunkt, inte den ursprungliga strängen som skickades in i formuläret (det kommer att vara i `cleaned_data` eftersom den allmänna fältmetoden `clean()` ovan redan har rensat data en gång).

  Om du till exempel vill validera att innehållet i en `CharField` som heter `serialnumber` är unikt, skulle `clean_serialnumber()` vara rätt plats att göra detta. Du behöver inte ett specifikt fält (det är en `CharField`), men du vill ha en formulärfältsspecifik del av valideringen och eventuellt rensa/normera data.

  Returvärdet för den här metoden ersätter det befintliga värdet i `cleaned_data`, så det måste vara fältets värde från `cleaned_data` (även om den här metoden inte ändrade det) eller ett nytt rensat värde.
- Metoden `clean()` i formulärunderklassen kan utföra validering som kräver åtkomst till flera formulärfält. Det är här du kan lägga in kontroller som ”om fält `A` anges, måste fält `B` innehålla en giltig e-postadress”. Den här metoden kan returnera en helt annan ordbok om den vill, som kommer att användas som `cleaned_data`.

  Eftersom fältvalideringsmetoderna har körts när `clean()` anropas, har du också tillgång till formulärets `errors`-attribut som innehåller alla fel som uppstått vid rensning av enskilda fält.

  Note that any errors raised by your [`Form.clean()`](/sv/6.1/ref/forms/api/#django.forms.Form.clean) override will not
  be associated with any field in particular. They go into a special
  ”field” (called `__all__`), which you can access via the
  [`non_field_errors()`](/sv/6.1/ref/forms/api/#django.forms.Form.non_field_errors) method if you need to. If you
  want to attach errors to a specific field in the form, you need to call
  [`add_error()`](/sv/6.1/ref/forms/api/#django.forms.Form.add_error).

  Observera också att det finns särskilda överväganden när du åsidosätter `clean()`-metoden för en `ModelForm`-underklass. (se [ModelForm dokumentation](/sv/6.1/topics/forms/modelforms/#overriding-modelform-clean-method) för mer information)

These methods are run in the order given above, one field at a time. That is,
for each field in the form (in the order they are declared in the form
definition), the `Field.clean()` method (or its override) is run, then
`clean_<fieldname>()`. Finally, once those two methods are run for every
field, the [`Form.clean()`](/sv/6.1/ref/forms/api/#django.forms.Form.clean) method, or its override, is executed whether
or not the previous methods have raised errors.

Exempel på var och en av dessa metoder ges nedan.

Som nämnts kan någon av dessa metoder ge upphov till ett `ValidationError`. För ett fält, om metoden `Field.clean()` ger upphov till ett `ValidationError`, anropas inte någon fältspecifik rengöringsmetod. Rengöringsmetoderna för alla återstående fält körs dock fortfarande.

## Upphävande av `ValidationError`

För att felmeddelanden ska vara flexibla och lätta att åsidosätta bör du beakta följande riktlinjer:

- Provide a descriptive error `code` to the constructor, to allow
  programmatic use (e.g. in tests) that will not vary with translations:

  ```
  # Good
  ValidationError(_("Invalid value"), code="invalid")

  # Bad
  ValidationError(_("Invalid value"))
  ```
- Tvinga inte in variabler i meddelandet; använd platshållare och `params`-argumentet i konstruktören:

  ```
  # Good
  ValidationError(
      _("Invalid value: %(value)s"),
      params={"value": "42"},
  )

  # Bad
  ValidationError(_("Invalid value: %s") % value)
  ```
- Använd mappningsnycklar i stället för positionsformatering. Detta gör det möjligt att placera variablerna i vilken ordning som helst eller att utelämna dem helt och hållet när meddelandet skrivs om:

  ```
  # Good
  ValidationError(
      _("Invalid value: %(value)s"),
      params={"value": "42"},
  )

  # Bad
  ValidationError(
      _("Invalid value: %s"),
      params=("42",),
  )
  ```
- Omslut meddelandet med `gettext` för att möjliggöra översättning:

  ```
  # Good
  ValidationError(_("Invalid value"))

  # Bad
  ValidationError("Invalid value")
  ```

Att sätta ihop allt:

```
raise ValidationError(
    _("Invalid value: %(value)s"),
    code="invalid",
    params={"value": "42"},
)
```

Det är särskilt viktigt att följa dessa riktlinjer om du skriver återanvändbara formulär, formulärfält och modellfält.

Även om det inte rekommenderas, om du är i slutet av valideringskedjan (dvs. ditt formulär `clean()`-metoden) och du vet att du *aldrig* kommer att behöva åsidosätta ditt felmeddelande kan du fortfarande välja den mindre verbala:

```
ValidationError(_("Invalid value: %s") % value)
```

Metoderna [`Form.errors.as_data()`](/sv/6.1/ref/forms/api/#django.forms.Form.errors.as_data) och [`Form.errors.as_json()`](/sv/6.1/ref/forms/api/#django.forms.Form.errors.as_json) har stor nytta av fullt utrustade `ValidationError` (med ett `code`-namn och en `params`-ordbok).

### Upprepa flera fel

Om du upptäcker flera fel under en rensningsmetod och vill signalera dem alla till den som skickar in formuläret, är det möjligt att skicka en lista med fel till konstruktören `ValidationError`.

Som ovan rekommenderas det att skicka en lista över `ValidationError`-instanser med `code` och `params` men en lista med strängar fungerar också:

```
# Good
raise ValidationError(
    [
        ValidationError(_("Error 1"), code="error1"),
        ValidationError(_("Error 2"), code="error2"),
    ]
)

# Bad
raise ValidationError(
    [
        _("Error 1"),
        _("Error 2"),
    ]
)
```

## Använda validering i praktiken

I de föregående avsnitten förklarades hur validering fungerar i allmänhet för formulär. Eftersom det ibland kan vara lättare att få saker på plats genom att se varje funktion användas, följer här en serie små exempel som använder var och en av de tidigare funktionerna.

### Använda validerare

Djangos formulär- (och modell-) fält stöder användning av verktygsfunktioner och klasser som kallas validerare. En validator är ett anropbart objekt eller en funktion som tar ett värde och returnerar ingenting om värdet är giltigt eller ger upphov till ett [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) om inte. Dessa kan skickas till ett fälts konstruktör, via fältets `validators` argument, eller definieras på [`Field`](/sv/6.1/ref/forms/fields/#django.forms.Field)-klassen själv med `default_validators`-attributet.

Validatorer kan användas för att validera värden i fältet, låt oss ta en titt på Djangos `SlugField`:

```
from django.core import validators
from django.forms import CharField

class SlugField(CharField):
    default_validators = [validators.validate_slug]
```

Som du kan se är `SlugField` en `CharField` med en anpassad validator som validerar att den inskickade texten följer vissa teckenregler. Detta kan också göras på fältdefinitionen så här:

```
slug = forms.SlugField()
```

är likvärdig med:

```
slug = forms.CharField(validators=[validators.validate_slug])
```

Vanliga fall som validering mot ett e-postmeddelande eller ett reguljärt uttryck kan hanteras med hjälp av befintliga valideringsklasser som finns i Django. Till exempel: är `validators.validate_slug` en instans av en [`RegexValidator`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator) konstruerad med det första argumentet som är mönstret: `^[-a-zA-Z0-9_]+\Z`. Se avsnittet om [Skriva validatorer](/sv/6.1/ref/validators/) för att se en lista över vad som redan finns tillgängligt och för ett exempel på hur man skriver en validator.

### Standardrengöring av formulärfält

Låt oss först skapa ett anpassat formulärfält som validerar att dess inmatning är en sträng som innehåller kommaseparerade e-postadresser. Den fullständiga klassen ser ut så här:

```
from django import forms
from django.core.validators import validate_email

class MultiEmailField(forms.Field):
    def to_python(self, value):
        """Normalize data to a list of strings."""
        # Return an empty list if no input was given.
        if not value:
            return []
        return value.split(",")

    def validate(self, value):
        """Check if value consists only of valid emails."""
        # Use the parent's handling of required fields, etc.
        super().validate(value)
        for email in value:
            validate_email(email)
```

Varje formulär som använder det här fältet kommer att köra dessa metoder innan något annat kan göras med fältets data. Det här är en rengöring som är specifik för den här typen av fält, oavsett hur det sedan används.

Låt oss skapa en `ContactForm` för att visa hur du använder det här fältet:

```
class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField()
    contact_email = forms.EmailField()
    recipients = MultiEmailField()
    urgent = forms.BooleanField(required=False)
```

Använd `MultiEmailField` som vilket annat formulärfält som helst. När metoden `is_valid()` anropas på formuläret kommer metoden `MultiEmailField.clean()` att köras som en del av rengöringsprocessen och den kommer i sin tur att anropa de anpassade metoderna `to_python()` och `validate()`.

### Rengöring av ett specifikt fältattribut

Continuing on from the previous example, suppose that in our `ContactForm`,
we want to make sure that the `recipients` field only contains addresses that
are `@example.com`. This is validation that is specific to our form, so we
don’t want to put it into the general `MultiEmailField` class. Instead, we
write a cleaning method that operates on the `recipients` field, like so:

```
from django import forms
from django.core.exceptions import ValidationError

class ContactForm(forms.Form):
    # Everything as before.
    ...

    def clean_recipients(self):
        data = self.cleaned_data["recipients"]
        if not all(email.endswith("@example.com") for email in data):
            raise ValidationError("All recipients must be @example.com.")

        # Always return a value to use as the new cleaned data, even if
        # this method didn't change it.
        return data
```

### Rengöring och validering av fält som är beroende av varandra

Suppose we add another requirement to our contact form: if the `urgent` field
is `True`, the `subject` must contain `"help"`. We are performing
validation on more than one field at a time, so the form’s [`clean()`](/sv/6.1/ref/forms/api/#django.forms.Form.clean)
method is a good spot to do this. Notice that we are talking about the
`clean()` method on the form here, whereas earlier we were writing a
`clean()` method on a field. It’s important to keep the field and form
difference clear when working out where to validate things. Fields are single
data points, forms are a collection of fields.

När formulärets `clean()`-metod anropas har alla enskilda fältrengöringsmetoder körts (de två föregående avsnitten), så `self.cleaned_data` kommer att fyllas i med alla data som har överlevt hittills. Så du måste också komma ihåg att ta hänsyn till det faktum att de fält du vill validera kanske inte har överlevt de första individuella fältkontrollerna.

Det finns två sätt att rapportera eventuella fel från detta steg. Den vanligaste metoden är förmodligen att visa felet högst upp i formuläret. För att skapa ett sådant fel kan du skapa ett `ValidationError` från `clean()`-metoden. Till exempel:

```
from django import forms
from django.core.exceptions import ValidationError

class ContactForm(forms.Form):
    # Everything as before.
    ...

    def clean(self):
        cleaned_data = super().clean()
        urgent = cleaned_data.get("urgent")
        subject = cleaned_data.get("subject")

        if urgent and subject:
            # Only do something if both fields are valid so far.
            if "help" not in subject:
                raise ValidationError(
                    "Must put 'help' in the subject for urgent requests."
                )
```

I den här koden visas ett felmeddelande högst upp i formuläret (normalt) som beskriver problemet om valideringsfelet uppstår. Sådana fel är icke-fältfel, som visas i mallen med `{{ form.non_field_errors }}`.

Anropet till `super().clean()` i exempelkoden säkerställer att all valideringslogik i överordnade klasser bibehålls. Om ditt formulär ärver ett annat som inte returnerar en `cleaned_data`-ordbok i sin `clean()`-metod (att göra det är valfritt), tilldela då inte `cleaned_data` till resultatet av `super()`-anropet och använd `self.cleaned_data` istället:

```
def clean(self):
    super().clean()
    urgent = self.cleaned_data.get("urgent")
    ...
```

The second approach for reporting validation errors might involve assigning the
error message to one of the fields. In this case, let’s assign an error message
to both the ”subject” and ”urgent” rows in the form display. Be careful when
doing this in practice, since it can lead to confusing form output. We’re
showing what is possible here and leaving it up to you and your designers to
work out what works effectively in your particular situation. Our new code
(replacing the previous sample) looks like this:

```
from django import forms

class ContactForm(forms.Form):
    # Everything as before.
    ...

    def clean(self):
        cleaned_data = super().clean()
        urgent = cleaned_data.get("urgent")
        subject = cleaned_data.get("subject")

        if urgent and subject and "help" not in subject:
            self.add_error(
                "subject", "Must put 'help' in the subject for urgent requests."
            )
            self.add_error(
                "urgent", "Must not mark urgent unless 'help' is in the subject."
            )
```

Det andra argumentet i `add_error()` kan vara en sträng, eller helst en instans av `ValidationError`. Se [Upphävande av ValidationError](#raising-validation-error) för mer information. Notera att `add_error()` automatiskt tar bort fältet från `cleaned_data`.