Dav*_*vid 1 encoding asp-classic
我试图理解ASP经典如何在内部处理字符串.我用谷歌搜索和调试,但我仍然不知道如何在ASP脚本中编码字符串.
请参见下图.
输入数据是否已转换,以便所有字符串变量具有相同的编码,无论哪个源?
大多数ASP页面都以utf-8的形式保存在磁盘上.但它们确实#include使用其他编码保存的asp文件.在前端页面的顶部,我将响应编码设置为unicode.
response.codepage = 65001 //unicode
reponse.charset = 'utf-8'
Run Code Online (Sandbox Code Playgroud)
首先,值得考虑的是UTF-8和Windows-1252(以及ISO-8859-1等)都基于US-ASCII.所有这些代码页中的前128个字符是相同的.使用完全相同的字节值,并且只占用一个字节.
在许多情况下,绝大多数内容都在US-ASCII范围内,因此很难说它们之间存在任何差异.通常整个文件只使用US-ASCII字符,因此尽管选择了编码,文件也是相同的(在文件开头可能保存了BOM).
基本脚本处理
首先,处理器将ASP文件与其所有包含组合在一起,并包含这些包含.这非常简单地将include标记替换为所引用的包含文件的内容.这完全是在字节级别完成的,不会尝试转换不同编码的文件.
接下来解析文件的组合版本.标记化,"编译"甚至成为一个紧密的interperter友好文件.在这一点上,文件中的大块内容(脚本代码块之外的东西)变成了一种特殊的形式Response.Write.它的特殊之处在于脚本执行时会到达这些特殊写入,处理器只是将文件中找到的字节直接逐字复制到输出流,同样不会尝试转换任何编码.
脚本代码和字符编码
ASP处理器不能很好地处理非ASCII的任何事情.您的代码中的所有代码,尤其是字符串文字都应该只使用ASCII格式.
一旦脚本执行,可能有点混乱所有字符串变量都使用Unicode编码存储.
当代码使用适当的Response.Write方法将响应写入内容时,这就是Response.CodePage生效的地方.它会将脚本提供给响应代码页的unicode字符串编码,然后再将其添加到输出流中.
Response.CharSet的作用是什么?
它将CharSet属性添加到Content-Typehttp标头.就是这样,它没有其他影响.如果设置这个字符集但发送不同的字符集,因为您的Response.CodePage与它不匹配,或者因为文件的字节内容不在该编码中,那么您可能会遇到问题.
输入编码
这里的事情变得非常混乱.当表单数据发布到服务器时,url编码标准中没有规定声明所使用的代码页.浏览器可以告诉使用什么编码,它们将默认为包含表单的html页面的charset,但是没有机制将该选择传达给服务器.
ASP认为发布的表单字段的代码页与其即将发送的响应的代码页相同.花一点时间来吸收那个......这意味着这个Response.CodePage值非常直观地反映了返回的字符串Request.Form.因此,尽早获取正确的代码页,进行一些表单处理,然后在发送响应之前设置代码页,这一点很重要,这可能会导致意外的结果.
经典的"网页看起来不错,但数据库中的数据已损坏"了
这种行为导致的一个常见问题是开发人员设置了CharSet ="UTF-8"但将代码页留在"Windows-1252"之类的地方.
最终发生的是用户输入以UTF-8编码发送到服务器的文本,但脚本代码将其读取为1252.此损坏的字符串存储在数据库中.后续网页会查看此数据,即从数据库中提取的损坏字符串.然后,此字符串由response.write使用1252编码发送,但目标页面将被告知其UTF-8.这具有扭转损坏的效果,并且一切对用户来说都很好.
但是,当其他组件(例如报表生成器)从数据库创建内容时,数据会显示为损坏,因为它是.
底线
你已经做了正确的事情,早期和一致地设置CharSet和CodePage.如果其他文件不能保存为UTF-8,如果其中包含非ascii内容,则会出现问题,否则您会没问题.
许多包括asps纯粹是没有内容的代码,因为该代码应该纯粹是ascii,它的编码并不重要.
| 归档时间: |
|
| 查看次数: |
3802 次 |
| 最近记录: |