UTF-8 is naturally preferred by WordPress, but it doesn't enforce the character set because it doesn't know the character set of random data that you give it.
So, if your database tables are set to UTF-8, but the data is not (say it's ISO-8859-1), then if it has invalid characters, the resulting insertion into the database can lead bad results, because MySQL rejects the string as non-UTF (or worse yet, truncates it at the first non-UTF-8 character).
Unfortunately, it's often a guess as to what the data is encoded as. You have to look at the data's binary representation and sort of figure it out. It's possible that blogger is returning ISO-8859-1 data, which will work fine if your table is not UTF-8 but will fail if it is. Or vice-versa. Hard to say. This is why details of the specific case matters.
Ideally, WordPress creates UTF-8 tables. WordPress has used UTF-8 as the default for a very long time, but at one point in time it did not. If it's a new install, it should be a UTF-8 table. Which means that if the data is not UTF-8, then you need to convert it. This also means that if your particular test install is old and/or not using UTF-8 tables for whatever reason, you might not have the same problems inserting seemingly the same data.
So, look at your character set on your test bed too. And try to examine the binary form of whatever blogger is sending back as well.