Classic ASP and UTF-8

Question

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?

Answer 1

I had the strange characters issue, tried all the suggested encoding settings suggested and nothing was working, although the above did get the data into the sql database correctly it wouldn't then display correctly (still an encoding/decoding issue).

My resolution was to remove the "CharSet=utf8;" from the database connection string.

So instead of my connection string of:

sConnection = "DRIVER={MySQL ODBC 5.1 Driver};SERVER=localhost;CharSet=utf8;Port:3306;DATABASE=dbname;UID=uid;PASSWORD=*****;OPTION=3" 

I used:

sConnection = "DRIVER={MySQL ODBC 5.1 Driver};SERVER=localhost;Port:3306;DATABASE=dbname;UID=uid;PASSWORD=*****;OPTION=3" 

Things are now displaying correctly!

Answer 2

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.