Documenti · PDF Toolkit
Come una scheda del browser legge e riscrive un PDF senza caricarlo
· Come funziona
pdf privacy lavoratori del web
"Viene eseguito nel tuo browser" è un'affermazione che puoi comprendere e testare. Questo post segue un PDF dal selettore file in memoria, tramite un Web Worker e di nuovo fuori come download, spiegando cosa fa ogni passaggio e perché non è coinvolto alcun server.
Il selettore file non è un caricamento: il momento di confusione quando si sceglie un file sembra come inviarlo
Un selettore di file assomiglia a un controllo di caricamento perché molti siti inviano immediatamente il file scelto. La sola selezione non richiede tale trasferimento. In questo toolkit, il browser concede alla pagina l'accesso all'oggetto File selezionato dall'utente e il controller ne convalida il tipo e la dimensione prima di leggere PDF byte nella memoria della scheda.
Il confine è osservabile: la scelta di un documento modifica lo stato dell'interfaccia locale, ne visualizza il nome, le dimensioni e il numero di pagine e abilita l'operazione. Non invia il file a un endpoint dell'applicazione. Il limite per PDF è 50 MB e il limite per immagini è 30 MB, applicato prima che inizi la costosa elaborazione.
Dal disco alla memoria: come il file API consegna alla pagina un array di byte che il sito JavaScript può leggere
Per i PDF, `arrayBuffer()` fornisce byte e `Uint8Array` li conserva per le chiamate dei lavoratori. I batch di immagini vengono gestiti in modo diverso per evitare una seconda lettura non necessaria: gli oggetti File non elaborati vengono conservati fino alla preparazione dell'immagine nel browser. Si tratta di operazioni di memoria all'interno del contesto corrente del browser, non di archiviazione remota o cronologia dell'account.
Il primo PDF viene ispezionato tramite una chiamata `info` nel lavoratore in modo che un documento di grandi dimensioni non blocchi la pittura mentre viene determinato il conteggio delle pagine. La scheda può contenere temporaneamente byte di origine, stato del parser, risorse preparate ed eventuale output. Cancellazione o chiusura di questioni perché l'elaborazione locale consuma ancora risorse reali del dispositivo.
La maggior parte delle trasformazioni PDF utilizza il lavoratore del toolkit; L'analisi PDF e la codifica del canvas hanno una suddivisione separata
Unisci, dividi, estrai, elimina, riordina, ruota, filigrana e chiama l'assembly image-to-PDF finale pdf-lib tramite il modulo di lavoro dedicato. I messaggi di avanzamento e annullamento superano quel confine mentre il lavoro computazionale rimane lontano dal thread dell'interfaccia principale. La cancellazione dei file termina il lavoratore invece di attendere la garbage collection.
PDF-to-image è l'eccezione importante. pdf.js utilizza il proprio lavoratore per l'analisi, ma la codifica del canvas del browser deve rimanere nel thread principale. Il renderer cede tra le pagine in modo che i controlli e il progresso possano essere ridisegnati. Dire che ogni trasformazione viene eseguita interamente in un lavoratore contraddirebbe l'implementazione spedita.
L'analisi e la scrittura sono fasi locali, ma la preparazione dell'immagine e la codifica della tela possono essere eseguite sul thread principale
La pipeline generale viene letta, interpretata, trasformata e codificata, ma ogni operazione sceglie il proprio macchinario concreto. Le operazioni di copia della pagina chiedono a pdf-lib di creare un nuovo documento. La rotazione modifica i metadati aggiuntivi della pagina. Le filigrane aggiungono disegni. PDF-to-image esegue il rendering delle pagine, mentre images-to-PDF prepara le immagini decodificate dal browser prima dell'assemblaggio del lavoratore.
Queste distinzioni influiscono sulla fedeltà. La copia delle pagine conserva il contenuto selezionabile; renderli in PNG o JPEG trasforma la pagina in pixel e perde il livello di testo. Le immagini nonPNG/JPEG possono essere decodificate e ricodificate come PNG prima dell'assemblaggio di PDF. “Locale” descrive il movimento dei dati, non un algoritmo di trasformazione universale.
Il download è un oggetto locale: come un BLOB e un oggetto URL ti danno un file che non è mai esistito su nessun server
Ogni operazione restituisce byte o un ZIP che l'interfaccia racchiude in un BLOB con il tipo di supporto appropriato. L'azione risultante chiama l'helper `downloadBlob` condiviso, che crea il download del browser anziché passare a un file del server. L'artefatto generato esisteva in memoria prima che l'utente lo salvasse nella normale memoria del dispositivo.
Anche le miniature dell'organizzatore utilizzano gli URL degli oggetti BLOB, ma il loro ciclo di vita è esplicito: i vecchi URL vengono revocati prima di un nuovo caricamento e tutti vengono revocati in caso di distruzione o cancellazione. Questa distinzione impedisce che una rivendicazione di privacy locale nasconda una perdita di memoria. Una volta scaricato, il file segue le normali regole di backup e condivisione del dispositivo.
Perché il limite è la memoria del tuo dispositivo: l'originale, la struttura analizzata e la copia riscritta risiedono tutte in RAM contemporaneamente
Il lavoro locale è limitato da RAM e dalle policy del browser, nonché da limiti di input espliciti. Un PDF può esistere contemporaneamente come byte di origine, un modello a oggetti analizzati, buffer di lavoro trasferiti, anteprime e output serializzato. Le pagine raster aggiungono tele di grandi dimensioni, quindi il renderer misura un budget di pixel e può ridurre la scala prima dell'allocazione.
Un telefono può avere difficoltà prima di un desktop anche al di sotto di 50 MB perché la dimensione del file compresso dice poco sulle immagini della pagina decodificate. Chiudi le schede non correlate, elabora meno pagine o utilizza un dispositivo più grande per lavori impegnativi. Il limite massimo rimane 50 MB per PDF e 30 MB per immagine; la memoria non è una scusa per non rivendicare alcun limite fisso.
Altri prodotti ToolAcre potrebbero utilizzare la rete; Anche l'analisi della produzione consentita è separata
Il repository afferma che altri due prodotti ToolAcre contattano la rete in base alla progettazione, quindi il comportamento locale deve essere verificato per prodotto anziché generalizzato in tutto il sito. Il codice dell'operazione PDF non ha endpoint che trasportano documenti e un test di isolamento automatizzato controlla tale invariante durante l'elaborazione.
L'analisi a livello di sito può essere eseguita solo sull'host di produzione canonico dopo il consenso. La lista consentita degli eventi ToolAcre esclude nomi di file, contenuti, testo incollato, URL e dimensioni esatte dei file, mentre gli script di Google rimangono codici di terze parti descritti dalle norme sulla privacy. Le richieste di risorse statiche o di analisi sono distinte dal caricamento di un documento.
Conclusione: ogni passaggio avviene sul tuo dispositivo e la pagina PDF Toolkit e il pannello Rete ti consentono di confermarlo
Il ciclo di vita completo è visibile: scegli un file, convalidalo e leggilo, trasformalo localmente con il lavoratore o il percorso di rendering appropriato, racchiudi l'output in un BLOB, scaricalo, quindi cancella i buffer e gli URL degli oggetti. Non è richiesto alcun server delle applicazioni per eseguire tali operazioni sulla pagina.
Tratta “nel browser” come un’architettura che puoi ispezionare piuttosto che come uno slogan. Osserva le richieste, leggi la nota specifica dell'operazione e utilizza Cancella file e libera memoria al termine. Questo controllo rilascia le immagini dell'organizzatore, elimina i riferimenti e termina il ruolo di lavoro, riducendo sia il carico di memoria che la durata del materiale documentale sensibile nella scheda. Scarica prima, verifica il file salvato e solo dopo cancella; l'elaborazione locale non fornisce intenzionalmente alcun fallback remoto per un risultato scartato troppo presto.