أمضيت عددًا كبيرًا بشكل مبالغ فيه من الليالي المتأخرة وأنا أُصلح سكربتات كان المفترض بها فقط أن «تلتقط ملفًا وتمشي». وفي تسع حالات من أصل عشر، كان السبب أن cURL نفّذ حرفيًا ما طلبته منه، لا ما كنت أقصده فعلًا. واتضح لي أن هناك فجوة كبيرة بين أن «curl -O يشتغل» وبين أن «curl -O يشتغل بشكل موثوق في بيئة الإنتاج».
هذا الدليل مخصص لسدّ تلك الفجوة. يأتي cURL مثبتًا مسبقًا على macOS ومعظم توزيعات Linux وWindows 10 وما بعده، وهذا يعني أنك على الأغلب تملكه أصلًا على جهازك. لكن بين أخطاء التحويل الصامتة، وأخطاء 403 المربكة، والانتقال من «تنزيل ملف واحد» إلى «تنزيل 500 ملف من دون أن ينهار الطرفية»، توجد فرص كثيرة للتعثر. سأشرح لك الأعلام المهمة، والأوامر العملية التي أستخدمها فعلًا، والأخطاء التي تربك الناس غالبًا، ثم النقطة التي يتوقف فيها cURL عن مساعدتك، وما الذي ينبغي استخدامه بدلًا منه.
ما هو cURL ولماذا ينبغي أن تهتم به؟
cURL هو أداة سطر أوامر مجانية ومفتوحة المصدر لنقل البيانات من خادم أو إليه باستخدام رابط URL. وهو يدعم HTTP وHTTPS وFTP وSFTP وقائمة طويلة من البروتوكولات الأخرى، لذلك تجده في كل مكان، من سكربتات bash إلى Dockerfiles إلى مسارات CI. وفي الخلفية، فإن الأمر curl الذي تكتبه في الطرفية يستخدم libcurl، وهي مكتبة نقل مكتوبة بلغة C وتندمج فيها تطبيقات كثيرة وروابط لغات متعددة. من أمثلتها امتداد cURL في PHP، بينما مكتبة Requests الشائعة في Python هي عميل HTTP منفصل مبني على urllib3، وليست مبنية على libcurl.
أحدث إصدار مستقر وقت كتابة هذا المقال هو curl 8.21.0، وقد صدر في يونيو 2026 — لكن لا تفترض أن نظام التشغيل لديك يضم هذا الإصدار تحديدًا. الإصدارات المعبأة ضمن التوزيعات غالبًا ما تتأخر عن المشروع الأصلي شهورًا، وأحيانًا أكثر، لذلك من المفيد تشغيل curl --version قبل أن تفترض أن خيارًا مثل --parallel متاح لديك.
لماذا تنزيل الملفات عبر cURL؟ أهم الاستخدامات
كثيرًا ما يُسألني لماذا قد يكلّف أحد نفسه عناء استخدام أداة سطر أوامر بينما تستطيع المتصفحات تنزيل الملفات بشكل ممتاز. والجواب الصريح: المتصفحات ممتازة إلى أن تحتاج إلى الأتمتة.
| حالة الاستخدام | لماذا يتفوق cURL |
|---|---|
| تنزيل الملفات الثنائية داخل CI/CD | قابل للسكربت، ولا يحتاج واجهة رسومية |
| جلب استجابات API أو ملفات التصدير | يدعم الرؤوس المخصصة، والمصادقة، وتمرير المخرجات |
| استئناف التنزيلات الكبيرة عبر SSH | دعم مدمج للاستئناف (-C -) |
| أتمتة التنزيلات المتكررة (مهام cron) | خفيف ويمكن دمجه بسهولة مع سكربتات shell |
| جلب ملفات خلف بوابة مصادقة | أعلام مصادقة مرنة (basic، token، cookies، .netrc) |
تنزيل المتصفح هو نقرة يدوية لمرة واحدة. أما cURL فيحوّل نفس العملية إلى شيء يمكنك جدولته، وربطه بسلسلة معالجة، وإعادة المحاولة عند الفشل، وتشغيله بالطريقة نفسها على مئة خادم في الوقت نفسه. وهذه هي الفكرة كلها — ليس أكثر بهرجة، بل أكثر قابلية للتكرار.
أهم أعلام cURL لتنزيل الملفات
أعود دائمًا إلى نحو اثني عشر علمًا فقط في 90% من عملي. وهذه هي الورقة المختصرة التي كنت أتمنى لو سلّمَني إياها أحد قبل سنوات، مرتبة بحسب ما تفعله فعلًا.
أعلام الإخراج وحفظ الملفات
-O(--remote-name) يحفظ الملف باستخدام آخر جزء من الرابط كاسم للملف. مفيد، لكنه قد يستبدل ملفًا موجودًا بالاسم نفسه من دون تنبيه.-o <filename>(--output) يتيح لك تحديد اسم الملف محليًا بنفسك:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) يستخدم اسم الملف الوارد في ترويسةContent-Dispositionمن الخادم بدلًا من الاسم المستمد من الرابط. هذا مفيد جدًا لتنزيلات الـ API، لكن تعامل مع أسماء الملفات القادمة من الخادم باعتبارها مدخلات غير موثوقة — نزّلها إلى مجلد مخصص بدلًا من مجلدك الرئيسي، وفقًا لإرشادات الأمان الخاصة بـ curl.
أعلام السلوك التي يحتاجها كل تنزيل
-L(--location) يطلب من curl تتبع التحويلات HTTP. من دونه، ستُحفظ استجابة 3xx على شكل صفحة HTML صغيرة للتحويل بدل ملفك الحقيقي — وهذا هو الخطأ الأكثر شيوعًا الذي أراه عندما يقول أحدهم «لماذا التنزيل عندي تالف؟».-C -(--continue-at -) يستأنف التنزيل المتقطع من حيث توقف.-s/-Sيعملان بصمت لكنهما ما زالا يعرضان الأخطاء — مفيدان في السكربتات عندما لا تريد شريط تقدم يملأ السجلات.--limit-rate 1Mيحد من سرعة النقل (مفيد على الاتصالات المشتركة أو عندما لا تريد استنزاف شبكة محدودة السعة).--connect-timeout 10و--max-time 300يمنعان الاتصال العالق من تجميد السكربت إلى الأبد.--retry 3و--retry-delay 5يعيدان المحاولة تلقائيًا عند الأخطاء العابرة — ووفقًا لـ صفحة man الخاصة بـ curl، من الأفضل إقرانها مع--retry-all-errorsفقط عندما تكون إعادة الطلب نفسه آمنة فعلًا.
أعلام التقدم والتشخيص
-#يعرض شريط تقدم بسيطًا بدل جدول الإحصاءات الافتراضي.-vيطبع مخرجات تفصيلية، بما في ذلك كامل رؤوس الطلب/الاستجابة — وهو خياري الأول عندما يتصرف شيء ما بشكل غريب.-I(--head) يجلب رؤوس الاستجابة فقط، وهو فحص تمهيدي ممتاز قبل الالتزام بتنزيل كبير.-wيتيح لك طباعة مخرجات مخصصة بعد النقل، مثلcurl -o /dev/null -s -w "%{http_code}\n" <url>للتحقق فقط من رمز الحالة.
قبل أن تبدأ
- مستوى الصعوبة: مبتدئ إلى متوسط (أقسام التنزيل الدفعي والمصادقة أكثر تقدمًا قليلًا)
- الوقت المطلوب: حوالي 15 إلى 20 دقيقة لاجتياز الأوامر الأساسية
- ما ستحتاج إليه: طرفية أو Terminal (macOS Terminal، أو Linux shell، أو Windows PowerShell/WSL)، وcURL مثبت (تحقق عبر
curl --version)، ورابط اختبار — سأستخدم مثالًا من ملف إصدار عام على GitHub لأنه ثابت ومتاح مجانًا
كيفية تنزيل الملفات باستخدام cURL خطوة بخطوة
الخطوة 1: تنزيل ملف واحد
الأساسيات البحتة: curl -O <url> يحفظ الملف باسمه الأصلي، بينما curl -o myfile.zip <url> يتيح لك إعادة تسميته أثناء التنزيل.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
أضيف -L الآن بشكل تلقائي ودائم، من دون استثناء — لقد دفعت ثمن نسيانه مرات كثيرة بعدما حوّلت إعادة التوجيه تنزيلًا «سليمًا» إلى ملف HTML حجمه 400 بايت. ينبغي أن ترى مؤشر التقدم يتحرك في الطرفية، ثم ينتهي بظهور الملف في الدليل الحالي.
عند نجاح الأمر، يصل شريط التقدم إلى 100% ويظهر curl-8.21.0.tar.gz في المجلد الحالي. تحقّق من الملف قبل استخدامه:
ls -lh curl-8.21.0.tar.gz
الخطوة 2: تنزيل الملف وإعادة تسميته
استخدم -o عندما تريد اسمًا محليًا محددًا بدلًا من آخر ما ينتهي به الرابط:
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
العلامة -S هنا تعيد عرض الأخطاء في حال كنت قد استخدمت أيضًا -s في موضع آخر من السكربت. هذا المزيج — -L -o <name> -S — هو عمليًا أمر التنزيل الافتراضي لدي لملف واحد.
الخطوة 3: استئناف تنزيل متقطع
إذا انقطع تنزيل كبير في منتصفه (واي فاي سيئ، خلل في VPN، أيًا كان)، فلا تبدأ من الصفر. نفّذ:
curl -C - -LO https://example.com/large-file.iso
الشرط المهم: هذا يعمل فقط إذا كان الخادم يدعم طلبات النطاقات الجزئية byte-range. تشير Accept-Ranges: bytes إلى ذلك بشكل إيجابي، لكن غيابها لا يثبت أن النطاقات غير مدعومة. الفحص الموثوق هو رد الخادم على طلب نطاق فعلي: الاستجابة القابلة للاستئناف تعود عادةً برمز 206 Partial Content مع Content-Range صالح. شغّل أمر الاستئناف وراجع الحالة عبر -v أو -D -؛ وإذا تجاهل الخادم النطاق أو رفض الموضع، فأعد البدء بوضوح بدلًا من افتراض أن الملف الجزئي آمن.
الخطوة 4: التنزيل مع شريط تقدم أو بصمت
لشكل أنظف في الطرفية التفاعلية: curl -# -LO <url>. وللسكربتات ومهام cron عندما تريد الأخطاء فقط من دون الضوضاء: curl -sS -LO <url>. أستخدم النسخة الصامتة تقريبًا في كل شيء ما عدا عندما أُشخّص يدويًا.
الخطوة 5: تحديد سرعة التنزيل
على اتصال مكتبي مشترك (أو عندما لا أريد أن أكون «ذلك الشخص» الذي يلتهم عرض النطاق أثناء مكالمة فيديو)، أستخدم التقييد التالي:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
الوحدات هي K وM وG، أي كيلوبايت وميغابايت وغيغابايت في الثانية على الترتيب.
الخطوة 6: حفظ رؤوس الاستجابة بجانب الملف
أحيانًا أحتاج إلى معرفة ما أرسله الخادم بالضبط — نوع المحتوى، ترويسات التخزين المؤقت، وما شابه — من دون إرباك الطرفية:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
هذا يضع رؤوس الاستجابة في headers.txt بينما يذهب الملف الفعلي إلى file.zip. ممتاز لتشخيص عدم تطابق نوع المحتوى أو التحقق من أن CDN يخزّن ما تظن أنه يخزّنه فعلًا.
نصائح ومزالق شائعة
- نصيحة: اجعل
-Lخيارك الافتراضي دائمًا. بصراحة لا أرى أي عيب في إضافته، وقد خسرت ساعات بسبب نسيانه. - نصيحة: عند كتابة السكربتات، ادمج
--failمع أمر التنزيل حتى تؤدي الاستجابة غير 2xx إلى خروج السكربت بخطأ فعلي، بدل حفظ صفحة خطأ بصمت كما لو كانت ملفك. - مأزق: لا تجمع بين
-C -و--remove-on-error— فهما غير متوافقين وفق توثيق curl، لأن الاستئناف يحتاج بقاء الملف الجزئي في مكانه. - مأزق: قد يستبدل
-Oالملفات من دون تنبيه. إذا كنت تنزل دفعة ملفات إلى مجلد مشترك، فاستخدم--output-dirلإبقاء الأمور منظمة.
كيفية تنزيل عدة ملفات والتنزيلات الدُفعية باستخدام cURL
أمثلة الملف الواحد هي الجزء السهل. أما سير العمل الحقيقي الذي بنيته — مثل سحب صادرات البيانات الليلية أو مزامنة الملفات الثنائية بين خوادم البناء — فكان يحتاج إلى التوازي، وهنا تتوقف معظم الشروحات... ببساطة. هناك ثلاثة أساليب تستحق المعرفة، وكل واحد منها خطوة أعلى في التعقيد.
الأسلوب 1: عدة روابط في أمر cURL واحد
الخيار الأبسط هو مجرد سرد الروابط:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
هذا يعمل، لكنه تسلسلي — أي إن curl يُكمل ملفًا واحدًا بالكامل قبل أن يبدأ الذي يليه. مناسب لثلاثة ملفات، ومؤلم لثلاثمئة.
الأسلوب 2: التنزيل المتوازي باستخدام --parallel (من curl 7.66+)
منذ curl 7.66، يمكنك إضافة --parallel (أو -Z) لجلب عدة روابط في الوقت نفسه:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
ومن المفيد أن تعرف أن الحد الأقصى الافتراضي للتوازي هو 50، وهو عدد أكبر بكثير من الاتصالات التي سيشكرها الخادم أو شبكتك أنت. أفضل أن أحدد --parallel-max بشكل صريح ومحافظ — عادةً من 4 إلى 8 — بدلًا من الاعتماد على القيمة الافتراضية.
الأسلوب 3: استخدام xargs وحلقات Bash للتوازي من قائمة روابط
عندما أملك قائمة كبيرة من الروابط في ملف نصي، ألجأ غالبًا إلى xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
أو، إذا أردت تحكمًا أكبر في ما يحدث مع كل مهمة، أستخدم حلقة bash مع العمليات الخلفية:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
أمر wait في النهاية مهم — فبدونه سيغادر السكربت قبل اكتمال التنزيلات الخلفية.
متى تختار wget أو aria2 بدلًا من cURL
سأكون مباشرًا: cURL ليس دائمًا الأداة المناسبة. إذا كنت تحتاج إلى عكس شجرة مجلدات موقع كامل، فإن wget -r يتعامل مع الزحف التكراري تلقائيًا بطريقة لم يُبنَ cURL أصلًا لأجلها. وإذا كنت تحتاج إلى تنزيلات مجزأة من مصادر متعددة لأقصى سرعة على ملف ضخم واحد، فإن aria2c أسرع فعلًا.
| الأداة | الأنسب لـ |
|---|---|
| cURL | الدقة، والسكربتات، والتنزيلات لملف واحد أو دفعات صغيرة، والتعامل مع الـ API |
| wget | التنزيلات التكرارية/المرآة الكاملة للمواقع، وجلب الملفات الثابتة بكميات أكبر |
| aria2 | التنزيلات متعددة المصادر/المجزأة، وتعظيم السرعة على الملفات الكبيرة |
تكمن قوة cURL دائمًا في الدقة وقابلية الدمج — تمرير البيانات، والسكربتات، ومرونة البروتوكولات — لا في الزحف القسري.
كيفية تنزيل الملفات المحمية باستخدام cURL: أنماط المصادقة
تتوقف معظم شروحات cURL عند -u user:pass ثم تكتفي بذلك. وهذا إرث من الإنترنت القديم. في 2026، الملفات التي أنزلها فعليًا تأتي من REST APIs، ولوحات تحكم مبنية على الجلسات، وأنظمة CI — وكل منها يفضّل نوعًا مختلفًا من الاعتماد.
المصادقة الأساسية
curl -u username:password -O https://legacy-server.example.com/file.zip
مناسبة لخوادم FTP التقليدية أو نقاط HTTP البسيطة. فقط اعلم أن كلمة المرور ستظهر في سجل أوامر shell وفي قائمة العمليات ما لم تكن حذرًا — وليس هذا ما سأستخدمه لشيء حساس.
مصادقة Bearer / OAuth Token
هذه هي الحالة التي لا تحظى بما يكفي من التمثيل في معظم الأدلة، وهي التي أستخدمها الآن غالبًا:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
هذا نمط حقيقي لسحب ملف إصدار خاص من GitHub — فقط استبدل الرمز المميز ومعرّف الأصل. معظم REST APIs والموارد المحمية بـ OAuth2 تتحدث بهذه اللغة الآن.
مصادقة الجلسات المعتمدة على ملفات الارتباط
لتطبيقات الويب التي ينشئ فيها تسجيل الدخول جلسة، احفظ مخزن الكوكيز أثناء تسجيل الدخول وأعد استخدامه عند التنزيل:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
ملف .netrc للبيئات المؤتمتة وCI
هذه هي الطريقة المفضلة لدي لأي شيء يعمل من دون مراقبة. أنشئ ملف ~/.netrc (أو _netrc في Windows):
machine example.com
login myusername
password mypassword
شدّد الحماية عليه باستخدام chmod 600 ~/.netrc، ثم استدعِه هكذا:
curl --netrc -LO https://example.com/protected-file.zip
الميزة هنا أن بيانات الاعتماد لا تلامس سجل أوامر shell ولا مصدر السكربت — وهذا مهم جدًا فعلًا في CI/CD حيث غالبًا ما تُسجَّل السكربتات كاملة.
| طريقة المصادقة | العلم/الخيار | الأنسب لـ |
|---|---|---|
| المصادقة الأساسية | -u user:pass | FTP القديم وHTTP البسيط |
| رمز Bearer | -H "Authorization: Bearer <token>" | REST APIs وOAuth2 |
| مصادقة الكوكيز | -b cookies.txt (+ -c للحفظ) | تطبيقات الويب المعتمدة على الجلسات |
ملف .netrc | --netrc أو --netrc-file | CI/CD والبيئات المؤتمتة |
استكشاف أخطاء تنزيل cURL الشائعة وإصلاحها
هذا هو القسم الذي كنت أتمنى لو وجدته عندما بدأت، لأن قليلًا جدًا من الشروحات يتناوله. «لماذا لا يعمل تنزيل curl الخاص بي» بحث حقيقي وشائع ومسبب للإحباط، وغالبًا ما تكون الحلول سطرًا واحدًا فقط عندما تعرف السبب.
| العَرَض | السبب المحتمل | الحل |
|---|---|---|
curl: (60) SSL certificate problem | شهادة موقعة ذاتيًا أو منتهية الصلاحية | --cacert <file> أو -k (للتطوير فقط) |
403 Forbidden / ملف فارغ | الخادم يحظر User-Agent الافتراضي الخاص بـ curl | -A "Mozilla/5.0..." أو -H "User-Agent: ..." |
يبدأ التنزيل من 0 مع -C - | الخادم لا يدعم Range | افحص بـ curl -I <url> وابحث عن Accept-Ranges: bytes |
| حفظ ملف بحجم 0 بايت | لم يتم تتبع إعادة التوجيه | أضف العلم -L |
curl: (28) Operation timed out | خادم بطيء أو مشاكل شبكة | --connect-timeout 10 --max-time 300 + --retry 3 |
| حفظ صفحة HTML بدل الملف | الصفحة تحتاج إلى تنفيذ JavaScript | لا يستطيع curl تشغيل JS — راجع القسم أدناه |
أخطاء شهادة SSL: ماذا تعني وكيف تُصلحها
الخطأ 60 يعني أن curl لم يتمكن من التحقق من شهادة SSL الخاصة بالخادم — عادةً لأنها موقعة ذاتيًا، أو منتهية، أو صادرة من جهة تصديق لا يثق بها curl. إذا كنت تملك الخادم، وجّه curl إلى حزمة CA الصحيحة باستخدام --cacert /path/to/ca.pem. أما العلم -k (--insecure) فيتجاوز التحقق بالكامل، وهو مقبول في بيئة تطوير محلية، لكنه فكرة سيئة جدًا لأي شيء يلامس الإنتاج أو بيانات مستخدم حقيقية.
أخطاء 403 Forbidden والتنزيلات الفارغة
عدد مفاجئ من الخوادم يحظر الطلبات التي تعرّف نفسها على أنها curl/8.21.0 (وهي سلسلة User-Agent الافتراضية الخاصة بـ curl)، بافتراض أنها روبوتات أو أدوات كَشْف. والإصلاح غالبًا بسيط: تظاهر بأنك متصفح.
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
وللتأكد مما يعود فعليًا قبل الالتزام بتنزيل كامل، أستخدم: curl -o /dev/null -s -w "%{http_code}\n" <url>.
المهلات، وإعادة المحاولة، والاتصالات غير المستقرة
هذا هو الأمر الذي كنت سأوشمه على ذراعي لو كنت أكثر شجاعة تجاه الوشوم.
أمر التنزيل الذي أستخدمه فعلًا في سكربتات الإنتاج، يجمع كل أعلام الاعتمادية معًا:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
هذا يعني تتبع التحويلات، والاستئناف، وخمس محاولات إعادة مع تأخير 3 ثوانٍ، ومهلة اتصال 10 ثوانٍ، وحدًا إجماليًا قدره 10 دقائق، وفشلًا صريحًا عند حالات HTTP السيئة — أي تقريبًا كل ما تعلمت بالطريقة الصعبة ضرورة تضمينه.
cURL في الأتمتة الحقيقية: مسارات CI/CD، والتمرير عبر الأنابيب، وأمان السكربتات
تمرير مخرجات cURL إلى أدوات أخرى
ليس من الضروري أن يحفظ curl أي شيء على القرص أصلًا — فالتمرير المباشر إلى أمر آخر من أكثر ميزاته التي لا يُقدَّر قدرها:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
نزّل ثم فك الضغط، أو نزّل ثم حلّل، في سطر واحد. هذا هو النمط الذي أستخدمه باستمرار لسحب البيانات لمرة واحدة.
استخدام cURL في GitHub Actions وCI/CD
خطوة GitHub Actions مبسطة لتنزيل ملف ثنائي مع منطق إعادة المحاولة والفشل الصريح عند الخطأ:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
خزّن أي رموز مميزة كأسرار CI ومرّرها عبر متغيرات البيئة — لا تضعها أبدًا في نص السكربت نفسه. واستخدم --fail (أو --fail-with-body إذا احتجت إلى رؤية جسم الخطأ أثناء التشخيص) حتى يؤدي التنزيل المعطوب فعلًا إلى كسر البناء بدل النجاح الصامت مع بيانات تالفة.
سؤال الأمان في curl | sh
هذا الموضوع يظهر تقريبًا في كل منتدى للمطورين قرأته، ولسبب وجيه: تمرير curl مباشرة إلى sh يعني تنفيذ كود بعيد لم تطّلع عليه، اعتمادًا كليًا على الثقة بأن الخادم لم يُخترق وأن الاتصال لم يُعبث به. هذه هي المخاطرة الحقيقية — ليست هلعًا، بل قلقًا مشروعًا وبسيطًا في سلسلة التوريد.
النهج الأكثر أمانًا هو أن تنزل أولًا، ثم تراجع السكربت، وتتحقق من المجموع الاختباري أو توقيع GPG إن وُجد، ثم تشغّله بعد ذلك فقط:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # اقرأه فعلًا
sha256sum install.sh # قارن بالمجموع المنشور إن توفر
bash install.sh
لا تزال أدوات التثبيت المعروفة مثل rustup وHomebrew تستخدم نمط curl | sh، وهو مقبول عمومًا في تلك الحالات المحددة لأن القائمين عليها وقنوات التوزيع معروفة جيدًا. ومع ذلك، أفضل دائمًا أن أضيّع عشر ثوانٍ إضافية في فحص السكربت بدل أن أكتشف بالطريقة الصعبة أنني لم يكن ينبغي أن أثق به.
متى لا يكفي cURL: الصفحات المعتمدة على JavaScript، ومواقع مكافحة الروبوتات، والبيانات المهيكلة
هناك نمط فشل يربك كثيرًا من الناس، ونادرًا ما يكون خطأهم: تشغّل curl -O على صفحة تبدو عادية، وبدل المحتوى المتوقع تحصل على هيكل HTML فارغ، أو صفحة تحدٍ من Cloudflare، أو شيء يبدو كأنه حطام. cURL فعل بالضبط ما صُمم له — جلب استجابة HTTP الخام — لكنه لا يستطيع تنفيذ JavaScript، أو حل CAPTCHA، أو تجاوز نظام بصمة مكافحة الروبوتات. هذه ليست عيوبًا في cURL؛ إنها ببساطة خارج نطاق عمله.
لماذا يفشل cURL مع صفحات الويب الحديثة
غالبًا ما تعيد تطبيقات الصفحة الواحدة الحديثة هيكل HTML شبه فارغ، ثم يجري عرض المحتوى الحقيقي على جانب العميل بواسطة JavaScript بعد تحميل الصفحة — وهو شيء لا ينفذه curl أصلًا. وإضافة إلى ذلك، تقوم أنظمة مثل Cloudflare وAkamai بتقديم صفحات تحدٍّ لأي شيء لا يبدو كمتصفح حقيقي، كما أن طلبات curl المتكررة من عنوان IP نفسه قد تُخفَّض سرعتها أو تُصنَّف سريعًا كحركة روبوت.
الخطوة التالية: واجهات برمجة تطبيقات للـ AI Web Scraper للمطورين
أقول إن curl هو الأداة المناسبة لنحو 80% من تنزيلات الملفات والبيانات الموجودة هناك — الأصول الثابتة، استجابات الـ API، أي شيء يُقدَّم كموارد HTTP بسيطة. أما الـ 20% الأخرى، أي الصفحات الثقيلة بالجافاسكربت أو المحمية ضد الروبوتات، فهي المكان الذي رأيت فيه المطورين يقضون ساعات في معركة مع الرؤوس وUser-Agent قبل أن يستسلموا في النهاية ويختاروا طبقة مختلفة تمامًا.
وهذه هي بالضبط الفجوة التي بنى فريقي Thunderbit لسدّها، إلى جانب إضافة Chrome التي يعرفنا بها معظم الناس. وعلى جانب المطورين، يوفّر Thunderbit Open API نقطة POST /distill التي تُرجع Markdown نظيفًا جاهزًا للنماذج اللغوية من رابط URL — مع معالجة عرض الصفحة على مستوى الخدمة — ونقطة POST /extract التي تُرجع JSON مهيكلًا مطابقًا للمخطط عندما تحتاج بيانات حقول فعلية بدل نص مقروء. وهناك أيضًا خادم MCP حتى تتمكن الوكلاء داخل Claude أو Cursor من استدعاء thunderbit_distill وthunderbit_extract أثناء المهمة، بالإضافة إلى CLI (npx @thunderbit/thunderbit-cli distill <url>) يعمل كثيرًا مثل curl داخل الطرفية. يمكنك تمرير مخرجات JSON إلى jq، مثل thunderbit distill <url> --format json | jq -r '.data.markdown'؛ أو إرسال مخرجات --format markdown إلى أداة نصية أو ملف بدلًا من ذلك.
وبالمقارنة المباشرة، يكون الفرق واضحًا جدًا. قد يُرجع طلب curl إلى صفحة منتج معتمدة على JavaScript عنصر <div id="root"></div> شبه فارغ. بينما يعيد الأمر المكافئ thunderbit distill محتوى الصفحة المعروض على شكل Markdown نظيف. يعمل Distill بسعر 1 رصيد لكل URL وExtract بسعر 20 رصيدًا لكل URL. وتختلف الحدود الخاصة بكل نقطة نهاية حاليًا: يدعم Batch Distill حتى 100 رابط لكل مهمة، بينما يقبل Batch Extract حتى 50 رابطًا مع مخطط واحد مشترك. راجع توثيق API الحالي قبل تحديد حجم قائمة الإنتاج.
إذا كنت جديدًا على هذا المفهوم عمومًا، فشرحنا الداخلي عن ما الذي يتضمنه استخلاص البيانات من الويب فعلًا يصلح كنقطة بداية جيدة، كما أن دليل الاستخلاص من دون كود يشرح جانب هذه المشكلة لغير المطورين في فريقك ممن لن يلمسوا الطرفية. وللمقارنة الأوسع بين الأدوات في هذا المجال، أعددنا أيضًا عرضًا لأفضل أفضل أدوات AI Web Scraper التي يجدر التعرف إليها.
مرجع سريع: ورقة غش تنزيل cURL
| المهمة | الأمر |
|---|---|
| تنزيل أساسي | curl -LO <url> |
| اسم ملف مخصص | curl -L -o myfile.zip <url> |
| استئناف التنزيل | curl -C - -LO <url> |
| صامت مع إظهار الأخطاء | curl -sSL -O <url> |
| تنزيلات متوازية | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| مصادقة برمز Bearer | curl -H "Authorization: Bearer <token>" -LO <url> |
| أمر التنزيل المفضل في السكربتات | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| تمرير إلى أداة استخراج | curl -sL <url> | tar xz |
الخلاصة وأهم النقاط
يبدأ تنزيل ملف باستخدام curl ببساطة — curl -O وغالبًا انتهيت — لكن المهارة الحقيقية تكمن في الطبقات التي تحته: معرفة متى تضيف -L، ومتى تستأنف بدلًا من البدء من جديد، وأي نمط مصادقة يناسب سير عملك فعلًا، وماذا تفعل في اللحظة التي يظهر فيها 403 أو غلاف HTML فارغ بدل الملف الذي كنت تتوقعه. لقد اعتمدت على كل واحدة من هذه الأنماط في مرحلة ما، وعادةً مباشرة بعد أن تعلمت بالطريقة الصعبة لماذا كانت مهمة.
لا يزال curl، وبكل وضوح، أداتي الافتراضية لتنزيل الملفات البسيطة والعمل على HTTP القابل للسكربت — فهو سريع، وموجود في كل مكان، ويتكامل بشكل جميل مع بقية أنابيب shell. لكن عندما تصطدم بصفحة معروضة عبر JavaScript أو بجدار ضد الروبوتات، فهذه ليست مشكلة curl تُحلّ بأعلام أكثر؛ إنها إشارة إلى أنك تحتاج إلى طبقة مختلفة، وهنا تمامًا يتولى API مثل Thunderbit المهمة من دون أن يجبرك على مغادرة الطرفية.
احفظ ورقة الغش، وجرب أمر إعادة المحاولة والاستئناف في تنزيلك المتعثر القادم، وإذا وصلت إلى الحائط الذي لا يعيد فيه curl سوى بيانات مشوشة، فأنت تعرف ما ستكون الخطوة التالية — صفحة الأسعار في Thunderbit تعرض الآن تفصيل الأرصدة الحالي إذا أردت معرفة تكلفة هذا الانتقال فعلًا، كما أن قناة YouTube لدينا تحتوي على شروحات عملية إن كنت تفضّل المشاهدة على القراءة.
الأسئلة الشائعة حول تنزيل الملفات باستخدام cURL
كيف أنزل ملفًا باستخدام cURL وأحفظه باسم محدد؟
استخدم -o متبوعًا بالاسم الذي تريده: curl -L -o yourname.ext <url>. وأضف -L حتى لا تعرقل إعادة التوجيه عملية التنزيل.
كيف أستأنف تنزيل cURL فشل في المنتصف؟
شغّل curl -C - -LO <url>. لن ينجح هذا إلا إذا كان الخادم يدعم طلبات النطاقات — تحقّق أولًا عبر curl -I <url> وابحث عن Accept-Ranges: bytes في الاستجابة.
هل يستطيع cURL تنزيل ملفات تتطلب تسجيل دخول؟
نعم، بأربع طرق رئيسية: المصادقة الأساسية (-u user:pass)، رموز Bearer (-H "Authorization: Bearer <token>")، الجلسات المعتمدة على الكوكيز (-b cookies.txt)، أو ملف .netrc للبيئات المؤتمتة. راجع قسم المصادقة أعلاه للحصول على التفصيل الكامل ومتى يناسب كل أسلوب.
ما الفرق بين cURL وwget عند تنزيل الملفات؟
يدعم cURL بروتوكولات أكثر، ويكون عادة أفضل للسكربتات والتمرير عبر الأنابيب والتنزيل الدقيق لملف واحد أو دفعات صغيرة. أما wget فهو مصمم للزحف التكراري وعكس أدلة المواقع بالكامل، لذلك يكون أفضل لجلب المواقع الثابتة بكميات كبيرة.
لماذا ينزّل cURL صفحة HTML بدل الملف الحقيقي؟
السببان المعتادان: إما أنك نسيت العلم -L فحوّلك الخادم إلى مكان آخر، أو أن الصفحة تحتاج إلى JavaScript لعرض محتواها الحقيقي — وهو أمر لا يستطيع curl تنفيذه ببساطة. في الحالة الثانية، ستحتاج إلى أداة قادرة على العرض بدلًا من إضافة أعلام أكثر إلى curl.
