I think a better question is "what characters are good to use in a filename". While RedGrittyBrick's answer is technically correct, safety isn't the only issue: usability is also important. The third file would be distinct from aB on Linux also.
#SECURE PAGE VERSUS FILESAFE WINDOWS#
Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead.
So you could probably safely use something like ✣ (if it weren't so hard to type)Ĭase-(in)sensitivity in Windows C> dir /B 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. This means you can store filenames in UTF-8 encoding. 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). Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped. In Linux and OS-X only / of the printable ASCII set is prohibited I believe. 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. These names refer to separate files which contain distinct separate content. It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. Some parts of Windows are case-sensitive, other parts are case-insensitive.
Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard. 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). In Windows, Windows Explorer does not allow control-characters or \/:*?"| You can use spaces. On all platforms it is best to avoid non-printable characters such as the ASCII control-characters. Windows: anything except ASCII's control characters and \/:*?"|.
0 kommentar(er)
