Linuxのfile
コマンドによってタイプdataとして報告されているC++ソースファイルがいくつかあります(1つは.cpp、もう1つは.h)。これらのファイルに対してfile -bi
コマンドを実行すると、次の出力が表示されます(各ファイルで同じ出力)。
application/octet-stream; charset=binary
各ファイルは明らかにプレーンテキストです(vi
で表示できます)。 file
がこれらのファイルのタイプを誤って報告する原因は何ですか?それはある種のUnicodeのものでしょうか?これらのファイルは両方とも(Visual Studio 2005を使用して)Windowsランドで作成されましたが、Linux(クロスプラットフォームアプリケーション)でコンパイルされています。
任意のアイデアをいただければ幸いです。
更新:どちらのファイルにもヌル文字がありません。 .cppファイル(コメントブロック内)でいくつかの拡張文字を見つけて削除しましたが、file
は同じエンコーディングを報告します。 SlickEditでエンコードを強制しようとしましたが、効果がないようです。 vim
でファイルを開くと、ファイルを開くとすぐに[converted]
行が表示されます。おそらく私はvimにエンコードを強制させることができますか?
問題のある行を見つけるためにバイナリ検索を使用して問題を見つけました。
head -n {1/2 line count} file.cpp > a.txt
tail -n {1/2 line count} file.cpp > b.txt
各半分に対してfile
を実行し、プロセスを繰り返すことで、問題のある行を見つけることができました。 Control + Pを見つけました(^P
)それに埋め込まれた文字。それを削除すると問題が解決しました。将来、これらの文字(およびその他の拡張文字)を検索するためのPerlスクリプトを自分で作成します。
すべてのヒントに答えてくれたすべての人に感謝します!
Vimは、文句を言わずに、あなたが投げたものを理解しようと一生懸命努力します。これにより、file
の出力を診断するために使用するツールは比較的貧弱になります。
Vimの「[変換済み]」通知は、ロケール設定(LANGなど)で提案されたテキストエンコーディングでvimが予期しない何かがファイルにあったことを示しています。
他の人はすでに提案しています
cat -v
xxd
非ASCII文字のgrepを試すことができます。
grep -P '[\x7f-\xff]' filename
もう1つの可能性は、プラットフォームの非標準の行末(CRLFまたはCR)ですが、file
がそれに対処し、「DOSテキストファイル」などを報告することを期待しています。
file -D filename
を実行すると、file
は、実行するテストを含むデバッグ情報を表示します。終わり近くに、ファイルタイプの決定に成功したテストが表示されます。
通常のテキストファイルの場合、次のようになります。
[31> 0 regex,=^package[ \t]+[0-9A-Za-z_:]+ *;,""]
1 == 0 = 0
ascmagic 1
filename.txt: ISO-8859 text, with CRLF line terminators
これにより、そのmimeタイプであると判断するために何が見つかったかがわかります。
可能性がありますファイルの先頭にBOMが付いて保存されている可能性がありますが、ファイルバイナリの最近のバージョンを考えていたでしょうそれも認識すべきです。
「head-2 | xxd」のようなものを介してそれらをダンプし、BOMが存在するかどうかを確認してみましたか?
* BOM =バイトオーダーマーク-Unicodeテキストファイルに存在する場合があります。 http://en.wikipedia.org/wiki/Byte_order_mark
これはおそらく、Unicodeまたはその他の文字セットからの非ASCII文字です。ほとんどのLinuxディストリビューションではvi
のバージョンであるvim
を使用しているため、次のように入力してその文字を検索できます。
/[<Ctrl-V>x80-<Ctrl-V>xff]
enterキーを押します。ここで、<Ctrl-V>
は、v
キーを押しながらCtrl
と入力することを意味します。同様に、次の方法でnullを検索できます(Mehrdadが提案したように)。
/<Ctrl-V>x00
ファイルはどのcharset/encoding /(codepage)にありますか?
ファイルに漂遊文字が含まれている可能性があります。通常、異なるプラットフォーム間の不適切なクロスエンコーディングが原因です。ファイル内の無効なデータにより、説明したようにfile
が報告される可能性があります。 recode
(またはiconv
)を使用してファイルをテストすることにより、特定の文字セットエンコーディングに対するファイルの有効性をテストできます。
一般的な文字エンコードのリストについては、リンクをたどってください
このスクリプトは、ファイルに対して無効な文字セットエンコーディング($my_csets
から)を一覧表示します。次の方法ですべての文字セットを一覧表示できます:recode -l
file="$1"
my_csets="UTF-16 UTF-8 windows-1250 ASCII"
# Use the next lines to test all charsets
# =======================================
# all_csets=$(recode -l |sed -ne "/^[^:/]/p" | awk '{print $1}')
# my_csets=$all_csets
for cset in $my_csets ;do
<"$1" recode $cset.. &>/dev/null || echo "$cset ERROR: $?"
done