استعادة البيانات "الخام" الحقيقية التي أنشأت منشورًا؟

مطور
21

إذا كنت تستخدم Chrome على سطح المكتب، فيمكنك استخدام Ctrl+Shift+V للصق النص العادي بدلاً من المفكرة.

أيضًا، في صفحة إعدادات موقع المسؤول، يمكنك تعطيل سلوك اللصق المنسق هذا بإلغاء تحديد خيار “enable rich text paste”.

22

شكرًا لك، لكن هدفي هو الحفاظ على التنسيق الأصلي من مستند Word (في البيانات الخام)، وليس اختزاله إلى نص عادي.

حاليًا، يقوم Discourse بإزالة مجموعة متنوعة من التنسيق—مثل حجم الخط ونوعه، بينما يحتفظ بآخرين (يبدو أن التظليل الغامق والمائل يبقيان). كمقارنة، يبدو أن محرر Gmail يحتفظ بكل التنسيق.

لمحاولة الحفاظ على المزيد من التنسيق، أفترض أن البديل سيكون رفع مستند Word (وليس لصق النص في المحرر، بل رفع المستند الفعلي). المشكلة هناك، أعتقد، هي أن Discourse لا يعرض محتوى الرفع مضمنًا (فقط يعرض رابط الرفع).

23

في هذه الحالة، الصق كود HTML الخام.

هناك أهداف مختلفة متداخلة. هدف Gmail هو الحفاظ على جميع التنسيقات، بينما هدف المنتدى هو الاحتفاظ بمجموعة فرعية ذات معنى منها مع منع إساءة الاستخدام (نصوص ضخمة، نصوص تومض، خطوط كبيرة بشكل مفرط، ألوان مزعجة، إلخ).

كمثال بسيط، إليك كود HTML لنص بسيط تم إنشاؤه بواسطة Office، وهو موجود في الحافظة بصيغة 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

لا يمكنك ذلك، إلا إذا قمت بإدراجه بنفسك كما فعلت في هذا المنشور. إذا كنت تحتاج إليه حقًا هناك، فأخفِه داخل تعليق. وإذا كنت ترغب في تحويله لاحقًا إلى تنسيق ماركداون بنفسك، فاستخدم أداة مثل pandoc.

24

أدعم التحويل إلى تنسيق Markdown في المنشور الذي يُعرض على الآخرين لتحقيق قدر من الاتساق. ما أثيرني حقًا هو الإدخال الخام.

كيف يمكنك الحصول على كود HTML الخام لوثيقة Word لتتمكن من لصقه؟

25

احفظه كملف HTML من Word، أو انسخه إلى الحافظة ثم اسحب النص/HTML صراحةً من الحافظة.

26

إذا كان اهتمامك الوحيد هو القدرة على الرجوع إلى المدخلات الخام في وقت لاحق، فقد يكون هذا المكون مناسبًا لك.

يضيف هذا المكون زرًا إلى قائمة المنشور لعرض المحتوى الخام على أساس كل منشور.

27

@jomaxro، ما هو بناء الجملة لترميز التعليق الخام؟

28

ما الذي تسأل عنه؟ هل تسأل ما هو الماركداون (markdown)؟ مثل https://commonmark.org/ هل تسأل كيف تحصل على الماركداون الخام (raw markdown) لمنشور؟ مثل /raw/123

29

للمنشور الواحد، يمكنك إضافة المعرّف (ID) إلى عنوان URL. على سبيل المثال، https://meta.discourse.org/raw/189183/27 هو ردك.

30

@pfaffman، الخيار الثاني. شكرًا لك، @Moin. هذا واضح، بالنظر إلى الوراء.

31

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

بينما، عند توسيع details بشكل تفاعلي في discuss.kde.org/t/43656، يمكنني توسيعه إلى:

1276×1076 184 KB

هل يمكن تلبية هذا الأمر بشكل فعال من جانب Discourse الأصلي؟ لقد لاحظت شيئًا مشابهًا في مثيلات Discourse أخرى مخصصة قليلاً، ولهذا السبب أسأل.

32

ما المشكلة التي تحاول حلها؟

هذه المواضيع خاصة لأنها روابط لمشاركات كبيرة.

هذا هو النص الأصلي للمنشور الأصلي.

33

النص الخام للمنشور الأصلي في ذلك الموضوع هو:

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

هل أردت رؤية محتويات التضمين؟ إذا كان الأمر كذلك، استخدم ما سبق. إذا لم يكن كذلك، فما الذي تتوقعه أن تراه؟

34

@supermathie، بالفعل. شكراً جزيلاً! من الواضح أن هناك الكثير من واجهة برمجة تطبيقات ديسكورس (Discourse API) مما أنا على دراية به.