Mark Schupp said:
Create the simplest page that you can which reproduces the problem and
post the entire code here.
Strangely, when I tried to fo that, the problem disappeared. Worse, I
noticed that the same characters were being displayed correctly in another
frame of the same frameset!
I did some more research and found an explanation (though that it's
implemented like this is a mind-blower to me):
--------------
Literal strings in a script are still encoded by using @CodePage (if
present) or the AspCodePage metabase property value (if set), or the system
ANSI code page. If you set Response.CodePage or Session.CodePage explicitly,
do so before sending nonliteral strings to the client. If you use literal
and nonliteral strings in the same page, make sure the code page of
@CodePage matches the code page of Response.CodePage,
--------------
The above is an excerpt from this page:
http://msdn.microsoft.com/library/d...html/268f1db1-9a36-4591-956b-d7269aeadcb0.asp
We haven't been setting any codepage. I had thought we tried to set it as a
possible solution using @codepage and saving the source as utf-8, but I see
I didn't even come close, there are included files, and I did not imagine
I'd *need* to set it elsewhere to make it effective.
So to cause my pages to be output as utf-8 I need all of this:
<% @CodePage = 65001 Language=VBScript %>
<%
Response.CharSet = "utf-8"
Response.CodePage = 65001
%>
[...]
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
AND the source file must be saved as utf-8, and any included files should be
saved as utf-8 also? That's straight nuts!
Also the doc contradicts itself, in one spot it says there can be only one
codepage (which seems reasonable) but in another it says, "...or the literal
strings are encoded differently from the nonliteral strings and display
incorrectly." If there was only one codepage, all output would be encoded
accordingly.
Unreal! And this is supposed to be an improvement over IIS5? It did not
seem to suffer from the same potential for ambiguity.
What's more, ANSI is perfectly capable of displaying 8 bit characters. So
it seems to me that IIS6 goes to way too much trouble trying to ascertain
the codepage, when all we really wanted was ANSI by default. In the end,
without having any explicit codepage set, it makes wrong assumptions and
incorrectly encodes some characters.
Another irony, I tried saving the source as unicode, and it bitterly
complained... so all strings in VBS are unicode, the script engine that does
this is unable to read source files saved as unicode? So how could unicode
be native, does it read ANSI source files and convert to unicode?
Riiight.... Add one to the reasons I gotta call BS on the "Unicode Native to
VBS" myth.
So in the end I said to hell with it, and substituted some chars in webdings
that look close enough, and fit in 7 bits. It works.
Thanks for the reply,
Mark