# ============================ # # # # Police de Caractères # # # # ============================ # AddDefaultCharset "ISO-8859-15" AddCharset "ISO-8859-15" .php .htm .html .css .js .xml .json .rss # DefaultLanguage "fr"Comme cela est indiqué, j'utilise le jeu de caractères "ISO-8859-15" qui correspond aux langues d'Europe occidentale.
<meta charset="UTF-8">Ceci est pour le navigateur du client afin qu'il sache comment interpréter correctement le contenu du fichier index.html.
<meta charset="ISO-8859-15">
Citation
Otomatic
Pas comprise par qui ? winking smiley
Citation
Otomatic
Très très très mauvaise idée.
Citation
Otomatic
D'ailleurs, ces directives ne font pas partie de la configuration de base.
Citation
Otomatic
Cela signifie QUE TOUTES les ressources textes auxquelles elle s'applique possèdent OBLIGATOIREMENT le jeu de caractère spécifié, passant outre toute autre définition, par exemple dans une balise <meta...
Citation
Otomatic
Avec les directives telles que tu les as définies, TOUS les documents .php .htm .html .css .js .xml .json .rss seront traités en tant que documents dont le jeu de caractère est ISO-8859-15, quelles que puissent être par ailleurs une déclaration contraire dans les documents eux-mêmes.
Citation
Otomatic
TU utilises, mais est-ce que les applications dont tu te sers utilisent le même jeux de caractères, comme SqlBuddy ou PhpMyAdmin par exemple ?
Citation
Otomatic
Il suffit que le serveur génère - sans que tu le saches - une entête header("content-type:xxxxxxx; charset=utf-8" ), et la balise <meta ne sert à rien, la directive header étant prioritaire.
Citation
Otomatic
Et tu n'es pas maître des envois header(...) pour les applications que tu utilises comme SqlBuddy ou PhpMyAdmin.
Citation
Otomatic
NON, NON, et NON et RE-NON !
Ça, c'était du temps de HTML 2 et Apache 1.0, il y a dix-huit années. Heureusement que cette obligation n'existe plus, sinon, comment feraient ceux qui utilisent des idéogrammes ou des caractères exotiques, ils seraient obligés d'écrire uniquement avec des entitées HTML ?
Citation
Otomatic
Une balise <meta charset doit être dans les entêtes de TOUTES les pages, mais c'est insuffisant, il faut une directive header("content-type:text/html; charset=$charset"winking smiley; dans les entêtes de toutes les pages.
Citation
Otomatic
Erreur à ne pas faire. Le serveur ne doit pas être prioritaire sur l'encodage des pages.
Citation
Otomatic
Quelle sauvegarde ?
Citation
Otomatic
Je lance Wampserver, puis localhost puis SqlBuddy et Oh! aucune surprise - exactement comme je m'y attendais - tous les caractères accentués des pages SqlBuddy (qui est utf-8) sont forcées par le serveur HTTP à ISO-8859-15, donc sont mal vus : par exemple "éditer les éléments sélectionnés" à la place de "éditer les éléments sélectionnés"
; PHP's default character set is set to empty. ; [php.net] ;default_charset = "UTF-8"Ce sont les entêtes des documents, quels qu'ils soient, qui doivent déclarer le jeu de caractères utilisé.
Citation
default_charset string
Depuis PHP 5.6.0, "UTF-8" est la valeur par défaut et celle ci est utilisé comme jeu de caractères par défaut pour les fonctions et modules. PHP enverra toujours un jeu de caractères par défaut à l'en-tête HTTP Content-type: header. Définir une valeur vide n'est pas recommandé.
Il y a un peu plus de dix ans, lorsque je me suis mis au PHP, toutes mes pages, mêmes celle qui contiennent 99% d'html ont une entête php, donc avec possibilité d'envoyer des header(). Toutes, je dis bien toutes, mes pages commencent systématiquement par include('inc/entete.php');Citation
Artemus24
J'ai des documents html dont le suffixe du fichier est ".html" et de ce fait, je ne fais aucune déclarative à l'intérieur, avec la fonction header(). Cela va de soi puisque je suis en ".html" et non en ".php".
<meta charset="ISO-8859-15" />pour être correctement interprété par le navigateur. Ça c'est la première étape.
Citation
De plus, avoir de l'utf-8 d'un bout à l'autre de la chaine, simplifie énormément le boulot.
Citation
De plus, lorsque tu effectues des export/import de base de données, pour éviter les problèmes, il est impératif que le fichier SQL soit utf-8.
Comme je l'ai déjà écrit, ça provient de plusieurs années de méthodologie d'écriture de programme de tests automatiques d'équipements aéronautiques.Citation
Artemus24
Ton idée de mettre un include 'en-tete' dans tous les documents est excellente.
Actuellement, je le fais mais uniquement pour le menu.
Citation
Otomatic
Ceci n'est pas possible, comme tu l'as écrit, avec la ligne de commande qui ne comporte que des jeux de caractères de 256 octets dont les 127 premiers sont ceux du code ASCII, seuls changent les 127 suivants. Ceci pour rester compatible avec les commandes.