Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!newsfeed10.multikabel.net!multikabel.net!newsfeed20.multikabel.net!news2.euro.net!newsfeed.freenet.ag!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-Id: <1655216.aK4W3vaeNJ@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 17 Jun 2011 22:03:17 +0200 User-Agent: KNode/4.4.7 Content-Transfer-Encoding: 8Bit Subject: Re: Form fields to database and back? Newsgroups: comp.lang.php References: Followup-To: comp.lang.php MIME-Version: 1.0 Lines: 62 NNTP-Posting-Date: 17 Jun 2011 22:03:18 CEST NNTP-Posting-Host: 99d431e5.newsspool3.arcor-online.net X-Trace: DXC=?e5dZNQQCITV0Pe9PRnbJ\McF=Q^Z^V3X4Fo<]lROoRQ8kFlDfX X-Complaints-To: usenet-abuse@arcor.de Xref: x330-a1.tempe.blueboxinc.net comp.lang.php: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, (2004)