■ データタイプ

前回からFTPの説明を始めている。
FTPとは何だった、ネット君。

ふぁいるとらんすふぁーぷろとこる。ファイル共有を行う為のプロトコルですよね。
やだな～、博士。忘れるわけないじゃないですか。

ふむ。自覚症状なしか、末期症状だな。

なんですか？
ちゃんと覚えていたじゃないですか。

ネット君。何事にも例外は存在する。
例外の安易な一般化は事態を混乱させるだけだぞ。

例外って。
それに事態って、どんな事態ですか？

ネット君……、いや、これは私の口から聞かされてはいけないことだろう。
ともかく、FTPだ。

うぅぅ～、なんなんですか、もう。

さて、ネット君。FTPの特徴はOSに依存しないクライアント・サーバシステムという点があったな。

そうでしたね。他のファイル共有、NetBIOSやNFSはファイルマウント型でOSに依存する、と。

うむ。OSに依存しない、ということは例えばバイトの取り扱いをどうするか、などという問題が発生する。

ばいと？
８ビットですよね。それがどう問題なんです？

何故８ビットと断定できるのだ？

え？
だって、８ビットじゃないですか。教養のコンピュータ基礎とかの授業ではそう教えてもらいましたよ？

確かにそういう基礎的な授業ではそう教えるが、実際は１バイト＝８ビットとは必ずしもいえない。
システムによっては、１バイトが７ビットだったり、９ビットだったりする。 ▼ link

へ？ １バイトが７ビットだったり、８ビットだったり、９ビットだったりするんですか？

うむ、そういうことだ。なのでネットワークでは８ビットで区切ることを、「バイト」とは言わず「オクテット」という。オクテットという言葉は以前出てきたな？

え～っと、う～んと。

ふむ、やはり、進行中か。あなどれんな。

何がです？

こっちの話だ。以前というのは、IPアドレスのところだ。第21回だ。
このようにバイトの扱いが違う以外にも、OSによって違いがあるのでFTPで差異を吸収してやらなければ、OSを無視したファイル交換ができない。

そりゃそうですね。

FTPではデータタイプという考えがあって、この問題を解決している。

でーたたいぷ？

うむ。以下の４つがある。

■ ASCIIモード

下の２つ。EBCDICとLOCALは現在はほとんど使われていないので省略する。
ASCIIとIMAGEはFTPクライアント・サーバは必ずサポートしていなければならない。ASCIIがデフォルトになる。

ASCIIって、あのASCIIですか？ 文字コードの。

そうだ。そのASCIIだ。文字データを転送するにはこのモードを使う。
動作としては、以下の形になる。

えぬぶいてーあすきー。ねっとわーくばーちゃるたーみなる。
telnetが使うASCIIですよね。

そうだ。telnet同様NVT-ASCIIを使用してデータを送る。
ASCIIモードのポイントは文字データを送るためにあることだ。

文字データってどんなのです？

テキスト文書やHTMLファイルなどだな。つまり文字そのものが主要なデータとなっているファイルだ。
これらはホストの文字コードで規定されているため、NVT-ASCIIに変換してすることが可能だ。

このようにホストで使用するコードが違っても、ちゃんとAからBへ「A」というアルファベットを送ることができるわけだ。
ちなみに改行(LFCF)もちゃんと変換する。

はは～。なんかtelnetの時に出てきた、ネットワーク仮想端末みたいですね。

そうだな。役割的には同じだな。
テキストモードには、さらにフォーマット制御が付け加えられる。

ふぉーまっと？
データを消す？

そっちのフォーマットという意味ではない。もともとの形式という意味だ。
つまり、単なるテキストというのはこう。

文字が連なっている、というだけの形式だ。画面端までいったら折り返したり、スクロールすることによって表示できる。
これをノンプリントという。

のんぷりんと。印刷しない？

そうだ。印刷したり、ディスプレイに表示したりという人間が見ることをあまり前提としていない形式だ。純粋な文字データの形式と言ってもいいだろう。これがデフォルトだ。さらに…。

改行やタブなどの文章の見栄えを制御するデータが入っているもの。これがtelnetフォーマット制御。

文章の見栄え。確かに改行とかって使いますよね。

NVT-ASCIIの制御コードを使って改行やタブを入れる。
フォーマットにはもう１つあるが、もう使われない制御フォーマットなので省略する。

