¿Qué caracteres están prohibidos en los nombres de directorio de Windows y Linux?

Sé que / es ilegal en Linux, y lo siguiente es ilegal en Windows (creo) * . " / \ [ ] : ; | ,

¿Qué más me estoy perdiendo?

Sin embargo, necesito una guía completa que tenga en cuenta los caracteres de doble byte. Vincular a recursos externos está bien para mí.

Primero necesito crear un directorio en el sistema de archivos usando un nombre que pueda contener caracteres prohibidos, así que planeo reemplazar esos caracteres con guiones bajos. Luego necesito escribir este directorio y su contenido en un archivo zip (usando Java), por lo que cualquier consejo adicional sobre los nombres de los directorios zip sería apreciado.

Una "guía completa" de caracteres de nombre de archivo prohibidos no funcionará en Windows porque reserva nombres de archivo y caracteres. Sí, los caracteres como * " ?y otros están prohibidos, pero hay un número infinito de nombres compuestos solo por caracteres válidos que están prohibidos. Por ejemplo, los espacios y puntos son caracteres válidos de nombre de archivo, pero los nombres compuestos solo por esos caracteres están prohibidos.

Windows no distingue entre mayúsculas y minúsculas, por lo que no puede crear una carpeta con nombre Asi aya existe una con nombre . Peor, los nombres aparentemente permitidos como PRNy CON, y muchos otros, están reservados y no permitidos. Windows también tiene varias restricciones de longitud; un nombre de archivo válido en una carpeta puede volverse inválido si se mueve a otra carpeta. Las reglas para nombrar archivos y carpetas están en los documentos de Microsoft.

En general, no puede usar texto generado por el usuario para crear nombres de directorio de Windows. Si desea permitir a los usuarios a nombre de todo lo que quieran, hay que crear nombres seguros como A, AB, A2et al., Nombres de las tiendas generados por los usuarios y sus equivalentes de ruta en un archivo de datos de la aplicación, y realizar el mapeo de ruta en su aplicación.

Si absolutamente debe permitir nombres de carpetas generados por el usuario, la única forma de saber si son inválidos es detectar excepciones y asumir que el nombre no es válido. Incluso eso está plagado de peligros, ya que las excepciones lanzadas para el acceso denegado, las unidades fuera de línea y el espacio fuera de la unidad se superponen con las que se pueden lanzar por nombres no válidos. Estás abriendo una enorme lata de dolor.

Hagámoslo simple y respondamos la pregunta primero.

1. Los caracteres ASCII imprimibles prohibidos son:

   • Linux / Unix:

     / (forward slash)
     

   • Ventanas:

     < (less than)
     > (greater than)
     : (colon - sometimes works, but is actually NTFS Alternate Data Streams)
     " (double quote)
     / (forward slash)
     \ (backslash)
     | (vertical bar or pipe)
     ? (question mark)
     * (asterisk)
     

2. Caracteres no imprimibles

   Si sus datos provienen de una fuente que permitiría caracteres no imprimibles, entonces hay más para verificar.

   • Linux / Unix:

     0 (NULL byte)
     

   • Ventanas:

     0-31 (ASCII control characters)
     

   Nota: Si bien es legal bajo los sistemas de archivos Linux / Unix crear archivos con caracteres de control en el nombre del archivo, puede ser una pesadilla para los usuarios tratar con dichos archivos .

3. Nombres de archivo reservados

   Los siguientes nombres de archivo están reservados:

   • Ventanas:

     CON, PRN, AUX, NUL 
     COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
     LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
     

     (tanto solos como con extensiones de archivo arbitrarias, por ejemplo LPT1.txt).

4. Otras reglas

   • Ventanas:

     Los nombres de archivo no pueden terminar en un espacio o punto.

Bajo Linux y otros sistemas relacionados con Unix, solo hay dos caracteres que no pueden aparecer en el nombre de un archivo o directorio, y esos son NUL '\0'y barra oblicua '/'. La barra oblicua, por supuesto, puede aparecer en un nombre de ruta, separando los componentes del directorio.

El rumor ¹ dice que Steven Bourne (de fama 'shell') tenía un directorio que contenía 254 archivos, uno por cada letra (código de carácter) que puede aparecer en un nombre de archivo (excluyendo /, '\0'el nombre .era el directorio actual, por supuesto ) Se usó para probar el shell Bourne y ocasionar estragos en programas incautos como los programas de respaldo.

Otras personas han cubierto las reglas de Windows.

Tenga en cuenta que MacOS X tiene un sistema de archivos que no distingue entre mayúsculas y minúsculas.

