I mentioned the database primarily so that I would not get suggestions that involve open's encoding option. All of the examples above are from the same column. It may be possible to have multiple formats in the same string. Even if that is not the case today, I would like a solution that supports it in the future.
I need to normalize to HTML. Whatever intermediate encoding gets the job done is fine by me. Passing html to encode_entities causes it to be double encoded, which does not display correctly on a web page, so first thing I do is run the input through decode_entities. I suppose it is possible that the input will already be double encoded html. I hadn't thought about running decode_entities multiple times before. Good idea.
The database is only a few months old, is added to constantly, and is expected to be added to indefinitely. It is extremely unlikely the provider will do anything to improve their input sanitization. Had they the choice, they would not provide me the data in any format. They certainly aren't going to make it any easier to parse.
I do try not to post n run. You took the time to read my message and reply, the least I can do is satisfy your curiousity.
Thank you for the detailed analysis and suggestions. Had Encoding::FixLatin not been suggested first, I probably would have ended up using your "guidelines" as an outline for a solution.