Votre avis sur (en)codage texte des pages HTML

**cat75** · 24/10/2016, 17h57

Bonjour,

Mes connaissances en programmation portent plus sur WBScript et Visual Basic Pro et Application. La conception de site WEB n'est pas vraiment mon domaine de compétence encore moins le langage JavaScript.

Par avance, merci de votre indulgence ! Il me faut mettre les mains dans le cambouis et apprendre une syntaxe différente.

J'ai lu avec intérêt différents tuto HTML/ JavaScript, en faisant plus confiance à votre site qui colle à l'actualité. Je constate que le langage JavaSript semble, au fil des ans, évoluer très vite et abandonner la compatibilité montante (fonctions devenant obsolètes ou en passe de le devenir).

Mon Boss ayant eu connaissance d'une instruction notée "deprecated" dans JavaScript 1.5, en l'occurrence "unescape" actuellement utilisée dans son code HTML, il me demande de me pencher sur le codage / décodage des chaines de caractères sur des pages n'utilisant que HTML5 (soit disant respectant la norme W3C ce qui semble exact selon site test trouvé) et Javascript… Il est totalement réfractaire à l'utilisation du PHP !

A la découverte du codage existant, je présume que la problématique se situera niveau fichier "ListeRef.js" contenant un tableau imbriqué dans une fonction JavaScript.

Ce qui me choque (mais est-ce Vrai ou Faux ?) est que ce tableau soit importé "en l'état" dans le HTML pour servir, à la fois à créer dynamiquement des titres dans la page HTML et aussi d'URL pour accès à une autre page HTML. Noter que le contenu est actualisée via par un programme WBScript puis le fichier est mis en ligne.

Or, les informations sont au format Windows ANSI. De fait ce dernier peut contenir tous les caractères français dont accents et autres signes type parenthèses. Je peux revoir ce point mais je pense que la solution doit être mise en œuvre au niveau de la page HTML pour un investissement durable …

Pour analyse : Voici un exemple (factice) du fichier de données ListeRef.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
function MyListe() {
// ================================================================================
// Insérer ici références
// ================================================================================
tabTxt[0] = "Céline (haut)/120102";
tabTxt[1] = "Robe à fleurs/1002103";
// ================================================================================
}

Et voici une synthèse partielle du fichier Index.html

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<!DOCTYPE html>
<html>
<head>
 
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
 
<title>Version 2.20.1</title>
 
<script src="../../ListeRef.js" type="text/javascript"></script>
 
<link rel="stylesheet" type="text/css" href="css/index_styles.css" />
 
</head>
 
<body>
 
<script type="text/javascript">
// Charger Liste
tabTxt = new Array();
MyListe();
 
 
// Afficher Menu appelle un code JavaScript externe qui traite les chaines du tableau pour lecture voire également comme URL
AfficherMenu();
 
</script>
</body>
</html>

Question :

Ne devrait-on pas encoder le texte brut (encodeURI() ?) au lieu de le travailler "en l'état" avant de le "balancer" dans la page HTML puis utiliser decodeURI() pour l'affichage en clair et decodeURIComponent() pour une URL ?

En outre dans le code HTML peut-on conserver un charset windows-1252 ou préférer utiliser UTF-8 avec les instructions ci-dessus ?

L'informatique reste, pour moi, la science de la modestie. Merci de vos précieuses remarques et / ou critiques à venir. Peut-être ai-je zappé sur certaines informations présentes sur votre site …

Bonne fin de journée,

**thelvin** · 24/10/2016, 19h39

Hello,

possible, difficile à dire puisqu'on ne sait pas exactement de quelle manière c'est "balancé" dans le HTML.

Tout cela ressemble fort à une manière de construire des URL qui ressemblent à ça : http://monsiteamoi.fr/produits/Céline (haut)/120102 , c'est typique d'une URL jolie dans la barre d'adresse et qui plaît aux moteurs de recherche, et aussi qui peuvent facilement faire de l'URL rewriting pour que ce soit en fait le numéro 120102 qui compte et que le reste soit ignoré.
Auquel cas, non, pas besoin d'échappement, l'URL est correcte telle quelle en faisant : 'http://monsiteamoi.fr/produits/' + tabTxt[0] ;

On pourrait dire que les références listées ici sont déjà échappées comme il faut, c'est à dire pas du tout car il n'y a pas besoin d'échappement.

Il y a des caractères qui n'auraient pas le droit de se trouver là, comme par exemple ? ou # ou %. Eux, il y aurait besoin de les échapper pour remplacer par exemple par %3F.
Mais ceux qui sont utilisés dans ton exemple, non, aucun problème.
Bon, plus exactement, le navigateur, quand on va lui dire de visiter cette URL, il va en réalité demander au serveur produits/C%E9line%20(haut)/120102 parce qu'à plus basse couche c'est comme ça qu'un client et un serveur HTTP communiquent des URLs. Mais, c'est pas le problème du développeur web, ça, c'est le boulot du navigateur. Il sait ce que c'est un espace, il sait ce que c'est un accent, donc il se débrouille, voilà.

En outre dans le code HTML peut-on conserver un charset windows-1252 ou préférer utiliser UTF-8 avec les instructions ci-dessus ?

En principe, le charset qu'il faut utiliser, c'est le bon. Celui que le serveur saura lire. Donc a priori si tu en as un qui marche, tu peux pas le changer sans changer aussi le charset attendu par le serveur.

Cela dit, en général oui, il vaut mieux utiliser utf-8, parce que quand deux sites web se lient l'un l'autre, ils ne savent pas si l'autre a un autre encodage, et en ce moment la tendance est tout le monde se met d'accord vers l'utf-8.
Ça vaut mieux. Mais, changer d'encodage ça se fait pas en un claquement de doigt, donc il vaut mieux rester sur celui qui marche.
Surtout qu'avoir des accents dans l'URL c'est quand même assez cosmétique et pas très utile.

**ABCIWEB** · 24/10/2016, 21h49

Oui clairement le standard du web est l'utf-8. Une lib comme jquery par exemple nécessite de travailler en utf-8, et plus généralement comme dit thelvin c'est le standard utilisé pour faire communiquer des scripts entre eux. Après le changement d'encodage peut demander beaucoup de travail (suivant l'existant côté serveur), donc à vous de voir en fonctions des besoins d'évolution de votre système. Le charset "windows-1252" est déconseillé pour faire de nouveaux sites (surtout si l'on ne connait pas tous les besoins futurs) mais peut suffire pour de l'existant et/ou des besoins bien délimités.

**SpaceFrog** · 25/10/2016, 08h44

Comme sus dit, le plus simple est de passer 100% utf-8.
http://j-willette.developpez.com/tut...-site-en-utf8/

Cela limitera grandement les surprises et complications.

**cat75** · 25/10/2016, 17h17

Coucou,

Un grand merci à vous tous pour ces informations très limpide et pédagogue me remettant sur le droit chemin.

Cette réponse à ma remarque concernant :

Ne devrait-on pas encoder le texte brut (encodeURI() ?) au lieu de le travailler "en l'état" avant de le "balancer" dans la page HTML

possible, difficile à dire puisqu'on ne sait pas exactement de quelle manière c'est "balancé" dans le HTML.

m'a incité à me pencher sur le traitement du texte "balancé" dans la page HTML :

Hormis une mise en forme en CSS, il s'agit de simple manipulations de chaines des caractères en JavaScript réalisées après le décodage avec la méthode unescape() de l'argument passé dans l'URL.

J'ai donc créé un code HTML de test "simplifié" en positionnant en variable le texte URL - mais la déclaration de cette variable globale est peut être incorrecte ? - pour tenter mettre en exergue l'anomalie empêchant de remplacer unescape() par decodeURI().

Dans la console je constate le message suivant :

SCRIPT5025 : l'URI à décoder contient un caractère incorrect.

je dispose des explications selon le lien donné mais aucun des caractères ( : / ; ? ) réservés et utilisés comme séparateurs ne sont présent dans la variable de départ utilisée pourtant correctement traitée avec unescape() !

J'avoue rester perplexe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<!DOCTYPE html>
<html>
<head>
 
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
 
<script type="text/javascript">
 
/*
============================================================
En fait pour reprendre le contenu du tableau tabTxt[0] = "Céline (haut)/120102";
Niveau URL "Céline (haut)" est le premier argument et "120102" le second argument
le texte est découpé en reperant la position du caractère "/" par la méthode substring() 
 
Appel d'une fonction (correcte) pour extraire argument à retenir
	var urlParam = ExtraireParam();
 
Récuperation du répertoire voulu dans parametre des url
En fait tabTxt[0] = "Céline (haut)/120102";
"Céline (haut)" est le premier argument et 120102 le second argument
Ce texte peut également contenir au début une date formatée AAAA-MM-JJ
Exemple argument 1 à traiter RepFile="2016-10-25 Céline (haut)/120102"
 
Récup de "2016-10-25 Céline (haut)" par 
	MyUrl = urlParam["RepFile"];
============================================================
*/
 
// De fait voici argument récupéré qui servira comme Url ET titre de feuille HTML
 
MyUrl = "2016-10-25%20C%E9line%20(haut)"
 
 
 
 
// ============================================================
// ============================================================
 
</script>
 
</head>
<body>
 
<script type="text/javascript">
 
// ============================================================
// Récuperer répertoire pour écrire le titre de la page
// Pour test comparatif activer celui voulu
// unescape()  par défaut
// decodeURI()
// decodeURIComponent()
// ============================================================
 
 
var rep_titre = unescape(MyUrl);
// var rep_titre = decodeURI(MyUrl);
// var rep_titre = decodeURIComponent(MyUrl);
 
 
// Si ce dernier niveau commence par une date sous la forme AAAA-MM-JJ
if (rep_titre.indexOf("-") > 0) {
// Remettre cette date sour la forme JJ/MM/AAAA compléte de la suite
rep_titre=rep_titre.substring(8,10) + "/" + rep_titre.substring(5,7) + "/" + rep_titre.substring(0,4) + " " + rep_titre.substring(11);
}
 
alert(rep_titre);
 
</script>
 
 
</body>
</html>

**Watilin** · 25/10/2016, 18h01

C’est une chose souvent mal documentée, encodeURI et ses variantes travaillent en UTF-8. Cela implique que les fonctions d’encodage vont produire des séquences de plusieurs octets pour les caractères spéciaux, et que les fonctions de décodage attendent ce même genre de séquence.

Un exemple concret :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
encodeURIComponent("é") // -> "%C3%A9"
escape("é")             // -> "%E9"
 
decodeURIComponent("%C3%A9") // -> "é"
decodeURIComponent("%E9")    // URIError: malformed URI sequence

Pour résoudre le problème tu as deux approches :
1. Modifier le WBScript pour qu’il génère des séquences UTF-8 ;
2. Ne rien échapper dans le fichier généré, mais expliciter son charset. Ça se fait ainsi :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<script src="../../ListeRef.js" type="text/javascript" charset="windows-1252"></script>

**SpaceFrog** · 26/10/2016, 08h15

La conversion d'un fichier en utf-8 se faut en deux click avec notepad++ par exemple.
J'évite de conserver des charsets différents.
Après quand la source est distante et non maitrisée reste la solution de Watilin de déclarer explicitement le charset.
Un autre possibilité un peu plus complexe consiste a curler le fichier distant et en faire un mb_convert.

**cat75** · 26/10/2016, 14h17

Sauf mauvaise documentation consultée, pourtant en langue anglaise – j'ai appris à me méfier des éventuelles "french traductions automatique" -, c'est la première fois dans ma carrière que je suis confronté au remplacement d'une instruction par une nouvelle n'autorisant pas une compatibilité montante. A moins d'un manque de finalisation ou maturité de cette dernière, hors fonctionnalités abandonnées pour raison de faille de sécurité…

Mais peut-être ai-je confondu vitesse et précipitation liée une mauvaise interprétation du mot "deprecated" que j'associe à un abandon à plus ou moins long terme de la fonctionnalité "unescape()" - on peut toujours contourner mais en réinventant la roue et écrire sa propre fonction de décodage de table de caractère… - au profit du "decodeURI()".

On peut toujours espérer. Est-ce que ce sera vraiment le cas ? Constat est fait que de vieux codage HTML fonctionnent toujours avec une pléiade de document.write…

... mais restons tourné vers l'avenir !

1000 Mercis à vous tous qui officiez sur ce site et acceptez de partager vos connaissances et ou le mot "veille technologique" n'est par usurpé !

Je le mets bien en évidence en favoris, dans l'espoir de pouvoir "en toute modestie" renvoyer l'ascenseur.