What characters are safe in cross-platform file names for Linux, Windows and OS-X












48















Currently, I use a YYMMDD-NAME+PAGE name for most of my files. NAME has spaces converted to underscores.



I'd like to use the YYYY-MM-DD date format, but I am not sure how to separate it from the name. A - would look strange if the name started with a number. If I use a _, then it conflicts with the underscore representing a space.



What characters are reasonably safe in file names that would work here? I am on Linux, but I might share files with other people (Windows 7, Mac OS X).










share|improve this question

























  • … on Unix, Windows, an Amiga 1000?

    – slhck
    Nov 18 '11 at 10:35











  • Mostly modern Linux.

    – Martin Ueding
    Nov 18 '11 at 10:42











  • - symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

    – Niranjan Singh
    Nov 18 '11 at 10:48











  • possible cross site duplicate of: stackoverflow.com/questions/4814040/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Jul 1 '14 at 12:25
















48















Currently, I use a YYMMDD-NAME+PAGE name for most of my files. NAME has spaces converted to underscores.



I'd like to use the YYYY-MM-DD date format, but I am not sure how to separate it from the name. A - would look strange if the name started with a number. If I use a _, then it conflicts with the underscore representing a space.



What characters are reasonably safe in file names that would work here? I am on Linux, but I might share files with other people (Windows 7, Mac OS X).










share|improve this question

























  • … on Unix, Windows, an Amiga 1000?

    – slhck
    Nov 18 '11 at 10:35











  • Mostly modern Linux.

    – Martin Ueding
    Nov 18 '11 at 10:42











  • - symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

    – Niranjan Singh
    Nov 18 '11 at 10:48











  • possible cross site duplicate of: stackoverflow.com/questions/4814040/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Jul 1 '14 at 12:25














48












48








48


11






Currently, I use a YYMMDD-NAME+PAGE name for most of my files. NAME has spaces converted to underscores.



I'd like to use the YYYY-MM-DD date format, but I am not sure how to separate it from the name. A - would look strange if the name started with a number. If I use a _, then it conflicts with the underscore representing a space.



What characters are reasonably safe in file names that would work here? I am on Linux, but I might share files with other people (Windows 7, Mac OS X).










share|improve this question
















Currently, I use a YYMMDD-NAME+PAGE name for most of my files. NAME has spaces converted to underscores.



I'd like to use the YYYY-MM-DD date format, but I am not sure how to separate it from the name. A - would look strange if the name started with a number. If I use a _, then it conflicts with the underscore representing a space.



What characters are reasonably safe in file names that would work here? I am on Linux, but I might share files with other people (Windows 7, Mac OS X).







filenames






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 18 '11 at 11:14









RedGrittyBrick

67.1k13106162




67.1k13106162










asked Nov 18 '11 at 10:32









Martin UedingMartin Ueding

86041631




86041631













  • … on Unix, Windows, an Amiga 1000?

    – slhck
    Nov 18 '11 at 10:35











  • Mostly modern Linux.

    – Martin Ueding
    Nov 18 '11 at 10:42











  • - symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

    – Niranjan Singh
    Nov 18 '11 at 10:48











  • possible cross site duplicate of: stackoverflow.com/questions/4814040/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Jul 1 '14 at 12:25



















  • … on Unix, Windows, an Amiga 1000?

    – slhck
    Nov 18 '11 at 10:35











  • Mostly modern Linux.

    – Martin Ueding
    Nov 18 '11 at 10:42











  • - symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

    – Niranjan Singh
    Nov 18 '11 at 10:48











  • possible cross site duplicate of: stackoverflow.com/questions/4814040/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Jul 1 '14 at 12:25

















… on Unix, Windows, an Amiga 1000?

– slhck
Nov 18 '11 at 10:35





… on Unix, Windows, an Amiga 1000?

– slhck
Nov 18 '11 at 10:35













Mostly modern Linux.

– Martin Ueding
Nov 18 '11 at 10:42





Mostly modern Linux.

– Martin Ueding
Nov 18 '11 at 10:42













- symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

– Niranjan Singh
Nov 18 '11 at 10:48





- symbol is safe to use on windows 7.. may be other modern operating system do same.. you can use minus symbol to separate..

– Niranjan Singh
Nov 18 '11 at 10:48













possible cross site duplicate of: stackoverflow.com/questions/4814040/…

– Ciro Santilli 新疆改造中心 六四事件 法轮功
Jul 1 '14 at 12:25





possible cross site duplicate of: stackoverflow.com/questions/4814040/…

– Ciro Santilli 新疆改造中心 六四事件 法轮功
Jul 1 '14 at 12:25










3 Answers
3






active

oldest

votes


















41














Summary:




  • Windows: anything except ASCII's control characters and /:*?"<>|

  • Linux, OS-X: anything except null or /


On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.



Windows



In Windows, Windows Explorer does not allow control-characters or /:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.



Some parts of Windows are case-sensitive, other parts are case-insensitive.
It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.



Linux, OS-X



In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.



Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.



Conclusion



So you could probably safely use something like (if it weren't so hard to type)





Case-(in)sensitivity in Windows



C> dir /B
Ab
aB
аB

C> type Ab
b
b

C> type aB
b
b

C> type аB
unicode homograph


Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.



(Windows 10 NTFS).






share|improve this answer





















  • 1





    All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

    – Isaac Rabinovitch
    Sep 6 '12 at 5:55






  • 4





    "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

    – RedGrittyBrick
    Sep 6 '12 at 9:22













  • It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

    – Marcks Thomas
    Sep 6 '12 at 15:27








  • 2





    Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

    – thecoshman
    Sep 10 '15 at 22:07






  • 1





    You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

    – Isaac Rabinovitch
    Aug 17 '17 at 3:31



















38














While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. I think a better question is "what characters are good to use in a filename".



Some potential guidelines:





  • [0-9a-zA-Z_] - Alphanumeric characters and the underscore are always fine to use.


  • /:*?"<>| and the null byte are problematic on at least one system, and should always be avoided.


  • Spaces are used as argument separators on many systems, so filenames with spaces should be avoided when possible. Other whitespaces (e.g. tabs) even more so.


  • Semicolons (;) are used to separate commands on many systems.
    Semicolons and commas(,) are used to separate command line arguments on (some versions of?) the windows command line.


  • ()^ #%&!@:+={}'~ and [`] all have special meanings in many shells, and are annoying to work around, and so should be avoided. They also tend to look horrible in URLs.


  • Leading characters to avoid:


    • Many command line programs use the hyphen [-] to indicate special arguments.

    • *nix based systems use a full-stop [.] as a leading character for hidden files and directories.



  • Anything not in the ASCII set can cause problems on older or more basic systems (e.g. some embedded systems), and should be used with care.


That basically leaves you with:



[0-9a-zA-Z-._]



that are always safe and not annoying to use (as long as you start the filename with an alpha-numeric) :)






share|improve this answer





















  • 1





    The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

    – Martin Ueding
    May 1 '14 at 13:20






  • 1





    Hrm... I guess the same could be said about (), actually.

    – naught101
    Jul 3 '14 at 23:57






  • 4





    In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

    – Casey Rodarmor
    Sep 5 '14 at 11:22











  • yeah, I removed them from the final list

    – naught101
    Sep 5 '14 at 15:29






  • 1





    comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

    – RedGrittyBrick
    Jul 11 '17 at 9:58



















4














You could:




  1. replace current underscores with # (proofreader's symbol for space)

  2. underscore to 'section' date from filename (or a second hyphen - easier to type)


Alt-1. initial-caps can replace spaces: YYMMDD-HHMM-FileName.ext or YYMMDD-HHMM_FileName.ext



Minimal characters for clear display, which auto-sorts with padded zeroes for Jan-Sep (& 1st-9th ea mo).






share|improve this answer

























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f358855%2fwhat-characters-are-safe-in-cross-platform-file-names-for-linux-windows-and-os%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    41














    Summary:




    • Windows: anything except ASCII's control characters and /:*?"<>|

    • Linux, OS-X: anything except null or /


    On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.



    Windows



    In Windows, Windows Explorer does not allow control-characters or /:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.



    Some parts of Windows are case-sensitive, other parts are case-insensitive.
    It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.



    Linux, OS-X



    In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.



    Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.



    Conclusion



    So you could probably safely use something like (if it weren't so hard to type)





    Case-(in)sensitivity in Windows



    C> dir /B
    Ab
    aB
    аB

    C> type Ab
    b
    b

    C> type aB
    b
    b

    C> type аB
    unicode homograph


    Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.



    (Windows 10 NTFS).






    share|improve this answer





















    • 1





      All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

      – Isaac Rabinovitch
      Sep 6 '12 at 5:55






    • 4





      "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

      – RedGrittyBrick
      Sep 6 '12 at 9:22













    • It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

      – Marcks Thomas
      Sep 6 '12 at 15:27








    • 2





      Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

      – thecoshman
      Sep 10 '15 at 22:07






    • 1





      You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

      – Isaac Rabinovitch
      Aug 17 '17 at 3:31
















    41














    Summary:




    • Windows: anything except ASCII's control characters and /:*?"<>|

    • Linux, OS-X: anything except null or /


    On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.



    Windows



    In Windows, Windows Explorer does not allow control-characters or /:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.



    Some parts of Windows are case-sensitive, other parts are case-insensitive.
    It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.



    Linux, OS-X



    In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.



    Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.



    Conclusion



    So you could probably safely use something like (if it weren't so hard to type)





    Case-(in)sensitivity in Windows



    C> dir /B
    Ab
    aB
    аB

    C> type Ab
    b
    b

    C> type aB
    b
    b

    C> type аB
    unicode homograph


    Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.



    (Windows 10 NTFS).






    share|improve this answer





















    • 1





      All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

      – Isaac Rabinovitch
      Sep 6 '12 at 5:55






    • 4





      "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

      – RedGrittyBrick
      Sep 6 '12 at 9:22













    • It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

      – Marcks Thomas
      Sep 6 '12 at 15:27








    • 2





      Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

      – thecoshman
      Sep 10 '15 at 22:07






    • 1





      You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

      – Isaac Rabinovitch
      Aug 17 '17 at 3:31














    41












    41








    41







    Summary:




    • Windows: anything except ASCII's control characters and /:*?"<>|

    • Linux, OS-X: anything except null or /


    On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.



    Windows



    In Windows, Windows Explorer does not allow control-characters or /:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.



    Some parts of Windows are case-sensitive, other parts are case-insensitive.
    It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.



    Linux, OS-X



    In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.



    Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.



    Conclusion



    So you could probably safely use something like (if it weren't so hard to type)





    Case-(in)sensitivity in Windows



    C> dir /B
    Ab
    aB
    аB

    C> type Ab
    b
    b

    C> type aB
    b
    b

    C> type аB
    unicode homograph


    Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.



    (Windows 10 NTFS).






    share|improve this answer















    Summary:




    • Windows: anything except ASCII's control characters and /:*?"<>|

    • Linux, OS-X: anything except null or /


    On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.



    Windows



    In Windows, Windows Explorer does not allow control-characters or /:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.



    Some parts of Windows are case-sensitive, other parts are case-insensitive.
    It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.



    Linux, OS-X



    In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.



    Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.



    Conclusion



    So you could probably safely use something like (if it weren't so hard to type)





    Case-(in)sensitivity in Windows



    C> dir /B
    Ab
    aB
    аB

    C> type Ab
    b
    b

    C> type aB
    b
    b

    C> type аB
    unicode homograph


    Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.



    (Windows 10 NTFS).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jul 23 '17 at 23:59

























    answered Nov 18 '11 at 11:18









    RedGrittyBrickRedGrittyBrick

    67.1k13106162




    67.1k13106162








    • 1





      All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

      – Isaac Rabinovitch
      Sep 6 '12 at 5:55






    • 4





      "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

      – RedGrittyBrick
      Sep 6 '12 at 9:22













    • It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

      – Marcks Thomas
      Sep 6 '12 at 15:27








    • 2





      Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

      – thecoshman
      Sep 10 '15 at 22:07






    • 1





      You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

      – Isaac Rabinovitch
      Aug 17 '17 at 3:31














    • 1





      All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

      – Isaac Rabinovitch
      Sep 6 '12 at 5:55






    • 4





      "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

      – RedGrittyBrick
      Sep 6 '12 at 9:22













    • It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

      – Marcks Thomas
      Sep 6 '12 at 15:27








    • 2





      Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

      – thecoshman
      Sep 10 '15 at 22:07






    • 1





      You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

      – Isaac Rabinovitch
      Aug 17 '17 at 3:31








    1




    1





    All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

    – Isaac Rabinovitch
    Sep 6 '12 at 5:55





    All in all a good answer, but I'd refrain from using filenames in spaces. Escaping them properly in all contexts is more trouble than it's worth. Notice that Microsoft stopped using space in system directory names. If you need to indicate word boundaries in names, CamelCase works fine.

    – Isaac Rabinovitch
    Sep 6 '12 at 5:55




    4




    4





    "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

    – RedGrittyBrick
    Sep 6 '12 at 9:22







    "C:Program files (x86)" still exists in Win8 - is that not a system directory? I agree that spaces can cause problems.

    – RedGrittyBrick
    Sep 6 '12 at 9:22















    It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

    – Marcks Thomas
    Sep 6 '12 at 15:27







    It is, but it can be renamed to pretty much anything. Of course, a lot of programs will freak out if you rename it to "]:foobar", but Windows refers to it as "%programfiles(x86)%" anyway.

    – Marcks Thomas
    Sep 6 '12 at 15:27






    2




    2





    Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

    – thecoshman
    Sep 10 '15 at 22:07





    Something to really keep in mind here, linux system are able to consider uppercase and lower as distinct, whilst Windows considers them the same.

    – thecoshman
    Sep 10 '15 at 22:07




    1




    1





    You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

    – Isaac Rabinovitch
    Aug 17 '17 at 3:31





    You'd be surprised how many programs suck at parsing. That's why there was no Windows 9.

    – Isaac Rabinovitch
    Aug 17 '17 at 3:31













    38














    While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. I think a better question is "what characters are good to use in a filename".



    Some potential guidelines:





    • [0-9a-zA-Z_] - Alphanumeric characters and the underscore are always fine to use.


    • /:*?"<>| and the null byte are problematic on at least one system, and should always be avoided.


    • Spaces are used as argument separators on many systems, so filenames with spaces should be avoided when possible. Other whitespaces (e.g. tabs) even more so.


    • Semicolons (;) are used to separate commands on many systems.
      Semicolons and commas(,) are used to separate command line arguments on (some versions of?) the windows command line.


    • ()^ #%&!@:+={}'~ and [`] all have special meanings in many shells, and are annoying to work around, and so should be avoided. They also tend to look horrible in URLs.


    • Leading characters to avoid:


      • Many command line programs use the hyphen [-] to indicate special arguments.

      • *nix based systems use a full-stop [.] as a leading character for hidden files and directories.



    • Anything not in the ASCII set can cause problems on older or more basic systems (e.g. some embedded systems), and should be used with care.


    That basically leaves you with:



    [0-9a-zA-Z-._]



    that are always safe and not annoying to use (as long as you start the filename with an alpha-numeric) :)






    share|improve this answer





















    • 1





      The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

      – Martin Ueding
      May 1 '14 at 13:20






    • 1





      Hrm... I guess the same could be said about (), actually.

      – naught101
      Jul 3 '14 at 23:57






    • 4





      In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

      – Casey Rodarmor
      Sep 5 '14 at 11:22











    • yeah, I removed them from the final list

      – naught101
      Sep 5 '14 at 15:29






    • 1





      comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

      – RedGrittyBrick
      Jul 11 '17 at 9:58
















    38














    While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. I think a better question is "what characters are good to use in a filename".



    Some potential guidelines:





    • [0-9a-zA-Z_] - Alphanumeric characters and the underscore are always fine to use.


    • /:*?"<>| and the null byte are problematic on at least one system, and should always be avoided.


    • Spaces are used as argument separators on many systems, so filenames with spaces should be avoided when possible. Other whitespaces (e.g. tabs) even more so.


    • Semicolons (;) are used to separate commands on many systems.
      Semicolons and commas(,) are used to separate command line arguments on (some versions of?) the windows command line.


    • ()^ #%&!@:+={}'~ and [`] all have special meanings in many shells, and are annoying to work around, and so should be avoided. They also tend to look horrible in URLs.


    • Leading characters to avoid:


      • Many command line programs use the hyphen [-] to indicate special arguments.

      • *nix based systems use a full-stop [.] as a leading character for hidden files and directories.



    • Anything not in the ASCII set can cause problems on older or more basic systems (e.g. some embedded systems), and should be used with care.


    That basically leaves you with:



    [0-9a-zA-Z-._]



    that are always safe and not annoying to use (as long as you start the filename with an alpha-numeric) :)






    share|improve this answer





















    • 1





      The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

      – Martin Ueding
      May 1 '14 at 13:20






    • 1





      Hrm... I guess the same could be said about (), actually.

      – naught101
      Jul 3 '14 at 23:57






    • 4





      In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

      – Casey Rodarmor
      Sep 5 '14 at 11:22











    • yeah, I removed them from the final list

      – naught101
      Sep 5 '14 at 15:29






    • 1





      comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

      – RedGrittyBrick
      Jul 11 '17 at 9:58














    38












    38








    38







    While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. I think a better question is "what characters are good to use in a filename".



    Some potential guidelines:





    • [0-9a-zA-Z_] - Alphanumeric characters and the underscore are always fine to use.


    • /:*?"<>| and the null byte are problematic on at least one system, and should always be avoided.


    • Spaces are used as argument separators on many systems, so filenames with spaces should be avoided when possible. Other whitespaces (e.g. tabs) even more so.


    • Semicolons (;) are used to separate commands on many systems.
      Semicolons and commas(,) are used to separate command line arguments on (some versions of?) the windows command line.


    • ()^ #%&!@:+={}'~ and [`] all have special meanings in many shells, and are annoying to work around, and so should be avoided. They also tend to look horrible in URLs.


    • Leading characters to avoid:


      • Many command line programs use the hyphen [-] to indicate special arguments.

      • *nix based systems use a full-stop [.] as a leading character for hidden files and directories.



    • Anything not in the ASCII set can cause problems on older or more basic systems (e.g. some embedded systems), and should be used with care.


    That basically leaves you with:



    [0-9a-zA-Z-._]



    that are always safe and not annoying to use (as long as you start the filename with an alpha-numeric) :)






    share|improve this answer















    While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. I think a better question is "what characters are good to use in a filename".



    Some potential guidelines:





    • [0-9a-zA-Z_] - Alphanumeric characters and the underscore are always fine to use.


    • /:*?"<>| and the null byte are problematic on at least one system, and should always be avoided.


    • Spaces are used as argument separators on many systems, so filenames with spaces should be avoided when possible. Other whitespaces (e.g. tabs) even more so.


    • Semicolons (;) are used to separate commands on many systems.
      Semicolons and commas(,) are used to separate command line arguments on (some versions of?) the windows command line.


    • ()^ #%&!@:+={}'~ and [`] all have special meanings in many shells, and are annoying to work around, and so should be avoided. They also tend to look horrible in URLs.


    • Leading characters to avoid:


      • Many command line programs use the hyphen [-] to indicate special arguments.

      • *nix based systems use a full-stop [.] as a leading character for hidden files and directories.



    • Anything not in the ASCII set can cause problems on older or more basic systems (e.g. some embedded systems), and should be used with care.


    That basically leaves you with:



    [0-9a-zA-Z-._]



    that are always safe and not annoying to use (as long as you start the filename with an alpha-numeric) :)







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 14 at 23:01

























    answered May 1 '14 at 2:35









    naught101naught101

    606821




    606821








    • 1





      The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

      – Martin Ueding
      May 1 '14 at 13:20






    • 1





      Hrm... I guess the same could be said about (), actually.

      – naught101
      Jul 3 '14 at 23:57






    • 4





      In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

      – Casey Rodarmor
      Sep 5 '14 at 11:22











    • yeah, I removed them from the final list

      – naught101
      Sep 5 '14 at 15:29






    • 1





      comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

      – RedGrittyBrick
      Jul 11 '17 at 9:58














    • 1





      The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

      – Martin Ueding
      May 1 '14 at 13:20






    • 1





      Hrm... I guess the same could be said about (), actually.

      – naught101
      Jul 3 '14 at 23:57






    • 4





      In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

      – Casey Rodarmor
      Sep 5 '14 at 11:22











    • yeah, I removed them from the final list

      – naught101
      Sep 5 '14 at 15:29






    • 1





      comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

      – RedGrittyBrick
      Jul 11 '17 at 9:58








    1




    1





    The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

    – Martin Ueding
    May 1 '14 at 13:20





    The braces () are part of regular expressions and have special meaning in the shell as well. But they are not as that bad to work with except some evil corner cases.

    – Martin Ueding
    May 1 '14 at 13:20




    1




    1





    Hrm... I guess the same could be said about (), actually.

    – naught101
    Jul 3 '14 at 23:57





    Hrm... I guess the same could be said about (), actually.

    – naught101
    Jul 3 '14 at 23:57




    4




    4





    In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

    – Casey Rodarmor
    Sep 5 '14 at 11:22





    In zsh, characters that might be interpreted differently include ()^;, so I think the right answer might actually be [0-9a-zA-Z.,_-] Comma could also possibly be excluded just because it's weird to see in a filename, although I can't think of an actual case where it would cause problems.

    – Casey Rodarmor
    Sep 5 '14 at 11:22













    yeah, I removed them from the final list

    – naught101
    Sep 5 '14 at 15:29





    yeah, I removed them from the final list

    – naught101
    Sep 5 '14 at 15:29




    1




    1





    comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

    – RedGrittyBrick
    Jul 11 '17 at 9:58





    comma can be annoying, try echo whereami > a,b,c in Win10 command prompt window.

    – RedGrittyBrick
    Jul 11 '17 at 9:58











    4














    You could:




    1. replace current underscores with # (proofreader's symbol for space)

    2. underscore to 'section' date from filename (or a second hyphen - easier to type)


    Alt-1. initial-caps can replace spaces: YYMMDD-HHMM-FileName.ext or YYMMDD-HHMM_FileName.ext



    Minimal characters for clear display, which auto-sorts with padded zeroes for Jan-Sep (& 1st-9th ea mo).






    share|improve this answer






























      4














      You could:




      1. replace current underscores with # (proofreader's symbol for space)

      2. underscore to 'section' date from filename (or a second hyphen - easier to type)


      Alt-1. initial-caps can replace spaces: YYMMDD-HHMM-FileName.ext or YYMMDD-HHMM_FileName.ext



      Minimal characters for clear display, which auto-sorts with padded zeroes for Jan-Sep (& 1st-9th ea mo).






      share|improve this answer




























        4












        4








        4







        You could:




        1. replace current underscores with # (proofreader's symbol for space)

        2. underscore to 'section' date from filename (or a second hyphen - easier to type)


        Alt-1. initial-caps can replace spaces: YYMMDD-HHMM-FileName.ext or YYMMDD-HHMM_FileName.ext



        Minimal characters for clear display, which auto-sorts with padded zeroes for Jan-Sep (& 1st-9th ea mo).






        share|improve this answer















        You could:




        1. replace current underscores with # (proofreader's symbol for space)

        2. underscore to 'section' date from filename (or a second hyphen - easier to type)


        Alt-1. initial-caps can replace spaces: YYMMDD-HHMM-FileName.ext or YYMMDD-HHMM_FileName.ext



        Minimal characters for clear display, which auto-sorts with padded zeroes for Jan-Sep (& 1st-9th ea mo).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Sep 6 '12 at 14:04









        Indrek

        20.6k117484




        20.6k117484










        answered Sep 6 '12 at 5:44









        tb01tb01

        411




        411






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f358855%2fwhat-characters-are-safe-in-cross-platform-file-names-for-linux-windows-and-os%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            RAC Tourist Trophy