escribir en español con eñes y tildes es muy fácil, pero para ello debes tener un CHARSET y una COLLATION que lo permitan. Yo uso charset utf8 y collation utf8_spanisch_ci, pero seguro que lo logras con el CHARSET latin1 y la collation latin1_spanisch_ci. No puedes aplicar a las tablas y a los campos una collation que no tenga nada que ver con el charset elegido.
Pero este no es el único problema. También tienes que hacer que se entiendan tu servidor web APACHE y tu base de datos. Por otra parte, los datos que muestras de tu base de datos, los muestras en un archivo PHP o HTML, todo lo cual te obliga a usar esa misma codificación en los archivos PHP y HTML, tanto para introducir datos como para mostrarlos. Además, si eliges UTF8, tu navegador debe tener seleccionado un tipo de letra utf8.
Quiero decir con esto que tu problema, si has elegido un charset de esos y su cotejamiento (collation) adecuado para el español, el problema ahora está probablemente en hacer que tu servidor se entere de eso, pues creo que trabaja por defecto con ISO-8859-1. Además con unos meta que indiquen el charset y guardando los archivos php y html como utf8, en caso de que sea ese el charset elegido, se resolverá parte del problema, si no todo él.
Te daré algunas indicaciones para hacerlo con utf8 (pido perdón al moderador por incluir recomendaciones sobre html y PHP (es el programa que yo uso), pero lo considero en este caso necesario, solicitándole que quite el código que no considere necesario [he reportado el post])
BASE DE DATOS
1) Cuando creo una base a través de PHPMyAdmin y quiero que contenga campos en utf-8, selecciono dicho charset, poniendo especial atención en que el cotejamiento de las conexiones MySQL sea en utf_unicode_ci, la tabla o tablas con cotejamiento utf_unicode_ci, los campos con cotejamiento utf_unicode_ci (son los que yo utilizo), aunque sólo aquellos en que voy a introducir utf-8.
ARCHIVOS HTML Y PHP
2) Las páginas con terminación html y php deben ser guardadas con formato utf-8 (ojo, porque algunos editores no lo permiten). Yo uso NotePad++ que en formato te permite elegir el que quieres. Si se trabaja con sesiones, hay que guardar como ANSI y mostrar utf8 sin BOM, para evitar que haya algo antes de los header.
3) En el archivo con terminación html debes escribir este meta <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
CONEXIÓN MYSQL MEDIANTE PHP
4) Cuando hagas la conexión a la base de datos MySQL, deberás escribir tras la conexión y justo después de seleccionar la base: mysql_query ("SET NAMES 'utf8'"), como en el ejemplo.
<?php
$link = mysql_connect ('localhost', 'root', 'tuclave');
if (!$link){
echo 'error al conectar';
die;
}
$bd = mysql_select_db('mibase');
if (!$bd){
echo 'error al seleccionar la base d datos';
die;
}
mysql_query ("SET NAMES 'utf8'");
?>
NAVEGADOR
5) Y, finalmente, debemos tener al menos una fuente utf8 y ponerla como fuente para nuestro navegador. Puedes en la programación poner una lista de familias de letras utf8 para que vaya eligiendo entre ellas. Y creo que si no encuentra una de ellas, seleccionará la letra unicode con la que cuente.
Hay algunos truquillos más, como codificar como utf-8 un archivo de texto (guardándolo como con ese formato) cuando vaya a importarse a una base de datos con character set utf-8. Si no lo haces, observarás que las palabras son cortadas por donde hay caracteres con acento o eñes.
Pero todavía hay más: el modo en que el paso de la información de AJAX a través del navegador o navegadores (hay diferencias).
Otra situación extraña que me ha ocurrido es que se me entregue una base con una codificación que no es la adecuada a la naturaleza de los datos con los que quiero trabajar. Pondré un ejemplo: se me entregó una base codificada en ISO-8859-1, pero yo necesitaba codificación UTF-8. No me quisieron cambiar la codificación. Es verdad, como se me dijo, que puedo almacenar los datos en utf8 en las tablas y campos, y así lo hice, pero la collation no funcionaba. La solución tendría que haber sido exportar los datos y luego crear una base con la codificación utf8 e importarlos, pero al no permitírseme me vi obligado a crear campos de orden y consulta específicos, con programación.
*********
PORQUE EL COTEJAMIENTO latin1_swedish_ci ES EL QUE ESTA POR DEFECTO
Por lo que yo puedo ver, latin1 fue el juego de caracteres predeterminado en los tiempos pre-multibyte (MySQL 4.1 hacia atras)y su cotejamiento por defecto era latin1_swedish_ci y parece que ha sido continuado, probablemente por razones de compatibilidad hacia abajo (porejemplo, para antiguas sentencias CREATE en las que no especificaron una cotejamiento).
En cuanto a por qué sueco, sólo puedo suponer que es porque MySQL es de una compañía sueca. No puedo ver ninguna otra razón para elegir este cotejamiento
**************
OJO AL COLLATION LO TRADUCEN COMO COTEJAMIENTO O COLACION
***********
CREATE TABLE `visitas_tmp` (
`id` int(11) default NULL,
`user_agent` varchar(255) default NULL,
`permalink` varchar(255) default NULL,
`created_at` datetime default NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
*******
Qué es eso de ASCII, ISO-8859-1 y UTF-8?
Los tres estándares representan el esfuerzo informático por brindar un sistema de codificación que permita representar los caracteres que se usan en todos los idiomas. El primer esfuerzo lo hizo ASCII y fue para el idioma inglés (128 caracteres), luego ante su insuficiencia para representar otros caracteres como los latinos por ejemplo, nace ISO-8859-1 (tambien llamado LATIN-1 ó ASCII extendido) pero debido a que no podía representar caracteres de otros idiomas aparece el estándar UNICODE (del cual es parte UTF-8).
Un buen detalle a saber es que mientras ISO-8859-1 usa un byte para representar un caracter, no pasa lo mismo con UTF-8 que puede usar hasta 4 bytes ya que es de longitud variable. Esto hace que una base de datos en UTF-8 sea un "poquito" mas pesada que una en ISO-8859-1. Esto sucede porque -por ejemplo- mientras ISO-8859-1 usa un byte para representar la letra ñ, UTF-8 usa dos bytes. Esto podríamos comprobarlo generando un documento con puras eñes en formato ISO-8859-1 y luego convirtiendolo a formato UTF-8, comprobarán que pesa... el doble!!!
Hay un tema más y es que muchas veces cuando vamos a migrar información nos encontramos con caracteres ISO-8859-1 (los correspondientes a los números 147, 148, 149, 150, 151 y 133) que no pueden verse en un editor UNIX pero si en un browser HTML. En ese caso si queremos reemplazar los caracteres podemos usar la siguiente instrucción
str_replace(array(chr(147), chr(148), chr(149), chr(150), chr(151), chr(133), '"', '•'), array(chr(34), chr(34), chr(45), chr(45), chr(45), '...', chr(34), chr(45)), $field);
donde 34, 45 son los equivalentes. Para más información se puede ver una tabla como
**************************************************************************************************http://cambio.name/personal/content/%C2%BFqu%C3%A9-es-eso-de-ascii-iso-8859-1-y-utf-8
************************************************************************
Los charset de mysql, phpmyadmin y el html del browser son distintos, debes poner los tres por separado, a que sea iguales para que funcione.
************************************************************************
Los charset de mysql, phpmyadmin y el html del browser son distintos, debes poner los tres por separado, a que sea iguales para que funcione.
************************************************************************
"Skaparate", yo utilizo el editor HTML-Kit, por lo tanto puedo escoger la codificación.
Deduzco, según tu explicación que si uso "iso-8859-1":
1.- Cotejamiento para las conexiones al servidor y para las tablas: "latin1_general_ci"
2.- Cotejamiento de campo: "latin1_spanish_ci"
3.- Justa tras la conexión con el servidor, colocar esta sentencia: "mysql_query("SET NAMES 'latin1'")"
4.- Y el meta: "<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />"
I si uso "utf-8":
1.- Cotejamiento para las conexiones al servidor y para las tablas: "utf8_general_ci"
2.- Cotejamiento de campo: "utf8_spanish_ci"
3.- Justo tras la conexión con el servidor, colocar esta sentencia: "mysql_query("SET NAMES 'utf8'")"
4.- Y el meta: "<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">"
He leido en alguna parte que el cotejamiento para las conexiones al servidor y para las tabals tenia que usar: "utf8_unicode_ci".
Ayer al acabar el dia, los de "SERED" no se que hicieron, pero arreglaron el problema con el codigo HTML, pero volvieron a desarreglar el texto extraido de la base de datos con PHP.
Lo que no entiendo, es porque hasta hace una semana todo funcionava correctamente, y de golpe y porrazo todo queda liado ?
Podeis darme mas ideas, y si puede ser mas específicas, por favor ?
Gracias por vuestra ayuda.
*********
http://foros.cristalab.com/utf-8-y-cotejamiento-en-la-db-t24674/
ALTER DATABASE 'mi_tabla' DEFAULT CHARACTER SET utf8 COLLATE utf8_bin
********
********
http://blog.soporteti.net/programacion-2/mysql-charset-y-collation/
MySQL – Charset y Collation
En MySQL vienen definidos unos valores por defecto para charset y para collation que en ocasiones puede darnos sorpresas al importar archivos SQL apareciendo caracteres extraños en lugar de los que esperábamos ver.
Por charset se entiende el juego de caraceteres que utiliza el servidor MySQL, mientras que por collation se entiende las reglas de comparación para ordenar alfabéticamente ese juego de caracteres.
En mi servidor(YO SE REFERIRA POR DEFAULT) se han definido por defecto utf-8 para charset y latin1_swedish_ci para el collation (los autores de MySQL son suecos).
Nosotros definiremos latin1(iso-8859-1) para el charset y latin1_spanish_ci para collation.
Editamos el archivo de configuración de MySQL que se suele llamar my.ini o my.cnf dependiendo del sistema operativo y añadimos los siguientes valores después de la sección [mysqld]:
character-set-server=latin1
collation-server=latin1_spanish_ci
default-character-set=latin1
default-collation=latin_spanish_ci
A continuación reiniciamos el servidor y así se habrán establecido los nuevos valores por defecto.
Para asegurarnos, especificamos los charsets en la configuración de PHP y Apache.
Editamos php.ini y modificamos la línea:
default_charset="iso-8859-1"
Editamos httpd.conf y modificamos la línea. Si comentamos la línea tomará el charset por defecto del navegador:
AddDefaultCharset ISO-8859-1***********utf8_spanish_ci vs utf8_spanish2_ci
Las colaciones utf8_spanish_ci y utf8_spanish2_ci se corresponden con español moderno y español tradicional respectivamente. En ambas colaciones , 'ñ' es una letra independiente, entre 'n' y 'o'. Además, para español tradicional 'ch' es una letra, ordenada entre 'c' y d, y 'll' es una letra que se coloca entre 'l' y 'm'.
Recomendado: utf8_spanish_ci.
**************
DIFERENCIA ENTRE usar utf8_spanish_ci utf8_general_ci
MEDIANTE EL SIGUIENTE PROBLEMA (Y EL PARRAFO ANTERIOR) QUEDARA BIEN CLARO LA DIFERENCIA DE USAR UNO O EL OTRO
Creo haber detectado un error en el orden por apellidos de los listados de los alumnos en la versión 1.9.x por ejemplo, "Cañizares" queda delante de "Cano" no sé si esto ocurre en otras plataformas y debo pasarlo al Tracker o se puede resolver de algún modo. Gracias.
RESPUESTA
Enrique,
seguramente estás usando MySQL con codificación utf8 y colación utf8_general_ci o utf8_unicode_ci.
En este caso, la 'ñ' se considera equivalente a la 'n' a efectos de ordenación. Si quieres que se distinga, tendrías que usar utf8_spanish_ci outf8_spanish_ci2 (más detalles sobre la diferencia entre ambos al final de la página http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html)
Saludos. Iñaki.
https://moodle.org/mod/forum/discuss.php?d=170189
-------------
POR OTRO LADO:
Conclusiones
Aunque parece ser un tema menor, la verdad es que hay harto que pensar y decidir detrás de los CHARSETs y COLLATIONs. Por el lado del CHARSET, aunque parezca como mejor opción utilizar siempre UTF8, hay casos en que resulta totalmente inútil: si queremos guardar una cadena cuyo valor sabemos que no contendrá valores distintos del alfabeto, es mejor ocupar ASCII y de esa forma estar seguros que no se pueden ingresar caracteres inválidos. Por otro lado, si estamos seguros de que nuestra aplicación nunca jamás tendrá otro idioma que no sea español, también podemos utilizar latin1, aunque hay que tener cuidado en hacer los ajustes necesarios en todos aquellos lados donde podría haber una influencia de otro set de caracteres.
El tema del COLLATION sí es un poco más extenso ya que dependerá mucho del cómo se efectúen las búsquedas y también el idioma en que estemos trabajando. MySQL asigna utf8_general_ci como COLLATION predeterminado de UTF-8, pero éste presenta algunos problemas en hebreo y en algunas localizaciones de idiomas cirílicos; principalmente bielorruso, macedonio, serbio y ucraniano; así que para estos casos resulta mejor ocupar utf8_unicode_ci, la que tampoco está exenta de polémica ya que es más lento que utf8_general_ci.
Como gran conclusión: traten de usar UTF-8 como CHARSET donde sea posible, y si quieren tener velocidad vayan por utf8_general_ci como COLLATION pero si quieren tener certeza de que todo está bien ordenado y que sea compatible con (casi) todos los idiomas del mundo ocupen utf8_unicode_ci. (YO USARE utf8_spanish_ci
EL ARCHIVO MY.INI CONTIENE ESTO
#collation_server=utf8_unicode_ci
#character_set_server=utf8
OJO OTRA COSA: Ojo que en MySQL, la codificación UTF-8 no existe! Sólo existe utf8 (en minúsculas sin raya) y por supuesto latin1, que sería el equivalente a ISO-8859-1.
http://blog.unreal4u.com/2012/08/sobre-collation-y-charset-en-mysql/
)
El tema del COLLATION sí es un poco más extenso ya que dependerá mucho del cómo se efectúen las búsquedas y también el idioma en que estemos trabajando. MySQL asigna utf8_general_ci como COLLATION predeterminado de UTF-8, pero éste presenta algunos problemas en hebreo y en algunas localizaciones de idiomas cirílicos; principalmente bielorruso, macedonio, serbio y ucraniano; así que para estos casos resulta mejor ocupar utf8_unicode_ci, la que tampoco está exenta de polémica ya que es más lento que utf8_general_ci.
Como gran conclusión: traten de usar UTF-8 como CHARSET donde sea posible, y si quieren tener velocidad vayan por utf8_general_ci como COLLATION pero si quieren tener certeza de que todo está bien ordenado y que sea compatible con (casi) todos los idiomas del mundo ocupen utf8_unicode_ci. (YO USARE utf8_spanish_ci
EL ARCHIVO MY.INI CONTIENE ESTO
#collation_server=utf8_unicode_ci
#character_set_server=utf8
OJO OTRA COSA: Ojo que en MySQL, la codificación UTF-8 no existe! Sólo existe utf8 (en minúsculas sin raya) y por supuesto latin1, que sería el equivalente a ISO-8859-1.
http://blog.unreal4u.com/2012/08/sobre-collation-y-charset-en-mysql/
http://blog.unreal4u.com/2012/08/sobre-collation-y-charset-en-mysql/
)
******************
Collations y encodes en MySQL
Ahora que empiezas un nuevo proyecto, hazte un favor y usa UTF-8 (YO COMO CHARSET) . Por cierto, desde 1994 la Asociación de Academias de la Lengua Española decidió que la CH y la LL no se tienen en cuenta como letras propias al ordenar el diccionario, por lo que la COLLATION adecuada en español es utf8_spanish_ci y NO utf8_spanish2_ci. Curiosamente, el Diccionario de la Real Academia ordenó la CH después de la C desde 1803 hasta 1994... unos poquitos años.
¿No sabes qué es una codificación de caracteres? ¿No sabes qué es una collation?
http://dev.mysql.com/doc/refman/5.0/en/charset.html
Aquí hay una buena lista de todas las collation y sus ordenaciones alfabéticas:
http://www.collation-charts.org/mysql60/by-charset.html
¿Problemas buscando cosas con eñes u ordinales (º, ª)...? Usa COLLATE utf8_bin. Si no lo usas, al buscar "º" te encontrará "º" y "o" y "ó" y "Ò"... Por ejemplo:
¿No sabes qué es una codificación de caracteres? ¿No sabes qué es una collation?
http://dev.mysql.com/doc/refman/5.0/en/charset.html
Aquí hay una buena lista de todas las collation y sus ordenaciones alfabéticas:
http://www.collation-charts.org/mysql60/by-charset.html
¿Problemas buscando cosas con eñes u ordinales (º, ª)...? Usa COLLATE utf8_bin. Si no lo usas, al buscar "º" te encontrará "º" y "o" y "ó" y "Ò"... Por ejemplo:
SELECT * FROM table WHERE field COLLATE utf8_bin LIKE '%º%';
***************
http://www.rae.es/consultas/exclusion-de-ch-y-ll-del-abecedario
Exclusión de ch y ll del abecedario
Se excluyen definitivamente del abecedario los signos ch y ll, ya que, en realidad, no son letras, sino dígrafos, esto es, conjuntos de dos letras o grafemas que representan un solo fonema. El abecedario del español queda así reducido a las veintisiete letras siguientes: a, b, c, d, e, f, g, h, i, j, k, l, m, n, ñ, o, p, q, r, s, t, u, v, w, x, y, z.El español se asimila con ello al resto de las lenguas de escritura alfabética, en las que solo se consideran letras del abecedario los signos simples, aunque en todas ellas existen combinaciones de grafemas para representar algunos de sus fonemas.La eliminación de los dígrafos ch y ll del inventario de letras del abecedario no supone, en modo alguno, que desaparezcan del sistema gráfico del español. Estos signos dobles seguirán utilizándose como hasta ahora en la escritura de las palabras españolas: el dígrafo ch en representación del fonema /ch/ (chico [chíko]) y el dígrafo ll en representación del fonema /ll/ o, para hablantes yeístas, del fonema /y/ (calle [kálle, káye]). La novedad consiste, simplemente, en que dejan de contarse entre las letras del abecedario.Al tratarse de combinaciones de dos letras, las palabras que comienzan por estos dígrafos o que los contienen no se alfabetizan aparte, sino en los lugares que les corresponden dentro de la c y de la l, respectivamente. La decisión de adoptar el orden alfabético latino universal se tomó en el X Congreso de la Asociación de Academias de la Lengua Española, celebrado en 1994, y viene aplicándose desde entonces en todas las obras académicas.- See more at: http://www.rae.es/consultas/exclusion-de-ch-y-ll-del-abecedario#sthash.RqSNK4Kn.dpuf
***********
http://manuales.guebs.com/mysql-5.0/charset.html
Hay una convención para nombres de colaciones: empiezan con el nombre del conjunto de caracteres al que están asociados, normalmente incluyen el nombre del idioma, y acaban con
*********
MySQL includes character set support that enables you to store data using a variety of character sets and perform comparisons according to a variety of collations. You can specify character sets at the server, database, table, and column level. MySQL supports the use of character sets for the
***************
http://softwareyotrasdesvirtudes.com/2012/10/09/como-modificar-tablas-a-utf8-mysql/
http://manuales.guebs.com/mysql-5.0/charset.html
Hay una convención para nombres de colaciones: empiezan con el nombre del conjunto de caracteres al que están asociados, normalmente incluyen el nombre del idioma, y acaban con
_ci(no distingue entre mayúsculas y minúsculas), _cs (distingue entre mayúsculas y minúsculas), o _bin(binario).*********
MySQL includes character set support that enables you to store data using a variety of character sets and perform comparisons according to a variety of collations. You can specify character sets at the server, database, table, and column level. MySQL supports the use of character sets for the
MyISAM, MEMORY, NDBCLUSTER, andInnoDB storage engines.***************
http://softwareyotrasdesvirtudes.com/2012/10/09/como-modificar-tablas-a-utf8-mysql/
Cómo modificar tablas a UTF8 MySQL
Imaginemos una aplicación con la base de datos de mysql. En ella editamos información por ejemplo, de usuarios.
Todo es bonito y precioso.
Hasta! que decides exportar información a csv, hacer un volcado de datos y exportarlo a otra base de datos… etc.
¿Por qué? ¡Se ven mal los acentos, ñññññ y muchos caracteres!
Si estás en este caso, es que tienes mezclados los charset. Familiarizate con COLLATION y CHARSET.
Es mejor que utilices por compatibilidad UTF8.
Mysql por defecto crea collation a ‘latin1_swedish_ci’. Para arreglar los datos deberás hacer lo siguiente:
Si lo haces desde consola:
- Modificar la tabla
ALTER TABLE `caracteristicas_subtipos`
COLLATE=’utf8_general_ci';
COLLATE=’utf8_general_ci';
- Exportar los datos por medio de inserts Hacer truncate de la tabla.
- Mediante volcado mysqldump -p –default-character-set=utf8 base_de_datos tabla_a_modificar > tabla_a_modificar.sql
- Volcar los datos.
- Mediante mysql -p base_de_datos < tabla_a_modificar.sql
Si lo haces desde una herramienta de mysql:
Cambia sólo la forma de obtener los datos. Exporta los datos a INSERTS. Haz un truncate de la tabla. Antes de volcar los inserts pon la sentencia:
set names utf8;
FAQ:
Se puede hacer aplicado a todo un esquema?: No, tendrás que hacerlo tabla por tabla. Si alguien lo ha conseguido que lo comente!! sería un gran descubrimiento!
Agradecimientos:
A @rcasas que me enseñó estas cosas tan chulas.
**************
Problemas html acentos y eñes: charset UTF-8 / ISO-8859-1
La codificación de las páginas web (charset) es un problema recurrente para los webmasters, porque:
- Depende del editor en que se haya hecho la web, si en el trabajamos por defecto en UTF-8 o ISO-8859-1. Si el archivo original estaba escrito en ISO-8859-1 y lo editamos en UTF-8, veremos los caracteres especiales mal codificados. Si guardamos ese archivo tal cual, estaremos corrompiendo la codificación original (se guardará mal, con UTF-8). Y viceversa.
- Depende de la configuración del Apache.
- Depende de si hay un archivo oculto .htaccess en el directorio raíz que sirve nuestra web (httpdocs, public_html o similar)
- Depende de si se especifica en las etiquetas META de los HTML resultantes.
- Depende de si se especifica en la cabecera de un archivo PHP.
- Depende del charset elegido en la base de datos (si se usa una base de datos para mostrar contenidos con un CMS, tal como Joomla, Drupal, phpNuke, o una aplicación propia que sea dinámica).
Por lo general, si nunca tienen que aparecer acentos o eñes en nuestra web, nos es indiferente la codificación (aunque pueden haber otros símbolos que nos fastidien). Aunque si nuestra web está en español, lo más normal es que coloquemos acentos y eñes. Para ello, el estándar HTML está preparado para colocar todos los símbolos y acentos que nos sean necesarios, codificándolos. Así, para los acentos y eñes, deberíamos colocar:
á -> á
é -> é
í -> í
ó -> ó
ú -> ú
ñ -> ñ
Variantes valenciano-catalán-balear para acentos abiertos:
à -> à
è -> è
ò -> ò
á -> á
é -> é
í -> í
ó -> ó
ú -> ú
ñ -> ñ
Variantes valenciano-catalán-balear para acentos abiertos:
à -> à
è -> è
ò -> ò
De este modo, veremos todos caracteres correctamente, independientemente del charset.
Sin embargo, puede ser tedioso para ciertos contenidos tener que ir traduciendo nosotros manualmente los caracteres. Es en estos casos donde vale la pena perder un poco de tiempo para ajustar las distintas configuraciones.
Primero, habría que determinar en nuestra web con las etiquetas META que nuestra web debe servirse en la codificación que nosotros elijamos. O sea, dentro de :
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
o bien
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
Si seguimos con el problema, Segundo, ver si por defecto tiene el servidor (apache) algún charset predefinido. Si es así, se ignorarán las etiquetas META del html.
En un servidor Linux, el archivo charset está en:
En un servidor Linux, el archivo charset está en:
/etc/apache2/conf.d/charset
también puede cambiarse en el archivo httpd.conf
Debería aparecer sólo "AddDefaultCharset off", para que haga caso de las etiquetas META (lo ideal). Podemos poner, por ejemplo, "AddDefaultCharset UTF-8", y así apache siempre emitirá las webs en UTF-8. El problema es que esto afecta a todo el servidor, y si luego tenemos alguna web que vaya a usar otra codificación tendremos un problema. Por eso, lo ideal es que esté a Off y que cada web defina cómo quiere mostrarse.
Pero puede darse el caso de que nosotros no seamos los administradores del servidor y sólo tengamos un Plesk, y no podamos acceder al archivo charset por encontrarse fuera de nuestro rango de permisos. Podemos, entonces, pedirle al administrador del servidor que coloque el parámetro anterior a Off, o bien...
Alternativa 1: Colocar un archivo .htaccess en el directorio raíz de la web
Los .htaccess son archivos de configuración que sobreescriben algunas configuraciones del apache sólo para determinados casos. Hay que tener en cuenta que estos archivos:
Los .htaccess son archivos de configuración que sobreescriben algunas configuraciones del apache sólo para determinados casos. Hay que tener en cuenta que estos archivos:
- Pueden funcionar total o parcialmente, dependiendo de la configuración del servidor (cuestión de seguridad).
- Son archivos ocultos, por lo que para verlos tenéis que tener habilitada la función "ver archivos ocultos" en vuestro programa que acceda por ftp.
Este archivo .htaccess debería tener al menos una línea de este tipo
AddDefaultCharset utf-8
Alternativa 2: Colocar una directiva en php que fuerce a mostrarse en la codificación deseada
Esto es, sólo sirve si el archivo tiene extensión ".php". Recordemos que el html y el php pueden convivir en el mismo fichero, con lo que si renombramos un ".html" a ".php", el resutlado es exactamente el mismo (si tenemos instalado el php en nuestro servidor, claro está).
En la primera línea del archivo que deseemos indicarle la codificación (o lo antes posible) deberíais colocar la siguiente cabecera:
Esto es, sólo sirve si el archivo tiene extensión ".php". Recordemos que el html y el php pueden convivir en el mismo fichero, con lo que si renombramos un ".html" a ".php", el resutlado es exactamente el mismo (si tenemos instalado el php en nuestro servidor, claro está).
En la primera línea del archivo que deseemos indicarle la codificación (o lo antes posible) deberíais colocar la siguiente cabecera:
<?php
header('Content-Type: text/html; charset=UTF-8'); ?>
Para todos los casos donde funcione el comando "AddCharset"
- Puede especificarse el charset según la extensión del archivo. Si, por ejemplo, queremos que los ".php" sean UTF-8 y los ".html" sean ISO, podemos colocar estas dos instrucciones seguidas:
- Puede especificarse el charset según la extensión del archivo. Si, por ejemplo, queremos que los ".php" sean UTF-8 y los ".html" sean ISO, podemos colocar estas dos instrucciones seguidas:
AddCharset UTF-8 .php
AddCharset ISO-8859-1 .html
AddCharset ISO-8859-1 .html
Muchisimas gracias !!! Tenia un problema ocn latin1 y con SET NAMES 'utf8' lo he podido resolver , gracias
ResponderEliminarhttps://gacetafrontal.com/biografia-de-javier-pulgar-vidal/
ResponderEliminary por todo lo que esta tenía para ofrecerle, tomando en cuenta que es, precisamente, aquí donde surge su interés por ser uno de los más grandes geógrafos,