對(duì)于ASP編碼亂碼問(wèn)題的深入研究與最終解決方案
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
ASP亂碼確實(shí)棘手,這個(gè)說(shuō)明比較權(quán)威。有待研究。哪的資料都不如官方資料權(quán)威。今天總算從MSDN中擇出了ASP編碼問(wèn)題的解決方案。 哪的資料都不如官方資料權(quán)威。今天總算從MSDN中擇出了ASP編碼問(wèn)題的解決方案。
這句話(huà)解釋清楚了@CODEPAGE,Response.CodePage,Session.CodePage 分別的作用是什么。 @CODEPAGE作用于所有靜態(tài)的字符串,比如某文件中的 const blogname="我的家" Response.CodePage,Session.CodePage作用于所有動(dòng)態(tài)輸出的字符串,比如<%=blogname%> 這句話(huà)很關(guān)鍵的是說(shuō)明了Response.CodePage的作用范圍是a single response,而SXNA中聲明的Session.CodePage的作用范圍是all responses in a session。
這句話(huà)我乍一看,把意思理解成了這樣:在sessions are enabled的時(shí)候,如果Response.CodePage沒(méi)有聲明,則Response.CodePage會(huì)被Session.CodePage賦值。如果sessions are not enabled的時(shí)候, 如果@CodePage已聲明,則Response.CodePage會(huì)被@CodePage賦值,等等............. 這句話(huà)解釋了為什么從SXNA中出來(lái)以后進(jìn)入一些別的頁(yè)面比如oblog,z-blog等等容易出現(xiàn)亂碼,因?yàn)槠渌绦驔](méi)有聲明Response.CodePage而恰巧SXNA聲明了Session.CodePage,因此一進(jìn)入SXNA,Session.CodePage立即被賦值(版本不同,有的版本賦了936有的版本賦了65001),而后進(jìn)入其他程序的時(shí)候Response.CodePage馬上被Session.CodePage賦值,如果這時(shí)Response.CodePage與頁(yè)面本身編碼不一樣的話(huà),頁(yè)面就會(huì)出現(xiàn)亂碼。所以進(jìn)入z-blog出現(xiàn)亂碼的時(shí)候我查了當(dāng)時(shí)的Session.CodePage和Response.CodePage都是936,而進(jìn)入oblog出現(xiàn)亂碼的時(shí)候Session.CodePage和Response.CodePage都是65001.就是說(shuō)要想保證葉面不出現(xiàn)亂碼,應(yīng)該聲明Response.CodePage,否則他就會(huì)按照Session.CodePage來(lái)解釋網(wǎng)頁(yè)(而不是按照@codepage解釋網(wǎng)頁(yè)). 如果僅僅按照上面的解釋的話(huà),我實(shí)際上是很糊涂的,因?yàn)槲覀兌际怯玫闹形牟傧到y(tǒng),當(dāng)每一次進(jìn)入瀏覽器的時(shí)候你可以嘗試輸出Session.CodePage,能看到他都是936!為什么進(jìn)入Z-blog的時(shí)候他不把默認(rèn)的Session.CodePage的936賦給Response.CodePage呢?反而把@CodePage給了Response.CodePage?什么情況下Session.CodePage才賦值給Response.CodePage呢?原文的sessions are enabled應(yīng)該如何理解呢? 也許上面的話(huà)應(yīng)該這樣理解:
因?yàn)閆blog和Oblog都聲明了@CodePage,所以,用戶(hù)剛剛啟動(dòng)完機(jī)器然后進(jìn)入瀏覽器瀏覽Zblog和Oblog的時(shí)候Response.CodePage會(huì)被@CodePage賦值,于是葉面顯示正常。
其中比較有用的一句話(huà)是說(shuō)如果Response.CodePage和@CODEPAGE不一樣的話(huà)會(huì)產(chǎn)生亂碼。也就是說(shuō)當(dāng)Z-blog的@CODEPAGE=65001而Z-blog的Response.CodePage被Session.CodePage賦為936的時(shí)候就會(huì)出現(xiàn)亂碼,oblog反之亦然。 不知道上面說(shuō)了這么多解釋清楚沒(méi)有-_-||
當(dāng)用戶(hù)進(jìn)入瀏覽器的時(shí)候Session.CodePage默認(rèn)為936,這個(gè)時(shí)候的默認(rèn)936不是程序聲明的,因此不會(huì)賦給Response.CodePage,當(dāng)進(jìn)入SXNA的時(shí)候,Session.CodePage被上面那段代碼一折騰就變成了程序聲明的Session.CodePage=936,因此再進(jìn)入Zblog的時(shí)候就把936給了Response.CodePage。 至此,全部原因已經(jīng)分析清楚了。 因此說(shuō),保證asp葉面一定不會(huì)出現(xiàn)亂碼的代碼應(yīng)該是這樣的:(假定是UTF-8的葉子)
進(jìn)一步說(shuō)明為什么要加Response.Charset,因?yàn)镸SDN說(shuō)應(yīng)該加...呵呵
另外,文件的編碼格式應(yīng)該與@CODEPAGE一樣:
這就是為什么zblog,pjblog等一些程序要吧文件存成UTF8編碼格式的原因. 綜上,如果所有的程序都聲明了Response.CodePage就不會(huì)被Session.CodePage干擾而出現(xiàn)亂碼了。所以Session.CodePage還是不能輕易用的!
參考文章: 該文章在 2015/8/23 23:02:22 編輯過(guò) |
關(guān)鍵字查詢(xún)
相關(guān)文章
正在查詢(xún)... |