Récupérer les données "brutes" réelles qui ont créé un post ?

Dev
21

Si vous utilisez Chrome sur ordinateur de bureau, vous pouvez utiliser Ctrl+Maj+V pour coller du texte brut au lieu du bloc-notes.

De plus, sur la page des paramètres du site d’administration, vous pouvez désactiver ce comportement de collage avancé en décochant l’option “enable rich text paste”.

22

Merci, mais mon objectif est de conserver la mise en forme d’origine de Microsoft Word (dans les données brutes), et non de la réduire à du texte brut.

Actuellement, Discourse supprime diverses options de mise en forme — telles que la taille et le type de police — tout en en conservant d’autres (le gras et l’italique semblent rester). À titre de comparaison, l’éditeur de Gmail semble conserver toute la mise en forme.

Pour tenter de préserver davantage de mise en forme, une alternative consisterait à télécharger un document Word (plutôt que de coller du texte dans l’éditeur — mais de télécharger le document réel). Le problème, je pense, est que Discourse n’affiche pas le contenu du téléchargement en ligne (il se contente d’afficher un lien de téléchargement).

23

Alors collez le code HTML brut.

Il y a différents objectifs en jeu. L’objectif de Gmail est de préserver toute la mise en forme, tandis que celui d’un forum est de conserver un sous-ensemble significatif de celle-ci tout en empêchant les abus (texte énorme, texte clignotant, POLICES TROP GROSSES, couleurs agaçantes, etc.).

Comme exemple simple, voici le code HTML d’un texte simple tel que généré par Office, présent dans le presse-papiers sous la forme text/html :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
	<title></title>
	<meta name="generator" content="LibreOffice 7.1.2.2 (Linux)"/>
	<style type="text/css">
		@page { size: 21.59cm 27.94cm; margin: 2cm }
		p { margin-bottom: 0.25cm; line-height: 115%; background: transparent }
	</style>
</head>
<body lang="en-CA" link="#000080" vlink="#800000" dir="ltr"><p style="margin-bottom: 0cm; line-height: 100%">
<b>Hello there</b><span style="font-weight: normal"> sunshine </span><i><span style="font-weight: normal">eh</span></i></p>
</body>
</html>

Cela ressemble à ceci :

@page { size: 21.59cm 27.94cm; margin: 2cm } p { margin-bottom: 0.25cm; line-height: 115%; background: transparent }

Hello there sunshine eh

Mais lorsqu’il est interprété par to-markdown.js, vous obtenez :

**Hello there** sunshine *eh*

Hello there sunshine eh

Vous ne le pouvez pas, sauf si vous l’ajoutez vous-même comme je l’ai fait dans ce message. Si vous en avez vraiment besoin, cachez-le dans un commentaire. Si vous souhaitez le convertir vous-même en Markdown plus tard, utilisez quelque chose comme pandoc.

24

Je soutiens le passage au format Markdown pour l’affichage des messages aux autres, afin d’assurer une certaine cohérence. Ce qui m’intéresse, c’est la saisie brute.

Comment obtenir le code HTML brut d’un document Word que vous pourriez coller ?

25

Enregistrez-le au format HTML depuis Word, ou copiez-le dans le presse-papiers et extrayez explicitement le texte/html du presse-papiers.

26

Si tout ce qui vous importe est de pouvoir consulter l’entrée brute à un moment ultérieur, ce composant pourrait vous convenir.

Il ajoute un bouton au menu des messages qui affiche le contenu brut pour chaque message.

27

@jomaxro, quelle est la syntaxe du balisage brut d’un commentaire ?

28

Que demandez-vous ? Demandez-vous ce qu’est le markdown ? Comme https://commonmark.org/ Demandez-vous comment obtenir le markdown brut d’une publication ? Comme /raw/123

29

Pour une publication unique, vous pouvez ajouter l’ID à l’URL. Par exemple, https://meta.discourse.org/raw/189183/27 est votre réponse.

30

@pfaffman, ce dernier. Merci, @Moin. C’est évident, avec le recul.

31

@jomaxro, /raw/ ne fonctionne pas sur aucun des messages de discuss.kde.org/c/community/blogs/24, car, à view-source:discuss.kde.org/raw/43656, j’observe :

<pre>Konqi | 2026-01-23 22:43:37 UTC | #1

&lt;p&gt;Leaking memory is impolite. It’s messy, it can suggest logic bugs, and thanks to AI grifters RAM is expensive.&lt;/p&gt;
&lt;hr&gt;
&lt;small&gt;This is a companion discussion topic for the original entry at &lt;a href="https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed"&gt;https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed&lt;/a&gt;&lt;/small&gt;

-------------------------

</pre>

alors que, lorsque les details sont développés interactivement à discuss.kde.org/t/43656, je peux les développer pour obtenir :

1276×1076 184 KB

Est-ce que cela pourrait être géré de manière réalisable du côté de Discourse en amont ? J’ai observé des choses similaires sur d’autres instances de Discourse légèrement personnalisées, c’est pourquoi je pose la question.

32

Quel problème essayez-vous de résoudre ?

Ces sujets sont spéciaux car ce sont des liens vers de grands messages.

C’est le texte brut de l’OP.

33

Le texte brut de l’OP dans ce sujet est :

○ → curl https://discuss.kde.org/posts/132565/raw
<p>Leaking memory is impolite. It’s messy, it can suggest logic bugs, and thanks to AI grifters RAM is expensive.
</p>
<hr>
<small>This is a companion discussion topic for the original entry at <a href="https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed">https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed</a></small>

C’est exactement ce qui est rendu dans la version cuite.

Ce n’est pas un bloc details qui est développé. Un clic sur Show Full Post charge quelque chose d’autre, qui est l’expansion complète de l’intégration (embed), qui ne provient pas du brut du message mais de métadonnées supplémentaires du message.

Vous pouvez voir la requête réseau dans votre navigateur lorsque vous cliquez dessus, voici l’équivalent :

○ → curl -s -H 'accept: application/json' 'https://discuss.kde.org/posts/132565/expand-embed' | jq -r .cooked
<div><div>
            <p>Leaking memory is impolite. It’s messy, it can suggest logic bugs, and thanks to AI grifters RAM is expensive.</p>
…
…
…
<p>LSAN is now enabled for some Frameworks CI builds, but ideally it would be enabled for all KDE projects. And of course any leaks found along the way should be fixed.</p>
<p>Happy leak-fixing!</p>
        </div></div>
<hr>
<small>This is a companion discussion topic for the original entry at <a href='https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed'>https://nicolasfella.de/posts/detecting-leaks-in-kde-ci/?utm_source=atom_feed</a></small>

Vouliez-vous voir le contenu de l’intégration (embed) ? Si oui, utilisez ce qui précède. Sinon, qu’attendez-vous de voir ?

34

@supermathie, en effet. Merci beaucoup ! Évidemment, une bien plus grande partie de l’API Discourse existe que je ne le pensais.