當Django處理上傳一個檔案時，檔案資料被放在request.FILES中。
這個文件解釋檔案怎麼樣被儲存在磁碟上或者記憶體中，怎樣定製預設的行為。

一，基本檔案上傳
考慮一個包含FileField的簡單的表單：
 

程式碼示例:
from  django  import  forms
classUploadFileForm(forms.Form):
   title=forms.CharField(max_length=50)
   file=forms.FileField()
 

一個處理這個表單的檢視將在request.FILES中接受檔案資料 ,request.FILES是一個字典,它對每個FileField(或者是ImageField,或者是其他的FileField的子類)都包含一個key.所以 從上面的表單中來的資料將可以通過request.FILES['file']鍵來訪問.
注意request.FILES只有 在request方法是POST並且發出POST請求的

有屬性enctype="multipart/form-data".否則，request。FILES將是空的。

另一個簡單的例子：
 

程式碼示例:
from fdjango.http improt HttpResponseRedirect
from django.shortcuts import render_to_response
from somewhere import handle_uploaded_file
def upload_file(request):
    if request.method == 'post':
        form =  UploadFileForm(rquest.POST,request.FILES)
        if form.is_valid():
            handle_uploaded_file(request.FILES['file'])
            return HttpResponseRedirect('/success/ur/')
   e

lse:
        form = UploadFileForm()
    return render_to_response('upload.html',{'form':form})
 

要注意，必須將request.FILES傳遞到表單的構造器中；這就是檔案資料怎樣和表單沾上邊的 。

二，處理上傳的檔案
最後的難題是怎樣處理從request.FILES中獲得的真實的檔案。
這個字典的每個輸入都是一個UploadedFile物件——一個上傳之後的檔案的簡單的包裝。
通常會使用下面的幾個方法來訪問被上傳的內容：
UploadedFile.read（）：從檔案中讀取整個上傳的資料。小心整個方法：如果這個檔案很大，你把它讀到記憶體中會弄慢你的系統。你可以想要使用chunks（）來代替，看下面；
UploadedFile.multiple_chunks()：如果上傳的檔案足夠大需要分塊就返回真。預設的這個值是2.5兆，當然這個值是可以調節的，看下面的UploadedFile.chunks()：一個產生器，返回檔案的塊。如果multiple_chunks()是真的話，你應該在一個迴圈中使用這個方法，而不是使用read（）；
UploadedFile.name：上傳檔案的名字（比如m_file.txt）
UploadedFile.size：以bytes表示的上傳的檔案的大小。
還有其他的幾個方法和屬性。你可以自己去查。
把他們放在一起，這裡是一個你處理上傳檔案的通常方法：
 

程式碼示例:
def handle_uploaded_file(f):
    destination = open('some/file/name.txt','wb+')
    for chunk in f.chunks():
        destination.write(chunk)
    destination.close()
 

在UploadedFile.chunks()上迴圈而不是用read()保證大檔案不會大量使用你的系統記憶體。

三，上傳的資料存在哪裡？
在你儲存上傳的檔案之前，資料需要被儲存在某些地方。預設呢的，如果一個上傳的檔案小於2.5兆，Django會將上傳的東西放在記憶體裡。這意味著只要從記憶體讀取資料並儲存到硬碟上，所以很快。然而，如果一個上傳的檔案太大，Django將將上傳的檔案寫到一個臨時的檔案中，這個檔案在你的臨時檔案路徑中。在Unix-like的平臺上意味著你可以預見Django產生一個檔案儲存為/tmp/tmpzfp6I6.upload的檔案。如果這個檔案足夠大，你可以觀察到這個檔案的大小在增大。
很多細節--2.5M;/tmp；等 等 都是簡單的看上去合理的預設值。繼續閱讀看看你怎麼樣個性化或者完全替代掉上傳行為。

