phpでの質問です。


header("location〜")をPOSTで渡す方法を探しています。
携帯サイトなのでJavascriptは使えません。
shift-jisのサイトからutf-8のサイトへ渡します。


(1)307でリダイレクト
header('Location: '.$url, true, 307);
=>POSTの文字コードを変換できないのでダメでした。

(2)POSTで送信してからリダイレクト
http://questionbox.jp.msn.com/qa3554188.html?StatusCheck=ON
=>うまくいきません。やり方が悪いのかもしれません…。

送り元のサイトの文字コードをutf-8にしてしまえば解決するのですが、携帯サイトなのでshift-jisにするしかありません。
(最近ではほとんどの機種がutf-8対応になっていますが、社長の機種が対応していなくて…)

よろしくお願いします。

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2008/09/26 15:40:05
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:hard No.2

回答回数32ベストアンサー獲得回数4

ポイント70pt

POST送信先のサイトが修正可能でマルチバイトに対応しているのであれば、

mb_convert_encoding()で$_POSTの値を変更するだけでしょうけど、

おそらくそれが出来ないからお困りなんですよね?


送信元フォームで文字コードを指定する方法は、以下のサイトが分かりやすいと思います。

http://wiki.mesolabo.com/?%E3%83%A1%E3%82%BD%E7%9F%A5%E6%81%B5%2...

id:shotets

> POST送信先のサイトが修正可能でマルチバイトに対応しているのであれば、

> mb_convert_encoding()で$_POSTの値を変更するだけでしょうけど、

> おそらくそれが出来ないからお困りなんですよね?

まさしくその通りです!

> 送信元フォームで文字コードを指定する方法は、以下のサイトが分かりやすいと思います。

すばらしい!

探していたのはまさにこのようなことです。

accept-charset="utf-8" というやり方は知っていましたが、IEでダメだったのであきらめていました。解決方法があったのですね!

PHPにとらわれすぎて問題の根本を見失っていたのかもしれません。

ありがとうございます。

しかし、この方法で携帯で試してみたのですが、

docomo => OK, AU => OK, softbank => NG

でした。残念。


◆追記です。

softbankだけNGの理由が分かりました。

softbankの携帯が文字コードを変換できる携帯だったので

試しに「自動」から「shift-jis」や「utf-8」に変更してみたところ

なんと送信先のページがshift-jisになっていました。

(shift-jisに切り替えたら送信データが文字化けして、ページは正常。

 utf-8に切り替えたら送信データは正常、ページが文字化け。)

つまり、教えていただいた方法でちゃんとUTF-8で送られていたということです。

ただいま、相手先にshift-jisになる場合の判別方法の回答待ちです。

それに合わせて送る側も対応すれば解決します。

2008/09/26 15:34:53

その他の回答1件)

id:tezcello No.1

回答回数460ベストアンサー獲得回数69

ポイント15pt

(POST で)受け取ったデータを、エンコードを変換して、別ホストへ投げるのなら、

fsockopen(), fwrite() を使って

書き出せばよいうのでは?

(もちろんその前に、mb_convert_encording() で変換しておく)

POST で送るのなら、このサンプル

http://www.ecoop.net/memo/2005-12-29-1.html

と同じような手順で書き出せばよいのでは?

プロトコルの詳細は、HTTP プロトコル POST でググるといろいろ見つかると思います。

id:shotets

回答ありがとうございます。

質問の仕方が悪くてすみません。

POSTデータを送るだけではダメなんです。

クライアントが送り先に行かないと(リダイレクトしないと)ダメなんです。

2008/09/26 09:40:38
id:hard No.2

回答回数32ベストアンサー獲得回数4ここでベストアンサー

ポイント70pt

POST送信先のサイトが修正可能でマルチバイトに対応しているのであれば、

mb_convert_encoding()で$_POSTの値を変更するだけでしょうけど、

おそらくそれが出来ないからお困りなんですよね?


送信元フォームで文字コードを指定する方法は、以下のサイトが分かりやすいと思います。

http://wiki.mesolabo.com/?%E3%83%A1%E3%82%BD%E7%9F%A5%E6%81%B5%2...

id:shotets

> POST送信先のサイトが修正可能でマルチバイトに対応しているのであれば、

> mb_convert_encoding()で$_POSTの値を変更するだけでしょうけど、

> おそらくそれが出来ないからお困りなんですよね?

まさしくその通りです!

> 送信元フォームで文字コードを指定する方法は、以下のサイトが分かりやすいと思います。

すばらしい!

探していたのはまさにこのようなことです。

accept-charset="utf-8" というやり方は知っていましたが、IEでダメだったのであきらめていました。解決方法があったのですね!

