1

まず、説明/解決策を探すのに多くの時間を費やしたと言いたいです。問題のヒントは見つかりましたが、特定の問題を解決する方法はありません。したがって、少なくともいくつかのケースで殴打されたように見えるトピックに関する投稿.

Mime ユーティリティによる適切なエンコード/デコードをテストする Java テスト クラスがあります。テストに使用される文字列はソース ファイルで宣言されており、入力文字列の処理後に assertEquals() を使用して等価性をテストします。次に例を示します。

String test = "S2, =?iso-8859-1?Q?F=E4ltstr=F6m?= =?iso-8859-1?Q?,_Patrik?= S3";
String expected = "S2, Fältström, PatrikS3";

私のエディター (および Notepad++ や UltraEdit などの他の外部エディター) では、windows-1252 または ISO-8859-1 エンコーディングとして読み取ることを選択した場合、入力文字列が適切に表示されます。UTF-8 では、予期される文字列が "F�ltstr�m" として表示されます。

コンパイルして Windows 7 マシンで実行すると、次の出力が得られます。

予想:S2、F�ltstr�m、PatrikS3

実際の :S2、Fältström、PatrikS3

この動作は、コマンド シェルとコード エディターで発生します。奇妙なことに、Windows XP マシンで動作します。それでも、コマンド シェルで chcp を使用してコードページを確認したところ、どちらの場合も同じ出力が得られました。これを機能させる唯一の方法は、「-encoding windows-1252」を使用してクラスをコンパイルすることですが、これはさまざまな理由で実行したくありません。

質問は次のとおりです。1) XP と Windows 7 の何が違い、これが失敗するのですか? デフォルトのプラットフォーム エンコーディングは変更されましたか? 2) Windows 7 マシンと Linux マシンの両方で動作するように修正するにはどうすればよいですか?

洞察に感謝します！

4

4 に答える 4

2

Windows 7 マシンで使用されているデフォルトのエンコーディングは UTF-8 ですが、Windows XP では Windows-1252 です。したがって、コンパイル時にファイルが使用するエンコーディングを常に明示し、プラットフォームのデフォルトに依存しないでください。

ところで：私が知る限り、私のWindows 7マシンのJavaはまだデフォルトとしてWindows-1252を使用しています。

于 2011-11-30T16:10:01.457 に答える
0

事前の回答で十分です。

あなたがそれを言ったように。参考までに、私たちのプロジェクトでは、（java）ソースエンコーディングをUTF-8に設定して、国際性を維持し、\uXXXXエスケープに戻す必要がないようにしました。リーダーとライターは、エンコーディングについて明示的に言及しています。実際、私たちの国内プロジェクトでも、UTF-8を使用しています。UTF-8は新しいコンベンションかもしれないと思います。

BufferedReader in = new BufferedReader(
      new InputStreamReader(new FileInputStream(is), "UTF-8"));

件名とコンテンツでUTF-8を処理できるJavaメールAPIでは、Mime文字列エスケープは必要ありません。

于 2011-12-01T11:45:27.887 に答える
0

私はこの問題の専門家ではありませんが、それらが実際に異なるかどうかを確認するには、
地域と言語のオプション -> コントロール パネル -> 詳細オプション タブ

にアクセスしてください。また、他のデフォルトのエンコーディング (*nix、MAC など) を使用する他のオペレーティング システムについても考えてください。
これにより、推測のオプションが残ります。たとえば、ラテン文字 A がある場合、ASCII、UTF-8、または ISO-8859-1 のいずれであるかを識別できないためです。これらの文字セットは文字を文字テーブルの同じエントリにマップするためです。 (この場合、16 進表記のテーブル エントリ 41)!
どうにかしてこれを解決したい場合は、 CharsetEncoder( Java SE 7 - CharsetEncoder )を使用する以外に完璧な解決策はありません。CharsetDecoder( Java SE 7 - Charset Decoder )文字を特定の形式で扱い、バイトとしてエンコード/デコードできる場合があります。ただし、このアプローチには次のような欠点もあります
。1) すべての文字マッピングが正常に検出されるとは期待できません。
2) 複数の/重い I/O を実行すると、パフォーマンスが大幅に低下します。

私の意見では、あなたの最善の策は次のとおりです。

Unix スタイルの行末 (/n) を使用して独自のエンコード/デコード (つまり UTF-8) を強制し、すべてのファイルをそのように扱います。他の人が作成したファイルを読み取ることが予想され、エンコーディングでマップできない文字を読み取ることが予想される場合は、「より大きな」文字セット (UTF-16) を使用するか、「不正な」文字をバイト単位で読み取って、バイト単位の独自のエンコーディング (ただし、読み取り不能/表現不可能な形式で書き込まれます!)

私の $0.02 セント。楽しんでください:)

編集：この投稿もチェックしてください：文字セット変換Java

于 2011-11-30T16:43:42.227 に答える
0

修正方法については、テスト データを 1 つまたは複数のファイルに保存することをお勧めします。ファイルが必要なエンコーディングで保存されていることを確認してください。必要なエンコーディングを使用して、実行時にテスト データを読み込みます。これにより、テストがコンパイラのエンコーディングから切り離されます。

于 2011-11-30T16:15:16.473 に答える