[Résolu] Script php convertisseur ANSI/Word/Entités ISO-8859-1

Bonjour tous le monde,

Je suis entrain de créer une page d'administration pour mon site. Avec un module d'édition de tuto. J'avais dans l'idée de convertir mes caractères spéciaux éèàù&ïô par les entités ISO-8859-1 équivalente avec simplement la fonction str_replace().

Mais mais mais, j'ai pensé d'un coup à la possibilité que le texte inséré pourrait être passer par Word avant. Et là c'est une autre paire de manches pour convertir les caractères Word>Entités ISO-8859-1.

Ma question est donc connaissez vous des scripts PHP déjà tout fait ?

J'ai trouvé un autre fil de discutions datant de 2005, peut être que depuis des solutions ont été apporté ?
http://forum.alsacreations.com/topic-2-2566-1-Le-validateur-me-retourne-non-SGML-character-number-146.html
Modifié par Spark (23 Sep 2007 - 18:42)

Pourquoi utiliser des entités? L'encodage ISO-8859-1 fonctionnera parfaitement avec les caractères accentués (sauf certains caractères comme œ, Œ, €, etc). Le mieux, c'est d'utiliser UTF-8, là tu auras une table de caractère complète et même plus (caractères arabes, chinois, thaï, etc).
Modifié par Patidou (14 Jul 2007 - 18:38)

Merci pour ta réponse.

Pourquoi utiliser des entités ? Parce qu'elle existe.

Et pourquoi ne pas utiliser UTF-8 ? Parce ça ne correspond pas à mes besoins, mon site est Francophone (et voir anglophone). Et ça ne répond à pas au problème de Word.
Modifié par Spark (14 Jul 2007 - 21:59)

Les entités ne servent plus à grand chose de nos jours*, elles étaient surtout utilisées dans le cas de l'encodage us-ascii ou quand les programmes n'étaient pas capables d'encoder/visualiser correctement les caractères. Mais maintenant cela fait longtemps que ces problèmes sont résolus.

Pour le cas de l'UTF-8, je te signale qand même que les ligatures œ et Œ (entre autres) sont utilisées en français notamment dans les mots avec œu comme : cœur, sœur, mœurs, œuf, etc mais aussi œil… Mais bon, tu fais comme tu veux…

Pour le cas de word, je ne comprends pas bien… Si les gens tapent leur textes dans Word, il y aura bien un moment où ils vont le copier-coller dans un formulaire pour l'entrer dans une base de données non? Ou j'ai rien compris…



*sauf pour bien sûr : <, >, & et éventuellement les guillemets.
Modifié par Patidou (15 Jul 2007 - 01:11)

a écrit :
Pour le cas de word, je ne comprends pas bien… Si les gens tapent leur textes dans Word, il y aura bien un moment où ils vont le copier-coller dans un formulaire pour l'entrer dans une base de données non? Ou j'ai rien compris…

Si tu as très bien compris, mais à ce que je sache l'UTF-8 ne prend pas en charge les caractère de word (comme les "jolies" apostrophes courbé). Et au delà de ça même si je me plante complet, je suis sur d'une chose, ces caractères ne sont pas valide xhtml strit 1.0.

a écrit :
*sauf pour bien sûr : <, >, & et éventuellement les guillemets.

Ainsi que œ et Œ.

