Extensión de nombre de archivo

Una extensión de nombre de archivo, extensión de nombre de archivo o extensión de archivo es un sufijo del nombre de un archivo de computadora (por ejemplo, .txt, .docx, .md). La extensión indica una característica del contenido del archivo o su uso previsto. Una extensión de nombre de archivo generalmente se delimita del resto del nombre de archivo con un punto (punto), pero en algunos sistemas se separa con espacios. Otros formatos de extensión incluyen guiones o guiones bajos en versiones anteriores de Linux y algunas versiones de IBM AIX.

Algunos sistemas de archivos implementan extensiones de nombre de archivo como una característica del propio sistema de archivos y pueden limitar la longitud y el formato de la extensión, mientras que otros tratan las extensiones de nombre de archivo como parte del nombre de archivo sin distinción especial.

Uso

Las extensiones de nombre de archivo pueden considerarse un tipo de metadatos. Se utilizan comúnmente para implicar información sobre la forma en que los datos pueden almacenarse en el archivo. La definición exacta, que proporciona los criterios para decidir qué parte del nombre del archivo es su extensión, pertenece a las reglas del sistema de archivos específico utilizado; por lo general, la extensión es la subcadena que sigue a la última aparición, si la hay, del carácter de punto (ejemplo: txt es la extensión del nombre de archivo readme.txt, y html la extensión de mysite.index.html). En los sistemas de archivos de algunos sistemas mainframe como CMS en VM, VMS y sistemas de PC como CP/M y sistemas derivados como MS-DOS, la extensión es un espacio de nombres separado del nombre de archivo. En DOS y Windows de Microsoft, las extensiones como EXE, COM o BAT indican que un archivo es un programa ejecutable. En OS/360 y sucesores, la parte del nombre del conjunto de datos que sigue al último punto, llamado calificador de bajo nivel, es tratado como una extensión por algún software, por ejemplo, TSO EDIT, pero no tiene un significado especial para el sistema operativo en sí; lo mismo se aplica a los archivos Unix en MVS.

Los sistemas de archivos para sistemas operativos tipo UNIX no separan los metadatos de la extensión del resto del nombre del archivo. El carácter de punto es solo otro carácter en el nombre de archivo principal. Un nombre de archivo puede no tener extensiones. A veces se dice que tiene más de una extensión, aunque la terminología varía al respecto, y la mayoría de los autores definen extensión de una manera que no permite más de una en el mismo nombre de archivo. Más de una extensión generalmente representa transformaciones anidadas, como files.tar.gz (.tar indica que el archivo es un archivo tar de uno o más archivos, y el .gz indica que el archivo tar está comprimido con gzip). Los programas que transforman o crean archivos pueden agregar la extensión adecuada a los nombres inferidos de los nombres de los archivos de entrada (a menos que se les dé explícitamente un nombre de archivo de salida), pero los programas que leen archivos generalmente ignoran la información; está destinado principalmente al usuario humano. Es más común, especialmente en archivos binarios, que el propio archivo contenga metadatos internos que describen su contenido. Este modelo generalmente requiere que se proporcione el nombre de archivo completo en los comandos, mientras que el enfoque de metadatos a menudo permite omitir la extensión.

Los sistemas de archivos VFAT, NTFS y ReFS para Windows tampoco separan los metadatos de la extensión del resto del nombre del archivo y permiten múltiples extensiones.

Con la llegada de las interfaces gráficas de usuario, surgió el problema de la gestión de archivos y el comportamiento de la interfaz. Microsoft Windows permitía asociar múltiples aplicaciones con una extensión determinada y había diferentes acciones disponibles para seleccionar la aplicación requerida, como un menú contextual que ofrecía la posibilidad de ver, editar o imprimir el archivo. La suposición aún era que cualquier extensión representaba un solo tipo de archivo; había un mapeo inequívoco entre la extensión y el icono.

El Mac OS clásico eliminó por completo los metadatos de extensión basados en nombres de archivo; en cambio, utilizó un código de tipo de archivo distinto para identificar el formato de archivo. Además, se especificó un código de creador para determinar qué aplicación se iniciaría cuando se hiciera doble clic en el icono del archivo. macOS, sin embargo, utiliza sufijos de nombre de archivo, así como códigos de tipo y creador, como consecuencia de su derivación del sistema operativo NeXTSTEP similar a UNIX.

Mejoras

