经典ASP和UTF-8 [英] Classic ASP and UTF-8

问题描述

我正在更改我的应用程序以使用utf-8页面。
因此，每个ASP页面都有此代码

  Response.CodePage = 65001 
 Response.CharSet =utf -8
  

和HTML

 < meta charset =UTF-8/> 
< meta http-equiv =Content-Typecontent =text / html; charset = UTF-8/> 
 

我在编码UTF-8时保存了Visual Studio 2013中的所有文档（没有签名）65001。

当我在HTML中写入特殊字符时，这样工作正常：

 < p>Atenção< / p> 
  

但是当我写入VBScript（经典的ASP）它不工作，特殊字符是凌乱。我可以通过保存编码UTF-8（带有签名）65001的文档（.asp）来修复它们。

：

• 我必须在每个网页上使用此编码（带签名）吗？



• 您需要设置<$ c
  $ c> @Codepage 指令为每个 .asp 文件。我们使用的是一个通用的 #include 文件，该文件在每个页面上首先包含，并且前面有以下行：

   <％@ Codepage = 65001％> 
  <％Option explicit％> 
  <％Response.Codeepage = 65001％> 
    

  详细了解Codepage指令此处（备注部分）。链接的页面是关于 Session.Codepage ，如果你想使用内置的会话，它也可能会让你感兴趣。

  
  
  

  使用BOM保存所有文件不是IIS的要求，我们保存所有没有BOM的文件正常工作。

  
  
  

  根据我的经验，在使用ASP多年以后：我们有时会遇到一些问题，源文件的BOMs潜入生成的输出，这导致问题AJAX / JSON响应。补救办法是在输出之前使用 Response.Clear 。

  
  

  I'm changing my application to work with utf-8 pages. So every ASP page has this code

  Response.CodePage = 65001 
  Response.CharSet = "utf-8"
  

  And HTML

  <meta charset="UTF-8" />
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
  

  I saved all documents in Visual Studio 2013 with encode UTF-8 (without signature) 65001.

  This is working fine when I write special characters in HTML like this:

  <p>Atenção</p>
  

  But when I write in VBScript (classic ASP) it's not working and the special characters are messy. I can fix them by saving the document (.asp) with encode UTF-8 (with signature) 65001.

  So, my questions are:

  • Do I have to use this encoding (with signature) on every page?
  • What kind of problems could I have with it?

  解决方案

  You need to set the @Codepage directive for each .asp file. We are using a generic #include file that is included first on every page and has the following lines up front:

  <%@Codepage = 65001 %>
  <% Option explicit %>
  <% Response.Codepage = 65001 %>
  

  See more info about the Codepage directive here (Remarks section). The linked page is about Session.Codepage which might also get interesting for you if you want to use the built-in Session.

  Saving all files with BOM is not a requirement for IIS, we have all files saved without BOM working properly.

  A note from my experience, after working with ASP for many a year: we had sometimes problems with BOMs of source files sneaking into the generated output, which lead to problems in AJAX/JSON responses. The remedy was to use a Response.Clear before writing output.

  这篇关于经典ASP和UTF-8的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！