Summary

  • O W3C publicou o primeiro Working Draft público da File API em 17 de novembro de 2009. Ele descrevia arquivos selecionados pela pessoa, FileList e leitura programática por FileReader.
  • Os rascunhos de 2013 e 2015 detalharam Blob, leitura assíncrona e URLs de blob. Uma página podia examinar o arquivo localmente; transmiti-lo depois era outra ação do aplicativo.

O botão de escolher arquivo é quase invisível de tão comum. Aperta-se, aponta-se uma foto, fecha-se a janela. Por trás desse ritual existe uma pergunta difícil: como a página recebe material suficiente para trabalhar sem ganhar a tarefa de andar pelas pastas da pessoa? Um formulário já podia mandar o arquivo a um servidor. A novidade da File API era transformar o item escolhido em um objeto que o código da página pudesse usar antes desse envio.

O primeiro Working Draft público, de 17 de novembro de 2009, partia de arquivos escolhidos individualmente. O campo <input type="file"> podia chamar a seleção; FileList agrupava o resultado. Um objeto File trazia nome e tipo, enquanto Blob representava bytes e partes deles. FileReader lia o conteúdo e avisava sobre o andamento por eventos. O navegador entregava ao site uma unidade de trabalho definida. As outras gavetas não faziam parte da encomenda.

Isso deu um novo primeiro ato à velha história do upload. Se a pessoa escolhesse a foto errada, a página poderia mostrá-la antes que o servidor recebesse a cópia. O texto de 2009 listava readAsBinaryString, readAsText e readAsDataURL como métodos assíncronos. Texto podia ser lido e imagem podia aparecer numa prévia; o usuário ganhava tempo para perceber o engano. O envio continuava possível, agora depois de um exame que a página podia realizar no próprio navegador.

Os casos de uso daquele documento ajudam a perceber o alcance. Um visualizador de letras de música poderia abrir uma lista escolhida e organizá-la na página. Um calendário poderia ler um arquivo local, juntar eventos e só depois oferecer sincronização. O arquivo deixava de ser apenas um pacote a despachar. Virava matéria-prima para uma aplicação que precisava conhecer o que a pessoa lhe havia dado.

O ponto sensível estava na escolha. A discussão de segurança de 2009 supunha que os arquivos lidos por FileReader tinham sido selecionados antes pelo usuário. Citava ataques que repetem o seletor até arrancar uma escolha, arquivos sensíveis do sistema e mudanças no disco entre selecionar e ler. São problemas de balcão, não de decoração: o arquivo local tem uma vida fora da página, pode mudar e às vezes deve ser recusado pelo navegador. O objeto da API precisava conviver com esse mundo sem fingir que todo arquivo era uma string congelada.

O Last Call Working Draft de 12 de setembro de 2013 distribuiu melhor as funções. FileList representava os selecionados; Blob guardava dados brutos imutáveis e admitia fatias; File acrescentava nome e informações de modificação; FileReader lia de modo assíncrono, emitindo progresso, conclusão e erro. Um exemplo lia como texto o arquivo escolhido e atualizava uma barra. Se a unidade fosse lenta, o site podia dizer que ainda estava trabalhando, em vez de deixar a pessoa encarando uma tela parada.

Faltava reconciliar o arquivo local com um hábito antigo da web: imagens normalmente aparecem por meio de URLs. Os rascunhos descreveram URLs de blob como referências para dados binários mantidos pelo navegador. O Working Draft de 21 de abril de 2015 mostrou URL.createObjectURL() alimentando uma prévia e URL.revokeObjectURL() retirando a referência quando ela já não era necessária. O texto alertava que esquecer referências podia causar vazamentos. Uma etiqueta de retirada serve para buscar a foto no balcão; ninguém deve tratá-la como endereço permanente do álbum.

Outro pormenor de 2015 revela o tamanho pensado para a entrega. File.name devolvia o nome do arquivo sem o caminho das pastas onde ele vivia. A página precisava mostrar “foto.jpg”, não desenhar o mapa da casa digital do usuário. O rascunho também descrevia URLs de blob vinculadas à origem e falha para pedidos de outra origem. O serviço ganhava um meio prático de usar a peça recebida sem que o caminho completo até ela virasse parte da conversa.

A história de publicações do W3C marca 2009 como o primeiro rascunho público da File API, 2013 como Last Call e 2015 como mais um Working Draft. Essa cronologia importa porque a ferramenta foi sendo especificada, não apareceu pronta num único lançamento. Também deixa claro o limite da cena: a API entrega bytes ao script; o aplicativo pode trabalhar com eles na página ou copiá-los para um servidor por outro mecanismo. A escolha inicial e a transmissão não são sinônimos.

Com a nova bancada, uma foto podia ser conferida antes do envio. Um calendário podia ser comparado com outro. Um documento grande podia mostrar progresso e permitir tratar um erro de leitura. O ganho era prosaico e enorme: o navegador sabia qual peça a pessoa tinha entregue, e a página podia trabalhar nela. O atendente ganhou ferramentas para cuidar da foto; não ganhou as chaves de todas as gavetas.