ترجمة آلية

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

المصدر الإنجليزي · الإبلاغ عن مشكلة في الترجمة

استكشاف الأخطاء وإصلاحها

تنسيق الأسئلة الشائعة: كل إدخال هو مشكلة → سبب → حل. للحصول على مرجع كامل لدلالات الأخطاء (رموز الحالة، الحالات النهائية، سياسة إعادة المحاولة)، راجع الاستجابات والأخطاء وتحديد المعدل والأخطاء.

a. الطلبات المباشرة لواجهة API تحصل على Cloudflare 403

المشكلة: طلب مكتوب يدويًا curl / سكريبت ضد نقاط نهاية REST الخاصة بـ www.perplexity.ai يُرجع 403 مع صفحة تحدي Cloudflare — حتى مع نسخ ملفات تعريف الارتباط من المتصفح — بينما تعمل نفس نقاط النهاية من خلال الأداة.

السبب: Cloudflare موجود أمام الموقع، وcf_clearance / __cf_bm مرتبطان ببصمة TLS الخاصة بالمتصفح. بصمة العميل المباشر لا تتطابق، لذلك يتم إطلاق التحدي. الأداة تعمل لأنها تستخدم Python urllib مع ملفات تعريف ارتباط مستوردة من المتصفح وبصمة User-Agent لسطح مكتب Chrome (pplx_export/core/http/cookie_transport.py:29). يمكن لـ Cloudflare أيضًا إرجاع 403 تحت التحكم في المعدل — في هذه الحالة يحمل الرد نفس شكل التحدي.

الحل:

• لا تتجاوز طبقة النقل الخاصة بالأداة؛ قم بتشغيل طلبك من خلال pplx-export / pplx-ask بدلاً من البرامج النصية المخصصة.
• داخل الأداة، يتم تصنيف استجابة 200 مع نص غير JSON (صفحة Cloudflare الوسيطة) كخطأ في النقل، وليس بيانات (pplx_export/core/http/cookie_transport.py:133).
• إذا بدأت 403s في الظهور داخل الأداة، أبطئ (راجع تحديد المعدل) وقم بتحديث ملفات تعريف الارتباط؛ التحدي المستمر يعني إعادة تسجيل الدخول في المتصفح.
• انتبه إلى وجهي 403: تحدي التحكم في المخاطر من Cloudflare (يختفي بمجرد أن تبطئ) مقابل 403 على مستوى API (ملف تعريف ارتباط منتهي الصلاحية — يتم رفعه فورًا بدون تراجع؛ راجع القسم التالي). صفحة التصميم ترسم الأخير (rate-limiting-errors.md).

خلفية: مصادقة API.

b. أخطاء 401 / ملفات تعريف ارتباط منتهية الصلاحية

المشكلة: تفشل الأوامر مع خطأ مصادقة — AuthTransportError: 鉴权失败 401 من pplx-export، أو pplx-ask ask يخرج مع تلميح HTTP 401/403 لتحديث ملف تعريف الارتباط.

السبب: انتهت صلاحية جلسة ملف تعريف الارتباط أو تم إبطالها. يتم التعامل مع 401/403 كفشل في المصادقة ويتم رفعها فورًا — لا تراجع، لأن التراجع لا يمكنه إصلاح جلسة ميتة ذاتيًا (pplx_export/core/http/cookie_transport.py:82; pplx_export/core/errors.py:68). بالإضافة إلى ذلك، يفشل batch بسرعة بعد 3 حالات فشل متتالية في المصادقة حتى لا يحرق ملف تعريف الارتباط الميت قائمة الانتظار.

الحل:

1. أعد تسجيل الدخول (أو أعد فتح الموقع) في المتصفح حتى يتم تجديد ملفات تعريف ارتباط الجلسة.
2. قم بتحديث ذاكرة التخزين المؤقت لملفات تعريف الارتباط الخاصة بالأداة. يتم إعادة استخدام ذاكرة التخزين المؤقت في <out>/index/.cookies.json خلال نافذة حداثة مدتها 12 ساعة (pplx_export/core/cookies/cache.py:22)، لذلك بعد إعادة تسجيل الدخول إما:
3. قم بتشغيل مرة واحدة مع --cookies-from <browser> لفرض استيراد جديد من المتصفح، أو
4. احذف <out>/index/.cookies.json ودع التشغيل التالي يعيد الاستيراد تلقائيًا.
5. كل تشغيل يتم التحقق منه بنجاح يعيد حفظ ذاكرة التخزين المؤقت (pplx_export/commands/common.py:150)، لذلك تظل عمليات التشغيل اليومية حديثة من تلقاء نفسها.

