すべてのファイル、特にテキストファイルの最後にある限り、[〜#〜] eof [〜#〜]の16進コードがあります。または[〜#〜] null [〜#〜]文字。そして、プログラムを作成してテキストファイルの内容を読み取りたい場合は、EOF hexcode。
私の質問:テキストファイルの16進表示を確認するためのツールをダウンロードしました。しかし、[〜#〜] eof [〜#〜](End Of File/NULL)または[〜#〜] eot [〜#〜](テキストの終わり)
ASCII/Hexコードテーブル:
これはHexビューアツールの出力です:
注:入力ファイルは、その内容が「「EOF」の16進コードはどこですか?」のテキストファイルです。
時間と配慮を評価してください。
EOF文字 のようなものはありません。オペレーティングシステムは、ファイルに含まれるバイト数を正確に認識します(これは、許可、作成日、および名前)、したがって、10バイトのファイルの11番目のバイトを読み取ろうとするプログラムに伝えることができます:ファイルの終わりに達したため、読み取るバイトがありません。
実際、たとえばgetchar
などのC関数によって返される「EOF」値は、バイトの範囲外の明示的なint
値です、ファイルに保存できない可能性があります!
特定のファイル形式では、NULターミネータの追加が必要になる場合があります(おそらく文字列は通常Cに格納されるためです)。また、このような装飾は通常、ファイルを「テキストファイル」と見なされないようにします。
ETXやNULなどのASCIIコードは、テレタイプライターや友人の時代に遡ります。 NULはin-memory文字列にCで使用されますが、これはファイルシステムには影響しません。
昔ファイルの終わりマーカーがありましたが、長年ファイルで使用されていませんでした。
次を使用して、Windowsでそれの遠いエコーを示すことができます。
C:\>copy con junk.txt
Hello
Hello again
- Press <Ctrl> and <z>
C:\>dump junk.txt
junk.txt:
00000000 4865 6c6c 6f0d 0a48 656c 6c6f 2061 6761 Hello..Hello aga
00000010 696e 0d0a in..
C:\>
EOTマーカーとしてCtrl-Z
を使用していることに注意してください。
ただし、Ctrl-Z
がファイルに表示されなくなったことにも注意してください。以前は0x1a
として表示されていましたが、一部のオペレーティングシステムでのみ表示され、一貫性がありません。
ETX
(0x03
)の使用は、それらの暗くて遠い時間の前でさえ停止しました。
EOFのようなものはありません。 EOFは、ファイルポインタがファイルの最後に到達したことを知らせるファイル読み取り関数によって返される値です。
EOT
バイト(0x04
)は今日まで、Unix tty端末によって入力の終了を示すために使用されています。で入力します Ctrl + D (つまり、^D
)シェルへの入力またはstdinから読み取るその他のプログラムを終了します。
ただし、他の人が指摘しているように、これはEOFとは異なります。EOFは、データそのものではなく条件です。
7ビットWintelの世界では、0x1Aまたはchr(26)です。
古いテキストファイルやアーカイブでまだ一般的に見られ、一部のファイル転送プロトコルで引き続き生成されます。特に、BBSシステムからダウンロードされたテキストファイルは、通常この文字で終了していました。
古いシステムには他にもこのようなセンチネル値があり、EOL(CR、LF、CR + LF)のようなものは時々予測される必要があります。
たとえばreturn(0)と同じレベルで、まだ使用されているのを見るのは煩わしいものです。
かつて、異なるEOF文字(異なるオペレーティングシステムの場合)。もはや見られません。通常、ファイルは128バイトのブロックにありました。)最近のBOMのようなPITAのコーディング用。
代わりに、通常はバイト値を配信するint read()
がありますが、EOFは-1を配信します.
NUL文字はCの文字列ターミネータです。Javaでは、文字列の途中にNUL文字を含めることができます。Cと連携するために、生成されるUTF-8バイトは複数のUnicode文字> 127およびNULの両方のバイトエンコーディング。
(これのいくつかはおそらく既に知られています。)