[FX.php List] Bad apostrophe character confounds FMP

[Jonathan Schwartz]

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