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.
全てのファイルアップロードハンドラは、django.core.files.uploadhandler.FileUploadHandler のサブクラスとなります。アップロードハンドラはいつでも好きなときに定義できます。
カスタマイズされたファイルアップロードハンドラでは、以下のメソッドを定義する 必要があります。
\nファイルアップロードから、データの "chunk" を受け取ります。
\nraw_data は、アップロードされたデータを含むバイト文字列です。
start はこの raw_data チャンクが始まる、ファイル内での位置です。
あなたが返すデータは、その後のアップロードハンドラの receive_data_chunk メソッドに渡されます。 この方法で、1 つのハンドラは他のハンドラの「フィルタ」になることができます。
receive_data_chunk から None を返し、残りのアップロードハンドラがこのチャンクを取得するのを短絡します。 これは、アップロードしたデータを自分で保存しておき、将来のハンドラでデータのコピーを保存したくない場合に便利です。
StopUpload または SkipFile 例外を発生させると、アップロードが中止されるか、ファイルが完全にスキップされます。
ファイルのアップロードが完了したときに呼ばれます。
\nハンドラは request.FILES に格納される UploadedFile オブジェクトを返します。 ハンドラは Upload`File オブジェクトが後続のアップロードハンドラから来るべきであることを示すために None を返すかもしれません。
独自のアップロードハンドラは、以下の省略可能なメソッドや属性を定義することができます:
\nDjango がメモリに格納してハンドラに送り込む "chunks" のサイズです (byte で表されます)。 つまり、この属性は FileUploadHandler.receive_data_chunk に渡されるチャンクのサイズをコントロールします。
パフォーマンスを最大限にするために、チャンクサイズは 4 で割り切れる必要があり、2 GB (231 bytes) を超えてはいけません。 複数のハンドラによってチャンクサイズが複数ある場合、Django はハンドラで定義された最小のチャンクサイズを使用します。
デフォルトは 64*210 bytes、つまり 64 KB です。
\n新しいファイルのアップロード開始を通知するコールバックです。 アップロードハンドラにデータが送られる前に呼び出されます。
\nfield_name は、ファイル <input> フィールドの文字列名です。
file_name は、ブラウザによって提供されるユニコードのファイル名です。
content_type は、ブラウザによって提供される MIME タイプです -- 例: 'image/jpeg'。
content_length は、ブラウザによって与えられる画像の長さです。提供されずに None となることがあります。
charset は、ブラウザによって与えられる文字セットです (例: utf8)。content_length のように、提供されないことがあります。
content_type_extra は、content-type からの、ファイルについての追加情報です。UploadedFile.content_type_extra をご覧ください。
このメソッドは、将来のハンドラがこのファイルをハンドリングするのを防ぐため、StopFutureHandlers 例外を投げます。
全てのアップロード (全てのファイル) が完了したことを通知するコールバックです。
\nハンドラに対して、生の HTTP インプットのパースを完全にオーバーライドできるようにします。
\ninput_data は、read() をサポートするファイルのようなオブジェクトです。
META は、request.META と同じオブジェクトです。
content_length は、input_data 内のデータの長さです。input_data` から ``content_length バイト以上を読み出さないでください。
boundary は、このリクエストの MIME
encoding は、リクエストのエンコーディングです。
アップロードハンドリングを継続したいとき、None を返します。もしくはリクエストに適した新しいデータ構造を直接返したいとき、 (POST, FILES) のタプルを返します。