Microsoft Outlook crashe lors de la lecture des e-mails avec des tableaux
Le 03 août 2022 à 06h28
1 min
Internet
Internet
Microsoft explique que le problème apparaît « lorsque vous ouvrez, répondez ou transférez des e-mails contenant des tableaux complexes » tels que des reçus Uber, relève BleepingComputer.
De plus, le bug affecte également Microsoft Word. Ses équipes ont développé des correctifs qui devraient être disponibles le 9 août.
En attendant, Microsoft propose une solution de contournement obligeant ses clients et utilisateurs à revenir à une version non affectée par le bug.
Le 03 août 2022 à 06h28
Commentaires (36)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 03/08/2022 à 07h44
Ben oui, mais si les gens commencent à mettre du contenu dans leurs messages aussi, on est pas rendu ! :/
Le 03/08/2022 à 07h47
/mode vieux con on
e-mail = texte brut + pièce jointe et comme ça tout roule
/mode vieux con off
Le 03/08/2022 à 07h52
Oui
et telnet en lecteur de mail.Edit : telnet pour extraire la pièce jointe, ça risque d’être compliqué.
Le 03/08/2022 à 08h04
Tout de suite …
Et tant que tu y es, pourquoi pas mutt et consort ?
Non, même Outlook sait faire des messages en texte brut.
Le 03/08/2022 à 08h36
Certes, mais sait-il seulement les lire ?
Le 03/08/2022 à 09h16
Je ne sais même pas étant donné que je dois être le seul de ma boîte à envoyer des messages en texte brut.
Le 03/08/2022 à 20h35
quitte à faire du telnet, autant faire du Gopher
Le 03/08/2022 à 22h20
Bah non, telnet permet de vraiment de récupérer des mails en pop3 sur un serveur. Je l’ai déjà fait.
Ça m’étonnerait que ça soit possible avec Gopher.
Le 03/08/2022 à 08h22
Ah, les joies du HTML sous outlook …
Je sais pas comment ça se passe dans les derniers versions d’Outlook (hors web), mais à l’époque d’outlook 2010, la lecture des mails “HTML” se faisait en utilisant le moteur de rendu HTML de … Word.
Avec une limitation amusante : Word étant fait pour du texte, les GIF n’étaient donc pas animés …
Et donc dans outlook, tous les gif étaient “fixes” … 🙄
J’espère que les dernières versions d’oulook utilisent le moteur d’Edge (ou au pire d’IE11 …)
Parce que là, un bug d’affichage de “tableau”, c’est ballot, tout de même …
Le 03/08/2022 à 14h52
A date, c’est toujours le moteur HTML Word d’utiliser dans la suite Microsoft 365 Apps. Depuis avril 2021, certains modules comme la recherche de salles s’appuie sur le moteur webview2 sous Edge Chromium mais grand-chose pour le moment.
Microsoft
Le “renouveau” devrait venir avec le client One Outlook qui n’est autre qu’un webview.
Le 03/08/2022 à 09h37
Du markdown partout !!
Le 03/08/2022 à 09h49
Si à 50 ans tu ne sais pas utiliser uudecode, tu as raté ta vie.
Le 03/08/2022 à 09h54
C’est vrai que markdown c’est vraiment le top pour faire des tableaux
(et c’est un fan de markdown qui écrit ce message)
Le 03/08/2022 à 13h17
La syntaxe de DokuWiki pour les tableaux est plus souple que celle de Markdown, tout en étant aussi lisible.
Le 03/08/2022 à 14h32
UUDecode : pu le coup de vieux …
Le 03/08/2022 à 15h59
Décidément, ça pète la forme chez MicroSoft en ce moment…
Le 03/08/2022 à 17h04
Il faudrait pas confondre le HTML5 qui est au top avec CSS, avec le HTML de word qui farcis toutes les balises avec des styles word à en gerber.
Le HTML façon Microsoft est la synthèse des mauvaises pratiques.
De base, il est indispensable de séparer le fond et la forme. C’est la raison pour laquelle il existe les balises h1, h2… pour les titres, les balises pour le enphases, celles pour les listes…. dans le vrai HTML
Dans Word, en résumé, il n’existe que des paragraphes et des tableau. La seule chose qui différentiel un titre 1 et un paragraphe est la mise en forme. C’est la balise w:p (paragraphe de word), qui est utilisée dans tous les cas.
La gestion des tableaux dans Word est une catastrophe car la notion de colonne disparaît contrairement au vrai HTML. Mis il y a pire: one note (mais c’est une autre histoire).
Pour en revenir à ton commentaire, le markdown, c’est top pour prendre des notes en quasi temps-réel mais faire des sites en markdown est juste une connerie. Les deux language n’ont simplement pas la même utilité.
Le 04/08/2022 à 09h01
Word, en tant que traitement de texte, est à la merci de ce qu’en font les utilisateurs : ils tapent du texte n’importe comment, mettent en page n’importe comment en changeant les polices n’importe comment, les tailles, etc. la plupart du temps n’importe comment sans se préoccuper des styles. Quand bien sûr ils ne font pas autant de paragraphes vides que nécessaire pour passer (n’importe comment) à la page suivante.
Tu vois le point précis sur lequel j’insiste ? C’est encore plus vrai dans un e-mail.
Espérer convertir le foutoir introduit par l’utilisateur vers du HTML proprement structuré est voué à l’échec. Honnêtement, je préfère largement qu’ils reproduisent fidèlement le bordel introduit par l’utilisateur plutôt qu’essayer d’y coller arbitrairement un semblant de structure sucée du pouce…
Accessoirement, le forum de NxI utilise markdown…
Le 03/08/2022 à 17h06
Extraire une PJ via Telnet, je m’y suis frotté (pour le fun) et ce n’est pas si compliqué que ça (merci Notepad++)
Le 03/08/2022 à 18h25
Pour envoyer du contenu riche dans un email, markdown serait largment suffisant.
A part le put*in de “souligné”, y a pas grand chose qui me manquerait dans mes emails et documents pro si on mettait du markdown partout.
Le 04/08/2022 à 08h05
C’est de toute façon de plus en plus en vogue dans les outils collaboratifs. Typiquement Confluence le supporte pour la mise en forme, et c’est super pratique pour appliquer un style hiérarchique rapide à un doc.
Et à titre perso mon blog est entièrement en markdown, rendu par Hugo (avec quelques shortcodes à la rescousse pour les petits trucs plus fancy).
Après le souci de markdown, c’est qu’il n’est manque encore de standardisation il me semble avec les flavors et implémentations custom qui se sont développées (et je pense que c’est celle de GitHub qui est la plus utilisée).
Le 04/08/2022 à 12h56
Ce qui se rapproche le plus d’un standard est CommonMark et c’est effectivement le format implémenté par Github, Gitlab et d’autres.
Le 03/08/2022 à 20h26
L autre jour j ai voulu envoyer mon premier mailing liste pour mon asso. Plein de bonne volonté j’utilise tous les derniers standard de pointe en HTML CSS. Je vérifie le tout sur Thunderbird , j envoie. Puis me viens l’idée de vérifier le mail sur le webmail de live. Une catastrophe. Ce que j’ignorais c’est que Thunderbird utiliser le moteur de firefox: le luxe! Les autres clients n’utilise pas de moteur comme outlock, et les webclient bloque les 3⁄4 du CSS surtout quand il est séparée, voir même les formats d’image. C est la que j’ai appris que un mail ce programme en… Tableau ! Comme le web en 1998! Je ne comprend pas comment c’est possible d’avoir un format aussi archaïque de nos jours?
Le 04/08/2022 à 08h50
Ah oui, oublie de faire tes mailing list avec du html / css standard, Oulook ne connait pas ça, il utilise son propre moteur de rendu immonde
Oublie même les div, uniquement du
Le 04/08/2022 à 08h21
Pour les courriels, je te rejoint car cela apporte le fond sans complication.
Le gros souci du markdown est la présence de plusieurs dialèctes nés pour contourner les premiers manques comme les tableaux apparus tardivement. J’ai peur que cela se passe comme pour le html au final: un gros foutoir.
Il nous manque donc un standard qui soit appuyé par de grosses boîtes comme pour dkim, spf et dmarc.
Le 04/08/2022 à 08h33
Un standrad comme ça?
Le 04/08/2022 à 09h08
J’ai cru ça aussi, mais finalement j’ai dû me résoudre à utiliser LaTeX parce que franchement y’a pas que les soulignés qui manquent.
Bon d’accord, LaTex n’a pas Mermaid pour les graphiques
Le 04/08/2022 à 10h22
Le standard “de fait” c’est le markdown de github de part l’importance de cette plateforme.
J’ai testé plusieurs programmes/librairies de rendu markdown, et toutes géraient la syntaxe de github.
Au pire, si c’est pas géré, c’est affiché tel quel sans le rendu… et ca reste lisible ! C’est la grande force de markdown comparé à du HTML. Sans le rendu HTML, bonne chance pour comprendre un tableau avec seulement le source HTML :)
Le 04/08/2022 à 12h44
Concernant Outlook, cela fait des décennies que des bogues/failles liés à l’interprétation du contenu surviennent. Je ne sais combien d’autres décennies il faudra afin de convaincre ceux qui croient que ce ne sont que des exceptions.
Si le code HTML est correctement indenté, c’est très lisible.
Le Markdown est un langage intermédiaire, qui sera ensuite compilé dans un autre, par exemple du HTML.
Ce faisant, il cache/supprime des fonctionnalités du langage cible en l’appauvrissant, recentrant sa syntaxe sur les usages supposés majoritaires C’est donc un langage satisfaisant pour une structure simple.
Par exemple, impossible de fusionner lignes ou colonnes d’un tableau, comme dans mon exemple précédent.
Si vous souhaitez profiter la pleine puissance d’un langage, comme dans la vie, mon conseil est qu’il est préférable de se passer des intermédiaire inutiles. :o)
Le 04/08/2022 à 14h20
Certes, le code HTML est lisible. Mais l’information (fond et forme) ne l’est pas.
Sans faire le rendu, difficile de dire ce qui est fusionné et ce qui ne l’est pas dans ton exemple.
HTML permet de faire des tableaux complexes, avec des fusions, du multiligne.
Pas Markdown. Donc Markdown est moins bien… En fait non.
Au départ, quand je suis passé à markdown pour des documents techniques, je vivais cette limitation sur les mises en forme comme une énorme contrainte. Je me suis forçé à ré-écrire mes tableaux pour qu’ils soient non fusionné et sans saut de ligne: une bête grille.
Je trouvais que c’était une régression, mais pas le choix.
Et puis… et puis les gens m’ont dit que mon nouveau document était plus lisible. WTF ??!!
Et en fait, oui. Cette contrainte oblige a structurer plus simplement des informations complexes. C’est donc plus digeste pour le lecteur. Et c’est même devenu plus simple pour moi, le rédacteur.
Le 05/08/2022 à 09h27
Ce n’est pas parce que “les gens” ne savent pas lire une tableau et qu’ils se retrouvent à se perdre avec des cellules fusionnées, qu’il faut nécessairement les encourager dans leur médiocrité.
C’est la limite de la satisfaction des autres, me concernant.
Pour ma part, en revanche, je trouve un tableau souffrant à outrance de redondances parfois difficile à exploiter en tant que lecteur, et source de multiples embûches/erreurs en tant que rédacteur. Ça rejoint les antédiluviens problèmes d’une copie en regard d’une référence.
Comme toujours, il y a un compromis très personnel à effectuer entre simplicité & complétude.
Un langage est parfait quand il convient au besoin, efficace donc. À deux langages à efficacité identique, le plus efficient devrait gagner.
Si le langage intermédiaire Markdown te convient, c’est excellent.
Je suis encore aujourd’hui épaté par les capacités du langage de présentation HTML associé à la mise en forme CSS. La spécification d’origine du premier date d’il y a 30 ans.
Et puis, il y a d’autres rendus possibles, et notamment le prédécesseur XML avec XSLT, et tellement de choses possibles, de manière efficiente, sans compilateur ni “nouveau” langage en surcouche…
Le 05/08/2022 à 13h04
Sauf que c’est surement pour “les gens” que tu écris ton documents et donc ton tableau. Tu dois donc écrire ton document pour qu’il soit le plus efficace pour transmettre les informations que tu veux donner à ton lectorat. Et pour que ce soit efficace, il faut que l’information soit claire, lisible et agréable.
De ce que j’ai compris de ce qu’il dit, c’est qu’en retravaillant ses documents de tel sorte que les tableaux n’ait besoin que d’une structure simple le retour de son lectorat était plus positif. Il en a conclus que l’utilisation de structure complexe pour un tableau rendait une complexité inutile à sa compréhension.
Alors que le but premier d’un tableau est de présenter une information ordonnée de manière claire concise et inpactante, les tableaux complexes ont tendance à rendre confus les lecteurs. Un tableau complexe, c’est trop d’informations, mal présentés. C’est donc une mauvaise figure qui n’aide pas le lecteur à comprendre ton propos.
Le 05/08/2022 à 10h21
Je suis totalement d’accord avc ton analyse côté utilisateurs mais les fondements mêmes des docx et de leurs traduction en html dans les mails ou lors d’un copier coller, sont fondamentalement mauvais. Tout n’ est que forme, il n’y a auun fond. Un tite 1 sous word n’est qu’un paragraphe affublé d’un style avec numérotation. Word ne connaît ni h1 à h6, ni em… que p et les tableaux. C’est précisément ce que décrivent les commentaires précédents dans les capacités de Outlook.
Cela correspond exactement à ce que l’on trouve dans les fichiers xml internes des docx.
Autant les bases d’excel sont très bonnes, autant les équipes en charge de word ont fait de la merde. Il ne s’agit donc pas des utilisateurs dans ce cas précis mais de mauvais choix de l’équipe de dev.
Je base mon analyse sur les formats office xml 2003 (format excel au top et format word totalement bâclée), et sur les formats des docx et xlsx depuis 2007. J’ai déjà eu à corriger à la main des documents docx dont les styles étaient partis en vrille et c’est une horreur sans nom.
J’ai par cotre écrit un programme qui parse les fichers xlsx pour en récupérer le contenu brut et c’est asez simple car le format xlsx est fondamentalement bien pensé..
En VBA, on retrouve les mêmes constats : grandes facilité sous excel et encore plus de choses sympas depuis le xlsx et l’amélioration considérable de la mise en forme conditionnelle, et encore plus de problèmes sous word et principalement une division par 20 des vitesses d’exécution des macros même en empêchant word de repaginer et de coriger l’orthographe et la grammaire à chaque modification.
J’ai même le sentiment que les équipes en chae de word sont en froid avec celles de VB quand on voit les bugs enre VBA et word comme quand on cherche à toucher aux marques de modifications ou à marquer des éléments comme modifiés.
Le 06/08/2022 à 09h49
Que proposes-tu, alors ? Le format Excel est structuré simplement parce qu’un tableau, par principe, est structuré : ce sont des cases, organisées en lignes et colonnes dans des feuilles, dans des fichiers. Un document Word n’est pas structuré, et il est donc logique que la représentation interne ne soit pas structurée non plus.
Si tu veux donner une structure au doument, soit tu trouves un moyen de convertir automagiquement un document non structuré en document structuré (ce qui n’est vraisemblablement pas possible) soit tu trouves un moyen de forcer les utilisateurs à créer exclusivement des documents structurés (ce qui est totalement impossible).
Il ne faut pas oublier que Word se coltine aussi la compatibilité avec les anciens formats, le problème ne date pas du passage au format XML, il était présent depuis toujours.
Quant au reste de tes doléances, oui je compatis, oui il y a des bugs, mais ce n’est pas de la faute au format interne ; s’il y a un problème à gérer les marques de changement en VB, ce problème n’est pas dû au fait que “tout y compris le titre est un paragraphe”, c’est juste … un bug.
Le 07/08/2022 à 13h06
HTML+CSS tout simplement. Je ne connais aucun format de description de document qui leur arrive à la cheville.
La seule et unique bonne idée dans le docx est le principe d’une archive zip contenant tous les éléments. Créer une archive contenant les html et les css et les éléments référencés dans une archive zip ferait un excellent format de document. pourquoi pas des htmlx
Je ne suis pas du tout d’accord avec toi. La structure d’un document, ce sont les principes que l’on retrouve justement dans le markdown car c’est la substance même de l’information: Une hiérarchie de titre, des paragraphes, des listes ordonnées ou non, des emphases ou citations qui avant même d’être du gras ou de l’italique sont des infirmations importantes que le rédacteur souhaite mettre en avant.
Le couple html + css est juste parfait à mon sens: le fond est dans le html et le css s’occupe de la forme. Séparer les deux est primordial.
Ce n’est pas possible pour un algorithme de redonner du fond à un amas de paragraphes. En s’aidant de la mise en forme, un humain peut y arriver.
Quand les documents ont été écrits à partir de bon canevas et de rédacteurs formés, il serait simple de convertir les paragraphes mis en forme de word en bon html ou markdown.
Word sais déjà gérer les ancien formats en mode compatibilité et quelques gros bugs de format sont ainsi déjà corrigé au passage en docx comme les sauts de page qui ne sont plus intégrés dans les paragraphes mais entre les paragraphes (on distingue bien les deux par leur largeur quand on affiche les caractères de mise en page).
Si les équipes de word le voulaient, ils auraient très bien pu améliorer les choses en ce sens dans le format docx. Au lieu de cela, ils ont encore complexifié la gestion des styles et plus particulièrement les styles de numérotation qui se dupliquent à l’utilisation à la moindre modification de numéro (continuer la numérotation ou reprendre à x). Dans mes docs j’ai vu jusqu’à plusieurs dizaines de copies des styles des titres. Impossible à corriger: word fait le ménage de temps en temps mais c’est juste très sale.
On est d’accord, c’est juste l’API qui est toute moisie. Je met juste l’accent sur le fait que word est globalement une grosse bouse truffée d’erreurs diverses. Pour autant, je ne conseille pas libre office avec qui je n’arrive pas à faire simplement les choses de base.
Le 07/08/2022 à 14h22
Merci, tu viens donc de confirmer que, étant donné que le but étant de permettre de représenter en HTML potentiellement TOUS les documents Word ayant jamais été écrits depuis la nuit des temps (y compris ceux importés depuis WordPerfect…), il n’était pas possible de générer du HTML structuré avec des tags sémantiques comme H1 ou EM.
La solution de Microsoft était donc la bonne, non pas qu’elle soit satisfaisante d’un point de vue théorique, mais bien parce que c’est la seule possible.
D’ailleurs LibreOffice ne fait pas autrement.
Heu, non, le couple html+css est très loin d’être parfait, bien au contraire. Une balise telle que H1 n’a absolument rien de “sémantique” ou de “fondamental”, elle se contente de dire qu’elle représente l’en-tête de plus haut niveau dans le document HTML actuel. Ce n’est pas sémantique car en fonction du découpage de l’oeuvre complète, cette balise H1 peut représenter soit le titre de l’ouvrage, d’une de ses parties, de l’un de ses volumes, de l’un de ses chapitres, etc…
En pratique, cela empêche d’utiliser un document HTML dans une structure plus large. Prenons un exemple : j’ai trois documents HTML, qui ont pour titre “IP”, “TCP” et “UDP”. Il semble logique que l’auteur ait utilise H1 pour ces trois titres.
C’est embêtant parce que maintenant ça m’interdit de concaténer ces trois documents dans un document maître titré “Les bases de TCP/IP”, vu qu’il faudrait que j’aie une balise H0 pour ce titre-là qui chapeautre les trois autres…
Dans le même ordre d’idées, “La genèse” est un titre de niveau 2 ou 3 si tu édites une Torah, mais peut-être de niveau 4 ou 5 si tu édites une bible chrétienne, dont la Torah n’est qu’une partie…
LaTeX fait un peu mieux (sections, sous-sections etc interprétées comme de niveau 1 et 2 quand on est dans le contexte “article” mais de niveau 2 et 3 quand on est dans un contexte “book”) mais c’est encore très loin d’être satisfaisant.
La solution “idéale” serait que les textes soient structurés sous forme d’un arbre avec des sections imbriquées dans d’autres sections arbitrairement, dont le niveau ne deviendrait fixé que dans le contexte du document global. Ce que font d’ailleurs les logiciels de documentation technique.
Microsoft Outlook crashe lors de la lecture des e-mails avec des tableaux
Commentaires