When coding fails to present our information it is necessary to take a path back to the data to determine where the problem is.
When I say the way back, I want to say that we should start to review on the surface and go deeper, to refine the problem. An example of a return path would be:
Documento (HTML-Javascript-CSS, etc) > Nivel 1
Servidor (PHP u otro lenguaje) > Nivel 2
Conexión a la Base de Datos (PDO, MySQLi u otros) > Nivel 3
Configuración de la BD (MySQL u otros) > Nivel 4
I think it is an intelligent method of debugging, because in this case the data presented on our screen is taken from a database through a server language and presented on the screen. If we review in this order we will always get to the bottom of the problem , but by levels. It's logical: you can not get to the bottom without going through the surface :)
Also, here the most precious thing is the data , so the less we touch or alter it, the better. This also implies that it is very important when creating the database to properly configure the database itself, as well as each table and each column ... so we will not have to be manipulating its structure, which could be a risk especially if the database is already has information, because as we know we could lose it or cause errors in the data ... but that is another matter.
Then we start to check from the surface towards the bottom to see where the problem is.
Note: Before embarking on this return path, consider a possible revision Level 0 . It is possible that if we have worked our content in any text editor such as Notepad or others, the encoding of the document is not adequate. So, according to the editor, it would be convenient to verify the coding that has been established in our file. This is only in case we have taken the text of some editor.
This Level 0 is important, especially if we have badly configured the coding in the editor and we think we can continue to enter data in the database with a coding that is not what we need.
HTML settings
Server configuration (PHP or other)
-
In the case of PHP:
We can use mb_internal_encoding :
mb_internal_encoding("UTF-8");
Or: default_charset (Since PHP 5.6+ is established to UTF-8 by default).
ini_set("default_charset", "UTF-8");
VERY IMPORTANT NOTE: Here I am referring to a configuration
global of PHP, not to apply coding / decoding functions on data constantly, which would be an error (which many
recommend, due to ignorance, in responses to similar cases
this). When we have problems with coding at the PHP level
we solve it at the root, in the configuration, not applying solutions to
half way that will keep us enslaved by applying
Constantly functions like utf8_encode to the data.
The way you connect to the BD, setting the encoding to UTF-8
-
In the case of MySQLi
/* cambiar el conjunto de caracteres a utf8 */
if (!$mysqli->set_charset("utf8")) {
printf("Error cargando el conjunto de caracteres utf8: %s\n", $mysqli->error);
exit();
} else {
printf("Conjunto de caracteres actual: %s\n", $mysqli->character_set_name());
}
See: mysqli :: set_charset
-
In the case of PDO
We send the following attribute to the connection parameters: PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'" . Example:
$options = array(
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'"
);
try {
# Intentar la conexión
$pdo = new PDO($dsn, $usr, $pwd, $options);
}
catch (PDOException $e) {
# Escribir posibles excepciones en el error_log
error_log($e->getMessage(),0);
}
...
The coding of the data itself (which can be: a, a column of a table, b, a table of the database, c, the database in general).
I would be debugging in that order, from 1 to 4.
As you say that in some scenario is seen correctly, it seems that the problem is at level 3.
Verify that when you connect to the Database you are establishing the encoding to UTF-8.
