我知道兩者都在 PowerShell 中使用,但用于不同的背景關系。
互聯網上關于這個主題的資訊很少,唯一談論它的網站(沒有讓我理解這個概念)是:https :
//www.rlmueller.net/PowerShellEscape.htm
我是 PowerShell 的初學者,我最近正在接近它。在我的另一個主題的答案中出現了
一個\轉義用例:
當我將引數傳遞給嵌套的 Start-Process 命令時,PowerShell 會洗掉多個連續的空格
有沒有人可以通過示例和用例向我詳細解釋PowerShell中轉義反引號`和反斜杠之間的區別\?
歡迎至少有一個來源,但這不是強制性的。
uj5u.com熱心網友回復:
反引號在 Powershell 中`用作轉義字符。也就是說,轉義引號、制表符等。與許多其他環境不同,Powershell 的換行符是`n,而不是\n。這具有簡化路徑的好處,因為它們在 Windows 中使用反斜杠。
作為一個實際的例子,在許多編程語言中,需要對路徑中的反斜杠進行轉義。如果您的應用程式位于
c:\program files\newApplication\myApp.exe
它的路徑必須寫成
c:\\program files\\newApplication\\myApp.exe
雙反斜杠表示法實際上是一個反斜杠,而不是諸如制表符或換行符之類的元字符。請注意,該路徑包含\newApplication. 現在,\n通常意味著換行,但顯然不是這樣。該檔案不在
c:\program files\
ewApplication\myApp.exe
畢竟,不是嗎?
Powershell 中不需要轉義,因為反斜杠本身沒有特殊含義。當 Powershell 看到 時c:\program files\newApplication\myApp.exe,它并沒有\n為前面提到的部分賦予任何特殊含義,它只是一個字串文字。
反斜杠\用作正則運算式中的轉義字符并表示元字符。也就是說,要匹配*正則運算式中的文字,必須對其進行轉義,以免它表示 Kleene 星(零個或多個匹配項)。
uj5u.com熱心網友回復:
vonPryz 的有用回答很好地涵蓋了 PowerShell-內部角度;讓我嘗試一個系統的總結,包括 PowerShell CLI角度,以及傳遞嵌入"到外部程式的引數:
在PowerShell session 中,唯一的轉義字符是`(所謂的反引號),在以下背景關系中:
內部擴展的字串(
"...",雙引號),而不是一個內部逐字字串('...'單引號); 有關支持的轉義序列,請參閱概念about_Special_Characters幫助主題:# " must be escaped; escape sequence `n expands to a newline. "3`" of`nrain"在不帶引號的命令引數中:
# > must be escaped to write verbatim 'a>b', # since outside a quoted string an unescaped > is a redirection. Write-Output a`>b對于續行:
# Spread the Get-Date call across two lines. # Important: ` must be the *very last char* on the line. Get-Date ` -Year 2525注:各種子系統,無論是PowerShell的特定與否,可以有自己的逃避規則,如
\在正則運算式,并`在通配符運算式。由于這些子系統的引數是通過 PowerShell 字串傳遞的,因此最好使用逐字字串文字,以避免 PowerShell 自己的字串插值與目標子系統最終看到的內容之間產生混淆;例如'A $50 fine.' -match '\$50'(\需要$從字面上處理正則運算式元字符)。
當PowerShell是所謂來自外部,通過它的命令列,不同的規則,可能在另外:
為了遵守Windows上廣泛使用的 CLI(命令列界面,通過命令列接受引數的程式)約定:
在呼叫
powershell.exe時,Windows PowerShell中CLI,"字符必須進行轉義用反斜杠-即作為\"-才能被保存在分析程序中的原始命令列的。pwsh.exe中,跨平臺的CLI,安裝點播PowerShell的(核心)7 版,現在很好地替代地接受""[1]代替\",這使得從呼叫cmd.exe更穩健。
相比之下,unescaped "在命令列上有句法功能,可以告訴 PowerShell 引數之間的邊界在哪里;這些"實體在命令列決議期間被洗掉。
這確保了僅希望使用引數呼叫帶有引數的 PowerShell腳本檔案( .ps1) 的-File外部呼叫者可以使用常規語法,而無需對 PowerShell 的 CLI 進行特殊情況呼叫。
但是,如果您使用引數將包含PowerShell 代碼的字串傳遞給 CLI-Command,那么 PowerShell 最終解釋的內容顯然必須是語法上有效的 PowerShell 代碼。
警告:如果您既不指定-Command也不指定-File:
powershell.exe默認為-Commandpwsh.exe現在默認為-File
有關-File和-Command呼叫之間的區別以及何時使用哪個,請參閱此答案。
If you use -Command, there are two, sequential parsing stages:
The command-line parsing stage, where syntactic (unescaped)
"are removed, and escaped\"(or"") turn into literal".The result of this stage is then parsed as PowerShell code, as it would be from inside a PowerShell session.
Therefore, you may situationally have to combine \ and `-escaping; e.g. (call from cmd.exe):
C:>powershell.exe -Command " \"3`\" of snow as of $(Get-Date)\" "
3" of snow as of 11/04/2021 14:13:41
Note the use of `\" in order to make PowerShell see `", i.e. a properly escaped " inside a "..." string, after command-line parsing.
Escaping " when calling external programs from PowerShell:
As a shell, it is PowerShell's job to pass the arguments that were passed based on its syntax rules to a target executable, so that the verbatim values that result from PowerShell's parsing are passed in a way that makes the target executable see them as such. In other words: PowerShell should perform any required escaping automatically, behind the scenes. (Unlike cmd.exe, PowerShell cannot just pass its own argument syntax through as-is, because external CLIs cannot be expected to understand '...' strings (single-quoting) or `-escaping).
To use a simply example: Passing '3" of snow' should be passed as "3\" of snow" behind the scenes, based on the most widely used escaping convention.
Sadly, up to at least PowerShell 7.1, this is not the case, and embedded " characters in arguments for external programs must additionally, manually be \-escaped in order to be passed through properly.
# Broken behavior up to at least PS v7.1
PS> cmd /c echo '{ "foo": "bar" }'
"{ "foo": "bar" }" # !! Embedded " aren't escaped.
PS> choice.exe /d Y /t 0 /m '{ "foo": "bar" }'
{ foo: bar } [Y,N]?Y # !! When parsed by an executable,
# !! embedded " are effectively LOST.
# Manual escaping required.
PS> choice.exe /d Y /t 0 /m '{ \"foo\": \"bar\" }'
{ "foo": "bar" } [Y,N]?Y # OK
This bug has existed since v1, and has never been fixed so as to avoid breaking existing workarounds. This may change in the upcoming (as of this writing) v7.2 - whether the fix will require opt-in or not is not clear to me, and it also looks like high-profile exceptions for non-conformant Windows CLIs won't be accommodated.
See this answer for more information, which includes links to relevant GitHub issues.
[1] Inside PowerShell, in "..." strings only, you may also use "" to escape an embedded ", as an alternative to `"
轉載請註明出處,本文鏈接:https://www.uj5u.com/gongcheng/348778.html
