473,888 Members | 2,194 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

trying to send 8 bit chars under IIS6

Greets,

Part of the content of one of our web pages uses wingdings and Chr(239)
through Chr(242) (which are little arrow outlines, though that's not really
important.)

It worked just fine in Windows 2000 Server, but now under Server 2003 it
seems that characters above 127 get converted somehow, and our code no
longer produces the desired effect.

Does anyone know how to make it send our content without modification, or
how to encode it in a way that it makes it out to the browser with the
intended character value (as opposed to some thoroughly useless conversion
to a 7 bit value)?

tia,
Mark
Jul 22 '05 #1
4 2469
IIS6 itself does not do any such conversion, so I am not certain the issue
has to do with 8bit characters.

Page Frameworks like ASP or the web browser (based on
Content-Encoding/Language hints from the response) can do such conversion,
but those are parameters you need to control if you wish your page to be
consistently interpreted.

Can you describe what codepage your ASP page is configured to be interpreted
as, and whether you send any additional response headers that may affect how
the browser interprets your response?

Because in order for the little arrow outlines to display properly, these
two things have to happen:
1. The response entity body must contain characters whose character code is
239-242
2. The browser must choose a code page (based on response headers) which
selects a font which maps little arrow outlines to character codes 239-242

You must ensure those two things happen; neither IIS nor the browser can
make it automagically happen.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...
Greets,

Part of the content of one of our web pages uses wingdings and Chr(239)
through Chr(242) (which are little arrow outlines, though that's not really
important.)

It worked just fine in Windows 2000 Server, but now under Server 2003 it
seems that characters above 127 get converted somehow, and our code no
longer produces the desired effect.

Does anyone know how to make it send our content without modification, or
how to encode it in a way that it makes it out to the browser with the
intended character value (as opposed to some thoroughly useless conversion
to a 7 bit value)?

tia,
Mark


Jul 22 '05 #2

"David Wang [Msft]" <so*****@online .microsoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
IIS6 itself does not do any such conversion, so I am not certain the issue
has to do with 8bit characters.

Page Frameworks like ASP or the web browser (based on
Content-Encoding/Language hints from the response) can do such conversion,
but those are parameters you need to control if you wish your page to be
consistently interpreted.
Thanks for your reply.

It is definitely a server side issue, I looked at the response using
Ethereal, before it reaches the browser. I also tried sending characters
with values over 128 using the default font, as a reality check. Characters
that use the 8th bit are being transformed somewhere in between the VBS/ASP
script -- which does a Response.Write( Chr(239)) -- and the requesting
client's TCP socket.

Can you describe what codepage your ASP page is configured to be
interpreted
as, and whether you send any additional response headers that may affect
how
the browser interprets your response?
It was implicit, we also tried explicitly setting it to ANSI and to UTF-8.
(Yes I saved the script source files as UTF-8 after adding the @CodePage
directive.) We also added the DTD that VS7 generates for new HTML
documents. The content type is ASP's default, HTML Document according to
IE. Ethereal confirms it, the type is text/html.

Because in order for the little arrow outlines to display properly, these
two things have to happen:
1. The response entity body must contain characters whose character code
is
239-242
Therein lies a big part of the problem, because those character values are
not being sent as written to the response context.

2. The browser must choose a code page (based on response headers) which
selects a font which maps little arrow outlines to character codes 239-242
We set the font via CSS for just the elements that display these characters.
We surely do not want the entire page to use wingdings (it would be
extremely difficult to read that way.) Wingdings is installed by default on
all Windows machines since Windows 95 iirc.

Further, as I stated, the value of the characters in question has been
altered by the time the content makes it to the browser. The page *is*
displaying wingdings characters where we expect it to, they just are not the
correct wingdings characters... because their value has been altered or
transformed in some strange way.

