在PowerShell中,`r`n和`n用于表示换行的区别是什么?

22 浏览
0 Comments

在PowerShell中,`r`n和`n用于表示换行的区别是什么?

我知道Windows和Unix中有不同的换行代码。但在PowerShell中,`r`n`n都可以用于换行。

是否有自动将`n转换为`r`n的功能,为什么要使用引号而不是反斜杠?

0
0 Comments

在PowerShell中,`r`n和`n`都可以作为换行符使用,无论所在平台是什么。`n`是LF(LINE FEED)字符,用于Unix系统中的换行。`r`n是CRLF(CARRIAGE RETURN + LINE FEED)字符序列,用于Windows系统中的换行。在PowerShell中,使用`(反引号)作为转义字符,不同于其他语言中的`\`。同样需要注意的是,在正则表达式上下文中,仍然可以使用`\`作为转义字符。在输出时,PowerShell会使用平台本机的换行符,Windows使用`r`n,Unix-like平台使用`n`。

至于问题:

1. 是否有自动将`n`转换为`r`n的机制?

答:是的,使用写入文件的文本创建命令时,会隐式地使用平台本机的换行符。因此,使用`Get-Content`读取文件,并使用`Set-Content`将这些行保存到文件中,将会将原始换行符转换为平台本机的换行符。但是需要注意的是,字符编码可能会发生改变。

2. 为什么要使用反引号(`)而不是反斜杠(\)作为转义字符?

答:在PowerShell中,使用反斜杠作为转义字符会产生冲突,因为反斜杠在文件路径中表示路径分隔符。为了避免在文件路径中使用反斜杠时需要进行转义,PowerShell选择了反引号作为转义字符。其他的一些shell也面临类似的问题,如cmd.exe选择了^作为转义字符,而像Bash这样的POSIX-like shell则使用反斜杠作为转义字符。

希望这些解答对你有帮助。

0
0 Comments

在Powershell中,`r和`n都可以用作换行符,但它们在不同操作系统中的处理方式略有不同。在使用get-content命令将文件读入字符串数组时(不使用-raw参数),数组中并没有换行符。然后,根据操作系统的不同,out-file(">")或set-content命令会根据需要添加相应的换行符。过去,Mac OS只使用`r作为换行符,但现在它与unix一样,使用`n。

下面是一个只包含`n(0x0A)的osx文件的示例:

format-hex file
   Label: /Users/js/foo/file
          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 61 62 63 0A 61 62 63 0A                         abc`nabc`n

如果想要在Windows上将Unix格式的换行符转换为Windows格式的换行符,可以参考这篇文章:Unix newlines to windows newlines (on Windows)

0
0 Comments

在Windows PowerShell中,`\n`和`\r\n`都可以用来表示换行符。但是,对于解析而言,PowerShell会将这两个换行符序列都视为相同。虽然`\r\n`换行符在过去是Windows系统的一个遗留问题,但现在大多数现代的Windows应用程序都会将它们解析为相同的换行符。

需要注意的是,这里提到的不是单引号或双引号,而是重音符或反引号(大多数键盘上的波浪线键),它们是PowerShell中指定的字符串转义字符。

对于Windows PowerShell脚本,有一件事会对解析产生影响,那就是使用字节顺序标记(BOM)。只有使用UTF8-BOM才能让PowerShell解释器在代码中看到Unicode(如表情符号);也就是说,通过使用UTF8-BOM来编码。

需要注意的是,不仅是PowerShell源代码文件(如脚本)可以接受任何换行符序列(甚至可以在单个文件中混合使用):所有内置的文本文件读取命令都可以,特别是`Get-Content`命令。尽管越来越多的应用程序可以读取任何换行符序列的文件,但它们通常会使用平台本地的换行符序列进行写入(特别是PowerShell和.NET API),在Windows上是CRLF,而且在可预见的将来也不会改变。因此,这并不是过去的遗留问题。

需要更具体地说明一下正确解码UTF-8所需的BOM:只有Windows PowerShell(版本为5.1及以下的Windows专用版本)需要BOM,而PowerShell [Core](6及以上版本的跨平台版本)则默认使用无BOM的UTF-8。

我确实在之前指定了Windows PowerShell的部分,但是很感谢你提到了换行符解析的问题。

谢谢;是的,我只是想更明确地提及Windows PowerShell / PowerShell [Core]版本的区别,尤其是随着时间的推移,PowerShell [Core]将变得越来越重要。总结起来就是:为了编写跨版本的脚本/模块,请将源代码文件保存为带有BOM的UTF-8格式。

0