比较以下两个命令:
mysqldump database_name --hex-blob -uuser_name -p | tee database_name_tee.sql
mysqldump database_name --hex-blob -uuser_name -p > database_name_out.sql
如果我运行第一个,完成后我会在终端上看到以下内容:
$ 62;c62;c62;c62;c
这是从哪里来的?这是否表明在此过程中某个地方出了问题?这些控制字符是否由于某种原因而被输出?
U+0C62是 Telugu Vowel Sign Vocalic L,我很确定它不是我的数据的一部分,所以我不认为这是 Unicode。无论如何,顺序似乎不是c62
但是62;c
。这可能是某种控制字符。无论是什么原因导致它都包含在输出文件中。如果我稍后cat
或者database_name_tee.sql
或,一旦完成,database_name_out.sql
我会再次看到这个序列。cat
tail database.sql -n200
不产生此输出;-n300
只产生$ 62;c62;c
;并-n400
产生$ 62;c62;c62;c62;c
.因此,无论是什么原因造成的,都会分布在整个文件中。
仔细研究 和head
,tail
我发现了罪魁祸首之一:一行,当保存到单独的文件并使用 打印时cat
,会生成$ 62;c62;c
.我的问题是这一行有 1043108 字节。
(生成的 SQL 文件非常好,运行时没有错误。我不认为这与 MySQL 本身有任何关系。)
我在 CentOS 服务器上运行初始版本mysqldump
,并且在服务器本身和我的 Ubuntu 桌面上看到相同的效果cat
,所以这似乎是一般的 Bash 事情。
od -c problem_line
产生65174 行输出,所以我把它缩减为演示相同输出的较小部分(也可作为普通十六进制转储)。
答案1
八进制转储中没有转义字符(那些是033
)。
有一些 8 位控制代码(通常除 xterm 之外的大多数终端都没有实现)。八进制232
是十六进制0x9a,并且(指的是XTerm 控制序列):
ESC Z
Return Terminal ID (DECID is 0x9a). Obsolete form of CSI c (DA).
...
CSI Ps c Send Device Attributes (Primary DA).
Ps = 0 or omitted -> request attributes from terminal. The
response depends on the decTerminalID resource setting.
...
-> CSI ? 6 c ("VT102")
这些字符来自终端对DECID
控制字符的响应。响应的详细信息取决于终端模拟器(问题中未提及)。