Display information with quotes in from

[gerben]

LS,

I want to make a content management system. Therefore I have to be
able to change the content of my mysql database. I'm writing the
content to text boxes in forms, to be able to edit them.

This works fine as long as there are no ' in the text. The information
in the database is correct, but when it is shown in the form,
everything after the quote is not shown.

I can write new text with quotes, and this will be stored in the
database correctly.

I am aware of addslashes/htmlentities in php, and have experimented
with it, but to no avail.

Any help apreciated

Gerben

[Raymond Loman]

ge*******@hotma il.com (gerben) wrote in message news:<79******* *************** ***@posting.goo gle.com>...

LS,

I want to make a content management system. Therefore I have to be
able to change the content of my mysql database. I'm writing the
content to text boxes in forms, to be able to edit them.

This works fine as long as there are no ' in the text. The information
in the database is correct, but when it is shown in the form,
everything after the quote is not shown.

I can write new text with quotes, and this will be stored in the
database correctly.

I am aware of addslashes/htmlentities in php, and have experimented
with it, but to no avail.

Any help apreciated

Gerben

Gergen,
(dutch?)
I have had the same problem using ASP on an ACCESS-db.

Before committing the content to the database, I used
the asp-replace command to replace every ' in the content
with &#39 and then commit to the db.
It worked.

--
Raymond

[Daniel R. Tobias]

ra*****@raymond loman.nl (Raymond Loman) wrote in message news:<b0******* *************** ***@posting.goo gle.com>...

Before committing the content to the database, I used
the asp-replace command to replace every ' in the content
with &#39 and then commit to the db.
It worked.

I wouldn't think that HTML-encoding would be the proper thing to do
with plain-text data being sent to a database. (And, if you were
HTML-encoding, then you should remember the trailing semicolon, so
it's ' .) In SQL, I believe the proper way to send a literal
quote/apostrophe is to double it, as ''.

--
Dan

[Andy Dingley]

ge*******@hotma il.com (gerben) wrote in message news:<79******* *************** ***@posting.goo gle.com>...

This works fine as long as there are no ' in the text. The information
in the database is correct, but when it is shown in the form,
everything after the quote is not shown.

When I code (particularly server-side), all my database column names
and my script variables use a naming convention that indicates their
content type as either "string" strFooBar (not HTML encoded), "HTML"
htmlFooBar (always encoded) or "URL" urlFooBar (safe for use in URLs).
Sometimes I even use extensions to this, for xml encoding (also
HTML-safe, but I know it doesn't depend on a HTML DTD for entities),
tainted user-entry data or even tainted user-entered HTML-subset (i.e.
weblog entries).

It's very easy to convert between these character-string-subtypes. The
hard part is _knowing_ what you have, and always treating each one
appropriately. I _know_ that my system will never load a string from a
database then write it straight out to a HTML stream without noticing
that it contains
<img src="goatse.cx" >

Equally I don't have content appearing for my users as &amp;lt;
because it has taken too many trips through the entity encoder.

[Alan J. Flavell]

On Thu, 20 May 2004, Andy Dingley wrote:

and my script variables use a naming convention that indicates their
content type as either "string" strFooBar (not HTML encoded), "HTML"
htmlFooBar (always encoded) or "URL" urlFooBar (safe for use in URLs).

Seems like good advice to me.

The immediate problem which occurs to me are those browsers which,
contrary to anything that's even hinted at in the specifications, take
a user input character in a form text input, and apply a completely
unsolicited HTML-ification into &#number; or even &entity; format
in the course of submitting the form.

So from the server side you can't tell unambiguously quite *what* the
user typed-in.

[Raymond Loman]

da*@tobias.name (Daniel R. Tobias) wrote in message news:<aa******* *************** ****@posting.go ogle.com>...

ra*****@raymond loman.nl (Raymond Loman) wrote in message news:<b0******* *************** ***@posting.goo gle.com>...

Before committing the content to the database, I used
the asp-replace command to replace every ' in the content
with &#39 and then commit to the db.
It worked.
I wouldn't think that HTML-encoding would be the proper thing to do
with plain-text data being sent to a database. (And, if you were
HTML-encoding, then you should remember the trailing semicolon, so
it's ' .)

yes, you are correct. Should be '
In SQL, I believe the proper way to send a literal
quote/apostrophe is to double it, as ''.

yes, in SQL you are correct. But HTML does not swallow double
' in the code. Better, it swallows it, but it doesn't spit out the result
you would like.

--
Raymond

[Owen Jacobson]

On Thu, 20 May 2004 11:22:41 +0100, Alan J. Flavell wrote:

On Thu, 20 May 2004, Andy Dingley wrote:

and my script variables use a naming convention that indicates their
content type as either "string" strFooBar (not HTML encoded), "HTML"
htmlFooBar (always encoded) or "URL" urlFooBar (safe for use in URLs).

Seems like good advice to me.

The immediate problem which occurs to me are those browsers which,
contrary to anything that's even hinted at in the specifications, take
a user input character in a form text input, and apply a completely
unsolicited HTML-ification into &#number; or even &entity; format
in the course of submitting the form.

Citations, please? I've never heard of this behaviour; it doesn't, or
wouldn't, surprise me in the least to find out it happens, but it seems
even more egrariously bogus than most things browsers do.

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

[Gertjan Klein]

On Mon, 24 May 2004 23:50:44 GMT, Owen Jacobson wrote:

On Thu, 20 May 2004 11:22:41 +0100, Alan J. Flavell wrote:

The immediate problem which occurs to me are those browsers which,
contrary to anything that's even hinted at in the specifications, take
a user input character in a form text input, and apply a completely
unsolicited HTML-ification into &#number; or even &entity; format
in the course of submitting the form.

Citations, please? I've never heard of this behaviour; it doesn't, or
wouldn't, surprise me in the least to find out it happens, but it seems
even more egrariously bogus than most things browsers do.

I've run into this in the past as well, and a simple test page confirms
this is the case for e.g. the euro sign. If a euro sign (placed in the
body text of the test page using &euro; or $#8364;) is copied and pasted
into a text input field and the form is subsequently submitted, some IE
versions (5.0 and 5.5) submit %26%238364%3B (i.e., €). Both
versions 4 and 6 submit %80, which probably makes more sense - at least
it is not a HTML entity (and Mozilla does the same ;). Oddly, Opera
(7.23) submits %3F, i.e. "?"...

Gertjan.

--
Gertjan Klein <gk****@xs4all. nl>

[Claire Tucker]

On Tue, 25 May 2004 11:16:46 +0200, Gertjan Klein <gk****@xs4all. nl>
wrote:

On Mon, 24 May 2004 23:50:44 GMT, Owen Jacobson wrote:

On Thu, 20 May 2004 11:22:41 +0100, Alan J. Flavell wrote:

The immediate problem which occurs to me are those browsers which,
contrary to anything that's even hinted at in the specifications, take
a user input character in a form text input, and apply a completely
unsolicited HTML-ification into &#number; or even &entity; format
in the course of submitting the form.

Citations, please? I've never heard of this behaviour; it doesn't, or
wouldn't, surprise me in the least to find out it happens, but it seems
even more egrariously bogus than most things browsers do.

I've run into this in the past as well, and a simple test page confirms
this is the case for e.g. the euro sign. If a euro sign (placed in the
body text of the test page using &euro; or $#8364;) is copied and pasted
into a text input field and the form is subsequently submitted, some IE
versions (5.0 and 5.5) submit %26%238364%3B (i.e., €). Both
versions 4 and 6 submit %80, which probably makes more sense - at least
it is not a HTML entity (and Mozilla does the same ;). Oddly, Opera
(7.23) submits %3F, i.e. "?"...

I remember vauguely something about this to do with entered characters
not being available in the document encoding. I think by default IE
(and Opera?) will submit forms using the charset that the containing
document uses, but the forms will accept any unicode character. Opera
must use "?" to mean "unrepresentabl e character" (probably using the
Windows API function to do the conversion) while IE obviously had a
bug where it would try to represent the unrepresentable character as
an HTML entity.

I seem to remember that sending the document in a unicode-based
encoding (for example, utf8) causes IE to send back the characters in
that same encoding, thus bypassing the problem completely. The
submitted characters will be encoded using %xx hexidecimal octet
references.

This is from memory, though. It's been a while since I've dealt with
this. A quick experiment could prove this for anyone who needs this.

-Claire

[Alan J. Flavell]

On Tue, 25 May 2004, Gertjan Klein wrote:

On Mon, 24 May 2004 23:50:44 GMT, Owen Jacobson wrote:

On Thu, 20 May 2004 11:22:41 +0100, Alan J. Flavell wrote:

The immediate problem which occurs to me are those browsers which,
contrary to anything that's even hinted at in the specifications, take
a user input character in a form text input, and apply a completely
unsolicited HTML-ification into &#number; or even &entity; format
in the course of submitting the form.
Citations, please? I've never heard of this behaviour; it doesn't, or
wouldn't, surprise me in the least to find out it happens, but it seems
even more egrariously bogus than most things browsers do.

My page http://ppewww.ph.gla.ac.uk/~flavell/...form-i18n.html
discusses this and other strange observations. It makes no claims to
be complete, however!
I've run into this in the past as well, and a simple test page confirms
this is the case for e.g. the euro sign. If a euro sign (placed in the
body text of the test page using &euro; or $#8364;) is copied and pasted
into a text input field and the form is subsequently submitted, some IE
versions (5.0 and 5.5) submit %26%238364%3B (i.e., €).
Yup, seen that.
Both versions 4 and 6 submit %80, which probably makes more sense
It makes sense of you assume that Windows-1252 is a good choice of
character encoding for use on the World-Wide Web. No guesses for who
is trying to impose that choice on us, eh?
- at least it is not a HTML entity (and Mozilla does the same ;).
Oddly, Opera (7.23) submits %3F, i.e. "?"...

That behaviour cannot be categorised as wrong, based on what the
specifications say. My page goes into details.

For most browsers, you get more-predictable results if your HTML form
page is charset=utf-8 (even if, in reality, it is only us-ascii !);
but then you get terrible trouble with Netscape-4 versions.