Conversion de caracteres asiatique en ent ites HTML
7 réponses
Thief13
Bonjour à tous
Voilà, je me trouve devant un GROS problème :
Je suis en train de développer un petit CMS pour un amis japonais, même
si les fonctionnalités sont très simple, il faut que l'utilisateur
puisse écrire en français en japonais et en chinois. Changer des
caractères accentué en entités html est assez simple avec la fonction
htmlentities, seulement, ce n'est pas la meme pour les caractère
japonais et chinois... Et pour compliquer la tache, Firefox pour sa part
transforme automatiquement les caractère asiatique en entités html
($#*;) mais pas les caractère accentué, avant de les envoyer au serveur,
ce qui me pose un premier problème lors du filtrage (que j'ai plus ou
moins réussi à résoudre), mais internet explorer ne le fait pas...
Si quelqu'un connais une solution à mon problème je lui serais très
reconnaissant car ça fait bien 1 mois que je bloque là dessous et que je
fouille tout le net à ce propos sans résultat...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Je suis en train de développer un petit CMS pour un amis japonais, même si les fonctionnalités sont très simple, il faut que l'utilisateur puisse écrire en français en japonais et en chinois. Changer des caractères accentué en entités html est assez simple avec la fonction htmlentities, seulement, ce n'est pas la meme pour les caractère japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le français, probablement Shift_JIS pour le japonais et Big5 pour le chinois), ou bien de ne déclarer aucun charset et d'être obligé de passer par des entités HTML, pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande passante : un caractère japonais a besoin de deux octets en Shift_JIS, trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Je suis en train de développer un petit CMS pour un amis japonais, même
si les fonctionnalités sont très simple, il faut que l'utilisateur
puisse écrire en français en japonais et en chinois. Changer des
caractères accentué en entités html est assez simple avec la fonction
htmlentities, seulement, ce n'est pas la meme pour les caractère
japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le
français, probablement Shift_JIS pour le japonais et Big5 pour le
chinois), ou bien de ne déclarer aucun charset et d'être obligé de
passer par des entités HTML, pourquoi ne pas tout passer en UTF-8,
ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande
passante : un caractère japonais a besoin de deux octets en Shift_JIS,
trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Je suis en train de développer un petit CMS pour un amis japonais, même si les fonctionnalités sont très simple, il faut que l'utilisateur puisse écrire en français en japonais et en chinois. Changer des caractères accentué en entités html est assez simple avec la fonction htmlentities, seulement, ce n'est pas la meme pour les caractère japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le français, probablement Shift_JIS pour le japonais et Big5 pour le chinois), ou bien de ne déclarer aucun charset et d'être obligé de passer par des entités HTML, pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande passante : un caractère japonais a besoin de deux octets en Shift_JIS, trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Thief13
Je suis en train de développer un petit CMS pour un amis japonais, même si les fonctionnalités sont très simple, il faut que l'utilisateur puisse écrire en français en japonais et en chinois. Changer des caractères accentué en entités html est assez simple avec la fonction htmlentities, seulement, ce n'est pas la meme pour les caractère japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le français, probablement Shift_JIS pour le japonais et Big5 pour le chinois), ou bien de ne déclarer aucun charset et d'être obligé de passer par des entités HTML, pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande passante : un caractère japonais a besoin de deux octets en Shift_JIS, trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là. De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Je suis en train de développer un petit CMS pour un amis japonais, même
si les fonctionnalités sont très simple, il faut que l'utilisateur
puisse écrire en français en japonais et en chinois. Changer des
caractères accentué en entités html est assez simple avec la fonction
htmlentities, seulement, ce n'est pas la meme pour les caractère
japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le
français, probablement Shift_JIS pour le japonais et Big5 pour le
chinois), ou bien de ne déclarer aucun charset et d'être obligé de
passer par des entités HTML, pourquoi ne pas tout passer en UTF-8,
ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande
passante : un caractère japonais a besoin de deux octets en Shift_JIS,
trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
De plus, l'avantage d'utiliser les entitées, c'est que tout les
caractère s'affiche même quand le navigateur ne se cale pas sur le bon
charset (ce qui arrive fréquament, malgres les déclaration...)
Je suis en train de développer un petit CMS pour un amis japonais, même si les fonctionnalités sont très simple, il faut que l'utilisateur puisse écrire en français en japonais et en chinois. Changer des caractères accentué en entités html est assez simple avec la fonction htmlentities, seulement, ce n'est pas la meme pour les caractère japonais et chinois... [...]
Plutôt que de jouer avec des charsets différents (ISO-8859-1 pour le français, probablement Shift_JIS pour le japonais et Big5 pour le chinois), ou bien de ne déclarer aucun charset et d'être obligé de passer par des entités HTML, pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Note en outre que ça te permet une économie substantielle de bande passante : un caractère japonais a besoin de deux octets en Shift_JIS, trois en UTF-8, mais *huit* en entités numériques (décimales ou hexa).
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là. De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Olivier Miakinen
[...] pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8');
[...] pourquoi ne pas tout passer en UTF-8,
ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent,
vire-les.
De plus, l'avantage d'utiliser les entitées, c'est que tout les
caractère s'affiche même quand le navigateur ne se cale pas sur le bon
charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv
dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut
donc pas arriver si tu le déclares comme ceci :
header('Content-type: text/html; charset=UTF-8');
[...] pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8');
Thief13
[...] pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ? Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité. je ne sias pas trop pourquois, mais desfois, firefox (ou meme ie) reste en iso-xxx quand je consulte des pages utf8, et si les entitées sont utilisé pas de probleme, dans le cas contraire, c'est un carnage. en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
[...] pourquoi ne pas tout passer en UTF-8,
ce qui te permettrait de n'avoir jamais aucun transcodage à faire ?
Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent,
vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai
fréquament des problemes avec les site (ou les mail !) en utf8 qui
n'utilise pas les entité. je ne sias pas trop pourquois, mais desfois,
firefox (ou meme ie) reste en iso-xxx quand je consulte des pages utf8,
et si les entitées sont utilisé pas de probleme, dans le cas contraire,
c'est un carnage. en plus, si j'utilise les entitées pour les caractères
japonais, plus besoin que le système client ai la langue installé.
De plus, l'avantage d'utiliser les entitées, c'est que tout les
caractère s'affiche même quand le navigateur ne se cale pas sur le bon
charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv
dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut
donc pas arriver si tu le déclares comme ceci :
header('Content-type: text/html; charset=UTF-8');
oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
[...] pourquoi ne pas tout passer en UTF-8, ce qui te permettrait de n'avoir jamais aucun transcodage à faire ? Mais je suis DEJA en utf8, seulement, le probleme est quand meme là.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité. je ne sias pas trop pourquois, mais desfois, firefox (ou meme ie) reste en iso-xxx quand je consulte des pages utf8, et si les entitées sont utilisé pas de probleme, dans le cas contraire, c'est un carnage. en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
De plus, l'avantage d'utiliser les entitées, c'est que tout les caractère s'affiche même quand le navigateur ne se cale pas sur le bon charset (ce qui arrive fréquament, malgres les déclaration...)
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Olivier Miakinen
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque d'annonce du jeu de caractères utilisé.
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le numéro 37253 soit transmis dans une entité numérique décimale ou une entité numérique hexadécimale ou en UTF-8, le système a tout autant besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent,
vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai
fréquament des problemes avec les site (ou les mail !) en utf8 qui
n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque
d'annonce du jeu de caractères utilisé.
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères
japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le
numéro 37253 soit transmis dans une entité numérique décimale ou une
entité numérique hexadécimale ou en UTF-8, le système a tout autant
besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv
dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut
donc pas arriver si tu le déclares comme ceci :
header('Content-type: text/html; charset=UTF-8');
oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du
serveur, éventuellement répertoire par répertoire (fichier .htaccess)
qui doit inclure le charset.
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque d'annonce du jeu de caractères utilisé.
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le numéro 37253 soit transmis dans une entité numérique décimale ou une entité numérique hexadécimale ou en UTF-8, le système a tout autant besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
Thief13
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les. C'est un joli concept, mais je t'assure que pour ma pare, j'ai
fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque d'annonce du jeu de caractères utilisé.
là, je bosse en locale, mais si je tombe sur un site comme ça, je te le
fait parvenire
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le numéro 37253 soit transmis dans une entité numérique décimale ou une entité numérique hexadécimale ou en UTF-8, le système a tout autant besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Bin, je me fourvois peut être, mais j'ai deux PC, un avec les police asiatique installé, l'autre pas. quand j'utilise les entités, ça s'affiche nikel sur les deux. je vien de vérifier... Quelque chose m'échappe peut être... peut etre est-ce dût au fait que sur le pc qui n'a pas les police, elle y ont été et windows ne les a pas désinstallé correctement, toujours est il que sans les entité, ça ne s'affiche que sur le pc qui a les polices installés.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé etre portable et doit pouvoir marcher sur des hebergement mutualisé gratuit... qui n'accepte pas forcément les htaccess ! C'est pour ça que je préfère utiliser les entités. de plus tout dans tous les livres sur le html que j'ai put suivre, il est fortement recommender de faire comme ça. pas un seul dit que c'est mieux de ce passer des entités et de configurer le charset avec des htaccess...
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent,
vire-les.
C'est un joli concept, mais je t'assure que pour ma pare, j'ai
fréquament des problemes avec les site (ou les mail !) en utf8 qui
n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque
d'annonce du jeu de caractères utilisé.
là, je bosse en locale, mais si je tombe sur un site comme ça, je te le
fait parvenire
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères
japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le
numéro 37253 soit transmis dans une entité numérique décimale ou une
entité numérique hexadécimale ou en UTF-8, le système a tout autant
besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Bin, je me fourvois peut être, mais j'ai deux PC, un avec les police
asiatique installé, l'autre pas. quand j'utilise les entités, ça
s'affiche nikel sur les deux. je vien de vérifier... Quelque chose
m'échappe peut être... peut etre est-ce dût au fait que sur le pc qui
n'a pas les police, elle y ont été et windows ne les a pas désinstallé
correctement, toujours est il que sans les entité, ça ne s'affiche que
sur le pc qui a les polices installés.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv
dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut
donc pas arriver si tu le déclares comme ceci :
header('Content-type: text/html; charset=UTF-8');
oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du
serveur, éventuellement répertoire par répertoire (fichier .htaccess)
qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé
etre portable et doit pouvoir marcher sur des hebergement mutualisé
gratuit... qui n'accepte pas forcément les htaccess ! C'est pour ça que
je préfère utiliser les entités. de plus tout dans tous les livres sur
le html que j'ai put suivre, il est fortement recommender de faire comme
ça. pas un seul dit que c'est mieux de ce passer des entités et de
configurer le charset avec des htaccess...
En UTF-8 tu n'as pas besoin des entités du tout. Si elles t'embêtent, vire-les. C'est un joli concept, mais je t'assure que pour ma pare, j'ai
fréquament des problemes avec les site (ou les mail !) en utf8 qui n'utilise pas les entité.
Donne-nous une URL, je suis prêt à parier que c'est à cause du manque d'annonce du jeu de caractères utilisé.
là, je bosse en locale, mais si je tombe sur un site comme ça, je te le
fait parvenire
je ne sias pas trop pourquois, [...]
Moi je sais. Voir ci-dessus.
en plus, si j'utilise les entitées pour les caractères japonais, plus besoin que le système client ai la langue installé.
Ça, excuse-moi d'être aussi franc, mais c'est n'importe quoi. Que le numéro 37253 soit transmis dans une entité numérique décimale ou une entité numérique hexadécimale ou en UTF-8, le système a tout autant besoin de savoir quel caractère est au numéro 37253 pour l'afficher.
Bin, je me fourvois peut être, mais j'ai deux PC, un avec les police asiatique installé, l'autre pas. quand j'utilise les entités, ça s'affiche nikel sur les deux. je vien de vérifier... Quelque chose m'échappe peut être... peut etre est-ce dût au fait que sur le pc qui n'a pas les police, elle y ont été et windows ne les a pas désinstallé correctement, toujours est il que sans les entité, ça ne s'affiche que sur le pc qui a les polices installés.
Ça, ça peut arriver quand tu déclares le charset par un META http-equiv dans la page HTML au lieu de le mettre dans les entêtes HTTP. Ça ne peut donc pas arriver si tu le déclares comme ceci : header('Content-type: text/html; charset=UTF-8'); oui, mais toutes mes pages ne sont pas forcéments généré en php.
certaines sont des pages html qui contiennent quelques scripts en php.
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé etre portable et doit pouvoir marcher sur des hebergement mutualisé gratuit... qui n'accepte pas forcément les htaccess ! C'est pour ça que je préfère utiliser les entités. de plus tout dans tous les livres sur le html que j'ai put suivre, il est fortement recommender de faire comme ça. pas un seul dit que c'est mieux de ce passer des entités et de configurer le charset avec des htaccess...
Olivier Miakinen
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé etre portable et doit pouvoir marcher sur des hebergement mutualisé gratuit... qui n'accepte pas forcément les htaccess !
J'écrivais « *éventuellement* répertoire par répertoire », et donc par exemple via un .htaccess . Mais le plus simple est bien sûr de définir le charset de manière globale.
Un hébergement, surtout mutualisé, doit permettre de définir le charset pour les pages statiques d'une façon ou d'une autre -- et de l'envoyer dans les entêtes HTTP. Que ce soit par config globale, par .htaccess, ou par toute autre méthode particulière, ça n'a pas d'importance. Mais il *faut* que ce soit possible. Si cet hébergement ne le permet pas, fût-il gratuit, il est à jeter aux orties (et à vouer à l'opprobre publique).
[...] de plus tout dans tous les livres sur le html que j'ai put suivre, il est fortement recommender de faire comme ça. pas un seul dit que c'est mieux de ce passer des entités et de configurer le charset avec des htaccess...
C'est dur, mais il faut se rendre à l'évidence : tout ce qui est écrit n'est pas forcément vrai. Il y a même des c**neries qui sont imprimées et vendues.
Note que pour les bouquins écrits en français ou en anglais cela peut même se comprendre. Mais je serais bien étonné que les bouquins écrits en japonais recommandent d'utiliser les entités pour tout.
Toi par exemple, accepterais-tu d'écrire tes pages HTML en mettant : « Bienvenue sur ma page » au lieu de : « Bienvenue sur ma page » ???
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du
serveur, éventuellement répertoire par répertoire (fichier .htaccess)
qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé
etre portable et doit pouvoir marcher sur des hebergement mutualisé
gratuit... qui n'accepte pas forcément les htaccess !
J'écrivais « *éventuellement* répertoire par répertoire », et donc par
exemple via un .htaccess . Mais le plus simple est bien sûr de définir
le charset de manière globale.
Un hébergement, surtout mutualisé, doit permettre de définir le charset
pour les pages statiques d'une façon ou d'une autre -- et de l'envoyer
dans les entêtes HTTP. Que ce soit par config globale, par .htaccess, ou
par toute autre méthode particulière, ça n'a pas d'importance. Mais il
*faut* que ce soit possible. Si cet hébergement ne le permet pas, fût-il
gratuit, il est à jeter aux orties (et à vouer à l'opprobre publique).
[...] de plus tout dans tous les livres sur
le html que j'ai put suivre, il est fortement recommender de faire comme
ça. pas un seul dit que c'est mieux de ce passer des entités et de
configurer le charset avec des htaccess...
C'est dur, mais il faut se rendre à l'évidence : tout ce qui est écrit
n'est pas forcément vrai. Il y a même des c**neries qui sont imprimées
et vendues.
Note que pour les bouquins écrits en français ou en anglais cela peut
même se comprendre. Mais je serais bien étonné que les bouquins écrits
en japonais recommandent d'utiliser les entités pour tout.
Toi par exemple, accepterais-tu d'écrire tes pages HTML en mettant :
« Bienvenue
sur ma page »
au lieu de :
« Bienvenue sur ma page »
???
Ce n'est pas une excuse. Pour les pages statiques, c'est la config du serveur, éventuellement répertoire par répertoire (fichier .htaccess) qui doit inclure le charset.
Ce n'est pas une solution acceptable. je devellope un CMS qui est sensé etre portable et doit pouvoir marcher sur des hebergement mutualisé gratuit... qui n'accepte pas forcément les htaccess !
J'écrivais « *éventuellement* répertoire par répertoire », et donc par exemple via un .htaccess . Mais le plus simple est bien sûr de définir le charset de manière globale.
Un hébergement, surtout mutualisé, doit permettre de définir le charset pour les pages statiques d'une façon ou d'une autre -- et de l'envoyer dans les entêtes HTTP. Que ce soit par config globale, par .htaccess, ou par toute autre méthode particulière, ça n'a pas d'importance. Mais il *faut* que ce soit possible. Si cet hébergement ne le permet pas, fût-il gratuit, il est à jeter aux orties (et à vouer à l'opprobre publique).
[...] de plus tout dans tous les livres sur le html que j'ai put suivre, il est fortement recommender de faire comme ça. pas un seul dit que c'est mieux de ce passer des entités et de configurer le charset avec des htaccess...
C'est dur, mais il faut se rendre à l'évidence : tout ce qui est écrit n'est pas forcément vrai. Il y a même des c**neries qui sont imprimées et vendues.
Note que pour les bouquins écrits en français ou en anglais cela peut même se comprendre. Mais je serais bien étonné que les bouquins écrits en japonais recommandent d'utiliser les entités pour tout.
Toi par exemple, accepterais-tu d'écrire tes pages HTML en mettant : « Bienvenue sur ma page » au lieu de : « Bienvenue sur ma page » ???
