La respuesta se cae de madura: Si el utf8_general_ci que utiliza tu tabla usa (como lo dice el manual) el charset UTF-8, la única forma en que puede entrar un dato en ella correctamente es que ese dato esté previamente convertido a UTF-8, y no puede ser de otra forma porque ese es el charset que tiene definido tu tabla...
El problema lo debes atacar de una de las dos formas:
1) Realizas la conversión en tus script antes de enviar los datos a las tablas.
2) Realizas la conversión en el INSERT y también al leerlas con SELECT, a fin de obtener los datos correctamente.
Si tu problema es que los datos los estás leyendo y aparecen mal, debes primero ver si el error es de la interfase o de la base.
Para ejemplificarlo mejor: Yo uso PHP para enviar datos a una web, cuyos campos están definidos como latin1. Para poder guardarlos y recibirlos bien debo forzosamente usar funciones de conversión, porque el envío y recepción de los datos se hacen como XML con charset UTF-8...
Ahora bien, si no uso esas conversiones en el PHP cuando leo la tabla, cuando los datos se reciben los caracteres están mal, pero si los reviso directamente con el phpMyAdmin en la web, los caracteres están bien... ¿Están bien grabados o no? Están bien. El error esta en la aplicación, no en los datos.
En síntesis: A mi entender el problema
no está en la estructura de la tabla ni en la definición de los campos (el UTF-8 soporta el cirílico). Yo sostengo que el problema está en la codificación que estás usando para enviarlos (la conexión portadora) y el modo de construir la inserción (la conversion en servidor).
Yo te sugiero que preguntes esos detalles en el Foro de PHP (
PHP - Foros del Web ), porque ellos tratan con esos problemas más habitualmente.
Temas a revisar:
10.3.6. Conjunto de caracteres y colación de la conexión 10.5. Soporte Unicode
Si revisas estos temas, verás que la conexión de transporte afecta la codificación, y además que el UTF-8
si sioporta cirilico.