在尝试通过使用空字符作为分隔符正确处理文件/文件夹名称列表（请参见我的其他问题）时，我遇到了Bash的一个奇怪行为，我不理解：
当将包含一个或多个空字符的字符串赋值给变量时，空字符会丢失/被忽略/未存储。
例如，
echo -ne "n\0m\0k" | od -c # -> 0000000 n \0 m \0 k
VAR1=`echo -ne "n\0m\0k"`
echo -ne "$VAR1" | od -c # -> 0000000 n m k
xxd命令存储数据的十六进制编码（并在需要时再次转换回原始数据）。VAR1=`echo -ne "n\0m\0k" | xxd -p | tr -d '\n'`
echo -ne "$VAR1" | xxd -r -p | od -c # -> 0000000 n \0 m \0 k
tr -d '\n' 并不是必要的，因为 xdd -r -p 似乎会吞掉/删除自动添加的换行符，至少在我使用的 bash v4.2.24 和 zsh v4.3.17 中是这样的。如果我在这里忽略了什么，请纠正我 ;) - antiplexecho -en "$username\0$password"将\n解释为换行符而不是字符串的一部分。更好的方法是使用printf "%s\0%s" "$username" "$password"或在这个问题的情况下，VAR1=$(printf "%s\0%s\0%s" n m k | xxd -p | tr -d '\n')。 - b_laoshi正如其他人所说，你不能存储或使用 NUL 字符：
然而，你可以处理任何二进制数据（包括 NUL 字符）：
因此，回答你的最后一个问题：
有人能给我指点一下，如何高效地存储或处理包含 \0 字符的字符串，而不会丢失任何（元）字符吗？
你可以使用文件或管道来高效地存储和处理任何带有任何元字符的字符串。
如果你计划处理数据，还应注意以下内容：
$(command..) 或 `command..`）除了作为变量之外还有一个额外的缺陷，就是它会吃掉你的末尾换行符。绕过限制
如果你想要使用变量，那么你必须通过编码来摆脱 NUL 字符，这里的其他各种解决方案都提供了聪明的方法来做到这一点（一个明显的方法是使用 base64 编码/解码）。
如果你关注内存或速度，你可能只想使用最小的解析器，并且只带引号 NUL 字符（和引号字符）。在这种情况下，这将对你有所帮助：
quote() { sed 's/\\/\\\\/g;s/\x0/\\x00/g'; }
然后，您可以通过将敏感数据输入quote来确保在将其存储在变量和命令行参数中之前保护您的数据，这将输出一个不含NUL字符的安全数据流。 您可以使用echo -en "$var_quoted"将原始字符串（包含NUL字符）返回，它将在标准输出上发送正确的字符串。
示例：
## Our example output generator, with NUL chars
ascii_table() { echo -en "$(echo '\'0{0..3}{0..7}{0..7} | tr -d " ")"; }
## store
myvar_quoted=$(ascii_table | quote)
## use
echo -en "$myvar_quoted"
注意：使用| hd可以以十六进制形式清晰地查看数据，并检查是否丢失了任何NUL字符。
更改工具
请记住，您可以在命令行中不使用变量或参数的情况下使用管道达到很远的效果，例如，请不要忘记<(command ...)结构，它将创建一个命名管道（一种临时文件）。
编辑：quote的第一个实现是不正确的，并且不会正确处理由echo -en解释的\特殊字符。感谢@xhienne发现这个问题。
编辑2：quote的第二次实现存在bug，因为仅使用\0，实际上会吃掉更多的零，因为\0，\00，\000和\0000是等价的。所以\0被替换为\x00。感谢@MatthijsSteen发现这个问题。
quote 函数似乎有问题。它可以正确地将 \0 字符替换为 \0，但未能转义原始流中的所有转义序列，这些序列最终会被后续的 echo -en 命令解释。 - xhienne\0，因为它会吃掉后面的3个零（echo -en '\00000' ~> 0），而是应该使用\0000或\x00。所以它应该变成这样：quote() { sed 's/\\/\\\\/g;s/\x0/\\x00/g'; } - Matthijs Steen使用uuencode和uudecode以实现POSIX可移植性
xxd和base64不符合POSIX 7标准，但uuencode符合。
VAR="$(uuencode -m <(printf "a\0\n") /dev/stdout)"
uudecode -o /dev/stdout <(printf "$VAR") | od -tx1
输出：
0000000 61 00 0a
0000003
很遗憾，除了将其写入文件之外，我没有看到Bash进程<()替换扩展的POSIX 7替代方案，并且它们在Ubuntu 12.04中默认未安装（sharutils包）。
所以我想真正的答案是：不要使用Bash来完成这个任务，使用Python或其他更合理的解释型语言。
<()，不如使用VAR="$(printf "a\0\n" | uuencode -m -)"来替代VAR="$(uuencode -m <(printf "a\0\n") /dev/stdout)"，您觉得如何？ - undefined我喜欢 杰夫的回答。我会使用Base64编码而不是xxd。它可以节省一点空间，并且更容易被认为是预期的内容。
VAR=$(echo -ne "foo\0bar" | base64)
echo -n "$VAR" | base64 -d | xargs -0 ...
-e参数。执行命令echo -n 'a\0b' | xxd -p会得到十六进制值为615c3062，代表4个字节而不是3个字节。与之对比，执行命令echo -ne 'a\0b' | xxd -p会得到610062的结果。（双引号同样适用） - Martin Jambon'\0'和"\0"在posix和bash中是等效的，它们都代表一个两个字节的字符串。 echo "\0"将打印\0，就像echo '\0'一样。 - Martin Jambon\xFF 转义了 NULL 字节。esc0() { sed 's/\xFF/\xFF\xFF/g; s/\x00/\xFF0/g'; }
cse0() { sed 's/\xFF0/\xFF\x00/g; s/\xFF\(.\)/\1/g'; }
当然，它也通过将其加倍来避免任何实际的\xFF，因此它的工作方式与使用反斜杠进行转义时完全相同。这也是为什么不能使用简单映射，并且需要引用替换中的匹配。
以下是一个示例，它使用变量预渲染块和线以提高速度，在帧缓冲区上绘制渐变（在X中不起作用）：
width=7680; height=1080; # Set these to your framebuffer’s size.
blocksPerLine=$(( $width / 256 ))
block="$( for i in 0 1 2 3 4 5 6 7 8 9 A B C D E F; do for j in 0 1 2 3 4 5 6 7 8 9 A B C D E F; do echo -ne "\x$i$j"; done; done | esc0 )"
line="$( for ((b=0; b < blocksPerLine; b++)); do echo -en "$block"; done )"
for ((l=0; l <= $height; l++)); do echo -en "$line"; done | cse0 > /dev/fb0
$block 包含转义的 NULL（加上 \xFF），在将所有内容写入帧缓冲区之前，cse0 会对它们进行反转义处理。
\0，那是因为它是用来分隔变量结尾的字符。因此，存储 NUL 字符基本上就相当于将变量设置为空。 - Nick Bull