PHPにとらわれすぎて問題の根本を見失っていたのかもしれません。

ありがとうございます。

しかし、この方法で携帯で試してみたのですが、

docomo => OK, AU => OK, softbank => NG

でした。残念。


◆追記です。

softbankだけNGの理由が分かりました。

softbankの携帯が文字コードを変換できる携帯だったので

試しに「自動」から「shift-jis」や「utf-8」に変更してみたところ

なんと送信先のページがshift-jisになっていました。

(shift-jisに切り替えたら送信データが文字化けして、ページは正常。

 utf-8に切り替えたら送信データは正常、ページが文字化け。)

つまり、教えていただいた方法でちゃんとUTF-8で送られていたということです。

ただいま、相手先にshift-jisになる場合の判別方法の回答待ちです。

それに合わせて送る側も対応すれば解決します。

2008/09/26 15:34:53
  • id:tezcello
    困っている事と、自サイト-目的サイト の関係がいまいち分からないです。
    POST とどう絡んでいるのか...

    自サイトの入力フォームのデータ送り先(action="...")が他所のサイトって事でしょうか?

    つまり、元々の問題が「アクセスしたい目的サイトのエンコードが利用環境(=社長の携帯)では使用できない」って事で、対策として「他所のサイトのフォームのみを自サイトで作った」のでしょうか?

    だとしたら、携帯と他所のサイトの間に立って、双方のエンコードの整合をとるようなプログラムを組むという事で解決できませんか?
      携帯 <-> 自サイト <-> 目的サイト

    (先の回答で示したように、(携帯と)のやり取りを、ソケット経由で目的サイトへ送ったりもらったり... 作った事が無いので詳細までは分かりませんが)

    プロキシを通している事になるので、相手が嫌がるかもしれませんねぇ。
  • id:shotets
    分かりにくくてすみません。

    > 自サイトの入力フォームのデータ送り先(action="...")が他所のサイトって事でしょうか?

    その通りです。

    ある他社のサービス(utf-8)にページ以降する際にPOST送信をしなければいけないのです。
    APIとかそういう類ではなく、ページ以降後はその他社のサイトでサービスの手続きを継続しなければなりません。


    社長の携帯のことを書いてややこしくしてしまったみたいです。
    社長の携帯はこの際関係ないですね。UTF-8に対応していない=サービスを受けられないということですものね。

    utf-8に対応していない携帯はサービスを受けられないのだから、自サイトをUTF-8にしてUTF-8未対応の携帯は無視してしまえば簡単なんでしょうけど。自サイトのコンテンツがshift-jisなのでそういうわけにもいかず。

    ソケット経由で目的サイトを受け取る場合、その後に続くサービスを受けようとすれば、目的サイト上の次のaction="~"の部分を送信先として抜き取り、自サイトのアドレスAに書き換えて、Aでまたソケット経由で送信受け取りという流れを繰り返すということになるのでしょうか。
    その場合、セキュリティ上の問題は大丈夫なのでしょうか?自サイトはSSLではなく、目的サイトはSLLです。

  • id:tezcello
    > utf-8に対応していない携帯はサービスを受けられないのだから、自サイトをUTF-8にして
    > UTF-8未対応の携帯は無視してしまえば簡単なんでしょうけど。自サイトのコンテンツが
    > shift-jisなのでそういうわけにもいかず。
    自サイトのエンコードの問題では無いように思います。
    他サイトのサービスなので、UTF-8 非対応では利用できないと明記してリンクを載せるくらいしかこちらにできることは無いのでは?
    もしも、他サイトのコンテンツを自サイトのモノの様に公開しているのだとしたら、それはアウトでしょう。


    > ソケット経由で目的サイトを受け取る場合、その後に続くサービスを受けようとすれば、
    > 目的サイト上の次のaction="~"の部分を送信先として抜き取り、自サイトのアドレスAに
    > 書き換えて、Aでまたソケット経由で送信受け取りという流れを繰り返すということに
    > なるのでしょうか。
    そういう事だと思います。

    > その場合、セキュリティ上の問題は大丈夫なのでしょうか?
    > 自サイトはSSLではなく、目的サイトはSLLです。
    SSL プロトコルを守って通信すれば、通信上のセキュリティは大丈夫なのでは?
    具体的にどうするのかは(暗号化するんだろう位しか)知りませんが。

    それよりも、目的サイトからするば不正アクセスともとられかねないので、接続を拒否されるかもしれませんね。
  • id:shotets
    やはりそうなりますよね。

    別に自サイトとして表示させたいわけでも、不正アクセスしたいわけでもないので、
    UTF-8に対応していない携帯は不可能ということになりますね。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません