Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1284 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

[XHTML] Validation XHTML et charset

n°491929
antp
Super Administrateur
Champion des excuses bidons
Posté le 20-08-2003 à 00:03:07  profilanswer
 

Reprise du message précédent :

MagicBuzz a écrit :

Mais je m'insurge quand on me dit que c'est ce qui est recommandé dans la norme.


 
Tu vas quand même pas recommander d'utiliser l'US-ASCII ?  
À la limite dire "le plus sûr c'est US-ASCII", mais de là à recommander d'utiliser ça...


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
mood
Publicité
Posté le 20-08-2003 à 00:03:07  profilanswer
 

n°491939
MagicBuzz
Posté le 20-08-2003 à 00:14:10  profilanswer
 

Moi je ne recommande de rien, je cite simplement la doc.
 
Deplus, recommander le plus petit dénominateur commun a toujours été la véritée absolue quelquesoit le domaine. A chacun de faire en sorte que ce dernier change.
 
Pour info (au cas où :sarcastic:)
 
18
10
=> Plus petit dénominateur commun : 2
 
18
9 (donc régression pourtant)
=> plus petit dénominateur commun : 9
 
euh... d'ailleurs, depuis tout à l'heure, je dis une connerie, c'est "plus grand dénominateur commun"
 
Vous aurez corrigé de vous-même ;)
 
Aujourd'hui où on nous casse les oreilles avec le XHTML pour faire des pages compatible avec les navigateurs texte et les aveugles sourds, on n'ira pas me faire gober que c'est pas le plus grand déominateur commun. On ne recommande pas de faire des sites avec des effets visuels en Open/GL et une présentation à la Copland OS (regarder l'anime intitulé "Lain" pour les incultes). Ce serait pourtant vachement plus sexy et sympa à développer. Mais le problème c'est bien l'accessibilité.
 
Hors l'UTF-8 et loin d'être accessible à tous les systèmes...
 
Je rappelle juste au passage d'ailleurs que le XML est prévu à la base pour échanger, par ftp ou http (donc le ftp risque de virer des infos si on passe en mode texte) des données entre serveurs de base de données hétérogènes. Hors entre deux bases, si tu utilises le même charset, t'as beaucoup de pot, et tous les SGBD sont loin de supporter tous les charset pour les intégrer. Donc passer le XML en us-ascii et s'assurer qu'en aucun cas l'information sera corrompue est tout de même la principale préoccupation dans de telles circonstances...

n°491945
MagicBuzz
Posté le 20-08-2003 à 00:17:42  profilanswer
 

HotShot a écrit :

J'ai jamais rien compris au principe de "l'encodage des caractères".
 
Si je tape un "a", que j'enregistre en .txt, nulle part il n'est précisé l'encodage etc... et pourtant ça affichera un "a"... alors, ça marche comment ?


par défaut, c'est us-ascii.
si tu utilise un charset spécifie (sous Windows, de base, c'est le charset windows-1251 pour l'europe de l'ouest) à ce moment il sera enregistré dans ce mode (à condition de passer par l'OS pour accéder au fichier). C'est pour cette raison que tu as très souvent des problèmes d'accent quand tu passes un fichier de windows à ms-dos ou à linux. parceque chacun utilise de base sont propre charset. l'UTF-8 et l'UTF-16 sont les seuls encodage qui permettent de stocker et relire n'importe quel caractère écrit dans n'importe quel alphabet... à condition que tout le long le fichier soit transoprté en binaire, et que tu le lise bien en UTF-x. Sinon, tu vois rien du tout :D

n°491956
antp
Super Administrateur
Champion des excuses bidons
Posté le 20-08-2003 à 00:27:24  profilanswer
 

l'UTF8 c'est de l'ASCII 8 bits tout con, tu le transporte comme tu veux tant que ça reste sur 8 bits, ça passe bien en mode texte (il n'utilise pas de caractères non imprimables pour le stockage des caractères étendus)


Message édité par antp le 20-08-2003 à 00:28:16

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°491980
MagicBuzz
Posté le 20-08-2003 à 00:35:38  profilanswer
 