تفاصيل الإعداد: بدء الاستخدام · التكوين.

c. فك تشفير ملفات تعريف الارتباط في Linux

المشكلة: على Linux، لا يستطيع الكشف التلقائي (أو --cookies-from chrome وشركاه) قراءة مخزن ملفات تعريف الارتباط الخاص بالمتصفح حتى إذا كان المتصفح مسجلاً للدخول.

الآلية: تقوم متصفحات عائلة Chromium بتشفير قاعدة بيانات ملفات تعريف الارتباط بمفتاح محفوظ في سلسلة مفاتيح نظام التشغيل، ويتم قراءته في وقت التشغيل من خلال واجهة برمجة تطبيقات Secret Service D-Bus. يتحدث browser_cookie3 مع D-Bus عبر jeepney بلغة Python الخالصة — المثبتة بالفعل مع الأداة على Linux، لا حاجة لإعداد أي شيء إضافي — ويتراجع إلى كلمة مرور peanuts القديمة عندما لا تستجيب أي سلسلة مفاتيح، والتي تقوم فقط بفك تشفير ملفات تعريف الارتباط التي كتبها Chrome أيضًا بدون سلسلة مفاتيح. عندما تكون سلسلة المفاتيح موجودة ولكن بحث D-Bus نفسه يفشل على مستوى النقل (على سبيل المثال، جلسة حافلة ترفض المصادقة المجهولة)، لا تنخرط سلسلة التراجع الخاصة بـ browser_cookie3 أبدًا؛ تكتشف الأداة هذه الحالة وتعيد المحاولة مرة واحدة مع تجاوز سلسلة المفاتيح، باستخدام كلمة مرور Chromium الافتراضية — نفس المفتاح الذي يستخدمه Chromium نفسه عندما لا تكون سلسلة المفاتيح متاحة (pplx_export/core/cookies/loaders.py:62-104، موصول في مسار التحميل عند loaders.py:136-153). لا يحتاج Firefox إلى أي من هذا: cookies.sqlite الخاص به غير مشفر.

المصفوفة:

الطبقة	الحالة	ما يحدث
المتصفح	Firefox	بدون احتكاك — cookies.sqlite غير مشفر
المتصفح	Chromium + سلسلة مفاتيح يمكن الوصول إليها	يعمل — يتم جلب المفتاح عبر Secret Service
المتصفح	Chromium + بدون سلسلة مفاتيح	مسار peanuts — يعمل فقط إذا كتب Chrome أيضًا بدون سلسلة مفاتيح
المتصفح	Chromium + سلسلة مفاتيح غير قابلة للوصول (فشل على مستوى D-Bus)	تعيد الأداة المحاولة تلقائيًا باستخدام كلمة مرور Chromium الافتراضية — نفس الوصول مثل مسار peanuts
طريقة التثبيت	حزمة أصلية	يتم اكتشافها تلقائيًا (المسارات المضمنة في browser_cookie3)
طريقة التثبيت	snap / flatpak	يتم اكتشافها تلقائيًا — يغطي سجل الملفات الشخصية المضمنة الملفات الشخصية تحت ~/snap/<name>/... أو ~/.var/app/<app-id>/... (pplx_export/core/cookies/profiles.py:37-67)
بيئة سطح المكتب	GNOME	عادةً ما يعمل خارج الصندوق (gnome-keyring)
بيئة سطح المكتب	KDE	قم بتمكين استخدام KWallet لواجهة Secret Service في إعدادات KWallet
بيئة سطح المكتب	بدون رأس / بسيط	لا توجد حافلة جلسة D-Bus → مسار peanuts
عائلة التوزيعة	Debian / Ubuntu	قم بتثبيت libsecret-1-0 + gnome-keyring
عائلة التوزيعة	Fedora / RHEL	قم بتثبيت libsecret + gnome-keyring؛ غالبًا ما تفتقر التثبيتات البسيطة / الخادم إلى سلسلة مفاتيح تمامًا — الفشل الأكثر شيوعًا
عائلة التوزيعة	Arch	نفس الآلية، تختلف أسماء الحزم فقط

لا تحتاج تثبيتات الحماية إلى علامات إضافية: يتم فحص المسار الأصلي أولاً، ثم قواعد بيانات ملفات تعريف الارتباط snap/flatpak الخاصة بالسجل عبر cookie_file= صريح (pplx_export/core/cookies/loaders.py:155-168).

السيناريو → القناة الموصى بها:

السيناريو	القناة الموصى بها
Firefox مثبت	--cookies-from firefox — بدون احتكاك
سطح مكتب GNOME / KDE	الكشف التلقائي يعمل فقط
متصفح snap / flatpak	الكشف التلقائي — يغطيه السجل؛ وإلا --cookies FILE تم تصديره عبر إضافة متصفح
خادم بدون رأس	--cookies FILE — الاحتياطي الشامل؛ --transport webbridge كملاذ أخير

d. تم تشغيل تصدير تحت حساب خاطئ (حسابات متعددة)

المشكلة: تم جلب سلاسل المحادثات المؤرشفة بجلسة الحساب الخاطئ — على سبيل المثال، جلب تشغيل --account alice بيانات كـ bob، أو يظهر الأرشيف سلاسل محادثات لا تنتمي إلى الحساب المقصود.

السبب: مع وجود عدة حسابات مسجلة الدخول في نفس المتصفح، قد ينتمي رمز الجلسة النشط (__Secure-next-auth.session-token) إلى حساب مختلف عن الحساب الذي استهدفته. إذا لم يتم تسجيل email للحساب المستهدف في تكوين مستوى المستخدم، لا يمكن للأداة اكتشاف ذلك وتسجل تحذيرًا فقط.

كيف تمنع الأداة ذلك (pplx_export/commands/common.py:93): عند بدء التشغيل، تستدعي طبقة النقل GET /api/auth/session وتقارن البريد الإلكتروني المباشر مع المسجل. عند عدم التطابق، تقوم تلقائيًا بتعداد ملفات تعريف ارتباط الجلسة لكل حساب في المتصفح (__Secure-pplx.session.<user_id>)، وتستبدل كل منها في الرمز النشط، وتختبر الجلسة حتى يتطابق البريد الإلكتروني المستهدف (pplx_export/commands/common.py:190; pplx_export/core/cookies/loaders.py:175). إذا لم يتطابق أي رمز، يتم إحباط الأمر مع خطأ واضح — لا يستمر بصمت كحساب خاطئ.

الحل:

• سجل email لكل حساب تحت [accounts.<name>] (راجع التكوين) ومرر --account بشكل صريح.
• تحقق من سطر سجل بدء التشغيل [auth] cookie 来源 …，当前账户: … — يسمي البريد الإلكتروني للجلسة المباشرة قبل جلب أي شيء.
• لتدقيق أرشيف موجود، يحمل thread.json لكل سلسلة محادثات حقل export_via يسجل الحساب الذي قام بالتصدير (pplx_export/sites/perplexity/fs_writer.py:229). يستخدم pplx-export sync-deleted نفس الحقل لاختيار الحساب للتحقق عبر الإنترنت.

عمق الآلية: مصادقة API · الأسئلة والحسابات.

e. "لم يتم العثور على ملف التكوين" — الوضع المنخفض

المشكلة: يقول تحذير بدء التشغيل أنه لم يتم العثور على ملف تكوين على مستوى المستخدم ويتم تشغيل الأمر في الوضع المنخفض؛ أو يفشل --account alice صريح مع خطأ يشير إلى config.example.toml.

السبب: لا يوجد ملف تكوين في أي من مواقع البحث الثلاثة — --config PATH، متغير البيئة PPLX_EXPORT_CONFIG، أو الافتراضي ~/.config/pplx-export/config.toml (pplx_export/config.py:113). حالتان مرتبطتان لكن متميزتان: مسار تكوين محدد بشكل صريح غير موجود يثير ConfigError؛ التكوين التالف (غير قابل للتحليل) يثير دائمًا ConfigError — التكوين المكسور لا يتدهور بصمت أبدًا.

تأثيرات الوضع المنخفض:

