UTF-8 är (i allmänhet) en "säker" kodning för alla teckenuppsättningar i världen. (Inte alltid den mest effektiva, och det finns några argument att framföra att Unicode underrepresenterar CJK-skripten med sin "unified han"-modell, men går vidare...)
Det är dock troligt att dina gränssnittsprogram inte översätts till/från UTF-8 korrekt. Till exempel, ó => ó ser ut som att UTF-8-data (där ett tecken kan spridas över ett varierande antal byte) presenteras för dig med en enkelbyte europeisk kodning, som ISO-8859-15 eller MS- CP-1451 eller liknande.
Du är förmodligen lagrar data korrekt, men laddar in det felaktigt. Om du bara använder mysql terminalprogram eller liknande, se till att din terminal är inställd för att använda UTF-8 (på ett Unix/Linux-system, locale borde förmodligen vara något som slutar på .utf8 , t.ex. min har LANG=en_US.utf8 )
Om du hämtar data med hjälp av ett GUI-verktyg eller liknande, kontrollera dess Inställningar/Preferences-panel för teckenuppsättningen.
Om du får tillbaka de felöversatta tecknen till ett program du har skrivit, titta på ditt språks verktyg för att ställa in språket. (Kanske, INSERT rutiner har det rätt, men SELECT rutiner har det fel?)
Och om detta skickas till webben, se till att dina (XML|HTML|XHTML)-filer har charset=utf8 deklareras på lämplig plats, eller översätt tillbaka från UTF-8 till teckenuppsättningen i ditt dokument (om möjligt) med något som iconv när du infogar text från databasen. (De flesta icke-Unicode-teckenuppsättningar kan naturligtvis bara representera en delmängd av Unicode, t.ex. ISO-8859-15-uppsättningen gör ett anständigt jobb med att täcka europeiska språk, men har inget stöd för kyrilliska, arabiska eller CJK-skriftsystem, så det är möjligt att misslyckas med att översätta ett tecken.) I Perl kan du använda passerargument för att open eller använd binmode för att sätta upp ett transparent teckenuppsättningsöversättningslager på en "filehandle"-ström.