私は一つ作った
cd /folder/ && find . -not \( -path ./exclude_folder -prune \) > /log.log
そして得る
find: â<80><98>./qs/www/ergebnisse/validitaet/0df21b8a-e227-47b2-aaa5-9f54d1f9b8fd.txtâ<80><99>: No such file or directory
内部ログファイル。本当ですが：
これは何â<80><98>ですかâ<80><99>？これはカラーコードですか？それらを避ける方法（find何もない--no-color）？
待つ。cat log.log代わりにこれを行うと、次のようなvi log.log結果が得られます。
find: ‘./qs/www/ergebnisse/validitaet/0df21b8a-e227-47b2-aaa5-9f54d1f9b8fd.txt’: No such file or directory
ベストアンサー1
ディストリビューションはUTF-8文字エンコーディングを使用します。これは、ほとんどの最新のディストリビューションでは正常です。
あなたが見るのは、UTF-8でエンコードされた文字が別のエンコーディングに現れる効果です。
多くのGNUユーティリティは、オープン引用符と閉じた引用符を表すために異なる引用符を使用しようとします。これは一部のフォントにはよく見えますが、他のフォントには良くありません。
生成された出力を見てみましょうfind。
$ find /x 2>&1 | hexdump -C
00000000 66 69 6e 64 3a 20 e2 80 98 2f 78 e2 80 99 3a 20 |find: .../x...: |
前後に/xシーケンスe2 80 98の合計がありますe2 80 99。
コンソールはUTF-8で構成され、UTF-8シーケンスを正しく表示します。プログラムはcatこの順序を認識したり気にしないため、問題になりません。
一方、viファイルをlatin1として解釈します。これは、少なくとも現代のディストリビューションではまれです。 latin1では、最初のバイトはwhilee2として解釈され、latin1では無効であり、次のように表示されます。その結果は次のとおりです。â809899<80>â<80><98>â<80><99>
この状況を避ける方法は？viファイルをUTF-8としてマークするか、出力でUTF-8シーケンスを使用しないようにファイルを設定できます。
$ LC_CTYPE=C find /x 2>&1 | hexdump -C
00000000 66 69 6e 64 3a 20 27 2f 78 27 3a 20 |find: '/x': |
UTF-8シーケンスを生成する代わりに、一重引用符が開いている引用符と閉じる引用符としてfind使用されます。'
UTF8を無効にすると、プログラムが入力を処理する方法が変わる可能性がありますが、あなたの例ではこれは重要ではありません。