Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 Kala Nov 18 '11 at 10:48
possible cross site duplicate of:… – Ciro Santilli 巴拿馬文件 六四事件 法轮功 Jul 1 '14 at 12:25
up vote 18 down vote accepted


  • 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.


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.

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.


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

share|improve this answer
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
"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
@RedGrittyBrick Oops. Good point. What I should have said is that MS stopped using names with spaces for newly-invented system directories. – Isaac Rabinovitch Sep 9 '12 at 3:43
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

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.
  • Colons (;) are used to separate commands on many systems.
  • []()^ #%&!@:+={}'~ 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:


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

share|improve this answer
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
Hrm... I guess the same could be said about (), actually. – naught101 Jul 3 '14 at 23:57
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. – rodarmor Sep 5 '14 at 11:22
yeah, I removed them from the final list – naught101 Sep 5 '14 at 15:29
@Phil_1984_: I had some inside the braces too : :) – naught101 Jan 27 '15 at 22:45

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


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.