The word "best not to use" in files and folders in ASCII.jp Windows
There is an "unavailable" character in the file name or folder name in Windows. But in fact, there is also the word "it's best not to use it". This time, let's think about these words.
Set both the file name and the folder name of the Windows to path name. Path names include file names, folder names, and path delimiters. The characters that cannot be used for path names vary depending on location. For example, there is a difference between the path processed in the API of the file system, the path handled by the application, or the path on the command line. However, the file name / folder name cannot contain path delimiters. In the standard, circle marks (backslashes) and slashes are path separators.
There are characters in Windows that cannot be used for file or folder names. When Explorer tries to use these characters, a message is displayed
The "unavailable" character in Windows Chinese file name
In Windows, there are "unavailable" characters in the file name or folder name, and when you change the file name, when these characters enter, a warning is displayed telling you that this is not possible. It is the nine letters in the following table.
文字 | 名称 | 意味 |
---|---|---|
\ | 円マーク | パスの区切り記号 |
⁄ | スラッシュ | パスの区切り記号 |
: | コロン | ドライブ文字記号 |
* | アスタリスク | ワイルドカード記号 |
? | 疑問符 | ワイルドカード記号 |
" | 2重引用符 | パスを囲む |
> | 大なり不等号 | リダイレクト記号 |
< | 小なり不等号 | リダイレクト記号 |
| | 縦棒、バー | パイプ記号 |
These are the rules that began in the era of MS-DOS. In a sense, it can also be said to be the "command.com" rule. These characters are no longer used for file and folder names because they have special meaning on the command line. MS-DOS initially performs everything on the command line. At this point, symbol characters with special meaning on the command line are prohibited from being used in file and folder names, and the determination of command line, file name and folder name is simplified.
These are still given special treatment and cannot be used for the names of files and folders. However, this is only partially related to the specification as a file system such as NTFS or vFAT. "\" and "/" as path delimiters are common, but other characters cannot be placed in absolute file names and pathnames, which is not the case. However, some degree of security countermeasures are also taken in the API of the file name to interpret and handle the passed path. Therefore, the characters that cannot be used are different, depending on the API and the parameter specification. In any case in Windows, paths that begin with "\?\" are not interpreted and processed directly (but API is not necessarily successful).
The "not available" character on the command line
The current Windows 10 can also use commands from the command line, which has two command-line interpreters: cmd.exe and powershell.exe. Cmd.exe,command.com 's successor, in particular, has taken over many features. Over the years, however, command-line functionality has been enhanced, creating characters that need to pay attention to how to use it. One of the notable examples is "spaces". Spaces, as symbolic characters that separate command line arguments, cannot contain spaces in file names and paths in the MS-DOS era.
The folder named "Program Files" that is still in use appears in the Windows95 that introduced vFAT. This may be to give the user a simple understanding of the naming of "filenames can use spaces". On the other hand, many users have to include the startup path of the installed application in a double quart.
Characters in Cmd.exe that must be enclosed in double quotation marks are not just spaces. According to cmd.exe 's online help, if the file name contains the following characters, you need to enclose it in double quotation marks.
& ( ) [ ] { } ^ = ; ! ' + , ` ~
You can display online help for cmd.exe with the command "cmd/?". Characters that require quotation marks are shown here.
これらは、コマンドラインやバッチでは特別な意味を持つ文字だ。たとえば、「&」は、cmd.exeでは、コマンドラインの区切りと解釈される。「^」は、cmd.exeのエスケープキャラクタとして使われている。基本的には、これらの文字がパスに含まれている場合、全体をダブルクオートで括れば安全である。このことはPowerShellでも同様だ。ただし、PowerShellでコマンドの引数ではなく、起動するプログラムのパスを表記するような場合に「&('パス')」という表記を使う必要がある。たとえば「c:\program files\test\test.exe」という実行ファイルの場合、cmd.exeでは
"c:\ program files\ test.test.exe"
In Powershell
&'c:\program files\test\test.exe'
として先頭に「&」を置き、シングルクオートで括る必要がある。PowerShellではダブルクオートは変数展開をするため、変数を表す「$」がパス中に含まれていると、これが展開され変数値に置き換えられてしまう。シングルクオートはこれをしない(ちなみにcmd.exeはシングルクオートに特殊な意味を持たせずダブルクオートだけが有効)。
先頭に「&」は、後続部分を評価(実行)するという意味で、これがないと、PowerShellでは単なる文字列の表示コマンドになってしまう。このあたり、PowerShellが言語側にちょっと倒し過ぎちゃった感があり、シェルとしてはイマイチ人気がない理由の1つなのだと思う。プログラムのステートメントとしては、これでもいいのだが、コマンドラインの場合には、別処理にしてもいいんじゃないかと思う。ちなみに、スペースなどを含まずシングルクオートで括る必要がないパスには「&」を付ける必要はない。
入力行の補完機能を使えば、自動的に「&」を付けてシングルクオートで括ってくれる。しかし、それを使わずに手入力で「"C:\program files\……"」といったcmd.exe方式の実行ファイルの指定をすると、入力行が表示されるだけというのは、かなりダメージがあり、それ以来PowerShellが嫌いになったという多数のユーザーを作ってしまったのではないかと思われる。
Although Cmd.exe can do simple path input, it also has a lot of thorny problems. The big one is the replacement function of environment variables based on "%". On the command line of cmd.exe, the string that surrounds the environment variable name with "%" is replaced with the value of the environment variable before execution. The famous one will be "% UserProfile%", which shows the user's home directory.
For example, if "% UserProfile%\ test.exe", it is the command that starts the test.exe command in the user's home directory. However, if the environment variable is not defined, no replacement occurs in the environment variable substitution. UserProfile,Windows prepares environment variables when it starts, so there are often substituted environment variable name definitions such as test and so on.
So for a command line like "% test.exe", in the absence of the test environment variable, the literal command, the test xyz string is defined, and the attempt is started after the "xyz.exe" replacement. To disable environment variable substitution, you need to specify "^% test ^% .exe" with "^". The same text has "!", which has almost the same meaning as "%" in the case that the delayed environment variable replacement is valid (cmd.exe startup option, etc.) (except that the timing of the replacement).
In addition, environment variable replacement needs to be surrounded by% before and after the environment variable name and is not replaced on only one side. However, it can have unexpected side effects, such as processing in complex batch files. Therefore, when using cmd.exe or powershell.exe, it is best not to use one character.