💔 Archivos rotos
Archivos corrompidos intencionalmente para verificar manejo de errores. Úsalos para probar validación y errores.
Un archivo PNG con la cabecera corrupta
PNG / 10 KB
Un archivo PNG truncado a medias
PNG / 30 B
Un archivo PDF con la cabecera corrupta
PDF / 10 KB
Un archivo PDF truncado a medias
PDF / 40 B
Un archivo ZIP corrupto
ZIP / 10 KB
Un archivo JSON con un error de sintaxis
JSON / 36 B
Un archivo CSV con filas de distinto número de columnas
CSV / 231 B
Por qué importan las pruebas con archivos rotos
En producción, los archivos pueden llegar dañados por fallos de red o errores de transferencia. Usuarios maliciosos también pueden subir archivos con extensiones falsificadas.
Usa estos archivos para probar que tu aplicación detecta y gestiona errores correctamente — sin caer y devolviendo mensajes claros.
📖 Dónde se suele tropezar
Archivos rotos a proposito: truncados a medias, con la cabecera corrupta, sintacticamente invalidos, con recuentos de columnas que no cuadran. Lo que ejercitan es tu manejo de errores, no tu seguridad. Estas son las formas que adopta la corrupcion por accidente, que no es lo mismo que un fichero fabricado por un atacante.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Lanza una excepcion y al usuario no se le dice nada | Un try / catch demasiado amplio se la traga y devuelve un resultado vacio o un 500 pelado. El log no suele decir mas que que algo fallo. |
Dile al usuario que archivo, que linea y que fallo. Pasa un archivo roto y mira la pantalla de verdad: juzgala por si alguien podria actuar con lo que dice. |
| Un archivo truncado pasa la comprobacion de tamano | Cualquier cosa por debajo del tope pasa. Nadie mira el otro extremo, asi que archivos de cero bytes o de unas decenas se guardan igual. | Pon tambien un minimo. Y comprueba el terminador del formato: un PDF deberia acabar en %%EOF y un ZIP con un End of Central Directory (50 4B 05 06); su ausencia delata el truncamiento. |
| Se comprueba la cabecera y se confia en el cuerpo | Unos magic bytes correctos no dicen nada de lo que viene despues. Los archivos header-corrupted de aqui son la imagen inversa: el cuerpo se lee y solo los primeros bytes estan mal. |
Valida donde realmente lees el archivo, no solo en la puerta. Decodificar de verdad una imagen, o listar un ZIP, es lo que lo zanja. |
| Un CSV con columnas descuadradas pasa en silencio | La mayoria de los parsers CSV devuelven un array por fila y no comprueban que los anchos coincidan. Las columnas que faltan quedan en null y se guardan asi. |
Toma la fila de cabecera como referencia y rechaza fila a fila indicando el numero de linea. Si el problema son delimitadores o comillas, pasar antes el fichero por el limpiador de CSV es mas rapido. |
Lo que se modela aqui es corrupcion accidental. Las entradas deliberadamente hostiles — bombas zip, XML anidado hasta el absurdo, un archivo inocente que se expande a gigabytes — no estan incluidas y exigen topes de tamano y profundidad aplicados antes de expandir nada.