四，改變上傳處理行為
三個設定改變Django的上傳處理行為：
FILE_UPLOAD_MAX_MEMORY_SIZE:以bytes為單位的到記憶體中的最大大小，。比這個值大的檔案將被先存到磁碟上。預設是2.5兆
FILE_UPLOAD_TEMP_DIR:比FILE_UPLOAD_MAX_MEMORY_SIZE大的檔案將被臨時儲存的地方。預設是系統標準的臨時路徑。
FILE_UPLOAD_PERMISSIONS:如果這個沒有給出或者是None，你將獲得獨立於系統的行為。大多數平臺，臨時檔案有一個0600模式，從記憶體儲存的檔案將使用系統標準umask。
FILE_UPLOAD_HANDLERS：上傳檔案的處理器。改變這個設定允許完全個性化——甚至代替——Django的上傳過程。
預設是：
 

("django.core.files.uploadhandler.MemoryFileUploadHandler",
 "django.core.files.uploadhandler.TemporaryFileUploadHandler",)
 

UploadedFile 物件
class UploadedFile
作為那些重File繼承的補充，素有的UploadedFile物件定義了下面的方法和屬性：
UploadedFile.content_type
檔案的content_type頭（比如text/plain
 orapplication/pdf
）。像使用者提供的任何資料一樣，你不應該信任上傳的資料就是這個型別。你仍然要驗證這個檔案包含這個頭宣告的content-type——“信任但是驗證”。
UploadedFile.charset
對於text/*的content-types，瀏覽器提供的字符集。再次，“信任但是驗證”是最好的策略。
UploadedFile.temporary_file_path()：只有被傳到磁碟上的檔案才有這個方法，它返回臨時上傳檔案的全路徑。
注意：
像通常的Python檔案，你可以迭代上傳的檔案來一行一行得讀取檔案：
 

for line in uploadedfile:
    do_something_with(line)

然而，不同於標準Python檔案，UploadedFile值懂得/n（也被稱為Unix風格）的結尾。如果你知道你需要處理有不同風格結尾的檔案的時候，你要在你的檢視中作出處理。

五，上傳處理控制代碼：
當一個使用者上傳一個檔案，Django敬愛那個這個檔案資料傳遞給上傳處理控制代碼——一個處理隨著檔案上傳處理檔案的小類。上傳處理控制代碼被FILE_UPLOAD_HANDLERS初始化定義，預設是：
 

程式碼示例:

(
"django.core.files.uploadhandler.MemoryFileUploadHandler"
,
 "django.core.files.uploadhandler.TemporaryFileUploadHandler"

,)
 

這兩個提供了Django處理小檔案和大檔案的預設上產行為。
你可以個性化處理控制代碼來個性化Django處理檔案的行為。比如你可以使用個性化的處理控制代碼來強制使用者配額，實時地壓縮資料，渲染進度條，甚至在儲存在本地的同時向另一個儲存地傳送資料。

六，實時修改上傳處理控制代碼
有的時候某些檢視要使用不同的上傳行為。這種情況下，你可以重寫一個上傳處理控制代碼，通過request.upload_handlers來修改。預設的，這個列表包含FILE_UPLOAD_HANDLERS提供的處理控制代碼，但是你可以像修改其他列表一樣修改這個列表。
比如，加入你寫了一個叫做
ProgressBarUploadHandler
 的處理控制代碼。你可以通過下面的形式加到你的上傳處理控制代碼中：
request.upload_handlers.insert（0，ProgressBarUploadHandler（））
你贏使用list.insert()在這種情況下。因為進度條處理控制代碼需要首先執行。記住，處理控制代碼按照順序執行。
如果你像完全代替掉上傳處理控制代碼，你可以賦值一個新的列表：
request.upload_handlers=[ProgressBarUploadHandler()]
注意：你只能在訪問request.POST或者request.FILES之前修改上傳處理控制代碼。——如果上傳處理開始後再改就沒用了。如果你在修改reqeust.uplaod_handlers之前訪問了request.POST
 or request.FILES
 ，Django將丟擲一個錯誤。
所以，在你的檢視中儘早的修改上傳處理控制代碼。

寫自定義的上傳處理控制代碼：

所有的上傳處理控制代碼都應 是 django.core.files.uploadhandler.FileUploadHandler的子類。你可以在任何你需要的地方定義控制代碼。
需要的方法：

自定義的上傳處理控制代碼必須定義一下的方法：
FileUploadHandler.receive_data_chunk(self,raw_data,start)：從檔案上傳中接收塊。

raw_data是已經上傳的位元組流
start是raw_data塊開始的位置

你返回的資料將被傳遞到下一個處理控制代碼的receive_data_chunk方法中。這樣一個處理控制代碼就是另一個的過濾器了。

返回None將阻止後面的處理控制代碼獲得這個塊，當你 自己儲存這個資料，而不想其他處理控制代碼儲存拷貝時很有用。

如果你觸發一個StopUpload或者SkipFile異常，上傳將被放棄或者檔案被完全跳過。
FileUploadHandler.file_complete(self, file_size)

當 檔案上傳完畢時呼叫。

處理控制代碼應該返回一個UploadFile物件，可以儲存在request.FILES中。處理控制代碼也可以返回None來使得UploadFile物件應該來自後來的上傳處理控制代碼。

剩下的就是可選的一些方法實現。
 

FILE_UPLOAD_MAX_MEMORY_SIZE = 209715200
FILE_UPLOAD_MAX_MEMORY_SIZE = 209715200

在你本機先好好測試一下，它是如何佔用記憶體，什麼時候開始存入temp目錄，怎麼遷移到upload目錄底下的

檔案上傳的時候，如果一個上傳的檔案小於2.5兆，Django會將上傳的東西放在記憶體裡，如果上傳的檔案大於2.5M，Django將整個上傳的檔案寫到一個臨時的檔案中,這個檔案在臨時檔案路徑中。上傳完畢後，將呼叫View中的_Upload()方法將臨時資料夾中的臨時檔案分塊寫到上傳檔案的存放路徑下，每塊的大小為64K,寫完後臨時檔案將被刪除。
UploadedFile.multiple_chunks()：如果上傳的檔案足夠大需要分塊就返回真。預設的這個值是2.5兆，當然這個值是可以調節的，看下面的UploadedFile.chunks()：一個產生器，返回檔案的塊。如果multiple_chunks()是真的話，你應該在一個迴圈中使用這個方法，而不是使用read（）；

在你儲存上傳的檔案之前，資料需要被儲存在某些地方。預設呢的，如果一個上傳的檔案小於2.5兆，Django會將上傳的東西放在記憶體裡。這意味著只要從記憶體讀取資料並儲存到硬碟上，所以很快。然而，如果一個上傳的檔案太大，Django將上傳的檔案寫到一個臨時的檔案中，這個檔案在你的臨時檔案路徑中。在Unix-like的平臺上意味著你可以預見Django產生一個檔案儲存為/tmp/tmpzfp6I6.upload的檔案。如果這個檔案足夠大，你可以觀察到這個檔案的大小在增大。

三個設定改變Django的上傳處理行為：
 

FILE_UPLOAD_MAX_MEMORY_SIZE:以bytes為單位的到記憶體中的最大大小，。比這個值大的檔案將被先存到磁碟上。預設是2.5兆
FILE_UPLOAD_TEMP_DIR:比FILE_UPLOAD_MAX_MEMORY_SIZE大的檔案將被臨時儲存的地方。預設是系統標準的臨時路徑。
FILE_UPLOAD_PERMISSIONS:如果這個沒有給出或者是None，你將獲得獨立於系統的行為。

大多數平臺，臨時檔案有一個0600模式，從記憶體儲存的檔案將使用系統標準umask。