Codage texte

Mage-Li

Membre actif
29 Mai 2004
399
14
41
www.ouf-web.com
Bonjours tout les devweber macisien !
Malgré une recherche et la lecture du topic : Avec quoi enregistrer un texte en html ? je n'ai pas trouvé la réponse a mon prob.

Quand je visualise une page XHTML que j'ai créé via HyperEdit, les é sont affichés sur mes navigateurs ( Safari, Explorer, Firefox ) comme des ´. J'ai pourtant esseyé de réencoder le texte en UTF-8 mais a la place des ´ j'ai des é !!!
J'ai aussi esseyé UTF-16 etc...

Une idée ?
 
j'utilise les codes numériques pour les principaux caractères spéciaux, et cela fonctionne très bien.

liste complète des caractères spéciaux.

Il est vrai que c'est + simple sous dreamweaver par exemple, car ce logiciel te propose de les inclure directement quand tu désires mettre des accents dans ton code....
 
Merci beaucoup :up:

Quelques questions pérsite néenmoins...
Donc si je comprend bien les é sont des caractére spéciaux. Mais dans toute cette liste qu'es qui correspond a UTF-8 ?

Et puis remplacer tout les é par des è c'est un peuk beaucoup, passionnément relou ! Il y a pas un petit soft qui fait ca automtatiquement ? A moins que j'ouvre Dreamweaver et que je sauvegarde mon fichier il réencodera et remplacera les ´ par des é peut etre...

Une derniére chose je comprend pas pourquoi les é sont des caractéres spéciaux. En quel codage texte est le XHTML et pourquoi on ne peut pas créer des documents direcetement dans ce codage ?

Encore merci :zen:
 
Merci une nouvelle liste c'est cool :love:

Mais pourquoi é et è donne le meme é ???

Je sais que j'en demande peut etre un peu trop mais bon... N'ésité pas a me filé un lien qui explique tout ca je le lirai ;)

J'aime comprendre les choses au leiu des les appliqués béttement...
 
Simplement parce que c'est le même code qui se cache derrière.

Il faut 2 choses pour représenter un caractère: sa valeur (un nombre) et le nom de l'encoding... C'est à partir de la combinaison des deux que ton browser sait afficher le bon caractère.

Puise que c'est un nombre, tu peux le représenter de deux façons: décimale et héxadécimale. En gros, les nombres décimaux sont faits de chiffres de 0 à 9 (ça fait 10 chiffres... donc décimal)... et en héxa, tu en as 16 (de 0 à F).

En plus, certains ont également un petit nom normalisé que ton browser sait reconnaître. D'où pour le é:
  1. é en petit nom
  2. é en décimal
  3. é en héxa

Dernier point, les humains comprennent mieux en décimal... parce qu'on a 10 doigts (en général)... et les ordinateurs comprennent mieux l'héxa, parce qu'on peut plus rapidement en faire une conversion binaire donc... des 0 et des 1 ;).
 
Merci bien pour t'on explication.
Ce que j'ai toujours du mal a cerné c'est les différentes "couches" de language. C'est a dire lorganisation, le fonctionnement de tout ca.

Parce que on créé un fichier XHTML codé en UTF-8. Il y a deja deux codage le texte et l'extension du fichier. Le browser reconnais le fichier HTML il le lie mais il ne lie pas directement l'UTF-8 ? Donc qu'es qui se passe ? Tu dis :

GrandGibus a dit:
Il faut 2 choses pour représenter un caractère: sa valeur (un nombre) et le nom de l'encoding... C'est à partir de la combinaison des deux que ton browser sait afficher le bon caractère.

Si je comprend bien le texte est converti en language machine. Mais par contre le nom de l'encoding c'est quoi ? Le nom du codage du texte ? C'est a dire dans mon exemple UTF-8 ?

PS: j'emploi le terme language machine sans trop savoir ce que c'est !
 
Bonjour,
Pour éviter les difficultés avec les caractères spéciaux (pb qui n'existe pas sur PC), j'utilise soit :
1) DreamWeaver (comme il est dit plus haut)
2) sous macOS X : BorakHTML (choisir encodage UTF-8 = base mac et non pas iso 8859 = base PC)
3) sous macOS 9 ou inf : Mac2HTML. Ce logiciel est très commode : On tape son texte normalement avec des accents et tout et tout... avec Simpletext, puis on glisse ce fichier sur l'icône de mac2HTML et voilà le texte encodé iso 8859, cad par ex. : é à=
Bloc de code:
é à etc...)
Par contre j'ai toujours eu du mal avec les codes ASCII je crois, qui portent des numéros de 160 à 256 précédés d'un & et d'un dièse et qui codent aussi les caractères spéciaux.
 
