This issue actually isn't specific to ActivEdit, but modern application servers, such as CFMX that support Unicode and the type of database field used.
Word punctuation, generally in the range of characters 8211 through 8221 may cause problems when you move content to a database field that doesnn't support unicode (varchar) (use nvarchar) and standard encoding for email, for instance.
ActivEdit doesn't change these characters, although you might think so if you view source and then switch back to Normal mode since the content then goes back through the hidden textarea and is converted according to the standard character set defined in Windows.
Because they may cause unforseen problems in other componenets or applications, we recommend that they be converted in the form action page with regular expressions.
You can find articles in our knowledge base that address specific issues that these characters present, along with sample regular expressions to convert them. There are similar technotes on the Macromedia site.
One particulary problematic situation is when text containing these characters are spell checked with a standard lexicon, since the lexicon supports only ascii. They cause the dictionary to become corrupted and unreadable when added to the lexicon. We added regular expressions to ActivSpell 2.0 to address this, although the problem was not common, since it only occurs when someone adds a word to the dictionary that is spelled correctly, but was displayed as misspelled since the Word punctuation was misread as a non-punctuation character.
See http://www.cfdev.com/support/kb/index.cfm/fuseaction/single/id/1056
and
http://www.cfdev.com/support/kb/index.cfm/fuseaction/single/id/1062
Note in the above article how the characters were also not recognized in our current db (moved from MS SQL) and were displayed as squares. The article wasn't touched by ActivEdit since the move, but the characters were preserved in CFMX and MS SQL with field type nvarchar.
Basically, a curly quote is not worth the trouble;-)