投稿を作成した実際の「生の」データを取得するには?

Chrome デスクトップをお使いの場合は、メモ帳ではなくプレーンテキストとして貼り付けるには、\u003ckbd\u003eCtrl\u003c/kbd\u003e+\u003ckbd\u003eShift\u003c/kbd\u003e+\u003ckbd\u003eV\u003c/kbd\u003e を使用できます。

また、管理サイトの設定ページで「enable rich text paste」オプションのチェックを外すことで、このリッチテキスト貼り付け機能を無効にすることもできます。

ありがとうございます。しかし、私の目的は、生のデータからMicrosoft Wordの元の書式を維持することであり、プレーンテキストに単純化することではありません。

現在、Discourseはフォントサイズやフォントの種類など、さまざまな書式を削除してしまいますが、太字や斜体などは残っています。比較すると、GmailのCompose機能はすべての書式を維持しているようです。

より多くの書式を維持するために、テキストをComposerに貼り付けるのではなく、Wordドキュメント自体をアップロードするという代替案も考えられます。ただし、その場合の問題は、Discourseがアップロードされたファイルの内容をインラインで表示せず、単にアップロードリンクを表示するだけだということです。

それなら、生の HTML を貼り付けてください。

そこには異なる目的が関わっています。Gmail の目的はすべての書式設定を維持することですが、フォーラムの目的は、悪用(巨大なテキスト、点滅するテキスト、過度に大きなフォント、迷惑な色など)を防ぎつつ、意味のあるサブセットを維持することです。

簡単な例として、Office が生成した単純なテキストの HTML(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>

表示は以下のようになります:

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

Hello there sunshine eh

しかし、to-markdown.js で解釈すると次のようになります:

**Hello there** sunshine *eh*

Hello there sunshine eh

あなたがこの投稿で私が行ったように、自分でそこに配置しない限り、それは不可能です。もしそれを本当にそこに置く必要があるなら、コメントの中に隠してください。後で自分でそれを Markdown に変換したい場合は、pandoc のようなものを使用してください。

一貫性のため、他のユーザーに表示される投稿を Markdown 形式に移行することに賛成です。私が興味を持っているのは、生の入力部分です。

Word ドキュメントから、貼り付け可能な生の HTML をどのように取得すればよいのでしょうか?

WordからHTMLとして保存するか、クリップボードにコピーし、クリップボードから明示的にtext/htmlを取得してください。

もし単に後で生の入力内容を参照できることが目的であれば、このコンポーネントが役立つかもしれません。

これは投稿メニューにボタンを追加し、投稿ごとに生の内容を表示するものです。

@jomaxroさん、コメントの生のマークアップの構文は何ですか?

何をお尋ねですか?マークダウンとは何か、例えば https://commonmark.org/ のようなものを尋ねていますか?投稿の生のマークダウンを取得する方法、例えば /raw/123 のようなものを尋ねていますか?

単一の投稿については、URLにIDを追加できます。例えば、\u003chttps://meta.discourse.org/raw/189183/27\u003e があなたの返信です。

@pfaffman、後者です。@Moin、ありがとうございます。今思えば当然のことでした。

@jomaxro/raw/discuss.kde.org/c/community/blogs/24 のどの投稿でも機能しません。例えば、view-source:discuss.kde.org/raw/43656 では、以下のような表示になります。

<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>

一方、discuss.kde.org/t/43656details をインタラクティブに展開すると、以下のように展開できます。

これは、上流の Discourse 側で対応可能でしょうか?他の、わずかにカスタマイズされた Discourse インスタンスでも同様の現象を確認しているため、質問させていただきました。

解決しようとしている問題は何ですか?

これらのトピックは、大きな投稿へのリンクであるため特別です。

これはopの生のテキストです。

そのトピックのOPの生のテキストは次のとおりです。

○ → 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>

これは、調理済みバージョンでレンダリングされるものとまったく同じです。

これは、detailsブロックが展開されているわけではありません。「Show Full Post」をクリックすると、埋め込みの完全な展開である何か別のものがロードされますが、これは投稿の生データからではなく、追加の投稿メタデータから取得されます。

クリックするとブラウザでネットワークリクエストを確認できます。同等のものは次のとおりです。

○ → 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>

埋め込みの内容を見たいですか?その場合は上記を使用してください。そうでない場合は、が表示されることを期待していますか?

@supermathie、その通りです。ありがとうございます!どうやら、私が思っているよりも多くのDiscourse APIが存在するようです。