[SOLUCIONADO] Problema con tildes y duda sobre comillas.

[harvey]

Hace tiempo solía poner las tildes con instrucciones tipo &aacute; En el código con el que estoy ahora mismo empecé omitiendola tras ver en algún artículo que ya no eran necesarias. Sin embargo ahora me encuentro que en algunas partes del código no me da problemas sin ponerles las intrucciones pero en otras si y en vez de salirme la tilde me sale código diferente. Se trata de texto dentro de código HTML metido dentro de instrucciones en PHP del tipo echo '<span>texto</span';

¿Alguna idea de que puede estar ocasionando el problema?

Otra duda, en una instrucción echo ¿qué parte poneis en comillas dobles y qué parte en comillas simples? ¿Por qué?

echo '<p class="header">Texto</p>'

o

echo "p class='header'>Texto</p>"

[Italico76]

Al comienzo debes colocar esto:

Código PHP:

<meta charset="utf-8"> 
<?php
 
    // sigues ...
 

O en caso que uses SESSIONs.......

Código PHP:

<?php session_start(); ?>
<meta charset="utf-8"> 
<?php
 
    // sigues ...
 

Si usas MVC o algun sistema de plantillas logicamente el meta-tag va en el TEMPLATE o en las VISTAS

[harvey]

Si coloco el <meta charset="utf-8"> sigo teniendo el problema pero al revés, aquellas palabras en que las tildes no me salía si lo hacen pero... aquelllas en las que salían me muestran un caracter que es recuadrito con cuatro letras pequeñitas dentro.

[Italico76]

Iniciado por harvey

Si coloco el <meta charset="utf-8"> sigo teniendo el problema pero al revés, aquellas palabras en que las tildes no me salía si lo hacen pero... aquelllas en las que salían me muestran un caracter que es recuadrito con cuatro letras pequeñitas dentro.

Deberas entonces fijarte como deben estar los tildes para que te salgan bien con esa <META> porque asi debe hacerse.

[edward1994]

Aveces a mi me sucedia lo mismo y no encontre como solucionar el problema con las tildes etc! Parecia que el problema estaba de cuando el valor era devuelto de la base de datos, Por lo que para solucionar eso, encriptaba con base64 lo que ingresaba que "Podian llevar acentos o comillas etc" y cuando lo iba a mostrar, solamente des encriptaba y listo aparecía todo perfecto.

[ocp001a]

Para poder mostrar una tilde escribiendo el código en php, el archivo debe ser guardado en codificación UTF-8 sin BOM

[Alexis88]

Iniciado por harvey

Otra duda, en una instrucción echo ¿qué parte poneis en comillas dobles y qué parte en comillas simples? ¿Por qué?

echo '<p class="header">Texto</p>'

o

echo "<p class='header'>Texto</p>"

En la wiki del foro hay un apartado en el que se trata ese tema: Uso de comillas dobles.

Saludos

[harvey]

Precisamente anoche estuve pensando eso, por los documentos en los que salian de una u otra manera las tildes, que debía ser por el formato con el que estaban guardados dichos archivos. Veo esta mañana que ese era el problema, que algunos archivos estaban guardados como ANSI y otros UTF-8 sin BOM.

Ahora voy a tener que modificar el contenido de la base de datos, que ahora sale mal en pantalla. Con solo volver a actualizar la información ya se guarda bien pero a través de phpmyadmin veo que en la base de datos aparece codificado esos caracteres. ¿Hay alguna manera de que en la base de datos se guarden estos igualmente bien (las tildes)? ¿Vale la pena?

[harvey]

Iniciado por Alexis88

En la wiki del foro hay un apartado en el que se trata ese tema: Uso de comillas dobles.

Saludos

Alexis yo para ese tipo de cosas uso sentencias tipo echo 'el valor es de '.$valor.' euros'; y en principio con sentencias tipo "el valor es de $valor euros" podria ir bien pero cuando uso HTML suelo usar los valores entre comillas dobles, para eso y para las clases de estilos. ¿Crees que valdría la pena cambiar la forma en que hago todo eso? No tengo claro que me ahorre tanto.

[Italico76]

@harvey SI es mucho el HTML que estas embebiendo, ENTONCES seria sintoma de que estas en un Template o en una Vista o que deberias hacer alrevez y embeber PHP en HTML

Entonces no te complicas tanto con las comillas dobles de los atributos HTML

[harvey]

En la base de datos tengo donde pone cotejamiento Latin1_swedish_ci ¿Debería cambiarlo a UTF8_Spanish no? ¿A spanish o a spanish 2? ¿Conseguiría asi que se me guarden los caracteres de acentos de manera legible? (Con los documentos html ya esta resuelto)

