windows 1252->ISO-8859-1

[mathmax]

Bonjour,

pour la réalisation de mon site, j'ai besoin d'intégrer des textes écrit dans word dans mes pages HTML. J'aurais donc besoin d'un programme qui transforme un texte "windows 1252" en un texte "ISO-8859-1". Un tel programme existe t-il?

J'ai téléchargé HTML-kit, Unired pour tenter de faire cette transformation, mais je n'ai pas trouvé comment faire. J'utilise aussi DreamWeaver et UltraEdit-32. Existe t-il des solutions avec ces programmes?

Merci

[Jeanluc]

Bonjour mathmax,

notepad.exe (le Bloc-notes de Microsoft) convertit très bien d'un jeu de caractères à l'autre. Il faut spécifier le jeu de caractères (ANSI, Unicode, UTF-8) au moment de la sauvegarde.

Si tu n'as qu'un fichier à convertir, c'est peut-être une solution pour toi.

Jean-Luc

[jeanpierre949]

Salut

Si tu as DW il me semble que tu peux importer des documents word directement dans ton html. fichier >> importer >> document word

[mathmax]

notepad.exe (le Bloc-notes de Microsoft) convertit très bien d'un jeu de caractères à l'autre. Il faut spécifier le jeu de caractères (ANSI, Unicode, UTF-8) au moment de la sauvegarde

Merci Jeanluc, mais lors de la sauvegarde voici les jeux de caractères qui me sont proposés:

-ANSI,

-unicode

-unicode big edian

-UTF8

Il n'y a ni "windows 1252" ni "ISO-8859-1". A moins que ces jeux de carctères soient aussi désignés par des noms ci-dessus?

Si tu as DW il me semble que tu peux importer des documents word directement dans ton html. fichier >> importer >> document word

Merci à toi aussi jeanpierre949. Cependant je ne peux importer qu'en mode création... En plus je ne sais pas trop comment il encode mon texte. J'ai pensé qu'il tenait compte de mon charset, mais en fait en le changeant il n'y a pas de différence.

Autre question: Comment annoncer qu'un texte est en UTF8 (que faut-il mettre dans le Charset?)

[Dudu]

Salut

Choisis UTF-8 c'est idéal pour le web, bien plus même que l'ISO

[Jeanluc]

Autre question: Comment annoncer qu'un texte est en UTF8 (que faut-il mettre dans le Charset?)

Tu mets ceci :

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Jean-Luc

[mathmax]

Merci.

Pour l'UTF8, j'ai entendu dire qu'il pouvait poser pronlèmes avec les langages PHP et ASP et qu'il il n'est pas officiellement supporté par MySQL.

De plus, il parait que quand on envoit ou on reçoit des données il faut faire attention que le logiciel ou le serveur en face connait la problématique des codages caractères et comprend bien qu'on lui envoie de l'UTF8.

En revanche, on dit que l'ISO-8859-1 on n'a pas se problème car c'est le codage "par défaut" de quasi tous les protocoles réseaux.

Et en fait: est-ce que unicode = ISO-8859-1?

Modifié 14 Septembre 2005 par mathmax

[Xavier]

L'unicode c'est une manière de représenter tous les caractères possibles dans un seul jeu de caractères (but : en finir avec tous les encodages incompatibles etc.).

Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères (aucune excuse !)

[Dudu]

Pour l'UTF8, j'ai entendu dire qu'il pouvait poser pronlèmes avec les langages PHP et ASP et qu'il il n'est pas officiellement supporté par MySQL.

Archi faux

Bon bien sûr si tu utilises des versions préhistoriques de MySQL il peut y avoir quelques incompatibilités mais il n'est évidemment pas conseillé (pour des questions de sécurité également) d'utiliser ce genre de versions en 2005.

De plus, il parait que quand on envoit ou on reçoit des données il faut faire attention que le logiciel ou le serveur en face connait la problématique des codages caractères et comprend bien qu'on lui envoie de l'UTF8.

"il paraît"

Moi il me paraît que je n'ai jamais eu de problème: il suffit de définir ses encodages. Où est le problème?

Il faut aussi faire attention que le logiciel ou le serveur en face ait conscience qu'on lui envoie .. de l'ISO-8859-1 ou bien de l'ISO 8859-15 ou bien de l'ISO 8859-16 ou bien du windows-1252 ou bien de l'ASCII ou bien de l'UTF-16 ou bien ... ou bien ...

En revanche, on dit que l'ISO-8859-1 on n'a pas se problème car c'est le codage "par défaut" de quasi tous les protocoles réseaux.

C'est dangereux de travailler en faisant confiance aux valeurs par défaut du serveur (qui c'est vrai sont souvent en ISO 8859-1).

