- - PR -
Linux環境において、Tomcat MySQL設定において、いろいろ
1
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-01-17 22:19
初歩的なことで、恐縮です。
私どもで、Javaのテストプログラムを作っております。 Windows環境では、問題なく動作したのですが、Linux環境も 挑戦しております。 そこで、以下の疑問を感じました。 WindowsのIEは、入力情報をシフトJISでサーバに送っていると認識しております。 Windows環境のTomcatはこれをEUCに自動変換してサーブレットに渡します。 ですからサーブレットでは文字コードを意識しなくても、リテラルと照合可能で した。 そして、デバッグのために内容表示をコマンドラインに出す時は、表示ルーチン の中でシフトJISに変換しますから、きちんと見えました。 ・RedHat Linux９ にてJava1.4をインストールして、テキストエデイターで編集した ソースを実行したところ、日本語のリテラル文字が化けます。 文字コードの問題だとは思いますが、どうしたらいいでしょうか？ また、Tomcatは、サブミット属性の文字列をEUCに変換することをしません。 そうするとシフトJISで入ってきます。サーブレットの中でリテラルとの照合がで きませんでした。プログラムロジックが誤動作し、わけのわからない状態になってしまいます。 なにが入って来たのかを調べようとして、その文字列をコマンドラインに表示す ると、シフトJISをEUCと見なしてシフトＪＩＳに変換しますから、文字はメチャク チャになってしまいます。 コード変換は一発タイミングがずれると、どんどん壊れていきます。 単なるコード違いではありませんから何のコードがどこで狂ったのかがすぐには わからない。 このような問題は、通常どのように解決しているのでしょうか。 そして、今日MySQLのインストールをLinux レッドハット環境に行いました。 また、よくわからないのですが、 Tomcatはバージョンが４−４．１．１８になっています。 DB Tomcatともに日本語の環境を考えますと、コード変換を行う必要があるのでしょうか。 また、Tomcatはポートも使用するのですよね。Linuxインストールでポートを開くことを指定していませんでしたので、もしかすると動かないかもしれません。 ポート番号はデフォルトで８０８０になっています。 このような、無知な当方にアドバイスをいただけますと幸いです。 | ||||||||||||||||
|
投稿日時: 2004-01-19 22:38
ちょっと最後の方は意味がわからないので最初の方だけ答えてみます･･･。
Shift_JISで送信するとは限らないと思います。 Server(コンテンツといった方が正しいかも)に合わせて フォームのデータを送信していると思います。
Tomcatでは、EUCには変換を行いません。 Servlet内部で取得できるのは、javax.servlet.ServletRequest.setCharacterEncoding() などを使用せず、特に何も処理をしていない場合は、 フォームデータをISO-8859-1の文字と解釈されたUnicode文字列が取得できるはずです。 (Tomcat5.xはどうなのかは知りませんが･･･)
え〜と、これはコマンドプロンプトに表示されている文字という事ですか？ ソースファイルのエンコーディング、またRedHat9のユーザーの環境変数LANGは どうなっているのでしょうか。 そこらへんの問題だと思います。(よく状況がわかりませんが)
文字化けに関しては、自分の場合、 内部でどう文字列が扱われているか16進数でダンプし、 その時の状況を追います。 プログラムの問題か、環境の問題かを発見できるはずです。 Servletの文字化けの問題はちょっと検索サイトで 検索をすればすぐ解決する問題だと思いますよ。 | ||||||||||||||||
|
投稿日時: 2004-01-20 00:30
いいえ、デフォルトエンコーディングで解釈されるはずです。WindowsならWindows-31J、 Unix環境なら通常はWebコンテナを起動した環境のLANGを参照していると思います。 ただし、通常はServletRequest#setCharacterEncodingで明示的にエンコーディングを 指定したほうがいいでしょう。 | ||||||||||||||||
|
投稿日時: 2004-01-20 23:35
？？？？？ 上記の情報はどこからの情報でしょうか？ http://java.sun.com/developer/technicalArticles/Servlets/servletapi2.3/ によりますと、 API 2.3 provides much-needed support for handling foreign language form submittals. There's a new method, request.setCharacterEncoding(String encoding) , that lets you tell the server a request's character encoding. A character encoding, also known as a charset, is a way to map bytes to characters. The server can use the specified charset to correctly parse the parameters and POST data. By default, a server parses parameters using the common Latin-1 (ISO 8859-1) charset. Unfortunately, that only works for Western European languages. When a browser uses another charset, it is supposed to send the encoding information in the Content-Type header of the request, but almost no browsers do. This method lets a servlet tell the server what charset is in use (it is typically the charset of the page that contains the form); the server takes care of the rest. For example, a servlet receiving Japanese parameters from a Shift_JIS encoded form could read the parameters like this: との事です。 文字エンコーディングは、サーバー環境で左右されるわけではなく、 Browserで左右される事もあるかもしれませんが、 基本的には、ISO-8859_1としてフォームデータは解釈されます。 え〜と、議論がつづきそうなら別スレ立てます〜。 [ メッセージ編集済み 編集者: ゴゴミル 編集日時 2004-01-20 23:35 ] [ メッセージ編集済み 編集者: ゴゴミル 編集日時 2004-01-21 00:52 ] | ||||||||||||||||
|
投稿日時: 2004-01-21 12:11
Servlet2.3ではデフォルトのエンコーディングが規定されていたのですね。 知りませんでした。私が書いたのは、HTTPリクエストにエンコーディング指定がない場合の 規定がなかった2.2以前での、Webコンテナの一般的な動作だとお考えください。 | ||||||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。