Un formato de archivo es una forma estándar de codificar la información para su almacenamiento en un archivo informático . Especifica cómo se utilizan los bits para codificar la información en un medio de almacenamiento digital . Los formatos de archivo pueden ser propietarios o libres .
Algunos formatos de archivo están diseñados para tipos de datos muy particulares: los archivos PNG , por ejemplo, almacenan imágenes de mapa de bits utilizando compresión de datos sin pérdida . Sin embargo, otros formatos de archivo están diseñados para el almacenamiento de varios tipos de datos diferentes: el formato Ogg puede actuar como un contenedor para diferentes tipos de multimedia , incluida cualquier combinación de audio y video , con o sin texto (como subtítulos ) y metadatos . Un archivo de texto puede contener cualquier flujo de caracteres, incluidos posibles caracteres de control , y está codificado en uno de varios esquemas de codificación de caracteres . Algunos formatos de archivo, como HTML , gráficos vectoriales escalables y el código fuente de software de computadora son archivos de texto con sintaxis definidas que permiten su uso para fines específicos.
Los formatos de archivo suelen tener una especificación publicada que describe el método de codificación y permite probar la funcionalidad prevista del programa. No todos los formatos tienen documentos de especificación disponibles libremente, en parte porque algunos desarrolladores consideran que sus documentos de especificación son secretos comerciales y en parte porque otros desarrolladores nunca redactan un documento de especificación formal, lo que permite que el precedente establecido por otros programas ya existentes que utilizan el formato defina el formato a través de cómo lo utilizan estos programas existentes.
Si el desarrollador de un formato no publica especificaciones gratuitas, otro desarrollador que desee utilizar ese tipo de archivo debe realizar ingeniería inversa del archivo para averiguar cómo leerlo o adquirir el documento de especificaciones de los desarrolladores del formato a cambio de una tarifa y firmando un acuerdo de confidencialidad . Este último enfoque solo es posible cuando existe un documento de especificaciones formal. Ambas estrategias requieren una cantidad significativa de tiempo, dinero o ambos; por lo tanto, los formatos de archivo con especificaciones disponibles públicamente tienden a ser compatibles con más programas.
La ley de patentes , en lugar de los derechos de autor , se utiliza con más frecuencia para proteger un formato de archivo. Aunque las patentes para formatos de archivo no están permitidas directamente por la ley estadounidense, algunos formatos codifican datos utilizando algoritmos patentados . Por ejemplo, antes de 2004, el uso de la compresión con el formato de archivo GIF requería el uso de un algoritmo patentado y, aunque el propietario de la patente inicialmente no hizo cumplir su patente, más tarde comenzó a cobrar regalías . Esto ha dado como resultado una disminución significativa en el uso de GIF y es en parte responsable del desarrollo del formato alternativo PNG . Sin embargo, la patente GIF expiró en los EE. UU. a mediados de 2003 y en todo el mundo a mediados de 2004.
Tradicionalmente, los distintos sistemas operativos han adoptado distintos enfoques para determinar el formato de un archivo en particular, y cada uno de ellos tiene sus propias ventajas y desventajas. La mayoría de los sistemas operativos y aplicaciones individuales modernos necesitan utilizar todos los enfoques siguientes para leer formatos de archivos "extranjeros", o incluso para trabajar con ellos por completo.
Un método popular utilizado por muchos sistemas operativos, incluidos Windows , macOS , CP/M , DOS , VMS y VM/CMS , es determinar el formato de un archivo según el final de su nombre, más específicamente las letras que siguen al punto final. Esta parte del nombre del archivo se conoce como extensión del nombre de archivo . Por ejemplo, los documentos HTML se identifican con nombres que terminan en .html (o .htm ), y las imágenes GIF con .gif . En el sistema de archivos FAT original , los nombres de archivo se limitaban a un identificador de ocho caracteres y una extensión de tres caracteres, conocida como nombre de archivo 8.3 . Hay un número limitado de extensiones de tres letras, lo que puede hacer que una extensión determinada sea utilizada por más de un programa. Muchos formatos todavía utilizan extensiones de tres caracteres a pesar de que los sistemas operativos y programas de aplicación modernos ya no tienen esta limitación. Dado que no existe una lista estándar de extensiones, más de un formato puede utilizar la misma extensión, lo que puede confundir tanto al sistema operativo como a los usuarios.
Un defecto de este enfoque es que se puede engañar fácilmente al sistema para que trate un archivo como un formato diferente simplemente cambiándole el nombre: un archivo HTML se puede tratar fácilmente como texto simple cambiándole el nombre de filename.html a filename.txt . Aunque esta estrategia era útil para los usuarios expertos que podían entender y manipular fácilmente esta información, a menudo resultaba confusa para los usuarios menos técnicos, que podían inutilizar un archivo accidentalmente (o "perderlo") cambiándole el nombre de forma incorrecta.
Esto provocó que la mayoría de las versiones de Windows y Mac OS ocultaran la extensión al enumerar los archivos. Esto evita que el usuario cambie accidentalmente el tipo de archivo y permite que los usuarios expertos desactiven esta función y muestren las extensiones.
Sin embargo, ocultar la extensión puede crear la apariencia de dos o más nombres de archivo idénticos en la misma carpeta. Por ejemplo, es posible que se necesite el logotipo de una empresa tanto en formato .eps (para publicaciones) como en formato .png (para sitios web). Con las extensiones visibles, estos aparecerían como nombres de archivo únicos: " CompanyLogo.eps " y " CompanyLogo.png ". Por otro lado, ocultar las extensiones haría que ambos aparecieran como " CompanyLogo ", lo que puede generar confusión.
Ocultar extensiones también puede suponer un riesgo de seguridad. [1] Por ejemplo, un usuario malintencionado podría crear un programa ejecutable con un nombre inocente como " Holiday photo.jpg.exe ". El " .exe " quedaría oculto y un usuario desprevenido vería " Holiday photo.jpg ", que parecería ser una imagen JPEG , normalmente incapaz de dañar la máquina. Sin embargo, el sistema operativo seguiría viendo la extensión " .exe " y ejecutaría el programa, que entonces podría causar daño a la computadora. Lo mismo ocurre con los archivos con una sola extensión: como no se muestra al usuario, no se puede deducir ninguna información sobre el archivo sin investigar explícitamente el archivo. Para engañar aún más a los usuarios, es posible almacenar un icono dentro del programa, en cuyo caso la asignación de iconos de algunos sistemas operativos para el archivo ejecutable ( .exe ) se anularía con un icono que se utiliza habitualmente para representar imágenes JPEG, haciendo que el programa parezca una imagen. Las extensiones también pueden ser falsificadas: algunos virus de macro de Microsoft Word crean un archivo de Word en formato de plantilla y lo guardan con una extensión .doc . Dado que Word generalmente ignora las extensiones y observa el formato del archivo, estas se abrirían como plantillas, se ejecutarían y propagarían el virus. [ cita requerida ] Esto representa un problema práctico para los sistemas Windows donde la ocultación de extensiones está activada de forma predeterminada.
Una segunda forma de identificar un formato de archivo es utilizar información sobre el formato almacenada dentro del propio archivo, ya sea información destinada a este fin o cadenas binarias que siempre se encuentran en ubicaciones específicas en los archivos de algunos formatos. Dado que el lugar más fácil para localizarlas es al principio, dicha zona suele denominarse cabecera de archivo cuando tiene más de unos pocos bytes , o número mágico si tiene sólo unos pocos bytes de longitud.
Los metadatos contenidos en el encabezado de un archivo se almacenan normalmente al principio del archivo, pero también pueden estar presentes en otras áreas, a menudo incluso al final, según el formato del archivo o el tipo de datos que contenga. Los archivos basados en caracteres (texto) suelen tener encabezados basados en caracteres, mientras que los formatos binarios suelen tener encabezados binarios, aunque esto no es una regla. Los encabezados de archivo basados en texto suelen ocupar más espacio, pero al ser legibles por humanos, se pueden examinar fácilmente utilizando un software simple como un editor de texto o un editor hexadecimal.
Además de identificar el formato del archivo, los encabezados de archivo pueden contener metadatos sobre el archivo y su contenido. Por ejemplo, la mayoría de los archivos de imagen almacenan información sobre el formato de la imagen, el tamaño, la resolución y el espacio de color , y opcionalmente , información de autor como quién hizo la imagen, cuándo y dónde se hizo, qué modelo de cámara y ajustes fotográficos se utilizaron ( Exif ), etc. Estos metadatos pueden ser utilizados por el software que lee o interpreta el archivo durante el proceso de carga y posteriormente.
Los encabezados de archivo pueden ser utilizados por un sistema operativo para recopilar rápidamente información sobre un archivo sin cargarlo todo en la memoria, pero al hacerlo se utilizan más recursos de la computadora que al leer directamente la información del directorio . Por ejemplo, cuando un administrador de archivos gráficos tiene que mostrar el contenido de una carpeta, debe leer los encabezados de muchos archivos antes de poder mostrar los íconos apropiados, pero estos estarán ubicados en diferentes lugares en el medio de almacenamiento, por lo que se tardará más tiempo en acceder a ellos. Una carpeta que contenga muchos archivos con metadatos complejos, como información en miniatura, puede requerir un tiempo considerable antes de poder mostrarse.
Si un encabezado está codificado en binario de manera que el encabezado en sí necesita una interpretación compleja para ser reconocido, especialmente para proteger el contenido de los metadatos, existe el riesgo de que el formato del archivo se pueda malinterpretar. Incluso puede que se haya escrito mal en la fuente. Esto puede dar como resultado metadatos corruptos que, en casos extremadamente graves, podrían incluso hacer que el archivo sea ilegible. [ Aclaración necesaria ]
Un ejemplo más complejo de encabezados de archivo son aquellos utilizados para formatos de archivos contenedores .
Una forma de incorporar metadatos de tipo de archivo, a menudo asociados con Unix y sus derivados, es almacenar un "número mágico" dentro del propio archivo. Originalmente, este término se utilizaba para un conjunto específico de identificadores de 2 bytes al principio de los archivos, pero dado que cualquier secuencia binaria puede considerarse un número, cualquier característica de un formato de archivo que lo distinga de forma única puede utilizarse para la identificación. Las imágenes GIF , por ejemplo, siempre comienzan con la representación ASCIIGIF87a de o GIF89a, dependiendo del estándar al que se adhieran. Muchos tipos de archivos, especialmente los archivos de texto sin formato, son más difíciles de detectar con este método. Los archivos HTML, por ejemplo, pueden comenzar con la cadena <html>(que no distingue entre mayúsculas y minúsculas), o una definición de tipo de documento adecuada que comience con <!DOCTYPE html, o, para XHTML , el identificador XML , que comienza con <?xml. Los archivos también pueden comenzar con comentarios HTML, texto aleatorio o varias líneas vacías, pero aún así ser HTML utilizable.
El método del número mágico ofrece mejores garantías de que el formato se identificará correctamente y, a menudo, puede determinar información más precisa sobre el archivo. Dado que las pruebas de "número mágico" razonablemente fiables pueden ser bastante complejas y cada archivo debe probarse efectivamente contra cada posibilidad en la base de datos mágica, este método es relativamente ineficiente, especialmente para mostrar grandes listas de archivos (en contraste, los métodos basados en el nombre de archivo y metadatos necesitan verificar solo un fragmento de datos y compararlo con un índice ordenado). Además, los datos deben leerse desde el propio archivo, lo que aumenta la latencia en comparación con los metadatos almacenados en el directorio. Cuando los tipos de archivo no se prestan al reconocimiento de esta manera, el sistema debe recurrir a los metadatos. Sin embargo, es la mejor manera para que un programa verifique si el archivo que se le ha indicado que procese tiene el formato correcto: si bien el nombre o los metadatos del archivo pueden alterarse independientemente de su contenido, fallar en una prueba de número mágico bien diseñada es una señal bastante segura de que el archivo está dañado o es del tipo incorrecto. Por otro lado, un número mágico válido no garantiza que el archivo no esté dañado o sea del tipo correcto.
Las llamadas líneas shebang en los archivos de script son un caso especial de números mágicos. En este caso, el número mágico es un texto legible para humanos que identifica un intérprete de comandos específico y las opciones que se le deben pasar.
Otro sistema operativo que utiliza números mágicos es AmigaOS , donde los números mágicos se denominaban "Magic Cookies" y se adoptaron como sistema estándar para reconocer ejecutables en formato de archivo ejecutable Hunk y también para permitir que programas, herramientas y utilidades individuales se ocuparan automáticamente de sus archivos de datos guardados, o cualquier otro tipo de archivo al guardar y cargar datos. Este sistema se mejoró posteriormente con el sistema de reconocimiento de tipos de datos estándar de Amiga . Otro método fue el método FourCC , originado en OSType en Macintosh, adaptado posteriormente por Interchange File Format (IFF) y derivados.
Una última forma de almacenar el formato de un archivo es almacenar explícitamente información sobre el formato en el sistema de archivos, en lugar de dentro del archivo en sí.
Este enfoque mantiene los metadatos separados tanto de los datos principales como del nombre, pero también es menos portátil que las extensiones de nombre de archivo o los "números mágicos", ya que el formato debe convertirse de un sistema de archivos a otro. Si bien esto también es cierto hasta cierto punto con las extensiones de nombre de archivo (por ejemplo, para la compatibilidad con el límite de tres caracteres de MS-DOS ), la mayoría de las formas de almacenamiento tienen una definición aproximadamente equivalente de los datos y el nombre de un archivo, pero pueden tener una representación variable o nula de otros metadatos.
Tenga en cuenta que los archivos zip o los archivos de almacenamiento resuelven el problema de la manipulación de metadatos. Un programa de utilidad recopila varios archivos junto con los metadatos sobre cada archivo y las carpetas/directorios de los que provienen, todo dentro de un nuevo archivo (por ejemplo, un archivo zip con la extensión .zip ). El nuevo archivo también está comprimido y posiblemente cifrado, pero ahora se puede transmitir como un solo archivo a través de sistemas operativos mediante transmisiones FTP o enviar por correo electrónico como un archivo adjunto. En el destino, el archivo único recibido debe descomprimirse con una utilidad compatible para que sea útil. Los problemas de manipulación de metadatos se resuelven de esta manera utilizando archivos zip o archivos de almacenamiento.
El sistema de archivos jerárquico de Mac OS almacena códigos para el creador y el tipo como parte de la entrada de directorio para cada archivo. Estos códigos se conocen como OSTypes. Estos códigos podrían ser cualquier secuencia de 4 bytes, pero a menudo se seleccionaban de modo que la representación ASCII formara una secuencia de caracteres significativos, como una abreviatura del nombre de la aplicación o las iniciales del desarrollador. Por ejemplo, un archivo de "pila" de HyperCard tiene un creador de WILD (del nombre anterior de Hypercard, "WildCard") y un tipo de STAK . El editor de texto BBEdit tiene un código de creador que hace referencia a su programador original, Rich Siegel. El código de tipo especifica el formato del archivo, mientras que el código de creador especifica el programa predeterminado con el que abrirlo cuando el usuario hace doble clic. Por ejemplo, el usuario podría tener varios archivos de texto, todos con el código de tipo de TEXT , pero cada uno abierto en un programa diferente, debido a que tienen diferentes códigos de creador. Esta característica fue pensada para que, por ejemplo, los archivos de texto sin formato legibles por humanos pudieran abrirse en un editor de texto de uso general, mientras que los archivos de código HTML o de programación se abrieran en un editor especializado o IDE . Sin embargo, esta característica era a menudo fuente de confusión para los usuarios, ya que a menudo era impredecible qué programa se iniciaría cuando se hiciera doble clic en los archivos. RISC OS utiliza un sistema similar, que consiste en un número de 12 bits que se puede buscar en una tabla de descripciones; por ejemplo, el número hexadecimal tiene un "alias" de PoScript , que representa un archivo PostScript .R*chFF5
Un identificador de tipo uniforme (UTI) es un método que se utiliza en macOS para identificar de forma única clases de entidades "tipificadas", como formatos de archivos. Fue desarrollado por Apple como reemplazo de OSType (códigos de tipo y creador).
La UTI es una cadena de Core Foundation , que utiliza una cadena DNS inversa . Algunos tipos comunes y estándar utilizan un dominio llamado público (por ejemplo, public.png para una imagen de Portable Network Graphics ), mientras que otros dominios se pueden utilizar para tipos de terceros (por ejemplo, com.adobe.pdf para Portable Document Format ). Las UTI se pueden definir dentro de una estructura jerárquica, conocida como jerarquía de conformidad. Por lo tanto, public.png se ajusta a un supertipo de public.image , que a su vez se ajusta a un supertipo de public.data . Una UTI puede existir en múltiples jerarquías, lo que proporciona una gran flexibilidad.
Además de los formatos de archivo, las UTI también se pueden utilizar para otras entidades que pueden existir en macOS, entre ellas:
En IBM OS/VS a z/OS , el catálogo VSAM (antes de los catálogos ICF ) y el registro de volumen VSAM en el conjunto de datos de volumen VSAM (VVDS) (con catálogos ICF) identifican el tipo de conjunto de datos VSAM.
En IBM OS/360 a z/OS , un bloque de control de conjunto de datos (DSCB) de formato 1 o 7 en la tabla de contenido de volumen (VTOC) identifica la organización del conjunto de datos ( DSORG ) del conjunto de datos que describe.
Los sistemas de archivos HPFS , FAT12 y FAT16 (pero no FAT32) permiten el almacenamiento de "atributos extendidos" con los archivos. Estos comprenden un conjunto arbitrario de tripletes con un nombre, un tipo codificado para el valor y un valor, donde los nombres son únicos y los valores pueden tener una longitud de hasta 64 KB. Existen significados estandarizados para ciertos tipos y nombres (en OS/2 ). Uno de ellos es que el atributo extendido ".TYPE" se utiliza para determinar el tipo de archivo. Su valor comprende una lista de uno o más tipos de archivo asociados con el archivo, cada uno de los cuales es una cadena, como "Texto sin formato" o "Documento HTML". Por lo tanto, un archivo puede tener varios tipos.
El sistema de archivos NTFS también permite el almacenamiento de atributos extendidos de OS/2, como una de las bifurcaciones de archivos , pero esta característica está presente simplemente para soportar el subsistema OS/2 (no está presente en XP), por lo que el subsistema Win32 trata esta información como un bloque opaco de datos y no la utiliza. En su lugar, se basa en otras bifurcaciones de archivos para almacenar metainformación en formatos específicos de Win32. Los atributos extendidos de OS/2 todavía pueden ser leídos y escritos por programas Win32, pero los datos deben ser analizados completamente por las aplicaciones.
En sistemas Unix y similares , los sistemas de archivos ext2 , ext3 , ext4 , ReiserFS versión 3, XFS , JFS , FFS y HFS+ permiten el almacenamiento de atributos extendidos con archivos. Estos incluyen una lista arbitraria de cadenas "nombre=valor", donde los nombres son únicos y se puede acceder a un valor a través de su nombre relacionado.
El Identificador Único Persistente (PUID) de PRONOM es un esquema extensible de identificadores persistentes, únicos e inequívocos para formatos de archivo, desarrollado por los Archivos Nacionales del Reino Unido como parte de su servicio de registro técnico PRONOM . Los PUID se pueden expresar como Identificadores Uniformes de Recursos utilizando el espacio de nombres info:pronom/ . Aunque todavía no se utiliza ampliamente fuera del gobierno del Reino Unido y algunos programas de preservación digital , el esquema PUID proporciona una mayor granularidad que la mayoría de los esquemas alternativos.
Los tipos MIME se utilizan ampliamente en muchas aplicaciones relacionadas con Internet y cada vez más en otros lugares, aunque su uso para información de tipo en disco es poco frecuente. Estos consisten en un sistema estandarizado de identificadores (administrado por IANA ) que consta de un tipo y un subtipo , separados por una barra diagonal , por ejemplo, text/html o image/gif . Originalmente, se concibieron como una forma de identificar qué tipo de archivo se adjuntaba a un correo electrónico , independientemente de los sistemas operativos de origen y destino. Los tipos MIME identifican archivos en BeOS , AmigaOS 4.0 y MorphOS , así como también almacenan firmas de aplicaciones únicas para el lanzamiento de aplicaciones. En AmigaOS y MorphOS, el sistema de tipos MIME funciona en paralelo con el sistema de tipos de datos específico de Amiga.
Sin embargo, existen problemas con los tipos MIME: varias organizaciones y personas han creado sus propios tipos MIME sin registrarlos correctamente ante IANA, lo que hace que el uso de este estándar sea incómodo en algunos casos.
Los identificadores de formato de archivo son otra forma no muy utilizada de identificar formatos de archivo según su origen y su categoría de archivo. Fue creado para el paquete de software Description Explorer. Está compuesto por varios dígitos de la forma NNNNNNNNN-XX-YYYYYYY. La primera parte indica la organización de origen/mantenedor (este número representa un valor en una base de datos de una empresa/organización de estándares), y los 2 dígitos siguientes categorizan el tipo de archivo en hexadecimal . La parte final está compuesta por la extensión de nombre de archivo habitual del archivo o el número estándar internacional del archivo, rellenado a la izquierda con ceros. Por ejemplo, la especificación de archivo PNG tiene el FFID de 000000001-31-0015948donde 31indica un archivo de imagen, 0015948es el número estándar e 000000001indica la Organización Internacional de Normalización (ISO).
Otra forma menos popular de identificar el formato de un archivo es examinar el contenido del archivo en busca de patrones distinguibles entre los tipos de archivo. El contenido de un archivo es una secuencia de bytes y un byte tiene 256 permutaciones únicas (0-255). Por lo tanto, el recuento de la aparición de patrones de bytes, a menudo denominado distribución de frecuencia de bytes, proporciona patrones distinguibles para identificar los tipos de archivo. Existen muchos esquemas de identificación de tipos de archivo basados en el contenido que utilizan una distribución de frecuencia de bytes para construir los modelos representativos del tipo de archivo y utilizan cualquier técnica estadística y de minería de datos para identificar los tipos de archivo. [2]
Existen varios tipos de formas de estructurar los datos de un archivo. A continuación se describen las más habituales.
Los formatos de archivo anteriores utilizaban formatos de datos sin procesar que consistían en volcar directamente las imágenes de memoria de una o más estructuras en el archivo.
Esto tiene varios inconvenientes. A menos que las imágenes de memoria también tengan espacios reservados para futuras ampliaciones, ampliar y mejorar este tipo de archivos estructurados es muy difícil. Además, crea archivos que pueden ser específicos de una plataforma o lenguaje de programación (por ejemplo, una estructura que contiene una cadena Pascal no se reconoce como tal en C ). Por otro lado, desarrollar herramientas para leer y escribir este tipo de archivos es muy sencillo.
Las limitaciones de los formatos no estructurados llevaron al desarrollo de otros tipos de formatos de archivo que pudieran ampliarse fácilmente y ser compatibles con versiones anteriores al mismo tiempo.
En este tipo de estructura de archivos, cada pieza de datos se integra en un contenedor que de alguna manera identifica los datos. El alcance del contenedor se puede identificar mediante marcadores de inicio y fin de algún tipo, mediante un campo de longitud explícito en algún lugar o mediante requisitos fijos de la definición del formato de archivo.
A lo largo de la década de 1970, muchos programas utilizaban formatos de este tipo general. Por ejemplo, los procesadores de texto como troff , Script y Scribe , y los archivos de exportación de bases de datos como CSV . Electronic Arts y Commodore - Amiga también utilizaron este tipo de formato de archivo en 1985, con su formato de archivo IFF (Interchange File Format).
A veces se denomina "fragmento" a un contenedor , aunque "fragmento" también puede implicar que cada pieza es pequeña y/o que los fragmentos no contienen otros fragmentos; muchos formatos no imponen esos requisitos.
La información que identifica un "fragmento" en particular puede recibir muchos nombres diferentes, a menudo términos como "nombre de campo", "identificador", "etiqueta" o "etiqueta". Los identificadores suelen ser legibles por humanos y clasifican partes de los datos: por ejemplo, como "apellido", "dirección", "rectángulo", "nombre de fuente", etc. No son lo mismo que los identificadores en el sentido de una clave de base de datos o un número de serie (aunque un identificador puede identificar sus datos asociados como una clave de este tipo).
Con este tipo de estructura de archivos, las herramientas que no conocen determinados identificadores de fragmentos simplemente omiten aquellos que no comprenden. Según el significado real de los datos omitidos, esto puede resultar útil o no ( CSS define explícitamente este comportamiento).
Este concepto ha sido utilizado una y otra vez por RIFF (el equivalente de IFF de Microsoft-IBM), PNG, almacenamiento JPEG, secuencias y archivos codificados DER ( Reglas de codificación distinguidas ) (que se describieron originalmente en CCITT X.409:1984 y, por lo tanto, son anteriores a IFF) y Formato de intercambio de datos estructurados (SDXF) .
De hecho, cualquier formato de datos debe identificar de alguna manera el significado de sus partes componentes, y los marcadores de límites incorporados son una forma obvia de hacerlo:
Este es otro formato extensible, que se parece mucho a un sistema de archivos ( los documentos OLE son sistemas de archivos reales), donde el archivo está compuesto de "entradas de directorio" que contienen la ubicación de los datos dentro del archivo mismo, así como sus firmas (y en ciertos casos su tipo). Buenos ejemplos de este tipo de estructuras de archivos son las imágenes de disco , los ejecutables , los documentos OLE, TIFF y las bibliotecas .
Algunos formatos de archivos como ODT y DOCX, al estar basados en PKZIP , están fragmentados y llevan un directorio. [ cita requerida ]
La estructura de un formato de archivo basado en directorios se presta a modificaciones con mayor facilidad que los formatos no estructurados o basados en fragmentos. [ cita requerida ] La naturaleza de este tipo de formato permite a los usuarios construir cuidadosamente archivos que hacen que el software de lectura haga cosas que los autores del formato nunca tuvieron la intención de que sucedieran. Un ejemplo de esto es la bomba zip . Los formatos de archivo basados en directorios también utilizan valores que apuntan a otras áreas del archivo, pero si algún valor de datos posterior apunta a datos que se leyeron anteriormente, puede resultar en un bucle infinito para cualquier software de lectura que suponga que el archivo de entrada es válido y sigue el bucle ciegamente. [ cita requerida ]
