私のシステムFedora 12の単一のプレーンテキストファイルの問題について完全に混乱しています。私はバイオインフォマティクス分野で知られているソフトウェアであるMakerを使用して多数のプレーンテキストファイルを生成しましたが、そのうちの1つは「アクセスできない」ようです。
Clon1918K_PCC1.gff具体的には、...コマンドを使用するls, ls -a, ls -liとcat, vim, cp, ls私のファイルが一覧表示されますClon1918K_PCC1.gff: No such file or directory。
ところで、すべてのファイルcp *.gffやcp *このファイルをコピーすると、同じようにコピーされます。
私は問題なくノーチラスで開いてみましたが、どちらの場合でも、内容を同じ名前の別のファイルにコピーすると問題がなくなりました。興味深いことに、この場合、奇妙なファイルは書き直されず、まったく同じ名前の2つのファイルが現れました。 1つはアクセス可能で、もう1つはアクセスできません。隠されたキャラクターを探してみるのに、すべてが大丈夫だと思います。
この奇妙な出来事について考えている人はいますか？ありがとうございます！
ベストアンサー1
同じディレクトリに同じ名前の2つのファイルを含めることはできません。定義によると、ファイル名は一意のキーです。
あなたが持っているのはほとんど確かに特別な性格です。あなたがそれを確認したことを知っていますが、正確にはどうですか？ls *gff | hexdump -C特殊文字がある場所を探してみてください。高いビットが設定されたバイト（たとえば、80間の16進値などFF）は問題を示します。下20（10進数32）も特殊文字です。もう一つのヒントは、.右側のテキスト列にドットがあることですhexdump -C。
UTF-8にはUS ASCII文字のように見える文字がたくさんあります。 US ASCIIでも、1とlは似ているように見えることがよくあります。キリル文字C（U + 0421）、ギリシャの三日月シグマ（U + 03F9、Cと同じ）、キリル文字/ギリシャ語の小文字「o」などがあります。これらは見るだけです。目に見えないUnicode文字がたくさんあるかもしれません。
説明する：高いビット表現に問題があるのはなぜですか？ファイル名 "Clon1918K_PCC1.gff" は 100% 7 ビット US ASCII のようです。これを渡すと、hexdump -C次のような結果が生成されます。
00000000 43 6c 6f 6e 31 39 31 38 4b 5f 50 43 43 31 2e 67 |Clon1918K_PCC1.g|
00000010 66 66 |ff|
これらのバイト値は0x80すべて7ビットUS ASCIIコードポイントであるため、以下に示します（ビット8がクリア）。 UnicodeコードポイントU + 0000〜U + 007Fは、伝統的な7ビットUS ASCII文字を表します。コードポイントU + 0080以降は異なる文字を表し、UTF-8で2〜6バイトにエンコードされています（Linuxではman utf8これを行う方法について多くの情報を入手してください）。定義によると、UTF-8はUS-ASCIIコードポイントを独自にエンコードします。つまり、16進ASCII文字41、Unicode U + 0041はシングルバイトでエンコードされます41。コードポイント≧128は2〜6バイトでエンコードされます。それぞれは8番目のビットが設定されています。。これにより、ASCII以外の文字の存在を簡単に検出できます。ストリームをデコードする必要はありません。。たとえば、ファイル名の3番目の文字「o」（ASCII、U + 006F）を6f「ο」などのUnicode文字「U + 03FB GREEK SMALL LETTER OMICRON」に変更するとします。hexdump -Cこれで以下が生成されます。
00000000 43 6c ce bf 6e 31 39 31 38 4b 5f 50 43 43 31 2e |Cl..n1918K_PCC1.|
00000010 67 66 66 |gff|
3番目の文字はUTF-8シーケンスでエンコードされ、ce bf各バイトに8番目のビットが設定されます。この場合は、困っているという信号です。また、hexdump7ビットASCIIデコードのみが単一のUTF-8文字デコードに失敗し、印刷できない2つの文字（..）を表示します。