Un nombre de archivo o nombre de archivo es un nombre utilizado para identificar de forma única un archivo de computadora en un sistema de archivos . Los diferentes sistemas de archivos imponen diferentes restricciones sobre la longitud de los nombres de archivos.
Un nombre de archivo puede (según el sistema de archivos) incluir:
.txt
para texto sin formato ,.pdf
para formato de documento portátil ,.dat
para datos binarios no especificados, etc.)Los componentes necesarios para identificar un archivo mediante utilidades y aplicaciones varían según el sistema operativo, al igual que la sintaxis y el formato de un nombre de archivo válido.
Los caracteres permitidos en los nombres de archivos dependen del sistema de archivos. La mayoría de los sistemas de archivos permiten las letras de la A a la Z y los dígitos del 0 al 9; Muchos sistemas de archivos admiten caracteres adicionales, como las letras a–z, caracteres especiales y otros caracteres imprimibles, como letras acentuadas, símbolos en alfabetos no romanos y símbolos en escrituras no alfabéticas. Algunos sistemas de archivos permiten que incluso caracteres no imprimibles, incluidos Bell , Null , Return y Linefeed , formen parte de un nombre de archivo, [1] aunque la mayoría de las utilidades no los manejan bien.
Los nombres de archivos pueden incluir elementos como un número de revisión o generación del archivo, como un código de computadora , un número de secuencia numérica (ampliamente utilizado por las cámaras digitales a través del estándar DCF ), una fecha y hora (ampliamente utilizada por el software de la cámara de los teléfonos inteligentes y para capturas de pantalla ), o un comentario como el nombre de un tema o una ubicación o cualquier otro texto para ayudar a identificar el archivo.
Algunas personas usan el término nombre de archivo cuando se refieren a una especificación completa de dispositivo, subdirectorios y nombre de archivo, como Windows C:\Program Files\Microsoft Games\Chess\Chess.exe . El nombre del archivo en este caso es Chess.exe . Algunas utilidades tienen configuraciones para suprimir la extensión como ocurre con MS Windows Explorer. [ no verificado en el cuerpo ]
Durante la década de 1970, algunas computadoras centrales y minicomputadoras tenían sistemas operativos donde los archivos del sistema se identificaban por un nombre de usuario o número de cuenta.
Por ejemplo, en los sistemas operativos TOPS-10 y RSTS/E de Digital Equipment Corporation , los archivos se identificaban por
En los sistemas operativos OS/VS1 , MVS y OS/390 de IBM , un nombre de archivo tenía hasta 44 caracteres y constaba de letras mayúsculas, dígitos y un punto. Un nombre de archivo debe comenzar con una letra o un número, un punto debe aparecer al menos una vez cada 8 caracteres, no pueden aparecer dos puntos consecutivos en el nombre y debe terminar con una letra o un dígito. [2] Por convención, las letras y números antes del primer punto eran el número de cuenta del propietario o del proyecto al que pertenecía, pero no era necesario utilizar esta convención. [3]
En el sistema MUSIC/SP de la Universidad McGill , los nombres de archivos consistían en
El sistema operativo Univac VS/9 tenía nombres de archivos que consistían en
En 1985, RFC 959 definió oficialmente un nombre de ruta como la cadena de caracteres que un usuario debe ingresar en un sistema de archivos para identificar un archivo. [4]
En las primeras computadoras personales que usaban el sistema operativo CP/M , los nombres de archivos siempre tenían 11 caracteres. Esto se denominó nombre de archivo 8.3 con un nombre de un máximo de 8 bytes y una extensión máxima de 3 bytes. Las utilidades y aplicaciones permitían a los usuarios especificar nombres de archivos sin espacios finales e incluir un punto antes de la extensión. En realidad, el punto no se almacenó en el directorio. El uso de solo caracteres de 7 bits permitió incluir varios atributos de archivo en el nombre de archivo real mediante el uso del bit de orden superior; estos atributos incluían Sólo lectura, Archivo y Sistema. [5] Con el tiempo, esto resultó demasiado restrictivo y el número de caracteres permitidos aumentó. Los bits de atributos se movieron a un bloque especial del archivo que incluye información adicional. [ cita necesaria ]
El sistema de archivos original File Allocation Table (FAT), utilizado por Standalone Disk BASIC-80 , tenía un nombre de archivo 6.3, con un máximo de 6 bytes en el nombre y un máximo de 3 bytes en la extensión. Los sistemas de archivos FAT12 y FAT16 en IBM PC DOS / MS-DOS y Microsoft Windows anteriores a Windows 95 usaban la misma convención 8.3 que el sistema de archivos CP/M. Los sistemas de archivos FAT admitían caracteres de 8 bits, lo que les permitía admitir caracteres no ASCII en los nombres de archivos y almacenaban los atributos por separado del nombre del archivo.
Alrededor de 1995, VFAT , una extensión del sistema de archivos FAT de MS-DOS, se introdujo en Windows 95 y Windows NT . Permitía nombres de archivos largos en mayúsculas y minúsculas (LFN), utilizando caracteres Unicode , además de los nombres clásicos "8.3".
Una referencia absoluta incluye todos los niveles de directorio. En algunos sistemas, una referencia de nombre de archivo que no incluye la ruta completa del directorio toma como valor predeterminado el directorio de trabajo actual . Esta es una referencia relativa. Una ventaja de utilizar una referencia relativa en scripts o archivos de configuración de programas es que diferentes instancias del script o programa pueden utilizar archivos diferentes.
Esto crea una ruta absoluta o relativa compuesta por una secuencia de nombres de archivos.
Los sistemas de archivos tipo Unix permiten que un archivo tenga más de un nombre; en los sistemas de archivos tradicionales de estilo Unix, los nombres son enlaces físicos al inodo del archivo o equivalente. Windows admite enlaces físicos en sistemas de archivos NTFS y proporciona el comando fsutil
en Windows XP y mklink
en versiones posteriores para crearlos. [6] [7] Los enlaces físicos son diferentes de los accesos directos de Windows, los alias clásicos de Mac OS/macOS o los enlaces simbólicos . La introducción de LFN con VFAT permitió alias de nombres de archivos. Por ejemplo, longfi~1.???
con un máximo de ocho más tres caracteres había un alias de nombre de archivo de " long file name.???
" como una forma de cumplir con las limitaciones de 8.3 para programas más antiguos.
Esta propiedad fue utilizada por el algoritmo del comando de movimiento que primero crea un segundo nombre de archivo y luego solo elimina el primer nombre de archivo.
Otros sistemas de archivos, por diseño, proporcionan solo un nombre de archivo por archivo, lo que garantiza que la alteración del archivo de un nombre de archivo no altere el archivo del otro nombre.
Algunos sistemas de archivos restringen la longitud de los nombres de archivos. En algunos casos, estas longitudes se aplican a todo el nombre del archivo, como en 44 caracteres en IBM z/OS . [2] En otros casos, los límites de longitud pueden aplicarse a partes particulares del nombre del archivo, como el nombre de un archivo en un directorio o el nombre de un directorio. Por ejemplo, 9 (p. ej., FAT de 8 bits en Standalone Disk BASIC ), 11 (p. ej., FAT12 , FAT16 , FAT32 en DOS), 14 (p. ej., Unix temprano), 21 ( Human68K ), 31, 30 (p. ej., Apple DOS 3.2 y 3.3), 15 (por ejemplo, Apple ProDOS ), 44 (por ejemplo, IBM S/370), [2] o 255 (por ejemplo, los primeros Berkeley Unix) caracteres o bytes. Los límites de longitud a menudo resultan de la asignación de un espacio fijo en un sistema de archivos para almacenar componentes de nombres, por lo que aumentar los límites a menudo requiere un cambio incompatible, además de reservar más espacio.
Un problema particular con los sistemas de archivos que almacenan información en directorios anidados es que puede ser posible crear un archivo con una ruta de acceso completa que exceda los límites de implementación, ya que la verificación de longitud puede aplicarse solo a partes individuales del nombre en lugar del nombre completo. Muchas aplicaciones de Windows están limitadas a un MAX_PATH
valor de 260, pero los nombres de archivos de Windows pueden superar fácilmente este límite. [8] Desde Windows 10, versión 1607 , se eliminaron las limitaciones de MAX_PATH. [9]
Los nombres de archivos en algunos sistemas de archivos, como FAT y los niveles ODS-1 y ODS-2 de Files-11 , se componen de dos partes: un nombre base o raíz y una extensión o sufijo utilizado por algunas aplicaciones para indicar el tipo de archivo . Algunos otros sistemas de archivos, como los sistemas de archivos Unix , VFAT y NTFS , tratan un nombre de archivo como una sola cadena; Una convención que se utiliza a menudo en esos sistemas de archivos es tratar los caracteres que siguen al último punto del nombre del archivo, en un nombre de archivo que contiene puntos, como la parte de extensión del nombre del archivo.
Varios archivos de salida creados por una aplicación pueden usar el mismo nombre base y varias extensiones. Por ejemplo, un compilador de Fortran podría usar la extensión FOR
para el archivo de entrada fuente, OBJ
para la salida del objeto y LST
para el listado. Aunque existen algunas extensiones comunes, son arbitrarias y una aplicación diferente podría usar REL
y RPT
. Las extensiones han estado restringidas, al menos históricamente en algunos sistemas, a una longitud de 3 caracteres, pero en general pueden tener cualquier longitud, por ejemplo, html
.
No existe un estándar de codificación general para nombres de archivos.
Los nombres de los archivos deben intercambiarse entre entornos de software para la transferencia de archivos en red, el almacenamiento del sistema de archivos, el software de copia de seguridad y sincronización de archivos, la gestión de la configuración, la compresión y el archivado de datos, etc. Por lo tanto, es muy importante no perder la información de los nombres de los archivos entre aplicaciones. Esto llevó a una amplia adopción de Unicode como estándar para codificar nombres de archivos, aunque es posible que el software heredado no sea compatible con Unicode.
Tradicionalmente, los nombres de archivos permitían cualquier carácter en sus nombres siempre que fueran seguros para el sistema de archivos. [10] Aunque esto permitió el uso de cualquier codificación y, por lo tanto, permitió la representación de cualquier texto local en cualquier sistema local, causó muchos problemas de interoperabilidad.
Un nombre de archivo podría almacenarse usando diferentes cadenas de bytes en distintos sistemas dentro de un solo país, como si uno usara codificación Shift JIS japonesa y otra codificación EUC japonesa . La conversión no fue posible ya que la mayoría de los sistemas no exponían una descripción de la codificación utilizada para un nombre de archivo como parte de la información extendida del archivo. Esto obligó a adivinar costosas codificaciones de nombres de archivos con cada acceso al archivo. [10]
Una solución fue adoptar Unicode como codificación para los nombres de archivos.
Sin embargo, en el Mac OS clásico, la codificación del nombre del archivo se almacenaba con los atributos del nombre del archivo. [10]
El estándar Unicode resuelve el problema de determinación de codificación.
No obstante, persisten algunos problemas de interoperabilidad limitados, como la normalización (equivalencia) o la versión Unicode en uso. Por ejemplo, UDF está limitado a Unicode 2.0; El sistema de archivos HFS+ de macOS aplica la normalización NFD Unicode y, opcionalmente, distingue entre mayúsculas y minúsculas (no distingue entre mayúsculas y minúsculas de forma predeterminada). La longitud máxima del nombre de archivo no es estándar y puede depender del tamaño de la unidad de código. Aunque es un problema grave, en la mayoría de los casos es limitado. [10]
En Linux, esto significa que el nombre del archivo no es suficiente para abrir un archivo: además, se necesita la representación exacta en bytes del nombre del archivo en el dispositivo de almacenamiento. Esto se puede resolver a nivel de aplicación, con algunas llamadas de normalización complicadas. [11]
La cuestión de la equivalencia Unicode se conoce como "colisión de nombres normalizados". Una solución es el reconocimiento de composición Unicode no normalizado que se utiliza en las comunidades técnicas de Subversion y Apache. [12] Esta solución no normaliza las rutas en el repositorio. Las rutas solo se normalizan con fines de comparación. Sin embargo, algunas comunidades han patentado esta estrategia, prohibiendo su uso por otras comunidades. [ se necesita aclaración ]
Para limitar los problemas de interoperabilidad, algunas ideas descritas por Sun son:
Esas consideraciones crean una limitación que no permite un cambio a una codificación futura diferente a UTF-8.
Un problema fue la migración a Unicode. Para ello, varias empresas de software proporcionaron software para migrar nombres de archivos a la nueva codificación Unicode.
Mac OS X 10.3 marcó la adopción por parte de Apple de la descomposición de caracteres Unicode 3.2, reemplazando la descomposición Unicode 2.1 utilizada anteriormente. Este cambio causó problemas a los desarrolladores que escribían software para Mac OS X. [15]
Dentro de un único directorio, los nombres de archivos deben ser únicos. Dado que la sintaxis del nombre de archivo también se aplica a los directorios, no es posible crear un archivo y entradas de directorio con el mismo nombre en un solo directorio. Varios archivos en diferentes directorios pueden tener el mismo nombre.
El enfoque de unicidad puede diferir tanto en la distinción entre mayúsculas y minúsculas como en la forma de normalización Unicode, como NFC, NFD. Esto significa que se pueden crear dos archivos separados con el mismo nombre de archivo de texto y una implementación de bytes diferente del nombre de archivo, como L"\x00C0.txt" (UTF-16, NFC) (A mayúscula latina con tumba) y L"\x0041 \x0300.txt" (UTF-16, NFD) (A mayúscula latina, combinación de graves). [dieciséis]
Algunos sistemas de archivos, como FAT , almacenan los nombres de archivos en mayúsculas, independientemente de la letra utilizada para crearlos. Por ejemplo, un archivo creado con el nombre "MiNombre.Txt" o "minombre.txt" se almacenaría con el nombre de archivo "MINOMBRE.TXT". Se puede utilizar cualquier variación de mayúsculas y minúsculas para hacer referencia al mismo archivo. Estos tipos de sistemas de archivos se denominan que no distinguen entre mayúsculas y minúsculas y no preservan las mayúsculas y minúsculas . Algunos sistemas de archivos prohíben por completo el uso de letras minúsculas en los nombres de archivos.
Algunos sistemas de archivos almacenan nombres de archivos en la forma en que fueron creados originalmente; estos se conocen como retentivos o preservadores de casos . Un sistema de archivos de este tipo puede distinguir entre mayúsculas y minúsculas o no . Si distingue entre mayúsculas y minúsculas, entonces "MiNombre.Txt" y "minombre.txt" pueden hacer referencia a dos archivos diferentes en el mismo directorio, y se debe hacer referencia a cada archivo con las mayúsculas exactas con las que se nombra. Por otro lado, en un sistema de archivos que no distingue entre mayúsculas y minúsculas y las preserva, sólo uno de "MiNombre.Txt", "minombre.txt" y "Minombre.TXT" puede ser el nombre de un archivo en un directorio determinado en un en un momento dado, y se puede hacer referencia a un archivo con uno de estos nombres mediante cualquier mayúscula del nombre.
Desde sus inicios, Unix y sus sistemas derivados preservaban las mayúsculas y minúsculas. Sin embargo, no todos los sistemas de archivos tipo Unix distinguen entre mayúsculas y minúsculas; De forma predeterminada, HFS+ en macOS no distingue entre mayúsculas y minúsculas, y los servidores SMB generalmente ofrecen un comportamiento que no distingue entre mayúsculas y minúsculas (incluso cuando el sistema de archivos subyacente distingue entre mayúsculas y minúsculas, por ejemplo, Samba en la mayoría de los sistemas tipo Unix), y los sistemas de archivos del cliente SMB sí distinguen entre mayúsculas y minúsculas. comportamiento insensible. La distinción entre mayúsculas y minúsculas en los sistemas de archivos es un desafío considerable para software como Samba y Wine , que deben interoperar eficientemente tanto con sistemas que tratan archivos en mayúsculas y minúsculas como diferentes y con sistemas que los tratan de la misma manera. [17]
Los sistemas de archivos no siempre han proporcionado el mismo juego de caracteres para componer un nombre de archivo. Antes de que Unicode se convirtiera en un estándar de facto, los sistemas de archivos utilizaban principalmente un conjunto de caracteres dependiente de la configuración regional. Por el contrario, algunos sistemas nuevos permiten que un nombre de archivo esté compuesto por casi cualquier carácter del repertorio Unicode, e incluso algunas secuencias de bytes que no sean Unicode. Las limitaciones pueden ser impuestas por el sistema de archivos, el sistema operativo, la aplicación o los requisitos de interoperabilidad con otros sistemas.
Muchas utilidades del sistema de archivos prohíben que aparezcan caracteres de control en los nombres de archivos. En los sistemas de archivos tipo Unix, elEl carácter nulo [18] y el separador de ruta /
están prohibidos.
Las utilidades del sistema de archivos y las convenciones de nomenclatura en varios sistemas prohíben que determinados caracteres aparezcan en los nombres de archivos o los hacen problemáticos: [8] Salvo que se indique lo contrario, los símbolos en la columna Carácter , " y < , por ejemplo, no se pueden usar en nombres de archivos de Windows.
Nota 1: Si bien están permitidos en los nombres de archivos y carpetas de Unix, la mayoría de los shells de Unix requieren caracteres específicos como espacios, <, >, |, \ y, a veces, :, (, ), &, ;, #, así como comodines. como ? y *, para citar o escapar :
five\ and\ six\<seven
(ejemplo de escape)'five and six<seven'
o"five and six<seven"
(ejemplos de cotización)
El carácter å ( 0xE5
) no estaba permitido como primera letra en un nombre de archivo en 86-DOS y MS-DOS/PC DOS 1.x-2.x, pero se puede utilizar en versiones posteriores.
En las utilidades de Windows, el espacio y el punto no están permitidos como carácter final de un nombre de archivo. [19] El punto está permitido como primer carácter, pero algunas aplicaciones de Windows, como Windows Explorer , prohíben crear o cambiar el nombre de dichos archivos (a pesar de que esta convención se usa en sistemas tipo Unix para describir archivos y directorios ocultos). Las soluciones alternativas incluyen agregar un punto al cambiar el nombre del archivo (que luego se elimina automáticamente), usar administradores de archivos alternativos , crear el archivo usando la línea de comando o guardar un archivo con el nombre deseado desde una aplicación. [20]
Algunos sistemas de archivos en un sistema operativo determinado (especialmente los sistemas de archivos implementados originalmente en otros sistemas operativos) y aplicaciones particulares en ese sistema operativo pueden aplicar restricciones e interpretaciones adicionales. Consulte la comparación de sistemas de archivos para obtener más detalles sobre las restricciones.
En sistemas tipo Unix, DOS y Windows, los nombres de archivo "." y ".." tienen significados especiales (directorio actual y principal respectivamente). Windows 95/98/ME también utiliza nombres como "...", "...." y así sucesivamente para indicar directorios abuelos o bisabuelos. [21] Todas las versiones de Windows prohíben la creación de nombres de archivos que constan únicamente de puntos, aunque los nombres que constan de tres puntos ("...") o más son legales en Unix.
Además, en las utilidades de Windows y DOS, algunas palabras también están reservadas y no pueden usarse como nombres de archivos. [20] Por ejemplo, archivos de dispositivo DOS : [22]
CON, CONIN$, CONOUT$, PRN, AUX, RELOJ$, NULCOM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 [8] LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 [8] LST (sólo en 86- DOS y DOS 1.xx)KEYBD$, SCREEN$ (sólo en multitarea MS-DOS 4.0 )$IDLE$ (solo en DOS concurrente 386 , DOS multiusuario y DR DOS 5.0 y superior)CONFIG$ (sólo en MS-DOS 7.0-8.0)
Los sistemas que tienen estas restricciones provocan incompatibilidades con algunos otros sistemas de archivos. Por ejemplo, Windows no podrá manejar o generar informes de error para estos nombres de archivos UNIX legales: aux.c, [23] q"uote"s.txt o NUL.txt.
Los nombres de archivos NTFS que se utilizan internamente incluyen:
$Mft, $MftMirr, $LogFile, $Volumen, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure,$Upcase, $Extend, $Quota, $ObjId y $Reparse