uploads.txt 8.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244
  1. ==================================
  2. Uploaded Files and Upload Handlers
  3. ==================================
  4. .. module:: django.core.files.uploadedfile
  5. :synopsis: Classes representing uploaded files.
  6. Uploaded files
  7. ==============
  8. .. class:: UploadedFile
  9. During file uploads, the actual file data is stored in :attr:`request.FILES
  10. <django.http.HttpRequest.FILES>`. Each entry in this dictionary is an
  11. ``UploadedFile`` object (or a subclass) -- a simple wrapper around an uploaded
  12. file. You'll usually use one of these methods to access the uploaded content:
  13. .. method:: UploadedFile.read()
  14. Read the entire uploaded data from the file. Be careful with this method:
  15. if the uploaded file is huge it can overwhelm your system if you try to
  16. read it into memory. You'll probably want to use ``chunks()`` instead; see
  17. below.
  18. .. method:: UploadedFile.multiple_chunks(chunk_size=None)
  19. Returns ``True`` if the uploaded file is big enough to require reading in
  20. multiple chunks. By default this will be any file larger than 2.5 megabytes,
  21. but that's configurable; see below.
  22. .. method:: UploadedFile.chunks(chunk_size=None)
  23. A generator returning chunks of the file. If ``multiple_chunks()`` is
  24. ``True``, you should use this method in a loop instead of ``read()``.
  25. In practice, it's often easiest simply to use ``chunks()`` all the time.
  26. Looping over ``chunks()`` instead of using ``read()`` ensures that large
  27. files don't overwhelm your system's memory.
  28. Here are some useful attributes of ``UploadedFile``:
  29. .. attribute:: UploadedFile.name
  30. The name of the uploaded file (e.g. ``my_file.txt``).
  31. .. attribute:: UploadedFile.size
  32. The size, in bytes, of the uploaded file.
  33. .. attribute:: UploadedFile.content_type
  34. The content-type header uploaded with the file (e.g. :mimetype:`text/plain`
  35. or :mimetype:`application/pdf`). Like any data supplied by the user, you
  36. shouldn't trust that the uploaded file is actually this type. You'll still
  37. need to validate that the file contains the content that the content-type
  38. header claims -- "trust but verify."
  39. .. attribute:: UploadedFile.content_type_extra
  40. .. versionadded:: 1.7
  41. A dictionary containing extra parameters passed to the ``content-type``
  42. header. This is typically provided by services, such as Google App Engine,
  43. that intercept and handle file uploads on your behalf. As a result your
  44. handler may not receive the uploaded file content, but instead a URL or
  45. other pointer to the file. (see `RFC 2388`_ section 5.3).
  46. .. _RFC 2388: http://www.ietf.org/rfc/rfc2388.txt
  47. .. attribute:: UploadedFile.charset
  48. For :mimetype:`text/*` content-types, the character set (i.e. ``utf8``)
  49. supplied by the browser. Again, "trust but verify" is the best policy here.
  50. .. note::
  51. Like regular Python files, you can read the file line-by-line simply by
  52. iterating over the uploaded file:
  53. .. code-block:: python
  54. for line in uploadedfile:
  55. do_something_with(line)
  56. However, *unlike* standard Python files, :class:`UploadedFile` only
  57. understands ``\n`` (also known as "Unix-style") line endings. If you know
  58. that you need to handle uploaded files with different line endings, you'll
  59. need to do so in your view.
  60. Subclasses of ``UploadedFile`` include:
  61. .. class:: TemporaryUploadedFile
  62. A file uploaded to a temporary location (i.e. stream-to-disk). This class
  63. is used by the
  64. :class:`~django.core.files.uploadhandler.TemporaryFileUploadHandler`. In
  65. addition to the methods from :class:`UploadedFile`, it has one additional
  66. method:
  67. .. method:: TemporaryUploadedFile.temporary_file_path()
  68. Returns the full path to the temporary uploaded file.
  69. .. class:: InMemoryUploadedFile
  70. A file uploaded into memory (i.e. stream-to-memory). This class is used
  71. by the :class:`~django.core.files.uploadhandler.MemoryFileUploadHandler`.
  72. Built-in upload handers
  73. =======================
  74. .. module:: django.core.files.uploadhandler
  75. :synopsis: Django's handlers for file uploads.
  76. Together the :class:`MemoryFileUploadHandler` and
  77. :class:`TemporaryFileUploadHandler` provide Django's default file upload
  78. behavior of reading small files into memory and large ones onto disk. They
  79. are located in ``django.core.files.uploadhandler``.
  80. .. class:: MemoryFileUploadHandler
  81. File upload handler to stream uploads into memory (used for small files).
  82. .. class:: TemporaryFileUploadHandler
  83. Upload handler that streams data into a temporary file using
  84. :class:`~django.core.files.uploadedfile.TemporaryUploadedFile`.
  85. .. _custom_upload_handlers:
  86. Writing custom upload handlers
  87. ==============================
  88. .. class:: FileUploadHandler
  89. All file upload handlers should be subclasses of
  90. ``django.core.files.uploadhandler.FileUploadHandler``. You can define upload
  91. handlers wherever you wish.
  92. Required methods
  93. ~~~~~~~~~~~~~~~~
  94. Custom file upload handlers **must** define the following methods:
  95. .. method:: FileUploadHandler.receive_data_chunk(raw_data, start)
  96. Receives a "chunk" of data from the file upload.
  97. ``raw_data`` is a byte string containing the uploaded data.
  98. ``start`` is the position in the file where this ``raw_data`` chunk
  99. begins.
  100. The data you return will get fed into the subsequent upload handlers'
  101. ``receive_data_chunk`` methods. In this way, one handler can be a
  102. "filter" for other handlers.
  103. Return ``None`` from ``receive_data_chunk`` to short-circuit remaining
  104. upload handlers from getting this chunk. This is useful if you're
  105. storing the uploaded data yourself and don't want future handlers to
  106. store a copy of the data.
  107. If you raise a ``StopUpload`` or a ``SkipFile`` exception, the upload
  108. will abort or the file will be completely skipped.
  109. .. method:: FileUploadHandler.file_complete(file_size)
  110. Called when a file has finished uploading.
  111. The handler should return an ``UploadedFile`` object that will be stored
  112. in ``request.FILES``. Handlers may also return ``None`` to indicate that
  113. the ``UploadedFile`` object should come from subsequent upload handlers.
  114. Optional methods
  115. ~~~~~~~~~~~~~~~~
  116. Custom upload handlers may also define any of the following optional methods or
  117. attributes:
  118. .. attribute:: FileUploadHandler.chunk_size
  119. Size, in bytes, of the "chunks" Django should store into memory and feed
  120. into the handler. That is, this attribute controls the size of chunks
  121. fed into ``FileUploadHandler.receive_data_chunk``.
  122. For maximum performance the chunk sizes should be divisible by ``4`` and
  123. should not exceed 2 GB (2\ :sup:`31` bytes) in size. When there are
  124. multiple chunk sizes provided by multiple handlers, Django will use the
  125. smallest chunk size defined by any handler.
  126. The default is 64*2\ :sup:`10` bytes, or 64 KB.
  127. .. method:: FileUploadHandler.new_file(field_name, file_name, content_type, content_length, charset, content_type_extra)
  128. Callback signaling that a new file upload is starting. This is called
  129. before any data has been fed to any upload handlers.
  130. ``field_name`` is a string name of the file ``<input>`` field.
  131. ``file_name`` is the unicode filename that was provided by the browser.
  132. ``content_type`` is the MIME type provided by the browser -- E.g.
  133. ``'image/jpeg'``.
  134. ``content_length`` is the length of the image given by the browser.
  135. Sometimes this won't be provided and will be ``None``.
  136. ``charset`` is the character set (i.e. ``utf8``) given by the browser.
  137. Like ``content_length``, this sometimes won't be provided.
  138. ``content_type_extra`` is extra information about the file from the
  139. ``content-type`` header. See :attr:`UploadedFile.content_type_extra
  140. <django.core.files.uploadedfile.UploadedFile.content_type_extra>`.
  141. This method may raise a ``StopFutureHandlers`` exception to prevent
  142. future handlers from handling this file.
  143. .. versionadded:: 1.7
  144. The ``content_type_extra`` parameter was added.
  145. .. method:: FileUploadHandler.upload_complete()
  146. Callback signaling that the entire upload (all files) has completed.
  147. .. method:: FileUploadHandler.handle_raw_input(input_data, META, content_length, boundary, encoding)
  148. Allows the handler to completely override the parsing of the raw
  149. HTTP input.
  150. ``input_data`` is a file-like object that supports ``read()``-ing.
  151. ``META`` is the same object as ``request.META``.
  152. ``content_length`` is the length of the data in ``input_data``. Don't
  153. read more than ``content_length`` bytes from ``input_data``.
  154. ``boundary`` is the MIME boundary for this request.
  155. ``encoding`` is the encoding of the request.
  156. Return ``None`` if you want upload handling to continue, or a tuple of
  157. ``(POST, FILES)`` if you want to return the new data structures suitable
  158. for the request directly.