Iniciado por Italico76

@harvey SI es mucho el HTML que estas embebiendo, ENTONCES seria sintoma de que estas en un Template o en una Vista o que deberias hacer alrevez y embeber PHP en HTML

Entonces no te complicas tanto con las comillas dobles de los atributos HTML

No sé que quiere decir Template o Vista. He ido aprendiendo PHP por mi cuenta como he podido. Pero bueno, ahí vamos.

[arcanisgk122]

comillas simples: no analizan variables internas (impresión rápida)
comillas dobles: analizan variables y imprimen en contenido que guardan.(peude provocar errores)

existe una serie de reglas para evitar que te salte código raros al que estés programando en español.

por ejemplo en los códigos HTML todo archivo debe tener meta utf-8
mas sin embargo el archivo tambien debe estar guardado en UTF-8 Sin BOM(sin Bom para evitar problemas si tienes PHP embebido)

adicional a eso los Archivos CSS y javascript deberías tambien de formatearlos en UTF-8 Sin Bom ya que al fin y al cabo son archivos de textos que tengas su extensión serán interpretado por diferentes partes del motor del navegador o del servidor,

continuando con esto seria base de datos:
te recomiendo poner la base de datos en unicode_ci y luego el colation de las tablas en utf8_general_ci.

asegúrate de que todas las conexiones que hagas a la base de datos utilicen utf8 como estándar:

$dblink->query("SET NAMES 'utf8'");

trata de cumplir con estas normas y no tendrás problemas de signos raros en el código.

[harvey]

Iniciado por arcanisgk122

comillas simples: no analizan variables internas (impresión rápida)
comillas dobles: analizan variables y imprimen en contenido que guardan.(peude provocar errores)

existe una serie de reglas para evitar que te salte código raros al que estés programando en español.

por ejemplo en los códigos HTML todo archivo debe tener meta utf-8
mas sin embargo el archivo tambien debe estar guardado en UTF-8 Sin BOM(sin Bom para evitar problemas si tienes PHP embebido)

adicional a eso los Archivos CSS y javascript deberías tambien de formatearlos en UTF-8 Sin Bom ya que al fin y al cabo son archivos de textos que tengas su extensión serán interpretado por diferentes partes del motor del navegador o del servidor,

continuando con esto seria base de datos:
te recomiendo poner la base de datos en unicode_ci y luego el colation de las tablas en utf8_general_ci.

asegúrate de que todas las conexiones que hagas a la base de datos utilicen utf8 como estándar:

$dblink->query("SET NAMES 'utf8'");

trata de cumplir con estas normas y no tendrás problemas de signos raros en el código.

Disculpa mi ignorancia, entiendo que con colation te refieres a lo que a mi me sale como cotejamiento en cada campo de la tabla pero ¿como hago lo de poner la base de datos en unicode_ci?

Por otro lado, lo de las conexiones, ¿como iría eso?¿así?:

Código PHP:

function conecta() {
$mysqli = new mysqli("xxxxxxx.com", "user", "pass", "database");
$mysqli -> query("SET NAMES 'utf8'"); 
return $mysqli;
}
 

EDITO: Lo he probado y veo que si, que me todo va bien así. Aunque sigo sin entender lo de poner la base de datos en unicode_ci ¿Como se hace eso?

[arcanisgk122]

Collation se modifica en la pestaña operations de phpmyadmin al igual que las tablas...

el procedimiento seria el siguiente, creas la base de datos y las tablas vacias,

luego seleccionas la base de datos entra en la pestañas operations y cambias el collation. guardas.
luego seleccionas la tabla entra en la pestaña operations y cambias el collation. guardas.

por ultimo sin eliminar las tablas haces un update o un insert de los datos y guala debes poder usas tildes y Ñ sin ningún problema...

y lo de la conexión es exacto a como lo escribes para ti.

me dejas dicho como te fue con mi respuesta.

[alexisverano]

Iniciado por harvey

Hace tiempo solía poner las tildes con instrucciones tipo &aacute; En el código con el que estoy ahora mismo empecé omitiendola tras ver en algún artículo que ya no eran necesarias. Sin embargo ahora me encuentro que en algunas partes del código no me da problemas sin ponerles las intrucciones pero en otras si y en vez de salirme la tilde me sale código diferente. .....

Esta problematica por aca lo solucionamos aplicando tres acciones.

Base datos y tablas -> Cotejamiento: utf8_general_ci

Paginas HTML o PHP:

Código HTML:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 

Paginas de conexion a base datos:

Código PHP:

$db_host = "localhost"; 
$db_usuario = "usuario"; 
$db_password = "clave"; 
$db_basedatos = "nombreDB"; 
$mysqli = new mysqli($db_host, $db_usuario, $db_password, $db_basedatos);
$mysqli->set_charset("utf-8");
 
// Verificando la conexión
if ($mysqli->connect_error) {
   printf ("Falló la conexión a la base de datos" ."<br>");
   printf ('Error: (' . $mysqli->connect_errno . ') ' . $mysqli->connect_error);
   exit();
}
 
//Verificando el Juego de Caracteres     
if (!$mysqli->set_charset("utf8")) {
   printf("Error cargando el conjunto de caracteres utf8: %s\n", $mysqli->error);
}
 
$mysqli->close();
 

[harvey]

arcanisgk122 pero por lo que veo el colation es lo mismo tanto en las tablas como en la base de datos. Lo que no entiendo es lo que me dices de poner la base de datos en unicode_ci si las tablas las estoy poniendo en utf8_general_ci.

Poniendo las tablas y la base de datos en utf8_general_ci está funcionando bien.

[arcanisgk122]

APORTE:

Hay por lo menos dos diferencias importantes:

Precisión de la clasificación

utf8_unicode_ci se basa en el estándar Unicode para la clasificación, y clasifica con precisión en una amplia gama de idiomas.

utf8_general_ci se acerca mucho a corregir ordenación Unicode en muchos idiomas comunes, pero tiene una serie de imprecisiones en algunas lenguas de decisiones en inadecuado para la clasificación correcta en esos idiomas.

Rendimiento

utf8_general_ci es más rápido en las comparaciones y la clasificación, ya que tiene un montón de accesos directos relacionados con el rendimiento.

utf8_unicode_ci utiliza un algoritmo mucho más compleja de comparación que tiene como objetivo para la clasificación correcta de acuerdo en una amplia gama de idiomas. Esto hace que sea más lento para ordenar y comparar un gran número de campos.

Unicode define complejos conjuntos de reglas de cómo se deben ordenar caracteres. Estas normas deben tener en cuenta las convenciones específicas del lenguaje; no todo el mundo ordena sus personajes en lo que podríamos llamar "orden alfabético".

En cuanto a América (es decir, "europeo") lenguas van, no hay mucha diferencia entre la ordenación Unicode y la utf8_general_ci simplificado de clasificación en MySQL, pero todavía hay algunas diferencias:

Para ejemplos, el tipo de intercalación Unicode "ß" como "ss", y "Œ" como "OE", como las personas que utilizan esos personajes normalmente quieren, mientras que utf8_general_ci los clasifica como caracteres individuales (presumiblemente como "s" y "e", respectivamente ).

En idiomas no latinos, como los idiomas asiáticos o idiomas con alfabetos diferentes, puede haber muchas más diferencias entre Unicode clasificación y la clasificación utf8_general_ci simplificado. La idoneidad de utf8_general_ci dependerá en gran medida de la lengua utilizada. Para algunos idiomas, será totalmente insuficiente.

Algunos caracteres Unicode se definen como ignorable, lo que significa que no deben contar para el orden y la comparación deberá pasar al siguiente carácter en su lugar. utf8_unicode_ci maneja estas correctamente.

Lo que se debe utilizar?

Casi nunca hay ninguna razón para utilizar utf_general_ci más, ya hemos dejado atrás el punto en el que la velocidad de la CPU es lo suficientemente baja para que la diferencia de rendimiento sería importante. Su base de datos es casi seguro que estará limitada por muy otros cuellos de botella que esto hoy en día. La diferencia en el rendimiento es sólo va a ser medible en situaciones muy especializados, y si ése es usted, usted ya lo sabría. Si está experimentando una clasificación lento, en casi todos los casos va a ser un problema con su plan de índices / consulta. Cambio de la función de intercalación no debería ser prioritario en la lista de cosas para solucionar problemas.

Cuando originalmente escribí esta respuesta (hace más de 4 años) me dijo que si quería, podría usar utf8_general_ci mayor parte del tiempo, y sólo usar utf8_unicode_ci al ordenar iba a ser lo suficientemente importante como para justificar el costo de rendimiento. Sin embargo, el costo de rendimiento ya no es realmente relevante (y no puede haber sido en aquel entonces, tampoco). Es más importante para ordenar adecuadamente en el idioma de sus usuarios están utilizando.

Otra cosa voy a añadir es que incluso si usted sabe que su aplicación sólo es compatible con el idioma Inglés, que aún puede tener que lidiar con los nombres de las personas, que a menudo pueden contener caracteres que se utilizan en otros idiomas en las que es tan importante para ordenar correctamente . El uso de las normas de Unicode para todo, ayuda a darle la tranquilidad de que la gente Unicode muy inteligentes han trabajado muy duro para hacer la ordenación trabajo correctamente.