Exemple des problèmes d'encodage. (et en quoi ça peut foutre une merde noire en UTF-8)
 
http://stats.manga-torii.com/test.txt
http://stats.manga-torii.com/test.asc
 
Ouvre notepad, et copie ces deux url dans la boîte d'ouverture d'un nouveau document.
 
Les deux fichiers sont les mêmes, enregistrés en UTF-8
 
Le premier est text/text;charset=utf-8 sur le serveur.
Notepad l'ouvre correctement. (enfin... sous XP/2003)
 

Exemple de fichier contenant à la fois des caractères français et japonais :
 
Belldandy (prénom féminin) : べるだんぢ


 
Le second est text/text;charset=us-ascii (ça peut par exemple être un firewall qui modifie le header pour s'assurer que les fichiers ne peuvent pas contenir du code executable)
Notepad affiche n'importe quoi.
 
Chez moi ça donne :
 


Exemple de fichier contenant à  la fois des caractères français et japonais :
 
Belldandy (prénom féminin) : ã?¹ã??ã? ã??ã?¢


 
On voit tout de suite que les caractères présents dans l'us-ascii sont passés correctement.
 
C'est le plus grand dénominateur commun. En effet TOUS les encodages de texte interprètent correctement les caractères us-ascii.
 
Là où ça merde à mort, c'est surtout le "" en début de fichier : avec ça, c'est bon, le fichier XML est à coup sûr pas valide. Hors, si le fichier ne contenait que du ASCII, alors ces caractères auraient disparus, rendant valide le fichier.
 
PS: pour faire le test, ne passez pas par IE ou même Moz si vous êtes sous Windows : en effet, Microsoft, par souci de simplification, ne respecte pas la norme, et réinterprète lui-même le charset, et retrouve donc le bon charset quand il vous ouvre notepad.


Message édité par MagicBuzz le 20-08-2003 à 00:38:23
n°491981
MagicBuzz
Posté le 20-08-2003 à 00:37:31  profilanswer
 

antp a écrit :

l'UTF8 c'est de l'ASCII 8 bits tout con, tu le transporte comme tu veux tant que ça reste sur 8 bits, ça passe bien en mode texte (il n'utilise pas de caractères non imprimables pour le stockage des caractères étendus)