La extensión del nombre de archivo se usó originalmente para determinar el tipo genérico del archivo. La necesidad de condensar el tipo de archivo en tres caracteres con frecuencia llevó a extensiones abreviadas. Los ejemplos incluyen el uso de .GFX para archivos gráficos, .TXT para texto sin formato y .MUS para música. Sin embargo, debido a que se han creado muchos programas de software diferentes que manejan estos tipos de datos (y otros) de diversas maneras, las extensiones de nombre de archivo comenzaron a asociarse estrechamente con ciertos productos, incluso con versiones específicas de productos. Por ejemplo, los primeros archivos de WordStar usaban .WS o .WSn, donde n era el programa' número de versión. Además, se desarrollaron usos conflictivos de algunas extensiones de nombre de archivo. Un ejemplo es .rpm, que se utiliza tanto para los paquetes de RPM Package Manager como para los archivos de RealPlayer Media;. Otros son .qif, compartidos por las fuentes DESQview, los libros contables financieros de Quicken y las imágenes de QuickTime; .gba, compartido por los scripts GrabIt y las imágenes ROM de Game Boy Advance; .sb, utilizado para SmallBasic y Scratch; y .dts, que se utilizan para Dynamix Three Space y DTS.

Algunos otros sistemas operativos que usaban extensiones de nombre de archivo generalmente tenían menos restricciones en los nombres de archivo. Muchos permitían longitudes de nombre de archivo completas de 14 o más caracteres, y las longitudes máximas de nombre de hasta 255 no eran infrecuentes. Los sistemas de archivos en sistemas operativos como Multics y UNIX almacenan el nombre del archivo como una sola cadena, no dividida en componentes de extensión y nombre base, lo que permite que el "." ser simplemente otro carácter permitido en los nombres de archivo. Dichos sistemas generalmente permiten nombres de archivo de longitud variable, lo que permite más de un punto y, por lo tanto, múltiples sufijos. Algunos componentes de Multics y UNIX, y las aplicaciones que se ejecutan en ellos, usaban sufijos, en algunos casos, para indicar tipos de archivos, pero no los usaban tanto; por ejemplo, los archivos ejecutables y de texto ordinarios no tenían sufijos en sus nombres.

El sistema de archivos de alto rendimiento (HPFS), utilizado en Microsoft y OS/2 de IBM, también admitía nombres de archivo largos y no dividía el nombre del archivo en un nombre y una extensión. La convención de usar sufijos continuó, aunque HPFS admitía atributos extendidos para archivos, lo que permitía almacenar el tipo de archivo en el archivo como un atributo extendido.

El sistema de archivos nativo de Windows NT de Microsoft, NTFS, admitía nombres de archivo largos y no dividía el nombre del archivo en un nombre y una extensión, pero nuevamente, la convención de usar sufijos para simular extensiones continuó, para la compatibilidad con las versiones existentes de Windows.

Cuando llegó la era de Internet, aquellos que usaban sistemas Windows que todavía estaban restringidos a formatos de nombre de archivo 8.3 tenían que crear páginas web con nombres que terminaran en .HTM, mientras que aquellos que usaban computadoras Macintosh o UNIX podían usar la extensión de nombre de archivo recomendada .html. Esto también se convirtió en un problema para los programadores que experimentaban con el lenguaje de programación Java, ya que requiere el sufijo de cuatro letras .java para los archivos de código fuente y el sufijo de cinco letras .class para archivos de salida de código de objeto del compilador de Java.

Finalmente, Windows 95 introdujo soporte para nombres de archivo largos y eliminó la división de nombre/extensión 8.3 en nombres de archivo de Windows que no es NT, en una versión extendida del sistema de archivos FAT de uso común llamado VFAT. VFAT apareció por primera vez en Windows NT 3.5 y Windows 95. La implementación interna de nombres de archivo largos en VFAT se considera en gran medida una chapuza, pero eliminó la importante restricción de longitud y permitió que los archivos tuvieran una combinación de letras mayúsculas y minúsculas, en máquinas que no ejecutarían bien Windows NT.

Problemas de nombre de comando

El uso de una extensión de nombre de archivo en el nombre de un comando aparece ocasionalmente, generalmente como un efecto secundario de que el comando se implementó como un script, por ejemplo, para Bourne shell o para Python, y el nombre del intérprete se agrega como sufijo al comando. nombre, una práctica común en los sistemas que se basan en asociaciones entre la extensión del nombre de archivo y el intérprete, pero muy desaprobada en sistemas similares a Unix, como Linux, Oracle Solaris, sistemas basados en BSD y macOS de Apple, donde el intérprete es normalmente se especifica como un encabezado en el script ("shebang").

En los sistemas basados en asociaciones, la extensión del nombre de archivo generalmente se asigna a una única selección de intérprete de todo el sistema para esa extensión (como ".py" que significa usar Python), y el comando en sí se puede ejecutar desde la línea de comandos incluso si se omite la extensión (suponiendo que se haya realizado la configuración adecuada). Si se cambia el idioma de implementación, la extensión del nombre del comando también cambia y el sistema operativo proporciona una API coherente al permitir que se use la misma versión sin extensión del comando en ambos casos. Este método adolece un poco de la naturaleza esencialmente global del mapeo de asociaciones, así como de los desarrolladores & # 39; evasión incompleta de extensiones al llamar a programas, y que los desarrolladores no pueden forzar esa evasión. Windows es el único empleador generalizado que queda de este mecanismo.

