Re: creating xml document
- From: "Dave" <david@xxxxxxxxxxxx>
- Date: Mon, 13 Nov 2006 18:34:52 GMT
That's some really useful information, thanks for taking the time to explain
things in such detail, it's always a steep learning curve!
Thanks
Dave
"Anthony Jones" <Ant@xxxxxxxxxxxxxxxx> wrote in message
news:u3jSDh0BHHA.4292@xxxxxxxxxxxxxxxxxxxxxxx
"Dave" <david@xxxxxxxxxxxx> wrote in message
news:NdZ5h.17148$Zy3.8387@xxxxxxxxxxxxxxxxxxxxxxx
It works!!!! Thank you very much Anthony, you have got me out of a BIGhole
there!
Could you please just explain what you have done differently, and why
server.urlencode was the wrong way to go, and why response.write does not
work in this case? That would be much appreciated as I'm still learning
in
this area!
What does DelegateList.Save Response actually do? Is this similar to
response.write?
Thanks
Dave
The purpose of URLEncode is to ensure characters that are invalid or out
of
the allowable range of a URL are encoded correctly. This is designed to
be
used when building URLs since the encoding it uses is only understood by
something expecting to receive a URL. Hence you should only user
URLEncode
when building strings for src and href attributes.
In your code there are three different character sets to consider.
Firstly the unicode character set (also known on Windows machines as
codepage 65000). This is the native character set used by VBScript and
COM
objects. It is a common set of characters that is able represent pretty
much every character or every language on the planet and then some. It
can
do this because each character occupies 2 bytes instead of just 1.
Hence this method:- adoRS(i).value would be returning a unicode string.
The second character set to consider is UTF-8 (also known on Windows
machines as codepage 65001). This is the default character set used by
XML.
An XML parser (such as the one built into flash) when loading a file or
receiving a download stream should assume it is receiving UTF-8 unless the
<?xml declare says otherwise. UTF-8 is in fact the same set as unicode
but
it use a variable length encoding. The first 128 characters are identical
to ASCII and occupy 1 byte most english strings will look identical
whether
encoded as ASCII or UTF-8. The larger the Unicode value a character needs
the longer the UTF-8 encoding becomes. For example the British £ requires
2
bytes in UTF-8.
The third character set to consider in this case is Windows-1252 (also
known
on Windows machines as codepage 1252). This is the standard system
codepage
that a machine installed with english settings will be using. It is a
single byte character set where the first 128 characters are identical to
ASCII (hence for most english string again indistinguishable from UTF-8 or
ASCII). The upper 128 characters contain other 'Latin' characters in
common
use in the West. The system code page is the code page used by ASP.
When you call Response.Write you asking ASP to convert the Unicode string
you are providing to the current codepage encoding then insert the result
of
the conversion in to the output buffer. The current codepage is
controlled
by the Session.Codepage and defaults to the system code page. If
therefore
you were to examine the value of Session.Codepage you will find it is set
to
1252. IIS6 has an additional Response.Codepage that is effective during
the
current response only (whereas session.codepage when set affects the whole
session).
Armed with that information what is happening here:-
Response.Write DelegateList.XML
??
DelegateList.XML is a string property on a COM object. It will return a
Unicode string which is the only type of string VBScript understands.
Now Response.Write will encode the provided string to codepage 1252
because
that is the current codepage for the session (or response). If the
unicode
string contains a character not available in the Windows-1252 set one of
two
things can happen. Either it will error or it will send ? instead.
Even if all characters are in the 1252 set there is still a problem. For
example the British £ is character 163 in the 1252 set and that's how the
Response.Write would encode it. But the XML parser is expecting UTF-8
encoding which (since £ isn't in the ASCII set) is expecting a different 2
byte encoding. Hence the stream is corrupt.
Now take a look at this:-
DelegateList.Save Response
Normally one pass Filename as a string to the Save method of an XML DOM.
This would cause the XML DOM to save it's contents to a file. It will do
this using the encoding specified on the <?xml declare or if that isn't
present use the default UTF-8 encoding.
The Save method can also take a COM object that implements the IStream
interface. The IStream interface allows content to be serialised from one
media to another. The Response object in ASP implements the IStream
interface so it is a valid object to pass to the Save method. The DOM
will
do the same thing it does when saving to a file but instead of writing
bytes
to disk it will write bytes to the provided IStream. The Response object
will simply copy the bytes received to the output buffer, it will not
attempt any code page conversion.
So using Save causes UTF-8 encoding to be sent to the Flash client which
is
what it was expecting.
These lines:-
Response.ContentType = "text/xml"
Response.CharSet = "UTF-8"
are just belts and braces in this case but it is good practice when
generating output from ASP to specify exactly what it is you are sending
to
the client.
HTH,
Anthony
.
- References:
- creating xml document
- From: Dave
- Re: creating xml document
- From: Anthony Jones
- Re: creating xml document
- From: Dave
- Re: creating xml document
- From: Anthony Jones
- Re: creating xml document
- From: Dave
- Re: creating xml document
- From: Anthony Jones
- creating xml document
- Prev by Date: Re: challenge! - vbscript version of the javascript in the address bar trick
- Next by Date: Re: How to verify a local account exists.
- Previous by thread: Re: creating xml document
- Next by thread: Strange behavior re: class property
- Index(es):
Relevant Pages
|