多网站前端设计师在设计网站的时候,都会碰到网站在快速浏览器下显示正常,在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小时内与您取得联系。