ＤＯＳで、ＡＳＣＩＩデータをバイナリコピーにて結合するとゴミがはいる？

DOSで、2つのASCIIデータをバイナリコピー（COPY /b)すると1バイトのゴミが入る場合があるのですが、なぜこのようになるのでしょうか？

しかし、必ずゴミが入るわけではないようにも思います。
→たまたま入る時がある？
→ASCIIデータの形によって、入る時がある？
バイナリコピーしない場合（COPY）は混在することは無いように思います。

昔、ASCIIデータは、バイナリコピーしない方が無難と聞いたことがある気もするのですが、昔過ぎて理由等忘れてしまいました。

詳しい方いらっしゃいましたらお教えいただけると助かります。

No.1 ベストアンサー 回答者： koi1234 回答日時： 2010/04/20 10:53

手元の環境でやってみました（WindowsのDOS窓ですが）

その1バイト増えるごみ というのはもしかしたらファイルの最後に
付いておりデータとして 0x1A（16進） ではありませんか？
（此方でやった限り逆にアスキーコピーした時に付いてるようですが）

そうならファイルの終了マーカを意味している物ではないかと思います
http://support.microsoft.com/kb/29852/ja

ファイルの中間にデータが増えるとか言うのでしたら
具体的なファイルのダンプコードなどをチェックするか
ここに乗せた方がいいのではないかと思います

アスキー（テキスト）ファイルの作成方法によってはファイル終了マーカとして
最後に0x1Aが書き込まれます
例）
DOSプロンプト上で copy con ファイル名 等として直接ファイル入力
終了する時には CTRL+Z の入力となりそのような作成すると
0x1Aが書き込まれます

プログラムなどでファイル造作する場合でもアスキーモードで開けば
このデータは無視されるはずです

この回答へのお礼

返答が遅くなり申し訳ありません。
内容理解し試したところその通りでした。
とても助かりました。

お礼日時：2010/09/20 01:00

No.2 回答者： siremono2496 回答日時： 2010/04/21 00:26

No1回答者さんからも指摘がありますが、テキストファイルの末尾にあるEOFコードがその正体でしょう。

ただこれも、どのテキストファイルにも存在するかというと、必ずしもそうとは言い切れません。Windows付属のメモ帳（NOTEPAD.EXE）で作成したテキストファイルも、確かWin98の頃にはもうEOFコードは付かなくなっていたと思います。もはやEOF自体が、かなり歴史的理由のためだけに存在するものになっているため、なくても問題ないでしょう。今となっては、EOFがあることで問題を起こすことの方が多いかも知れません。

また、これはDOSの頃からの伝統ですが、COPYの/Bオプションの機能は、複数ファイルを結合する時、ファイル内にEOFコードがあってもそこで停止しないようにするだけです。なので、もし結合するバイナリファイルの中にEOFと同じデータがない場合は、/Bをつけてもつけなくても動作は同じです。これとは逆に、末尾がEOFでないテキストファイルを結合する時も、やはり/Bの有無には関係なく同じファイルが出来上がります。

テキストとバイナリでファイルを区別することは、フロッピーですら贅沢品であった時代の遺物と言ってよいのでは？今はもう個人でも普通にGB単位の大きさのファイルを扱う時代です。マシンパワーもファイル管理ごときでは負荷らしい負荷になりません。テキストかバイナリかでコマンドの動作を変えることの合理性は、すでにほぼ失われたと個人的には思います。

余談ながら、ftp転送でも同様にテキストとバイナリを区別できますが、これもやはり歴史的理由と言えるでしょう。良かれと思ってテキストモードで転送したのに、サーバ側で勝手に改行コードや文字コードを変えられてしまい、えらい目に遭ったなんて言うトラブルもありますし、こちらも害の方が目立つ状況です。全てバイナリモードでアップロードすれば、こうした問題は起きないので、普通のユーザーにとってはむしろ確実です。

この回答へのお礼

返答が遅くなり申し訳ありません。
補足説明ありがとうございました。
とても助かりました。

お礼日時：2010/09/20 01:01