When a unicode output is translated to an 8-bit character set, sometimes it is done with a "best efforts" conversion. Characters that don't have an exact match are converted to something similar, so maybe "a with circumflex" becomes "a". This can be extremely dangerous for security. There is a unicode character "half-width less than sign". Browsers do not recognise this as the start of a tag, so it is not usually escaped. However, on a best efforts conversion it may be translated to a regular < and this can cause an XSS flaw. This isn't just a theoretical concern; I have seen this in the wild. Some info here.
In most cases, the best solution is to use utf-8 everywhere. If this is not possible, you should do a strict conversion, rather than best efforts. And if that isn't possible, then you must do the best efforts conversion BEFORE you do any escaping.
There is a very simple rule to avoid problems: decode before validate. Whatever character set you get it (or URL encoding, etc.) - decode it fully before you validate or do any operations on the data. If you follow this rule, you should be good, even if there are flaws in your decoding (e.g. accepting overlong utf-8 sequences).