NVT-ASCIIの制御コードっていうと、CRLFとかVTとかHTですよね。
単なる文字の羅列データか、改行とか入った「見る」ための文字データか、ってことですか。

■ IMAGEタイプ

もう１つのタイプは、IMAGEタイプだ。
これは文字ではない任意のビット列を転送するタイプだ。

任意のビット列？
それってどういうことです？

画像や、実行ファイル(.exe)は連続したビット列だ。特にそのビットを文字に変換して何かを行うわけではない。
そのようなデータは純粋なビットとしてそのまま送る必要がある。

あ～、JPGとかを間違ってメモ帳で開いちゃったりすると出てくるわけのわからない文字列。

そうだ。これらのファイルはビットはビットとして受け取ってもらわないと困るわけだ。
なので、「文字ではありません。ビット列(binary)ですよ」と明示して送る。

ははぁ、なるほど。ビット列をそのまま送る、と。

そういうことだ。どちらかといえば、このタイプで送ることの方が多いな。
画像や実行ファイルはこのタイプだし、例えばWordやExecelなどの.docや.xlsもこちらに入る。

へぇ、ASCIIはあまり使わないんですか？

そういうわけではないが。一般によく使われるWebサイトのアップロードの際には、HTMLファイルはASCIIタイプで送る。
Webサーバとクライアントの文字コードの違いの問題があるからな。

なるほど。

ともかく、FTPではこの２つのタイプがあるということを覚えておきたまえ。
ほとんどのFTPクライアントではこの設定が必要だしな。

了解です。

■ データ構造

さて、ファイルと一言で言っても、OSや記憶装置によって違いがある。
FTPではファイルの特性を３つに分類している。

特性？
どう違うんです？

簡単に言うと、保存方式だな。
どういう単位でデータを保存しているか、という構造だ。

どういう単位でデータを保存しているか？
…ファイル構造ならファイル単位、レコード構造ならレコード単位ってことですか？

その通り。現在ではほとんどファイル構造だ。他の２つは汎用機などで使われている形式だ。
ファイル構造は、１つのファイルの中身が特に構造化されていない、つまり単なるデータである、という構造だ。

単なるデータであるという構造？

ネット君。壊れたアナログレコードじゃあるまいし、同じ言葉を繰り返すのはよしなさい。

はぁ。でもさっぱりです。
もうちょっと日本語でお願いします。

十二分に日本語だが。
まぁ、そうだな。図で表すとこういう形だ。

ファイルの中にレコードやページがある？

簡単に言えばそうなるな。例えばレコード構造で言えば、「住所ファイル」というファイルがあったとすると、１人分のデータがレコードとして保存されている。ファイルにアクセスすると、１人分のレコードを読み書きする、という形になる。

ははぁ、わかるようなわからないような。

現在普通に使うファイルは、そのファイルにアクセスすればファイル全体のデータが表示されるだろう？ レコード構造やページ構造はそうではない、ということだ。

ファイルの中にレコードやページがある…。
例えば、Wordファイル(.doc)はページがありますよね。ということはWordファイルはページ構造なんですか？

いや。ページ構造は、各ページ単位にアクセスが可能なのだ。
Wordファイルでは、３ページ目だけを取り出す、というファイルアクセスはできないだろう？

確かにそれはできないですね。

うむ。Wordファイルは開く(アクセス)すると全ページが表示されるわけだ。つまり、ファイル構造なのだな。

なんとなく、わかったかな？

うむ。レコード構造やページ構造は使われないことが多い。
なので、まぁ、特に覚える必要はないと言えばない。

あららら。そうなんですか。

うむ。
さて、今回はこれぐらいにしておこう。

はい。

FTPがOS・システムの差異を無視するクライアント・サーバシステムを実現するために、色々やっているのがわかるだろう？

そうですね。
でも、なんかこれは使われないとか、そんなんばっかりでしたね。

うむ、それはやはりFTPが由緒ある古いプロトコルだ、ということが影響している。
昔のOSやシステムに対応するため、様々な手法を使っている、ということだよ。

古いプロトコルですからね。

現在では、タイプはASCIIタイプかIMAGEタイプ、構造はファイル構造のみ、というFTPソフトがほとんどだ。
WindowsやUNIXならばそれぐらいしか使わないからな。

なるほど。

次回はデータの転送について説明しよう。
ともかく、それではまた次回。

いぇっさ～。
３分間ネットワーキングでした～♪