一部のUTF-8文字（将来のバージョンで変更される可能性があります）を除いて、ASCIIログファイルがあります。
現在、gedit / lessなどでこのファイルを表示/検索/編集可能にする方法を理解する必要があります。
enca -L none file返品7bit ASCII characters Surrounded by/intermixed with non-text data。
enconv -L none -X ASCII file「成功」ですが、enconv -L none -X UTF-8 file実際には何も変わりません。
このファイルをどのように回復できますか？
アップデート（一部の回答後）：
実際、以下に示すように（すべてが同意します：）、ASCII + UTF-8はUTF-8です。私が持っているもの
0003bbc0 28 4c 6f 61 64 65 72 29 20 50 61 74 69 65 6e 74 |(Loader) Patient|
0003bbd0 20 00 5a 00 5a 00 5a 00 38 00 31 00 30 00 34 00 | .Z.Z.Z.8.1.0.4.|
0003bbe0 20 6e 6f 74 20 66 6f 75 6e 64 20 69 6e 20 64 61 | not found in da|
0003bbf0 74 61 62 61 73 65 0d 0a 32 36 20 53 65 70 20 32 |tabase..26 Sep 2|
私はこれがcp1252型エンコーディングになると思います。実際、私はそれが何であるかわかりません。 cp1252はASCIIの1バイトです。そうですか？
ところで、実際にLinux barfsは、入力ファイル（IDソース）が誤ってエンコードされていることを見つけるのに役立ちました。
答え1
「一部のUTF-8文字を除くASCII」ファイルはUTF-8ファイルです。
UTF-8ロケールを使用する限り、表示/検索/編集が可能です。
ASCIIにはUTF-8特殊文字と同等の表現がないため、ASCIIに変換できません。
Isolatinに切り替えたいと思うかもしれません
iconv -f UTF-8 -t ISO-8859-1
答え2
あなたが持っているのは実際にはASCII（通常の8ビットバイトエンコーディング）であり、一部UCS-2（Unicodeは、各文字が2つの8ビットバイトでエンコードされるBasic Plane（BMP）に制限されています。）またはおそらくUTF-16（U + D7FF以上のコードポイントのマルチワードエンコーディングを使用してすべてのUnicodeをエンコードできるUCS-2拡張）。
この不敬な混合物をすぐに処理できるツールを見つけることができるかどうか疑問です。このファイルを完全に普遍的にデコードする方法はありません。あなたの場合、おそらくある時点で一部のASCIIデータはUTF-16でエンコードされているでしょう（WindowsとJavaはUTF-16のようで、Unixの世界ではほとんど聞いたことがありません）。元のデータがすべてASCIIであると仮定すると、すべてのヌルバイトを削除して利用可能なファイルを回復できます。
<bizarre tr -d '\000' >ascii
答え3
ファイルに一部のUTF-8文字を含むASCIIが含まれている場合、そのファイルはUTF-8ファイルとして定義されます。純粋なASCIIファイルも有効なUTF-8です。
現在使用中の内容は、ASCII、UTF-8、その他のシングルバイトエンコーディング（Latin-1など）が混在しているようです。それでは整理も大変ですが、ファイルに実際にどんな内容が含まれているのか分からず、良いアドバイスをするのは難しいです。出力を投稿してみてくださいhexdump -C file（問題のある文字を含む数行に減らす）。
答え4
chardetパッケージで試してみてくださいpython-chardet。enca認識できないファイルで試しました...chardet文字セットの種類が検出されました。 （マンページによると、エンカ代表する非常に単純な文字セット分析 :)
タイプが検出できない場合、再エンコーダは入力フォーマットを知る必要があるため、再エンコードはかなり役に立ちません（参照：文字セットの検出、次のように）
たとえば、別のテキストエディタでファイルを開くことができます。emacs、、、、vimなどjedit。
geditファイルを開くダイアログボックスには、選択/追加/削除オプションがあります。文字セットリストから文字セットを選択/追加できます（文字セットが何であるかを知ったら）。geditこのリストに表示されているタイプのみが開きます。
あるいは、ワードプロセッサファイルでもよい。 OpenOffice.orgを使って開きます。
別の（切れた（？））オプションは、user.willがファイルに印刷可能な文字列を strings印刷することです。
strings
文字セットの検出問題がいっぱいです。 ~のためたくさんラテンスクリプトに基づく言語（あなたのスクリプトのようです）にたくさん文字セットが変更されます。これらの文字セットのうち、唯一の共通トピックは、基本的な7ビットASCII文字セットです。これは、16進数x 00からx 7Fまでの128の可能性で構成されています。
誰でもたくさんビット8（別の128文字）を使用するシングルバイト文字セットは、次のものを使用します。上限さまざまな文字セットがあるほど、さまざまな方法があります。
そうでなければ知るエンコーディングとは何か、検出プログラムはエンコーディングが何であるかわからないため、通常は統計的確率ゲーム（逆工学）です。手紙探しています。バイト値のみが表示されます。一意に定義された違いが見つからない場合（マイナーな操作ではない）、唯一の方法は、最も一般的に使用される一致文字セットを選択することです。
結論は、ファイルに完全に有効な文字セットAが含まれていても、文字セットBと同じように検出プログラムに有効であるということです。理由は次のとおりです。知る必要がある文字エンコーディング！ - 特にシングルバイト文字のみを使用する文字セットの場合。
マルチバイト文字セットはより明確です。指紋しかし、それでもサンプルセットが十分に大きくないと推測ゲームです...