Hi Satish
I finally got this puzzle solved. I was approaching it from the wrong
angle.
My original problem began when sending data by ENCTYPE="multipart/form-data"
I would get an error when the user put in ascii values greater than 127.
What was actually happening was that some of the form fields were being sent
twice.
see example below:-
-----------------------------7d16e892c Content-Disposition: form-data;
name="thumbnail"; filename="" Content-Type:
application/octet-stream -----------------------------7d16e892c
Content-Disposition: form-data; name="thumbnail"; filename="" Content-Type:
application/octet-stream -----------------------------7d16e892c
Content-Disposition: form-data; name="Description"
â?¬ -----------------------------7d16e892c Content-Disposition: form-data;
name="PropertyID" 96 -----------------------------7d16e892c
Content-Disposition: form-data; name="Submit" Update
Property -----------------------------7d16e892c--
The reason that I was approaching it from the wrong direction was that I
went back to sending the form in the traditional way i.e. not using
ENCTYPE="multipart/form-data". But as you pointed out, I should have been
using Request.BinaryRead.
Anyway before I go on to explain why the fields were being sent twice in my
original problem, I want to explain where these funny ‘ characters were
coming from.
They are actually HTML Character Entity Equivalents.
for example
‘
is the HTML Character Entity Equivalent for left single quotation mark. A
table of these characters can be found in Appendix J, p.800 of Alex Homer's
Book, Proffessional ASP 3.0 Web Techniques.
I'm surprised that nobody had recognised this before.
Anyway back to my original problem
After many hours of painstaking troubleshooting I discovered that the
problem wasn't in the form, it wasn't in the function for breaking apart the
binary data, nor was it in page which called this function. The problem was
with a meta tag in the head of the page that the form was in. Here it is:-
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
When I took out this meta tag, ascii values greater then 127 worked
perfectly. So now it obviously defaults to some other character set. I
don't know which one.
Perhaps somebody could share this piece of information with us.
Well all I can say now is Thanks be to God...............................!
:-)
Kind Regards
Oliver Dempsey
----- Original Message -----
From: sathish r <sathish297@y...>
To: ASP Web HowTo <asp_web_howto@p...>
Sent: Wednesday, October 31, 2001 11:13 AM
Subject: [asp_web_howto] RE: trapping ascii values greater then 127
> Please Use
> 1. Response.BinaryRead()
>
>
>
> ----- Original Message -----
> From: <odempsey@b...>
> To: "ASP Web HowTo" <asp_web_howto@p...>
> Sent: Thursday, October 25, 2001 5:04 PM
> Subject: [asp_web_howto] RE: trapping ascii values greater then 127
>
>
> > Nobody has posted a solution to this problem. Is this because nobody
> knows
> > how to solve it or that it just can't be solved. C'mon guys there must
be
> > somebody that knows how to solve this problem :-)
> >
> > In case you haven't read the previious posts, I was trying to trap ascii
> > values which weren't being sent as you might expect from a form. To
> > demonstrate this I set up a form at the following loction to show how it
> was
> > interpreting the values:-
> > www.barrowvale.com/test.asp
> > For example if you put a capital T into the text box and press submit it
> > will tell you that the ascii value is 84, However if you put in the
symbol
> > for the Euro (ascii = 128) you will get the result below. Please read
> below
> > to see how far I had got in trouble shooting this problem.
> >
> >
> > Kind Regards
> > Oliver Dempsey
>
$subst('Email.Unsub')
>
>
>
View Cart
