Documentos · PDF Kit de ferramentas
Como uma guia do navegador lê e reescreve um PDF sem carregá-lo
· Como funciona
pdf privacidade trabalhadores da web
'Executar no seu navegador' é uma afirmação que você pode entender e testar. Esta postagem segue um PDF do seletor de arquivos para a memória, por meio de um Web Worker, e retorna como um download, explicando o que cada etapa faz e por que nenhum servidor está envolvido.
O seletor de arquivos não é um upload — o momento de confusão ao escolher um arquivo é como enviá-lo
Um seletor de arquivos se assemelha a um controle de upload porque muitos sites enviam o arquivo escolhido imediatamente. A seleção por si só não exige essa transferência. Neste kit de ferramentas, o navegador concede à página acesso ao objeto Arquivo selecionado pelo usuário e o controlador valida seu tipo e tamanho antes de ler PDF bytes na memória da guia.
O limite é observável: a escolha de um documento altera o estado da interface local, exibe seu nome, tamanho e contagem de páginas e habilita a operação. Ele não publica o arquivo em um endpoint do aplicativo. O limite PDF é 50 MB e o limite da imagem é 30 MB, aplicado antes do início do processamento caro.
Do disco para a memória - como o arquivo API entrega à página uma matriz de bytes que o próprio JavaScript do site pode ler
Para PDFs, `arrayBuffer()` fornece bytes e `Uint8Array` os retém para chamadas de trabalho. Os lotes de imagens são tratados de maneira diferente para evitar uma segunda leitura desnecessária: os objetos Arquivo brutos são retidos até a preparação da imagem do navegador. Estas são operações de memória dentro do contexto atual do navegador, não de armazenamento remoto ou histórico da conta.
O primeiro PDF é inspecionado por meio de uma chamada `info` no trabalhador para que um documento grande não bloqueie a pintura enquanto a contagem de páginas é determinada. A guia pode armazenar temporariamente bytes de origem, estado do analisador, ativos preparados e saída eventual juntos. Limpar ou encerrar é importante porque o processamento local ainda consome recursos reais do dispositivo.
A maioria das transformações PDF usa o trabalhador do kit de ferramentas; A análise de PDF e a codificação de tela têm uma divisão separada
Mesclar, dividir, extrair, excluir, reordenar, girar, colocar marca d'água e chamar a montagem da imagem final para PDF pdf-lib por meio do trabalhador de módulo dedicado. As mensagens de progresso e cancelamento ultrapassam esse limite enquanto o trabalho computacional fica longe do thread da interface primária. A limpeza dos arquivos encerra o trabalho em vez de aguardar a coleta de lixo.
PDF-to-image é a exceção importante. pdf.js usa seu próprio trabalhador para análise, mas a codificação da tela do navegador deve permanecer no thread principal. O renderizador cede entre as páginas para que os controles e o progresso possam ser redesenhados. Dizer que cada transformação é executada inteiramente em um trabalhador contradiria a implementação enviada.
A análise e a gravação são etapas locais, mas a preparação da imagem e a codificação da tela podem ser executadas no thread principal
O pipeline geral é lido, interpretado, transformado e codificado, mas cada operação escolhe seu próprio maquinário concreto. As operações de cópia de página solicitam ao pdf-lib a criação de um novo documento. A rotação altera os metadados aditivos da página. Marcas d'água anexam desenhos. PDF-to-image renderiza páginas, enquanto images-to-PDF prepara imagens decodificadas pelo navegador antes da montagem do trabalhador.
Essas distinções afetam a fidelidade. A cópia de páginas mantém o conteúdo selecionável; renderizá-los para PNG ou JPEG transforma a página em pixels e perde sua camada de texto. Imagens não PNG/JPEG podem ser decodificadas e recodificadas como PNG antes da montagem PDF. “Local” descreve a movimentação de dados, não um algoritmo de transformação universal.
O download é um objeto local — como um Blob e um objeto URL fornecem um arquivo que nunca existiu em nenhum servidor
Cada operação retorna bytes ou um ZIP que a interface envolve em um Blob com o tipo de mídia apropriado. A ação resultante chama o auxiliar `downloadBlob` compartilhado, que cria o download do navegador em vez de navegar até um arquivo do servidor. O artefato gerado existia na memória antes de o usuário salvá-lo no armazenamento normal do dispositivo.
As miniaturas do organizador também usam URLs de objetos Blob, mas seu ciclo de vida é explícito: URLs antigos são revogados antes de um novo carregamento e todos são revogados na destruição ou limpeza. Essa distinção evita que uma reivindicação de privacidade local oculte um vazamento de memória. Depois de baixado, o arquivo segue as regras comuns de backup e compartilhamento do dispositivo.
Por que o limite é a memória do seu dispositivo - o original, a estrutura analisada e a cópia reescrita, todos armazenados em RAM de uma só vez
O trabalho local é limitado por RAM e políticas do navegador, bem como limites de entrada explícitos. Um PDF pode existir simultaneamente como bytes de origem, um modelo de objeto analisado, buffers de trabalho transferidos, visualizações e saída serializada. As páginas raster adicionam telas grandes, de modo que o renderizador mede um orçamento de pixels e pode reduzir a escala antes da alocação.
Um telefone pode ter problemas mais cedo do que um desktop, mesmo abaixo de 50 MB porque o tamanho do arquivo compactado diz pouco sobre as imagens decodificadas da página. Feche guias não relacionadas, processe menos páginas ou use um dispositivo maior para trabalhos exigentes. O limite máximo permanece 50 MB por PDF e 30 MB por imagem; a memória não é uma desculpa para reivindicar nenhum limite fixo.
Outros produtos ToolAcre podem usar a rede; a análise de produção consentida também é separada
O repositório afirma que dois outros produtos ToolAcre entram em contato com a rede por design, portanto, o comportamento local deve ser verificado por produto, em vez de generalizado em todo o site. O código de operação PDF não possui endpoint que transporta documentos e um teste de isolamento automatizado verifica essa invariante durante o processamento.
A análise de todo o site só pode ser executada no host de produção canônico após consentimento. Sua lista de permissões de eventos ToolAcre exclui nomes de arquivos, conteúdos, texto colado, URLs e tamanhos exatos de arquivos, enquanto os scripts do Google permanecem códigos de terceiros descritos pela política de privacidade. Solicitações estáticas de ativos ou análises são distintas de um upload de documento.
Conclusão: cada etapa acontece no seu dispositivo, e a página do PDF Toolkit e o painel Rede permitem que você confirme
O ciclo de vida completo é visível: escolha um arquivo, valide e leia-o, transforme-o localmente com o trabalhador apropriado ou caminho de renderização, envolva a saída em um Blob, baixe-o e, em seguida, limpe buffers e URLs de objetos. Nenhum servidor de aplicativos é necessário para executar essas operações de página.
Trate “no navegador” como uma arquitetura que você pode inspecionar, em vez de um slogan. Observe as solicitações, leia a nota específica da operação e use Limpar arquivos e liberar memória quando terminar. Esse controle libera imagens do organizador, elimina referências e encerra o trabalhador, reduzindo a pressão da memória e o tempo de vida do material confidencial do documento na guia. Baixe primeiro, verifique o arquivo salvo e só depois limpe; o processamento local intencionalmente não fornece nenhum substituto remoto para um resultado descartado muito cedo.