Documentos · PDF Kit de herramientas
Cómo una pestaña del navegador lee y reescribe un PDF sin cargarlo
· Cómo funciona
pdf privacidad trabajadores web
'Se ejecuta en su navegador' es una afirmación que puede comprender y probar. Esta publicación sigue un PDF desde el selector de archivos a la memoria, a través de un Web Worker, y regresa como una descarga, explicando qué hace cada paso y por qué no hay ningún servidor involucrado.
El selector de archivos no es una carga: el momento de confusión al elegir un archivo parece enviarlo
Un selector de archivos se parece a un control de carga porque muchos sitios envían el archivo elegido inmediatamente. La selección por sí sola no requiere esa transferencia. En este kit de herramientas, el navegador otorga a la página acceso al objeto Archivo seleccionado por el usuario y el controlador valida su tipo y tamaño antes de leer PDF bytes en la memoria de pestañas.
El límite es observable: elegir un documento cambia el estado de la interfaz local, muestra su nombre, tamaño y número de páginas, y habilita la operación. No publica el archivo en un punto final de la aplicación. El límite PDF es 50 MB y el límite de la imagen es 30 MB, y se aplica antes de que comience el procesamiento costoso.
Del disco a la memoria: cómo File API entrega a la página una matriz de bytes que el propio JavaScript del sitio puede leer
Para archivos PDF, `arrayBuffer()` proporciona bytes y `Uint8Array` los retiene para las llamadas de los trabajadores. Los lotes de imágenes se manejan de manera diferente para evitar una segunda lectura innecesaria: los objetos de archivo sin formato se conservan hasta la preparación de la imagen del navegador. Estas son operaciones de memoria dentro del contexto actual del navegador, no almacenamiento remoto o historial de cuenta.
El primer PDF se inspecciona mediante una llamada `info` en el trabajador para que un documento grande no bloquee la pintura mientras se determina el recuento de páginas. La pestaña puede mantener juntos temporalmente los bytes de origen, el estado del analizador, los activos preparados y la salida final. Borrar o cerrar es importante porque el procesamiento local aún consume recursos reales del dispositivo.
La mayoría de las transformaciones PDF utilizan el trabajador del kit de herramientas; PDF el análisis y la codificación del lienzo tienen una división separada
Fusionar, dividir, extraer, eliminar, reordenar, rotar, marcar con marca de agua y llamar al ensamblaje final de imagen a PDF pdf-lib a través del módulo de trabajo dedicado. Los mensajes de progreso y cancelación cruzan ese límite mientras que el trabajo computacional se mantiene alejado del hilo de la interfaz principal. Al borrar archivos, el trabajador termina en lugar de esperar a que se recoja la basura.
PDF-to-image es la excepción importante. pdf.js utiliza su propio trabajador para el análisis, pero la codificación del lienzo del navegador debe permanecer en el hilo principal. El renderizador cede entre páginas para que los controles y el progreso puedan volver a pintarse. Decir que cada transformación se ejecuta íntegramente en un trabajador contradiría la implementación enviada.
El análisis y la escritura son etapas locales, pero la preparación de imágenes y la codificación del lienzo se pueden ejecutar en el hilo principal.
La canalización general se lee, interpreta, transforma y codifica, pero cada operación elige su propia maquinaria concreta. Las operaciones de copia de página solicitan a pdf-lib que cree un documento nuevo. La rotación cambia los metadatos de la página aditiva. Las marcas de agua añaden dibujos. PDF-to-image representa páginas, mientras que images-to-PDF prepara imágenes decodificadas por el navegador antes del ensamblaje del trabajador.
Esas distinciones afectan la fidelidad. Al copiar páginas se conserva el contenido seleccionable; renderizarlos en PNG o JPEG convierte la página en píxeles y pierde su capa de texto. Las imágenes que no son PNG/JPEG se pueden decodificar y volver a codificar como PNG antes del ensamblaje de PDF. "Local" describe el movimiento de datos, no un algoritmo de transformación universal.
La descarga es un objeto local: cómo un Blob y una URL de objeto le brindan un archivo que nunca existió en ningún servidor.
Cada operación devuelve bytes o un ZIP que la interfaz envuelve en un Blob con el tipo de medio apropiado. La acción resultante llama al asistente compartido `downloadBlob`, que crea la descarga del navegador en lugar de navegar a un archivo del servidor. El artefacto generado existía en la memoria antes de que el usuario lo guardara en el almacenamiento normal del dispositivo.
Las miniaturas del organizador también usan URL de objetos Blob, pero su ciclo de vida es explícito: las URL antiguas se revocan antes de una nueva carga y todas se revocan al destruirlas o borrarlas. Esa distinción evita que un reclamo de privacidad local oculte una pérdida de memoria. Una vez descargado, el archivo sigue las reglas habituales de copia de seguridad y uso compartido del dispositivo.
Por qué el límite es la memoria de su dispositivo: el original, la estructura analizada y la copia reescrita se encuentran en la RAM al mismo tiempo
El trabajo local está limitado por las políticas de RAM y del navegador, así como por límites de entrada explícitos. Un PDF puede existir simultáneamente como bytes de origen, un modelo de objetos analizado, buffers de trabajo transferidos, vistas previas y salida serializada. Las páginas rasterizadas añaden lienzos grandes, por lo que el renderizador mide un presupuesto de píxeles y puede reducir la escala antes de la asignación.
Un teléfono puede tener problemas antes que una computadora de escritorio, incluso por debajo de 50 MB porque el tamaño del archivo comprimido dice poco sobre las imágenes decodificadas de la página. Cierre pestañas no relacionadas, procese menos páginas o utilice un dispositivo más grande para trabajos exigentes. El límite máximo sigue siendo 50 MB por PDF y 30 MB por imagen; La memoria no es una excusa para pretender que no hay un límite fijo.
Otros productos ToolAcre pueden utilizar la red; el análisis de producción consentido también es independiente
El repositorio indica que otros dos productos ToolAcre contactan la red por diseño, por lo que el comportamiento local debe verificarse por producto en lugar de generalizarse en todo el sitio. El código de operación PDF no tiene ningún punto final que transporte documentos y una prueba de aislamiento automatizada verifica esa invariancia durante el procesamiento.
Los análisis de todo el sitio solo se pueden ejecutar en el host de producción canónico después del consentimiento. Su lista de permitidos de eventos ToolAcre excluye nombres de archivos, contenidos, texto pegado, URL y tamaños exactos de archivos, mientras que los scripts de Google siguen siendo códigos de terceros descritos en la política de privacidad. Las solicitudes de activos estáticos o análisis son distintas de la carga de un documento.
Conclusión: cada paso ocurre en su dispositivo, y la página del kit de herramientas PDF y el panel de Red le permiten confirmarlo.
El ciclo de vida completo es visible: elija un archivo, valídelo y léalo, transfórmelo localmente con el trabajador o ruta de procesamiento apropiado, envuelva la salida en un Blob, descárguelo y luego borre los buffers y las URL de los objetos. No se requiere ningún servidor de aplicaciones para realizar esas operaciones de página.
Trate "en el navegador" como una arquitectura que puede inspeccionar en lugar de un eslogan. Observe las solicitudes, lea la nota específica de la operación y utilice Borrar archivos y liberar memoria cuando haya terminado. Ese control libera imágenes del organizador, elimina referencias y despide al trabajador, lo que reduce tanto la presión de la memoria como la vida útil del material de documentos confidenciales en la pestaña. Descargue primero, verifique el archivo guardado y solo luego borre; El procesamiento local no proporciona intencionalmente ningún respaldo remoto para un resultado descartado demasiado pronto.