HTMLEditFormat() is the least used and least understood function in CFML amongst most CF developers.
That said, let me explain and alleviate your fears. First, if you have time, read the RFC for HTML 2.0: http://www.ietf.org/rfc/rfc1866.txt Reading the RFC will clue you in that any tag attribute's value will be stored in the browser memory with escaped characters like: > < " & translated to their actual literal values: > < " & And when the form submits, the actual literal values in the browser's memory will be encoded depending on the form's method. For both GET and POST operations, these literals: > < " & will be converted to: %3e %3c %22 %26 When the ColdFusion Server receives these form values (GET or POST), these values %3e %3c %22 %26 will be converted back to: > < " & Hence, when you access your form variables: URL.blah or FORM.blah, the values would be what the user see's in the his/her browser's form fields. The caveat to all of this is UNICODE characters. In IE (not sure in Netscape), Unicode characters outside of the ASCII range gets encoded into this format before submission (and before METHOD encoding): &#nnnn; This is then sent as (after METHOD encoding): %26%23nnnn%3b I have verified this with a packet listener in a controlled environment. :) In CF 4.x.x (I have not verified CF5 or MX), %26%23nnnn%3b is translated back to &#nnnn; Hence when you access the form variables: URL.blah or FORM.blah, the value would be: &#nnnn; (Note: & to %26 conversion may be wrong. It could be: & to & to %26amp%3b. I can't remember, but it is all good. The translation is always kosher with a HTML 2.0 or better compliant browser and server. :)) The &#nnnn; issue is something you all are worried about. BUT, for the purpose of quotation marks, greater/lesser-than signs, and ampersands, you don't have to worry about them at all with HTMLEditFormat(). You should ALWAYS use HTMLEditFormat(). All other solutions ARE hackneyed. To fix the problem of &#nnnn; escaped unicode characters, use this workaround: function smf_HTMLEditFormat(I_str) { return REReplaceNoCase(HTMLEditFormat(I_str, -1), "&(##?[[:alnum:]]+);", "&\1;", "ALL"); } Hence, even if you stored the data in the DB as: &#nnnn;, when you give the browser: &#nnnn;, the browser will take care of presenting the equivalent Unicode character. If it doesn't, it is not a HTML 4.0 compliant browser. :P I have a good feeling that CF5/MX actually translated the encoded characters to unicode characters. :P No empirical data to prove it though. :P Alright. That's my take on this issue. :) ---------------------------- James Ang Senior Programmer MedSeek, Inc. [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:48 AM To: CF-Talk Subject: Re: FW: RE: Quotation Hell Just jumping in briefly to explain what I did to get around " and ' in our apps. Going into the database would be fine (using perserveSingleQuotes() and whatever 'escape' character we could use that the database recognizes), it's pulling out and displaying again that became a problem. So, when we're displaying to the end user... " & ' became ", etc so that it wouldn't break the form fields, etc. Going back into the database via 'save changes' button, the " apparently becomes a " again going back in... thus, we were able to maintain the 'original' user-submitted value. One thing I hate about certain forum software (and, I won't say which) is that what you submitted isn't what's always returned to the user when they want to edit. I griped about it, but was told that it's faster to do the 'translation' of things before shoving it into the db. They failed to recognize something -- I don't care what it's translation is, I care about data integrity and making sure that if that's what I put in, that's what I get out when I go to edit that data blob. To this day, it's still an issue and I just quit pestering the forum maker as it's their product vs. my opinion. :P I think if you use HTMLEditFormat(), you're putting yourself into a new world of problems. Especially if the < > characters translate to something else. Not to mention, great... now you gotta worry about storage issue (especially if you're using a varchar field and not a blob-type field). ~Todd On Thu, 13 Jun 2002, Adrian Lynch wrote: > -----Original Message----- > From: Adrian Lynch > Sent: 13 June 2002 17:33 > To: '[EMAIL PROTECTED]' > Subject: RE: RE: Quotation Hell > > > Thats ok, you can be a jackarse all you want. I hadn't used htmlEditFormat() > before, if I had, I might have suggested it. It was a case of I've got a way > around it, see if it works for you. > > One thing you might notice with htmlEditFormat(), is that you still have the > problem of extra characters, " still becomes ", and if that's what you > put in you DB and you then use Left(), you have a problem if it chops it, > and you still need to make sure your DB is not going to be expecting more > than it gets. > > Now if I'm wrong about this someone please tell me, or is this hackneyed > too? > > Ade > > -- ============================================================ Todd Rafferty ([EMAIL PROTECTED]) - http://www.web-rat.com/ | Team Macromedia Volunteer for ColdFusion | http://www.macromedia.com/support/forums/team_macromedia/ | http://www.flashCFM.com/ - webRat (Moderator) | http://www.ultrashock.com/ - webRat (Back-end Moderator) | ============================================================ ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