Euh... Non, l'UTF-8 peut utiliser jusqu'à 3 bytes pour stocker un unique caractère (c'est le cas du japonnais)
Deplus, je maintiens que si tu passes par FTP et que tu as la bonne idée de mettre "text" (format par défaut pour un fichier txt entre autre) il va transporter les 7 bits de poids faible, donc ton fichier ne ressemble plus à rien à l'arrivée, même si tu utilises le bon encodage pour le relire.

n°492009
antp
Super Administrateur
Champion des excuses bidons
Posté le 20-08-2003 à 00:59:06  profilanswer
 

Dans tes deux fichiers exemple, les deux s'affichent nickel chez moi dans Notepad (les deux sont identiques)... donc je pige pas où tu veux en venir :D
Mais là tes fichiers sont encodés en UTF8 avec un "header" de 3 bytes qui indique que c'est de l'UTF8.
Or pour un fichier XML c'est pas nécessaire, on l'encode comme du 8 bits classique (ASCII étendu ou un truc du genre), et c'est tout. Là y aura pas de problèmes tant qu'il reste en 8 bits.
 

MagicBuzz a écrit :


Euh... Non, l'UTF-8 peut utiliser jusqu'à 3 bytes pour stocker un unique caractère (c'est le cas du japonnais)


Et alors ?
il stocke ton caractère japonais en tant que Éüõ (par exemple), je vois pas en quoi ça pose un problème, n'importe quel soft peut le traiter comme du texte
Je lis et écris des données de fichiers XML UTF8 avec un parseur XML qui ne supporte que l'ANSI (chaînes à 1 octet par caractère), ça marche nickel, je les retransforme en unicode dans mon soft par après pour avoir des chaînes WideString où chaque caractère prend deux octets.
 

MagicBuzz a écrit :


Deplus, je maintiens que si tu passes par FTP et que tu as la bonne idée de mettre "text" (format par défaut pour un fichier txt entre autre) il va transporter les 7 bits de poids faible, donc ton fichier ne ressemble plus à rien à l'arrivée, même si tu utilises le bon encodage pour le relire.


:heink: il transfère pas en 8 bits le mode texte ?


Message édité par antp le 20-08-2003 à 01:00:38

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°492024
Kristoph
Posté le 20-08-2003 à 01:32:36  profilanswer
 

MagicBuzz a écrit :


Euh... Non, l'UTF-8 peut utiliser jusqu'à 3 bytes pour stocker un unique caractère (c'est le cas du japonnais)
Deplus, je maintiens que si tu passes par FTP et que tu as la bonne idée de mettre "text" (format par défaut pour un fichier txt entre autre) il va transporter les 7 bits de poids faible, donc ton fichier ne ressemble plus à rien à l'arrivée, même si tu utilises le bon encodage pour le relire.


 
Je sais pas ce que tu as fumé, mais c'est très fort ! La seule chose que le mode de transfert ftp texte fait par rapport au mode binaire, c'est convertir le caractères de retour à la ligne dans le format de la machine du destinataire. Pour étre précis, le client et le serveur se mettent d'accord sur le format Unix pour le transport. Autrement dit, entre 2 machines Unix, le mode ftp ascii et le mode binaire se comportente exactement de la même façon.

n°492025
MagicBuzz
Posté le 20-08-2003 à 01:38:31  profilanswer
 

vous utilisez quel OS ?
moi j'utilise 2K3, et notepad se comporte normalement, c'est à dire qu'il ne retrouve pas le content-type du second fichier.
 
et non, le mode texte tronque tes bytes à 7 bits, plus 1 bit pour la parité. sinon, pour ce qui est des caractères UTF-8 convertis en ANSI, deux problèmes :
 
1) t'es pas à l'abrit qu'un des caractères contienne un < ou un >, ou encore un & (à moins qu'ils aient prévu ça dans la norme, mais j'en doute, ça relève du bricoleur du dimanche)
2) des convertisseurs & #1234; en n'importe quel charset, ça se trouve dans n'importe quelle librairie de n'importe quel langage. Par contre, un convertisseur de "è" en "è" dans un charset donné, c'est déjà plus chaud à trouver... Hors, tu ne peux pas stocker ça dans la base tel quel, puisque si par exemple tu utilise MySQL, et qu'une donnée se termine par "à", ça va donner "à ", hors MySQL a un bug qui fait qu'il vire systématiquement les espaces en bout de chaîne dans un varchar (cf. lien que j'ai donné à simogeo dans son topic sur le type char avec MySQL). A ce moment, l'information UTF-8 est définitivement perdue, et c'est pas le seul exemple. Alors que si tu stockes les caractères encodés à la sauce HTML, tu ne perdra aucune info.
 
Dans tout langage y'a des fonction HTMLEncode et HTMLDecode, c'est pas fait pour les poissons rouges.
 
Surtout que dans tous les cas, il te faudra passer par ces fonctions, puisqu'il faut remplacer les <, & et > par des caractères qui ne risquent pas de faire planter le parseur XML.


Message édité par MagicBuzz le 20-08-2003 à 01:41:43
n°492026
MagicBuzz
Posté le 20-08-2003 à 01:40:38  profilanswer
 

Kristoph a écrit :


 
Je sais pas ce que tu as fumé, mais c'est très fort ! La seule chose que le mode de transfert ftp texte fait par rapport au mode binaire, c'est convertir le caractères de retour à la ligne dans le format de la machine du destinataire. Pour étre précis, le client et le serveur se mettent d'accord sur le format Unix pour le transport. Autrement dit, entre 2 machines Unix, le mode ftp ascii et le mode binaire se comportente exactement de la même façon.


J'ai beau récupérer un fichier sous Unix en mode texte sur mon PC sous Windows, il ne me remet jamais en forme les retours à la ligne...


Message édité par MagicBuzz le 20-08-2003 à 01:40:59
mood
Publicité
Posté le 20-08-2003 à 01:40:38  profilanswer
 

n°492035
pascalC
Posté le 20-08-2003 à 02:24:36  profilanswer
 

MagicBuzz a écrit :


par défaut, c'est us-ascii.
si tu utilise un charset spécifie (sous Windows, de base, c'est le charset windows-1251 pour l'europe de l'ouest)


 
Mince, il est grand temps que je me mette au russe moi !

n°492037
pascalC
Posté le 20-08-2003 à 02:46:48  profilanswer
 

MagicBuzz a écrit :

Exemple des problèmes d'encodage. (et en quoi ça peut foutre une merde noire en UTF-8)
 
http://stats.manga-torii.com/test.txt
http://stats.manga-torii.com/test.asc
 
Ouvre notepad, et copie ces deux url dans la boîte d'ouverture d'un nouveau document.
 
Les deux fichiers sont les mêmes, enregistrés en UTF-8
 
Le premier est text/text;charset=utf-8 sur le serveur.
Notepad l'ouvre correctement. (enfin... sous XP/2003)
 

Exemple de fichier contenant à la fois des caractères français et japonais :
 
Belldandy (prénom féminin) : べるだんぢ


 
Le second est text/text;charset=us-ascii (ça peut par exemple être un firewall qui modifie le header pour s'assurer que les fichiers ne peuvent pas contenir du code executable)
Notepad affiche n'importe quoi.


 
J'adore ton type Mime, très créatif, novateur même ! :-)

n°492038
pascalC
Posté le 20-08-2003 à 02:57:10  profilanswer
 

Urd-sama a écrit :

textpad, mais je pense pas que ca soit le problème
mais si jamais j'essayerai avec un autre ce soir


 
Au contraire, je pense que le problème est là, ton logiciel doit enregistrer ton document en us-ascii 7 bits  et pas en iso 8859-1 (logiciel en version US ?). Tu aurais pas une URL à nous indiquer qu'on aille voir de nous-mêmes ?

n°492039
MagicBuzz
Posté le 20-08-2003 à 03:04:36  profilanswer
 

j'aime bien l'esprit de ce forum, franchement.
 
on vous emmerde à tout bout de champ "les normes y'a que ça de vrai, faut les suivre à la lettre".
 
t'as la bonne idée d'indiquer qu'une des recommandations d'une des normes est moins bandante qu'il n'y paraît, et systématiquement :
 
- dans un premier temps, on te contredit (j'adore)
- dans un second temps, ça devient "ta" recommandation, "ta" merde, de toute façon tu es un con, et j'en passe.
 
bien... ça occupe mes soirées au moins. si vous avez rien de mieu à foutre que de vous mettre des oeillères et d'imaginer que tout est beau dans le meilleur des mondes possible, c'est votre problème. moi je bosse pas de cette façon, désolé y'a une phase qui s'appelle étude dans un projet. quand vous aurez écrit une superbe application qui marche super bien sur votre serveur et qui sera incapable de tourner sur le serveur de production, vous irez demander à l'administrateur du serveur de prod de modifier la moitiée des paramètres pour vos beaux yeux, et changer la configuration de la moitiée du parc informatique de l'entreprise... continuez à croire qu'un P4 avec linux c'est un serveur, et qu'une appli utilisée par 20 personnes c'est une appli client/serveur de grande envergure, et qu'un superbe réseau de 50 machines c'est un réseau "d'entreprise". marquez d'un point vers votre CV, que je sâche la prochaine fois qu'on me consulte pour une ambauche à vous écarter des projets sur lesquels je travail.

n°492040
pascalC
Posté le 20-08-2003 à 03:05:42  profilanswer
 

MagicBuzz a écrit :

Je sais :)
D'où une des recommandations W3C qui consiste à faire systématiquement du us-ascci contrairement à ce que m'a répondu je ne sais plus qui dans un topic à propos du XML.


 
"The ASCII character set is not sufficient for a global information system such as the Web, so HTML uses the much more complete character set called the Universal Character Set (UCS), defined in [ISO10646]. This standard defines a repertoire of thousands of characters used by communities all over the world."
 
http://www.w3.org/TR/html401/charset.html#encodings

n°492041
MagicBuzz
Posté le 20-08-2003 à 03:07:52  profilanswer
 

Citation :

The relevant specification (RFC 3023) specifies a strong default of "us-ascii" for such documents so we will use this value regardless of any encoding you may have indicated elsewhere.


 
Putain, t'as des yeux derrière la merde que tu as devant ?

n°492042
pascalC
Posté le 20-08-2003 à 03:33:59  profilanswer
 

MagicBuzz a écrit :

Citation :

The relevant specification (RFC 3023) specifies a strong default of "us-ascii" for such documents so we will use this value regardless of any encoding you may have indicated elsewhere.


 
Putain, t'as des yeux derrière la merde que tu as devant ?


 
Bah non, c'est toi qui en as plein les yeux et qui est tellement omnubilé par tes problèmes de xml que tu ne vois rien d'autre :
"J'ai un petit problème avec la validation d'un simple fichier XHTML."
 
Et que comme le html, le xhtml dépend de la RFC2646, pas de la 3023 car il est toujours envoyé en text/html, s'il était envoyé en application/xhtml+xml là tu aurais raison ("By virtue of all XHTML content being XML, it has the same considerations when sent as 'application/xhtml+xml' as does XML) mais les chances pour que ce soit le cas sont infimes puisque dans ce cas IE serait incapable de les afficher.

n°492063
urd-sama
waste of space
Posté le 20-08-2003 à 08:17:50  profilanswer
 

bon j'ai pas tout lu votre débat sur les charset, mais je récapitule ce que j'ai compris et le but de la chose.
Le but c'est que je suis en train de terminer une introduction XHTML pour noobs et à la fin je parle de la validation XHTML. pour ca, j'ai mis un code tout fait pour que le noob puisse tester, et que ca donne juste.
Donc je ne peux pas l'uploader sur un serveur dans le cadre de cet exercice.
ensuite, si je veux m'en sortir, je dois mettre les codes html pour les accents? et comment expliquer en langage noob le pourquoi de la chose?

n°492119
antp
Super Administrateur
Champion des excuses bidons
Posté le 20-08-2003 à 09:49:24  profilanswer
 

MagicBuzz a écrit :


et non, le mode texte tronque tes bytes à 7 bits, plus 1 bit pour la parité.  


 
:heink: et mes accents, comment ils sont transmis alors :heink:
 

MagicBuzz a écrit :


sinon, pour ce qui est des caractères UTF-8 convertis en ANSI, deux problèmes :
 
1) t'es pas à l'abrit qu'un des caractères contienne un < ou un >, ou encore un & (à moins qu'ils aient prévu ça dans la norme, mais j'en doute, ça relève du bricoleur du dimanche)


 
[:rofl] t'as lu la doc ? il n'utilise que les caractères au-delà de 128, donc justement pas de problèmes avec ça
 

MagicBuzz a écrit :


2) des convertisseurs & #1234; en n'importe quel charset, ça se trouve dans n'importe quelle librairie de n'importe quel langage. Par contre, un convertisseur de "è" en "è" dans un charset donné, c'est déjà plus chaud à trouver... Hors, tu ne peux pas stocker ça dans la base tel quel, puisque si par exemple tu utilise MySQL, et qu'une donnée se termine par "à", ça va donner "à ", hors MySQL a un bug qui fait qu'il vire systématiquement les espaces en bout de chaîne dans un varchar (cf. lien que j'ai donné à simogeo dans son topic sur le type char avec MySQL). A ce moment, l'information UTF-8 est définitivement perdue, et c'est pas le seul exemple. Alors que si tu stockes les caractères encodés à la sauce HTML, tu ne perdra aucune info.


 
mais de quoi tu parles ? je vois pas le rapport avec les espaces... on s'en fout des espaces, je vois pas le rapport avec l'UTF8. Puis la conversion UTF8<->Unicode/WideString, à mon avis tous les langages qui gèrent l'unicode gèrent aussi cette conversion (perso je m'en fous, je ne programme qu'en Delphi, et là y a UTF8Decode et UTF8Encode :D)
 

MagicBuzz a écrit :


Dans tout langage y'a des fonction HTMLEncode et HTMLDecode, c'est pas fait pour les poissons rouges.


 
:heink: non pas tous, pas en Delphi ni en C++Builder en tout cas o
 

MagicBuzz a écrit :


Surtout que dans tous les cas, il te faudra passer par ces fonctions, puisqu'il faut remplacer les <, & et > par des caractères qui ne risquent pas de faire planter le parseur XML.


 
heu ça c'est le parseur XML qui s'en charge hein ! m'enfin :heink: Quel parseur foireux tu utilises ?
 

MagicBuzz a écrit :

j'aime bien l'esprit de ce forum, franchement.
 
- dans un premier temps, on te contredit (j'adore)


 
:heink: faut dire que quand tu présentes des choses, au premier abord ça ressemble toujours à du grand n'importe quoi, là par ex quand tu me parles d'UTF8 on dirait que tu ne sais même pas comment c'est encodé :o
 

MagicBuzz a écrit :


bien... ça occupe mes soirées au moins. si vous avez rien de mieu à foutre que de vous mettre des oeillères et d'imaginer que tout est beau dans le meilleur des mondes possible, c'est votre problème. moi je bosse pas de cette façon, désolé y'a une phase qui s'appelle étude dans un projet. quand vous aurez écrit une superbe application qui marche super bien sur votre serveur et qui sera incapable de tourner sur le serveur de production, vous irez demander à l'administrateur du serveur de prod de modifier la moitiée des paramètres pour vos beaux yeux, et changer la configuration de la moitiée du parc informatique de l'entreprise... continuez à croire qu'un P4 avec linux c'est un serveur, et qu'une appli utilisée par 20 personnes c'est une appli client/serveur de grande envergure, et qu'un superbe réseau de 50 machines c'est un réseau "d'entreprise". marquez d'un point vers votre CV, que je sâche la prochaine fois qu'on me consulte pour une ambauche à vous écarter des projets sur lesquels je travail.


 
[:rofl] ça y est, t'es reparti dans ton trip


Message édité par antp le 20-08-2003 à 09:50:21

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°492122
Krueger
tout salaire demande dutravail
Posté le 20-08-2003 à 09:54:50  profilanswer
 

Hum...
 
si Content-Type = text/xml :
encodage recommandé = utf-8 ou utf-16
encodage par défaut = us-ascii
 
RFC 3023
 
Je sens un malentendu sur ces deux termes.


Message édité par Krueger le 20-08-2003 à 10:00:14

---------------
"Colère et intolérance sont les ennemis d'une bonne compréhension." Gandhi
n°492139
MagicBuzz
Posté le 20-08-2003 à 10:12:04  profilanswer
 

je vois pas comment en toute logique on peut recommander quelquechose qui n'est pas la valeur par défaut, surtout si cette dernière n'est pas compatible avec ce qui est recommandé.
 
je crois que certains ne maîtrisent pas la langue française si la grammaire des normes. y'a une différence entre recommandé et conseillé, préféré. ça ne veux rigoureusement pas dire la même chose, mais alors VRAIMENT pas du tout.
 
donc si on parle pas la même langue, on pourra jamais se comprendre. toujours est-il qu'il est impossible que l'UTF-8/UTF-16 soit RECOMMANDE par la norme si c'est l'us-ascii qui est utilisé par défaut.

n°492140
urd-sama
waste of space
Posté le 20-08-2003 à 10:13:55  profilanswer
 

je dois faire quoi moi alors  :cry:  
arrêtez de vous engueuler sur mon topic bordel  :cry:

n°492161
Krueger
tout salaire demande dutravail
Posté le 20-08-2003 à 10:30:40  profilanswer
 

MagicBuzz > As-tu au moins relu la RFC ? (section 3.1 : Text/xml Registration)
Urd-sama > Si tu souhaites réellement valider ton contenu par W3C, encode-le en us-ascii. Ton système ne renvoie probablement pas au validateur le bon encodage de ton fichier uploadé sur le serveur (s'il en envoie un). C'est pourquoi il voit ça comme du us-ascii.


---------------
"Colère et intolérance sont les ennemis d'une bonne compréhension." Gandhi
n°492168
urd-sama
waste of space
Posté le 20-08-2003 à 10:35:31  profilanswer
 

Krueger a écrit :


Urd-sama > Si tu souhaites réellement valider ton contenu par W3C, encode-le en us-ascii. Ton système ne renvoie probablement pas au validateur le bon encodage de ton fichier uploadé sur le serveur (s'il en envoie un). C'est pourquoi il voit ça comme du us-ascii.


merci
vais tenter de finir le rapport avec ca :jap:

n°492171
Kristoph
Posté le 20-08-2003 à 10:36:27  profilanswer
 

MagicBuzz a écrit :

je vois pas comment en toute logique on peut recommander quelquechose qui n'est pas la valeur par défaut, surtout si cette dernière n'est pas compatible avec ce qui est recommandé.
 
je crois que certains ne maîtrisent pas la langue française si la grammaire des normes. y'a une différence entre recommandé et conseillé, préféré. ça ne veux rigoureusement pas dire la même chose, mais alors VRAIMENT pas du tout.
 
donc si on parle pas la même langue, on pourra jamais se comprendre. toujours est-il qu'il est impossible que l'UTF-8/UTF-16 soit RECOMMANDE par la norme si c'est l'us-ascii qui est utilisé par défaut.


 
- Recommandé : encodage à utiliser dorenavent dans toute nouvelle solution
- Utilisé par défaut : encodage choisi purement pour raison de compatibilité avec l'existant. cf obsolete, déprécié, banni

n°492177
Krueger
tout salaire demande dutravail
Posté le 20-08-2003 à 10:42:38  profilanswer
 

Kristoph a écrit :


 
- Recommandé : encodage à utiliser dorenavent dans toute nouvelle solution
- Utilisé par défaut : encodage choisi purement pour raison de compatibilité avec l'existant. cf obsolete, déprécié, banni
 


:non:
Toi aussi, lis la RFC. :D
Par 'par défaut', ils sous-entendent quand l'encodage n'est pas spécifié, s'il est faux ou s'il n'est pas supporté.


---------------
"Colère et intolérance sont les ennemis d'une bonne compréhension." Gandhi
n°492186
Kristoph
Posté le 20-08-2003 à 10:47:00  profilanswer
 

Krueger a écrit :


:non:
Toi aussi, lis la RFC. :D
Par 'par défaut', ils sous-entendent quand l'encodage n'est pas spécifié, s'il est faux ou s'il n'est pas supporté.


 
Je sais bien ça, mais on pourrait se demander pourquoi ils n'ont pas choisit l'encodage recomandé comme encodage par defaut. La norme ne dit pas qu'il faut toujours indiquer l'encodage utilisé ?

n°492198
Krueger
tout salaire demande dutravail
Posté le 20-08-2003 à 10:57:13  profilanswer
 

1. Je ne sais pas. Peut-être que ça a été dit plus haut dans ce topic, mais je n'ai plus envie d'y regarder. Cette discussion commence à m'embrouiller.
2. Tu n'es pas obligé d'indiquer l'encodage, mais c'est fortement recommandé.


---------------
"Colère et intolérance sont les ennemis d'une bonne compréhension." Gandhi
n°492271
pascalC
Posté le 20-08-2003 à 12:04:36  profilanswer
 

Urd-sama a écrit :


merci
vais tenter de finir le rapport avec ca :jap:


 
Pour connaître facilement ce qu'envoie ton serveur, tu charges la page avec Mozilla/Netscape/Firebird et tu tapes CTRL + I

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[Validation] XHTML 1.0 Transitional CSS, Omittag No et Background[XHTML] IE passe, Mozilla bloque ...
[PHP WML XHTML] Reconaitre un navigateur HTML ou WAP ?[XHTML] problème avec le #
[XHTML/CSS] Ecrire dans le bas d'une divCSS XHTML passe sous IE mais pas sous netscape
[Résolu] Sessions PHP et Validation[xhtml] cellspacing, padding, colspan... ils deviennent quoi ? [end]
[PHP] Validation d'un champs date 
Plus de sujets relatifs à : [XHTML] Validation XHTML et charset


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR