1630 sujets

Formats, encodage, internationalisation, XML

Encodage des pages à la création

Bonjour,

J'ai un site internet valid (W3C) XHTML 1.0 Strict!

Lorsque je passe en htlm5
<!doctype html>
<html lang="fr">
<head>
<meta charset="iso-8859-1">
<title>Mon titre</title>

J'obtiens 1 warning !
Using windows-1252 instead of the declared encoding iso-8859-1.

Étant absolument certain de ne pas avoir déclaré de : windows-1252 je me demande pourquoi.

En poursuivant mes recherches j'ai constaté dans Notepad++ que mes pages semblent être encodées en ANSI !!!

Est ce que j’obtiens ce warning à cause de ça ?

Ma petite question Smiley smile
Si je convertis toutes mes pages en UTF-8 quel genre de changement je risque d'avoir dans mes codes html et php ?

merci d'avance pour votre aide
Je te conseil de déclarer de l'utf-8 dans ta page xhtml, et dans notepad++ tu convertis en utf-8 sans BOM. Avant de sauvegarder ta page vérifie bien qu'il n'y est pas de caractères spécial qui pointe le bout de son nez. Si ce n'est pas le cas bingo ^^ Smiley langue
Merci pour cette réponse très claire au sujet de BOM.

Concernant la conversion de page Php encodées en ANSI, lorsqu'on les converties en UTF-8, quels sont les changements et risques de modification de code ?
tweb a écrit :
lt;title&gt;Mon titre&lt;/title&gt;

J'obtiens 1 warning !
Using windows-1252 instead of the declared encoding iso-8859-1.

Étant absolument certain de ne pas avoir déclaré de : windows-1252 je me demande pourquoi.


Bonjour,

Parce que vous avez utilisé des caractères non compris dans la norme ISO 8859-1 mais compris dans la norme CP-1252, qui est identique à ISO 8859-1, fors 27 caractères supplémentaires comme :

€
œ
Œ
ÿ
Ÿ
—
–
’
‘
…

Lorsque vous déclarez une page comme étant codée selon une norme (ISO 8859-1 en l’occurrence), il faut échapper (= convertir en entités, numériques de préférence) tous les caractères hors de cette norme. Donc, dans votre code, ne pas écrire € mais &#8364; et ainsi de suite.

On considère de nos jours avec raison qu'il est bien plus simple d'utiliser UTF-8. Cela oblige à l'utiliser d'un bout à l'autre de la chaîne, c'est-à-dire pas seulement dans le code (X)HTML mais aussi dans tout ce qui va servir à générer du contenu (PHP, base SQL, CSS éventuellement, etc.).
ThomasLinard a écrit :
On considère de nos jours avec raison qu'il est bien plus simple d'utiliser UTF-8. Cela oblige à l'utiliser d'un bout à l'autre de la chaîne, ...

On a la même obligation avec tous les codages de caractères, en réalité.
Avec UTF-8, on doit effectivement être vigilant à bien utiliser/déclarer de l'UTF-8 à toutes les étapes, tandis que si on utilise ISO-8859-1 (aussi appelé latin1) c'est parfois plus simple car plusieurs outils sont encore configurés par défaut pour accepter du ISO-8859-1.

Je plussoie la recommandation d'utiliser UTF-8, un codage de caractères beaucoup plus versatile que ISO-8859-1, Windows-1252 et consorts.
(Pour information, quand Notepad++ parle de ANSI, il s'agit en réalité du codage Windows-1252. "ANSI" n'est pas un alias officiel ou même logique de ce codage. Faut pas chercher à comprendre, Notepad++ est un peu couillon.)

tweb a écrit :
Concernant la conversion de page PHP encodées en ANSI, lorsqu'on les converties en UTF-8, quels sont les changements et risques de modification de code ?