Parce que le jour où ton hébergeur décide de changer quelques petits trucs dans les configs, tu te retrouves dans une galère infernale.

Quoi çà n'arrive jamais un hébergeur qui change ses paramètres du jour au lendemain? Tiens un exemple qui m'est arrivé il y a moins de 2 semaines: l'hébergeur de mon site perso migre son serveur SQL, il faut donc changer tous les fichiers conf pour remplacer "localhost" par "sql.mon-herbergeur.tld". Oui bien sûr l'hébergeur, très sérieux et professionel, m'a envoyé un mail ainsi qu'à tous les autres hébergés. Sauf que l'adresse mail dont dispose mon hébergeur est une obscure BAL de mon FAI que je relève une fois tous les 200 ans. Résultat des courses: grosse frayeur en voyant toutes mes pages avec "Erreur MySQL : 2002 - Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) avant de me dire qu'ils avaient certainement changé un truc et de courir relever mes mails à l'adresse de mon FAI.

Et en fait: est-ce que unicode = ISO-8859-1?

Non, justement.

[mathmax]

Tous ce que j'ai entendu dire se trouve ici:My Webpage

Peux être que je me suis mal exprimé. Dis moi ce qe que tu en penses.

Bon, mais une fois que j'ai choisi mon jeu de carctère, je n'ai pas bien compris comment encoder mes textes. Il faut passer par le bloc-note OK, mais je ne comprend pas bien les options qui me sont proposé lors de la sauvegarde (ANSI,

unicode, unicode big edian). Un petit éclaircicement? Toute cette histoire de jeu de caractère me parait encore bien obscure...

Merci pour l'aide.

[Xavier]

Pour l'UTF8, j'ai entendu dire qu'il pouvait poser pronlèmes avec les langages PHP et ASP et qu'il il n'est pas officiellement supporté par MySQL.

<{POST_SNAPBACK}>

Archi faux

Bon bien sûr si tu utilises des versions préhistoriques de MySQL il peut y avoir quelques incompatibilités mais il n'est évidemment pas conseillé (pour des questions de sécurité également) d'utiliser ce genre de versions en 2005.

<{POST_SNAPBACK}>

Euh... pas si faux que ça en fait

Php ne supporte pas du tout qu'il y ait un BOM (qui indique le sens des bits, voir l'explication que j'ai liée dans mon dernier message). Ça fait tout foirrer et il mets des erreurs. Et il n'est plus possible d'envoyer d'headers.

Moi c'est ce que j'appelle un problème. D'ailleurs des problèmes dus à des logiciels ne supportant pas le BOM sont super nombreux. (autre exemple qui me vient à l'esprit : Mozilla).

Bien entendu, de nombreux éditeurs de texte ont besoin du BOM pour détecter que la page est en utf-8, sinon ils l'ouvrent en windows-1252 (ou pire)... c'est pas que c'est perdu d'avance, mais c'est presque tout comme

Pour MySQL c'est une vraie galère d'utiliser le utf-8, il faut changer plein de choses de partout, en tous cas à ce que j'ai lu c'est pas facile.

Bref, le jour où ce sera supporté partout correctement, BOM compris, on pourra réétudier la question

[mathmax]

Ok, merci pour ces précisions. Je crois que je vais choisir la simplicité (ISO-8859-1), d'autant plus que je n'ai pas des caractères très spéciaux à intégrer dans mes textes.

Question: comment encoder mon texte en ISO-8859-1? On m'a dit de le faire avec le bloc note mais lors de l'enregistrement de mon fichier, dans la rubrique codage il n'y a indiqué ISO-8859-1...

[Jeanluc]

Si tu n'as pas de caractères trop exotiques, l'option ANSI devrait convenir pour obtenir un codage ISO-8859-1 (en tout cas, pour tous les caractères accentués du français).

Jean-Luc

[mathmax]

Ok merci, mais n'est t-il vraiment pas possible d'encoder en ISO-8859-1?

[Xavier]

C'est bien possible que le bloc-notes windows ne le supporte pas. Profites-en pour passer à un éditeur un tout petit peu plus évolué

[mathmax]

J'utilise Dreamweaver. Je pense que lui le fait mais je n'ai pas trouvé comment. Le sais tu?

[loufoque]

Ce que Windows appelle unicode c'est utf-16 et ce qu'il appelle ansi c'est le charset local, windows-1252 sur les systèmes occidentaux.

N'utilise jamais notepad pour quoi que ce soit. En plus en utf-8 il met le BOM (ce qui est plus ou moins une aberration)

Unired est très bien.

Ensuite quant au support dans MySQL ou PHP.

