次の2つのコマンドを比較してみてください。
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+0C62Telugu 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ラインの出力だから私はそれを次のように減らしました。同じ出力のより小さい部分を示します。(次にも利用可能一般的な16進ダンプ)。
答え1
8進ダンプにエスケープ文字はありません033
。
いくつかの8ビット制御コードがあります(通常、xtermを除くほとんどの端末では実装されていません)。 8進数232
は16進数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
応答から来ます。応答の詳細は端末エミュレータによって異なります(質問には記載されていません)。