• سجل الحسابات فارغ، لذلك يتم تخطي التحقق من ملكية ملفات تعريف الارتباط مع تحذير ويتم تشغيل الأوامر كحساب نائب default (pplx_export/commands/common.py:51). --account صريح يخرج بخطأ بدلاً من ذلك.
• يتخطى pplx-ask ask النقل التلقائي إلى مساحة BOT (يبقى moved_to_bot false في JSON النتيجة) ويحمل القياس عن بعد معرف مستخدم فارغ؛ بخلاف ذلك، يعمل السؤال والأرشفة.
• تهبط الأرشيفات تحت مجلد الحساب الاحتياطي المشتق من اسم المستخدم.

الحل: انسخ config.example.toml إلى ~/.config/pplx-export/config.toml، املأ [accounts.<name>] (display_name / email / user_id)، [bot_space]، و default_account — راجع التكوين.

f. ENTRY_EXPIRED مقابل ENTRY_DELETED

المشكلة: الإبلاغ عن تصدير أو إعادة مزامنة سلسلة محادثات ENTRY_EXPIRED أو ENTRY_DELETED، ولا يمكن جلب سلسلة المحادثات مرة أخرى أبدًا.

السبب: يصل كلاهما كـ HTTP 400 من GET /rest/thread/<uuid> مع رموز خطأ مختلفة، وكلاهما نهائي — سلسلة المحادثات لم تعد موجودة على المنصة:

الرمز	المعنى	تعيين الأداة	الحالة النهائية
ENTRY_EXPIRED	قامت المنصة بتنظيف سلسلة المحادثات (احتفاظ ~3 أشهر)	EntryExpiredError (pplx_export/core/errors.py:24)	expired
ENTRY_DELETED	تم حذف سلسلة المحادثات بنشاط بواسطة المستخدم / الجانب البعيد (التأثير النهائي لـ DELETE /rest/thread/delete_thread_by_entry_uuid)	EntryDeletedError، فئة فرعية من EntryExpiredError (pplx_export/core/errors.py:30)	deleted

ما يعنيه ذلك لأرشيفك:

• لا يتم إعادة محاولة أي من الحالتين أبدًا — ليس عن طريق المزامنة المتزايدة، ولا مع --force. تعيش العلامة النهائية في <out>/index/batch_state.json.
• لا يتم حذف أرشيفك المحلي أو نقله أبدًا بواسطة الأداة — نسخة المستودع هي النسخة الاحتياطية. يسجل أمر التصدير الحالة النهائية ويخرج بأمان (pplx_export/commands/export_cmd.py:51).
• نظرًا لأن علاقة الفئة الفرعية متعمدة، فإن مسارات الكود التي تعرف فقط EntryExpiredError لا تزال تعامل ENTRY_DELETED كنهائية؛ المسارات الواعية (دفعة / تصدير / مزامنة محذوفة / ملء خلفي لوضع البحث) تصنفها بدقة كـ deleted.
• الخلاصة العملية: قم بالتصدير في الوقت المناسب. بعد التنظيف لمدة ~3 أشهر، تنتهي أيضًا روابط مصدر القطعة / التقرير بشكل لا رجعة فيه.

ذات صلة: المزامنة المتزايدة · الاستجابات والأخطاء.

g. الأصول التي لا يمكن تنزيلها (معالجات toolu_)

المشكلة: بعض الإدخالات في assets/assets_manifest.json تحتوي على إصدارات مميزة بـ "no_download_channel": true، ولا يوجد ملف مقابل تحت assets/files/.

السبب: معالجات مساحة العمل السحابية المسبوقة بـ toolu_ (DOC_FILE / CODE_FILE / UNKNOWN بدون نموذج URL) ليس لديها قناة تنزيل API: يُرجع GET /rest/assets/<asset_uuid>/data 404 ASSET_NOT_FOUND لها، ويرفض file-repository/download معالجات file:repo/... (400). هذه حدود معروفة لاكتمال الأرشيف، وليس خطأ في التصدير. يميز pplx-export assets-backfill هذه الإصدارات بـ no_download_channel ويتخطاها (pplx_export/commands/assets_backfill_cmd.py:356).

الحل:

• لا شيء لتنزيله اليوم — العلم هو السجل المتعمد للحدود.
• غالبًا ما يبقى المحتوى مضمّنًا: يتم حفظ نص استخراج الصفحة الفرعية وحمولات الخطوة في JSON الخام لسلسلة المحادثات (raw_entries.json / raw_blocks.json) وفي turns/ المقدم — تحقق هناك أولاً.
• يتم تتبع file-repository/list-files كمسار إنقاذ محتمل في المستقبل؛ راجع خريطة طريق اكتشاف API.

