一般に、テキストファイルを転送する場合、ASCIIモードの使用が推奨されていますが、これには疑問を感じています。
例として、クライアントがWindowsでSJIS、サーバがUNIXでEUCの場合、ASCIIモードでクライアントからSJISのテキストファイルをアップロードすると、
そのファイルの改行コードがCR+LFからLFになりますが、その結果、SJISで改行コードがLFのなんとも中途半端なファイルができてしまいます。
それなら、いっそのことテキストファイルであろうがなんだろうが、すべてのファイルをBinaryモードで転送した方がよいように思います。必要ならば、クライアントやサーバでnkfなどのコマンドを使った方がよっぽどシンプルでトラブルが少ないと思います。
ASCIIモードの存在意義について教えてください。
もともとは、文字通りASCIIコードで利用する際の利便性を向上するために生まれたものであるため、マルチバイト言語圏での利便性については中途半端になってしまっているのは否めないと思います。
したがって、私自身も個人的にはあまりASCIIモードは当てにしていません。
しかし、CGIのアップロードなどでは、
「文字コードは勝手に対象サーバの標準に合わせられては困るけれど、改行コードはできればサーバ設定にあわせてほしい」
という局面もあるかと思います。そういった場合に使う意味はあるのではないでしょうか。
と言ってみる
Windowsのメモ帳でUnicode保存すると改行はCRLFで、RedhatのgeditでUnicode保存すると改行はLFです。
OS毎に標準が違うということであって、文字コードと改行コードの間に関係性があるわけではないのでは。
----
>それなら、いっそのことテキストファイルであろうがなんだろうが、すべてのファイルをBinaryモードで転送した方がよいように思います。必要ならば、クライアントやサーバでnkfなどのコマンドを使った方がよっぽどシンプルでトラブルが少ないと思います。
>ASCIIコードのための機能なのですね。それ以外は想定外ということで。
これはまったく同感です。
それを中途半端と考えるかどうかは人それぞれだと思います。
元々関連性の無い部分なので自分は特に気になりません。
Linux 等では改行コードは標準で LF なのでそれ以外は動作に支障が出る場合があります。
CGI(Perl) 等を使用して最初にはまるのがこれである事が多いです。
(改行コードLF でないと動かない)
もともとOS間のテキストファイル改行コードの差異を吸収する為だけの機能なので、
アップロード前のファイルもエディタ等で改行コードLFに統一できるのなら、特に必要は無いです。