Excel 2004, UTF-8 et autres problèmes

[JJBee]

Bonjour à tou(te)s
Rêve-je (!) ou bien Excel 2004 (de Microsoft Office 2004) est incapable de lire un fichier tabulé codé en UTF-8 (oui, je sais, c'est tout à fait possible avec Open/NeoOffice (ou encore Tables) ;^)) ?
Il s'agit de permettre à des utilisateurs « lambda » d'ouvrir dans Excel 2004 des fichiers (tabulés et codés en UTF-8 donc) que je crée à la volée depuis des données d'une base MySQL à l'aide d'un script PHP. Je peux, bien évidemment, choisir un autre codage (ISO-8859-15 par exemple) mais je suis surpris qu'Excel 2004 ne supporte pas l'UTF-8 (en 2009 !) et de plus j'ai un second problème plus tordu à résoudre :
il semble également que lorsque des sauts de ligne sont dans un champ pourtant délimité par des guillemets (disons une adresse postale du genre : "1 rue Machin (saut de ligne) Bat C") cet a@#$%&ll$ d'Excel considère ce saut de ligne comme la fin de l'enregistrement et place ce qui suit dans une nouvelle ligne de la feuille de calcul. Grrrrrrrrrrrrrrr :^(
L'idéal serait de demander le moins de manipulations « exotiques » aux utilisateurs de ces fichiers.
Une idée ?
Merci d'avance.

 

[Aliboron]

.../... je suis surpris qu'Excel 2004 ne supporte pas l'UTF-8 (en 2009 !)

Comme son nom l'indique quand même un peu, Excel 2004 a quelques années au compteur. Même si on aurait pu souhaiter une meilleure prise en compte de l'Unicode en 2004, il ne faut pas non plus vouloir remonter le temps. La version actuelle c'est Excel 2008... qui n'importe pas non plus les fichiers texte en Unicode !

A priori, il comprend surtout "Occidental (Macintosh)" comme encodage...

e.../... lorsque des sauts de ligne sont dans un champ pourtant délimité par des guillemets (disons une adresse postale du genre : "1 rue Machin (saut de ligne) Bat C") cet a@#$%&ll$ d'Excel considère ce saut de ligne comme la fin de l'enregistrement et place ce qui suit dans une nouvelle ligne de la feuille de calcul. Grrrrrrrrrrrrrrr

Quelle est l'origine de ton fichier ? Je n'arrive pas à reproduire ça (chez moi, le retour chariot reste bien dans une cellule lors de l'import d'un fichier en CSV avec délimitation par des points virgules).

 

[JJBee]

Tout d'abord, merci pour ta réponse (il semblerait que tu sois un spécialiste d'Office ;^)).

Comme son nom l'indique quand même un peu, Excel 2004 a quelques années au compteur. Même si on aurait pu souhaiter une meilleure prise en compte de l'Unicode en 2004, il ne faut pas non plus vouloir remonter le temps. La version actuelle c'est Excel 2008... qui n'importe pas non plus les fichiers texte en Unicode !

Étant donné qu'il est encore mis à jour (11.5.xx) je pouvais espérer que le support de l'UTF-8 soit ajouté (rêvons un peu ;^)).

A priori, il comprend surtout "Occidental (Macintosh)" comme encodage...

Ayant la « main » sur l'encodage du fichier puisque je le crée moi-même à l'aide d'un script PHP, je peux donc en choisir un autre (ISO-8859-15 ou Mac-Roman par ex.). Cependant, cela m'oblige à modifier certains caractères qui, crois-je, n'existent pas en ISO-8859-15 et/ou en Mac-Roman (guillemets simples courbes ?). Ce n'est pas impossible mais c'est « chiant ».

Quelle est l'origine de ton fichier ? Je n'arrive pas à reproduire ça (chez moi, le retour chariot reste bien dans une cellule lors de l'import d'un fichier en CSV avec délimitation par des points virgules).

Il s'agit d'un fichier que je crée à l'aide d'un script PHP avec des données d'une base MySQL en UTF-8. Les champs sont séparés par une tabulation (ajoutée par le script) et à la fin de chaque ligne (enregistrement) un saut de ligne est ajouté. J'ai essayé avec les trois combinaisons possibles : \n,\r et \r\n (ou encore nl, cr et nl+cr) avec le même (mauvais) résultat (avec Office uniquement, Open/Neo Office 3.xx et Tables fonctionnent parfaitement). Mais peut-être ai-je fait une erreur, je regarderai ça plus en détails lorsque j'aurais à nouveau accès à Office (que je n'utilise pas personnellement*;^)).
Merci encore.