Summary

  • El primer borrador público de la File API del W3C, fechado el 17 de noviembre de 2009, describió archivos seleccionados por la persona como objetos que un script podía leer mediante FileReader.
  • Los borradores de 2013 y 2015 desarrollaron FileList, Blob, lectura asíncrona y URL de blob. Previsualizar un archivo elegido dentro de la página y enviarlo al servidor eran decisiones separadas.

El empleado de una tienda de fotografía recibe una imagen para imprimir. Examina esa imagen, no abre todos los cajones de la casa del cliente buscando otras. En el navegador, una página necesitaba una forma igual de precisa para tratar un archivo local. Antes podía existir un formulario de subida, claro; la pregunta nueva era cómo convertir el archivo escogido en algo con lo que un programa web pudiera trabajar sin confundir selección con acceso general al ordenador.

El primer borrador público del W3C, del 17 de noviembre de 2009, empezaba por los archivos elegidos individualmente. FileList reunía esa selección, que podía salir del conocido <input type="file">. File llevaba información como nombre y tipo; Blob representaba los datos binarios y permitía trabajar con fragmentos. FileReader leía el contenido y avisaba de lo que ocurría mediante eventos. El sitio recibía una pieza manejable de información, no un inventario de los cajones vecinos.

La diferencia se notaba antes de pulsar «enviar». Un formulario clásico podía remitir la foto a un servidor para descubrir allí que el usuario había escogido la imagen equivocada. El lector de archivos permitía mostrarla primero en la página. El borrador de 2009 enumeraba readAsBinaryString, readAsText y readAsDataURL como métodos asíncronos. Los nombres parecen una lista de taller, pero ampliaban la tarea de la web: leer texto, manejar datos y construir una vista previa sin que el primer paso tuviera que ser un viaje por la red.

Los ejemplos del mismo borrador iban mucho más allá de la fotografía. Un visor de letras de canciones podía abrir un archivo de lista musical y ordenarlo dentro de la aplicación. Un calendario podía leer un archivo local, combinar citas y ofrecer luego una sincronización. En ambas escenas, el archivo es material para trabajar, no una maleta cuyo único destino es el servidor. La web empezaba a hacer trabajo útil al lado del usuario.

El punto de entrada importaba tanto como el lector. La sección de seguridad de 2009 suponía que los archivos leídos mediante FileReader habían sido seleccionados antes por la persona. Consideraba un selector insistente que volviera a abrirse hasta obtener una respuesta, archivos sensibles del sistema que debían quedar fuera y archivos modificados después de ser elegidos. La idea de «elegir un archivo» requería reglas para un entorno vivo: el contenido puede moverse, cambiar o quedar inaccesible, y el navegador tiene que responder a esas situaciones.

El borrador Last Call de 12 de septiembre de 2013 organizó mejor las piezas. FileList contenía los objetos seleccionados. Blob era una secuencia de datos inmutable que podía cortarse en porciones. File añadía nombre y fecha de modificación. FileReader ofrecía lectura asíncrona con progreso, finalización y error. El propio documento mostraba un archivo leído como texto mientras la interfaz actualizaba una barra. Si una unidad montada respondía despacio, la página podía explicarle al usuario qué estaba pasando, en lugar de mirar al techo.

Después aparecía el problema favorito de la web: casi todo quiere tener una URL. Un archivo elegido es un objeto local, pero una imagen en una página espera una dirección para mostrarse. Los borradores describieron URL de blob como puente. El texto de 21 de abril de 2015 enseñaba a crear una referencia con URL.createObjectURL() y a retirarla con URL.revokeObjectURL() cuando la vista previa terminaba. También explicaba que las referencias olvidadas podían acumularse. La pequeña URL era una ficha temporal del mostrador, no la nueva dirección pública de la foto.

Hay un detalle que resume la economía de información del diseño. El File.name de 2015 daba el nombre del archivo, sin la ruta de las carpetas que lo contenían. Una página puede enseñar «foto.jpg» al lado de la miniatura sin conocer toda la jerarquía del ordenador. El mismo borrador describía URL de blob ligadas al origen y fallos para solicitudes desde otro origen. El objeto escogido resultaba útil porque se podía nombrar y leer; su utilidad no exigía que la página conociera cada pasillo del archivador.

La historia de publicaciones del W3C sitúa el primer borrador público en 2009, el Last Call en 2013 y otra versión de trabajo en 2015. Esa secuencia importa: cada texto explica una etapa del contrato, y ninguno convierte por sí solo el botón del archivo en una garantía sobre lo que el sitio hará después. Una aplicación que recibe los datos puede transformarlos en la página o enviarlos más tarde por otros medios. La elección inicial y la transmisión son dos decisiones que merecen verse por separado.

El resultado fue una web menos torpe. La foto equivocada podía detectarse antes de subirla. Una hoja de cálculo podía examinarse y resumirse en el navegador. Un texto podía leerse sin obligar al usuario a mandar primero una copia a un servidor. El sitio conservaba poder sobre los bytes que recibía, pero el primer intercambio quedaba definido: una persona eligió este archivo, el navegador lo convirtió en objeto legible y la página debía hacer explícito su siguiente movimiento. El archivador no era parte del encargo.