- 締切済み
UTF-8 環境をSJIS化した後の改行コードの取扱がよくわかりません
RedHat Linux ES4 にて、デフォルトUTF-8の文字コードを以下のサイトの手順に従いSJIS化して使用しています。 (サイトの例ではEUC⇒SJISなのですが) http://www.k5.dion.ne.jp/~whatsup/linux/euc_to_sjis.html その後、Windows上でシェルスクリプトなどを作成し、ASCIIでアップロードして実行すると『:bad interpreter: そのようなファイルやディレクトリはありません』となります。 Webで調べたところ改行コードが正しくないとの事なのですが、どうにか回避することは出来ないでしょうか?
- みんなの回答 (2)
- 専門家の回答
みんなの回答
- chie65536
- ベストアンサー率41% (2512/6032)
漢字コードと改行コードは、一切、関連性がありません。 漢字を一切使わないファイルでも、改行コードを間違うとサーバーでエラーになります。 LinuxやUnixの世界では、改行コードは「LF(ラインフィード、文字コード10)」の1文字です。 MS-DOSやWindowsの世界では、改行コードは「CR(キャリッジリターン、文字コード13)」+「LF(ラインフィード、文字コード10)」の2文字です。 改行が「CR+LF」になっているテキストファイルを、Linuxサーバーにアップロードする場合「CR+LFをLFのみに書き換えてアップロード」する必要があります。ダウンロードの場合はその逆が必要です。 そして、その変換をしてくれるのが、FTPクライアントソフトの「ASCIIで転送(ASCIIモード)」です。 どうやら正しくASCIIモードで転送をしているようなので、問題は、漢字コードや改行コードの変換ではないようです。 漢字コードが違えば文字化けするだけですし、改行コードが違えば「Error 500:Internal Server Error」が出る筈。 「:bad interpreter: そのようなファイルやディレクトリはありません」が出ているとしたら、マジに「そのようなファイルやディレクトリがない」としか思えません。 シェルスクリプトの1行目の「スクリプトを実行すべきシェルの指定」で、シェルの位置が「サーバーのシェルがある位置」になってないのでは? もし、Linuxのシェルが「/user/local/bin/csh」だったら1行目には「#! /user/local/bin/csh」と書かないとならないし、「/bin/csh」だったら1行目には「#! /bin/csh」と書かないとならないですよ。 ここを間違うと、httpdが起動すべきシェルを見失います。
- sakusaker7
- ベストアンサー率62% (800/1280)
UTF-8かSJISかということと、行末のコードが どうなのかは関係ないのですがそれはおいといて。 > ASCIIでアップロードして実行すると とありますけど、ftpで転送しているのでしょうか? だとしたら本当にasciiモードになっていますか? od とか hexdumpを使って行末がどうなっているか確かめて、 本当にCR+LFになっているのなら、 tr -d '\013' < スクリプト >別のファイル でCRを消すとか。 perl -i.bak -pe 's/\r//g' スクリプト とかでもできます。
お礼
ありがとうございます。 とりあえず自己解決しました。 というか、細かい事はよくわからないのですが、エディタにて 改行コードとして『LF+CR』でなく『LF』として保存しなおしてBINARYモードで転送したら実行できるようになりました。 様々なパターンを試しましたが、実行できたのは 文字コード:SHIFT-JIS、改行コード:LF、転送モード:BINARY の組合せのみでした。
お礼
ありがとうございます。 とりあえず自己解決しました。 というか、細かい事はよくわからないのですが、エディタにて 改行コードとして『LF+CR』でなく『LF』として保存しなおしてBINARYモードで転送したら実行できるようになりました。 様々なパターンを試しましたが、実行できたのは 文字コード:SHIFT-JIS、改行コード:LF、転送モード:BINARY の組合せのみでした。