[FX.php List] Bad apostrophe character confounds FMP

[Bob Patin]

Jonathan,

If you want to send me the problem page (backchannel of course), I'll  
resave it in Dreamweaver and send it back to you; I think your problem  
is that the page hasn't actually re-formatted...

I had nightmares with this on a Japanese site, but the UTF-8 was the  
main part of the solution. I also now routinely strip slashes in  
forms, since that causes all sorts of trouble as well.

Bob Patin
Longterm Solutions
bob at longtermsolutions.com
615-333-6858
http://www.longtermsolutions.com
Member of FileMaker Business Alliance and FileMaker TechNet

   CONTACT US VIA INSTANT MESSAGING:
      AIM or iChat: longterm1954
      Yahoo: longterm_solutions
      MSN: tech at longtermsolutions.com
      ICQ: 159333060

--------------------------
Contact us for FileMaker hosting and programming for all versions of  
FileMaker
PHP • CDML • Full email services • Free DNS hosting • Colocation •  
Consulting

On Dec 10, 2007, at 10:35 AM, Jonathan Schwartz wrote:

> Errr...this is getting weirder by the moment.
>
> I tried the function below (thanks) and the offending apostrophe was  
> replaced with:
>
> 	&number8217,
>
> So the name read like this on the web form:	 O&number8217,Doherty
>
> I'm assuming that I have a broader issue to resolve here with  
> handling non-standard characters and that this is a current example  
> of the problem.  Or...just I just fix the original bad character and  
> a forget that whole thing?
>
> J
>
>
>
> At 11:03 AM -0500 12/10/07, VanBuskirk, Patricia wrote:
>> Sounds like it's a "curly apostrophe" .. I had a major issue with  
>> those once before and ended up having to put a special function in  
>> my process page to weed them out.  This, after many painful hours  
>> of troubleshooting!!  Here's the code I use for that...
>>
>> function convert_smart_quotes($string)
>> {
>>     $search = array(chr(145),
>> 	                 chr(146),
>> 					 chr(147),
>> 					 chr(148),
>> 					 chr(151),
>> 					 "#",
>> 					 ";",
>> 					 "[",
>> 					 "]",
>> 					 "{",
>> 					 "}",
>> 					 "URL=http://");
>>      $replace = array("'",
>> 	                   "'",
>> 					   '"',
>> 					   '"',
>> 					   "-",
>> 					   "number",
>> 					   ",",
>> 					   "",
>> 					   "",
>> 					   "",
>> 					   "",
>> 					   "");
>>      return str_replace($search, $replace, $string); }
>>
>> $ 
>> _POST 
>> ['Customer_Description 
>> ']=convert_smart_quotes($_POST['Customer_Description']);
>>
>>
>> -----Original Message-----
>> From: fx.php_list-bounces at mail.iviking.org [mailto:fx.php_list-bounces at mail.iviking.org 
>> ] On Behalf Of Jonathan Schwartz
>> Sent: Monday, December 10, 2007 10:51 AM
>> To: FX.php Discussion List
>> Subject: Re: [FX.php List] Bad apostrophe character confounds FMP
>>
>> Ok...that didn't quite work.
>>
>> I put the UTF encoding statement on a couple of
>> likely pages in the solution and the offending
>> character still came in from the FMP record and
>> ended up causing FMP to fail upon trying to
>> create a new record with the data.  (I'm leaving
>> the bad character in the original record until
>> the issue is fixed).
>>
>> By the way, the character does look like an
>> apostrophe, but not the same as other apostrophes.
>>
>> With the UTF statement in, what exactly should
>> happen when a bad character is encountered?
>>
>>
>> For reference, the ages with  UTF statement:
>> 	1) Login (bring in FMP record)
>> 	2) Contact (Edit original FMP record)
>> 	3) Review before creating new record
>> 	... (create record page has no html)
>> 	4) Review of created record
>>
>> Jonathan
>>
>> At 7:07 AM -0800 12/10/07, Troy Meyers wrote:
>>> Jonathan,
>>>
>>> Yes it would. It doesn't matter if the source of
>>> the character coming back is user input or a
>>> value being parroted back. One of the places I
>>> found and fixed was a form page with a long list
>>> of checkboxes of author names. If a user
>>> selected one with that contained an accented e
>>> (é) or umlaut (ü) then the problem would occur.
>>>
>>> -Troy
>>>
>>>
>>>>  Alex and Troy,
>>>>
>>>>  I'm embarrassed to say that I had NO content type encoding on the
>>>>  page...or most other pages for that matter. I haven't  
>>>> concentrated on
>>>>  this area...up until now...but I intend to.
>>>>
>>>>  Question...would this statement help if the bad character already
>>>>  existed in an FMP record, was subsequently displayed on a fx.php  
>>>> page
>>>>  and then resubmitted to FMP?  That's what caused the current  
>>>> problem.
>>>>
>>>>  Thx
>>>>
>>>>  Jonathan
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>>
>> --
>> Jonathan Schwartz
>> Exit 445 Group
>> jonathan at exit445.com
>> http://www.exit445.com
>> 415-381-1852
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
>
> --
> Jonathan Schwartz
> Exit 445 Group
> jonathan at exit445.com
> http://www.exit445.com
> 415-381-1852
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list