DeleGateによる日本語文字コード変換

文字コード変換リバースプロキシとしてのDeleGate リバースプロキシの構成 文字コード変換プロキシ 文字コード変換リバースプロキシの構成 文字コード変換プロキシの問題点 文字コード異常の例とDeleGateによる回避方法 DeleGateによるHTTPリクエストの日本語コード変換(デモ) 各種プロトコル用文字コード変換プロキシの構成例 文字コード変換FTPプロキシ 文字コード変換Telnetプロキシ 文字コード変換POPプロキシ 文字コード変換SMTPプロキシ 文字コード変換SOCKSプロキシ 文字コード変換制御パラメタ(マニュアルより抜粋) 関連: DeleGateにおける日本語文字コードおよびMIMEコード変換機能

[2007年01月31日]
各種プロトコル用文字コード変換プロキシの構成例を追加。

[2007年01月23日]
文字コード異常の例とDeleGateによる回避方法 を追加、 文字コード変換プロキシの問題点 加筆。

[2006年12月30日]
DeleGate 9.4.2 では、10年ばかり御無沙汰気味だった日本語文字コード変換機能 について見直しを行い、以下の拡張を行いました。

• サーバ向けの文字コード変換の指定方法を拡充 (CHARCODE)
• 指定した文字を別の文字にマップする機能を導入 (CHARMAP)

■ 文字コード変換リバースプロキシとしてのDeleGate

クライアントとサーバの間の文字コードや文字セットの不整合によって、 いわゆる文字化け等の問題が発生します。 そのような問題を、サーバ側で回避するために、DeleGateを 「文字コード変換を行うリバースプロキシ」として使用することができます。

■ リバースプロキシの構成

いわゆる「リバースプロキシ」は、以下のように構成されます。

[http://www.com.dom:80] [http://serv:8880] client -------------------> DeleGate -------------------> HTTP-server

　　-P80 SERVER=http

このDeleGateは、80番ポートでHTTPサーバとして動作する

　　MOUNT="/* http://serv:8880/*"

このDeleGateが受け取る全てのURL を http://serv:8880 に転送する

　　nvhost=www.com.dom

このDeleGateが www.com.dom として参照された場合にのみ、 このMOUNTを適用する
(転送先のサーバが唯一である場合には省略可)

　　URICONV=where:any

このDeleGateが認識できる全てのテキスト型応答データに、 このMOUNTを適用する

　　PERMIT="http:serv:*"

任意のクライアントからのアクセスを許可、ただしアクセス先は http://serv に限定する

　　RELAY=no

MOUNTされたサーバへの中継以外は拒否する

client <----- EUC-JP ------- DeleGate <===== Japanese ==== HTTP-server ------ EUC-JP ------> ------ EUC-JP ----->

これが、DeleGateが当初から持っていた機能なのですが、これだけですと、逆に クライアント側からサーバへ、日本語テキストを送信する場合に問題が起こります。 典型的には検索エンジンへの検索語の送信や、掲示版への書き込みなどです。

まず、一般にクライアントは、サーバから返されたレスポンスの文字コードに 合わせてリクエストの文字コードを決定して送信します。 ここで、DeleGateによってレスポンスがサーバの文字コードと異なるコードに 変換され、クライアントがそのコードに合わせてリクエストを送信し、 サーバがその文字コードを認識してくれないと、文字化けが起こります。 また、一度もサーバからの応答を得ていない状態で、クライアントから日本語 を送信する場合には、文字コードはクライアントの一存で決められ、 サーバの期待する文字コードになっていない可能性があります。

このことから、DeleGate は 9.0.3以降、 上の例のように CHARCODE オプションによってサーバからのレスポンスに対して 文字コード変換を行った場合、サーバからのレスポンスの元の文字コードを Cookieに入れてクライアント送り、それを 次のリクエスト時に返送してもらうことで、サーバの文字コードを知り、 サーバ向けの文字コード変換を行うようになっています （ただし、サーバ向けの文字コード変換を明示的にCHARCODEオプションで 指定した場合(†1)には、そちらが優先します）。

ただこの方法には、サーバからの文字コードを一度も見ていない段階（あるいは それを記憶したCookieがクリアされた状態）でクライアントからのリクエストを サーバに中継する場合には、必要な文字コード変換が行えない、 という問題があります。

■ 文字コード変換リバースプロキシの構成

幸い、リバースプロキシの場合にはサーバが特定されていて、そのサーバが受理 できる文字コードが確定していることが普通です。このため、その文字コードに 固定的に変換してやるように、リバースプロキシを設定してやれば、より 確実に必要な文字コード変換を行うことができます。 上の例のように構成されたリバースプロキシ上で、文字 コード変換を行うとしましょう。例えば、 クライアントと http://www.com.dom のサーバとして動作している DeleGate との間では、テキストデータを UTF-8 でコード化して通信し、 DeleGate とhttp://serv:8880 サーバとの間では EUC-JP でコード化するものとします。

[http://www.com.dom:80] [http://serv:8880] client <----- UTF-8 ------- DeleGate <=================== HTTP-server ===================> DeleGate ----- EUC-JP ------>

クライアント向けのレスポンス中の日本語コードの変換は、 CHARCODE=UTF-8 と指定します。 一方、サーバ向けのリクエスト中の文字コードの変換は CHARCODE=charcode:tosv のように指定します (†2)。

[ httpd.cnfの内容 ] -P80 SERVER=http MOUNT="/* http://serv:8880/* nvhost=www.com.dom" URICONV=where:any PERMIT="http:serv:*" RELAY=no CHARCODE=UTF-8 CHARCODE=EUC-JP:tosv

最近のブラウザは、任意の文字コードに対応しているものが多いので、 サーバが受理するコードだけが限定されるという状況ならば、この例の クライアント向けの文字コード変換は不必要であるかも知れません (†3)。

ただし、一方を Unicode に、他方を JIS の文字セットに固定することで、 Unicode と JIS の文字セットの変換を行う際に、変換表を限定することで、 変換表に無い文字がコード変換時に自動的に除外されるという効果があり、 これが有効である場合が考えられます （現状のDeleGateでは、この変換の際に JIS X 0213 文字セット中の文字 が自動的に除外されます）。 また、EUC-JPあるいはISO-2022-XX系から Shift_JIS への変換でも同様です （補助漢字が自動的に除外されます）。

　サーバ向けの文字コード変換は、リクエストヘッダのURLの中、 およびPOSTリクエストのボディ(†p1)の中に、 %XX%XX (URLのエスケープ表記) あるいは &#ddddd; (Unicode文字のHTML表記) のようにエンコードされた日本語テキストに対して適用されます。 (†p2) ここで、%XX%XX の形式でエンコードされたものについては、 それが日本語テキストであるのか、またどの日本語コードで表現され ているのかは、どこにも指示されていません。このため一つの文字列が、例えば EUC-JP としても Shift_JIS としても解釈可能な場合、 変換結果が期待通りにならない場合があります (†p3)。

■ サーバ固有の文字コード指示との不整合の問題

　サーバ固有の何らかの形式で、リクエスト中の非ASCII文字の文字コードが指示 されている場合があります。(†p4) DeleGateがそのようなリクエスト中の日本語テキストに文字コード変換を行った 場合、併せてそのような指示も書換えないと、サーバ側での文字コードの判別を 誤らせることになります。 残念ながらそのような指示の形式は標準化されたものでなく、個別に対処する しかない、一般的な解決が困難な問題です。

■ 日本語文字コード間の文字セットの不整合の問題

　DeleGate/9.4.2 現在、DeleGate がサポートしている（と思われる）日本語の 文字セットは、JIS X 0201, JIS X 0208, JIS X 0212 です。 文字コードは、ISO-2022-JP, EUC-JP, Shift_JIS および UTF-8 です。 ここで、文字コードの間で、表現できる文字セットは、それぞれに異なります。 例えば「半角カナ」は、ISO-2022-JP には含まれていないので、例えば Shift_JIS から ISO-2022-JP に変換すると、半角から全角に変換されます。 例えば EUC-JP でコード化されている「補助漢字」は、Shift_JIS に変換すると 失われます。 変換先のコードが存在しない場合その文字は（デフォルトでは）ゲタ記号(〓) にしています (†p5)。

■ Unicodeの問題

　UTF-8 (Unicode文字セット) と JIS文字セットのコードと間の変換では、 Unicode.Org から配布されている変換表を、DeleGate の起動時に （CHARSET オプションが指定されている場合）、 DeleGate.ORG 経由でダウンロードして、用いています。 DeleGate/9.4.2 現在、用いているのは、OBSOLETE と分類されている変換表で、 これは JIS X 0213 を含んでいません。 今後、必要性があると判断された段階で、実装したいと思っています。 （Unihan.txt の表から日本語の文字コードを抽出することになると思います） なお、Unicode については、よく言われているように、JISコードとの間の変換が 一意でないという問題もあります。

■ 文字コード異常の例とDeleGateによる回避方法

■ 特定の文字コードにしか対応していないクライアント

　もともと DeleGateの日本語文字コード変換の機能は、黎明期のウェブブラウザ (日本語対応前の、Win/Mac 版 NCSA Mozaic)でとりあえず日本語が読めるよう、 追加されたものでした。 現在ではメジャーなHTTPのクライアントは、各種の日本語文字コードをサポート しているので、この問題はほとんど無いでしょう。 ただ、HTTP以外のプロトコルにおいては、このような変換が必要な状況は未だに あるようです。
　この問題は、サーバからクライアントにテキストを中継する際に、文字コードを クライアントがサポートしているものに変換してやることで回避できます。 例えばクライアントが EUC-JP に対応しているなら、 CHARCODE=euc-jp のように指定します。 (†b1)

■ サーバへ送られるメール・ニュースの文字コードの統一

　これもDeleGateの歴史的な用途として、ニュースリーダ(NNTPクライアント)から 投稿された記事の文字コードを、DeleGateでISO-2022-JP に強制変換してサーバに 送出するという機能が、しばらく使われていました。 この使われ方も、クライアント側の文字コード対応やネットニュースの衰退とともに、 現在ではほとんど見られなくなっていると思います。 現在では、メールを配送するSMTPの中継において、文字コードの強制や文字セットの 制限などを行う上で、必要性があるかも知れません。
　メール・ニュースのケースは、受信者(の使用クライアントプログラム)が不特定 多数であるため、受理可能な文字コードが特定できない場合といえます。 このため、日本語メール・ニュースについては、推奨されている(はずの) ISO-2022-JP に揃えるのが安全策(であるはず)です。 例えばサーバに送出(中継)するメッセージの文字コードを ISO-2022-JP に統一する には、 CHARCODE=iso-2022-jp:tosv のように指定します。 (†b2) (†b3)

■ 文字コードが指示されていない日本語テキストによる字化け

　サーバから送られて来た応答テキストが、どのような文字コードによるものか、 どこにも（HTTPやMIMEのヘッダにも、HTMLのMETAタグにも）指示されていない場合 があります。 この時、その文字コードが何であるかはクライアント（ブラウザ）側で推定する ことになりますが、その自動判別に失敗した時や、デフォルトが非日本語の状態 に設定されている時に、字化けが発生します。 (†b4)
　このようなケースの多くは、リバースプロキシあるいはクライアント側のDeleGate において、応答の文字コードを推定し、HTTPヘッダ (Content-Type 中の charset パラメタ) に指示してやることで、回避することができます。 DeleGateにこれを行わせるには、 CHARCODE=guess のように指定します。

■ 文字コードが混在した日本語テキストによる字化け

　サーバから送られて来た応答テキストが、複数の文字コードの混在したものである 場合があります。ほとんどのライアント（ブラウザ）はそれに対処してくれません ので、ここで字化けが発生します。 (†b5) これは、サーバ側で日本語文字コードを考慮せずに、複数のソースからのデータを マージしてレスポンスを合成した場合などに発生します。 そもそも、このようなテキストは通常の規格上許容されていないものですし、 文字コードの自動判別がより困難になりますが、DeleGateではいくつかの ケースについて、文字コードの混在した入力を判別して、対応しています。
　このようなケースでもやはり、リバースプロキシあるいはクライアント側のDeleGate において、特定の文字コードへのコード変換を行えば解消します。 例えば文字コードを EUC-JP に揃えるには、 CHARCODE=euc-jp のように指定します。

■ サーバ側のサポートしない文字コードでのリクエストで字化け

　検索サーバや掲示版への書き込みなど、クライアント側から送信した日本語 テキストの文字コードを、サーバ側で認識・受理できない場合に字化けが起こります。 この問題は、サーバ側がどの文字コードを受理できるかをクライアントが認識・考慮 していない場合や、そのコードに対処していない場合、そのコードで表現できない 文字を送ろうとする場合、などに発生します。
　この問題は、DeleGateによってサーバ向けのデータ中の文字コードを適切に 変換してやることで回避することができます。
　DeleGateをリバースプロキシとしての使用する場合など、対象サーバの数が 少なくその受理できる文字コードが特定できる場合には、 CHARCODE=euc-jp:tosv あるいは、 CHARCODE=euc-jp:tosv:http:server1,server2 などと指定することで対応できます。
（HTTPの）クライアント側のプロキシで、対象サーバが特定できない場合、 クライアント向けの文字コード変換、例えば CHARCODE=euc-jp などを指定すると、クライアント向けの変換の際にサーバの元の文字コードを Cookie中 (svcc) に記憶させ、 これに基づいてサーバ向けの文字コード変換を行います。

■ 各種プロトコル用文字コード変換プロキシの構成例

上述のような、拡張された CHARCODE パラメタによる文字コード変換が、 DeleGate/9.4.3 以降、HTTP以外のプロトコルにも適用できるようになりました。 (†c1) また、9.4.1で拡張された SOCKSTAP 機能を使用すると、SOCKS対応のクライアントソフトであれば、 プロキシで仲介していることをユーザに意識させることなく、 文字コード変換を行うことができます。

■ 文字コード変換FTPプロキシ

FTPには、データを転送するモード（DATA TYPE）として、 バイナリモード（TYPE IMAGE）とテキストモード（TYPE ASCII/EBCDIC）があります。 バイナリモードでは、転送されるデータには変換が加えられずに転送されますが、 テキストモードでは、必要に応じて改行コード（CRLF/LF）の変換などが行われます。 (†c2) DeleGateの日本語文字コード変換も、転送モードがテキストモードである場合に 行われます。 (†c3)

さて、DeleGateを FTPプロキシとして実行するには、以下の例のように実行します。

delegated -P8021 SERVER=ftp

この DeleGate に文字コード変換をさせる、例えばクライアント向け(ダウンロード) データをShift_JIS に変換するという場合、以下のようにします。

delegated -P8021 SERVER=ftp CHARCODE=Shift_JIS

さらに、サーバ向け(アップロード)データは UTF-8 に変換するなら、 以下のようにします。

delegated -P8021 SERVER=ftp CHARCODE=Shift_JIS CHARCODE=utf-8:tosv

ここで、上の例の方法では、利用者はDeleGateをプロキシサーバとして明示的に 認識しなければならない（ログイン名として ユーザ名@サーバ名 と入力する） のが、少しだけ面倒です。 そこで、FTPクライアントがSOCKSに対応している場合には、DeleGateをSOCKSサーバ として動作させ、 SOCKS上で中継されるFTPプロトコルを解釈して、 文字コード変換やキャッシュなどをさせることができます。 (†c4)

delegated -P1080 SERVER=socks SOCKSTAP=ftp CHARCODE=Shift_JIS

一方、DeleGate を FTP用の「リバースプロキシ」として使用する（クライアント からは通常のFTPサーバに見える）には、以下のようにします。

[ DeleGateの起動コマンド ] delegated +=ftpd.cnf [ ftpd.cnf ファイルの内容 ] -P21 SERVER=ftp MOUNT="/* ftp://ftpserv:21/*" RELAY=no CHARCODE=Shift_JIS CHARCODE=utf-8:tosv

■ 文字コード変換Telnetプロキシ

Telnetでは一つのセッションの中で、複数の文字コードが混在したテキストを容易に 端末に送ることができますので、それによって、DeleGateによる入力文字コード認識の 状態が適切でなくなることがあります。そのような場合には、 ブレーク(control-Cなど)を送ってやると、文字コード認識状態を初期化できます。

無変換中継プロキシ：

delegated -P23 SERVER=telnet://server

文字コード変換プロキシ：

delegated -P23 SERVER=telnet://server CHARCODE=iso-2022-jp CHARCODE=Shift_JIS:tosv

任意のサーバに接続できるプロキシとする場合：

delegated -P23 SERVER=telnet CHARCODE=iso-2022-jp

SOCKSプロキシとして動作し、Telenetプロトコル上の文字コードを変換する場合：

delegated -P1080 SERVER=socks SOCKSTAP=telnet CHARCODE=iso-2022-jp:tocl:telnet

■ 文字コード変換POPプロキシ

(†c5)

無変換中継プロキシ：

delegated -P110 SERVER=pop://server

文字コード変換（クライアント向け）プロキシ：

delegated -P110 SERVER=pop://server CHARCODE=EUC-JP

任意のサーバに接続できるプロキシとする場合：

delegated -P110 SERVER=pop CHARCODE=iso-2022-jp

SOCKSプロキシとして動作し、POPプロトコル上の応答の文字コードを変換する場合：

delegated -P1080 SERVER=socks SOCKSTAP=pop CHARCODE=iso-2022-jp:tocl:pop

■ 文字コード変換SMTPプロキシ

(†c5)

無変換中継プロキシ：

delegated -P25 SERVER=smtp://server

文字コード変換（サーバ向け）プロキシ：

delegated -P25 SERVER=smtp://server CHARCODE=iso-2022-jp:tosv

■ 文字コード変換SOCKSプロキシ

一つのSOCKSサーバで複数のプロトコルを中継し、指定した応用プロトコルに 文字コード変換を行うことができます。

delegated -P1080 SERVER=socks SOCKSTAP=ftp,telnet,pop CHARCODE=iso-2022-jp

---

(†c1) 文字コード変換機能自体の実装も9.4.3以降で改善されていますので、 この機能を利用される場合には、9.4.3(現時点ではpreliminaryリリース) 以降のDeleGateを利用して下さい。
(†c2) デフォルトのモードはサーバやクライアントによって異なりますが、一般には ディレクトリの情報（ファイルの一覧リスト）を転送する際にはテキストモード、 ファイルを転送する場合にはバイナリモードとなっていると思います。
(†c3) 現在の実装では、CHARCODEによる文字コード変換は、data-connection に対して のみ行われます。 control-connection（コマンド・レスポンス）に対する変換が必要な場合には、 CMAP と FTOCL / FTOSV の組合せで指定して下さい。
(†c4) 9.4.1 で導入された SOCKSTAP パラメタで、アプリケーションプロトコルの内容(メッセージ形式や手順)の 解釈・中継を行うプロトコルを指定します。
(†c5) メールやニュースに対する文字コード変換は、テキスト型のメッセージ、あるいは multipart 型のメッセージのテキスト型のパートに対して適用されます。

---

PageViews: 4,711 hits / 386 nets

以下は、DeleGate の参照マニュアル Manual.htm からの抜粋です。

CHARCODE parameter* ==  CHARCODE=[inputCode/]outputCode[:[tosv][:connMap]]
        outputCode  ==  charCode
          charCode  ==  iso-2022-jp | euc-jp | shift_jis | utf-8 | us-ascii |
                               JIS | EUC | SJIS | UTF8 | ASCII | guess
           connMap  ==  [ProtoList][:[dstHostList][:[srcHostList]]]
                    --  restriction: applicable to HTTP, FTP, SMTP, POP,
                                     NNTP, Telnet, Tcprelay
                    --  default: none

CHARMAP parameter*  ==  CHARMAP=mapType:charMap[,charMap]*[:tosv]
           mapType  ==  ascii | ucs | jis | ucsjis | jisucs
           charMap  ==  inCharCode1[-inCharCode2]/outCharCode2[-[outCharCode2]]
          charCode  ==  hexa-decimal code | single ASCII character
                    --  default: none