You must ensure those two things happen; neither IIS nor the browser can
make it automagically happen.
I surely didn't expect that from either of them, and as I stated, this same
code worked perfectly in Win2K/IIS5. It's not something we set out on a
lark to do, and wistfully hoped it would miraculously happen, we have
worling code already deployed on next-to-latest major release of IIS. So I
suspect it has something to do with IIS6 MIME type handling "enhancemen ts"

In practice I've all but decided to just say the hell with it, and replace
the wingding characters with images. Yes it will add a few KB to the size
of the content, and a number of extra requests will be generated by the page
as it renders (even cached images generate an HTTP request per instance of
the image, delivering them inline as individual characters incurs much less
client request overhead) but nobody with broadband will ever know the
difference.

Even so I'd love to get to the bottom of this, because I saw a loosely
related issue (involving XML) in another NG. If it alters any XML, it won't
be so easy to work around.
-Mark

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...
Greets,

Part of the content of one of our web pages uses wingdings and Chr(239)
through Chr(242) (which are little arrow outlines, though that's not
really
important.)

It worked just fine in Windows 2000 Server, but now under Server 2003 it
seems that characters above 127 get converted somehow, and our code no
longer produces the desired effect.

Does anyone know how to make it send our content without modification, or
how to encode it in a way that it makes it out to the browser with the
intended character value (as opposed to some thoroughly useless conversion
to a 7 bit value)?

tia,
Mark

Jul 22 '05 #3
Create the simplest page that you can which reproduces the problem and post
the entire code here.

--
--Mark Schupp
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:nbbBe.3059 4$8o.26125@fed1 read03...

"David Wang [Msft]" <so*****@online .microsoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
IIS6 itself does not do any such conversion, so I am not certain the
issue
has to do with 8bit characters.

Page Frameworks like ASP or the web browser (based on
Content-Encoding/Language hints from the response) can do such
conversion,
but those are parameters you need to control if you wish your page to be
consistently interpreted.


Thanks for your reply.

It is definitely a server side issue, I looked at the response using
Ethereal, before it reaches the browser. I also tried sending characters
with values over 128 using the default font, as a reality check.
Characters that use the 8th bit are being transformed somewhere in between
the VBS/ASP script -- which does a Response.Write( Chr(239)) -- and the
requesting client's TCP socket.

Can you describe what codepage your ASP page is configured to be
interpreted
as, and whether you send any additional response headers that may affect
how
the browser interprets your response?


It was implicit, we also tried explicitly setting it to ANSI and to UTF-8.
(Yes I saved the script source files as UTF-8 after adding the @CodePage
directive.) We also added the DTD that VS7 generates for new HTML
documents. The content type is ASP's default, HTML Document according to
IE. Ethereal confirms it, the type is text/html.

Because in order for the little arrow outlines to display properly, these
two things have to happen:
1. The response entity body must contain characters whose character code
is
239-242


Therein lies a big part of the problem, because those character values are
not being sent as written to the response context.

2. The browser must choose a code page (based on response headers) which
selects a font which maps little arrow outlines to character codes
239-242


We set the font via CSS for just the elements that display these
characters. We surely do not want the entire page to use wingdings (it
would be extremely difficult to read that way.) Wingdings is installed by
default on all Windows machines since Windows 95 iirc.

Further, as I stated, the value of the characters in question has been
altered by the time the content makes it to the browser. The page *is*
displaying wingdings characters where we expect it to, they just are not
the correct wingdings characters... because their value has been altered
or transformed in some strange way.

You must ensure those two things happen; neither IIS nor the browser can
make it automagically happen.


I surely didn't expect that from either of them, and as I stated, this
same code worked perfectly in Win2K/IIS5. It's not something we set out
on a lark to do, and wistfully hoped it would miraculously happen, we have
worling code already deployed on next-to-latest major release of IIS. So
I suspect it has something to do with IIS6 MIME type handling
"enhancemen ts"

In practice I've all but decided to just say the hell with it, and replace
the wingding characters with images. Yes it will add a few KB to the size
of the content, and a number of extra requests will be generated by the
page as it renders (even cached images generate an HTTP request per
instance of the image, delivering them inline as individual characters
incurs much less client request overhead) but nobody with broadband will
ever know the difference.

Even so I'd love to get to the bottom of this, because I saw a loosely
related issue (involving XML) in another NG. If it alters any XML, it
won't be so easy to work around.
-Mark

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...
Greets,

Part of the content of one of our web pages uses wingdings and Chr(239)
through Chr(242) (which are little arrow outlines, though that's not
really
important.)

It worked just fine in Windows 2000 Server, but now under Server 2003 it
seems that characters above 127 get converted somehow, and our code no
longer produces the desired effect.

Does anyone know how to make it send our content without modification, or
how to encode it in a way that it makes it out to the browser with the
intended character value (as opposed to some thoroughly useless
conversion
to a 7 bit value)?

tia,
Mark


Jul 22 '05 #4

"Mark Schupp" <no******@email .net> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..
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.CodePa ge or Session.CodePag e 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.CodePa ge,
--------------

The above is an excerpt from this page:

http://msdn.microsoft.com/library/de...269aeadcb0.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=VBScri pt %>
<%
Response.CharSe t = "utf-8"
Response.CodePa ge = 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
--
--Mark Schupp
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:nbbBe.3059 4$8o.26125@fed1 read03...

"David Wang [Msft]" <so*****@online .microsoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..
IIS6 itself does not do any such conversion, so I am not certain the
issue
has to do with 8bit characters.

Page Frameworks like ASP or the web browser (based on
Content-Encoding/Language hints from the response) can do such
conversion,
but those are parameters you need to control if you wish your page to be
consistently interpreted.


Thanks for your reply.

It is definitely a server side issue, I looked at the response using
Ethereal, before it reaches the browser. I also tried sending characters
with values over 128 using the default font, as a reality check.
Characters that use the 8th bit are being transformed somewhere in
between the VBS/ASP script -- which does a Response.Write( Chr(239)) --
and the requesting client's TCP socket.

Can you describe what codepage your ASP page is configured to be
interpreted
as, and whether you send any additional response headers that may affect
how
the browser interprets your response?


It was implicit, we also tried explicitly setting it to ANSI and to
UTF-8. (Yes I saved the script source files as UTF-8 after adding the
@CodePage directive.) We also added the DTD that VS7 generates for new
HTML documents. The content type is ASP's default, HTML Document
according to IE. Ethereal confirms it, the type is text/html.

Because in order for the little arrow outlines to display properly,
these
two things have to happen:
1. The response entity body must contain characters whose character code
is
239-242


Therein lies a big part of the problem, because those character values
are not being sent as written to the response context.

2. The browser must choose a code page (based on response headers) which
selects a font which maps little arrow outlines to character codes
239-242


We set the font via CSS for just the elements that display these
characters. We surely do not want the entire page to use wingdings (it
would be extremely difficult to read that way.) Wingdings is installed
by default on all Windows machines since Windows 95 iirc.

Further, as I stated, the value of the characters in question has been
altered by the time the content makes it to the browser. The page *is*
displaying wingdings characters where we expect it to, they just are not
the correct wingdings characters... because their value has been altered
or transformed in some strange way.

You must ensure those two things happen; neither IIS nor the browser can
make it automagically happen.


I surely didn't expect that from either of them, and as I stated, this
same code worked perfectly in Win2K/IIS5. It's not something we set out
on a lark to do, and wistfully hoped it would miraculously happen, we
have worling code already deployed on next-to-latest major release of
IIS. So I suspect it has something to do with IIS6 MIME type handling
"enhancemen ts"

In practice I've all but decided to just say the hell with it, and
replace the wingding characters with images. Yes it will add a few KB to
the size of the content, and a number of extra requests will be generated
by the page as it renders (even cached images generate an HTTP request
per instance of the image, delivering them inline as individual
characters incurs much less client request overhead) but nobody with
broadband will ever know the difference.

Even so I'd love to get to the bottom of this, because I saw a loosely
related issue (involving XML) in another NG. If it alters any XML, it
won't be so easy to work around.
-Mark

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//
"Mark J. McGinty" <mm******@spamf romyou.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...
Greets,

Part of the content of one of our web pages uses wingdings and Chr(239)
through Chr(242) (which are little arrow outlines, though that's not
really
important.)

It worked just fine in Windows 2000 Server, but now under Server 2003 it
seems that characters above 127 get converted somehow, and our code no
longer produces the desired effect.

Does anyone know how to make it send our content without modification,
or
how to encode it in a way that it makes it out to the browser with the
intended character value (as opposed to some thoroughly useless
conversion
to a 7 bit value)?

tia,
Mark



Jul 22 '05 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
3107
by: Ron Weldy | last post by:
I have a test server runinng 2003/IIS 6 with a mixture of asp and asp.net files. On my workstation I have a share set up to the folder where the web files reside. I am just doing quick and dirty asp editing (like I used to be able to do with 2K/IIS5) where I use VS.NET, open an asp file, make changes, save and refresh my browser. Problem is that I get an Access is Denied error when I try to save the file and then the file gets wiped on...
2
2127
by: David Hearn | last post by:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. SQLExpress database file auto-creation error: The connection string specifies a local SQL Server Express instance using a...
10
3963
by: Sven Huijbrechts | last post by:
Hello, I need to send a couple of "NUL"s -> HEX value "00" on a networkstream.. This is the code we currently use to send string: Dim sendBytes As () = Encoding.ASCII.GetBytes(inputtext.ToString) networkStream.Write(sendBytes, 0, sendBytes.Length) Since there is no char value for hex 00 (NUL) it's not possible to use a
2
5297
by: Alpha | last post by:
Hi, I'm able to make connection to a server using socket connection. However, when I send a command string the server just ignores it. All command string needs to start with "0xF9" at Byte 0. During the run-time debug, I see it to be "u" with a "~" on top of it. Is that OxF9? Can someone tell me what I'm doing wrong? Thanks, Alpha private void Connect(String server, String message) { //Socket Connect
17
2246
by: Chad | last post by:
I'm want static char *output; to hold the modified string "tel chad" However, when I debug it, static char *output holds the ascii value of the strng, and not the string itself. Here is what I have. I know gets(), strcat strcpy() shouldn't be used.
1
2667
by: Luwk | last post by:
I have an application that communicates with the Company's Active Directory to get the OU of the users. This said application is an ASP.Net web site and has the Windows Authentication enabled. . Now, here's the anomaly: If the application is run on a Server using IIS 5.1, the application works like a charm and the communcation with the Active Directory occurs without any problem.
10
2131
by: Andrew Wan | last post by:
I have been having a nightmare with ASP/ASP.NET & IIS6. We use Msxml2.DOMDocument.4.0 object to create a XML object in ASP. The Msxml2.DOMDocument.4.0 is from the Windows Platform SDK Feb 2003 (the last version compatible with VC6). Then we use TranslateXSLT(XMLDocument.transformNode) passing in a xsl file path. Our pages work perfectly fine under IIS5 & IIS6 onsite. However strange things happening at our clients IIS6: -...
2
2771
by: Andrew Wan | last post by:
Okay, this is really weird. We have two Windows 2003 Server SP1 PCs. One hosts IIS6 website, and the other hosts our DCOM service program. Our website is ASP/XSL. An ASP page uses Msxml2.DOMDocument.4.0 to transform a XML top node via XSL stylesheet outputting to HTML. We have set up the website on-site successfully with no problems. However, when we upgraded our client some how IIS6 still references a really old XSL file. No matter how...
1
1407
by: neisan | last post by:
Hi there, I'm trying for a while to obtain the XML content of a file without spaces. I have a XML file with the following content: <script> <command> <createDocument> <name>MyDocument</name>
0
9799
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11173
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10772
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10434
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7988
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5810
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4635
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4239
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3245
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.