Cuando Steve Bourne estaba escribiendo su shell de Unix (que se conoció como el shell de Bourne), creó un directorio de 254 archivos con nombres de un carácter, uno para cada valor de byte excepto '\0'y barra, los dos caracteres que no pueden aparecer en Unix nombres de archivo Utilizó ese directorio para todo tipo de pruebas de coincidencia de patrones y tokenización. (El directorio de prueba, por supuesto, fue creado por un programa). Durante años después, ese directorio fue la ruina de los programas de caminar por el árbol de archivos; los probó a la destrucción.

^{Tenga en cuenta que el directorio debe haber contenido entradas .y .., por lo tanto, podría decirse que eran 253 archivos (y 2 directorios) o 255 entradas de nombre, en lugar de 254 archivos. Esto no afecta la efectividad de la anécdota o las pruebas cuidadosas que describe.}

En lugar de crear una lista negra de caracteres, puede usar una lista blanca . A fin de cuentas, el rango de caracteres que tiene sentido en un contexto de nombre de archivo o directorio es bastante corto, y a menos que tenga algunos requisitos de nomenclatura muy específicos, sus usuarios no lo incluirán en su aplicación si no pueden usar toda la tabla ASCII.

No resuelve el problema de los nombres reservados en el sistema de archivos de destino, pero con una lista blanca es más fácil mitigar los riesgos en la fuente.

En ese espíritu, esta es una gama de personajes que pueden considerarse seguros:

• Letras (az AZ) : caracteres Unicode también, si es necesario
• Dígitos (0-9)
• Guion bajo (_)
• Guión (-)
• Espacio
• Punto (.)

Y cualquier personaje seguro adicional que desee permitir. Más allá de esto, solo tiene que aplicar algunas reglas adicionales con respecto a espacios y puntos . Esto suele ser suficiente:

• El nombre debe contener al menos una letra o número (para evitar solo puntos / espacios)
• El nombre debe comenzar con una letra o número (para evitar puntos / espacios iniciales)
• El nombre puede no terminar con un punto o espacio (simplemente recorte esos si están presentes, como lo hace Explorer)

Esto ya permite nombres bastante complejos y sin sentido. Por ejemplo, estos nombres serían posibles con estas reglas y serían nombres de archivo válidos en Windows / Linux:

• A...........ext
• B -.- .ext

En esencia, incluso con tan pocos caracteres en la lista blanca, aún debe decidir qué tiene sentido y validar / ajustar el nombre en consecuencia. En una de mis aplicaciones, utilicé las mismas reglas que antes pero eliminé los puntos y espacios duplicados.

La manera fácil de hacer que Windows le diga la respuesta es intentar cambiar el nombre de un archivo a través del Explorador y escribir / para el nuevo nombre. Windows abrirá un cuadro de mensaje que le indicará la lista de caracteres ilegales.

A filename cannot contain any of the following characters:
    \ / : * ? " < > | 

https://support.microsoft.com/en-us/kb/177506

Bueno, aunque solo sea para fines de investigación, entonces su mejor opción es mirar esta entrada de Wikipedia sobre nombres de archivos .

Si desea escribir una función portátil para validar la entrada del usuario y crear nombres de archivo basados ​​en eso, la respuesta corta es no . Eche un vistazo a un módulo portátil como Perl's File :: Spec para echar un vistazo a todos los saltos necesarios para realizar una tarea tan "simple".

Para Windows puede verificarlo usando PowerShell

$PathInvalidChars = [System.IO.Path]::GetInvalidPathChars() #36 chars

Para mostrar códigos UTF-8, puede convertir

$enc = [system.Text.Encoding]::UTF8
$PathInvalidChars | foreach { $enc.GetBytes($_) }

$FileNameInvalidChars = [System.IO.Path]::GetInvalidFileNameChars() #41 chars

$FileOnlyInvalidChars = @(':', '*', '?', '\', '/') #5 chars - as a difference

En Windows 10 (2019), los siguientes caracteres están prohibidos por un error cuando intenta escribirlos:

Un nombre de archivo no puede contener ninguno de los siguientes caracteres:

\ / : * ? " < > |

Aquí está la implementación de ac # para Windows basada en la respuesta de Christopher Oezbek

Se hizo más complejo por el booleano contiene carpeta, pero es de esperar que cubra todo

/// <summary>
/// This will replace invalid chars with underscores, there are also some reserved words that it adds underscore to
/// </summary>
/// <remarks>
/// /programming/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names
/// </remarks>
/// <param name="containsFolder">Pass in true if filename represents a folder\file (passing true will allow slash)</param>
public static string EscapeFilename_Windows(string filename, bool containsFolder = false)
{
    StringBuilder builder = new StringBuilder(filename.Length + 12);

    int index = 0;

    // Allow colon if it's part of the drive letter
    if (containsFolder)
    {
        Match match = Regex.Match(filename, @"^\s*[A-Z]:\\", RegexOptions.IgnoreCase);
        if (match.Success)
        {
            builder.Append(match.Value);
            index = match.Length;
        }
    }

    // Character substitutions
    for (int cntr = index; cntr < filename.Length; cntr++)
    {
        char c = filename[cntr];

        switch (c)
        {
            case '\u0000':
            case '\u0001':
            case '\u0002':
            case '\u0003':
            case '\u0004':
            case '\u0005':
            case '\u0006':
            case '\u0007':
            case '\u0008':
            case '\u0009':
            case '\u000A':
            case '\u000B':
            case '\u000C':
            case '\u000D':
            case '\u000E':
            case '\u000F':
            case '\u0010':
            case '\u0011':
            case '\u0012':
            case '\u0013':
            case '\u0014':
            case '\u0015':
            case '\u0016':
            case '\u0017':
            case '\u0018':
            case '\u0019':
            case '\u001A':
            case '\u001B':
            case '\u001C':
            case '\u001D':
            case '\u001E':
            case '\u001F':

            case '<':
            case '>':
            case ':':
            case '"':
            case '/':
            case '|':
            case '?':
            case '*':
                builder.Append('_');
                break;

            case '\\':
                builder.Append(containsFolder ? c : '_');
                break;

            default:
                builder.Append(c);
                break;
        }
    }

    string built = builder.ToString();

    if (built == "")
    {
        return "_";
    }

    if (built.EndsWith(" ") || built.EndsWith("."))
    {
        built = built.Substring(0, built.Length - 1) + "_";
    }

    // These are reserved names, in either the folder or file name, but they are fine if following a dot
    // CON, PRN, AUX, NUL, COM0 .. COM9, LPT0 .. LPT9
    builder = new StringBuilder(built.Length + 12);
    index = 0;
    foreach (Match match in Regex.Matches(built, @"(^|\\)\s*(?<bad>CON|PRN|AUX|NUL|COM\d|LPT\d)\s*(\.|\\|$)", RegexOptions.IgnoreCase))
    {
        Group group = match.Groups["bad"];
        if (group.Index > index)
        {
            builder.Append(built.Substring(index, match.Index - index + 1));
        }

        builder.Append(group.Value);
        builder.Append("_");        // putting an underscore after this keyword is enough to make it acceptable

        index = group.Index + group.Length;
    }

    if (index == 0)
    {
        return built;
    }

    if (index < built.Length - 1)
    {
        builder.Append(built.Substring(index));
    }

    return builder.ToString();
}

A partir del 18/04/2017, no hay una lista simple en blanco o negro de caracteres y nombres de archivos entre las respuestas a este tema, y ​​hay muchas respuestas.

La mejor sugerencia que se me ocurrió fue dejar que el usuario nombrara el archivo como quisiera. Usando un controlador de errores cuando la aplicación intenta guardar el archivo, detectar cualquier excepción, asumir que el nombre de archivo es el culpable (obviamente, después de asegurarse de que la ruta de guardado también esté bien) y solicitar al usuario un nuevo nombre de archivo. Para obtener mejores resultados, coloque este procedimiento de verificación dentro de un ciclo que continúa hasta que el usuario lo haga bien o se dé por vencido. Funcionó mejor para mí (al menos en VBA).

Aunque los únicos caracteres ilegales de Unix pueden ser /y NULL, aunque se debe incluir alguna consideración para la interpretación de la línea de comandos.

Por ejemplo, si bien puede ser legal nombrar un archivo 1>&2o 2>&1en Unix, los nombres de archivo como este pueden malinterpretarse cuando se usan en una línea de comando.

De manera similar, podría ser posible nombrar un archivo $PATH, pero cuando intente acceder a él desde la línea de comandos, el shell se traducirá $PATHa su valor variable.

Las dificultades para definir, qué es legal y qué no , ya se abordaron y se sugirieron listas blancas . Pero Windows admite caracteres de más de 8 bits . Wikipedia dice que (por ejemplo) el

la letra del modificador de dos puntos [( Ver 7. más abajo ) se usa] a veces en los nombres de archivo de Windows, ya que es idéntica a los dos puntos en la fuente Segoe UI utilizada para los nombres de archivo. El colon [ASCII heredado] en sí mismo no está permitido.

Por lo tanto, quiero presentar un enfoque mucho más liberal utilizando caracteres Unicode para reemplazar los "ilegales". Encontré el resultado en mi caso de uso comparable mucho más legible. Mira por ejemplo en este bloque . Además, incluso puede restaurar el contenido original a partir de eso. Las posibles opciones e investigaciones se proporcionan en la siguiente lista:

1. En lugar de *( U+002A * ASTERISK), puede usar uno de los muchos enumerados, por ejemplo U+2217 ∗ (ASTERISK OPERATOR)o elFull Width Asterisk U+FF0A ＊
2. En lugar de ., puede usar uno de estos , por ejemplo⋅ U+22C5 dot operator
3. En lugar de ", puedes usar “ U+201C english leftdoublequotemark(Alternativas ver aquí )
4. En lugar de /( / SOLIDUS U+002F), puede usar ∕ DIVISION SLASH U+2215(otros aquí )
5. En lugar de \( \ U+005C Reverse solidus), puede usar ⧵ U+29F5 Reverse solidus operator( más )
6. En lugar de [( U+005B Left square bracket) y ]( U+005D Right square bracket), puede usar por ejemplo U+FF3B［ FULLWIDTH LEFT SQUARE BRACKETy U+FF3D ］FULLWIDTH RIGHT SQUARE BRACKET(desde aquí , más posibilidades aquí )
7. En lugar de :, puede usar U+2236 ∶ RATIO (for mathematical usage)o U+A789 ꞉ MODIFIER LETTER COLON, (ver dos puntos (letra) , a veces se usa en los nombres de archivo de Windows, ya que es idéntico a los dos puntos en la fuente Segoe UI utilizada para los nombres de archivo. Los dos puntos en sí no están permitidos) (Ver aquí )
8. En lugar de ;, puedes usar U+037E ; GREEK QUESTION MARK(ver aquí )
9. Para |, hay algunos buenos sustitutos tales como: U+0964 । DEVANAGARI DANDA, U+2223 ∣ DIVIDESo U+01C0 ǀ LATIN LETTER DENTAL CLICK( Wikipedia ). Además, los caracteres del cuadro de dibujo contienen varias otras opciones.
10. En lugar de ,( , U+002C COMMA), puede usar por ejemplo ‚ U+201A SINGLE LOW-9 QUOTATION MARK(ver aquí )
11. Para ?( U+003F ? QUESTION MARK), estos son buenos candidatos: U+FF1F ？ FULLWIDTH QUESTION MARKo U+FE56 ﹖ SMALL QUESTION MARK(a partir de él re , dos más de Script bloque , buscar "cuestión")

Al crear accesos directos a Internet en Windows, para crear el nombre del archivo, omite los caracteres ilegales, excepto la barra diagonal, que se convierte en menos.

En shells de Unix, puede citar casi todos los caracteres entre comillas simples '. Excepto la comilla simple en sí, y no puede expresar caracteres de control, porque \no está expandido. Es posible acceder a la comilla simple dentro de una cadena entre comillas, porque puede concatenar cadenas con comillas simples y dobles, como las 'I'"'"'m'que se pueden usar para acceder a un archivo llamado "I'm"(la comilla doble también es posible aquí).

Por lo tanto, debe evitar todos los caracteres de control, porque son demasiado difíciles de ingresar en el shell. El resto sigue siendo divertido, especialmente los archivos que comienzan con un guión, porque la mayoría de los comandos los leen como opciones a menos que tenga dos guiones --antes, o los especifique con ./, lo que también oculta el inicio -.

Si quiere ser amable, no use ninguno de los caracteres que el shell y los comandos típicos usan como elementos sintácticos, a veces dependientes de la posición, por lo que, por ejemplo, aún puede usar -, pero no como primer carácter; lo mismo con ., puede usarlo como primer carácter solo cuando lo diga en serio ("archivo oculto"). Cuando eres malo, los nombres de tus archivos son secuencias de escape VT100 ;-), de modo que un ls confunde la salida.

Tenía la misma necesidad y estaba buscando recomendaciones o referencias estándar y encontré este hilo. Mi lista negra actual de caracteres que se deben evitar en los nombres de archivo y directorio son:

$CharactersInvalidForFileName = {
    "pound" -> "#",
    "left angle bracket" -> "<",
    "dollar sign" -> "$",
    "plus sign" -> "+",
    "percent" -> "%",
    "right angle bracket" -> ">",
    "exclamation point" -> "!",
    "backtick" -> "`",
    "ampersand" -> "&",
    "asterisk" -> "*",
    "single quotes" -> "“",
    "pipe" -> "|",
    "left bracket" -> "{",
    "question mark" -> "?",
    "double quotes" -> "”",
    "equal sign" -> "=",
    "right bracket" -> "}",
    "forward slash" -> "/",
    "colon" -> ":",
    "back slash" -> "\\",
    "lank spaces" -> "b",
    "at sign" -> "@"
};