文字数とバイト数の違いとNCデータのサイズの変化について

“ソフトの制限の1KB”というのは、
おそらくはソフトから送出されるバイト数ですね.

“ディスク上のサイズ”というのは、
ファイルシステムが管理できる最小単位に
切り上げられた数値です.
例えば、3.5インチ2HDフロッピーディスクのFATだと、
1バイトのファイルでもディスク上の1024バイトを占有します.
これはFATというファイルシステムが
クラスタ単位でしかファイルをディスクに書き込めず、
3.5インチ2HDでは1つのクラスタが
512バイトで構成されるセクタを2つ使うからです.
ハードディスクではクラスタのサイズはより大きくなります.
1KB程度のファイルでディスク上のサイズが32KBというのは、
この1クラスタが32768バイトに設定されているという事です.

CP/Mの様な化石的に古いOSならともかく、現在のファイルシステムは、
ファイルがディスク上の何バイトを占有していようと、
バイト単位でアクセスが可能です.
仮にファイルがディスク上の32KBを占有しても、
実際のファイルサイズが1バイトであれば
1バイトのファイルとして読み出される訳です.

なお、“NCデータの文字数”に関しては、
これを何でカウントしたか判りませんが、
改行コードの扱いの違いなどでファイルサイズとの間に差が出ます.
例えば、ウィンドウズのメモ帳などで作成したテキストファイルの場合、
改行には2バイト使われます.
改行はNCではEOB(エンドオブブロック)になりますが、
NC内では一般にEOBは1文字として扱われます.
(このEOBはパンチされる際には最大で3文字になります.)
逆にスペースは、例えばファナックの場合には、
コメント内では1文字になりますが、それ以外では
何文字あろうとNCに送り込まれる際に無視されるため0文字です.
(ただファナックではプログラムをパンチする際に時折行末に意味も無くスペースが添加されます.)

では、実際に転送ソフトが送出するバイト数が
幾つになるか、という事ですが、
これははっきり言ってソフトの仕様によります.
NCが無視する文字を転送ソフトが確実に削除して送出するなら、
送出バイト数はNC上の文字数とほぼ同じになります.
ファイルをありのままに送り出すのであれば、
この送出バイト数はほぼパソコン上の実ファイルサイズになります.
EOBをLF+CR+CRに変換して送出する事になれば、
送出バイト数は実ファイルサイズ以上にもなります.
最初と最後に“%”の無いファイルに
“%”を付加して送り出してもやはり
送出されるバイト数は実ファイルサイズから大きくなります.

ただ、“ディスク上のサイズ”に相当するバイト数が
まるまる転送ソフトから送出されるという事は決してありません.
この数値はあくまでファイルの管理面で重要になるだけであり、
ファイルへのアクセス面では全く関係の無いものです.

ディスク上のサイズは、私も以前、気になって調べた記憶があります

文字数とバイトは違うもの。半角1byte(8bit）,全角・漢字は2byteが必要です
ソフトにもよると思うが、スペースも実際はカウントされるように思う
1KB→1000byte→半角文字で1000文字となる筈ですが。。。

NCdataもtext方式だろうから実際はメールで自由に送受信が可能な筈ですが、
そこは体験版だから制限を設けてNCマシン側から直に送付出来ないのかな。。
出来ればお金は使いたくないね。小分けにして送信なーんて出来ないだろうな