• 本文作者：@Ryan Miao
• 本文鏈接：https://www.cnblogs.com/woshimrf/p/java-utf8-iso-charset.html
• 版權聲明：?本博客所有文章除特別聲明外，均采用?CC BY-NC-SA 3.0?許可協議。轉載請注明出處！

目錄

1.1 結論放在開頭
1.2 為什么要編碼，我們認知的符號地如何存在的
1.2.1 java中的編碼
1.2.2 幾個重要的編碼
1.2.3 java中編碼的流程
1.2.4 繼續舉例分析字符在java中的亂碼情況
1.3 java web的一些編碼知識

Post@https://ryan-miao.github.io
測試代碼https://github.com/Ryan-Miao/someTest/commit/50241e50d4b6ecdb8820e58f4cb9628bfb7d77ec

背景

還是多語言, 在項目中遇到本地環境和服務端環境不一致亂碼的情形。因此需要搞清楚亂碼產生的過程，來分析原因。

獲取多語言代碼如下：

private Map<String, String> getLocalizationContent(Locale locale) {ResourceBundle bundle = ResourceBundle.getBundle(this.resourceBundleName, Locale.US);ResourceBundle bundleLocale = ResourceBundle.getBundle(this.resourceBundleName, locale);Set<String> keys = bundle.keySet();Map<String, String> map = new HashMap();String key;String translation;for(Iterator var6 = keys.iterator(); var6.hasNext(); map.put(key, translation)) {key = (String)var6.next();try {translation = bundleLocale.getString(key);translation = new String(translation.getBytes("ISO-8859-1"), "UTF-8");translation = this.escapeStringForJavaScript(translation);} catch (UnsupportedEncodingException | MissingResourceException var10) {translation = bundle.getString(key);}}return map; }

其中，因為ResourceBundle通過PropertyResourceBundle讀取properties文件。 這就要看以哪種方式load Properties了。提供了兩種構造函數：

public PropertyResourceBundle (InputStream stream) throws IOException {Properties properties = new Properties();properties.load(stream);lookup = new HashMap(properties); } public PropertyResourceBundle (Reader reader) throws IOException {Properties properties = new Properties();properties.load(reader);lookup = new HashMap(properties); }

通過跟蹤ResourceBundle.getBundle(this.resourceBundleName, locale);源碼發現創建bundle的方法為：

public ResourceBundle newBundle(String baseName, Locale locale, String format,ClassLoader loader, boolean reload)throws IllegalAccessException, InstantiationException, IOException {String bundleName = toBundleName(baseName, locale);ResourceBundle bundle = null;if (format.equals("java.class")) {try {@SuppressWarnings("unchecked")Class<? extends ResourceBundle> bundleClass= (Class<? extends ResourceBundle>)loader.loadClass(bundleName);// If the class isn't a ResourceBundle subclass, throw a// ClassCastException.if (ResourceBundle.class.isAssignableFrom(bundleClass)) {bundle = bundleClass.newInstance();} else {throw new ClassCastException(bundleClass.getName()+ " cannot be cast to ResourceBundle");}} catch (ClassNotFoundException e) {}} else if (format.equals("java.properties")) {final String resourceName = toResourceName0(bundleName, "properties");if (resourceName == null) {return bundle;}final ClassLoader classLoader = loader;final boolean reloadFlag = reload;InputStream stream = null;try {stream = AccessController.doPrivileged(new PrivilegedExceptionAction<InputStream>() {public InputStream run() throws IOException {InputStream is = null;if (reloadFlag) {URL url = classLoader.getResource(resourceName);if (url != null) {URLConnection connection = url.openConnection();if (connection != null) {// Disable caches to get fresh data for// reloading.connection.setUseCaches(false);is = connection.getInputStream();}}} else {is = classLoader.getResourceAsStream(resourceName);}return is;}});} catch (PrivilegedActionException e) {throw (IOException) e.getException();}if (stream != null) {try {bundle = new PropertyResourceBundle(stream);} finally {stream.close();}}} else {throw new IllegalArgumentException("unknown format: " + format);}return bundle; }

也就是說，最終通過properties.load(stream);的方法讀取properties文件的。

The load(Reader) / store(Writer, String) methods load and store properties from and to a character based stream in a simple line-oriented format specified below. The load(InputStream) / store(OutputStream, String) methods work the same way as the load(Reader)/store(Writer, String) pair, except the input/output stream is encoded in ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes as defined in section 3.3 of The Java? Language Specification;?only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings.

@Test public void unicodeToChar(){char aChar = '\u4E2D';Assert.assertEquals('中', aChar);String aStr = "\u4E2D\u6587";Assert.assertEquals("中文", aStr);}

根據官方文檔，使用Unicode轉義可以識別中文字符的。按照之前本地的表現，Properties文件以中文原樣書寫，并且文件字符集為utf8,生成字節流的時候中文肯定會變成多個字節。這樣系統讀取之后的字符是不對的。需要再次使用utf8編碼為正確的字符。而服務端的表現是：不需要再次編碼，讀出來的字符就是正確的。那么就可以證明服務端的Properties文件的中文經過了轉義，或者讀取的時候進行了轉義。目前本地和服務端的唯一區別就是系統。一個是打包的過程，本地編譯是否和服務端編譯不同？一個是服務端的jvm，到現在沒搞清楚服務端jvm的版本。看消息說，java9可以支持直接使用中文而不用轉碼了。

所以, 問題的根源找到了： 先證明打包是否有問題--將服務端的包在本地跑一下。然后驗證服務端的jvm是否有直接讀取utf8的能力---編寫一個簡單的讀寫code。

找問題的時候找了很久，經過高人指導后又靜心查閱了編碼的資料才能融會貫通。以下是查資料時整理的對理解編碼和亂碼有用的文章。

---

亂碼的分類

目前看到兩種亂碼：問號和ISO符號亂碼。

1. 開始學習亂碼之道

以下內容轉載自深入分析 Java 中的中文編碼問題, 作者：許令波，發表時間：2011 年 7 月 06 日。

1.1 結論放在開頭

iso-8859-1以一個字節(1 byte)存儲字符。即字符a存儲為一個字節，即8位(8 bit)。

utf-8變長字節存儲字符，最小單位是一個字節。iso-8859-1正好相當于utf-8的一個單位。因此，將以utf-8編碼的字節流用iso-8859-1的方式讀取后字符亂碼但信息不丟失，只需要將字符還原成byte數組(str.getBytes("ISO-8859-1"))，重新以utf-8讀取(new String(byte[], "UTF-8"))即可。

1.2 為什么要編碼，我們認知的符號地如何存在的

1.2.1 java中的編碼

計算機中存儲信息的最小單元是一個字節即 8 個 bit，所以能表示的字符范圍是 0~255 個

人類要表示的符號太多，無法用一個字節來完全表示

要解決這個矛盾必須需要一個新的數據結構 char(16bit, 2byte)，從 char 到 byte 必須編碼

1.2.2 幾個重要的編碼

ASCII
（發音： /??ski/ ass-kee[1]，American Standard Code for Information Interchange，美國信息交換標準代碼）是基于拉丁字母的一套電腦編碼系統。它主要用于顯示現代英語，而其擴展版本EASCII則可以部分支持其他西歐語言，并等同于國際標準ISO/IEC 646。至今為止共定義了128個字符。

用一個字節的低 7 位表示，0~31 是控制字符如換行回車刪除等；32~126 是打印字符，可以通過鍵盤輸入并且能夠顯示出來。

ISO 8859-1
正式編號為ISO/IEC 8859-1:1998，又稱Latin-1或“西歐語言”，是國際標準化組織內ISO/IEC 8859的第一個8位字符集。它以ASCII為基礎，在空置的0xA0-0xFF的范圍內，加入96個字母及符號，藉以供使用附加符號的拉丁字母語言使用。

ISO-8859-1 仍然是單字節編碼，它總共能表示 256 個字符。

GB2312

它的全稱是《信息交換用漢字編碼字符集 基本集》，它是雙字節編碼，總的編碼范圍是 A1-F7，其中從 A1-A9 是符號區，總共包含 682 個符號，從 B0-F7 是漢字區，包含 6763 個漢字。

GBK

全稱叫《漢字內碼擴展規范》，是國家技術監督局為 windows95 所制定的新的漢字內碼規范，它的出現是為了擴展 GB2312，加入更多的漢字，它的編碼范圍是 8140~FEFE（去掉 XX7F）總共有 23940 個碼位，它能表示 21003 個漢字，它的編碼是和 GB2312 兼容的，也就是說用 GB2312 編碼的漢字可以用 GBK 來解碼，并且不會有亂碼。

UTF-16

具體定義了 Unicode 字符在計算機中存取方法。UTF-16不是定長兩字節，它是變長，有二或四字節，Unicode的碼點最大已經到了U+10FFFF. 轉化格式，這個是定長的表示方法，不論什么字符都可以用兩個字節表示，兩個字節是 16 個 bit，所以叫 UTF-16。UTF-16 表示字符非常方便，每兩個字節表示一個字符，這個在字符串操作時就大大簡化了操作，這也是?Java 以 UTF-16 作為內存的字符存儲格式的一個很重要的原因。

Unicode（中文：萬國碼、國際碼、統一碼、單一碼）是計算機科學領域里的一項業界標準。它對世界上大部分的文字系統進行了整理、編碼，使得電腦可以用更為簡單的方式來呈現和處理文字。
在表示一個Unicode的字符時，通常會用“U+”然后緊接著一組十六進制的數字來表示這一個字符。在基本多文種平面（英文：Basic Multilingual Plane，簡寫BMP。又稱為“零號平面”、plane 0）里的所有字符，要用四個數字（即兩個char,16bit ,例如U+4AE0，共支持六萬多個字符）；在零號平面以外的字符則需要使用五個或六個數字。舊版的Unicode標準使用相近的標記方法，但卻有些微小差異：在Unicode 3.0里使用“U-”然后緊接著八個數字，而“U+”則必須隨后緊接著四個數字。

UTF-8（8-bit Unicode Transformation Format）

UTF-16 統一采用兩個字節表示一個字符，雖然在表示上非常簡單方便，但是也有其缺點，有很大一部分字符用一個字節就可以表示的現在要兩個字節表示，存儲空間放大了一倍，在現在的網絡帶寬還非常有限的今天，這樣會增大網絡傳輸的流量，而且也沒必要。而 UTF-8 采用了一種變長技術，每個編碼區域有不同的字碼長度。不同類型的字符可以是由 1~6 個字節組成。

UTF-8 有以下編碼規則：

如果一個字節，最高位（第 8 位）為 0，表示這是一個 ASCII 字符（00 - 7F）。可見，所有 ASCII 編碼已經是 UTF-8 了。

如果一個字節，以 11 開頭，連續的 1 的個數暗示這個字符的字節數，例如：110xxxxx 代表它是雙字節 UTF-8 字符的首字節。

如果一個字節，以 10 開始，表示它不是首字節，需要向前查找才能得到當前字符的首字節

1.2.3 java中編碼的流程

1.2.3.1 什么時候需要編碼

將字符轉換為字節，以及將字節轉換字符的時候。

1.2.3.2 Java在什么時候編碼

通過I/O讀寫的時候，以及自定義轉碼的時候。I/O又區分為磁盤I/O和網絡I/O。

java中關于編碼有字節流和字符流。最初學java的時候肯定不去想為啥搞這東西。等用的時候才發現真是有用的。

字節流就是可以理解為byte數組, 一個byte就是一個字節，一個字節等于8位, 即8個0和1的二進制，也即兩位的十六進制（FF）。ISO的編碼就是基于單字節的，每個字節都可以映射為一個字符。

字符流當然就是面向字符的。這個是在字節流之上做了重組。字符流的最小單位是一個字符，可以理解為char數組。a和中都是一個字符，但如果用字節表示的話，a是一個字節，中是兩個。

下面介紹字節流和字符流的交互。

1.2.3.3 Java中的I/O流程

Reader是Java IO中讀取字符的父類，InputStream是讀取字節的父類，InputStreamReader是字節到字符的橋梁，具體通過StreamDecoder實現。其中StreamDecoder需要指定Charset編碼格式，如果用戶不指定，則采用本地環境默認字符集。

Writer是寫字符的父類，OutputStream是寫字節的父類，OutputStreamWriter是字符到字節的橋梁。

?
demo:

@Test public void test_write_read_encoding() throws IOException {String file = this.getClass().getClassLoader().getResource("").getPath()+File.separator+"test.txt";String charset = "UTF-8";// 寫字符換轉成字節流FileOutputStream outputStream = new FileOutputStream(file);OutputStreamWriter writer = new OutputStreamWriter(outputStream, charset);try {writer.write("這是要保存的中文字符");} finally {writer.close();}// 讀取字節轉換成字符FileInputStream inputStream = new FileInputStream(file);InputStreamReader reader = new InputStreamReader(inputStream, charset);StringBuilder sb = new StringBuilder();int charRead = reader.read();while (charRead != -1){sb.append((char) charRead);charRead = reader.read();}System.out.println(sb.toString()); }

文章最初的亂碼是因為write的時候是以utf-8編碼，而讀取的時候按照iso-8859-1解碼。這時候亂碼就是：è??ˉè|???-???-??-??|。

1.2.3.4 內存中的編碼

除了讀寫文件，還可以在內存中轉換編碼。

@Test public void testConvert() throws UnsupportedEncodingException {String s = "這是一段中文字符串";byte[] b = s.getBytes("UTF-8");String utf8 = new String(b,"UTF-8");String iso = new String(b,"iso-8859-1");Assert.assertEquals(s, utf8);Assert.assertEquals("è?\u0099?\u0098ˉ??\u0080??μ??\u00AD?\u0096\u0087?\u00AD\u0097??|??2", iso); } @Test public void testEncodingCharSet(){String aStr = "中文";Charset charset = Charset.forName("UTF-8");ByteBuffer byteBuffer = charset.encode(aStr);CharBuffer charBuffer = charset.decode(byteBuffer);Assert.assertEquals(aStr, charBuffer.toString()); }

1.2.3.5 java如何編碼

通過實例分析編碼過程。

@Test public void testEncoder(){String name = "I am 君山";char[] chars = name.toCharArray();for (char c : chars) {System.out.printf(c +"（"+(int)c+ "）=" + Integer.toHexString(c) +" | ");}System.out.println();try {byte[] iso8859 = name.getBytes("ISO-8859-1");System.out.println("iso:");toHex(iso8859);byte[] utf8 = name.getBytes("UTF-8");System.out.println("utf8:");toHex(utf8);byte[] gb2312 = name.getBytes("GB2312");System.out.println("gb2312:");toHex(gb2312);byte[] gbk = name.getBytes("GBK");System.out.println("gbk:");toHex(gbk);byte[] utf16 = name.getBytes("UTF-16");System.out.println("utf16:");toHex(utf16);} catch (UnsupportedEncodingException e) {e.printStackTrace();}}private void toHex(byte[] data) {for (byte b: data){byte[] bytes = {b};System.out.printf(Hex.encodeHexString(bytes) + " | ");}System.out.println(); }

注釋：

java中char轉換成int是因為char是16位的，int是32位，強轉不丟失。

char轉換成int的數值表示什么？明天去看看java編程思想，應該是該字符在Unicode字符集中的排序位置。

本實例中將char轉換的數值轉為16進制(Hex)來代表這個字符。比如君的int值為21531,轉換成16進制為541b。而君的Unicode也正好是\u541b。所以，++Java中char是通過存儲字符的16進制的數值來表示該字符的++。

java編碼需要用的類圖：

首先根據Charset.forName(charsetName)查找Charset，然后創建CharsetEncoder, 最后調用CharsetEncoder.encode進行編碼。其中UTF-8等編碼子類中內部類Encoder都繼承了CharsetEncoder。

String. getBytes(charsetName)時序圖:

下面分析字符串編碼的具體過程：
首先，控制臺輸出內容：

I（73）=49 | （32）=20 | a（97）=61 | m（109）=6d | （32）=20 | 君（21531）=541b | 山（23665）=5c71 | iso: 49 | 20 | 61 | 6d | 20 | 3f | 3f | utf8: 49 | 20 | 61 | 6d | 20 | e5 | 90 | 9b | e5 | b1 | b1 | gb2312: 49 | 20 | 61 | 6d | 20 | be | fd | c9 | bd | gbk: 49 | 20 | 61 | 6d | 20 | be | fd | c9 | bd | utf16: fe | ff | 00 | 49 | 00 | 20 | 00 | 61 | 00 | 6d | 00 | 20 | 54 | 1b | 5c | 71 |

對應關系如下圖,具體規則請參考原文，這里只share圖：

從上圖看出 7 個 char 字符經過 ISO-8859-1 編碼轉變成 7 個 byte 數組，ISO-8859-1 是單字節編碼，中文“君山”被轉化成值是 3f 的 byte。3f 也就是“？”字符，所以經常會出現中文變成“？”很可能就是錯誤的使用了 ISO-8859-1 這個編碼導致的。中文字符經過 ISO-8859-1 編碼會丟失信息，通常我們稱之為“黑洞”，它會把不認識的字符吸收掉。由于現在大部分基礎的 Java 框架或系統默認的字符集編碼都是 ISO-8859-1，所以很容易出現亂碼問題，后面將會分析不同的亂碼形式是怎么出現的。

UTF-8 對單字節范圍內字符仍然用一個字節表示，對漢字采用三個字節表示。UTF-8 編碼與 GBK 和 GB2312 不同，不用查碼表，所以在編碼效率上 UTF-8 的效率會更好，所以在存儲中文字符時 UTF-8 編碼比較理想

1.2.3.6 幾種編碼比較

對中文字符后面四種編碼格式都能處理，GB2312 與 GBK 編碼規則類似，但是 GBK 范圍更大，它能處理所有漢字字符，所以 GB2312 與 GBK 比較應該選擇 GBK。UTF-16 與 UTF-8 都是處理 Unicode 編碼，它們的編碼規則不太相同，相對來說 UTF-16 編碼效率最高，字符到字節相互轉換更簡單，進行字符串操作也更好。它適合在本地磁盤和內存之間使用，可以進行字符和字節之間快速切換，如 Java 的內存編碼就是采用 UTF-16 編碼。但是它不適合在網絡之間傳輸，因為網絡傳輸容易損壞字節流，一旦字節流損壞將很難恢復，想比較而言 UTF-8 更適合網絡傳輸，對 ASCII 字符采用單字節存儲，另外單個字符損壞也不會影響后面其它字符，在編碼效率上介于 GBK 和 UTF-16 之間，所以 UTF-8 在編碼效率上和編碼安全性上做了平衡，是理想的中文編碼方式。

1.2.4 繼續舉例分析字符在java中的亂碼情況

你是否考慮過，當我們在電腦中某個文本編輯器里輸入某個漢字時，它到底是怎么表示的？我們知道，計算機里所有的信息都是以 01 表示的，那么一個漢字，它到底是多少個 0 和 1 呢？我們能夠看到的漢字都是以字符形式出現的，例如在 Java 中“淘寶”兩個字符，它在計算機中的數值 10 進制是 28120 和 23453，16 進制是 6bd8 和 5d9d，也就是這兩個字符是由這兩個數字唯一表示的。Java 中一個 char 是 16 個 bit 相當于兩個字節，所以兩個漢字用 char 表示在內存中占用相當于四個字節的空間。

1.2.4.1 中文變成了看不懂的字符, 一個漢字變成兩個亂碼字符

例如，字符串“淘！我喜歡！”變成了“ì ? ￡ ?? ò ?2?? ￡ ?”編碼過程如下圖所示

1.2.4.2 一個漢字變成一個問號

1.2.4.3 一個漢字變成兩個問號

1.2.4.4 不應該這樣編碼，即使結果是正確的

//亂碼 String value = request.getParameter(name); //正常 String value = String(request.getParameter(name).getBytes(" ISO-8859-1"), "GBK");

這種情況是這樣的，ISO-8859-1 字符集的編碼范圍是 0000-00FF，正好和一個字節的編碼范圍相對應。這種特性保證了使用 ISO-8859-1 進行編碼和解碼可以保持編碼數值“不變”。雖然中文字符在經過網絡傳輸時，被錯誤地“拆”成了兩個歐洲字符，但由于輸出時也是用 ISO-8859-1，結果被“拆”開的中文字的兩半又被合并在一起，從而又剛好組成了一個正確的漢字。雖然最終能取得正確的漢字，但是還是不建議用這種不正常的方式取得參數值，因為這中間增加了一次額外的編碼與解碼，這種情況出現亂碼時因為 Tomcat 的配置文件中 useBodyEncodingForURI 配置項沒有設置為”true”，從而造成第一次解析式用 ISO-8859-1 來解析才造成亂碼的。

1.3 java web的一些編碼知識

1.3.1 URL的編碼和解碼

首先，估計絕大部分搞web的不一定說的出URL的組成部分是啥：

上圖中以 Tomcat 作為 Servlet Engine 為例，它們分別對應到下面這些配置文件中：
Port 對應在 Tomcat 的<Connector port="8080"/>?中配置，而 Context Path 在<Context path="/examples"/>中配置，Servlet Path 在 Web 應用的?web.xml中的

<servlet-mapping> <servlet-name>junshanExample</servlet-name> <url-pattern>/servlets/servlet/*</url-pattern> </servlet-mapping>

<url-pattern>?中配置，PathInfo 是我們請求的具體的 Servlet，QueryString 是要傳遞的參數，注意這里是在瀏覽器里直接輸入 URL 所以是通過 Get 方法請求的，如果是 POST 方法請求的話，QueryString 將通過表單方式提交到服務器端。

上圖中 PathInfo 和 QueryString 出現了中文，當我們在瀏覽器中直接輸入這個 URL 時，在瀏覽器端和服務端會如何編碼和解析這個 URL 呢？為了驗證瀏覽器是怎么編碼 URL 的我們選擇 FireFox 瀏覽器并通過 HTTPFox 插件觀察我們請求的 URL 的實際的內容，以下是 URL：HTTP://localhost:8080/examples/servlets/servlet/ 君山 ?author= 君山在中文 FireFox3.6.12 的測試結果
君山的編碼結果分別是：e5 90 9b e5 b1 b1，be fd c9 bd，查閱上一屆的編碼可知，PathInfo 是 UTF-8 編碼而 QueryString 是經過 GBK 編碼，至于為什么會有“%”？查閱 URL 的編碼規范 RFC3986 可知瀏覽器編碼 URL 是將非 ASCII 字符按照某種編碼格式編碼成 16 進制數字然后將每個 16 進制表示的字節前加上++“%”，++所以最終的 URL 就成了上圖的格式了。

默認情況下中文 IE 最終的編碼結果也是一樣的，不過 IE 瀏覽器可以修改 URL 的編碼格式在選項 -> 高級 -> 國際里面的發送 UTF-8 URL 選項可以取消。
從上面測試結果可知瀏覽器對 PathInfo 和 QueryString 的編碼是不一樣的，不同瀏覽器對 PathInfo 也可能不一樣，這就對服務器的解碼造成很大的困難，下面我們以 Tomcat 為例看一下，Tomcat 接受到這個 URL 是如何解碼的。
解析請求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，這個方法把傳過來的 URL 的 byte[] 設置到 org.apache.coyote.Request 的相應的屬性中。這里的 URL 仍然是 byte 格式，轉成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：

protected void convertURI(MessageBytes uri, Request request) throws Exception { ByteChunk bc = uri.getByteChunk(); int length = bc.getLength(); CharChunk cc = uri.getCharChunk(); cc.allocate(length, -1); String enc = connector.getURIEncoding(); if (enc != null) { B2CConverter conv = request.getURIConverter(); try { if (conv == null) { conv = new B2CConverter(enc); request.setURIConverter(conv); } } catch (IOException e) {...} if (conv != null) { try { conv.convert(bc, cc, cc.getBuffer().length - cc.getEnd()); uri.setChars(cc.getBuffer(), cc.getStart(), cc.getLength()); return; } catch (IOException e) {...} } } // Default encoding: fast conversion byte[] bbuf = bc.getBuffer(); char[] cbuf = cc.getBuffer(); int start = bc.getStart(); for (int i = 0; i < length; i++) { cbuf[i] = (char) (bbuf[i + start] & 0xff); } uri.setChars(cbuf, 0, length); }

從上面的代碼中可以知道對 URL 的 URI 部分進行解碼的字符集是在 connector 的<Connector URIEncoding=”UTF-8”/>中定義的，如果沒有定義，那么將以默認編碼 ISO-8859-1 解析。所以如果有中文 URL 時最好把 URIEncoding 設置成 UTF-8 編碼。

QueryString 又如何解析？

GET 方式 HTTP 請求的 QueryString 與 POST 方式 HTTP 請求的表單參數都是作為 Parameters 保存，都是通過 request.getParameter 獲取參數值。對它們的解碼是在 request.getParameter 方法第一次被調用時進行的。request.getParameter 方法被調用時將會調用 org.apache.catalina.connector.Request 的 parseParameters 方法。這個方法將會對 GET 和 POST 方式傳遞的參數進行解碼，但是它們的解碼字符集有可能不一樣。POST 表單的解碼將在后面介紹，QueryString 的解碼字符集是在哪定義的呢？它本身是通過 HTTP 的 Header 傳到服務端的，并且也在 URL 中，是否和 URI 的解碼字符集一樣呢？從前面瀏覽器對 PathInfo 和 QueryString 的編碼采取不同的編碼格式不同可以猜測到解碼字符集肯定也不會是一致的。的確是這樣?QueryString 的解碼字符集要么是 Header 中 ContentType 中定義的 Charset 要么就是默認的 ISO-8859-1，要使用 ContentType 中定義的編碼就要設置 connector 的?<Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/>?中的?useBodyEncodingForURI?設置為?true。這個配置項的名字有點讓人產生混淆，它并不是對整個 URI 都采用 BodyEncoding 進行解碼而僅僅是對 QueryString 使用 BodyEncoding?解碼，這一點還要特別注意。

從上面的 URL 編碼和解碼過程來看，比較復雜，而且編碼和解碼并不是我們在應用程序中能完全控制的，所以在我們的應用程序中應該盡量避免在 URL 中使用非 ASCII字符，不然很可能會碰到亂碼問題，當然在我們的服務器端最好設置?<Connector/>?中的 URIEncoding 和 useBodyEncodingForURI 兩個參數。

HTTP Header 的編解碼

當客戶端發起一個 HTTP 請求除了上面的 URL 外還可能會在 Header 中傳遞其它參數如 Cookie、redirectPath 等，這些用戶設置的值很可能也會存在編碼問題，Tomcat 對它們又是怎么解碼的呢？

對 Header 中的項進行解碼也是在調用 request.getHeader 是進行的，如果請求的 Header 項沒有解碼則調用 MessageBytes 的 toString 方法，這個方法將從 byte 到 char 的轉化使用的默認編碼也是?ISO-8859-1，而我們也不能設置 Header 的其它解碼格式，所以如果你設置 Header 中有非 ASCII 字符解碼肯定會有亂碼。

我們在添加 Header 時也是同樣的道理，不要在 Header 中傳遞非 ASCII 字符，如果一定要傳遞的話，我們可以先將這些字符用 org.apache.catalina.util.URLEncoder 編碼然后再添加到 Header 中，這樣在瀏覽器到服務器的傳遞過程中就不會丟失信息了，如果我們要訪問這些項時再按照相應的字符集解碼就好了。
POST 表單的編解碼在前面提到了 POST 表單提交的參數的解碼是在第一次調用 request.getParameter 發生的，POST 表單參數傳遞方式與 QueryString 不同，它是通過 HTTP 的 BODY 傳遞到服務端的。當我們在頁面上點擊 submit 按鈕時瀏覽器首先將根據?ContentType的?Charset?編碼格式對表單填的參數進行編碼然后提交到服務器端，在服務器端同樣也是用 ContentType 中字符集進行解碼。所以通過 POST 表單提交的參數一般不會出現問題，而且這個字符集編碼是我們自己設置的，可以通過 request.setCharacterEncoding(charset) 來設置。
另外針對 multipart/form-data 類型的參數，也就是上傳的文件編碼同樣也是使用 ContentType 定義的字符集編碼，值得注意的地方是上傳文件是用字節流的方式傳輸到服務器的本地臨時目錄，這個過程并沒有涉及到字符編碼，而真正編碼是在將文件內容添加到 parameters 中，如果用這個編碼不能編碼時將會用默認編碼 ISO-8859-1 來編碼。

HTTP BODY 的編解碼

當用戶請求的資源已經成功獲取后，這些內容將通過 Response 返回給客戶端瀏覽器，這個過程先要經過編碼再到瀏覽器進行解碼。這個過程的編解碼字符集可以通過 response.setCharacterEncoding 來設置，它將會覆蓋 request.getCharacterEncoding 的值，并且通過 Header 的 Content-Type 返回客戶端，瀏覽器接受到返回的 socket 流時將通過 Content-Type 的 charset 來解碼，如果返回的 HTTP Header 中 Content-Type 沒有設置 charset，那么瀏覽器將根據 Html 的<meta HTTP-equiv="Content-Type" content="text/html; charset=UTF-8" />?中的 charset 來解碼。如果也沒有定義的話，那么瀏覽器將使用默認的編碼來解碼。

其它需要編碼的地方

除了 URL 和參數編碼問題外，在服務端還有很多地方可能存在編碼，如可能需要讀取 xml、velocity 模版引擎、JSP 或者從數據庫讀取數據等。
xml 文件可以通過設置頭來制定編碼格式

<?xml version="1.0" encoding="UTF-8"?>

Velocity 模版設置編碼格式：

services.VelocityService.input.encoding=UTF-8

JSP 設置編碼格式：

<%@page contentType="text/html; charset=UTF-8"%>

訪問數據庫都是通過客戶端 JDBC 驅動來完成，用 JDBC 來存取數據要和數據的內置編碼保持一致，可以通過設置 JDBC URL 來制定如 MySQL：

url="jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=UTF-8"

Post@https://ryan-miao.github.io

參考

• https://www.ibm.com/developerworks/cn/java/j-lo-chinesecoding/index.html
• http://www.importnew.com/23963.html
• https://en.wikipedia.org/wiki/Unicode
• https://en.wikipedia.org/wiki/ISO/IEC_8859-1
• https://en.wikipedia.org/wiki/ASCII

from:?https://www.cnblogs.com/woshimrf/p/java-utf8-iso-charset.html

總結

以上是生活随笔為你收集整理的java中byte, iso-8859-1, UTF-8，乱码的根源的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。