¿Es correcto usar ciertos caracteres especiales al nombrar nombres de archivos en Linux?


18

¿Es correcto el uso de ciertos caracteres especiales, como +, &, ', .(DOT) y ,(coma), básicamente, en los nombres de archivo.

Entiendo que puede usar -y _sin problemas, pero haciendo algunas investigaciones no he podido encontrar algo definitivo sobre los otros símbolos; algunos dicen que puedes, otros dicen que no puedes y otros dicen que "no se recomienda" usarlos (lo que sea que eso signifique).


¿Qué programas estás utilizando para trabajar con estos archivos? Solo los programas que interpretan algunos caracteres de una manera especial (p. Ej., Shells en cadenas sin comillas) darán problemas. Su programa C promedio toma todo lo que no es NUL sin pestañear.
Anthon

99
¿Qué quieres decir con "correcto"?
David Richerby

El problema con el uso de caracteres especiales en un nombre de archivo es que hacerlo aumenta la posibilidad de que algún código defectuoso maneje mal el nombre de archivo. Sin embargo, no creo que ninguno de los personajes que enumeró sea particularmente probable que cause algún problema. Tendría más problemas con los espacios en blanco, que generalmente deben evitarse . Y EOL, específicamente, debe evitarse a toda costa.

Windows tiene restricciones más estrictas sobre lo que puede estar en un nombre de archivo, por lo que si hay alguna posibilidad de que los archivos tengan que usarse allí, es algo a lo que debe prestar atención.
evilsoup

Respuestas:


28

¿Es correcto usar ciertos caracteres especiales, como +, &, ',. (punto) y, (coma), básicamente, en nombres de archivo.

Si.

Correcto pero no necesariamente aconsejable o conveniente.

Puede usar cualquier carácter excepto nulo y/ dentro de un nombre de archivo en los sistemas de archivos modernos de Unix y Linux.

Puede usar la puntuación ASCII . Algunas utilidades usan paradas ( punto ) y comas en los nombres de los archivos que crean.

Puede usar caracteres de control ASCII , sin embargo, esto no es aconsejable, ya que es poco probable que se muestren de manera aceptable y sean difíciles de usar.

Puede usar metacaracteres de shell , como ASCII ampersand y ASCII apostrophe. Sin embargo, esto es inconveniente y requiere que al construir comandos tenga especial cuidado en citar o escapar de dichos caracteres.

Puede usar caracteres de varios bytes usando una variedad de codificaciones. Depende del shell y / o las utilidades interpretar y mostrar correctamente los caracteres que no son ASCII. Es recomendable restringirse a una codificación popular como UTF-8 y establecer la configuración regional de manera adecuada.

Tendrá menos problemas al usar caracteres imprimibles ASCII, limitando el conjunto de caracteres de puntuación a los que no son metacaracteres de shell y no comienza un nombre con un guión (o una parada, a menos que desee ocultar el archivo).


23

Como han dicho los demás, en los sistemas Unix / Linux modernos, los nombres de archivo pueden contener cualquier carácter, excepto \0(NUL) y /(barra oblicua).

Además de eso, el estándar POSIX define un juego de caracteres portátil para nombres de archivos:

3.278 Juego de caracteres de nombre de archivo portátil

El conjunto de caracteres a partir del cual se construyen los nombres de archivos portátiles.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

Los últimos tres caracteres son los caracteres <period>, <underscore> y <hyphen>, respectivamente. Ver también Nombre de ruta .

La pathchkutilidad de GNU Coreutils verifica esto cuando se llama con la -popción, y la -Popción advierte sobre nombres de archivos vacíos (que no son válidos pero pueden pasarse como argumento pathchk) y nombres de archivos que comienzan con un guión ( -).


9

La apuesta más segura es consultar la entrada de Wikipedia para el conjunto de caracteres permitido para cualquier sistema operativo. Se puede encontrar desde aquí .

Por ejemplo, para la mayoría de los sistemas basados ​​en Unix, el conjunto de caracteres permitido es de 8 bits y el carácter reservado es el carácter nulo (NUL, '\0'). Sin embargo, no es una buena práctica usar los caracteres especiales en los nombres de los archivos, ya que representan un problema al eliminarlos.

