前全球的4大瀏覽器分別是谷歌的 Chrome,微軟的Edge,蘋果的Safari 和火狐的Firefox,這4大瀏覽器占了90%以上的份額。
而這4大瀏覽器背后,其實也是4大內核,分別是Trident(也稱IE內核)、webkit、Blink、Gecko,無一例外,全是美國的。
從網頁瀏覽行為來看,瀏覽器內核是解析網頁的工具,通過“ 排版引擎 ” 和 “JavaScript 引擎 ”,將文本標記,解析成精美的網頁,內核才是核心。
至于瀏覽器,形象的來講,只是給內核套一個殼,加上一些其它功能,瀏覽器的核心還是內核。
但也因為內核有多個,大家的標準多多少少還是稍有不同的,所以大家在解析同一網頁時,使用不同的瀏覽器時,可能會發現一些問題,那就是大家的排版可能不一致,甚至有些網頁,在某些瀏覽器中,會顯示“亂碼”一樣。
不過,好消息是近日谷歌、微軟、蘋果和 Mozilla 基金會聯手了,這可是首次了,4家宣布共同努力提高瀏覽器的互操作性。
其實說得簡單一點,那就是4大巨頭表態,要確保 Chrome、Edge、Safari 和 Firefox 這4大瀏覽器,給所有用戶,提供同樣可靠和一致的 Web 體驗,同一網頁,用這4種瀏覽器瀏覽,都會是同樣效果,不會再有“亂碼”等等情況出現。
事實上,在2021年的時候,谷歌和微軟就聯手了,雙方合作推出了 Compat 2021 標準,讓雙方的瀏覽器提供一致的WEB體驗。
而這個Compat 2021 標準涉及的東西比較多,差不多囊括了網頁上的所有顯示元素,比如Dialog Element(對話框元素)、滾動條控件、表單控件等等。
當時蘋果、火狐沒有加入進來,而今終于蘋果、火狐也加入進來了,4大瀏覽器齊聚首了。
另外值得一提的是,目前國內的瀏覽器,均使用的是前面所講的4大內核,而這4大廠商更多的也是從內核入手,所以國產瀏覽器樣,也一樣可以享受到這一波技術紅利。
明:本欄目所使用的素材都是凱哥學堂VIP學員所寫,學員有權匿名,對文章有最終解釋權;凱哥學堂旨在促進VIP學員互相學習的基礎上公開筆記。
關于亂碼問題的解決
會有亂碼現象,其實就是因為字符集編碼不一致的問題,就好像中國人和外國人談話一樣,互相不懂對方在說啥。字符集編碼也是如此,本來就是一段GBK編碼的文字,卻要用utf-8的編碼格式去解碼,就當然是雞同鴨講會出現亂碼啦,這個時候就得使用GBK編碼的格式去解碼才不會出問題。如果互相都是使用的GBK編碼后,那就像中國人和中國人都說普通話一樣,就能聽懂對方在說什么,這樣才不會出現亂碼。
在web開發中,請求或響應數據時出現亂碼,往往就是客戶端和服務端的編碼不一致的問題所導致的。
不過在介紹如何解決亂碼的問題前,我們先看看HttpServletRequest中關于獲得表單數據的一些方法,雖然在上一篇也介紹了使用方式,不過關于亂碼和拿到具體的值這方面沒有涉及到:
獲得和設置表單數據方法(如果是上傳文件的話則無法獲取文件中的數據):
既然和表單有關,那么就得先寫一個簡單的html表單代碼,我們可以在Eclipse中創建一個html文件:
可能使用Eclipse編寫HTML的代碼不太方便,我們也可以使用一個專門編寫html代碼的工具來編寫Eclipse里已經創建了的html文件,我這里使用HBuilder作為示例:
1.復制Eclipse中的html文件所在目錄的路徑:
2.在HBuilder中點擊文件,然后選擇打開目錄把復制的文件路徑粘貼進去,并為這個工程起一個新的名稱:
工程目錄如下:
如圖,可以看到index.html已經在這個工程下了,我們可以在HBuilder中編輯這個html文件,編輯的內容會同步到Eclipse,因為它倆訪問的都是同一個目錄同一個html文件。
3.我在HBuilder編輯的代碼如下:
4.再看看Eclipse發生了什么:
可以看到代碼是同步的。
瀏覽器運行結果:
以下使用實際代碼演示常用的幾個獲得表單數據的方法,代碼示例:
在Eclipse中執行html文件,Eclipse有一個內置的瀏覽器:
如果要在其他的瀏覽器則需要使用這個URL地址:
http://localhost:8080/TestResponse/index.html
不要直接在HBuilder中運行這個html文件,因為它的URL是指向HBuilder的工程路徑的。
控制臺打印結果:
如圖,可以看到我們將所有的值都獲得到手了。
獲得表單數據的時候要注意一個問題:當你需要獲得一個屬性的值時,如果得到的結果為null,那么就是因為表單數據中并沒有這個屬性的存在。例如我獲得一個不存在的屬性:
控制臺打印結果:
可以看到結果為null,所以當你獲得表單數據進行某些操作時,出現了空指針異常的話,很有可能就是因為代碼上寫錯了獲得了一個不存在的屬性。
如果表單數據中的某個屬性值沒有寫,那么獲得的將是一個空字符串,而非null,例如:
控制臺打印結果:
如圖,并沒有打印null,而是打印空白,這個空白就是一個空字符串:’’
會出現亂碼的情況,以及解決方法:
現在我們修改一下代碼把表單提交的方法改為post,再運行一次,看看控制臺的打印結果,html代碼示例:
Java代碼示例:
提交的表單:
控制臺的打印結果:
可以看到控制臺中的打印結果出現了不能識別的字符,解決方法很簡單,使用setCharacterEncoding(String)方法,設置表單提交的數據的編碼格式即可:
運行結果:
注意:除了在Java代碼中需要設置編碼格式,在html文件中也要設置好編碼格式,如果html中不設置編碼格式的話,即便在Java代碼中使用了setCharacterEncoding(String)方法設置了也沒有用,所以這是雙向的,例如我把html文件中設置編碼格式的標簽給刪掉:
可以看到在網頁上顯示都是亂碼(這是因為Eclipse內置的瀏覽器原因,一般市面上的瀏覽器提前預設了字符編碼,所以不會出現這種情況)
控制臺打印結果:
果然出現了不能識別的字符,所以html文件也是需要設置好編碼的,不然的話就會出現亂碼的情況。
下面來看看瀏覽器的地址欄中為什么能夠顯示中文:
這其實是因為瀏覽器轉碼了,可以把這個URL復制到記事本中:
可以看到是一堆的編碼,并沒有顯示中文,所以實際上瀏覽器就是把這個編碼給轉換成了中文而已。
只要不屬于128個字符內的字符,在地址欄中都會轉換成這種格式的編碼,這些編碼格式是采用的16進制的編碼格式,以上面這文本示例編碼對應的中文:
如圖,每一個16進制編碼都是以%開頭,這是utf-8編碼的中文,所以一個中文字對應3個16進制編碼。
如果是GBK編碼格式的中文則是一個中文字對應2個16進制編碼,但是GBK編碼格式轉換成的16進制編碼不能被瀏覽器轉換,會仍然顯示著16進制編碼:
中文字對應的16進制編碼:
如圖,GBK編碼格式的中文字和utf-8編碼的中文字不一樣,是2個16進制編碼對應一個中文字。
關于客戶端請求數據方面的亂碼情況就介紹這么多,另外響應數據中出現亂碼的情況和解決方法在介紹HttpServletResponse方法部分進行說明。
思維導圖:
HttpServletResponse中的方法
HttpServletResponse接口類型的對象是封裝服務端響應數據的,所以這個對象中的方法都是與響應數據相關。以下羅列一些常用的方法:
下面使用實際的例子,演示以上方法的使用方式:
編輯響應頭一類的方法:
代碼示例:
在服務端設置響應數據的編碼格式是很有必要的,這么做同樣的也是為了避免出現亂碼的問題。例如以下這個示例,我不設置響應數據的編碼格式,并輸出一段中文,看看會發生什么,代碼示例:
運行結果:
如圖,可以看到,沒有設置響應數據的編碼格式的話,輸出中文就會無法被識別。
這種問題設置一下響應數據的編碼格式就好了,但是服務端設置的編碼格式,要與瀏覽器端的編碼格式對應上,如果不對應的話仍然會是亂碼,代碼示例:
運行結果:
添加新的響應頭數據:
代碼示例:
打開TCP/IP Monitor窗口,可以看到以上代碼添加進響應頭的數據:
獲得設置的響應頭信息:
代碼示例:
控制臺打印結果:
修改響應頭信息:
代碼示例:
TCP/IP Monitor窗口:
總結:
解決客戶端表單提交數據亂碼的問題,需要使用setCharacterEncoding(String)方法,設置好與客戶端對應的編碼格式。
解決服務端響應數據亂碼的問題,則使用setCharacterEncoding(String)方法,設置好對應的編碼格式。
HttpServletRequest是封裝請求數據的對象,所以它的方法都是與客戶端請求信息相關的。
HttpServletResponse是封裝響應數據的對象,所以它的方法都是與服務端響應信息相關的。
亂碼是我們在程序開發中經常碰到且讓人頭疼的一件事,尤其是我們在做javaweb開發,如果我們沒有清楚亂碼產生的原理,碰到亂碼問題了就容易摸不著頭腦,無從下手。
亂碼主要出現在兩部分,如下:
第一,瀏覽器通過表單提交到后臺,如果表單內容有中文,那么后臺收到的數據可能會出現亂碼。
第二,后端服務器需要返回給瀏覽器數據,如果數據中帶有中文,那么瀏覽器上可能會顯示亂碼。
接下來我們逐一分析亂碼產生的原因,以及如何解決亂碼問題。
這里又分為get請求和post請求。
get請求
get請求,請求參數中帶有中文,后臺接收會出現亂碼,原因是tomcat默認編碼是“ISO-8859-1”,所以tomcat會使用“ISO-8859-1”對中文進行編碼,該編碼不支持中文,所以后臺接收到就亂碼了。解決方式有兩種。
post請求
post請求,出現亂碼的原因同get請求,解決方式比較簡單,如下:
request.setCharacterEncoding("utf-8");
設置請求參數的編碼格式為“utf-8”,這樣就不會有問題了。
后端返回數據給瀏覽器,一般也有兩種形式,一種是response.getOutputStream(),一種是response.getWriter()。
兩者區別以及使用規則
因此,調用requonse.getWriter()方法時可實現文本字符串數據輸出,調用response.getOutputStream()方法可現實字節流數據的輸出。所以,如果要輸出圖片等二進制數據時,需要使用response.getOutputStream。
注意,getOutputStream()和getWriter()不能同時使用,否則會拋出”getWriter() has already been called for this response“異常。
區別講完了,下面我們主要還是通過實踐分析下亂碼產生的原理。
response.getOutputStream().print()
返回英文數據就不說了,沒什么問題,看下返回中文是什么效果;
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.getOutputStream().print(str);
}
結果如下:
分析:
OutPutStream是輸出二進制數據的,所以需要對字符串改成二進制輸出,Tomcat使用的是"ISO8859-1"編碼對其進行轉換,而中文對”ISO859-1“不支持,所以就拋異常了。
response.getOutputStream.write()
同樣的,我們再來看下輸出中文會怎么樣。
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.getOutputStream().write(str.getBytes());
}
頁面輸出結果如下:
涓浗鍔犳補錛屾姹夊姞娌?
分析:
在java中,String的getBytes()方法是得到一個操作系統默認的編碼格式的字節數組,我電腦的系統是macos,默認編碼格式是utf-8,返回給瀏覽器是utf-8編碼格式的字節數組,但是瀏覽器默認是"gbk"編碼解析,所以就亂碼了。
既然這樣,那我們換成“gb2312”編碼(gb2312編碼是gbk編碼的一種)試試呢?
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.getOutputStream().write(str.getBytes());
}
頁面輸出:
中國加油,武漢加油
原理我們弄清楚了,但是在項目開發中,我們需要編碼統一,最常用的就是中文字符編碼"UTF-8",可是按照我們的理解,如果我們直接response.getOutputStream().write(str.getBytes("utf-8"));肯定會亂碼,我們需要用某種方式,告訴瀏覽器,你要用我指定的“utf-8”編碼接受我返回的中文。response.setContentType("text/html;charset=UTF-8")這樣就完事了,看看效果吧。
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.setContentType("text/html;charset=utf-8");
response.getOutputStream().write(str.getBytes("utf-8"));
}
頁面輸出:
中國加油,武漢加油
response.getWriter()
前面已經總結過了,response.getWriter()跟response.getOutputStream()不一樣,outputStream是輸出二進制的,writer是輸出字符串的。response.getWriter()輸出也有兩種方法,一種是print(),一種是write(),其實兩者在處理亂碼這一塊沒有什么區別,就不分開講述了。
示例:
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.getWriter().print(str);
}
頁面輸出:
?????????
分析:
同樣的,Tomcat默認的編碼是ISO 8859-1,當我們輸出中文數據的時候,Tomcat會依據ISO 8859-1碼表給我們的數據編碼,中文不支持這個碼表呀,所以出現了亂碼。
這個時候response.setContentType("text/html;charset=UTF-8")又派上用場了。
@RequestMapping("/helloworld.do")
public void helloworld(HttpServletRequest request, HttpServletResponse response) throws IOException {
String str = "中國加油,武漢加油";
response.setContentType("text/html;charset=utf-8");
response.getWriter().print(str);
}
頁面輸出:
中國加油,武漢加油
在這里,response.setContentType("text/html;charset=UTF-8")做了兩件事,response.setCharacterEncoding("UTF-8");和response.setHeader("Content-Type", "text/html;charset=UTF-8");具體就是,第一,輸出中文”中國加油,武漢加油“的時候,對中文進行”utf-8“編碼;第二,告訴瀏覽器,你也要用"utf-8"來顯示我返回的中文。
對于springMVC項目,如何解決亂碼問題呢?項目中一般會在web.xml中配置編碼過濾器。配置如下:
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
這樣能保證請求的參數按照指定的編碼格式進行編碼,簡單翻看下過濾器源碼如下:
@Override
protected void doFilterInternal(
HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
if (this.encoding != null && (this.forceEncoding || request.getCharacterEncoding() == null)) {
request.setCharacterEncoding(this.encoding);
if (this.forceEncoding) {
response.setCharacterEncoding(this.encoding);
}
}
filterChain.doFilter(request, response);
}
代碼中有兩處重要的地方值得注意,分別是request.setCharacterEncoding(this.encoding);和response.setCharacterEncoding(this.encoding);前者表示我們對請求過來的參數使用指定的"utf-8"進行編碼,后者便是,返回給瀏覽器時,后端返回字符的編碼是“utf-8”。
好了,經過以上分析是不是亂碼也沒有那么可怕了。只要明白其中的緣由,解決起來就是一行代碼或者幾行配置的事兒了,如果大家覺得有幫助,不妨點贊支持一下?
*請認真填寫需求信息,我們會在24小時內與您取得聯系。