これは、g++ などのコンパイラから直接出力されたファイルと-o
(outfile) フラグに関するものです。
バイナリであれば、0 と 1 の集まりでよいのではないでしょうか。
これらを cat すると、理解できない出力も得られますが、完全な単語も得られます。
ファイル化するとすぐに答えが得られます。計算は行われていないようです。バイナリ ファイルには実際にこのような情報を含むヘッダーがあるのでしょうか?
バイナリ実行ファイルは、CPU が即座に明確に理解できるマシン命令の形式でコンパイルされたプログラムにすぎないと思っていました。そうであれば、その命令セットは単なるビット パターンではないでしょうか。では、バイナリ内のその他のものは何でしょうか。ビットをどのように表示するのでしょうか。
また、プロセッサのマニュアルを入手したら、1つのマシン命令ごとに手動でバイナリを記述できますか?これは非常に非効率的ですが、とても「Hello World!」デモでも動作させることができれば魅力的です。
答え1
このスーパーユーザーの質問:バイナリ ファイルをテキスト エディターで開くと、バイナリ コードが表示されないのはなぜですか?最初のポイントに非常によく対応しています。
バイナリ データとテキスト データは分離されていません。これらは単なるデータです。これらをデータとして分類するのは、解釈次第です。バイナリ データ (画像ファイルなど) をテキスト エディターで開くと、その多くは意味をなさないものになります。これは、バイナリ データが (テキストとして) 選択した解釈に適合しないためです。
ファイルは 0 と 1 として保存されます (例: メモリの電圧/無電圧、ハード ドライブの磁化/無磁化)。cat
0/1 シーケンスは人間にとってあまり役に立たないため、ファイルを ing しても 0 と 1 は表示されません。文字の方が意味が分かりやすく、ほとんどの目的には 16 進ダンプの方が適しています (hexdump
ファイルで試してみてください)。
実行ファイルヘッダーがあるプログラムが構築されたアーキテクチャや、ファイルのどのセクションがコードでどのセクションがデータであるかなどのパラメータを記述します。これは、file
バイナリ ファイルの特性を識別するために使用されます。
最後に:はい、CPUオペコードを直接使用してアセンブリ言語でプログラムを書くことができます。UNIXアセンブリプログラミング入門そしてそのIntel x86 ドキュメント出発点として。
答え2
すべてのファイルは 1 と 0 として保存されますが、cat は各 BYTE (8 ビット) を文字として解釈しようとするため、判読できない文字が表示されます。
答え3
すべてのファイルは内部的にはバイナリであり、一連のビット。
ファイルのビットは実際にはバイトすべてのファイルは整数バイトで構成されています。すべてのUNIXシステム、そして実際ほとんどのコンピュータは8ビット(オクテット(ネットワーク用語では) バイトを 8 ビットの数値、つまり 0 から 2 8 -1 = 255までの数値として解釈する自然な方法があります。
バイナリとして見るには、バイナリ表記で書き出すツールが必要です。人間はバイナリ表記にはあまり向いていません。何かを書くのに時間がかかりすぎるからです。16進数16進数の表記法です。たとえば、41
(16進数の65)は01000001
(2進数の65)よりも読みやすいです。次のようなコマンドを使用できます。od
(“8 進ダンプ”) またはhexdump
または をhd
使用すると、各バイトを 8 進数または 16 進数で表記したファイルを一覧表示します (od -t x1
は 16 進数に切り替えます)。
バイトは文字を表すことができます。文字エンコーディングUnixの世界で使用されている。それらはすべてアスキーは、0から127までのバイトの解釈を定義します。これは、可能なバイト値の半分の意味しか定義していないことに注意してください。たとえば、65は大文字A
、97は小文字a
、30は数字0
などを表します。一部の文字エンコーディングでは、各文字を1バイトで表します。たとえば、ラテン語-1エンコーディングでは、163は を表し£
、241はñ
を表します。この方法で表現できる文字の最大数は256で、それほど多くはありません。したがって、文字ごとに1バイト以上を使用する他のエンコーディングもあります。現在、Unixの世界では、事実上の標準エンコーディングはUTF-8は可変長エンコード(文字によってバイト数が異なります)であり、Unicode文字セット。
テキスト ファイルは、理解可能なテキストを含むバイナリ ファイルです。実際、Unix プログラムの場合、次の 2 つの条件を満たすファイルはテキスト ファイルです。
- テキスト ファイルには、ヌル バイト (数値が 0 のバイト) を含めることはできません。このバイトは文字を表すものではなく、多くのテキスト操作プログラムで内部的に特別なマーカーとして使用されます。
- テキストファイルは一連の行で構成され、各行は改行文字(数値は 10 です)。
マシン実行ファイルは、特殊な種類のバイナリ ファイルです。これらcat
のファイルに対してコマンドを実行すると、時々テキストが混ざったゴミが表示されます。これらのファイルには、端末用のコマンドも偶然含まれている場合があります。プログラムを使用するとstrings
、印刷できない文字を除いたバイナリ ファイル内のすべてのテキスト フラグメントを表示できます。
マシン実行ファイルは、マシン命令のシーケンスそのものではありません。オペレーティングシステムにファイルをメモリにロードする方法を指示するちょっとした追加情報、プログラムが使用するデータ、オプションでデバッグ情報も含まれています。ほとんどのUNIXシステムは妖精マシン実行可能ファイルの形式。この形式は、マシン コードを含むファイルがどのようにセクションに分割されるかを指定します。その部分はマシン アーキテクチャに依存しません。一部のセクションにはコードが含まれ、そのコードの意味は特定のマシン アーキテクチャに固有です。
このコマンドを使用するobjdump -D /path/to/machine-executable
と、実行可能ファイルのリストを人間が読める形式で表示できます。アセンブリ言語まあ、訓練された人間なら読めるでしょう。アセンブリ言語はプロセッサ アーキテクチャに固有であり、マシン命令に直接マップされます。
アセンブリ言語で完全なプログラムを書くことは可能ですが、時間がかかるため、重要なプログラムではほとんど行われません。本当にクレイジーな場合は、プログラムを直接バイナリで書くかもしれません。印刷する最短のプログラムHello world
ライアン・ヘンゼイが書き方を説明しますPC プロセッサ用の 142 バイト ELF 実行ファイル;ブライアン・レイターELFフォーマットを分析し、45バイトのプログラムを作成した。Linux が実行できるプログラム (そのプログラムは何も印刷しません)。
バイナリファイルではない実行ファイルもあり、それらはスクリプト逆に、実行可能ではないバイナリファイルも数多くあります。画像、動画、圧縮ファイル、ワードプロセッサ文書、コードライブラリなどです。エントリーポイント、他のプロセッサ アーキテクチャ用の実行可能ファイルなど