5.jsp文件的编辑,上传,编译成servlet,网络传输发生了什么呢?
【编辑】jsp文件windows操作开发保存时默认是按照GBK编码字符串的,可以指定保存成UTF-8等其它格式。假设以UTF-8格式保存
编辑动作:GBK录入->unicode->UTF-8保存jsp文件
【上传】此时UTF-8码保存的jsp文件被转换成了UNIX系统下的iso-8859-1编码
上传动作:UTF-8保存jsp文件->unicode->iso-8859-1保存jsp文件==========(有待考究,也许没有文件编码的转换)
【编译】[tomcat举例]jvm读出iso-8859-1保存jsp文件进入内存,不作任何格式的修改,交给jasper告诉它我读出好了而且文件编码格式iso-8859-1,jasper会根据指定的pageEncoding属性来决定响应内容的编码格式,当没有设置此属性时,翻译之后的_jsp.java文件为response.setContentType("text/html"),内容的编码jasper采取了默HTTP协议的传输编码格式iso-8859-1,所以我们在GBK屏显环境下看到的是乱码,(因为iso-8859-1直接高位补0进入内存处理区,结果导致两个汉字会看到四个iso-8859-1字符,gbk包含latin-1字符点阵,而进行输出缓冲待传输时又进行了简单的去高位0操作,准备传输的是默认的latin-1编码字节流)那为什么客户端反而可以看到正常的中文字符呢?
编译动作:iso-8859-1保存jsp文件->unicode->网卡出缓冲码流(取决于pageEncoding)如果则没有默认latin1
如:"眼泪"D1BBC0E1默认iso-8859-1字节四个->unicode补高位0x00D10,x00BB,0x00C0,0x00E1我们看到的乱码 ->iso-8859-1字节缓冲输出又还原到D1BBC0E1
【网络传输】经过上面的示例之后,IE端得到iso-8859-1码因为没捕获到HTTP响应头"Content-Type"也没有捕获到<meta>属性,得到的D1BBC0E1字节流会按照IE自身支持的字符集(系统Locale)来加以显示,所以反而会两两字节重组后得到正确的"眼泪"二字
IE端解释动作:iso-8859-1网卡出缓冲编码字节流->unicode->屏显GBK码
==============================================
==============================================
总体发生动作:
编辑动作:GBK录入->unicode->UTF-8保存jsp文件================================1
上传动作:UTF-8保存jsp文件->unicode->iso-8859-1保存jsp文件==================2(上传换码否?)
编译动作:iso-8859-1保存jsp文件->unicode->iso-8859-1默认/pageEncoding属性===3
传输动作:iso-8859-1默认/pageEncoding属性->unicode->屏显GBK码===============4
观察后不难发现:
1,2环节不会有任何错误;3,4环节也不会有任何错误.
2环节后半部分、3环节上半部分是否发生文件上传转码并无影响,
因为->unicode->iso-8859-1码保存jsp文件==2
iso-8859-1码保存jsp文件->unicode==3 构成闭环,在这里不会发生任何错误。
关键点:在jasper处理2,3环节的地方,文件是以utf-8保存的,可如果没有pageEncoding='utf-8'的指定,就会导致输出码流不再是保存时的utf-8码流传给了IE端,IE端就会按照这个错误的pageEncoding属性指定的编码进行解码重组,而出现错误。
点评:
编译动作是个关键点:它在取出jsp源文件的时候,一定要和jsp源文件保存时的编码一致,否则就会出错误.
这一点由pageEncoding="文件保存码"="Eclipse开发工具workspace工作区编码"来保证的。
jsp静态汉字显示关键点就是:
1。pageEncoding=""只要设置,一定要和保存jsp文件时编码一致。
2。pageEncoding=""没有设置,注意<meta>属性,要和保存jsp文件时编码一致。
3。如果既没有pageEncoding="",也没有<meta>属性, 那么是默认的iso-8859-1对于Tomcat进行jasper编译的时候来说。而对于webSphere来说,一定会默认的在jsp或者servlet传输时默认指定content-type头部为iso-8859-1,所以这里的页面<meta>不在有任何的效果
以上分析了jsp页面中不读取动态字符串,静态字符串的展示原理,那么针对访问数据库数据文件的动态字符串的生成又是什么样子呢?这个可以参考上方的【数据库数据文件读取:】来理解。只是需要注意,从数据库取出的动态字符串必需和jsp文件保存时[既是pageEncoding=""]的编码一致,
如:pageEncoding="utf-8",那么new String(rs.getString().getBytes("iso-8859-1"),"utf-8");
jsp总结:
pageEncoding属性告之IE浏览器什么编码方式保存的静态字符串,IE好根据此来逆向解释往->unicode内存码转换
pageEncoding = "jsp文件保存码" = "Eclipse开发环境workspace工作区编码"
new String(rs.getString().getBytes("数据文件码"),"jsp文件保存码");
tomcat服务器在jasper解释开始解释jsp源文件的时候,是根据pageEncoding属性指定的码集进行网卡缓冲待输出字节流.如果未指定,则按照默认的iso-8859-1码流输出
【编辑】jsp文件windows操作开发保存时默认是按照GBK编码字符串的,可以指定保存成UTF-8等其它格式。假设以UTF-8格式保存
编辑动作:GBK录入->unicode->UTF-8保存jsp文件
【上传】此时UTF-8码保存的jsp文件被转换成了UNIX系统下的iso-8859-1编码
上传动作:UTF-8保存jsp文件->unicode->iso-8859-1保存jsp文件==========(有待考究,也许没有文件编码的转换)
【编译】[tomcat举例]jvm读出iso-8859-1保存jsp文件进入内存,不作任何格式的修改,交给jasper告诉它我读出好了而且文件编码格式iso-8859-1,jasper会根据指定的pageEncoding属性来决定响应内容的编码格式,当没有设置此属性时,翻译之后的_jsp.java文件为response.setContentType("text/html"),内容的编码jasper采取了默HTTP协议的传输编码格式iso-8859-1,所以我们在GBK屏显环境下看到的是乱码,(因为iso-8859-1直接高位补0进入内存处理区,结果导致两个汉字会看到四个iso-8859-1字符,gbk包含latin-1字符点阵,而进行输出缓冲待传输时又进行了简单的去高位0操作,准备传输的是默认的latin-1编码字节流)那为什么客户端反而可以看到正常的中文字符呢?
编译动作:iso-8859-1保存jsp文件->unicode->网卡出缓冲码流(取决于pageEncoding)如果则没有默认latin1
如:"眼泪"D1BBC0E1默认iso-8859-1字节四个->unicode补高位0x00D10,x00BB,0x00C0,0x00E1我们看到的乱码 ->iso-8859-1字节缓冲输出又还原到D1BBC0E1
【网络传输】经过上面的示例之后,IE端得到iso-8859-1码因为没捕获到HTTP响应头"Content-Type"也没有捕获到<meta>属性,得到的D1BBC0E1字节流会按照IE自身支持的字符集(系统Locale)来加以显示,所以反而会两两字节重组后得到正确的"眼泪"二字
IE端解释动作:iso-8859-1网卡出缓冲编码字节流->unicode->屏显GBK码
==============================================
==============================================
总体发生动作:
编辑动作:GBK录入->unicode->UTF-8保存jsp文件================================1
上传动作:UTF-8保存jsp文件->unicode->iso-8859-1保存jsp文件==================2(上传换码否?)
编译动作:iso-8859-1保存jsp文件->unicode->iso-8859-1默认/pageEncoding属性===3
传输动作:iso-8859-1默认/pageEncoding属性->unicode->屏显GBK码===============4
观察后不难发现:
1,2环节不会有任何错误;3,4环节也不会有任何错误.
2环节后半部分、3环节上半部分是否发生文件上传转码并无影响,
因为->unicode->iso-8859-1码保存jsp文件==2
iso-8859-1码保存jsp文件->unicode==3 构成闭环,在这里不会发生任何错误。
关键点:在jasper处理2,3环节的地方,文件是以utf-8保存的,可如果没有pageEncoding='utf-8'的指定,就会导致输出码流不再是保存时的utf-8码流传给了IE端,IE端就会按照这个错误的pageEncoding属性指定的编码进行解码重组,而出现错误。
点评:
编译动作是个关键点:它在取出jsp源文件的时候,一定要和jsp源文件保存时的编码一致,否则就会出错误.
这一点由pageEncoding="文件保存码"="Eclipse开发工具workspace工作区编码"来保证的。
jsp静态汉字显示关键点就是:
1。pageEncoding=""只要设置,一定要和保存jsp文件时编码一致。
2。pageEncoding=""没有设置,注意<meta>属性,要和保存jsp文件时编码一致。
3。如果既没有pageEncoding="",也没有<meta>属性, 那么是默认的iso-8859-1对于Tomcat进行jasper编译的时候来说。而对于webSphere来说,一定会默认的在jsp或者servlet传输时默认指定content-type头部为iso-8859-1,所以这里的页面<meta>不在有任何的效果
以上分析了jsp页面中不读取动态字符串,静态字符串的展示原理,那么针对访问数据库数据文件的动态字符串的生成又是什么样子呢?这个可以参考上方的【数据库数据文件读取:】来理解。只是需要注意,从数据库取出的动态字符串必需和jsp文件保存时[既是pageEncoding=""]的编码一致,
如:pageEncoding="utf-8",那么new String(rs.getString().getBytes("iso-8859-1"),"utf-8");
jsp总结:
pageEncoding属性告之IE浏览器什么编码方式保存的静态字符串,IE好根据此来逆向解释往->unicode内存码转换
pageEncoding = "jsp文件保存码" = "Eclipse开发环境workspace工作区编码"
new String(rs.getString().getBytes("数据文件码"),"jsp文件保存码");
tomcat服务器在jasper解释开始解释jsp源文件的时候,是根据pageEncoding属性指定的码集进行网卡缓冲待输出字节流.如果未指定,则按照默认的iso-8859-1码流输出