Charset en HTML 5

Bonjour,

Le 18/04/2013 21:06, GR a écrit :

Le charset pour HTML 5 est changé pour l'Europe ?

Au tout début de HTML, je crois que le charset par défaut était
ISO-8859-1. Mais il a toujours été plus propre de déclarer celui
qu'on utilise et ne pas se baser sur une valeur par défaut.

"Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"

Et de toute manière l'encodage propriétaire Windows-1252 n'a *jamais*
été un charset souhaitable.

C'est un avertissement mais je n'aime pas ça !

Pas envie d'écrire ainsi écrire...

Des avis ?

Ben oui. Tu écris « écrire » dans ton éditeur favori, et tu lui demandes
gentiment de sauver le résultat en UTF-8. Si en outre tu demandes tout
aussi gentiment à ton serveur web favori de déclarer le charset UTF-8
dans les entêtes HTTP, tout ira bien.

Si tu ne sais pas faire, voir ce groupe ou fciw.serveurs pour le serveur
web, fr.comp.applications.editeurs-de-texte pour l'éditeur de texte. Et
s'il s'avère que ce dernier ne sait pas sauver en UTF-8 sans BOM, alors
jette-le aux orties et prends-en un autre.

Cordialement,
--
Olivier Miakinen

Le 18/04/2013 21:06, GR a écrit :

Bonjour,

Le charset pour HTML 5 est changé pour l'Europe ?

"Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"

C'est un avertissement mais je n'aime pas ça !

Pas envie d'écrire ainsi écrire...

Des avis ?

Site : http://www.grenault.net
Cours photo : http://www.grenault.net/tech.htm
Home cinéma : http://www.grenault.net/homecine.htm

Bonsoir Monsieur

Déjà que çà fait un moment qu'on attend PHP 6...

Les standards, les préférences, le code propriétaire, toussa...

La liberté d'entreprendre, le champ de la complexité à la Edgar Morin...

A quand les machines à programmer, voire concevoir des types de
conception Informatique de type condensatoire, avec optimisation des
ressources, de la vitesse d'exécution et des performances des programmes ?

Quelques petites babioles de standards difficiles ? à adopter.

Moi, j'ai fait un site en iso8859-1 théoriquement adapté de manière
semi-automatique à la norme PHP 6 par mes soins, avec un script en
Bourne Shell, et un script Awk ( Il y a quelques années ). Mais... C'est
en iso8859-1, alors j'espère que le moment venu, il y aura encore un
petit moyen de hack, pour que ces scripts en iso, fonctionnent sous PHP 6.

Par exemple, dans les .htaccess

Mais... S'il n'y a a pas moyen de faire autrement, j'aurai des
problèmes pour passer en UTF-8, cause mes strlen() et autres substr()...

Et puis... Faudrait encore que UTF-8 tienne la route, quand on saura
le langage des extra-terrestres, que nous ne manquerons pas de
rencontrer sur Mars. ;)

Bof... A chaque époque ses vicissitudes... ;)

Bien amicalement.

Jean François Ortolo

Le 18/04/13 23:16, Jean Francois Ortolo a écrit :

en iso8859-1, alors j'espère que le moment venu, il y aura encore un
petit moyen de hack, pour que ces scripts en iso, fonctionnent sous PHP 6.

Par exemple, dans les .htaccess

Ceux-là doivent certainement être en ascii, non ?

ce qui ne pose pas de blème si on a choisi de "coder" en européen de
l'ouest ou en fenestrel

Mais... S'il n'y a a pas moyen de faire autrement, j'aurai des
problèmes pour passer en UTF-8, cause mes strlen() et autres substr()...

Merci de ne pas postillonner !!!


Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
(tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
utf-8 et le sauvegardes ainsi, non ?)



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

Le Jeudi 18 avril 2013 à 19:06 UTC, GR écrivait sur
fr.comp.infosystemes.www.auteurs :

Pas envie d'écrire ainsi écrire...

Des avis ?

Olivier ayant déjà en partie répondu je ne vais pas le paraphraser.
Juste une précision sur les entités HTML (sauf pour & et je crois
 ) ne sont utile que si le charset du document n'est pas déclaré
ou ne correspond pas à l'encodage dans le quel le document a été
sauvegardé.
Il y a belle lurette que je ne me préoccupe plus de ça !

@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-

Le 19/04/2013 07:40, Gérald Niel répondait à GR :

Juste une précision sur les entités HTML (sauf pour & et je crois
 ) ne sont utiles que [...]

J'ajouterai < (avec > si on aime la symétrie mais celui-ci n'est
pas indispensable), et éventuellement " ou ' dans une valeur
d'attribut déjà délimitée respectivement par " ou '. En revanche  
n'est utile que pour que le développeur sache au premier coup d'½il
distinguer qu'il a mis une espace insécable au lieu d'une espace simple
(ou alors c'est parce qu'il utilise l'éditeur de Firefox ou SeaMonkey
qui remplace l'espace insécable par une simple).

Le 19/04/2013 03:03, SAM a écrit :

Le 18/04/13 23:16, Jean Francois Ortolo a écrit :

en iso8859-1, alors j'espère que le moment venu, il y aura encore un
petit moyen de hack, pour que ces scripts en iso, fonctionnent sous
PHP 6.

Par exemple, dans les .htaccess

Ceux-là doivent certainement être en ascii, non ?

ce qui ne pose pas de blème si on a choisi de "coder" en européen de
l'ouest ou en fenestrel

Mais... S'il n'y a a pas moyen de faire autrement, j'aurai des
problèmes pour passer en UTF-8, cause mes strlen() et autres substr()...

Merci de ne pas postillonner !!!


Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
(tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
utf-8 et le sauvegardes ainsi, non ?)



Cordialement,

Bonjour Monsieur

J'ai mis toutes mes lettres accentuées ( ascii étendu ) de mes textes
affichés, en mode lettre html, à part les noms des courses, que
théoriquement je peux convertir automatiquement à la volée avec
utf8encode ( ou bien iconv() ).

Ceci, même si le contenu de ma base de données reste en mode latin1.

Convertir la database existante en mode utf8 ce serait un sacré boulot.

Mais ce sera peut-être nécessaire à terme, si l'évolution actuelle se
poursuit.

Ce qui me gêne, c'est surtout les strlen et substr() de mes scripts... ;)

Tout mon site est fait avec de scripts php, sauf quatre pages html.

Je croyais que strlen() et substr() étaient soit obsolètes en PHP 6,
soit inadaptés pour traiter de l'utf8, peut-être que je me trompe ?

Et puis, si ces instructions disparaissent, faudra que je trouve une
solution de rechange.

Tout çà me fait penser qu'il va falloir que je fasse déjà un audit
complet de mon site, pour voir si je ne fais pas l'ignoble, la
calamiteuse confusion entre une chaîne de caractères et une array, en
faisant pour les deux : $str[$i]

Interdit en PHP 6... ;)

Merci beaucoup pour vos encouragements à passer en utf8, c'est
l'avenir, mais pour combien de temps ?

Bien amicalement.

Jean François Ortolo

Le 18/04/2013 22:24, Olivier Miakinen a écrit :

Bonjour,

Le 18/04/2013 21:06, GR a écrit :

Le charset pour HTML 5 est changé pour l'Europe ?

Au tout début de HTML, je crois que le charset par défaut était
ISO-8859-1. Mais il a toujours été plus propre de déclarer celui
qu'on utilise et ne pas se baser sur une valeur par défaut.

"Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"

Et de toute manière l'encodage propriétaire Windows-1252 n'a *jamais*
été un charset souhaitable.

C'est un avertissement mais je n'aime pas ça !

Pas envie d'écrire ainsi écrire...

Des avis ?

Ben oui. Tu écris « écrire » dans ton éditeur favori, et tu lui demandes
gentiment de sauver le résultat en UTF-8. Si en outre tu demandes tout
aussi gentiment à ton serveur web favori de déclarer le charset UTF-8
dans les entêtes HTTP, tout ira bien.

Si tu ne sais pas faire, voir ce groupe ou fciw.serveurs pour le serveur
web, fr.comp.applications.editeurs-de-texte pour l'éditeur de texte. Et
s'il s'avère que ce dernier ne sait pas sauver en UTF-8 sans BOM, alors
jette-le aux orties et prends-en un autre.

Cordialement,

On s'est donc fait avoir, nous, les pauvres européens, on ne nous
accorde même pas un charset spécifique. C'est honteux ! Battons nous,
n'acceptons pas le dictat anglo-saxon !

De toute façon le HTML 5 n'est pas finalisé. Je reste donc en
windows-1252, non mais !

--
Site : http://www.grenault.net
Cours photo : http://www.grenault.net/tech.htm
Home cinéma : http://www.grenault.net/homecine.htm

Le 19/04/13 10:08, Jean Francois Ortolo a écrit :

Le 19/04/2013 03:03, SAM a écrit :

Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
(tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
utf-8 et le sauvegardes ainsi, non ?)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

Ha!? Oui!
Je n'avais pas fait gaffe que PHP est toujours aussi tortueux :-(
Que, possiblement, on ne peut lui expliquer une bonne fois qu'on est en
utf-8 de partout et qu'ainsi il pédale dans la semoule entre les octets
et les "caractères".

hop! :
$length = strlen(utf8_decode($s));
Yapuka faire un recherche/échange général sur tous les fichiers du site ;-)

re-hop! :
$new_string = mb_substr($string, $start, $end, 'UTF-8');
Là ça va être un poil + compliqué ...

Merci beaucoup pour vos encouragements à passer en utf8, c'est
l'avenir, mais pour combien de temps ?

Il parait surtout que c'est plus encombrant ...



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

GR (Fri, 19 Apr 2013 10:25:10 +0200 -
fr.comp.infosystemes.www.auteurs) :

Bonjour,

On s'est donc fait avoir, nous, les pauvres européens, on ne nous
accorde même pas un charset spécifique.

On nous en accorde plein, au contraire, les plus courants étant
ISO-8859-1, ISO-8859-15 (le même mais avec prise en compte de quelques
caractères supplémentaires tels que ¤ ou ½), et UTF-8.

C'est honteux ! Battons nous,
n'acceptons pas le dictat anglo-saxon !

Il n'y a pas de diktat anglo-saxon, même les chinois ont leur propre jeu
de caractère.

De toute façon le HTML 5 n'est pas finalisé.

Quel rapport avec les jeux d'encodage des caractères ?

Je reste donc en windows-1252, non mais !

C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.

Actuellement, le meilleur choix pour les sites web est à mon sens UTF-8.

Et une bonne pratique est de systématiquement indiquer le jeu de
caractères utilisé dans les en-têtes des pages HTML.

--
Eric

Le 19/04/2013 14:34, SAM a écrit :

Le 19/04/13 10:08, Jean Francois Ortolo a écrit :

Le 19/04/2013 03:03, SAM a écrit :

Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
(tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
utf-8 et le sauvegardes ainsi, non ?)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

Ha!? Oui!
Je n'avais pas fait gaffe que PHP est toujours aussi tortueux :-(
Que, possiblement, on ne peut lui expliquer une bonne fois qu'on est en
utf-8 de partout et qu'ainsi il pédale dans la semoule entre les octets
et les "caractères".

hop! :
$length = strlen(utf8_decode($s));
Yapuka faire un recherche/échange général sur tous les fichiers du site ;-)

re-hop! :
$new_string = mb_substr($string, $start, $end, 'UTF-8');
Là ça va être un poil + compliqué ...

Merci beaucoup pour vos encouragements à passer en utf8, c'est
l'avenir, mais pour combien de temps ?

Il parait surtout que c'est plus encombrant ...



Cordialement,

Bonjour Monsieur

J'ai fait mieux que çà.

J'ai programmé aujourd'hui, les fonctions suivantes :

_strrpos() , _strpos() , _strlen(), _strtolower, _strtoupper() ,
_substr(), _strstr(), etc...

En utilisant la même notation que les fonctions habituelles iso, mais
avec le _ au début.

Ces fonctions, sont des interfaces avec les fonctions correspondantes
de type : mb_*(), en fonction du charset, que j'ai mis dans une
constante : ENCODING, incluse dans un script : display_errors.php ,
ainsi que le scrtpt contenant ces fonctions : fonctions_utf8.php.

Il ne me reste plus, qu'à programmer la fonction _strtr(), compte
tenu du fait que la fonction mb_strtr() n'existe pas en PHP.

J'ai testé mes fonctions déjà faites, avec ENODING mis à : "ISO-8859-15".

Tout baigne dans l'huile.

le bug, ce sont les voyelles accentuées dans les scripts de mon site. ;)

Sur mon ordinateur, j'ai déjà ajouté le souligné ( _ ) au début de
toute ces fonctions.

Je vais probablement savoir si mon site marche en local, ce week-end.

Après, il faudra que je prenne des mesures pour résoudre le problème
des voyelles accentuées.

Ceci, pour pouvoir basculer d'un seul coup, de ISO-8859-15, à UTF-8.

Mais... IL y a toujours le problème de la database, également à
migrer. ;(

Je ne pourrai pas faire l'économie de scripts ad hoc, de
lecture/écriture/conversion de mes tables MySQL.

Bien amicalement.

Jean François Ortolo