Quali caratteri sono vietati nei nomi di directory di Windows e Linux?

So che / è illegale in Linux e quanto segue è illegale in Windows (penso) * . " / \ [ ] : ; | ,

Cos'altro mi manca?

Ho bisogno di una guida completa, tuttavia, che tenga conto dei caratteri a doppio byte. Il collegamento a risorse esterne va bene per me.

Devo prima creare una directory sul filesystem usando un nome che possa contenere caratteri proibiti, quindi ho intenzione di sostituire quei caratteri con caratteri di sottolineatura. Ho quindi bisogno di scrivere questa directory e il suo contenuto in un file zip (usando Java), quindi qualsiasi consiglio aggiuntivo riguardante i nomi delle directory zip sarebbe apprezzato.

Una "guida completa" di caratteri di file proibiti non funzionerà su Windows perché riserva nomi di file e caratteri. Sì, personaggi come * " ? e altri sono vietati, ma esiste un numero infinito di nomi composti solo da caratteri validi che sono vietati. Ad esempio, spazi e punti sono caratteri di nome file validi, ma i nomi composti solo da tali caratteri sono vietati.

Windows non distingue tra caratteri maiuscoli e minuscoli, quindi non è possibile creare una cartella denominata Ase ane esiste già una. Nomi peggiori, apparentemente consentiti come PRNe CON, e molti altri, sono riservati e non consentiti. Windows ha anche diverse restrizioni di lunghezza; un nome file valido in una cartella può diventare non valido se spostato in un'altra cartella. Le regole per la denominazione di file e cartelle si trovano nei documenti Microsoft.

In generale, non è possibile utilizzare il testo generato dall'utente per creare nomi di directory di Windows. Se si desidera consentire agli utenti di nome tutto ciò che vogliono, è necessario creare nomi sicuri come A, AB, A2et al., Memorizzare i nomi generati dagli utenti ei loro equivalenti di percorso in un file di dati delle applicazioni, ed eseguire la mappatura percorso nell'applicazione.

Se devi assolutamente consentire i nomi delle cartelle generati dall'utente, l'unico modo per sapere se non sono validi è quello di catturare le eccezioni e supporre che il nome non sia valido. Anche questo è pieno di pericoli, poiché le eccezioni generate per l'accesso negato, le unità offline e lo spazio esterno dell'unità si sovrappongono a quelle che possono essere gettate per nomi non validi. Stai aprendo un'enorme lattina di dolore.

Manteniamolo semplice e prima rispondiamo alla domanda.

