Je suis devant un problème assez ennuyeux et j'aimerais votre avis.
J'ai une appli de publipostage permettant d'envoyer des messages
facilement à tout le personnel. Les envois peuvent ête fait de machine
Windows, Unix/Linux, MacOS ... chacune avec son propre codage de
caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare
que les utilisateurs utilisent Word ou autres pour effectuer la
rédaction préliminaire, qui rajoute de nombreux caractères "loufoques"
bien spécifiques à Windows.
Comment faire pour unifier toutes ces sources pendant le traitement et
que chaque destinataire reçoive le message de façon lisible ?
Tout transformer en ASCII n'est pas une solution et imposer des
transformation suivant les codes de caractères peut poser problème. Par
exemple:
- le code cp1252 (156) correspont au "e dans l'o", et (189) en Iso. Si
on transforme en Iso les clients windows verront un 1/2 à la place (code
cp1252 189)
- l'euro se code 128 en cp1252 et 164 en Iso, qui correspond aussi en
cp1252 au "symbole monétaire" (le rond avec des traits)
- ...
Donc pas mal d'embètements en perspective pour tout rendre correctement.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jedi121
"Tulan" a écrit le 14/01/2004 :
Salut à tous.
Je suis devant un problème assez ennuyeux et j'aimerais votre avis.
J'ai une appli de publipostage permettant d'envoyer des messages facilement à tout le personnel. Les envois peuvent ête fait de machine Windows, Unix/Linux, MacOS ... chacune avec son propre codage de caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare que les utilisateurs utilisent Word ou autres pour effectuer la rédaction préliminaire, qui rajoute de nombreux caractères "loufoques" bien spécifiques à Windows.
Comment faire pour unifier toutes ces sources pendant le traitement et que chaque destinataire reçoive le message de façon lisible ?
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le permet pas en natif (voir http://fr.php.net/types.string ). Par contre il faudrait peut-être creuser du côté de UTF8 http://fr2.php.net/utf8_encode
"Tulan" a écrit le 14/01/2004 :
Salut à tous.
Je suis devant un problème assez ennuyeux et j'aimerais votre avis.
J'ai une appli de publipostage permettant d'envoyer des messages
facilement à tout le personnel. Les envois peuvent ête fait de machine
Windows, Unix/Linux, MacOS ... chacune avec son propre codage de
caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare
que les utilisateurs utilisent Word ou autres pour effectuer la
rédaction préliminaire, qui rajoute de nombreux caractères "loufoques"
bien spécifiques à Windows.
Comment faire pour unifier toutes ces sources pendant le traitement et
que chaque destinataire reçoive le message de façon lisible ?
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le
permet pas en natif (voir http://fr.php.net/types.string ).
Par contre il faudrait peut-être creuser du côté de UTF8
http://fr2.php.net/utf8_encode
Je suis devant un problème assez ennuyeux et j'aimerais votre avis.
J'ai une appli de publipostage permettant d'envoyer des messages facilement à tout le personnel. Les envois peuvent ête fait de machine Windows, Unix/Linux, MacOS ... chacune avec son propre codage de caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare que les utilisateurs utilisent Word ou autres pour effectuer la rédaction préliminaire, qui rajoute de nombreux caractères "loufoques" bien spécifiques à Windows.
Comment faire pour unifier toutes ces sources pendant le traitement et que chaque destinataire reçoive le message de façon lisible ?
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le permet pas en natif (voir http://fr.php.net/types.string ). Par contre il faudrait peut-être creuser du côté de UTF8 http://fr2.php.net/utf8_encode
Tulan
Jedi121 wrote:
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le permet pas en natif (voir http://fr.php.net/types.string ). Par contre il faudrait peut-être creuser du côté de UTF8 http://fr2.php.net/utf8_encode
Merci de l'info je vais voir ça ... mais il reste un problème: qu'en est-il du support UTF-8 dans les clients de messageries ? Je sais que Mozilla le gère sans problème, mais c'est hélas un client marginal dans le parc, la grande majorité étant OE ou Eudora 4.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des substitutions en fonction des tables cp1252, Iso ... ?
--------------------- Enlevez le 0 pour m'écrire
Jedi121 wrote:
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le
permet pas en natif (voir http://fr.php.net/types.string ).
Par contre il faudrait peut-être creuser du côté de UTF8
http://fr2.php.net/utf8_encode
Merci de l'info je vais voir ça ... mais il reste un problème: qu'en
est-il du support UTF-8 dans les clients de messageries ? Je sais que
Mozilla le gère sans problème, mais c'est hélas un client marginal dans
le parc, la grande majorité étant OE ou Eudora 4.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des
substitutions en fonction des tables cp1252, Iso ... ?
Je répondrai UNICODE mais malheureusement il me semble que PHP ne le permet pas en natif (voir http://fr.php.net/types.string ). Par contre il faudrait peut-être creuser du côté de UTF8 http://fr2.php.net/utf8_encode
Merci de l'info je vais voir ça ... mais il reste un problème: qu'en est-il du support UTF-8 dans les clients de messageries ? Je sais que Mozilla le gère sans problème, mais c'est hélas un client marginal dans le parc, la grande majorité étant OE ou Eudora 4.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des substitutions en fonction des tables cp1252, Iso ... ?
--------------------- Enlevez le 0 pour m'écrire
Olivier Miakinen
J'ai une appli de publipostage permettant d'envoyer des messages facilement à tout le personnel. Les envois peuvent ête fait de machine Windows, Unix/Linux, MacOS ... chacune avec son propre codage de caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare que les utilisateurs utilisent Word ou autres pour effectuer la rédaction préliminaire, qui rajoute de nombreux caractères "loufoques" bien spécifiques à Windows.
En effet.
Comment faire pour unifier toutes ces sources pendant le traitement et que chaque destinataire reçoive le message de façon lisible ?
La seule unification possible est Unicode, avec UTF-8 pour la transmission dans des caractères 8-bits.
Tout transformer en ASCII n'est pas une solution
Non, en effet. Tu nivellerais par le bas au lieu de le faire par le haut.
et imposer des transformation suivant les codes de caractères peut poser problème. Par exemple: - le code cp1252 (156) correspont au "e dans l'o", et (189) en Iso.
En ISO-8859-15, tu veux dire. Il n'existe pas en ISO-8859-1 ni dans la plupart des autres encodages ISO.
Si on transforme en Iso les clients windows verront un 1/2 à la place (code cp1252 189)
Ceux qui tententeraient d'afficher ce caractère ISO-8859-15 en CP1252 verraient en effet « 1/2 ». Note que ceux qui tenteraient de l'afficher en ISO-8859-1 verraient la même chose que CP1252.
- l'euro se code 128 en cp1252 et 164 en Iso, qui correspond aussi en cp1252 au "symbole monétaire" (le rond avec des traits)
Donc pas mal d'embètements en perspective pour tout rendre correctement.
Oui. Une solution consisterait effectivement à tout transformer en UTF-8. Mais tu n'as peut-être pas besoin d'aller jusque là. Si simplement tu précises le charset utilisé dans le message que tu envoies, cela doit marcher dans la plupart des cas, sauf peut-être pour des encodages exotiques.
Par exemple, ton article sur fclp contient ces entêtes : Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit
--------------------- Enlevez le 0 pour m'écrire
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où quelqu'un prendra l'adresse il recevra tout le spam qui t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la forme .
J'ai une appli de publipostage permettant d'envoyer des messages
facilement à tout le personnel. Les envois peuvent ête fait de machine
Windows, Unix/Linux, MacOS ... chacune avec son propre codage de
caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare
que les utilisateurs utilisent Word ou autres pour effectuer la
rédaction préliminaire, qui rajoute de nombreux caractères "loufoques"
bien spécifiques à Windows.
En effet.
Comment faire pour unifier toutes ces sources pendant le traitement et
que chaque destinataire reçoive le message de façon lisible ?
La seule unification possible est Unicode, avec UTF-8 pour la
transmission dans des caractères 8-bits.
Tout transformer en ASCII n'est pas une solution
Non, en effet. Tu nivellerais par le bas au lieu de le faire par le haut.
et imposer des
transformation suivant les codes de caractères peut poser problème. Par
exemple:
- le code cp1252 (156) correspont au "e dans l'o", et (189) en Iso.
En ISO-8859-15, tu veux dire. Il n'existe pas en ISO-8859-1 ni dans la
plupart des autres encodages ISO.
Si on transforme en Iso les clients windows verront un 1/2 à la place (code
cp1252 189)
Ceux qui tententeraient d'afficher ce caractère ISO-8859-15 en CP1252
verraient en effet « 1/2 ». Note que ceux qui tenteraient de l'afficher
en ISO-8859-1 verraient la même chose que CP1252.
- l'euro se code 128 en cp1252 et 164 en Iso, qui correspond aussi en
cp1252 au "symbole monétaire" (le rond avec des traits)
Donc pas mal d'embètements en perspective pour tout rendre correctement.
Oui. Une solution consisterait effectivement à tout transformer en
UTF-8. Mais tu n'as peut-être pas besoin d'aller jusque là. Si
simplement tu précises le charset utilisé dans le message que tu
envoies, cela doit marcher dans la plupart des cas, sauf peut-être pour
des encodages exotiques.
Par exemple, ton article sur fclp contient ces entêtes :
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
---------------------
Enlevez le 0 pour m'écrire
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que
tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où
quelqu'un prendra l'adresse tulan0@chez.com il recevra tout le spam qui
t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la
forme tulan0@chez.com.invalid .
J'ai une appli de publipostage permettant d'envoyer des messages facilement à tout le personnel. Les envois peuvent ête fait de machine Windows, Unix/Linux, MacOS ... chacune avec son propre codage de caractères (cp1252, Iso-8859-1, macroman ...). De plus il n'est pas rare que les utilisateurs utilisent Word ou autres pour effectuer la rédaction préliminaire, qui rajoute de nombreux caractères "loufoques" bien spécifiques à Windows.
En effet.
Comment faire pour unifier toutes ces sources pendant le traitement et que chaque destinataire reçoive le message de façon lisible ?
La seule unification possible est Unicode, avec UTF-8 pour la transmission dans des caractères 8-bits.
Tout transformer en ASCII n'est pas une solution
Non, en effet. Tu nivellerais par le bas au lieu de le faire par le haut.
et imposer des transformation suivant les codes de caractères peut poser problème. Par exemple: - le code cp1252 (156) correspont au "e dans l'o", et (189) en Iso.
En ISO-8859-15, tu veux dire. Il n'existe pas en ISO-8859-1 ni dans la plupart des autres encodages ISO.
Si on transforme en Iso les clients windows verront un 1/2 à la place (code cp1252 189)
Ceux qui tententeraient d'afficher ce caractère ISO-8859-15 en CP1252 verraient en effet « 1/2 ». Note que ceux qui tenteraient de l'afficher en ISO-8859-1 verraient la même chose que CP1252.
- l'euro se code 128 en cp1252 et 164 en Iso, qui correspond aussi en cp1252 au "symbole monétaire" (le rond avec des traits)
Donc pas mal d'embètements en perspective pour tout rendre correctement.
Oui. Une solution consisterait effectivement à tout transformer en UTF-8. Mais tu n'as peut-être pas besoin d'aller jusque là. Si simplement tu précises le charset utilisé dans le message que tu envoies, cela doit marcher dans la plupart des cas, sauf peut-être pour des encodages exotiques.
Par exemple, ton article sur fclp contient ces entêtes : Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit
--------------------- Enlevez le 0 pour m'écrire
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où quelqu'un prendra l'adresse il recevra tout le spam qui t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la forme .
Tulan
Merci pour ces informations, elles confirment mes réflexions sur ce problème.
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où quelqu'un prendra l'adresse il recevra tout le spam qui t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la forme .
Mmmmhh ... je dois avouer que je n'avais pas fait attention à cela, toutes mes excuses je change cela ;)
Merci pour ces informations, elles confirment mes réflexions sur ce
problème.
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que
tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où
quelqu'un prendra l'adresse tulan0@chez.com il recevra tout le spam qui
t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la
forme tulan0@chez.com.invalid .
Mmmmhh ... je dois avouer que je n'avais pas fait attention à cela,
toutes mes excuses je change cela ;)
Merci pour ces informations, elles confirment mes réflexions sur ce problème.
J'espère que tu as réservé les deux adresses (avec et sans le 0) et que tu te contentes de ne pas relever la boîte avec un 0. Sinon, le jour où quelqu'un prendra l'adresse il recevra tout le spam qui t'était destiné.
Dans les deux cas, je te conseille de donner ta fausse adresse sous la forme .
Mmmmhh ... je dois avouer que je n'avais pas fait attention à cela, toutes mes excuses je change cela ;)
Olivier Miakinen
[...] qu'en est-il du support UTF-8 dans les clients de messageries ? Je sais que Mozilla le gère sans problème, mais c'est hélas un client marginal dans le parc, la grande majorité étant OE ou Eudora 4.
Je crois bien que l'immense majorité des clients actuels le gèrent. Pour commencer, tu peux être sûr que tous ceux qui savent afficher du HTML savent aussi interpréter de l'UTF-8 : cela peut te donner une idée. Pour plus d'infos, voir fr.usenet.8bits (non modéré).
Attention, je ne veux pas dire pour autant qu'il faut absolument utiliser UTF-8.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des substitutions en fonction des tables cp1252, Iso ... ?
Plus exactement, tu dois connaître le codage du message pour envoyer la bonne information de charset. Tout ceci me semble de plus en plus dans le thème de fr.usenet.8bits, aussi j'y dirige la suite de la discussion.
[...] qu'en
est-il du support UTF-8 dans les clients de messageries ? Je sais que
Mozilla le gère sans problème, mais c'est hélas un client marginal dans
le parc, la grande majorité étant OE ou Eudora 4.
Je crois bien que l'immense majorité des clients actuels le gèrent. Pour
commencer, tu peux être sûr que tous ceux qui savent afficher du HTML
savent aussi interpréter de l'UTF-8 : cela peut te donner une idée.
Pour plus d'infos, voir fr.usenet.8bits (non modéré).
Attention, je ne veux pas dire pour autant qu'il faut absolument
utiliser UTF-8.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des
substitutions en fonction des tables cp1252, Iso ... ?
Plus exactement, tu dois connaître le codage du message pour envoyer la
bonne information de charset. Tout ceci me semble de plus en plus dans
le thème de fr.usenet.8bits, aussi j'y dirige la suite de la discussion.
[...] qu'en est-il du support UTF-8 dans les clients de messageries ? Je sais que Mozilla le gère sans problème, mais c'est hélas un client marginal dans le parc, la grande majorité étant OE ou Eudora 4.
Je crois bien que l'immense majorité des clients actuels le gèrent. Pour commencer, tu peux être sûr que tous ceux qui savent afficher du HTML savent aussi interpréter de l'UTF-8 : cela peut te donner une idée. Pour plus d'infos, voir fr.usenet.8bits (non modéré).
Attention, je ne veux pas dire pour autant qu'il faut absolument utiliser UTF-8.
N'y a-t-il pas moyen de tester le codage du message pour appliquer des substitutions en fonction des tables cp1252, Iso ... ?
Plus exactement, tu dois connaître le codage du message pour envoyer la bonne information de charset. Tout ceci me semble de plus en plus dans le thème de fr.usenet.8bits, aussi j'y dirige la suite de la discussion.
Jean-Marc Molina
Je te conseille de tout transformer en UTF8, si possible à la source. Jete un coup d'oeil aux libs iconv et MBS. Tu peux transformer des textes d'un charset vers un autre. Dans mon cas mes pages sont en UTF8 alors la saisie s'opère en UTF8, j'intègre aussi des documents issus d'OpenOffice.org, en UTF8 alors qu'avant j'étais en ISO-8859-1/15. Tout dépend du contrôle que tu as sur les applications distantes. Pour les clients ils supportent tous en majorité UTF8 (Outlook, navigateurs...), donc aucun problème de ce côté.
JM
-- Europe > France > Lyon Clé anti-pourriel : « PASUNPOURRIEL » (doit apparaître dans le sujet ou le corps de votre message si vous me répondez personnellement)
Je te conseille de tout transformer en UTF8, si possible à la source.
Jete un coup d'oeil aux libs iconv et MBS. Tu peux transformer des textes
d'un charset vers un autre.
Dans mon cas mes pages sont en UTF8 alors la saisie s'opère en UTF8,
j'intègre aussi des documents issus d'OpenOffice.org, en UTF8 alors qu'avant
j'étais en ISO-8859-1/15. Tout dépend du contrôle que tu as sur les
applications distantes.
Pour les clients ils supportent tous en majorité UTF8 (Outlook,
navigateurs...), donc aucun problème de ce côté.
JM
--
Europe > France > Lyon
Clé anti-pourriel : « PASUNPOURRIEL » (doit apparaître dans le sujet ou le
corps de votre message si vous me répondez personnellement)
Je te conseille de tout transformer en UTF8, si possible à la source. Jete un coup d'oeil aux libs iconv et MBS. Tu peux transformer des textes d'un charset vers un autre. Dans mon cas mes pages sont en UTF8 alors la saisie s'opère en UTF8, j'intègre aussi des documents issus d'OpenOffice.org, en UTF8 alors qu'avant j'étais en ISO-8859-1/15. Tout dépend du contrôle que tu as sur les applications distantes. Pour les clients ils supportent tous en majorité UTF8 (Outlook, navigateurs...), donc aucun problème de ce côté.
JM
-- Europe > France > Lyon Clé anti-pourriel : « PASUNPOURRIEL » (doit apparaître dans le sujet ou le corps de votre message si vous me répondez personnellement)
