Tengo una tabla de nombres de personajes en una base de datos mySQL.
Estoy tratando de consultar la tabla y ordenarlos alfabéticamente por nombre.
Algunos de los personajes tienen nombres como "The Dagda" y "The" deben ignorarse, por lo que intento usar:
select character_id, name from characters where is_del=0 order by trim('The ' from name)
Lo que parece funcionar...
Algunos de los otros personajes tienen caracteres UTF-8 en sus nombres, como "Ériu".
Sin embargo, ahora, cuando se devuelve mi tabla, obtengo estas entradas "É" enumeradas entre "A" y "B".
ES DECIR:
Aengus Amergin Ériu Balor Banba, etc.
La preservación de estos caracteres UTF es de vital importancia en el front-end.
¿Alguien sabe un método en el que podría hacer que estos caracteres "É" y similares se representen como "E" para fines de clasificación, pero aún se mostrarán en el conjunto de datos como lo que realmente son?
Estoy pensando antes de preguntar esto que esto puede no ser posible, pero espero que alguien aquí haya tenido un problema similar antes y pueda tener una solución.
Gracias por adelantado.
EDITAR: cambió UTF-16 a UTF-8 (mi mal)
EDITAR @Rick James:
No pude formatear esto de manera legible en un comentario, pero el hexágono de la consulta es el siguiente:
Aengus Óg | 41656E67757320C383E2809C67
Amergin | 416D657267696E
Ériu | C383E280B0726975
Balor | 42616C6F72
banba | 42616E6261
El tercer elemento hacia abajo es Ériu: no estoy seguro de por qué se representan como se muestra arriba, pero esto es lo que se muestra a través de la interfaz de phpmyadmin cuando ejecuto la consulta select character_id, name, hex(name) from characters order by trim('The ' from name)
El nombre completo del primer personaje debe ser Aengus Óg (supongo que esto se debe nuevamente al conjunto de caracteres o la colación, pero no estoy seguro, así que pido disculpas por la ignorancia de mi parte aquí)
La "doble codificación" parece ser el problema. Discuto esto un poco en Problemas con caracteres UTF-8; lo que veo no es lo que almacené
Debería `
41 65 6E 67 75 73 20 C383 E2809C 67 Óg es hexadecimal C393 67 en UTF-8.
Latin1 hex C3 93 67 es Óg
Repita para obtener C383 E2809C 67
CONVERT(BINARY(CONVERT('Aengus Óg' USING latin1)) USING utf8mb4) --> 'Aengus Óg'Esto parece ser "doble codificación":
CONVERTIR(BINARIO(CONVERTIR(CONVERTIR(UNHEX('C383E280B0726975') USANDO utf8mb4) USANDO latin1)) USANDO utf8mb4) --> 'Ériu'
Con Ériu como paso intermedio. Esto explica por qué se clasificó con los Atléticos.
Este es un problema común. A menudo pasa desapercibido porque los navegadores "arreglan" el problema.
Experimente con SELECT contra la tabla. Si el primero funciona para ti, entonces es solo Mojibake.
SELECT CONVERT(BINARY(CONVERT(my_column USING latin1)) USING utf8mb4) FROM ... WHERE ...; Lea esas otras preguntas y respuestas para ver qué pasos salieron mal para causar el problema. Es probable que implique almacenar caracteres UTF-8 en una columna declarada latin1 .
ALTER TABLE ... CONVERT TO ... asume que los datos se almacenaron correctamente. Pero no fue así. Ahora tiene el CHARACTER SET configurado correctamente en las columnas, pero los datos en él han sido Mojibaked. Entonces, necesita algo como
UPDATE tbl SET col1 = CONVERT(BINARY(CONVERT(col1 USING latin1)) USING utf8mb4), col2 = CONVERT(BINARY(CONVERT(col2 USING latin1)) USING utf8mb4), ... ;Más sobre la corrección:http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases
¿Retroceder? Si se siente más cómodo retrocediendo antes de CONVERTIR A, entonces ignore la mayor parte de lo que dije antes, entonces necesita ALTERAR en 2 pasos después de la reversión. (Ver ese enlace de blog.)