Dokumente · PDF Toolkit
Wie ein Browser-Tab ein PDF liest und neu schreibt, ohne es hochzuladen
· Wie es funktioniert
pdf Datenschutz Web-Worker
„Läuft in Ihrem Browser“ ist eine Behauptung, die Sie verstehen und testen können. Dieser Beitrag folgt einem PDF von der Dateiauswahl in den Speicher, über einen Web Worker und zurück als Download, und erklärt, was jeder Schritt bewirkt und warum kein Server beteiligt ist.
Die Dateiauswahl ist kein Upload – der Moment der Verwirrung bei der Auswahl einer Datei sieht aus, als würde man sie senden
Eine Dateiauswahl ähnelt einer Upload-Steuerung, da viele Websites die ausgewählte Datei sofort senden. Die Auswahl allein erfordert diese Übertragung nicht. In diesem Toolkit gewährt der Browser der Seite Zugriff auf das vom Benutzer ausgewählte Dateiobjekt, und der Controller überprüft dessen Typ und Größe, bevor er PDF Bytes in den Tab-Speicher liest.
Die Grenze ist beobachtbar: Die Auswahl eines Dokuments ändert den lokalen Schnittstellenstatus, zeigt seinen Namen, seine Größe und Seitenzahl an und aktiviert den Vorgang. Die Datei wird nicht an einen Anwendungsendpunkt gesendet. Die PDF-Obergrenze beträgt 50 MB und die Bildobergrenze beträgt 30 MB und wird durchgesetzt, bevor die teure Verarbeitung beginnt.
Von der Festplatte in den Speicher – wie die Datei-API der Seite ein Byte-Array übergibt, das das eigene JavaScript der Site lesen kann
Für PDFs stellt `arrayBuffer()` Bytes bereit und ein `Uint8Array` hält sie für Worker-Aufrufe bereit. Bildstapel werden unterschiedlich gehandhabt, um ein unnötiges zweites Lesen zu vermeiden: Rohe Dateiobjekte werden bis zur Browser-Bildvorbereitung beibehalten. Hierbei handelt es sich um Speichervorgänge innerhalb des aktuellen Browserkontexts, nicht um Remotespeicher oder Kontoverlauf.
Der erste PDF wird durch einen `info`-Aufruf im Worker überprüft, damit ein großes Dokument das Malen nicht blockiert, während die Seitenzahl bestimmt wird. Auf der Registerkarte können vorübergehend Quellbytes, Parser-Status, vorbereitete Assets und eventuelle Ausgaben zusammengehalten werden. Das Löschen oder Schließen ist von Bedeutung, da die lokale Verarbeitung immer noch echte Geräteressourcen verbraucht.
Die meisten PDF-Transformationen verwenden den Toolkit-Worker; PDF Parsing und Canvas-Codierung haben eine separate Aufteilung
Zusammenführen, Teilen, Extrahieren, Löschen, Neuanordnen, Drehen, Wasserzeichen und endgültiges Bild-zu-PDF Assembly-Aufruf von pdf-lib über den dedizierten Modul-Worker. Fortschritts- und Abbruchmeldungen überschreiten diese Grenze, während die Rechenarbeit vom primären Schnittstellenthread ferngehalten wird. Durch das Löschen von Dateien wird der Worker beendet, anstatt auf die Garbage Collection zu warten.
PDF-to-image ist die wichtige Ausnahme. pdf.js verwendet seinen eigenen Worker zum Parsen, die Browser-Canvas-Codierung muss jedoch im Hauptthread verbleiben. Der Renderer gibt zwischen den Seiten nach, sodass Steuerelemente und Fortschritt neu gezeichnet werden können. Zu sagen, dass jede Transformation vollständig in einem Worker ausgeführt wird, würde der ausgelieferten Implementierung widersprechen.
Das Parsen und Schreiben sind lokale Phasen, aber die Bildvorbereitung und Canvas-Codierung können im Hauptthread ausgeführt werden
Die allgemeine Pipeline wird gelesen, interpretiert, transformiert und codiert, aber jede Operation wählt ihre eigene konkrete Maschinerie. Seitenkopiervorgänge fordern pdf-lib auf, ein neues Dokument zu erstellen. Durch die Drehung werden zusätzliche Seitenmetadaten geändert. Wasserzeichen fügen Zeichnungen hinzu. PDF-to-image rendert Seiten, während images-to-PDF browserdekodierte Bilder vor der Worker-Assemblierung vorbereitet.
Diese Unterscheidungen wirken sich auf die Treue aus. Beim Kopieren von Seiten bleiben auswählbare Inhalte erhalten; Durch das Rendern in PNG oder JPEG wird die Seite in Pixel umgewandelt und verliert ihre Textebene. Nicht-PNG/JPEG-Bilder können vor der PDF-Assemblierung als PNG dekodiert und neu kodiert werden. „Lokal“ beschreibt die Datenbewegung, nicht einen universellen Transformationsalgorithmus.
Der Download ist ein lokales Objekt – wie ein Blob und eine Objekt-URL Ihnen eine Datei liefern, die auf keinem Server existierte
Jeder Vorgang gibt Bytes oder eine ZIP-Datei zurück, die die Schnittstelle in einen Blob mit dem entsprechenden Medientyp einschließt. Die Ergebnisaktion ruft den gemeinsam genutzten Helfer `downloadBlob` auf, der den Browser-Download erstellt, anstatt zu einer Serverdatei zu navigieren. Das generierte Artefakt war im Speicher vorhanden, bevor der Benutzer es im normalen Gerätespeicher gespeichert hat.
Organizer-Miniaturansichten verwenden ebenfalls Blob-Objekt-URLs, ihr Lebenszyklus ist jedoch explizit: Alte URLs werden vor einem neuen Laden widerrufen, und alle werden beim Zerstören oder Löschen widerrufen. Diese Unterscheidung verhindert, dass ein lokaler Datenschutzanspruch ein Speicherleck verbirgt. Nach dem Herunterladen folgt die Datei den üblichen Regeln für die Gerätesicherung und -freigabe.
Warum die Grenze der Speicher Ihres Geräts ist – das Original, die analysierte Struktur und die neu geschriebene Kopie befinden sich alle gleichzeitig im RAM
Lokale Arbeit wird durch RAM- und Browserrichtlinien sowie explizite Eingabeobergrenzen begrenzt. Ein PDF kann gleichzeitig als Quellbytes, ein analysiertes Objektmodell, übertragene Worker-Puffer, Vorschauen und serialisierte Ausgabe vorhanden sein. Rasterseiten fügen große Leinwände hinzu, daher misst der Renderer ein Pixelbudget und reduziert möglicherweise die Skalierung vor der Zuweisung.
Ein Telefon kann sogar unter 50 MB früher Probleme haben als ein Desktop, da die komprimierte Dateigröße wenig über dekodierte Seitenbilder aussagt. Schließen Sie nicht verwandte Registerkarten, verarbeiten Sie weniger Seiten oder verwenden Sie ein größeres Gerät für anspruchsvolle Aufgaben. Die feste Obergrenze beträgt weiterhin 50 MB pro PDF und 30 MB pro Bild; Erinnerung ist keine Entschuldigung dafür, keine feste Grenze zu beanspruchen.
Andere ToolAcre-Produkte nutzen möglicherweise das Netzwerk; Die Analyse der genehmigten Produktion erfolgt ebenfalls separat
Das Repository gibt an, dass zwei weitere ToolAcre-Produkte das Netzwerk absichtlich kontaktieren, sodass das lokale Verhalten pro Produkt überprüft werden muss und nicht auf der gesamten Website verallgemeinert werden muss. Der Operationscode PDF hat keinen Endpunkt, der Dokumente trägt, und ein automatisierter Isolationstest prüft diese Invariante während der Verarbeitung.
Siteweite Analysen können nur nach Zustimmung auf dem kanonischen Produktionshost ausgeführt werden. Die Zulassungsliste für ToolAcre-Ereignisse schließt Dateinamen, Inhalte, eingefügten Text, URLs und genaue Dateigrößen aus, während Google-Skripte in der Datenschutzrichtlinie beschriebene Codes von Drittanbietern bleiben. Statische Asset- oder Analyseanfragen unterscheiden sich vom Hochladen eines Dokuments.
Imbiss: Jeder Schritt erfolgt auf Ihrem Gerät und auf der Seite des PDF Toolkits und im Netzwerkfenster können Sie ihn bestätigen
Der gesamte Lebenszyklus ist sichtbar: Wählen Sie eine Datei aus, validieren und lesen Sie sie, transformieren Sie sie lokal mit dem entsprechenden Worker oder Rendering-Pfad, verpacken Sie die Ausgabe in einen Blob, laden Sie sie herunter und löschen Sie dann Puffer und Objekt-URLs. Für die Ausführung dieser Seitenvorgänge ist kein Anwendungsserver erforderlich.
Behandeln Sie „im Browser“ als eine Architektur, die Sie inspizieren können, und nicht als einen Slogan. Beobachten Sie Anfragen, lesen Sie den vorgangsspezifischen Hinweis und verwenden Sie „Dateien löschen und Speicher freigeben“, wenn Sie fertig sind. Diese Steuerung gibt Organisatorbilder frei, löscht Referenzen und beendet den Worker, wodurch sowohl die Speicherbelastung als auch die Lebensdauer vertraulicher Dokumentmaterialien auf der Registerkarte verringert werden. Zuerst herunterladen, die gespeicherte Datei überprüfen und erst dann löschen; Die lokale Verarbeitung bietet absichtlich keinen Remote-Fallback für ein zu früh verworfenes Ergebnis.