如何平臺默認的字符編碼影響的跨平臺性能

Question

我已閱讀，你能解釋一下如何，可能影響跨其糟糕的主意，閱讀文本文件，並導入文本到陣列等時使用的平臺默認的字符編碼，例如平臺性能，以及如何克服這個問題？是否有應該用於跨平臺應用程序的編碼？謝謝

Answer 1

這不是關於性能，而是關於顯示和正確讀取正確編碼的文本。有許多的方式來解決該問題：

• 設置JVM選項-Dfile.encoding=utf-8
• 始終使用的字符編碼參數重載的方法。這些是String,Reader,Writer等等。

我認爲後者是必須的。如果你總是設置jvm選項，它將會起作用，但是如果你忘記在某個時候設置它，那麼隨機的地方會出現意想不到的失敗。

另一個問題 - 堅持UTF-8。請參閱this question。

Answer 2

通常它沒有問題，如果讀寫文件不在平臺之間交換。但是，如果你有例如在Windows（Win1252，類似於iso8859-1編碼）創建，然後開始在最近的Linux（UTF-8編碼），你的應用程序的配置文件，配置文件將與幾乎所有的字符在127以上（如德國變音ä問題，ö，ü或歐元符號或類似字符）。

在這種情況下，只需指定您始終使用任一編碼，並堅持使用它。如果您只使用純ASCII（非拉丁擴展！）文件，那麼到目前爲止您不會遇到任何問題。

Answer 3

的默認編碼變化從操作系統OS，甚至在同一臺機器上的用戶在一些多語言安裝的情況之間。這意味着如果使用不同的默認編碼進行讀取，由應用程序編寫的字符數據會有所不同並且不可讀/顯示損壞。歐元字符（€）將編碼爲下UTF-8字節80下窗口1252，A4下ISO-8859-15和E2 82 AC。

舊編碼能引起data loss因爲其中許多隻支持的代碼點的狹窄範圍內。

的only supported way更改默認編碼是改變它在操作系統中。

在選擇編碼方面更明確一些，更喜歡無損Unicode編碼（通常是UTF-8）。例如，在Windows上進行"ANSI"編碼作爲默認編碼的決定在支持Windows 95時更有意義。