Detta dokument beskriver Djangos API:er för filåtkomst för filer som till exempel de som laddas upp av en användare. API:erna på lägre nivå är tillräckligt generella för att du ska kunna använda dem för andra ändamål. Om du vill hantera ”statiska filer” (JS, CSS, etc.), se Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS).
\nSom standard lagrar Django filer lokalt med hjälp av inställningarna MEDIA_ROOT och MEDIA_URL. Exemplen nedan förutsätter att du använder dessa standardinställningar.
Django tillhandahåller dock sätt att skriva anpassade ”fillagringssystem” som gör att du helt kan anpassa var och hur Django lagrar filer. I andra halvan av detta dokument beskrivs hur dessa lagringssystem fungerar.
\nNär du använder en FileField eller ImageField tillhandahåller Django en uppsättning API:er som du kan använda för att hantera den filen.
Tänk på följande modell, som använder en ImageField för att lagra ett foto:
from django.db import models\n\n\nclass Car(models.Model):\n name = models.CharField(max_length=255)\n price = models.DecimalField(max_digits=5, decimal_places=2)\n photo = models.ImageField(upload_to="cars")\n specs = models.FileField(upload_to="specs")\nVarje Car-instans har ett photo-attribut som du kan använda för att få fram detaljerna i det bifogade fotot:
>>> car = Car.objects.get(name="57 Chevy")\n>>> car.photo\n<ImageFieldFile: cars/chevy.jpg>\n>>> car.photo.name\n'cars/chevy.jpg'\n>>> car.photo.path\n'/media/cars/chevy.jpg'\n>>> car.photo.url\n'https://media.example.com/cars/chevy.jpg'\nDetta objekt - car.photo i exemplet - är ett File-objekt, vilket innebär att det har alla de metoder och attribut som beskrivs nedan.
Du kan till exempel ändra filnamnet genom att ställa in filens name till en sökväg i förhållande till fillagringsplatsen (MEDIA_ROOT om du använder standard FileSystemStorage):
>>> import os\n>>> from django.conf import settings\n>>> initial_path = car.photo.path\n>>> car.photo.name = "cars/chevy_ii.jpg"\n>>> new_path = os.path.join(settings.MEDIA_ROOT, car.photo.name)\n>>> # Move the file on the filesystem\n>>> os.rename(initial_path, new_path)\n>>> car.save()\n>>> car.photo.path\n'/media/cars/chevy_ii.jpg'\n>>> car.photo.path == new_path\nTrue\nSå här sparar du en befintlig fil på disken till en FileField:
>>> from pathlib import Path\n>>> from django.core.files import File\n>>> path = Path("/some/external/specs.pdf")\n>>> car = Car.objects.get(name="57 Chevy")\n>>> with path.open(mode="rb") as f:\n... car.specs = File(f, name=path.name)\n... car.save()\n...\nInternt använder Django en django.core.files.File-instans varje gång den behöver representera en fil.
För det mesta använder du en Fil som Django har gett dig (dvs. en fil som är kopplad till en modell enligt ovan, eller kanske en uppladdad fil).
Om du behöver konstruera en File själv är det enklaste sättet att skapa en med hjälp av ett Python-inbyggt file-objekt:
>>> from django.core.files import File\n\n# Create a Python file object using open()\n>>> f = open("/path/to/hello.world", "w")\n>>> myfile = File(f)\nNu kan du använda alla dokumenterade attribut och metoder i File-klassen.
Tänk på att filer som skapas på detta sätt inte stängs automatiskt. Följande metod kan användas för att stänga filer automatiskt:
\n>>> from django.core.files import File\n\n# Create a Python file object using open() and the with statement\n>>> with open("/path/to/hello.world", "w") as f:\n... myfile = File(f)\n... myfile.write("Hello World")\n...\n>>> myfile.closed\nTrue\n>>> f.closed\nTrue\nAtt stänga filer är särskilt viktigt när man använder filfält i en loop över ett stort antal objekt. Om filer inte stängs manuellt efter åtkomst kan det uppstå risk för att filbeskrivare tar slut. Detta kan leda till följande fel:
\nOSError: [Errno 24] Too many open files\nBakom kulisserna delegerar Django beslut om hur och var filer ska lagras till ett fillagringssystem. Detta är det objekt som faktiskt förstår saker som filsystem, öppning och läsning av filer etc.
\nDjangos standard fillagring är 'django.core.files.storage.FileSystemStorage'. Om du inte uttryckligen anger ett lagringssystem i default-nyckeln i inställningen STORAGES, är det detta som kommer att användas.
Se nedan för mer information om det inbyggda standard fillagringssystemet, och se Så här skriver du en anpassad lagringsklass för information om hur du skriver ditt eget fillagringssystem.
\nÄven om du för det mesta vill använda ett File-objekt (som delegerar till rätt lagring för filen) kan du använda fillagringssystem direkt. Du kan skapa en instans av någon anpassad fillagringsklass, eller - ofta mer användbart - du kan använda det globala standardlagringssystemet:
>>> from django.core.files.base import ContentFile\n>>> from django.core.files.storage import default_storage\n\n>>> path = default_storage.save("path/to/file", ContentFile(b"new content"))\n>>> path\n'path/to/file'\n\n>>> default_storage.size(path)\n11\n>>> default_storage.open(path).read()\nb'new content'\n\n>>> default_storage.delete(path)\n>>> default_storage.exists(path)\nFalse\nSe API för fillagring för API:et för fillagring.
\nDjango levereras med en django.core.files.storage.FileSystemStorage-klass som implementerar grundläggande lokal filsystemlagring.
Till exempel kommer följande kod att lagra uppladdade filer under /media/photos oavsett vad din MEDIA_ROOT-inställning är:
from django.core.files.storage import FileSystemStorage\nfrom django.db import models\n\nfs = FileSystemStorage(location="/media/photos")\n\n\nclass Car(models.Model):\n ...\n photo = models.ImageField(storage=fs)\nCustom storage systems fungerar på samma sätt: du kan skicka in dem som argumentet storage till en FileField.
Du kan använda en callable som storage parameter för FileField eller ImageField. Detta gör att du kan ändra den använda lagringen vid körning, till exempel välja olika lagring för olika miljöer.
Your callable will be evaluated when your model classes are loaded, and must\nreturn an instance of Storage.
Till exempel:
\nfrom django.conf import settings\nfrom django.db import models\nfrom .storages import MyLocalStorage, MyRemoteStorage\n\n\ndef select_storage():\n return MyLocalStorage() if settings.DEBUG else MyRemoteStorage()\n\n\nclass MyModel(models.Model):\n my_file = models.FileField(storage=select_storage)\nFör att ställa in en lagring som definieras i inställningen STORAGES kan du använda storages:
from django.core.files.storage import storages\n\n\ndef select_storage():\n return storages["mystorage"]\n\n\nclass MyModel(models.Model):\n upload = models.FileField(storage=select_storage)\nBecause the callable is evaluated when your model classes are loaded, if you\nneed to override the STORAGES setting in tests, you should use a\nLazyObject subclass instead:
from django.core.files.storage import storages\nfrom django.utils.functional import LazyObject\n\n\nclass OtherStorage(LazyObject):\n def _setup(self):\n self._wrapped = storages["mystorage"]\n\n\nmy_storage = OtherStorage()\n\n\nclass MyModel(models.Model):\n upload = models.FileField(storage=my_storage)\nLazyObject fördröjer utvärderingen av lagringen tills den faktiskt behövs, vilket gör att override_settings() kan träda i kraft:
@override_settings(\n STORAGES={\n "mystorage": {\n "BACKEND": "django.core.files.storage.InMemoryStorage",\n }\n }\n)\ndef test_storage():\n model = MyModel()\n assert isinstance(model.upload.storage, InMemoryStorage)\n