Pages :
(reprise du message précédent)

Tu peux utiliser NotePAd++ en natif, et rechercher les caractères spéciaux dans Dreamweaver (il y a quelques part les caractères spéciaux), le sreprendre dans le code proposé par Dreamweaver, et les inclures dans ton doc sur Notpad. (N'oublie pas de déclarer ton charset sur ton doc).
Madmax > si tu utilises les caractères de 128 à 159 que j'ai indiqués, il faut utiliser leur entité &xxxxxx;
Il y a un article d'openweb qui en parle mieux que moi, j'ai perdu le lien mais tu peux le retrouver... le titre c'est "caractères interdits en HTML et XHTML" ou similaire.

Pourquoi on ne peut pas encoeder en cette norme > normal, c'est windows Smiley exit
a écrit :
Dans ce cas, tourne toi vers l’utf-8, d’autant plus si tes pages sont statiques

Elle ne le seront pas justement...

a écrit :
Tu peux utiliser NotePAd++ en natif, et rechercher les caractères spéciaux dans Dreamweaver

Oui merci, mais ça c'est encoder manuellement. J'aurais voulu pouvoir encoder avec un programme.

si tu utilises les caractères de 128 à 159 que j'ai indiqués, il faut utiliser leur entité &xxxxxx;

Merci Quentin C, je vais changer ces carctères à la main. Je renonce à trouver un programme qui m'encode tout automatiquement (ça va me prendre plus de temps de le chercher que de changer ces carctères à la main.)
J'avou que je suis quand même déçu... Smiley decu
Bobe a écrit :


Dans ce cas, tourne toi vers l’utf-8, d’autant plus si tes pages sont statiques (pas de base de données, pas de scripts serveur pour générer les pages, …).


Pourquoi ca change quelque chose si on a une base de donnée, l'UTF8 ? (mySQL dans mon cas ...)
Ça peut être problématique si la base de données ne gère pas les encodages multi-octets comme l’utf-8 et qu’on a besoin d’utiliser des fonctions SQL de traitement de chaînes ou de faire des comparaisons de chaînes.

MySQL ne supporte l’utf-8 qu’à partir de la version 4.1.
Ah ouais ... Donc si on utilise un mySQL 4.1, on a aucun probleme a utilsier l'encodage UTF-8 ?
Modifié par muaddib (17 Sep 2005 - 09:28)
Oui, aucun problème dans ce cas, au niveau de la base de données.

Après, si on utilise php, il faut également avoir le module mbstring de PHP installé (même problème que pour SQL, il faut que les fonctions de traitement de chaînes soient compatibles avec les encodages multi-octets).
Bobe a écrit :
Oui, aucun problème dans ce cas, au niveau de la base de données.

Après, si on utilise php, il faut également avoir le module mbstring de PHP installé (même problème que pour SQL, il faut que les fonctions de traitement de chaînes soient compatibles avec les encodages multi-octets).


Ou alors utiliser tout simplement les fonction utf8_encode() et utf8_decode Smiley cligne

++
Pour quoi faire ? Le but est de ne plus se casser la tête avec les encodages et que la chaîne reste en utf-8 tout du long.
Pages :