Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #2205 > unrolled thread

Form fields to database and back?

Back to article view | Back to comp.lang.php

Contents

  Form fields to database and back? bobmct <bobm3@worthless.info> - 2011-06-16 20:36 -0400
    Re: Form fields to database and back? The Natural Philosopher <tnp@invalid.invalid> - 2011-06-17 01:43 +0100
      Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-16 21:03 -0400
    Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-16 21:02 -0400
      Re: Form fields to database and back? bobmct <bobm3@worthless.info> - 2011-06-16 22:34 -0400
        Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-16 23:50 -0400
          Re: Form fields to database and back? bobmct <bobm3@worthless.info> - 2011-06-17 07:09 -0400
            Re: Form fields to database and back? bobm3@worthless.info - 2011-06-17 15:18 +0000
              Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-17 16:44 -0400
        Re: Form fields to database and back? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-06-17 13:28 +0200
        Re: Form fields to database and back? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-06-17 22:03 +0200
          Re: Form fields to database and back? bobmct <bobm3@worthless.info> - 2011-06-17 19:52 -0400
            Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-17 21:01 -0400
              Re: Form fields to database and back? Captain Paralytic <paul_lautman@yahoo.com> - 2011-06-22 09:05 -0700
                Re: Form fields to database and back? Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-22 13:15 -0400
            Re: Form fields to database and back? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-06-18 08:35 +0200

#2205 — Form fields to database and back?

I've run into a situation where the data in a particular set of fields
on a form contain lots and lots of special characters (they are regex
notes for a department).

The normal methods I used are failing to retrieve and display the
original characters.

My google searches come up with some rather conflicting
recommendataions.  So I thought I would ask this group.

What is the most accurate technique for translating, storing,
retrieving and properly re-displaying such fields with php and mysql?

Thanks

[toc] | [next] | [standalone]

#2206

bobmct wrote:
> I've run into a situation where the data in a particular set of fields
> on a form contain lots and lots of special characters (they are regex
> notes for a department).
> 
> The normal methods I used are failing to retrieve and display the
> original characters.
> 
> My google searches come up with some rather conflicting
> recommendataions.  So I thought I would ask this group.
> 
> What is the most accurate technique for translating, storing,
> retrieving and properly re-displaying such fields with php and mysql?
> 
> Thanks
> 
try BLOBS
that's good for storage and retrieval. But inserting can be an issue if 
the regexp contains 'quotes'

[toc] | [prev] | [next] | [standalone]

#2208

On 6/16/2011 8:43 PM, The Natural Philosopher wrote:
> bobmct wrote:
>> I've run into a situation where the data in a particular set of fields
>> on a form contain lots and lots of special characters (they are regex
>> notes for a department).
>>
>> The normal methods I used are failing to retrieve and display the
>> original characters.
>>
>> My google searches come up with some rather conflicting
>> recommendataions. So I thought I would ask this group.
>>
>> What is the most accurate technique for translating, storing,
>> retrieving and properly re-displaying such fields with php and mysql?
>>
>> Thanks
>>
> try BLOBS
> that's good for storage and retrieval. But inserting can be an issue if
> the regexp contains 'quotes'

Blobs should (almost) never be used to store text (why are they called 
BINARY LONG OBJECTS?).

And quotes are never a problem with any database if you escape the 
strings properly.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2207

On 6/16/2011 8:36 PM, bobmct wrote:
> I've run into a situation where the data in a particular set of fields
> on a form contain lots and lots of special characters (they are regex
> notes for a department).
>
> The normal methods I used are failing to retrieve and display the
> original characters.
>
> My google searches come up with some rather conflicting
> recommendataions.  So I thought I would ask this group.
>
> What is the most accurate technique for translating, storing,
> retrieving and properly re-displaying such fields with php and mysql?
>
> Thanks
>

It depends on what the problem is - which is why you're probably finding 
conflicting answers.  Your question is too vague for a meaningful answer.

First of all, it it ASCII, UTF-8 or some other character set?  It does 
make a difference, and you want everything (the web page, PHP and MySQL 
to agree).

Second of all, how are you storing and retrieving the information?  Then 
how are you displaying it?

Generally, text information should be stored in the database in text 
fields, using the appropriate charset and collation.

But to give you a good answer requires a lot more information.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2209

On Thu, 16 Jun 2011 21:02:23 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>It depends on what the problem is - which is why you're probably finding 
>conflicting answers.  Your question is too vague for a meaningful answer.
>
>First of all, it it ASCII, UTF-8 or some other character set?  It does 
>make a difference, and you want everything (the web page, PHP and MySQL 
>to agree).
>
>Second of all, how are you storing and retrieving the information?  Then 
>how are you displaying it?
>
>Generally, text information should be stored in the database in text 
>fields, using the appropriate charset and collation.
>
>But to give you a good answer requires a lot more information.

Good points.  I should have been more clear.

The fields(s) in the Mysql database aredefined as  varchar(255)

A typical field the user would enter would be like this:

prd ="^ptmdtr-slb.bna.com^";

I need to store it in the db field then be able to retrieve it and
redisplay it exactly as entered.

Currently I am using:
$fld = htmlspecialchars_decode($fld);
$fld = addslashes($fld);

update table set field_name = '$fld' 

To retrieve and redisplay I use:
$fld = $row['field_name'];
$fld = htmlspecialchars($fld);
$fld = stripslashes($fld);

Now I know that I am missing something here so if any ofyou kind
persons would suggest a "usual' sequence of functions to use to
accomplsih this I'd be mighty greatful.

Thanks

[toc] | [prev] | [next] | [standalone]

#2210

On 6/16/2011 10:34 PM, bobmct wrote:
> On Thu, 16 Jun 2011 21:02:23 -0400, Jerry Stuckle
> <jstucklex@attglobal.net>  wrote:
>
>> It depends on what the problem is - which is why you're probably finding
>> conflicting answers.  Your question is too vague for a meaningful answer.
>>
>> First of all, it it ASCII, UTF-8 or some other character set?  It does
>> make a difference, and you want everything (the web page, PHP and MySQL
>> to agree).
>>
>> Second of all, how are you storing and retrieving the information?  Then
>> how are you displaying it?
>>
>> Generally, text information should be stored in the database in text
>> fields, using the appropriate charset and collation.
>>
>> But to give you a good answer requires a lot more information.
>
> Good points.  I should have been more clear.
>
> The fields(s) in the Mysql database aredefined as  varchar(255)
>
> A typical field the user would enter would be like this:
>
> prd ="^ptmdtr-slb.bna.com^";
>
> I need to store it in the db field then be able to retrieve it and
> redisplay it exactly as entered.
>
> Currently I am using:
> $fld = htmlspecialchars_decode($fld);
> $fld = addslashes($fld);
>
> update table set field_name = '$fld'
>
> To retrieve and redisplay I use:
> $fld = $row['field_name'];
> $fld = htmlspecialchars($fld);
> $fld = stripslashes($fld);
>
> Now I know that I am missing something here so if any ofyou kind
> persons would suggest a "usual' sequence of functions to use to
> accomplsih this I'd be mighty greatful.
>
> Thanks
>

A varchar field is great, as long as you're using the same charset all 
the way through.  But there are some other problems in your code:

First of all, you shouldn't be using htmlspecialchars_decode() - you do 
not get an encoded string from the browser; it's already been handled.

Second of all, addslashes() is definitely the WRONG function to use - 
and has been for years.  Before storing in the database, you should use 
mysql_real_escape_string($fld).

When you get the data from the database, you should not be using 
stripslashes().  There's no need.

Finally, when you go to display the data, you do want to use 
htmlspecialchars(), or possibly better for your needs, htmlentities().

See if that doesn't work better.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2213

On Thu, 16 Jun 2011 23:50:12 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 6/16/2011 10:34 PM, bobmct wrote:
>> On Thu, 16 Jun 2011 21:02:23 -0400, Jerry Stuckle
>> <jstucklex@attglobal.net>  wrote:
>>
>>> It depends on what the problem is - which is why you're probably finding
>>> conflicting answers.  Your question is too vague for a meaningful answer.
>>>
>>> First of all, it it ASCII, UTF-8 or some other character set?  It does
>>> make a difference, and you want everything (the web page, PHP and MySQL
>>> to agree).
>>>
>>> Second of all, how are you storing and retrieving the information?  Then
>>> how are you displaying it?
>>>
>>> Generally, text information should be stored in the database in text
>>> fields, using the appropriate charset and collation.
>>>
>>> But to give you a good answer requires a lot more information.
>>
>> Good points.  I should have been more clear.
>>
>> The fields(s) in the Mysql database aredefined as  varchar(255)
>>
>> A typical field the user would enter would be like this:
>>
>> prd ="^ptmdtr-slb.bna.com^";
>>
>> I need to store it in the db field then be able to retrieve it and
>> redisplay it exactly as entered.
>>
>> Currently I am using:
>> $fld = htmlspecialchars_decode($fld);
>> $fld = addslashes($fld);
>>
>> update table set field_name = '$fld'
>>
>> To retrieve and redisplay I use:
>> $fld = $row['field_name'];
>> $fld = htmlspecialchars($fld);
>> $fld = stripslashes($fld);
>>
>> Now I know that I am missing something here so if any ofyou kind
>> persons would suggest a "usual' sequence of functions to use to
>> accomplsih this I'd be mighty greatful.
>>
>> Thanks
>>
>
>A varchar field is great, as long as you're using the same charset all 
>the way through.  But there are some other problems in your code:
>
>First of all, you shouldn't be using htmlspecialchars_decode() - you do 
>not get an encoded string from the browser; it's already been handled.
>
>Second of all, addslashes() is definitely the WRONG function to use - 
>and has been for years.  Before storing in the database, you should use 
>mysql_real_escape_string($fld).
>
>When you get the data from the database, you should not be using 
>stripslashes().  There's no need.
>
>Finally, when you go to display the data, you do want to use 
>htmlspecialchars(), or possibly better for your needs, htmlentities().
>
>See if that doesn't work better.

Thank much Jerry,

That's just the advice I was looking for.

Bob

[toc] | [prev] | [next] | [standalone]

#2221

Well - another follow-up:

Using your advise this is what the results are:

Data as originally stored in varchar field:
prd ="^ptmdtr-slb.bna.com^";

Data as put back into the varchar field:
prd ="^ptmdtr-slb.bna.com^";

I am using php.5.2.6 (older but I'm locked into it at this point) and 
mysql 5.0.25, apache 2.2.11

Upon retrieving the data I use $fld = htmlspecialchars($fld); to display,

and upon storing I use $fld = mysql_real_escape_string($fld); to update.

For what ever reason it appears that the fields are coming back from the 
browser (referenced as $fld = $_POST['field_name'];) actually still 
encoded.

So you see?  I'm at a loss with this (should be minor) issue.

Any more suggestions?

Thanks - Bob

[toc] | [prev] | [next] | [standalone]

#2229

On 6/17/2011 11:18 AM, bobm3@worthless.info wrote:
> Well - another follow-up:
>
> Using your advise this is what the results are:
>
> Data as originally stored in varchar field:
> prd ="^ptmdtr-slb.bna.com^";
>
> Data as put back into the varchar field:
> prd ="^ptmdtr-slb.bna.com^";
>
> I am using php.5.2.6 (older but I'm locked into it at this point) and
> mysql 5.0.25, apache 2.2.11
>
> Upon retrieving the data I use $fld = htmlspecialchars($fld); to display,
>
> and upon storing I use $fld = mysql_real_escape_string($fld); to update.
>
> For what ever reason it appears that the fields are coming back from the
> browser (referenced as $fld = $_POST['field_name'];) actually still
> encoded.
>
> So you see?  I'm at a loss with this (should be minor) issue.
>
> Any more suggestions?
>
> Thanks - Bob

How are you displaying the data in the browser?  What do you see on the 
screen and in the page source?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2215

El 17/06/2011 4:34, bobmct escribió/wrote:
> The fields(s) in the Mysql database aredefined as  varchar(255)
>
> A typical field the user would enter would be like this:
>
> prd ="^ptmdtr-slb.bna.com^";

Sorry but... How can you call that "special characters"? That's plain 
7-bit ASCII. It's been properly handled by computers since the 1960s.



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#2226

bobmct wrote:

> A typical field the user would enter would be like this:
> 
> prd ="^ptmdtr-slb.bna.com^";
> 
> I need to store it in the db field then be able to retrieve it and
> redisplay it exactly as entered.
> 
> Currently I am using:
> $fld = htmlspecialchars_decode($fld);
> $fld = addslashes($fld);
> 
> update table set field_name = '$fld'

This does not make sense.  Either you are writing a CMS, then you should 
store all markup verbatim (after removing potentially unwanted elements).  
Or you are not, then you should not be receiving markup in the first place.

Unless you write for debugging, you could combine the calls:

  $fld = addslashes(htmlspecialchars($fld));

But not even debugging merits two assignments here.  (Note that this is just 
an example.  Do not use addslashes() here.)

If this is just a bad example, then consider this: You should avoid using 
such PHP built-ins to escape parts of a database query.  addslashes() is 
inadequate() to the task.  Use extension-provided functions, like 
mysql_real_escape_string() or (better) prepared statements (as supported 
e.g. by PDO, MySQLi, and sqlsrv, and implemented e.g. by Zend Framework).
 
> To retrieve and redisplay I use:
> $fld = $row['field_name'];
> $fld = htmlspecialchars($fld);
> $fld = stripslashes($fld);

I do not see why stripslashes() is needed (other than to compensate for the 
pointless addslashes() before).  htmlspecialchars() is only needed in the 
output (so unless you are displaying a value twice, `echo' the return value 
of htmlspecialchars() directly – unless your template engine/framework 
already does that for you before, which it should be able to if it is any 
good), and you should provide suitable additional parameters then (so that, 
e.g., Unicode characters can be properly decoded and referred in the 
markup).

Of course, you do not need or want to escape all dynamically generated 
content, only where it matters (given a proper character encoding, 
especially one that is the same in the database and the generated document, 
and you making sure that no unwanted HTML is stored/retrieved in the first 
place, there is no need to escape the generated content of elements.)  Not 
trying to escape things that do not need to be escaped can have positive 
impact on the performance of a Web application (if you know the value is an 
int – as made sure by a properly designed interface –, you don't have to 
treat it like a string).
 

PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
 -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#2234

All good points everyone, of course.  But with extensive testing today
here's what I had to end up with for consistent results:

From field to database I used mysql_real_escape_string.

When I look at the actual data stored in the db field that function
inserted backslashes before each double quote.

To display the retrieved db field I ran it through htmlspecialchars()
but the backslashes  still remained.  I had to use stripslashes to
remove them.

And no, this is NOT a cms.  Its a stand alone database update program.

Works for now.

And a general comment on nesting functions vs individual lines...

I've been coding for many decades and quite often, including prior to
this project, I have had to trudge through code written by others.
When one has no idea about the code and no documentation let alone
self documented code, nested functions are difficult to decode.

Of course it can be done but I've learned that when programs are
running on 16 core 48GB RAM systems,  it makes little difference in
performance but a whole LOT of difference for the next person to
understand.

Just my $.02 worth.

[toc] | [prev] | [next] | [standalone]

#2238

On 6/17/2011 7:52 PM, bobmct wrote:
> All good points everyone, of course.  But with extensive testing today
> here's what I had to end up with for consistent results:
>
>  From field to database I used mysql_real_escape_string.
>
> When I look at the actual data stored in the db field that function
> inserted backslashes before each double quote.
>

Then you have done something else, like used addslashes() somewhere. 
Alternatively, magic_quotes_gpc may be set on your server (it should NOT 
be; it has been deprecated for years and will be removed in PHP 6). But 
mysql_real_escape_string() will not cause backslashes to be added to the 
data in the database; when you retrieve the data it will be exactly as 
it originally was.


> To display the retrieved db field I ran it through htmlspecialchars()
> but the backslashes  still remained.  I had to use stripslashes to
> remove them.
>

That's because you did something else beforehand which is invalid.

> And no, this is NOT a cms.  Its a stando alone database update program.
>
> Works for now.
>
> And a general comment on nesting functions vs individual lines...
>
> I've been coding for many decades and quite often, including prior to
> this project, I have had to trudge through code written by others.
> When one has no idea about the code and no documentation let alone
> self documented code, nested functions are difficult to decode.
>
> Of course it can be done but I've learned that when programs are
> running on 16 core 48GB RAM systems,  it makes little difference in
> performance but a whole LOT of difference for the next person to
> understand.
>
> Just my $.02 worth.

PHP does not allow nested functions.  I'm not sure where that came up 
(you didn't quote the relevant text).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2295

On Jun 18, 2:01 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> On 6/17/2011 7:52 PM, bobmct wrote:
> PHP does not allow nested functions.  I'm not sure where that came up
> (you didn't quote the relevant text).
It came from TPL's suggestion of:
$fld = addslashes(htmlspecialchars($fld));
and are you sure that php doesn't allow this?

[toc] | [prev] | [next] | [standalone]

#2298

On 6/22/2011 12:05 PM, Captain Paralytic wrote:
> On Jun 18, 2:01 am, Jerry Stuckle<jstuck...@attglobal.net>  wrote:
>> On 6/17/2011 7:52 PM, bobmct wrote:
>> PHP does not allow nested functions.  I'm not sure where that came up
>> (you didn't quote the relevant text).
> It came from TPL's suggestion of:
> $fld = addslashes(htmlspecialchars($fld));
> and are you sure that php doesn't allow this?

Ah, that's what he's talking about.

Sure, that's allowed.   But that's not really "nesting".  Nesting 
functions would be more like:

function foo() {
    ...
    function bar() {
       ...
    }
}

Similar to nested loops.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2242

bobmct wrote:

> From field to database I used mysql_real_escape_string.
> 
> When I look at the actual data stored in the db field that function
> inserted backslashes before each double quote.
> 
> To display the retrieved db field I ran it through htmlspecialchars()
> but the backslashes  still remained.  I had to use stripslashes to
> remove them.

Then you are doing something wrong.  mysql_real_escape_string() – AISB, 
prepared statements (PS) with MySQLi or PDO are preferable to that – only 
escapes the data for the query, so that SQL code injection is prevented.
It does _not_ change the data to be stored.  So when you retrieve the data 
you should not need to unescape anything.  Perhaps you have used 
mysql_real_escape_string() on the retrieved data also, but that is _not_ its 
purpose.

> Works for now.

By chance.  mysql_real_escape_string() does more than addslashes(), which is 
why it is preferable to that.  (And PS are preferable to it because they 
consider the type automatically, among other advantages.)
 

PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web