Obviously this is too simple, so it's hard to find an explicit answer in the online documentation:
- To select the output encoding you want to use in the ASP script, you have to set the response.codepage property or change the per-page default with the @Codepage directive. To use utf-8 encoding, set the response.codepage to 65001.
- The HTTP Content-type header should match the encoding you're using. Set the response.charset (second part of the content-type header) to "utf-8".
- If you use META tag in your HTML to set the content-type or encoding attribute in the xml pseudo-instruction, these have to match the HTTP encoding as well. You don't have to specify utf-8 encoding in XML, as it's the default XML encoding.
- Instead of setting response.codepage in every response, you can set session.codepage at the start of the session.
- Important: If you use HTML forms, you have to set the @Codepage in all ASP scripts processing the forms or change the AspCodepage metabase property, otherwise the script might misinterpret the input data.
This post is part of You've asked for it series of articles.
Posts
2 comments:
Hi Ivan,
Thanks for the popst above, it has been helpfull!
We have recently moved all our classic ASP pages to UTF-8 using the method described above.
I have noticed that this has had some effects (e.g. empty tags no longer self-close) on any MSXML XSL parsing that we do. I was wondering if you knew of any documents that outlined the effects of this UTF-8 on the MSXML parser so we can know what to expect.
Regards
Todd
Hi Todd!
Never had any problems with UTF-8. Is it possible that you've upgraded MSXML at the same time? Various versions of MSXML handle HTML output differently (as I've learnt the hard way ... everything was working nicely on a local server, but not when I've uploaded the ASP pages into the production environment).
If you send me a short example of what's going wrong (use the "Send a message to Ivan" link from my bio page), I'll try to help you.
Post a Comment