PHP se fout totalement de l'encodage que tu utilises, mais la plupart des fonctions se basent sur le principe que chaque octet est un caractères (strlen par exemple) ce qui est évidemment faux en utf-8. Il peut être utile de recoder certaines fonctions, et iconv et mbstring peuvent aussi fournir quelques trucs. PHP6 arrangera cela et surtout, ce qui est intéressant, c'est qu'il fournira ICU avec collations etc.

MySQL s'en foutait jusqu'à la version 4.1. Maintenant il gère ça (ce qui pose énormement de problèmes aux débutants), l'utilité étant de pouvoir avoir les bonnes collations.

[Xavier]

En plus en utf-8 il met le BOM (ce qui est plus ou moins une aberration)

<{POST_SNAPBACK}>

Pas tant que ça...

L'abération c'est que ce soit encore aussi mal supporté.

Joël Spolsky in Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères (aucune excuse !) :

Hé bien, techniquement, oui, je pense bien que ça pourrait, et, en fait, les premiers implémenteurs voulaient pouvoir stocker leurs points de code Unicode en mode "poids fort derrière" [high-endian] ou "poids fort devant" [low-endian], selon que leur CPU était rapide ou lente dans l'un ou l'autre, et c'était bonnet blanc et blanc bonnet, et cela faisait déjà deux façons de stocker de l'Unicode. Alors les gens furent obligés d'en arriver à la convention bizarre de placer les caractères FE FF au début de toutes les chaînes Unicode; on appela ça une marque d'ordre des octets Unicode (Unicode Byte Order Mark) et si vous intervertissiez vos octets de poids faible et fort ça donnait FF FE, et les gens qui lisaient votre chaîne savaient qu'ils devraient intervertir tous les autres octets. Pfff. Et toutes les chaînes Unicode en liberté dans la nature ne possédent pas cette marque d'ordre des octets au début.

[Verticrawl]

La conversion de caractères est toujours un vrai problème, particulierement quand il s'agit de convertir des datas existantes.

Pour faire cela il faut penser à :

- la charset de la base de données (si vous utilisez MySQL4 et plus [interclassement /collation]

- exporter avec MYSQLDUMP

- convertir avec iconv --from-code [LATIN1] --to-code [uTF-8] (voir man iconv)

- importer dans une nouvelle BD avec le bon interclassement/charset [conseil : creer une nouvelle base pour test )

parenthese : pour MYSQL si vous souhaitez transcrire du latin-1 (iso-8859-1), il faut utiliser le collation utf8_swedish_ci ou latin1_swedish_ci

Pour le contenu html, meme principe mais en changeant l'entete http [meta-equiv] et en verifiant les header http

Pour le serveur apache : attention, il doit envoyer la bonne entete http avec le bon content type (certains hébergeurs ont verrouillés cela, verifier avec l'analyseur d'entete du hub...)

Vous pouvez vous en sortir facilement avec 3 fonctions :

- mysqldump pour l'export sql (creation fichier texte de l'export)

- iconv ou mb_convert pour transcrire les datas (disponibles en php !!!! )

ATTENTION A WINDOWS-1251 !!! et ses caractères maison.

IMPACT CHARSET SUR REFERENCEMENT :

quasi-null car les moteurs parlent systematiquement toutes les charsets. utf-8 est préconisé (il y a qque temps pour ggle) mais cela n'as plus d'impact. On sait que ggle a mis en place des process de correction de charset dans son crawler pour les fautes de charset (un caractere windows-1251 dans de l'iso-8859-1 par exemple).

A contrario, les erreurs de codage (type au lieu de ' ) ont un impact notable sur les moteurs, parce que les séparateurs de texte sont des criteres de pertinence de contenu (proximité de mot, globalité du ranking sur plusieurs termes. [ voir mon intervention sur w3 campus / janvier 2006 ].

Avec un peu de temps et de creativite, vous pouvez migrer vos sites dans la charset de votre choix !

IMPACT CHARSET SUR SITE :

utf-8 est codé sur 1 a 3 octets...physiquement l'espace disque est plus gros...le transfert de datas (bande passante) peut avoir aussi ce facteur 3...

Coté navigateur client...90% sont encore windows (1252 en l'occurence). la transcription de l'utf-8 dans un navigateur peut ralentir l'affichage de votre page.

Coté site : utf-8 et unicode permettent l'intégration de 650 langues dont le chinois ...mais est-ce votre impératif ?

Bon dev

A éviter : notepad, dreamw... pensez plutot Unired (opensource russe) ou Editplus (shareware)...mais méfiez vous de ce que vous faites avec ces outils car ils enregistrent souvent dans la charset de votre pc ! En clair si vous passez à l'utf-8 ...bossez sous linux (mettez les moulinettes sur votre serveur web sous linux) et évitez windows à tout prix.

Modifié 1 Septembre 2006 par Verticrawl