多網站前端設計師在設計網站的時候,都會碰到網站在快速瀏覽器下顯示正常,在ie下可能就會出現錯位的情況!所以我們在設計網站之前一定要先了解IE兼容性問題。
關于CSS對IE的兼容問題一直是DIV+CSS的一個大問題,因為不通瀏覽器識別代碼產生的效果是不同的,所以造成了很多瀏覽器對相同的CSS,產生不同的效果,這樣就產生了網站的錯位,個人理解是這樣的。
網站設計
先來了解下瀏覽器的內核:
瀏覽器內核又可以分成兩部分:渲染引擎(layout engineer 或者 Rendering Engine)和 JS 引擎。它負責取得網頁的內容(HTML、XML、圖像等等)、整理訊息(例如加入 CSS 等),以及計算網頁的顯示方式,然后會輸出至顯示器或打印機。瀏覽器的內核的不同對于網頁的語法解釋會有不同,所以渲染的效果也不相同。所有網頁瀏覽器、電子郵件客戶端以及其它需要編輯、顯示網絡內容的應用程序都需要內核。JS 引擎則是解析 Javascript 語言,執行 javascript 語言來實現網頁的動態效果。
最開始渲染引擎和 JS 引擎并沒有區分的很明確,后來 JS 引擎越來越獨立,內核就傾向于只指渲染引擎。有一個網頁標準計劃小組制作了一個 ACID 來測試引擎的兼容性和性能。內核的種類很多,如加上沒什么人使用的非商業的免費內核,可能會有 10 多種,但是常見的瀏覽器內核可以分這四種:Trident、Gecko、Blink、Webkit。
各個瀏覽器內核不同,就可能造成不兼容的情況出現。
常見的兼容性問題:
1、不同瀏覽器的標簽默認的外補丁( margin )和內補丁(padding)不同
解決方案: css 里增加通配符 * { margin: 0; padding: 0; }
2、IE6雙邊距問題;在 IE6中設置了float , 同時又設置margin , 就會出現邊距問題
解決方案:設置display:inline;
3、當標簽的高度設置小于10px,在IE6、IE7中會超出自己設置的高度
解決方案:超出高度的標簽設置overflow:hidden,或者設置line-height的值小于你的設置高度
4、圖片默認有間距
解決方案:使用float 為img 布局
5、IE9一下瀏覽器不能使用opacity
解決方案:
opacity: 0.5;filter: alpha(opacity=50);filter: progid:DXImageTransform.Microsoft.Alpha(style=0, opacity=50);
6、邊距重疊問題;當相鄰兩個元素都設置了margin 邊距時,margin 將取最大值,舍棄最小值;
解決方案:為了不讓邊重疊,可以給子元素增加一個父級元素,并設置父級元素為overflow:hidden;
7、cursor:hand 顯示手型在safari 上不支持
解決方案:統一使用 cursor:pointer
8、兩個塊級元素,父元素設置了overflow:auto;子元素設置了position:relative ;且高度大于父元素,在IE6、IE7會被隱藏而不是溢出;
解決方案:父級元素設置position:relative
關于瀏覽器兼容性的這種錯位,因為瀏覽器的種類越來越多,從IE5,6,7,8,9,10這些都是比較常用的瀏覽器,但是正因為各種瀏覽器的出現,為了更好的兼容各個版本的瀏覽器,我們就需要學習如何來處理IE的兼容問題。從而網絡上出現了很多所謂的HACK ,其實也就是針對各個瀏覽器的特點,來對各種瀏覽器的不同嗜好,產生的不同效果,實現的一種兼容各個版本瀏覽器的效果。
這個地方我們我們不是來講各種可見的HACK效果,這些大家,可以在百度上來一下,就能找到我們所要的結果。
因為IE從6開始為了適應各個版本,就自身有了一個兼容性,所以我們可以指定給網頁一個兼容特性;
比如 網頁在IE7下無錯位,但在IE6 和 IE8下有錯位,那么我們就可以指定當用戶使用IE6和IE8的時候直接指定給IE6 和 IE8采用IE7的兼容模式來實現網頁的不錯位。
但是這樣一來,網頁的兼容特性只是實現了,IE6,IE7,IE8的一個兼容,為了同時兼容FF,我們這個時候就需要使用HACK來達到兼容FF的效果。
這樣我們使用IE自身的特性和HACK之間的特性就達到了網頁的兼容效果,我認為這樣實現兼容效果是最簡單最方便的。這樣我們其實就是對一種IE和FF之間的HACK在起作用,相對的寫了很少的代碼,也很實用和方便。
兼容性的問題越來越重要了,特別是IE8的出現讓當時大半的網頁都出現錯位等現象,而解決的辦法,我們來看一個網上的例子:
“css兼容IE8
微軟在IE8提供三種解析頁面的模式:
IE8 Standard Modes :默認的最標準的模式,嚴格按照W3C相關規定
IE7 Standards Modes :IE7現在用的解析網頁的模式,開起機關是在<head>中加入 <meta http-equiv="X-UA-Compatible" content="IE=7">
Quirks Modes :IE5用的解析網頁的模式,開起機關是刪除HTML頂部的DOCTYPE聲明
注意:不同模式間的網頁在IE8中可以互相 frame ,因此因不會模式下的DOM和CSS渲染不一樣,所以會引發很多問題,務必注意如果你的頁面對IE7兼容沒有問題,又不想大量修改現有代碼,同時又能在IE8中正常使用,微軟聲稱,開發商僅需要在目前兼容IE7的網站上添加一行代碼即可解決問題,此代碼如下:
<meta http-equiv="x-ua-compatible" content="ie=7" />”
加了以上這個代碼,就可以比較完美的解決一般的兼容性問題了。
1.當我們使用IE內核的瀏覽器下在PHPExcel報表時(谷歌、火狐瀏覽器正常, IE瀏覽器,360瀏覽器的兼容模式報錯),會出現如下錯誤:
2.解決辦法:
在下載文件時,對當前的瀏覽器進行判斷,
如果是IE內核的瀏覽器的話,進行文件名的轉碼,
若不是IE內核的瀏覽器,則不用。
關鍵代碼如下:
亂碼是我們在程序開發中經常碰到且讓人頭疼的一件事,尤其是我們在做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小時內與您取得聯系。