在Java 18中，將UTF-8指定為標準Java API的默認字符集，有了這一更改，依賴于默認字符集的API將在所有實作、作業系統、區域設定和配置中保持一致，
做這一更改的主要目標：
- 當Java程式的代碼依賴于默認字符集時，使其更具可預測性和可移植性，
- 闡明標準Java API在哪里使用默認字符集，
- 在整個標準Java API中對UTF-8進行標準化，但控制臺I/O除外，
需要注意的是，這一更改的目標并不是定義新的標準Java API或受支持的JDK API，盡管這項作業可能會發現新的便利方法可能會使現有的API更易于使用，這一更改并不是要棄用或洗掉依賴默認字符集的標準Java API，
用于讀寫檔案和處理文本的標準Java API允許將字符集作為引數傳遞，字符集控制Java編程語言的原始位元組和16位字符值之間的轉換，例如，支持的字符集包括US-ASCII、UTF-8和ISO-8859-1，
如果沒有傳遞字符集引數，則標準的Java API通常使用默認的字符集，JDK在啟動時根據運行時環境選擇默認的字符集：作業系統、用戶的區域設定和其他因素，
因為默認字符集在每個地方都不一樣，所以使用默認字符集的API會帶來許多不明顯的危險，甚至對經驗豐富的開發人員也是如此，
考慮這樣一個應用程式，它在不傳遞字符集的情況下創建一個java.io.FileWriter，然后使用它將一些文本寫入檔案，結果檔案將包含一個使用運行應用程式的JDK的默認字符集編碼的位元組序列，第二個應用程式在不同的機器上運行，或者由同一臺機器上的不同用戶運行，在不傳遞字符集的情況下創建一個java.io.FileReader，并使用它來讀取該檔案中的位元組，生成的文本包含使用運行第二個應用程式的JDK的默認字符集解碼的字符序列，如果第一個應用程式的JDK和第二個應用程式的JDK之間的默認字符集不同，則生成的文本可能會被損壞或不完整，因為FileReader無法判斷它使用了相對于FileWriter的錯誤字符集來解碼文本，
比如這就是一個典型的例子，在MacOS上以UTF-8編碼的日語文本檔案在Windows上以美英或日語區域設定讀取時被損壞：
java.io.FileReader(“hello.txt”) -> “こんにちは” (macOS)
java.io.FileReader(“hello.txt”) -> “??“??“???????? ” (Windows (en-US))
java.io.FileReader(“hello.txt”) -> “縺ォ縺，縺ッ” (Windows (ja-JP)
在JDK 17及更早版本中，默認字符集是在Java運行時才確定的，在MacOS上，除POSIX C語言環境外，它是UTF-8，在其他作業系統上，取決于用戶的區域設定，比如：Windows上，它是基于代碼頁的字符集，如Windows-1252或Windows-31j，如果不清楚Java應用運行環境的默認編碼，可以使用這個命令查看當前JDK的默認字符集：
java -XshowSettings:properties -version 2>&1 | grep file.encoding
程式猿DD Tips：在過去的版本中，當讀寫檔案時，沒有指明字符集的話，所選擇的字符集與作業系統、用戶區域等因素相關，而不同的作業系統的默認編碼不同，所以很可能會出現讀寫編碼不一致的情況，從而導致程式在不同系統下運行出現亂碼問題，所以這一更改可以讓Java開發的應用具備更好的移植性，同時，從這一點的改進，也提醒我們，在讀寫檔案的時候，為了你的應用有更好的可移植性，在涉及讀寫操作的時候，一定要加上編碼引數，這樣即使在Java 18之前的版本，也能擁有更好的可移植性，同時為將來升級Java 21提供更好的兼容前提，
本文配套視頻：https://www.bilibili.com/video/BV1YY4y1a7vGopen in new window
如果您學習程序中如遇困難？可以加入我們超高質量的技術交流群，參與交流與討論，更好的學習與進步！另外，不要走開，關注我！持續更新Java新特性教程！
歡迎關注我的公眾號：程式猿DD，第一時間了解前沿行業訊息、分享深度技術干貨、獲取優質學習資源
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/466956.html
標籤：Java
上一篇：自定義持久層框架