En los sistemas con directivas de intérprete, incluidas prácticamente todas las versiones de Unix, las extensiones de nombre de comando no tienen un significado especial y, por norma, no se utilizan, ya que el método principal para establecer intérpretes para scripts es comenzar con una sola línea que especifique el intérprete a usar (que podría verse como una bifurcación de recursos degenerada). En estos entornos, incluir la extensión en un nombre de comando expone innecesariamente un detalle de implementación que pone en riesgo futuro todas las referencias a los comandos de otros programas si la implementación cambia. Por ejemplo, sería perfectamente normal que un script de shell se vuelva a implementar en Python o Ruby, y luego en C o C++, todo lo cual cambiaría el nombre del comando si se usaran extensiones. Sin extensiones, un programa siempre tiene el mismo nombre sin extensión, solo cambia la directiva del intérprete y/o el número mágico, y las referencias al programa desde otros programas siguen siendo válidas.

Problemas de seguridad

El comportamiento predeterminado del Explorador de archivos, el explorador de archivos provisto con Microsoft Windows, es que no se muestren las extensiones de nombre de archivo. Los usuarios malintencionados han tratado de propagar virus y gusanos informáticos mediante el uso de nombres de archivos con la forma LOVE-LETTER-FOR-YOU.TXT.vbs. La esperanza es que aparezca como LOVE-LETTER-FOR-YOU.TXT, un archivo de texto inofensivo, sin alertar al usuario del hecho de que se trata de un programa informático dañino, en este caso, escrito en VBScript. El comportamiento predeterminado de ReactOS es mostrar las extensiones de nombre de archivo en ReactOS Explorer.

Las versiones posteriores de Windows (a partir de Windows XP Service Pack 2 y Windows Server 2003) incluían listas personalizables de extensiones de nombre de archivo que deberían considerarse "peligrosas" en ciertas "zonas" de operación, como cuando se descarga de la web o se recibe como un archivo adjunto de correo electrónico. Los sistemas de software antivirus modernos también ayudan a defender a los usuarios contra tales intentos de ataques cuando es posible.

Algunos virus se aprovechan de la similitud entre ".com" dominio de nivel superior y el ".COM" extensión de nombre de archivo mediante el envío por correo electrónico de archivos adjuntos de archivos de comandos ejecutables maliciosos con nombres superficialmente similares a direcciones URL (por ejemplo,, "myparty.yahoo.com"), con el efecto de que los usuarios inconscientes hagan clic en el correo electrónico -Enlaces incrustados que creen que conducen a sitios web pero que en realidad descargan y ejecutan los archivos adjuntos maliciosos.

Ha habido instancias de malware diseñado para explotar vulnerabilidades en algunas aplicaciones de Windows que podrían causar un desbordamiento del búfer basado en la pila al abrir un archivo con una extensión de nombre de archivo demasiado larga y no controlada.

La extensión del nombre de archivo es solo un marcador y el contenido del archivo no tiene por qué coincidir. Esto se puede usar para disfrazar contenido malicioso. Cuando se intenta identificar un archivo por razones de seguridad, se considera peligroso confiar únicamente en la extensión y se prefiere un análisis adecuado del contenido del archivo. Por ejemplo, en los sistemas derivados de UNIX, no es raro encontrar archivos sin ninguna extensión, ya que los comandos como archivo (comando) están destinados a usarse en su lugar y leerán el encabezado del archivo para determinar su contenido..

Alternativas

En muchos protocolos de Internet, como el correo electrónico HTTP y MIME, el tipo de flujo de bits se establece como el tipo de medio, o tipo MIME, del flujo, en lugar de una extensión de nombre de archivo. Esto se proporciona en una línea de texto que precede a la secuencia, como Content-type: text/plain.

No existe un mapeo estándar entre las extensiones de nombre de archivo y los tipos de medios, lo que genera posibles discrepancias en la interpretación entre autores, servidores web y software de cliente al transferir archivos a través de Internet. Por ejemplo, un autor de contenido puede especificar la extensión svgz para un archivo de gráficos vectoriales escalables comprimido, pero es posible que un servidor web que no reconozca esta extensión no envíe el tipo de contenido adecuado application/svg+ xml y su encabezado de compresión requerido, lo que hace que los navegadores web no puedan interpretar y mostrar correctamente la imagen.

BeOS, cuyo sistema de archivos BFS admite atributos extendidos, etiquetaría un archivo con su tipo de medio como un atributo extendido. Los entornos de escritorio KDE y GNOME asocian un tipo de medio con un archivo examinando tanto el sufijo del nombre de archivo como el contenido del archivo, al estilo del comando de archivo, como una heurística. Eligen la aplicación que se inicia cuando se abre un archivo en función de ese tipo de medio, lo que reduce la dependencia de las extensiones de nombre de archivo. macOS utiliza extensiones de nombre de archivo y tipos de medios, así como códigos de tipo de archivo, para seleccionar un identificador de tipo uniforme mediante el cual identificar el tipo de archivo internamente.