Langellier a dit:
Bonjour,
Pour éviter les difficultés avec les caractères spéciaux (pb qui n'existe pas sur PC), j'utilise....

Rien à voir ! Le caractère 'é' en html s'obtient par les 3 manières citées plus haut (´ ...). Un point c'est tout et qu'on soit sur PC, Mac ou TO 7.

Si le ie de micro$oft l'accepte c'est pour éviter de faire planter les pages... au même titre d'ailleurs que la tolérence bien connue aux oublis de balises fermantes.
 
mageli a dit:
(...)Si je comprend bien le texte est converti en language machine. Mais par contre le nom de l'encoding c'est quoi ? Le nom du codage du texte ? C'est a dire dans mon exemple UTF-8 ? (...)

Le fichier est une série d'octets stockées dans l'ordinateur (sur le disque). Si on considère qu'un octet (huit bits ou une série de 8 chiffres de 0 ou 1) représente un caractère, cela nous fait que 256 caractères possibles. On atteint vite les limites si on considère certaines langues -asiatiques par exemple. Le codage ASCII est sur 1 octet par exemple.

Du coup, on aurait envie de représenter les caractères sur plusieurs octets... tout en continuant à lire ceux à 1. Ainsi, le charset (c'est son petit nom) figure au début du fichier pour indiquer combien d'octet représente un caractère....

Tu peux t'amuser à sauver avec TextEdit avec différents encodings... et ouvrir le contenu avec un éditeur hexadécimal genre HexEditor.
 
Les entités HTML pour les caractères accentués (é etc.) c'était indispensable à l'époque où les navigateurs ne savaient correctement gérer les jeux de caractères codés et qu'on n'avait pas de moyen aisé pour que le serveur indique au client avec quel encodage est réalisée la page qu'il va envoyer.

En effet, normalement le serveur envoie au client différentes informations avant d'envoyer le fichier lui-même. Ce sont les entêtes HTTP. Parmi ces entêtes il y en a une qui permet de spécifier le type MIME et l'encodage, c'est le Content-type.
Si on crée sa page en UTF-8 dans son éditeur, il faut faire en sorte que le serveur envoie le header indiquant que la page va être de l'UTF-8. Si on ne le fait pas, il y a de très fortes chances que le navigateur client ne s'y retrouve pas car quand il ne sait pas quoi faire il va soit essayer de deviner (avec tous les risques de tomber à côté de la plaque) soit il va utiliser un encodage par défaut (avec tous les risques de retomber à côté de la plaque).

Donc en définitive, quel que soit le codage utilisé dans sa page web, il faut que le serveur l'indique au client avant l'envoi de la page elle-même.
Pour indiquer qu'une page est réalisé avec le codage utf-8, on peut faire ça en PHP avec :
<?php header('Content-Type: text/html; charset=utf-8'); ?>
A mettre au tout début du fichier.

Notez que la ligne
<meta http-equiv="Content-type" content="text/html; charset=iso-8859-1" />
que certains se contentent de mettre à l'intérieur du fichier HTML ne suffit pas. En effet, pour analyser correctement une page web, le navigateur a besoin de connaître l'encodage AVANT de débuter l'analyse. Or, pour trouver cette ligne, il faut qu'il commence l'analyse sans savoir quel encodage est utilisé. Une fois qu'il la trouve, le navigateur recommence alors l'analyse depuis le début en utilisant cette fois le bon encodage.

Quelques articles à lire à ce sujet :
- Introduction aux jeux de caractères
- Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères (surtout la partie Le point le plus important à propos des encodages où il est question d'encodage et de sites web).
 
  • J’aime
Réactions: Niconemo et molgow
Aujourd'hui tous mes documents sont encodés en UTF-8
Du moment qu'ils le sont et que les pages web générées on une déclaration correcte de l'encodage, je n'utilise plus du tout les entités et ça passe sur tous les navigateurs que j'ai pu tester (et à mon avis sur tous tout court). Unicode ça sert à ça au départ... Je sais qu'il y a encore des vielles craintes à ce sujets mais tout semble démontrer qu'elles sont injustifiées (et d'ailleurs j'ai vu des craintes mais jamais d'arguments les justifiant) : les "é" passent très bien dans le code en UTF-8.

C'était pour moi le seul obstacle à l'abandon du wysiwyg jusqu'à ce que je m'aperçoive que ce n'en est pas un.

Sylver : excellent ton 2e lien ! (le 1er est un incontournable) :up: