Durante las cargas de archivos, los datos del archivo real se almacenan en request.FILES. Cada entrada en este diccionario es un objeto UploadedFile (o una subclase) – un envoltorio alrededor de un archivo subido. Suele utilizar uno de estos métodos para acceder a los contenidos del archivo subido:
Lee toda la data subida desde el archivo. Ten cuidado con este método: si el archivo subido es enorme puede sobrecargar tu sistema si intentas leerlo en memoria. Probablemente querrás usar chunks() en su lugar; véase a continuación.
Returns True si el archivo subido es lo suficientemente grande como para requerir la lectura en múltiples trozos. Por defecto, esto será cualquier archivo mayor que 2,5 megabytes, pero eso está configurable; véase a continuación.
Un generador que devuelve trozos del archivo. Si multiple_chunks() es True, debes utilizar este método en un bucle en lugar de read().
En la práctica, a menudo es más fácil utilizar chunks() todo el tiempo. Buclear sobre chunks() en lugar de utilizar read() garantiza que archivos grandes no sobrecarguen la memoria del sistema.
Aquí hay algunas atributos útiles de UploadedFile:
El nombre del archivo subido (por ejemplo, my_file.txt).
El tamaño, en bytes, del archivo subido.
La cabecera de tipo de contenido subida con el archivo (por ejemplo, text/plain o application/pdf). Al igual que cualquier dato proporcionado por el usuario, no debes confiar en que el archivo subido es realmente este tipo. Todavía necesitarás validar que el archivo contiene el contenido que la cabecera de tipo de contenido afirma – «confía pero verifica».
Un diccionario que contiene parámetros adicionales pasados a la cabecera de tipo de contenido. Esto se proporciona típicamente por servicios, como Google App Engine, que interceptan y manejan las subidas de archivos en su nombre. Como resultado, tu manejador puede no recibir el contenido del archivo subido, sino una URL o otro puntero al archivo (véase RFC 2388).
Para tipos de contenido text/*, el conjunto de caracteres (es decir, utf8) proporcionado por el navegador. Una vez más, «confía pero verifica» es la mejor política aquí.
Nota
Al igual que los archivos regulares de Python, puedes leer el archivo línea a línea mediante iteraciones sobre el archivo subido:
for line in uploadedfile:
do_something_with(line)
Las líneas se dividen utilizando la convención de fin de línea universal universal newlines. Los siguientes son reconocidos como un final de línea: la convención de fin de línea Unix '\n', la convención de Windows '\r\n' y la antigua convención Macintosh '\r'.
Las subclases de UploadedFile incluyen:
Un archivo cargado a una ubicación temporal (es decir, stream-a-disco). Esta clase se utiliza por el TemporaryFileUploadHandler. Además de los métodos desde UploadedFile, tiene un método adicional:
Devuelve la ruta completa al archivo subido temporal.
Un archivo cargado en memoria (es decir, stream-a-memoria). Esta clase se utiliza por el MemoryFileUploadHandler.
Juntos los manejadores de carga de archivos MemoryFileUploadHandler y TemporaryFileUploadHandler proporcionan el comportamiento por defecto de Django para cargar archivos, leyendo pequeños archivos en memoria y grandes en disco. Están ubicados en django.core.files.uploadhandler.
Manejador de carga de archivo para streamear subidas a memoria (usado para pequeños archivos).
Manejador de carga que streamea datos a un archivo temporal utilizando TemporaryUploadedFile.
Los archivos de subida de archivos deben ser clases que hereden de django.core.files.uploadhandler.FileUploadHandler. Puedes definir los manejadores de subida donde desees.
Los manejadores de subida personalizados deben definir los siguientes métodos:
Recibe una «porción» de datos del archivo de subida.
raw_data es un bytestring que contiene los datos cargados.
start es la posición en el archivo donde comienza esta porción raw_data.
Los datos que devuelvas se alimentarán a los métodos posteriores de los manejadores de subida receive_data_chunk. De esta manera, un manejador puede ser un «filtro» para otros manejadores.
Devuelve None desde receive_data_chunk para cortocircuitar a los manejadores restantes de obtener esta porción. Esto es útil si estás almacenando los datos cargados tú mismo y no quieres que futuros manejadores almacenen una copia de los datos.
Si levantas una excepción StopUpload o SkipFile, la subida se abortará o el archivo se saltará completamente.
Se llama cuando un archivo ha terminado de cargarse.
El handler debe devolver un objeto UploadedFile que se almacenará en request.FILES. Los handlers también pueden devolver None para indicar que el objeto UploadedFile proviene de los siguientes handlers de carga.
Los handlers de carga personalizados también pueden definir cualquier de los siguientes métodos o atributos opcionales:
Tamaño, en bytes, de las «partes» que Django debe almacenar en memoria y alimentar al handler. Es decir, este atributo controla el tamaño de las partes alimentadas a FileUploadHandler.receive_data_chunk.
Para una máxima rendimiento los tamaños de parte deben ser divisibles por 4 y no superar 2 GB (231 bytes) en tamaño. Cuando hay múltiples tamaños de partes proporcionados por múltiples handlers, Django utilizará el tamaño de parte más pequeño definido por cualquier handler.
El valor predeterminado es 64*210 bytes, o 64 KB.
Llamada a un callback que indica que una nueva carga de archivo está comenzando. Esta se llama antes de que se haya alimentado ningún dato a cualquier handler de carga.
field_name es el nombre de cadena del campo <input> de archivo.
file_name es el nombre de archivo proporcionado por el navegador.
content_type es el tipo MIME proporcionado por el navegador – E.g. 'image/jpeg'.
La longitud de la imagen dada por el navegador es content_length. A veces, esto no se proporciona y será None.
El conjunto de caracteres (por ejemplo, utf8) dado por el navegador es charset. Al igual que content_length, a veces no se proporciona.
La información extra sobre el archivo desde la cabecera content-type es content_type_extra. Consulte UploadedFile.content_type_extra.
Esta función puede levantar una excepción StopFutureHandlers para evitar que los futuros maneadores traten este archivo.
Señalización de llamada de retorno que indica que la subida (todos los archivos) ha completado.
Señalización de llamada de retorno que indica que la subida fue interrumpida, por ejemplo, cuando el usuario cerró su navegador durante la subida de archivo.
Permite al maneador sobrescribir completamente la interpretación del input HTTP bruto.
input_data es un objeto tipo archivo que admite read()-ing.
META es el mismo objeto que request.META.
La longitud de los datos en input_data es content_length. No leas más de content_length bytes de input_data.
límite es el límite MIME para esta solicitud.
codificación es la codificación de la solicitud.
Devuelve None si deseas que se continúe con el manejo de subidas, o una tupla de (POST, FILES) si deseas devolver las nuevas estructuras de datos adecuadas para la solicitud directamente.
may 31, 2026