主页 / unix / 问题 / 787780
Accepted
Ed Morton
Asked: 2024-12-07 21:13:12 +0800 CST

为什么 grep/sed/awk 中 ' 的 ASCII 转义序列处理方式不同？

  • 772

使用所有 3 个工具的 GNU 版本（向下滚动查看 FreeBSD 尝试），如果我想'使用带有'-delimited 脚本的 awk 在输入中查找，我们可以尝试使用十六进制和八进制转义序列进行匹配：

$ echo "'" | awk '/\x27/'
'

$ echo "'" | awk '/\047/'
'

$ echo "'" | awk '/\o047/'
awk: cmd. line:1: warning: regexp escape sequence `\o' is not a known regexp operator

因此，正如您直观预期的那样，前两个方法有效，而第三个方法无效。

现在让我们用 sed 尝试同样的操作（带或不带-E）：

$ echo "'" | sed -n '/\x27/p'
'

$ echo "'" | sed -n '/\047/p'
$

$ echo "'" | sed -n '/\o047/p'
'

和 grep （带或不带-E）：

$ echo "'" | grep '\x27'
grep: warning: stray \ before x

$ echo "'" | grep '\047'
grep: warning: stray \ before 0

$ echo "'" | grep '\o047'
grep: warning: stray \ before o

所以：

  1. 最重要的是：它们为什么不同？
  2. 第二个好奇心：有没有办法在 grep 中使用转义序列进行匹配，'而无需诉诸 GNU greps 不可移植-P选项，也不需要在 grep 使用诸如这样的 shell 构造看到转义序列之前扩展转义序列grep $'\047'？

值得注意的是，八进制\047是 awk 中推荐的转义序列（请参阅http://awk.freeshell.org/PrintASingleQuote或https://web.archive.org/web/20230530010453/http://awk.freeshell.org/PrintASingleQuote，如果发生故障）。

就这个问题而言，我对允许文字的替代方案'或其他任何工具的功能或其他任何事情都不感兴趣，我只是想找出为什么这 3 个特定的正则表达式匹配工具对 ASCII 转义序列的处理方式彼此不同。但是，我有兴趣了解 BSD 或这 3 个工具的其他变体在给定上述相同脚本的情况下如何表现。

附加信息：

FreeBSD

这是 FreeBSD 13.1 的行为：

% echo "'" | awk '/\x27/'
'
% echo "'" | awk '/\047/'
'
% echo "'" | sed -n '/\x27/p'
'
% echo "'" | sed -n '/\047/p'
% echo "'" | sed -n '/\o047/p'
sed: 1: "/\o047/p": RE error: trailing backslash (\)
% echo "'" | grep '\x27'
grep: trailing backslash (\)
% echo "'" | grep '\047'
%

POSIX

以下是正则表达式的 POSIX 标准和相关 3 个工具对此的说明：

从正则表达式规范中我们看到，BRE或EREx中都不0是“特殊字符”，因此它们是“普通字符”，并且

当不在括号表达式中时，未转义字符前面的普通字符的解释是未定义的，但以下情况除外：

后面跟着字符列表，其中不包含0BRE或ERE ，因此我的结论是，在 POSIX 的正则表达式中，既没有定义行为，也没有定义x行为。\x27\047

POSIX awk 规范正则表达式部分说明：

\ddd
一个字符后跟一个、两个或三个八进制数字的最长序列 (01234567)。如果所有数字均为 0（即 NUL 字符的表示），则行为未定义。如果数字产生的值大于八进制 377，则行为未定义。

所以我们知道\0是为 POSIX awk 定义的但\x事实并非如此，所以 awk 的行为\x未由 POSIX 为 awk 定义，因此留给各种 awk 实现。

POSIX sed 规范正则表达式部分为正则表达式添加了一些变化，但没有提及\0或\x并且遵循 POSIX 正则表达式定义，因此POSIX 对于 sed 未定义\0或。\x

POSIX grep 规范描述部分完全遵循 POSIX 正则表达式定义，因此\0POSIX\x对 grep 未定义。

因此显然 的含义\xdd取决于 grep、sed 和 awk 的工具实现者，而 的含义\0dd是为 awk 定义的，但取决于 grep 和 sed 的实现者。

GNU 手册

GNU awk 手册转义序列部分说明：

\nnn
八进制值 nnn，其中 nnn 代表“0”和“7”之间的 1 到 3 位数字。例如，ASCII ESC（转义）字符的代码为“\033”。

\xhh…
十六进制值 hh，其中 hh 代表十六进制数字序列（'0'–'9'，以及 'A'–'F' 或 'a'–'f'）。'\x' 后最多允许两位数字...

这就是\x47GNU awk 的定义。

GNU sed 手册转义序列部分说明：

\oxxx
生成或匹配八进制 ASCII 值为 xxx 的字符。

\xxx
生成或匹配十六进制 ASCII 值为 xx 的字符。

\o047这就是\x27GNU sed 的定义。

GNU grep 手册中没有我找到的对十六进制或八进制转义序列的引用，这解释了我们在尝试使用它们时看到的警告消息，大概意味着它们在 GNU grep 中不受支持。

awk

1 个回答

  1. Best Answer

    \1，，，\2...用于基本正则表达式中的反向引用（20 世纪 60 年代末的 BRE ，如，， ...\3中所示）。\4edgrepsed

    70 年代后期使用新正则表达式算法引入的扩展正则表达式egrep没有（并且该算法也不可能具有）反向引用支持。

    awk与同时代egrep，其语言C从一开始就模仿了所使用的 ERE，具有类似 C 的字符串文字，您可以在其中使用\47八进制转义（就像在 C 中一样），并且没有什么可以阻止这些转义也被添加到/ERE/正则表达式文字中，因为 ERE 不能有反向引用。

    在 之外awk，POSIX BRE 和 ERE 都不支持这些转义。只有\n指定了sed（因为原始 历史上支持它sed）。

    \47作为字节 0x27 的转义序列绝对不能添加到 BRE 中，因为它会与反向引用发生冲突。由于自 70 年代末以来许多 ERE 实现都增加了对反向引用的支持，因此将其添加到 ERE 也不再是一种选择。令人痛苦的是，大多数awkERE 都不支持反向引用，而在那些支持反向引用的 ERE 中，例如 busybox，您必须执行awk '$0 ~ "^(.*)\\1$"'等效的操作grep -x '\(.*\)\1'（不是awk '/^(.*)\1$/'，而是\1匹配以 结尾的内容）。^Aawk '/^(.*)\\1$/'\1

    请注意，每个工具中的语法，但echo对于那些八进制序列（最初可能来自 C）\后跟 1 到 3 个八进制数，不需要前导，0并且对于大于 63（077）的字节数，不能以 0 为前导。 （\0377除了（）后跟echo），所以虽然不会与反向引用冲突，因为不是有效的反向引用（至少在 POSIX BRE 中，有些地方意味着整个匹配），会。\037^_7\047\0\0\377

    来自C89 \xHH（ANSI C），自 perl 4 以来也出现在 perl 中（在其字符串文字和正则表达式文字中）。它没有与反向引用冲突的问题，但尚未得到所有正则表达式引擎的支持³。在 C 中，\x后面可以跟任意数量的十六进制数字，因为charANSI C 中的 s 不必是 8 位。在 中perl，最多只接受 2 位数字，但在 Unicode 模式下\x{HH}可以扩展到\x{20AC}¹ 也受支持。在其他地方， 之后可以使用多少个十六进制数字因\x应用程序而异。例如在 ksh93 中，$'\x20AC'不是字节0x20（ASCII 中的空格）后跟AC，而是字符 U+20AC（€），UTF-8 编码²。

    自 2024 版标准以来， ksh93 中的$'\47'和$'\x27'shell 引用运算符现在已出现在POSIX 中shsh（尚未出现在所有实现中；特别是dash在大多数基于 Debian 的系统上找不到）。

    在任何情况下，像 awk "\47"（或$'\x27'4）一样，它扩展为字节 0x27，因此仅适用于'使用 ASCII 作为基本字符集的系统，所以我自己不会使用它，因为我看不出引入对特定字符编码的依赖的意义。

    zsh 中的($'\u0027'或$'\u27'或$'\U00000027')确实扩展为'字符，几乎也进入了 POSIX 2024 sh，但由于不同 shell 之间对于它们应该扩展为什么字符集存在一些分歧和差异（UTF-8 无条件地扩展为 ksh93，读取代码时语言环境的字符映射为 bash，执行代码时语言环境的字符映射为 zsh）以及当字符映射没有相应字符时该怎么办，因此它的包含被推迟到下一个主要版本。

    在任何具体情况下'，都不需要指定点代码，因为\'可以在其中使用它$'...'来表示单引号。

    有了这些\OOO和\xHH现在添加到sh，每个单独的工具就更没有必要添加对它们的支持了。

    在 POSIX 类 shell 中，我个人喜欢将, , ,单引号代码参数或任何命令的单引号参数嵌入'其中，将其插入到单引号外面：sedawkperlsh\'

    sh -c 'echo "It'\''s not pretty, but it works"'
awk 'BEGIN{print "It'\''s not pretty, but it works"}'

    使用awk，您可以执行以下操作：

    awk -v q="'" 'BEGIN{print "It" q "s not really prettier"}'

    在rc或zsh -o rcquotes

    awk 'BEGIN{print "It''s slightly prettier"}'

    在 中fish，您可以执行以下操作：

    awk 'BEGIN{print "It\'s slightly prettier"}'

    但这意味着'...'那里没有完全强的引号，因此，就像 ksh93 一样$'...'，你必须注意\里面，这很痛苦。

    另一个选择是这样做：

    awk_code=$(cat << 'EOF'
BEGIN {print "It's much more legible albeit a bit longer"}
EOF
)
awk "$awk_code"

    ¹ 甚至\x{7fffffffffffffff}超越了 Unicode 范围，扩展了 UTF-8 编码算法。

    ² 而 则$'\xe9'扩展为字节 0xe9，而不是 U+00E9 的 UTF-8 编码（é）。这与默认非 Unicode 模式下的 perl 行为相匹配，其中默认编码为 iso8859-1（又名 latin1，单字节），其中 255 以上的字符不存在，因此 perl 会针对这些字符切换到 UTF-8（并发出警告），但在 Unicode 模式下的 perl 中，"\xe9"扩展为 U+00E9 的 UTF-8 编码，而在 ksh93 中，$'\xe9'无论是否在 UTF-8 语言环境中，都是字节 0xe9。要根据其 Unicode 代码点输出 UTF-8 编码字符，最好使用较新的版本（来自 zsh）\uXXXX（或\UXXXXXXXXX对于那些高于 0xffff 的代码点）

    ³ 就您提到的 FreeBSD 而言sed，它不是由正则表达式引擎完成的；这些s 在调用正则表达式引擎之前被扩展（在各个地方，而不仅仅是正则表达式）（类似于在标准中\xHH执行的情况），并且仅从 FreeBSD 13.0 开始。subject ~ "\47"awk

    4但要注意，必须确保后面跟着的不是更多的十六进制数字，因为 ksh93 的行为$'\x20ac'会扩展为€如上所述，这是 POSIX 允许的，但不是必需的，所以如果你想要字节 0x27 后跟AC，你需要$'\x27'$'AC'例如（或使用没有问题的八进制形式；ksh93 确实支持$'\x{27}AC'，但 POSIX 没有指定，并且如上所述很少找到。

    • 9

相关问题