testdiskLinuxのパッケージを使用して、exFATサムドライブから失われたファイルを回復しようとしています。削除されたファイルを見つけるのに最適です。ところで、アイテムを見ているうちに奇妙な点を発見しました。このプログラムはファイル名を読み取ることができず、ファイルサイズが大きく、タイムスタンプが奇妙な数十の既存のファイルと削除されたファイルを要求します。
たとえば、1つのエントリは79862082558814991bytes2-Apr-1911とfilenamesを読み込みます,~WM-*'? M-kxfM-'D^^Q謁懫䞭鵣ㄆ冚୩鳼묁쐚쵡૪댷腁濬。無効な項目名は、歪んだ文字、外国語、絵文字です。興味深いことに、タイムスタンプのいくつかはUnixの時代以前です。
これらの奇妙なエントリはドライブのルートにありません。特定のフォルダにのみ存在します。英数字のみを含むファイルも正常に表示されます。
私の質問は次のとおりです
- この現象の理由は何ですか？ testdiskがランダムな残りのバイトを「削除されたファイル」として誤って選択していますか？それとも、Windowsで生成されたいくつかのファイルがLinuxに適していませんか？
- LinuxとWindowsは実際にファイル名に異なるエンコーディング/ルールセットを使用しますか？それでは、あるオペレーティングシステムでは有効ですが、別のオペレーティングシステムでは無効な名前のファイルが敵対的なオペレーティングシステムに転送されるとどうなりますか？すべてがそう言えないことに変わりましたか？
ps すべてのファイルの内容は UTF-8 でエンコードされます。
ベストアンサー1
(1) ファイルクリーナー/彫刻家はかつてファイルだったように見えるパターンを探します。これは、定義に従ってこれらのファイルを一般的に使用できなくなるために必要です。時には、ファイルではないものが特定の経験的方法と一致するため、このような誤検出が発生することがあります。
（2）私の経験によると、ほとんどのファイルシステムは仕様の一部として、または暗黙的にどこでも特定のエンコーディングを使用します。
たとえば、多くの初期ファイルシステムでは、ASCIIがすべてだったため、ASCIIを暗示していました。
NTFSは、UnicodeおよびUCS-2エンコーディング（16ビット固定幅文字）を指定します。
さまざまなLinux拡張ファイルシステムが「暗黙的」か「明示的」なのかは不明ですが、実際にはUnicodeとUTF-8、または非常に古いカーネルではASCIIかもしれません。実際のファイル名は、NUL（0）を超える解釈されていないバイトシーケンスです。これらのバイトは表示ルーチンによって文字として解釈されます。これらの表示ルーチンのほとんどは、ユーザースペース（たとえば、ls(1)使用しているユーティリティとターミナルエミュレータ）にあります。
システムに誤った文字が見つかった場合、システムは別のアクションを実行します。非常に一般的な規則として、歴史的にUnix派生システムはそれを機能させようとしましたが、/または最初はそれに気付かなかった（潜在的にユーザーにとって非常に混乱した結果をもたらす可能性があります）。一方、Microsoft派生システムは気づいたときにこれを行いました。エラーを返すか、そうでなければ奇妙に振る舞います。