Si tu passes de ISO-8859-1 ou Windows-1252 ou autre à UTF-8, pas de souci au niveau des caractères: tous ceux disponibles dans ces codages sont également disponibles en UTF-8 (qui permet de coder tous les caractères Unicode, c'est-à-dire tout). Donc tu ne risques pas de perdre des informations (caractères incompatibles), alors que ça pourrait être le cas dans le sens inverse (de UTF-8 ou UTF-16 à ISO-8859-15, par exemple).

Par contre il faut t'assurer que tu déclares bien de l'UTF-8 au navigateur web. Donc, côté HTML:
<meta charset="UTF-8">

et, si besoin, modifier la configuration de ton serveur ou dans ton fichier .htaccess pour que les en-têtes HTTP ne déclarent pas un mauvais charset mais bien de l'UTF-8, ou alors pas de charset du tout. À ce sujet: Voir et modifier les en-têtes HTTP.

Côté PHP, il faut faire attention à certaines fonctions de manipulation des chaines de caractères, qui par défaut font comme si elles travaillaient en ISO-8859-1. Si tu utilises certaines de ces fonctions, il faut leur passer un paramètre particulier pour déclarer que tes données (le contenu d'une variable par exemple) sont en UTF-8. Pour les fonctions concernées et la marche à suivre, on se réfèrera à la documentation de PHP. Si tu ne fais qu'une utilisation minimale de PHP dans tes pages, il se peut que ça ne te concerne pas du tout.
Modifié par fvsch (22 Aug 2012 - 20:03)
Bonjour,

Merci beaucoup pour la qualité de ces réponses.

Validation html 5 accepté avec le validateur w3c

Mais maintenant j'ai des points d'intérogation s'affiche à la place des accents pour les infos venant de ma base Smiley fache
exemple côte se transforme en c?te

MySQL connection collation => utf8_unicode_ci

Dans ma base côte s'écrit bien côte, pourquoi j'obtiens un point d'intérogation si mes pages sont en utf-8 ?

Je dois changer de collation ?

merci
Modifié par tweb (23 Aug 2012 - 09:42)
tweb a écrit :
pourquoi j'obtiens un point d'intérogation si mes pages sont en utf-8 ?

Le code de tes pages peut être en UTF-8, tes pages peuvent être déclarées et interprétées en UTF-8... mais si tu récupères des données que tu avais enregistrées en base en ISO-8859-1, bah tes données n'ont pas été magiquement transformées en UTF-8, d'où ce problème.

Tu n'avais pas mentionné l'existence de données en base. Une migration de base de données de ISO-8859-1 à UTF-8 ce n'est pas impossible, mais bon c'est pas anodin à réaliser non plus, et expliquer la manoeuvre dans une réponse de forum risque d'être compliqué.

À noter que s'il s'agit juste de récupérer des données (et pas d'en écrire), tu peux éventuellement conserver tes données en ISO-8859-1 (latin1), en t'assurant que tes tables/champs sont marqués en latin1 et que ta connexion est paramétrée en utf8: MySQL fera alors la conversion (latin1 vers utf8) à la volée.

Autrement, si tu es sûr que tes données sont en UTF-8 en base, ça peut être un problème de connexion (voir du côté de SET NAMES), ou bien tes tables ou champs sont tagués comme étant en latin1 et donc MySQL croit à tort que c'est du latin1 et fait une conversion latin1->utf8 qui met le bazar.
Bonjour,

Merci beaucoup pour tout ces détails

Après avoir effectué un Dump voici les Set names:
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;


J'ai vérifié chez Ovh avec PhpMyAdmin les paramètres de la base (voir image)

upload/45898-ovhphpmyad.JPG

Idem pour une table (voir image)

upload/45898-mysqlcolla.JPG

Tout semble être en UTF-8 mais côte reste c?te Smiley ohwell
tweb a écrit :
Après avoir effectué un Dump voici les Set names

Heu c'est un dump de quoi? Ce sont des instructions dans un dump de ta base? Si c'est le cas elles ne sont pas appliquées à tes connexions MySQL en général, donc pas de rapport. Et si ça fait partie de la configuration de phpMyAdmin, même histoire: ça ne s'applique pas à tes connexions.

Les seules choses qui comptent ce sont:
- La configuration du serveur (qui peut être dans /etc/my.cnf ou ailleurs, ça dépend de ton installation).
- Les instructions que tu utilises lors de l'ouverture de ta connexion depuis ton client (un script PHP par exemple peut être un client MySQL).

Quand on n'est pas soi-même administrateur système, et sachant que la plupart des serveurs MySQL sont configurés avec par défaut des connexions client-serveur en latin1, il est préférable d'utiliser l'instruction SET NAMES (ou une méthode équivalente) juste après l'ouverture de chaque connexion.

Je connais pas grand chose à PHP, mais apparemment tu dois pouvoir utiliser:
- mysqli_character_set_name() pour récupérer l'information du charset utilisé pour la connexion;
- mysqli_set_charset() pour changer le charset de la connexion.

À surveiller:
- On n'utilise pas utf8_encode et utf8_decode (parce que c'est Le Mal).
- Si on utilise certaines fonctions de manipulation de chaines de caractères, notamment htmlentities(), on veille à bien passer un paramètre pour indiquer qu'on travaille en UTF-8 (oui, PHP est ainsi fait, pas ma faute si c'est de la m... Smiley cligne ).
Modifié par fvsch (25 Aug 2012 - 13:14)
Bonjour,

Effectivement après avoir ajouté
mysql_query("SET NAMES 'utf8'");
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET COLLATION_CONNECTION = 'utf8_unicode_ci'");

dans mon code Php
function connect()


Tout s'affiche correctement Smiley langue

L'interclassement dans PhpMyadmin est resté en latin1_swedish_ci
upload/45898-Mysqlinter.JPG
Étant donné que j'aimerai tenir compte de ce qui est très bien expliqué.
fvsch a écrit :
À noter que s'il s'agit juste de récupérer des données (et pas d'en écrire), tu peux éventuellement conserver tes données en ISO-8859-1 (latin1), en t'assurant que tes tables/champs sont marqués en latin1 et que ta connexion est paramétrée en utf8: MySQL fera alors la conversion (latin1 vers utf8) à la volée.

Autrement, si tu es sûr que tes données sont en UTF-8 en base, ça peut être un problème de connexion (voir du côté de SET NAMES), ou bien tes tables ou champs sont tagués comme étant en latin1 et donc MySQL croit à tort que c'est du latin1 et fait une conversion latin1->utf8 qui met le bazar.

Est ce que je dois passer l'interclassement en utf8_unicode_ci avec PhpMyadmin ?
(Je ne suis pas en dédié, je sais que PhpMyadmin c'est pas terrible...)
Il me semble que l'interclassement a uniquement une influence sur les ORDER BY.
Mais pour éviter des problèmes dans l'avenir (migration de code, export DB) et pour que cela soit plus propre ?


Dernière petite question Smiley confused

Est ce que utf8_unicode_ci est vraiment la collation la plus permissive pour une compatibilité avec toutes sortes de caractères ?

Un très grand merci pour toutes ces explications d'une qualité exceptionnelle Smiley cligne
tweb a écrit :
L'interclassement dans PhpMyadmin est resté en latin1_swedish_ci

Donc, avec une connexion en utf8, MySQL va normalement faire des conversions à la volée.
Hypothèse: tes données en base sont en latin1, et MySQL les convertit en utf8 avant de te les envoyer. Même chose dans le sens inverse quand tu insères des données en base. Du coup, des caractères existant en UTF-8 mais pas en ISO-8859-1 ne pourront pas être stockés en base. À tester avec des caractères japonais par exemple (tu vas sur cette page par exemple et tu fais du copier-coller).

tweb a écrit :
Est ce que je dois passer l'interclassement en utf8_unicode_ci avec PhpMyadmin ?

Idéalement oui, mais si tes données en base sont en ISO-8859-1 il faudrait aussi les convertir en UTF-8, et ça c'est une autre paire de manches...

tweb a écrit :
Il me semble que l'interclassement a uniquement une influence sur les ORDER BY.

Effectivement. utf8_general_ci est plus pertinent que utf8_unicode_ci, mais moins rapide sur certaines opérations. Ça dépend donc de tes besoins de performances. En général utf8_general_ci est très bien.

tweb a écrit :
Est ce que utf8_unicode_ci est vraiment la collation la plus permissive pour une compatibilité avec toutes sortes de caractères ?

Unicode est le jeu de caractères le plus permissif (en gros, ça définit TOUS les caractères, c'est l'intérêt du truc). UTF-8 est un codage qui implémente le jeu de caractères Unicode (il y en a quelques autres, dont UTF-16, mais UTF-8 est le plus utilisé). utf8_unicode_ci est un interclassement, à ce titre il définit juste un ordre de tri des caractères, mais l'interclassement permet aussi à MySQL de savoir quel est (en théorie, car c'est juste du déclaratif...) le codage utilisé, UTF-8 en l'occurrence.
fvsch a écrit :
des caractères existant en UTF-8 mais pas en ISO-8859-1 ne pourront pas être stockés en base.

Exact Smiley rolleyes

Pour éviter des doutes avec la compatibilité de mes codes j'ai essayé d'insérer directement des caractères Japonais avec PhpMyadmin dans une table de ma base et ce n'est pas possible. C'est confirmé ma base est bien ISO-8859-1

Warning: #1366 Incorrect string value: '\xE5\x85\xA8\xE4\xBD\x93...' for column 'adresse' at row 1

fvsch a écrit :
si tes données en base sont en ISO-8859-1 il faudrait aussi les convertir en UTF-8, et ça c'est une autre paire de manches...


Pas forcément Smiley cligne

Après avoir effectué un dump de la base on peut la modifier (recherche/remplace dans un éditeur de texte) sans que cela soit trop compliqué en ajoutant ce qui se trouve caractère gras

CREATE TABLE `table_test_japonais` (
  `col1` varchar(255) [b]COLLATE utf8_unicode_ci NOT NULL,[/b]
  `col2` varchar(255) [b]COLLATE utf8_unicode_ci NOT NULL,[/b]
  `col3` varchar(255) [b]COLLATE utf8_unicode_ci NOT NULL[/b]
) ENGINE=MyISAM DEFAULT CHARSET=[b]utf8 COLLATE=utf8_unicode_ci;[/b]


Et ensuite on réimporte la base, mais c'est assez fastidieux...

On peut aussi bricoler dans PhpMyAdmin en changeant l'interclassement de chaque colonne dans une table
`MA_COLONNE` text NOT NULL,

deviendra
`MA_COLONNE` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,


Mais c'est aussi fastidieux, donc un peu n'importe quoi mais ça marche Smiley lol

Avant de faire n'importe quoi, je vais quand même attendre ton avis et tes conseils Smiley cligne


J'ajoute cette info pour ceux qui utilise Ultraedit:
Chaque nouvelle page n'est pas en UTF-8, il faut obligatoirement convertir à chaque fois !!!
L'introduction par défaut de cette possibilité à été introduite à partir de la version 16.00 en modifiant les paramètres d'origine !!!
Avancé -> Configuration -> Éditeur -> Création de nouveaux fichiers
Sans oublier de vérifier que le BOM ne soit pas coché pour l'enregistrement des fichiers
Avancé -> Configuration -> Traitement des fichiers -> Enregistrement

J'ai utilisé Ultraedit pendant 4 ans sans savoir que j'étais en ISO Smiley fache Smiley bawling
Sujet clos
Aller à