HTML文書ファイル名の日本語対応化について。

日本語URIの概要。(平成19年 6月29日 更新)

HTML文書のファイル名及びHTML文書を収納しているディレクトリ名に、日本語の文字(仮名・漢字)が使えるようにしたものです。

現実的な問題として、日本語にはいくつかの文字コードがあり、それぞれがそれなりに使われているという事実があります。

日本向けのモバイルコンテンツでは歴史的な理由からシフトJISコードを用いる事とされておりますが、PC向けのコンテンツではその他の文字コードも多く使われております。

PCサイトなど他のサイトから日本語URIをそのままリンクした場合、文字コードの違いを吸収しないとURIの解決が出来なくなります。

• 例えば「日本語」も
  • シフトJISコードでは%93%FA%96%7B%8C%EA
  • UTF-8コードでは%E6%97%A5%E6%9C%AC%E8%AA%9E

  となります。このように違いが生じるため、何らかの対策を執らないとどちらか或いは双方ともアクセス出来ないという事になり兼ねません。

一応、IRI(国際化されたリソース識別名)の仕様が西暦2005年(平成17年)にRFC第3987号として公開されましたが、まだまだ現実的にはIRIへの対応は充分と言えません。

• IRIではユニコードを用いて表現する事となっております。

このため、文字コードの違いを吸収する機能が必要になります。

すなわち、文字コードの相互変換機能を導入して、文字コードに関係なく々リソースを選択出来るようにする必要があるのです。

しらぎくモバイルシステムが第4.330版(平成19年 6月25日)から導入した機能は、この問題を解決するために導入されました。

具体的には、

検索エンジン及びPCに対しては、UTF-8コードに統一します

これは検索エンジンでは非英語URIはUTF-8コードでエンコードされている場合に限り文字表示されるからです。

• その他の文字コードの場合の非英語URIはURLエンコードされて表示されます。

PCに対しても日本語URIのUTF-8コード化はそれほど問題は無いと思われるので、そのようにしております。

実機にはオリジナルの文字コードのままで配信します

一般にUTF-8コードが望ましいとされておりますが、UTF-8コードはシフトJISコードなどと較べてオクテット数が増えてしまい、変換後のファイルが肥大化する原因となります。

このため、特に実機にはオリジナルの文字コードのままで配信する事とします。

• エクストラパスの場合にはURLエンコードも省略します(WAP 1.0及びH"リンクではURLエンコードしていない非アスキィのURIが処理出来ない場合があるため常にURLエンコードしております)。

文字コードの違いをアクセス時に吸収します

• 検索エンジンに対してはUTF-8コードでエンコードされた規範的(キャノニカル)なURIに恒久リダイレクトを行い、URIのエンコーディングを統一します。
• その他の環境では、エンコードに拘らずオリジナルの文書にアクセス出来るようにします。

サポートの条件。

Perlのヴァージョンが 5.8.1 依り後である事。

この条件を満たすPerlでは標準で文字コードの変換処理がサポートされます。

文字コードの変換処理を導入する事で、どの文字コードでエンコードされたURIであっても適切に処理されるようになります。

加えて、グーグルやヤフーなど検索エンジンがページ案内の際に日本語でURIを表示してくれるようにもなります。

• 検索エンジンが非英語のURIをURLエンコード無しで表示出来るようにするには、URLをUTF-8コードでエンコードする必要があります。しらぎくモバイルシステムでは検索エンジンに対してはオリジナルのファイル名がどの文字コードであっても一律にUTF-8コードでエンコードしたURIを参照してもらうようにしております。

エンコードする文字コードを設定している事。

設定ファイル「KConfig.pl」内に$path_i18nに適切な文字コードを設定しておきます。

尚、一システムで利用出来る非英語文字コードは一種類のみとなります。

従いまして、あるファイルはシフトJISコードでエンコードされたファイル名で、またあるファイルはEUC日本語コードでエンコードされたファイル名と言うような非英語文字コードを混在させる事は出来ません。

HTML文書のみが対象となります。

画像などのファイルに関してはサポートしておりません。

画像などは引続きアスキィコードの範囲でファイル名・収納ディレクトリ名を定めて下さい。

ご利用の際の注意事項。

日本語ファイル名及びディレクトリ名で好ましい文字。

日本語ファイル名及びディレクトリ名では、以下の文字をご利用になる事を推奨します。

• 従来のアスキィコードで利用出来る文字、すなわち半角英数字, 半角ハイフン, 半角アンダスコア, 半角ピリオド, 半角ティルダ
• 全角仮名文字, 仮名記号, 反復音符, 漢字

上記以外の文字、特に機種依存文字を用いた場合、アクセス出来ない場合があります。

また、全角と半角がある文字については、全角と半角が混在してもアクセスは可能ですが、URIを口頭や文書などで伝達する際にトラブルが起こる恐れがありますので統一するようにして下さい。

• アスキィ文字のみからなるURIについて、旧RFCでは半角丸括弧なども可能とされておりましたが、現行RFCでは外されておりますので、避けた方が良いでしょう。
• 尚、国際化されたURI(IRI)の仕様ではアスキィ文字のみからなるURIについて、旧RFCでは半角丸括弧なども可能とされておりましたが、現行RFCでは外されておりますので、避けた方が良いでしょう。

シフトJISコードのファイル名が化ける場合があります。

サーヴァやFTPクライアントソフトウェアに依っては、シフトJISコードでエンコードされたファイル名のファイルを転送しようとすると、サーヴァ側で文字化けしてしまう場合があります。

このトラブルが起こり得る文字は、「ソ」「表」「申」「十」などです。

設置したのにアクセス出来ない場合には、ファイル名が文字化けしている事が考えられますので、FTPクライアントソフトウェアで確認してみて、もしそうであるならファイル名を変更してみて下さい。

• ファイルの内容そのものが変質する事はありませんのでご安心下さい。

制作者が確認した不具合。(平成19年 6月30日)

ウィンドウズ XP上でのアパッチ 1.3.33・Perl 5.8.8で、UTF-8コードでエンコードされた日本語パスが正常に受け取れませんでした。

尚、

• シフトJISコードでエンコードされた日本語パスは正常に受け取れた事と、
• リナックス(フェドラ・コア)上でのアパッチ 2.0.50・Perl 5.8.3では問題が起きない事から、

OS或いはサーヴァプログラムの問題と思われます。

• その後同一のCGIを双方に置いたところ、ウィンドウズ版のPerlで正規表現が正常に処理されていない事が判明しました。データが正しく引き渡されていないようです。
• 更にサーヴァプログラムをAn HTTPDに代えてみたところ、やはり同様の誤作動が起こる事が判明しました。ウィンドウズではエクストラパスの引渡しに問題があるようです。
  • An HTTPDではこの他にもWAP 1.0端末向けなどでPNG画像が正しく配信出来ないようです。

このため、ウィンドウズ上でのサーヴァで日本語ファイル名を使いたい場合には、エクストラパスを使わずクエリでファイルを指定するように設定するようにして下さい。