Quelqu'un a saisi un certain texte dans un fichier word, puis recopier
ces lignes dans une base mySQL. word a le défaut de transformer les
apostrophes en un caractère reconnu par word seulement.
Y a-t-il une méthode simple pour corriger ces apostrophes ?
Présentement, j'ai un htmlentities qui transforme les accents en
entités (la base mySQL est en latin-1 et tout le texte de la page
html que j'ai transformée en PHP est en UTF8). Y a-t-il une
fonction similaire pour les apostrophes ? Je suis certain que celui
qui saisit ce texte va introduire d'autres apostrophes et je pense
qu'il est plus simple de corriger au moment de l'affichage.
"Olivier Miakinen" <om+ a écrit dans le message de news:4a02ed0c$ > Le 07/05/2009 08:59, Denis Beauregard a écrit : >> >> Quelqu'un a saisi un certain texte dans un fichier word, puis >> recopier ces lignes dans une base mySQL. word a le défaut de >> transformer les apostrophes en un caractère reconnu par word >> seulement. >
J'ai le même problème avec un copier/coller de Word ou Open Office dans un champ de saisie
> Ce caractère est reconnu par d'autres logiciels que Word, même si > c'est dans un jeu de caractères propriétaire (CP1252 de Microsoft) : > http://www.miakinen.net/vrac/charsets/?or=4&pr6.
Cette page est superbe !
J'ai cherché cette page un long moment un jour sans jamais la trouver... :(
Je vais essayer de mettre l'adresse dans un coin.
>> Y a-t-il une méthode simple pour corriger ces apostrophes ? >> >> Présentement, j'ai un htmlentities qui transforme les accents en >> entités (la base mySQL est en latin-1 et tout le texte de la page >> html que j'ai transformée en PHP est en UTF8). Y a-t-il une >> fonction similaire pour les apostrophes ?
Je m'aperçois au fil de cette discussion que je dois avoir tout faux depuis des années !!! Mes méthodes de programmation ont été acquise il y a 40 ans et celles d'internet il y a12 ans. Il va donc falloir que je reprenne tous mes basiques à zéro, en effet depuis que je programme en php/mySQL j'ai fait moyennement attention à toutes ces questions et j'ai paramétré mySQL au petit bonheur-la-chance en tâtonnant pour voir quel était le meilleur résultat sur les apostrophes, les euros, le oe ae liés, etc. Mes paramètres interclassement sont en général "latin_1_swedish_ci " chez OVH ou "latin_general_ci " chez online.
ça, ç'est le stockage (je crois). Mais le client peut très bien discuter avec la bd en utf8.
Entre le charset du serveur, de la base, de la table, du client, on s'y perd...
La liste est la: SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
Je lance toujours juste après la connexion à la base: SET NAMES 'charset_name' SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre sur le tri.
Mes prgramme php déclarent ceci : <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
Pascal
Le 09 May 2009 11:11:29 GMT,
"Bernard" <bernard.lelann@laposte.net> a écrit :
Bonjour,
"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de
news:4a02ed0c$1@meta.neottia.net...
> Le 07/05/2009 08:59, Denis Beauregard a écrit :
>>
>> Quelqu'un a saisi un certain texte dans un fichier word, puis
>> recopier ces lignes dans une base mySQL. word a le défaut de
>> transformer les apostrophes en un caractère reconnu par word
>> seulement.
>
J'ai le même problème avec un copier/coller de Word ou Open Office
dans un champ de saisie
> Ce caractère est reconnu par d'autres logiciels que Word, même si
> c'est dans un jeu de caractères propriétaire (CP1252 de Microsoft) :
> http://www.miakinen.net/vrac/charsets/?or=4&pr6.
Cette page est superbe !
J'ai cherché cette page un long moment un jour sans jamais la
trouver... :(
Je vais essayer de mettre l'adresse dans un coin.
>> Y a-t-il une méthode simple pour corriger ces apostrophes ?
>>
>> Présentement, j'ai un htmlentities qui transforme les accents en
>> entités (la base mySQL est en latin-1 et tout le texte de la page
>> html que j'ai transformée en PHP est en UTF8). Y a-t-il une
>> fonction similaire pour les apostrophes ?
Je m'aperçois au fil de cette discussion que je dois avoir tout faux
depuis des années !!!
Mes méthodes de programmation ont été acquise il y a 40 ans et celles
d'internet il y a12 ans.
Il va donc falloir que je reprenne tous mes basiques à zéro,
en effet depuis que je programme en php/mySQL j'ai fait moyennement
attention
à toutes ces questions et j'ai paramétré mySQL au petit
bonheur-la-chance en tâtonnant pour voir quel était le meilleur
résultat sur les apostrophes, les euros,
le oe ae liés, etc.
Mes paramètres interclassement sont en général "latin_1_swedish_ci "
chez OVH
ou "latin_general_ci " chez online.
ça, ç'est le stockage (je crois). Mais le client peut très bien discuter
avec la bd en utf8.
Entre le charset du serveur, de la base, de la table, du client, on s'y
perd...
La liste est la:
SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
Je lance toujours juste après la connexion à la base:
SET NAMES 'charset_name'
SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre
sur le tri.
Mes prgramme php déclarent ceci :
<meta http-equiv="content-Type" content="text/html;
charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
"Olivier Miakinen" <om+ a écrit dans le message de news:4a02ed0c$ > Le 07/05/2009 08:59, Denis Beauregard a écrit : >> >> Quelqu'un a saisi un certain texte dans un fichier word, puis >> recopier ces lignes dans une base mySQL. word a le défaut de >> transformer les apostrophes en un caractère reconnu par word >> seulement. >
J'ai le même problème avec un copier/coller de Word ou Open Office dans un champ de saisie
> Ce caractère est reconnu par d'autres logiciels que Word, même si > c'est dans un jeu de caractères propriétaire (CP1252 de Microsoft) : > http://www.miakinen.net/vrac/charsets/?or=4&pr6.
Cette page est superbe !
J'ai cherché cette page un long moment un jour sans jamais la trouver... :(
Je vais essayer de mettre l'adresse dans un coin.
>> Y a-t-il une méthode simple pour corriger ces apostrophes ? >> >> Présentement, j'ai un htmlentities qui transforme les accents en >> entités (la base mySQL est en latin-1 et tout le texte de la page >> html que j'ai transformée en PHP est en UTF8). Y a-t-il une >> fonction similaire pour les apostrophes ?
Je m'aperçois au fil de cette discussion que je dois avoir tout faux depuis des années !!! Mes méthodes de programmation ont été acquise il y a 40 ans et celles d'internet il y a12 ans. Il va donc falloir que je reprenne tous mes basiques à zéro, en effet depuis que je programme en php/mySQL j'ai fait moyennement attention à toutes ces questions et j'ai paramétré mySQL au petit bonheur-la-chance en tâtonnant pour voir quel était le meilleur résultat sur les apostrophes, les euros, le oe ae liés, etc. Mes paramètres interclassement sont en général "latin_1_swedish_ci " chez OVH ou "latin_general_ci " chez online.
ça, ç'est le stockage (je crois). Mais le client peut très bien discuter avec la bd en utf8.
Entre le charset du serveur, de la base, de la table, du client, on s'y perd...
La liste est la: SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
Je lance toujours juste après la connexion à la base: SET NAMES 'charset_name' SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre sur le tri.
Mes prgramme php déclarent ceci : <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
Pascal
Bernard
Bonjour,
Merci Pascal,
Entre le charset du serveur, de la base, de la table, du client, on s'y perd...
La liste est la: SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
J'avais vu sa petite soeur française http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html mais j'ai mal compris ce qu'est la "collation" ... et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une requête de recherche avec des mots-clés accentués du type LIKE '%mon mot accentué%' car au départ dans le champ de saisie-client il y a "mon mot accentué" et dans la base du serveur soit "mon mot accentué" soit "mon mot accentu´" soit même parfois "mon mot accentu?"
Je vais me remettre sur l'ouvrage en essayant SET NAMES 'charset_name' et SET CHARACTER SET charset_name
:->(
Je lance toujours juste après la connexion à la base: SET NAMES 'charset_name' SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre sur le tri.
Mes prgramme php déclarent ceci : <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Bernard
Bonjour,
Merci Pascal,
Entre le charset du serveur, de la base, de la table, du client, on s'y
perd...
La liste est la:
SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
J'avais vu sa petite soeur française
http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html
mais j'ai mal compris ce qu'est la "collation" ...
et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une requête de
recherche avec des mots-clés accentués du type LIKE '%mon mot accentué%'
car au départ dans le champ de saisie-client il y a "mon mot accentué"
et dans la base du serveur
soit "mon mot accentué"
soit "mon mot accentu´"
soit même parfois "mon mot accentu?"
Je vais me remettre sur l'ouvrage en essayant
SET NAMES 'charset_name' et SET CHARACTER SET charset_name
:->(
Je lance toujours juste après la connexion à la base:
SET NAMES 'charset_name'
SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre
sur le tri.
Mes prgramme php déclarent ceci :
<meta http-equiv="content-Type" content="text/html;
charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Entre le charset du serveur, de la base, de la table, du client, on s'y perd...
La liste est la: SHOW VARIABLES LIKE "%character_set%";
C'est expliqué la: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
J'avais vu sa petite soeur française http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html mais j'ai mal compris ce qu'est la "collation" ... et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une requête de recherche avec des mots-clés accentués du type LIKE '%mon mot accentué%' car au départ dans le champ de saisie-client il y a "mon mot accentué" et dans la base du serveur soit "mon mot accentué" soit "mon mot accentu´" soit même parfois "mon mot accentu?"
Je vais me remettre sur l'ouvrage en essayant SET NAMES 'charset_name' et SET CHARACTER SET charset_name
:->(
Je lance toujours juste après la connexion à la base: SET NAMES 'charset_name' SET CHARACTER SET charset_name
Je crois que ça suffit ? Mais j'avoue que j'en suis pas sur.
Pour compliquer le tout, il y a l'interclassement qui joue entre autre sur le tri.
Mes prgramme php déclarent ceci : <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1">
Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Bernard
Pascal
Le 10 May 2009 18:09:32 GMT, "Bernard" a écrit :
J'avais vu sa petite soeur française http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html mais j'ai mal compris ce qu'est la "collation" ... et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une requête de recherche avec des mots-clés accentués du type LIKE '%mon mot accentué%' car au départ dans le champ de saisie-client il y a "mon mot accentué" et dans la base du serveur soit "mon mot accentué" soit "mon mot accentu´" soit même parfois "mon mot accentu?"
mettre des entités html dans une base, je suis pas trop pour. L'html n'est pas la seule finalité possible. Et dans le cas d'entité html, il faut bien penser à l'appliquer également à la chaine recherchée.
Si il y a é é et ? à la fois, la base est sérieusement amochée :/ Sans données cohérentes, pas possible de chercher ou de faire quoi que se soit d'ailleurs.
Avec un charset homogène de bout en bout, ça pose pas de soucis.
Je vais me remettre sur l'ouvrage en essayant SET NAMES 'charset_name' et SET CHARACTER SET charset_name
phpyadmin peut aider. sur la page d'accueil, le charset du serveur est indiqué.
Sur le mien : MySQL charset: UTF-8 Unicode (utf8) Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères bizarre d'une table utf8, j'ai un soucis.
Dans l'onglet variables, on voit aussi les different charsets avec les valeurs actuelles et les valeurs par défaut.
>> >> Mes prgramme php déclarent ceci : >> <meta http-equiv="content-Type" content="text/html; >> charset=iso-8859-1"> > > Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Pascal
Le 10 May 2009 18:09:32 GMT,
"Bernard" <bernard.lelann@laposte.net> a écrit :
J'avais vu sa petite soeur française
http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html
mais j'ai mal compris ce qu'est la "collation" ...
et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une
requête de recherche avec des mots-clés accentués du type LIKE '%mon
mot accentué%' car au départ dans le champ de saisie-client il y a
"mon mot accentué" et dans la base du serveur
soit "mon mot accentué"
soit "mon mot accentu´"
soit même parfois "mon mot accentu?"
mettre des entités html dans une base, je suis pas trop pour. L'html
n'est pas la seule finalité possible. Et dans le cas d'entité html, il
faut bien penser à l'appliquer également à la chaine recherchée.
Si il y a é é et ? à la fois, la base est sérieusement amochée :/
Sans données cohérentes, pas possible de chercher ou de faire quoi que
se soit d'ailleurs.
Avec un charset homogène de bout en bout, ça pose pas de soucis.
Je vais me remettre sur l'ouvrage en essayant
SET NAMES 'charset_name' et SET CHARACTER SET charset_name
phpyadmin peut aider. sur la page d'accueil, le charset du serveur est
indiqué.
Sur le mien : MySQL charset: UTF-8 Unicode (utf8)
Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères
bizarre d'une table utf8, j'ai un soucis.
Dans l'onglet variables, on voit aussi les different charsets avec les
valeurs actuelles et les valeurs par défaut.
>>
>> Mes prgramme php déclarent ceci :
>> <meta http-equiv="content-Type" content="text/html;
>> charset=iso-8859-1">
>
> Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http.
<?php
header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le client envoie les données des formulaire avec le charset de la page.
si le client détecte le mauvais charset, ça coince.
J'avais vu sa petite soeur française http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html mais j'ai mal compris ce qu'est la "collation" ... et, sauf si j'ai mal lu, je n'y ai pas trouvé comment faire une requête de recherche avec des mots-clés accentués du type LIKE '%mon mot accentué%' car au départ dans le champ de saisie-client il y a "mon mot accentué" et dans la base du serveur soit "mon mot accentué" soit "mon mot accentu´" soit même parfois "mon mot accentu?"
mettre des entités html dans une base, je suis pas trop pour. L'html n'est pas la seule finalité possible. Et dans le cas d'entité html, il faut bien penser à l'appliquer également à la chaine recherchée.
Si il y a é é et ? à la fois, la base est sérieusement amochée :/ Sans données cohérentes, pas possible de chercher ou de faire quoi que se soit d'ailleurs.
Avec un charset homogène de bout en bout, ça pose pas de soucis.
Je vais me remettre sur l'ouvrage en essayant SET NAMES 'charset_name' et SET CHARACTER SET charset_name
phpyadmin peut aider. sur la page d'accueil, le charset du serveur est indiqué.
Sur le mien : MySQL charset: UTF-8 Unicode (utf8) Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères bizarre d'une table utf8, j'ai un soucis.
Dans l'onglet variables, on voit aussi les different charsets avec les valeurs actuelles et les valeurs par défaut.
>> >> Mes prgramme php déclarent ceci : >> <meta http-equiv="content-Type" content="text/html; >> charset=iso-8859-1"> > > Le doubler avec l'envoie d'une entête http adequat.
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Pascal
Bernard
Bonjour,
Sur le mien : MySQL charset: UTF-8 Unicode (utf8) Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères bizarre d'une table utf8, j'ai un soucis.
moi j'ai : interclassement : utf8_general_ci c'est la même chose ?
>> >> Mes prgramme php déclarent ceci : >> <meta http-equiv="content-Type" content="text/html; >> charset=iso-8859-1"> > > Le doubler avec l'envoie d'une entête http adequat.
c'est à dire ?
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le pensais que le header php ISO-8859-1 était équivalent au meta html iso-8859-1, je me trompe ?
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Je commence à comprendre la où ça coince
Bon, j'ai encore du boulot !
merci encore
Bernard
Bonjour,
Sur le mien : MySQL charset: UTF-8 Unicode (utf8)
Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères
bizarre d'une table utf8, j'ai un soucis.
moi j'ai : interclassement : utf8_general_ci c'est la même chose ?
>>
>> Mes prgramme php déclarent ceci :
>> <meta http-equiv="content-Type" content="text/html;
>> charset=iso-8859-1">
>
> Le doubler avec l'envoie d'une entête http adequat.
c'est à dire ?
J'ai ça en entête:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http.
<?php
header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le pensais que le header php ISO-8859-1 était équivalent au meta html
iso-8859-1, je me trompe ?
Le client envoie les données des formulaire avec le charset de la page.
si le client détecte le mauvais charset, ça coince.
Sur le mien : MySQL charset: UTF-8 Unicode (utf8) Mes pages phpmyadmin sont envoyé en utf8. donc si je vois un caractères bizarre d'une table utf8, j'ai un soucis.
moi j'ai : interclassement : utf8_general_ci c'est la même chose ?
>> >> Mes prgramme php déclarent ceci : >> <meta http-equiv="content-Type" content="text/html; >> charset=iso-8859-1"> > > Le doubler avec l'envoie d'une entête http adequat.
c'est à dire ?
J'ai ça en entête: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Le pensais que le header php ISO-8859-1 était équivalent au meta html iso-8859-1, je me trompe ?
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Je commence à comprendre la où ça coince
Bon, j'ai encore du boulot !
merci encore
Bernard
Olivier Miakinen
Le 11/05/2009 21:46, Bernard répondait à Pascal (sans citer son nom) :
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Pas seulement avec Firefox : c'est dans la norme, et tous les naviga- teurs la respectent. Du moins, tous respectent le fait que l'entête HTTP est prioritaire sur la balise META.
Le pensais que le header php ISO-8859-1 était équivalent au meta html iso-8859-1, je me trompe ?
Oui et non. S'il n'y a pas de charset dans l'entête Content-Type HTTP, c'est en effet le META qui est pris en compte. Dans le cas contraire, le META est ignoré.
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Je commence à comprendre la où ça coince
Bon, j'ai encore du boulot !
Si jamais tu ne l'as jamais vu, ceci est très intéressant : http://french.joelonsoftware.com/Articles/Unicode.html
Le 11/05/2009 21:46, Bernard répondait à Pascal (sans citer son nom) :
Je parlais de l'entête http.
<?php
header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Pas seulement avec Firefox : c'est dans la norme, et tous les naviga-
teurs la respectent. Du moins, tous respectent le fait que l'entête HTTP
est prioritaire sur la balise META.
Le pensais que le header php ISO-8859-1 était équivalent au meta html
iso-8859-1, je me trompe ?
Oui et non. S'il n'y a pas de charset dans l'entête Content-Type HTTP,
c'est en effet le META qui est pris en compte. Dans le cas contraire, le
META est ignoré.
Le client envoie les données des formulaire avec le charset de la page.
si le client détecte le mauvais charset, ça coince.
Je commence à comprendre la où ça coince
Bon, j'ai encore du boulot !
Si jamais tu ne l'as jamais vu, ceci est très intéressant :
http://french.joelonsoftware.com/Articles/Unicode.html
Le 11/05/2009 21:46, Bernard répondait à Pascal (sans citer son nom) :
Je parlais de l'entête http. <?php header('Content-Type: text/html; charset=ISO-8859-1');
Avec firefox l'entête http est prioritaire sur tout le reste.
Pas seulement avec Firefox : c'est dans la norme, et tous les naviga- teurs la respectent. Du moins, tous respectent le fait que l'entête HTTP est prioritaire sur la balise META.
Le pensais que le header php ISO-8859-1 était équivalent au meta html iso-8859-1, je me trompe ?
Oui et non. S'il n'y a pas de charset dans l'entête Content-Type HTTP, c'est en effet le META qui est pris en compte. Dans le cas contraire, le META est ignoré.
Le client envoie les données des formulaire avec le charset de la page. si le client détecte le mauvais charset, ça coince.
Je commence à comprendre la où ça coince
Bon, j'ai encore du boulot !
Si jamais tu ne l'as jamais vu, ceci est très intéressant : http://french.joelonsoftware.com/Articles/Unicode.html
Bernard
> Si jamais tu ne l'as jamais vu, ceci est très intéressant : http://french.joelonsoftware.com/Articles/Unicode.html
Non, pas vu, merci, j'y vais
Bernard
> Si jamais tu ne l'as jamais vu, ceci est très intéressant :
http://french.joelonsoftware.com/Articles/Unicode.html