تخطيط البيان: تخطيط الأرشيف.

h. يبدو أن الأمر معلق / فترات صمت طويلة

العرض: يبدو أن index / batch / export متوقف؛ قد يقتله مدير المهام الخارجي كـ "مهلة".

السبب: دائمًا تقريبًا انتظار تراجع أو طلب قيد التنفيذ، وليس تعليقًا. عند أخطاء 429 / 5xx / الشبكة، تنام طبقة النقل بين المحاولات — حتى 300 ثانية لكل انتظار (pplx_export/core/throttle.py, Throttle.backoff).

ما تراه الآن (الإفصاح الافتراضي، لا حاجة لـ -v): يتم عرض الانتظار بواسطة نبضات INFO. يطبع التراجع سطرًا أوليًا ثم نبضة عد تنازلي كل ~10 ثوانٍ (Throttle.heartbeat_interval); يطبع طلب واحد يتوقف قبل الاستجابة نبضة "لا يزال ينتظر الرد"; وتطبع تدفقات pplx-ask نبضة "لا يزال ينتظر تدفق الرد" أثناء تشغيل بحث عميق / مجلس بصمت:

22:27:24 [auth] 正在校验账户 cookie（来源 cache）…
22:27:40 退避 ~51s（连续失败 1 次，网络异常重试中）
22:27:50 仍在等待重试，剩余 ~41s
22:28:00 仍在等待重试，剩余 ~31s

إجمالي وقت الانتظار لم يتغير — النبضات تجعله مرئيًا فقط؛ المقاطعة آمنة في أي نقطة (تتم كتابة الحالة بشكل ذري ويصلح التشغيل التالي الفجوة). لا يزال -v / --log-file يضيفان تتبع طلب DEBUG الكامل.

تخطي فحص بدء التشغيل: يبدأ index / batch بفحص جلسة يتبع نفس قواعد التراجع، لذلك على شبكة سيئة يمكن أن يكون أول انتظار هو خطوة التحقق من الحساب هذه. مرر --skip-auth-check لتخطيها والذهاب مباشرة إلى العمل، مع الثقة في الحساب المسجل الدخول حاليًا — راجع التكوين.

النمط المضاد: تغليف CLI في مدير مهام بمهلة زمنية قصيرة وصعبة (مهام الخلفية للوكيل، مغلفات cron على غرار timeout(1)) أثناء ربط الحسابات بـ && — سلسلة التراجع للحساب الأول تحرق المهلة بأكملها والحساب المرتبط لا يعمل أبدًا. حساب واحد لكل استدعاء، ميزانية سخية: راجع الميزانية الزمنية للمتصلين.

i. أين السجلات؟

وحدة التحكم: تقدم على مستوى INFO افتراضيًا؛ -v / --verbose يتحول إلى DEBUG (تتبع الطلب، القرارات الداخلية)؛ يتم عرض التحذيرات والأخطاء دائمًا.

ملف: مرر --log-file لالتقاط تدفق DEBUG الكامل (pplx_export/core/logging.py:45):

• --log-file بدون قيمة يهبط في <out>/index/logs/<cmd>-<timestamp>.log (pplx_export/commands/common.py:218) — على سبيل المثال pplx-ask-ask-20260723-120000.log.
• --log-file PATH يكتب إلى المسار المحدد.

ملفات الحالة الأخرى المفيدة للتشخيص (تحت <out>/index/):

الملف	المحتوى
.cookies.json	ذاكرة تخزين مؤقت لملفات تعريف الارتباط (حداثة 12 ساعة؛ مكتوبة بشكل ذري بـ 0o600 — إنها بيانات اعتماد مكافئة لتسجيل الدخول، احتفظ بها خاصة)
batch_state.json	حالة تصدير لكل سلسلة محادثات، بما في ذلك علامات expired / deleted النهائية
answer_variants_log.jsonl	سجل متغير إعادة كتابة الإجابة
library_*.json	لقطات فهرس المكتبة لكل حساب

j. انظر أيضًا

• بدء الاستخدام — الإعداد الأولي واستيراد ملفات تعريف الارتباط
• التكوين — الحسابات، مساحة BOT، الوضع المنخفض
• pplx-ask — واجهة سطر الأوامر للاستعلام التفاعلي
• pplx-export — واجهة سطر الأوامر للأرشفة
• تحديد المعدل — سياسة السرعة والتراجع