Bon ok tu m'as convaincu pour l'UFT8 (bien que alsacreations ne l'utilise pas, comment ca marche non plus, webmaster-hub également, )

Reste le problème de worl, j'ai pas envi de me cesser le c.l à faire un site valide si c'est pour le pourrir avec ça.
Modifié par Spark (15 Jul 2007 - 01:53)

Spark a écrit :
Si tu as très bien compris, mais à ce que je sache l'UTF-8 ne prend pas en charge les caractère de word (comme les "jolies" apostrophes courbé). Et au delà de ça même si je me plante complet, je suis sur d'une chose, ces caractères ne sont pas valide xhtml strit 1.0.

Je crois que justement ces jolies apostrophes courbées sont dans UTF-8. Mais je n'ai pas word pour tester… Le mieux c'est de faire rapidos une petit page en utf-8, de coller un bout de texte pour tester et de passer la page dans le validateur. A mon avis ils seront valides en UTF-8. C'est comme le caractère «trois points de suspension (…)» qui est aussi invalide en iso mais valide en UTF-8.

Modifié par Patidou (15 Jul 2007 - 09:02)

Elles sont bien en utf-8, mais word n'utilise pas le bon code point. Il utilise la plage 128-255 je crois, qui est invalide en utf

a écrit :

Pourquoi utiliser des entités ? Parce qu'elle existe.

« Pourquoi utiliser XHTML 1.1 ? Parce que ça existe et que c'est récent. »
Tu vois, c'est pas parce que ça existe qu'il faut forcément l'utiliser, donc c'est un raisonnement absurde.

Pour word, en fait, il faut convertir tous les caractères dans la plage 128-160 par leur entité si tu travailles en iso. En utf8 en théorie tu n'as pas à y toucher. En téhorie.... parce que word utilise un encodage propriétaire microsoft qui se rapproche de l'iso et ce n'est pas du tout sûr que la conversion se fasse automatiquement et correctement (cf encodages Windows:XXXX parfois appelé également CPXXXX, XXXX étant un nombre allant approximativement de 1250 à 1260 désignant les différentes variations de cet encodage. Pour le français et les langues européennes de l'ouest en général, il s'agit du 1252).
Pour trouver la liste des entités correspondantes à ces caractères en iso, Google est ton ami. Les caractèrs incriminés sont, entre autres : euro, guillemets saxons, points de suspension, pour mille, ligature oe, apostrophes typographiques recourbées, puce, etc.

QuentinC a écrit :
Pour trouver la liste des entités correspondantes à ces caractères en iso, Google est ton ami.

Y'a plus près Codage valide des caractères Windows illégaux en HTML et XHTML sur openweb

FlorentG a écrit :

Y'a plus près Codage valide des caractères Windows illégaux en HTML et XHTML sur openweb

Merci mais les entités j'ai au moins 3 liens avec le tableau de correspondance. Ce que je cherchais c'est script tout fait (gain de temps) car je ne suis quand même pas le seul gar au monde à vouloir avoir un code valide

Mais bon je vais m'y coller et essayé dans faire un moi même. Auriez vous des conseils ?

Parce que je ne pense pas qu'un truc comme ça soit optimal :

$texte=str_replace('€', '&euro', $texte);
$texte=str_replace('‚', '‚', $texte);
etc. ...

Modifié par Spark (17 Jul 2007 - 20:17)

Salut Spark,

une petite fonction comme ça :

<?php
// Définition de la fonction ClrWord
function ClrWord( $Texte )
{
$string = array("€" => "&euro;", "‚" => "&sbquo;", "ƒ" => "&fnof;", "„" => "&bdquo;", "…" => "&hellip;", "†" => "&dagger;", "‡" => "&Dagger;", "ˆ" => "&circ;", "‰" => "&permil;", "Š" => "&Scaron;", "‹" => "&lsaquo;", "Œ" => "&OElig;", "Ž" => "Z", "‘" => "&lsquo;", "’" => "&rsquo;", "“" => "&ldquo;", "”" => "&rdquo;", "•" => "&bull;", "–" => "&ndash;", "—" => "&mdash;", "˜" => "&tilde;", "™" => "&trade;", "š" => "&scaron;", "›" => "&rsaquo;", "œ" => "&oelig;", "ž" => "z", "Ÿ" => "&Yuml;");
$Texte = strtr("$Texte", $string);
return $Texte;
}
?>

A+

Hmm merci j'aime ça, voilà de quoi en apprendre un peu plus sur la fonction array de façon utile et très concrète pour moi.


Mais dis moi, il n'y a plus rien à faire, il y 'a déjà tout


Thanks

You're welcome !

a écrit :

Codage valide des caractères Windows illégaux en HTML et XHTML
sur openweb

C'est précisément à ce document-là que je pensais, je ne le retrouvais plus.

QuentinC a écrit :

Pourquoi utiliser des entités ? Parce qu'elle existe.

« Pourquoi utiliser XHTML 1.1 ? Parce que ça existe et que c'est récent. »
Tu vois, c'est pas parce que ça existe qu'il faut forcément l'utiliser, donc c'est un raisonnement absurde.

Pour précisé, j'ai commencé à faire ça car mes caractères spéciaux c'étaient mis du jour au lendemain à être remplacé par des truc du genre "A@" (c'est pas arrivé tout seul bien sur), donc rien d'absurde la dedans. Bien que j'ai fini par résoudre ce problème je n'ai jamais compris pourquoi la manip' que j'avais faite à marché.
Modifié par Spark (19 Jul 2007 - 22:44)

Quelle manip ?

Spark a écrit :
Pour précisé, j'ai commencé à faire ça car mes caractères spéciaux c'étaient mis du jour au lendemain à être remplacé par des truc du genre "A@"

Plutot é ? C'est des caractères utf-8 affiché comme si c'était du iso-8859-1. Donc tes caractères étaient bon, manquait juste les bon header/meta pour indiquer que c'était de l'utf

Et bien j'ai pris ma sauvegarde SQL je l'ai ouvert avec notepad++ et j'ai tout converti en UTF-8, tous mes é on été remplacé par é, j'ai mis cette joyeuseté dans la BDD et haut miracle tout était affiché normalement (alors qu'a la base c'était un fausse manip').

Avant (ou après je sais plus) ça j'avais modifié le headers via php pour déclarer le jeux de caractère ISO-8859-1, car je me suis aperçu qu'avec un base mysql5 rien n'était spécifié (contrairement avec mes BDD en v4).

Encore avant ça j'ai passé ma BDD en latin-general car par défaut c'était en german.


Enfin bref à l'heure actuelle je sais même plus ce qu'il y a dans la BDD, mdr.

Bon allé pour mettre cça au claire je vais voir ..[voyage temporel].. je n'ai plus de é dans la BDD mais bien des éè etc, maintenant que j'y pense je crois que j'avais fini par tout ouvrir et réenregistré. Je dois dire que c'est le bordel dans ma tête, j'étais tellement crevé.

Alors c'était pas du jour au lendemain, c'était lors de la migration MySQL 4 => 5.
J'ai eu de la chance pour ma part, mon changement d'hébergeur avec un passage de 3.23 à 5.1 s'est passé sans encombre. J'ai défini Latin-1 partout et c'est allé comme une lettre à la poste. A la base je n'avais que des .sql encodés en iso pour faire le transfert.

Spark a écrit :
tous mes é on été remplacé par é,

Il n'ont pas été remplacés par é, il ont été convertis en utf-8 Maintenant si le logiciel croit que c'est de l'iso, il va afficher é. L'utf-8 est un encoding multi-bytes, donc certains caractère peuvent être codés sur plusieurs octets (donc le é est codé sur 2 octets).

En fait un des trucs les plus importants avec l'encoding, c'est dire au logiciel/navigateur/sgbd quel encoding tu veux utiliser. Si on ne lui indique pas le bon, il risque d'afficher n'importe quoi. Et comme la plupart des trucs affichent par défaut de l'iso-8859-1, on voit s'afficher des trucs louchent genre é