1. I caratteri ASCII stampabili proibiti sono:

   • Linux / Unix:

     / (forward slash)
     

   • Finestre:

     < (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. Caratteri non stampabili

   Se i tuoi dati provengono da una fonte che consentirebbe caratteri non stampabili, c'è altro da verificare.

   • Linux / Unix:

     0 (NULL byte)
     

   • Finestre:

     0-31 (ASCII control characters)
     

   Nota: sebbene sia legale nei file system Linux / Unix creare file con caratteri di controllo nel nome file, potrebbe essere un incubo per gli utenti gestire tali file .

3. Nomi di file riservati

   Sono riservati i seguenti nomi di file:

   • Finestre:

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

     (sia da soli che con estensioni di file arbitrarie, ad esempio LPT1.txt).

4. Altre regole

   • Finestre:

     I nomi dei file non possono terminare in uno spazio o punto.

Sotto Linux e altri sistemi relativi a Unix, ci sono solo due caratteri che non possono apparire nel nome di un file o di una directory, e sono NUL '\0'e barra '/'. La barra, ovviamente, può apparire in un nome di percorso, separando i componenti della directory.

Rumor ¹ vuole che Steven Bourne (di 'shell' fama) ha avuto una directory che contiene 254 file, uno per ogni singola lettera (codice carattere) che può apparire in un nome di file (ad esclusione /, '\0', il nome .è stata la directory corrente, naturalmente ). È stato usato per testare la shell Bourne e ha provocato il caos su programmi inconsueti come programmi di backup.

Altre persone hanno coperto le regole di Windows.

Nota che MacOS X ha un file system senza distinzione tra maiuscole e minuscole.

Quando Steve Bourne stava scrivendo la sua shell Unix (che divenne nota come shell Bourne), creò una directory di 254 file con nomi di un carattere, uno per ogni valore di byte tranne '\0'e barra, i due caratteri che non possono apparire in Unix nomi dei file. Ha usato quella directory per tutti i tipi di test di pattern-matching e tokenizzazione. (La directory di test è stata ovviamente creata da un programma.) Per anni in seguito, quella directory è stata la rovina dei programmi di file tree-walking; li ha messi alla prova per la distruzione.

^{Si noti che la directory deve contenere voci .e .., quindi, probabilmente 253 file (e 2 directory) o 255 voci nome, anziché 254 file. Ciò non influisce sull'efficacia dell'aneddoto o sull'attenta verifica che descrive.}

Invece di creare una lista nera di personaggi, è possibile utilizzare una lista bianca . Tutto considerato, l'intervallo di caratteri che ha senso in un contesto di nome file o directory è piuttosto breve e, a meno che non abbiate alcuni requisiti di denominazione molto specifici, gli utenti non lo terranno contro l'applicazione se non possono usare l'intera tabella ASCII.

Non risolve il problema dei nomi riservati nel file system di destinazione, ma con una whitelist è più facile mitigare i rischi alla fonte.

In questo spirito, questa è una serie di personaggi che possono essere considerati sicuri:

• Lettere (az AZ) - Anche i caratteri Unicode, se necessario
• Cifre (0-9)
• Underscore (_)
• Trattino (-)
• Spazio
• Punto (.)

E qualsiasi altro personaggio sicuro che desideri consentire. Oltre a ciò, devi solo applicare alcune regole aggiuntive relative a spazi e punti . Questo di solito è sufficiente:

• Il nome deve contenere almeno una lettera o un numero (per evitare solo punti / spazi)
• Il nome deve iniziare con una lettera o un numero (per evitare punti / spazi iniziali)
• Il nome potrebbe non terminare con un punto o uno spazio (è sufficiente tagliare quelli se presenti, come fa Explorer)

Ciò consente già nomi abbastanza complessi e senza senso. Ad esempio, questi nomi sarebbero possibili con queste regole ed essere nomi di file validi in Windows / Linux:

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

In sostanza, anche con così pochi personaggi nella whitelist dovresti comunque decidere cosa ha effettivamente senso e convalidare / regolare il nome di conseguenza. In una delle mie applicazioni, ho usato le stesse regole di cui sopra ma ho rimosso tutti i punti e gli spazi duplicati.

Il modo più semplice per farti dire la risposta da Windows è provare a rinominare un file tramite Explorer e digitare / per il nuovo nome. Windows farà apparire una finestra di messaggio che ti dirà l'elenco dei personaggi illegali.

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

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

Bene, se non altro per scopi di ricerca, allora la cosa migliore da fare è guardare questa voce di Wikipedia sui nomi dei file .

Se si desidera scrivere una funzione portatile per convalidare l'input dell'utente e creare nomi di file basati su quello, la risposta breve è no . Dai un'occhiata a un modulo portatile come File :: Spec di Perl per dare un'occhiata a tutti i luppoli necessari per svolgere un compito così "semplice".

Per Windows puoi verificarlo usando PowerShell

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

Per visualizzare i codici UTF-8 è possibile convertire

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

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

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

In Windows 10 (2019), i seguenti caratteri sono vietati da un errore quando si tenta di digitarli:

Un nome file non può contenere nessuno dei seguenti caratteri:

\ / : * ? " < > |

Ecco l'implementazione ac # per windows basata sulla risposta di Christopher Oezbek

È stato reso più complesso dal contenuto booleano di Folder, ma si spera che copra tutto

/// <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 partire dal 18/04/2017, nessuna semplice lista in bianco o nero di caratteri e nomi di file è evidente tra le risposte a questo argomento - e ci sono molte risposte.

Il miglior suggerimento che ho potuto suggerire è stato quello di lasciare all'utente il nome del file come preferisce. Utilizzando un gestore di errori quando l'applicazione tenta di salvare il file, rileva eventuali eccezioni, presume che il nome del file sia da incolpare (ovviamente dopo aver verificato che anche il percorso di salvataggio fosse ok) e richiede all'utente un nuovo nome di file. Per risultati ottimali, collocare questa procedura di controllo all'interno di un ciclo che continua fino a quando l'utente non lo ottiene correttamente o si arrende. Ha funzionato meglio per me (almeno in VBA).

Anche se gli unici caratteri Unix illegali potrebbero essere /e NULL, sebbene una certa considerazione per l'interpretazione della riga di comando dovrebbe essere inclusa.

Ad esempio, mentre potrebbe essere legale nominare un file 1>&2o2>&1 in Unix, nomi di file come questo potrebbero essere interpretati erroneamente quando utilizzati su una riga di comando.

Allo stesso modo potrebbe essere possibile nominare un file $PATH, ma quando si tenta di accedervi dalla riga di comando, la shell si tradurrà $PATHnel suo valore variabile.

Difficoltà nel definire, ciò che è legale e non era già stato affrontato e sono state suggerite le whitelist . Ma Windows supporta caratteri più di 8 bit . Wikipedia afferma che (ad esempio) il

la lettera di modifica due punti [( vedi 7. sotto ) è] talvolta usata nei nomi di file di Windows poiché è identica ai due punti nel carattere dell'interfaccia utente Segoe utilizzato per i nomi di file. Il colon [ASCII ereditato] stesso non è permesso.

Pertanto, voglio presentare un approccio molto più liberale usando i caratteri Unicode per sostituire quelli "illegali". Ho trovato il risultato nel mio caso d'uso comparabile di gran lunga più leggibile. Cerca ad esempio in questo blocco . Inoltre puoi anche ripristinare il contenuto originale da quello. Le possibili scelte e ricerche sono fornite nel seguente elenco:

1. Invece di *( U+002A * ASTERISK), puoi usare uno dei tanti elencati, ad esempio U+2217 ∗ (ASTERISK OPERATOR)oFull Width Asterisk U+FF0A ＊
2. Invece di ., puoi usare uno di questi , per esempio⋅ U+22C5 dot operator
3. Invece di ", puoi usare “ U+201C english leftdoublequotemark(Le alternative vedi qui )
4. Invece di /( / SOLIDUS U+002F), puoi usare ∕ DIVISION SLASH U+2215(altri qui )
5. Invece di \( \ U+005C Reverse solidus), puoi usare⧵ U+29F5 Reverse solidus operator ( altro )
6. Invece di [( U+005B Left square bracket) e ]( U+005D Right square bracket), puoi usare ad esempio U+FF3B［ FULLWIDTH LEFT SQUARE BRACKETe U+FF3D ］FULLWIDTH RIGHT SQUARE BRACKET(da qui , più possibilità qui )
7. Invece di :, puoi usare U+2236 ∶ RATIO (for mathematical usage)o U+A789 ꞉ MODIFIER LETTER COLON, (vedi due punti (lettera) , a volte usati nei nomi di file di Windows poiché è identico ai due punti nel carattere dell'interfaccia utente di Segoe utilizzato per i nomi di file. I due punti non sono consentiti) (Vedi qui )
8. Invece di ;, puoi usare U+037E ; GREEK QUESTION MARK(vedi qui )
9. Per |, ci sono alcuni buoni sostituti quali: U+0964 । DEVANAGARI DANDA, U+2223 ∣ DIVIDESo U+01C0 ǀ LATIN LETTER DENTAL CLICK( Wikipedia ). Inoltre, i caratteri del disegno della scatola contengono varie altre opzioni.
10. Invece di ,( , U+002C COMMA), puoi usare ad esempio ‚ U+201A SINGLE LOW-9 QUOTATION MARK(vedi qui )
11. Per ?( U+003F ? QUESTION MARK), questi sono buoni candidati: U+FF1F ？ FULLWIDTH QUESTION MARKo U+FE56 ﹖ SMALL QUESTION MARK(da lui re , altri due da Simboli Block , cercare "domanda")

Quando si creano collegamenti a Internet in Windows, per creare il nome del file, salta i caratteri non consentiti, ad eccezione della barra, che viene convertita in meno.

Nelle shell Unix, puoi citare quasi ogni carattere tra virgolette singole '. Tranne la stessa virgoletta stessa e non puoi esprimere caratteri di controllo, perché \non è espanso. È possibile accedere alla stessa virgoletta stessa all'interno di una stringa tra virgolette, perché è possibile concatenare le stringhe con virgolette singole e doppie, come ad esempio è 'I'"'"'m'possibile utilizzare per accedere a un file chiamato "I'm"(qui è possibile anche la doppia virgoletta).

Quindi dovresti evitare tutti i personaggi di controllo, perché sono troppo difficili da inserire nella shell. Il resto è ancora divertente, in particolare i file che iniziano con un trattino, perché la maggior parte dei comandi li legge come opzioni a meno che tu non abbia due trattini in --precedenza, o se li specifichi con ./, che nasconde anche l'inizio -.

Se vuoi essere gentile, non usare nessuno dei caratteri che la shell e i comandi tipici usano come elementi sintattici, a volte dipendenti dalla posizione, quindi ad esempio puoi ancora usare -, ma non come primo carattere; lo stesso con ., puoi usarlo come primo carattere solo quando lo intendi ("file nascosto"). Quando sei cattivo, i nomi dei tuoi file sono sequenze di escape VT100 ;-), in modo che ls alterni l'output.

Avevo lo stesso bisogno e stavo cercando consigli o riferimenti standard e mi sono imbattuto in questo thread. La mia attuale lista nera di personaggi che dovrebbero essere evitati nei nomi di file e directory sono:

$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" -> "@"
};