file.encodingJavaアプリケーションでは常にシステムプロパティを設定することをお勧めします。
設定しないとしfile.encodingます。これは、Javaがプラットフォームに依存するデフォルトの文字セット（たとえばString.getBytes）を使用することを意味します。これにより、アプリケーション全体がプラットフォームに依存するようになります。
たとえば、を設定すると、そのような呼び出しがどのプラットフォームでも同じように機能-Dfile.encoding=UTF-8することが保証されます。String.getBytes
それは意味がありますか？
いいえ、必ずしも意味がありません。独自のアプリケーションで作成されていないファイルを読み取る場合は、どのプラットフォームでも、ファイルエンコーディングをデフォルトのままにしておくことをお勧めします。これは、これらのファイルを読み取ることができる必要があるためです。
また、独自のアプリケーション、またはよく知られた指定されたファイルエンコーディングを使用するアプリケーションによって作成されたファイルを読み取る場合は、IOリーダーとライターをインスタンス化するときにこのエンコーディングを使用する必要があります。
String.getBytes()単にそれらを使用しないなどの方法String.getBytes(Charset)の場合、プラットフォームのデフォルトのエンコーディングの代わりに特定のエンコーディングを使用する場合は、代わりに使用してください。
条件付きではい。JBが述べたように、「プラットフォームのデフォルト」を使用すると、他のローカルアプリケーション（または同種のサーバーファームがある場合は同じプラットフォーム上の他のリモートアプリケーション）によって生成されたファイルを読み取るときに役立つ場合があります。
ですから、慎重に選択してください。しかし、一般的にはそうすると思います。常に独自のリーダーを作成するというアドバイスが常に可能であるとは限りません。一般に、拡張文字を使用するファイルを生成するほとんどのものは、UTF-8を使用することになります。
結局、多くのファイルは制御できない選択に依存しているため、テストとカスタマイズに行き着きますが、UTF-8から始めて、必要に応じてダウングレードすることをお勧めします。
file.encodingSystem-Propertyを設定することは、Javaでサポートされている構成オプションではないため、一般的にはお勧めできません。
つまり、機能する場合と機能しない場合があります。動作しないということは、例外を意味する可能性があります。正確には、「Java 1.6で動作し、WindowsのJava 1.7で動作しますが、LinuxのJava1.7では動作しなくなりました」という種類の問題です。
その背後にある理由はここに示されています：
「file.encoding」プロパティは、J2SEプラットフォーム仕様では必要ありません。これはSunの実装の内部詳細であり、ユーザーコードによって調べたり変更したりしないでください。また、読み取り専用にすることも目的としています。コマンドラインまたはプログラム実行中の他の任意の時点で、このプロパティの任意の値への設定をサポートすることは技術的に不可能です。
VMとランタイムシステムで使用されるデフォルトのエンコーディングを変更するための推奨される方法は、Javaプログラムを起動する前に、基盤となるプラットフォームのロケールを変更することです。