إذا كان للرابط أكثر من نقطة واحدة، فإن المنشئ لا يعرف كيفية التعامل معه بعد النقطة الثانية. مثل هذا:
خطأ أم ميزة؟
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
أعتقد أنك استخدمت تأثير التركيز في كتابة canine_pancreatitis. مثل هذا النص.
إعجاب واحد (1)
تكون الأحرف المائلة بسبب الشرطة السفلية بعد النقطة الثانية. إذا قمت بتغليف الرابط بـ \u003c \\u003e أعتقد أنه سيتم عرضه بشكل صحيح:
\u003chttps://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf\u003e
\u003chttps://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf\u003e
4 إعجابات
كل يوم شيء جديد. لم أكن أعرف أن الشرطات السفلية تجعل النص مائلاً أيضاً.
إذن… إنها ميزة، وليست خطأ 
إعجاب واحد (1)
حسنًا، يتم الخلط بين الارتباط التلقائي بسبب النقاط المتعددة في رابط ملف PDF، ويبدأ في قراءة الشرطات السفلية التالية كعلامات تنسيق، وهو ما قد لا يكون مرغوبًا فيه؟
ولكن التفاف الهروب <> هو حل بديل جيد إذا كنت بحاجة إليه. 
إعجابَين (2)
إنها مسألة يتتبعها @Vitaly، ويعتمد الأمر حقًا على مدى شيوع هذه المشكلات. إذا كانت رابطًا واحدًا من كل مليون رابط، فلن يكون من المفيد تحسين أداة ربط الروابط، وإذا كانت رابطًا واحدًا من كل 10 روابط، فبالتأكيد سيكون الأمر كذلك.
4 إعجابات
يعتمد الأمر. إذا كانت هناك حاجة لمشاركة روابط وملفات PDF علمية، كما هو الحال في منتدى الخاص بي، فمن الشائع جدًا تغطية كل رابط تقريبًا. بخلاف ذلك، ليس كثيرًا ولكن أكثر من نقطة واحدة ليس شكلًا نادرًا أيضًا.
من وجهة نظري - هل هناك سبب لعدم كفاية البدء بـ http:// أو https:// والانتهاء بمسافة، بالإضافة إلى أشكال الملفات المسموح بها بالطبع؟
القواعد معقدة ومتطورة.
يعمل رابط الربط أيضًا بدون البادئة https:// لإضافة تعقيد إضافي.
أشك في أنه يمكننا فعل شيء لتخفيف سلوك رابط الربط لحالة البادئة https://، ولكن سأترك الأمر لـ Vitaly لإبداء رأيه.
إعجاب واحد (1)
هذه هي نقطتي بطريقة ما 
حسنًا، أنا أحاول تعليم المستخدمين استخدام < و >. أكبر مشكلة تتعلق بتجربة المستخدم هنا هي أن Discourse يبدأ في التصرف في كثير من الحالات بشكل مختلف عما يتوقعه المستخدمون. ولكن هذا شيء أعمق بكثير من مجرد محاولة تذكر متى تعمل الروابط ومتى لا تعمل.
هذا منطقي بالنسبة لي. أعتقد أنه قد يكون من المناسب فقط ربط أسماء المضيفين المجردة والمطالبة بأن تحتوي عناوين URL التي تحتوي على مسار على http.
لقد سجلت حالة اختبار ولكن باحتمالية عالية إنها نفس المشكلة المستندة إلى التركيز كما كانت من قبل.
بشكل عام، يمكن إصلاح جميع الروابط التي تحتوي على البروتوكول http(s)://، وسأبدأ العمل على هذا قريبًا جدًا (حقًا).
الروابط غير الدقيقة ليس لها حل واقعي (وستفتح الباب أمام ReDoS). ولكن، كما قلت مرات عديدة، القيمة المضافة لهذا الوضع ليست واضحة، وهي معطلة افتراضيًا بسبب العديد من الآثار الجانبية. لقد فعلت ذلك فقط لأن الحزم الأخرى قدمتها.
إعجاب واحد (1)
أعتقد أن حل حالة http(s):// سيقطع شوطًا طويلاً.
الغالبية العظمى من الناس ينسخون عنوان URL من شريط العناوين في المتصفح، وهو يتضمن بالتأكيد البروتوكول.
إعجاب واحد (1)
بالتأكيد. لا أعرف حالات حقيقية يمكن أن تكون فيها الروابط بدون بروتوكول مفيدة.
عادةً ما يكون ذلك للحالات الهامشية حيث يتذكر المستخدمون نطاقًا ويريدون فقط كتابته. عادةً لا يتضمن المسار، ومعامل الاستعلام … نادرًا جدًا.
على سبيل المثال:
مرحباً… هل تفقدت discourse.org
إعجابَين (2)
IMO إجبار هؤلاء المستخدمين على كتابة https:// لمثل هذه الروابط أبسط، من محاربة الآثار الجانبية للوضع غير الدقيق.