Por ejemplo, puedo tener un nombre de archivo como -ramesh.txte intento eliminarlo como se muestra a continuación.

rm -ramesh.txt
rm: invalid option -- 'a'
Try `rm ./-ramesh.txt' to remove the file `-ramesh.txt'.
Try `rm --help' for more information.
rm "-ramesh.txt"
rm: invalid option -- 'a'
Try `rm ./-ramesh.txt' to remove the file `-ramesh.txt'.
Try `rm --help' for more information.

Necesito eliminar el archivo como,

rm -- "-ramesh.txt"
rm: remove regular empty file `-ramesh.txt'? y

Se pueden encontrar más detalles de esta respuesta también .

/Creo que en Linux y OS-X solo está prohibido el conjunto ASCII imprimible. Algunos caracteres (como los metacaracteres de shell *?!) causarán problemas en las líneas de comando y requerirán que el nombre de archivo se cite o se escape correctamente.

Los sistemas de archivos de Linux como ext2, ext3 son independientes del conjunto de caracteres (creo que simplemente lo tratan más o menos como una secuencia de bytes, solo nulos y /están prohibidos). Esto significa que puede almacenar nombres de archivo en codificación UTF-8. Creo que depende del shell u otra aplicación saber qué codificación usar para convertir correctamente el nombre de archivo para su visualización o procesamiento.

Para concluir, el problema no está en usar los caracteres especiales para los nombres de archivo sino en cómo manejarlos.


Por esa razón ("cómo manejarlos"), uso casi exclusivamente solo letras, números, guiones bajos y puntos, aunque solo sea para hacerme la vida más fácil cuando más tarde decido que necesito usar programas de línea de comandos para hacer cosas en mis archivos (que parece aparecer siempre al menos una vez).
phyrfox

19
No para abogar por los nombres de archivo que comienzan con, -sino solo para ser precisos: 1) definitivamente no necesita las comillas alrededor de este nombre de archivo, 2) en lugar de usar el --argumento especial , puede hacer exactamente lo que rmsugiere: rm ./-ramesh.txtasí que no necesita hacerlo exactamente como sugieres.
Michał Politowski

@ MichałPolitowski No solo no necesita las comillas, tienen exactamente cero efecto.
ctrl-alt-delor

4

Su investigación es casi correcta. Es posible usar caracteres especiales en los nombres de archivo, pero no es aconsejable ya que estos caracteres tienen un significado especial. Las convenciones de nomenclatura de archivos en Linux describen otras restricciones en los nombres de archivos, como "Los nombres de archivos nunca deben comenzar con un guión".

Ejemplo simple de realizar operaciones de línea de comando con caracteres especiales en los nombres de archivo.

Como nota personal, prefiero evitar caracteres especiales en los nombres de los archivos porque requieren atención especial cuando estos archivos se utilizan para cualquier procesamiento. Por lo tanto, elimina la preocupación de tratar con caracteres especiales del proceso de desarrollo.


1
Así que su consejo sería utilizar solamente -, _y .(DOT) en los nombres de archivo?
Chris Klein

@ChrisKlein, sí, aunque no al principio del nombre del archivo.
Simply_Me

Hay un significado especial en el programa (por ejemplo, su shell), no en el nombre del archivo. Casi todos los programas en T & L no se preocupan por los personajes en absoluto , siempre y cuando no hay un NUL en el nombre de archivo.
Anthon

@Anthon, sí, mi shell como se describe en el enlace.
Simply_Me

2
Como nota personal, recomendaría a los desarrolladores nombrar la carpeta principal de su proyecto como "föλder \ t☃", para que se den cuenta de inmediato si cometen un error que se rompe en dichos nombres de archivos, en lugar de publicar códigos o binarios rotos que otros tienen que evitar. Usarlo no es un problema, siempre que sea el único que comience con 'f', la finalización de pestañas en cualquier shell introducirá las cosas difíciles de escribir.
Peteris
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.