Wordpress News/Blog contains funny characters, your site has been hacked

If you are finding weird characters in the Wordpress News Blog roll, then your has been hacked. An example is; 

I+ACYAIw-8217+ADs-m excited to announce that the first beta of WordPress 3.9 is now available for testing. WordPress 3.9 is due out next month +ACYAIw-8212+ADs but in order to hit that goal, we need your help testing all of the goodies we+ACYAIw-8217+ADs-ve added: We updated TinyMCE, the software powering the visual editor, to the latest version. +AFsAJgAj-8230+ADsAXQ- […]

or you see those characters in the title tag of your site, hackers have gotten into your site and/or guessed your password. See more information on latest attack here - http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html

There are many, resolutions but even after this http://codex.wordpress.org/FAQ_My_site_was_hacked and many more recommendation using Google search about this. 

You may see these I+ACYAIw-8217+ADs-m still appear. An analysis of several sites, indicates that this has been caused by a change in a database setting. These strings are stored in your MySQL database and once corrupted remain there. 

This is because a change to using UTF-7 instead of UTF-8. See below for changes back to UTF-8.You may have to convert old database fields into the new characters set, see below for a solution. 

But for WordPress New RSS Blog entries from the mother-ship,  these entries which are stored in WordPress as transients. You can just blow of them off, and delete them.

Here is an excellent plug-in to just that. Delete all transients 

http://wordpress.org/plugins/delete-expired-transients/

Actually you can create a schedule task to do this periodically. 

To be thorough, you may want to check these settings.

1. Check the DB_CHARSET constant in wp-config.php, it may read utf-7 change to utf-8.

1 2 3

/** Database Charset to use in creating database tables. */ define('DB_CHARSET', 'utf8'); define('DB_COLLATE', '');

2. In the WordPress admin menu, Change “Settings->Reading->Encoding for Pages and Feeds” from UTF-8 from UTF-7

Following the above bad advice might appear to ‘fix’ the appearance of some languages, but others will still display incorrectly. Furthermore, these changes will cause your text to be encoded incorrectly, so that when you do implement the correct fix, your foreign-language pages will have bad character mappings and be filled with incorrect characters. You will then have to correct or re-enter the text from scratch.
If you found unusual characters in your database, try this...

To fix this problem, you need to change the default character set/collation of your WordPress site’s MySQL database to UTF-8/utf8_general_ci and then convert all the current table data.
The traditional way to do this is to run various “ALTER DATABASE” and “ALTER TABLE” SQL queries within phpMyAdmin or via the command-line mysql client, and you can find some great instructions here:
http://en.gentoo-wiki.com/wiki/Convert_latin1_to_UTF-8_in_MySQL

Unfortunately, this procedure is tedious.

There is however a fantastic plugin named Convert WP Database to UTF-8. This plugin adds a sub-menu page named “UTF-8 DB Converter” to the Plugins Menu. Simple click on “Start converting” and the plugin will automatically execute the required SQL queries to alter the character set and collation of all your existing WordPress tables.

You only need to do it once per website, and the problem is fixed for good. You can then uninstall the plugin.
Although this plugin has always run without a hitch for me, it is proper practice to make a backup of your WordPress database before attempting this procedure, just in case something goes wrong. Most web hosts provide wizards that let you easily backup your MySQL databases, but you can do this using phpMyAdmin or a WordPress plugin like

Also, you should place your website in maintenance mode using a plugin like WP Maintenance Mode to stop users accessing your website while the character set conversion is in progress. The time taken will vary depending on how big your database is, but for me, the conversion has always been completed in less than 1 minute.

Additional reading
Technical 
http://joemaller.com/1328/fixing-mixed-encoding-mysql-dumpfiles-with-wordpress/
Easy to read
http://digwp.com/2011/07/clean-up-weird-characters-in-database/