During file uploads, the actual file data is stored in request.FILES. Each entry in this dictionary is an\nUploadedFile object (or a subclass) – a simple wrapper around an uploaded\nfile. You’ll usually use one of these methods to access the uploaded content:
Read the entire uploaded data from the file. Be careful with this method:\nif the uploaded file is huge it can overwhelm your system if you try to\nread it into memory. You’ll probably want to use chunks() instead; see\nbelow.
Returns True if the uploaded file is big enough to require reading in\nmultiple chunks. By default this will be any file larger than 2.5 megabytes,\nbut that’s configurable; see below.
A generator returning chunks of the file. If multiple_chunks() is\nTrue, you should use this method in a loop instead of read().
In practice, it’s often easiest simply to use chunks() all the time.\nLooping over chunks() instead of using read() ensures that large\nfiles don’t overwhelm your system’s memory.
Here are some useful attributes of UploadedFile:
The name of the uploaded file (e.g. my_file.txt).
The size, in bytes, of the uploaded file.
\nThe content-type header uploaded with the file (e.g. text/plain\nor application/pdf). Like any data supplied by the user, you\nshouldn’t trust that the uploaded file is actually this type. You’ll still\nneed to validate that the file contains the content that the content-type\nheader claims – «trust but verify.»
\nA dictionary containing extra parameters passed to the content-type\nheader. This is typically provided by services, such as Google App Engine,\nthat intercept and handle file uploads on your behalf. As a result your\nhandler may not receive the uploaded file content, but instead a URL or\nother pointer to the file. (see RFC 2388 section 5.3).
For text/* content-types, the character set (i.e. utf8)\nsupplied by the browser. Again, «trust but verify» is the best policy here.
Subclasses of UploadedFile include:
A file uploaded to a temporary location (i.e. stream-to-disk). This class\nis used by the\nTemporaryFileUploadHandler. In\naddition to the methods from UploadedFile, it has one additional\nmethod:
Returns the full path to the temporary uploaded file.
\nA file uploaded into memory (i.e. stream-to-memory). This class is used\nby the MemoryFileUploadHandler.
Together the MemoryFileUploadHandler and\nTemporaryFileUploadHandler provide Django’s default file upload\nbehavior of reading small files into memory and large ones onto disk. They\nare located in django.core.files.uploadhandler.
File upload handler to stream uploads into memory (used for small files).
\nUpload handler that streams data into a temporary file using\nTemporaryUploadedFile.
All file upload handlers should be subclasses of\ndjango.core.files.uploadhandler.FileUploadHandler. You can define upload\nhandlers wherever you wish.
Custom file upload handlers must define the following methods:
\nReceives a «chunk» of data from the file upload.
\nraw_data is a byte string containing the uploaded data.
start is the position in the file where this raw_data chunk\nbegins.
The data you return will get fed into the subsequent upload handlers”\nreceive_data_chunk methods. In this way, one handler can be a\n«filter» for other handlers.
Return None from receive_data_chunk to short-circuit remaining\nupload handlers from getting this chunk. This is useful if you’re\nstoring the uploaded data yourself and don’t want future handlers to\nstore a copy of the data.
If you raise a StopUpload or a SkipFile exception, the upload\nwill abort or the file will be completely skipped.
Called when a file has finished uploading.
\nThe handler should return an UploadedFile object that will be stored\nin request.FILES. Handlers may also return None to indicate that\nthe UploadedFile object should come from subsequent upload handlers.
Custom upload handlers may also define any of the following optional methods or\nattributes:
\nSize, in bytes, of the «chunks» Django should store into memory and feed\ninto the handler. That is, this attribute controls the size of chunks\nfed into FileUploadHandler.receive_data_chunk.
For maximum performance the chunk sizes should be divisible by 4 and\nshould not exceed 2 GB (231 bytes) in size. When there are\nmultiple chunk sizes provided by multiple handlers, Django will use the\nsmallest chunk size defined by any handler.
The default is 64*210 bytes, or 64 KB.
\nCallback signaling that a new file upload is starting. This is called\nbefore any data has been fed to any upload handlers.
\nfield_name is a string name of the file <input> field.
file_name is the filename provided by the browser.
content_type is the MIME type provided by the browser – E.g.\n'image/jpeg'.
content_length is the length of the image given by the browser.\nSometimes this won’t be provided and will be None.
charset is the character set (i.e. utf8) given by the browser.\nLike content_length, this sometimes won’t be provided.
content_type_extra is extra information about the file from the\ncontent-type header. See UploadedFile.content_type_extra.
This method may raise a StopFutureHandlers exception to prevent\nfuture handlers from handling this file.
Callback signaling that the entire upload (all files) has completed.
\nAllows the handler to completely override the parsing of the raw\nHTTP input.
\ninput_data is a file-like object that supports read()-ing.
META is the same object as request.META.
content_length is the length of the data in input_data. Don’t\nread more than content_length bytes from input_data.
boundary is the MIME boundary for this request.
encoding is the encoding of the request.
Return None if you want upload handling to continue, or a tuple of\n(POST, FILES) if you want to return the new data structures suitable\nfor the request directly.