2017-08-22 12 views
1

私は今、最も素晴らしい仕事、すべてのプログラマーの夢を得ています。ここにはおよそ15年前のソフトウェアがあります。その中に「いくつかのバグ」を修正するだけです。 32ビットのjava6、tomcat6、非ユニコードのソースコード、antビルドシステム、そして私が「好き」しかできないもの。struts1 taglibでutf8を実行するにはどうすればよいですか?

注:私は電源が.warファイルにしかないため、サーバー側の設定は問題ありません。

答えて

4

あなたの主な問題は<bean:message>タグにある可能性がありますが、他のタグでも問題が発生する可能性があります。

Javaコアは非常に早いアルファ日からutf8をサポートしますが、残念ながら.propertiesファイルの処理では例外があります。これらのファイルは、JDK API呼び出しによって常にiso8859-1と解釈されます。

Struts1タグライブラリは、*.propertiesファイルに格納されたキーでアドレス指定されたi18n文字列を使用します。 struts1ソースに少し掘り、私が見つけたこれら:

  • それはISO8859-1でこのように常に、JDK呼び出しで.propertiesファイルを読み込みます。コードに深く組み込まれているため、変更する方法はありません。
  • ロケールまたはlocaleKeyは、様々なsystem.properties又はweb.xml設定によって変更することができる支柱1にパラメータがあり、.propertiesは依然としてISO8859-1として常に読み取られます。このロケール/ロケールキーは、実際に解釈されるプロパティファイルにのみ追加の拡張子を追加します。
  • struts1、およびの対応する部分をフォーク/複製せずにJDK Propertiesヘッダーにいくつかの非標準的な事柄を強制することなく、規約を変更する方法はありません。このような遺物コードの場合、それは非常に便利なことではありません。支柱と、あなたのシステムの他の部分が、

(例えば、JSPパーサ/インタプリタ)、必要に応じて、すでにいくつかの変換を行いますので、このISO8859-1テキスト場合、UTF8に変換されますJSPページは正しく設定されています(メタヘッダーなど)。

さらに、プロパティリーダーは、同様にハードワイヤードされたundisable機能を使用して、utf8を少しサポートします。 \uC0DEの形式でutf8文字を受け入れます。したがって、\uまたは\U(大文字と小文字を区別しない)の後に、とUnicode文字の16ビットの16進値を与えることができます。

長さは常に16ビットでなければならず、他の長さは許されませんが、これらはすでに大文字小文字を区別していません。 UTF8としてエンコード

my.property.key=árvíztűrő tükörfúrógép 

したがって

、...、動作しませんが、それはISO8859-1として解釈されます。

この文字列はiso8859-1として入力できます。いくつかのアクセントにはiso8859-1マッピングがないため、iso8859-1エンコーディングには存在しないため、動作しません。あなたは上記の形式にエンコードする場合

しかし、:

my.property.key=\u00E1rv\u00EDzt\u0171r\u0151 t\u00FCk\u00F6rf\u00FAr\u00F3g\u00E9p 

[はい、それは動作します!

この変換を行うには、今日は到達不能なnative2asciiツールがSunにありました。ネット上のアーカイブからこのツールを掘り起こすか、別のものを探す必要があります。

Linuxでは、uni2asciiというツールがあります(debianベースのディストリビューションでは、apt-get install uni2asciiでインストールできます)。これは正しい変換を行います。正しいパラメータは次のとおりです。

uni2ascii -a U myfile.properties 

結果はstdoutに送られます。

ビルドシステムに組み込む方法(いくつかのant/maven execモジュール、または毎回手動で変更するときに単にそれを使用する方法)はあなた次第です。

+1

Strutsを 'Properties'に責めないでください。彼らはいつも 'ISO-8859-1'でした。それはJavaの欠陥です。 – Kayaman

+1

@Kayaman Right、fixed。 :-) – peterh

+1

Javaの* fault *自体ではありません。その間、UTF-8は現在のように広く普及していなかったため、単一の文字エンコーディングを使用する「安全な」代替手段と考えられていました。それでも、それは主に迷惑になっています。 – Kayaman

関連する問題