web-dev-qa-db-ja.com

Linuxのfileコマンドがテキストファイルをデータとして報告する原因は何ですか?

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にエンコードを強制させることができますか?

4
Jonah Bishop

問題のある行を見つけるためにバイナリ検索を使用して問題を見つけました。

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スクリプトを自分で作成します。

すべてのヒントに答えてくれたすべての人に感謝します!

3
Jonah Bishop

Vimは、文句を言わずに、あなたが投げたものを理解しようと一生懸命努力します。これにより、fileの出力を診断するために使用するツールは比較的貧弱になります。

Vimの「[変換済み]」通知は、ロケール設定(LANGなど)で提案されたテキストエンコーディングでvimが予期しない何かがファイルにあったことを示しています。

他の人はすでに提案しています

  • cat -v
  • xxd

非ASCII文字のgrepを試すことができます。

  • grep -P '[\x7f-\xff]' filename

もう1つの可能性は、プラットフォームの非標準の行末(CRLFまたはCR)ですが、fileがそれに対処し、「DOSテキストファイル」などを報告することを期待しています。

4
RedGrittyBrick

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タイプであると判断するために何が見つかったかがわかります。

3
Daniel Beck

可能性がありますファイルの先頭にBOMが付いて保存されている可能性がありますが、ファイルバイナリの最近のバージョンを考えていたでしょうそれも認識すべきです。

「head-2 | xxd」のようなものを介してそれらをダンプし、BOMが存在するかどうかを確認してみましたか?

* BOM =バイトオーダーマーク-Unicodeテキストファイルに存在する場合があります。 http://en.wikipedia.org/wiki/Byte_order_mark

0
GodEater

これはおそらく、Unicodeまたはその他の文字セットからの非ASCII文字です。ほとんどのLinuxディストリビューションではviのバージョンであるvimを使用しているため、次のように入力してその文字を検索できます。

/[<Ctrl-V>x80-<Ctrl-V>xff]

enterキーを押します。ここで、<Ctrl-V>は、vキーを押しながらCtrlと入力することを意味します。同様に、次の方法でnullを検索できます(Mehrdadが提案したように)。

/<Ctrl-V>x00
0
garyjohn

ファイルはどの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 
0
Peter.O