Por qué las herramientas de archivos deben verificar su propia salida
Transformación y verificación deben ser etapas separadas. La transformación crea una salida candidata; el verificador vuelve a analizar o decodificar ese candidato y comprueba las propiedades relevantes para la tarea. Solo entonces debe considerarse listo.
Última revisión técnica: 2026-09-19
Puntos clave
- Que no se lance una excepción no equivale a un resultado verificado.
- El verificador debe inspeccionar los bytes generados en vez de confiar únicamente en el estado interno de la transformación.
- Los criterios dependen de la tarea: orden de unión, ausencia tras redacción, reducción de tamaño y dimensiones de imagen necesitan controles distintos.
- Una propiedad desconocida o no verificable debe seguir como UNKNOWN o bloquear el éxito en lugar de adivinarse como PASS.
Por qué una transformación puede fallar en silencio
Una biblioteca puede devolver bytes aunque la salida haya perdido una página, cambiado la geometría, generado el formato incorrecto o conservado información que debía eliminarse. Algunas fallas son semánticas y no sintácticas.
Un verificador reduce este riesgo tratando la salida candidata como una entrada nueva y comprobándola contra requisitos explícitos.
Cada herramienta necesita un contrato de verificación distinto
Una unión de PDF debe verificar páginas, orden y geometría. Un compresor debe demostrar además que la salida aceptada es menor. Un compresor de imágenes debe confirmar formato, dimensiones y transparencia. La redacción debe demostrar la ausencia de estructuras y rutas de información prohibidas.
Esas comprobaciones deben ser obligatorias para las propiedades incluidas en la afirmación de éxito. Un control opcional o poco fiable no debe convertirse silenciosamente en PASS.
Por qué importa volver a analizar de forma independiente
Si el mismo estado interno que produjo el resultado es la única evidencia de corrección, un error común puede afectar a ambas etapas. Volver a analizar los bytes finales crea una frontera más fuerte.
Esto no hace infalible al software, pero convierte muchas suposiciones ocultas en contratos explícitos y comprobables.
Modelo de verificación de ZAMAZY
Las herramientas enfocadas de ZAMAZY siguen un modelo de transformar y después verificar. Una salida candidata no se considera correcta solo porque el procesamiento terminó.
Las comprobaciones obligatorias son específicas de cada herramienta y fallan de forma cerrada. Las condiciones no compatibles o no verificables con fiabilidad no se presentan como listas.
Proceso práctico
- Crea la salida candidata sin sobrescribir el archivo original.
- Analiza o decodifica el candidato como si fuera un archivo nuevo.
- Compara las propiedades específicas de la tarea con el resultado esperado.
- Permite la descarga solo cuando todas las comprobaciones obligatorias hayan tenido éxito.
Ejemplo y ayuda para decidir
Supón que una unión escribe un PDF válido de cinco páginas pero coloca el anexo antes de la portada. Una comprobación solo estructural podría pasar aunque la tarea siga siendo incorrecta. Del mismo modo, una imagen puede decodificarse bien y tener dimensiones equivocadas o cambios de píxel no deseados. La pregunta útil es qué propiedad obligatoria se comparó realmente con el plan.
Para unir, revisa número, orden y geometría. Para comprimir, exige una salida aceptable y menor además de las comprobaciones declaradas. Para redacción, distingue ausencia de estructuras prohibidas de sustitución correcta de las regiones marcadas. ZAMAZY bloquea un resultado de descarga exitosa cuando no pasan los controles obligatorios del resultado compatible; aun así revisa el archivo antes de compartirlo.
Cuándo este enfoque no es adecuado
Comprobar magic bytes del formato no es validar una firma criptográfica. Una salida verificada no demuestra que se seleccionara toda zona sensible, que todos los dispositivos sean compatibles o que un portal acepte el archivo. Mantén UNKNOWN distinto de PASS. Un escenario ilustrativo no es un benchmark, auditoría independiente ni garantía para todas las entradas.
Ejemplo editorial, no un benchmark. Complemento revisado el:
Fuentes y límites de la evidencia
Estas fuentes explican formatos y métodos. No certifican a ZAMAZY; los hechos y límites compatibles de ZAMAZY se indican en la página de cada herramienta.
- PDF-LIB: PDFDocument API — Primitivas de copia de páginas; no son una prueba completa de preservación de ZAMAZY.
- W3C: PNG Specification, Third Edition — Píxeles PNG, alfa y chunks; no implica que se acepte cualquier variante PNG.
- Google: WebP Container Specification — Modos WebP, alfa, animación y contenedores de metadatos.
Preguntas frecuentes
¿Por qué volver a abrir un archivo que acaba de generarse?
Porque los bytes finales son el producto real. Volver a analizarlos puede detectar corrupción, formatos incorrectos, páginas perdidas o cambios que el estado interno no muestra.
¿Puede verificarse cualquier propiedad de archivo en el navegador?
No. Algunas propiedades pueden quedar fuera del parser compatible o del entorno del navegador. Deben informarse como no compatibles o desconocidas, no inventarse como correctas.
¿La verificación garantiza que cualquier portal aceptará el archivo?
No. Demuestra propiedades técnicas definidas dentro del contrato de soporte de la herramienta. Un portal externo puede aplicar reglas adicionales.