ملاحظة جانبية: عندما حاولت النشر، رأيت نافذة منبثقة تقول “حدث خطأ: عذرًا، يمكن للمستخدمين الجدد وضع رابطين فقط في المنشور”. لا أعرف ما نوع البريد العشوائي الذي يمكنه منعه حيث أن رابطًا واحدًا يكفي لمعظم مرسلي البريد العشوائي، ولكن الآن يجب علي استبدال بعض روابطي المنسقة بشكل جميل بتلميحات نصية. عملية إضافة تلميح في محرر markdown الافتراضي هي بحد ذاتها معيبة ومزعجة بما يكفي لتستحق تقريرًا منفصلاً.
ملاحظة جانبية إضافية: يبدو أن المراجع المستندة إلى Markdown تُحسب أيضًا كروابط. سأقوم بإزالتها لصالح الأرقام الفائقة النصية Unicode. بعد 40 دقيقة من محاولتي كتابة هذا المنشور.
وفقًا لـ STD 66 / RFC 3986¹ (قائمة مستخرجة سهلة القراءة للناس²)، يمكن ترك 81 حرفًا بدون إلغاء تهريب في جزء أو قائمة انتظار عنوان URL. هذه القائمة، مرتبة بترتيب ASCII بواسطة إطار العمل “Foundation³” في لغة البرمجة Swift: !$&'()*+,-./0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
ما يلي هو عنوان URL يحتوي على العديد من هذه الأحرف: Example Domain'()*+,-./0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~ كما قد ترى، يتم قطع التمييز عند نقطة معينة.
أثناء العمل على مشروعي الذي يستخدم هذه الأحرف الـ 81 لتشفير البيانات الثنائية في أجزاء (على غرار base64، ولكن أكثر إحكامًا) قمت بالتحقق الآن من التمييز المطابق للمواصفات على العديد من المواقع. بينما كان خطأ مماثل، بشكل غير متسق، موجودًا في أماكن أخرى (مثل منتدى GitHub غير قادر على تمييز الحرف الأخير إذا كان ~)، فإن Discourse لديه أكبر مجموعة من الرموز المكسورة. قد تظهر بعض الأحرف أو لا تظهر اعتمادًا على سياق غامض، وبالتالي لا أعتقد أنني سأتمكن من تجميع قائمة شاملة.
¹ ابحث عن Google rfc/rfc3986.txt
² ابحث عن إجابة Stack Overflow #26119120
³ ابحث عن documentation/foundation/nscharacterset/urlfragmentallowed على Apple > Developer
ملاحظة جانبية إضافية إضافية: بعض عناوين البريد الإلكتروني القياسية لا يتم تمييزها أيضًا. سأستخدم رابطي الثاني للربط إلى https://e-mail.wtf لبعض الأمثلة.
غير مميز، ولكن يجب أن يكون:
orgmail(to John Doe)@example.com
“:(){ :|:& };:”@example.com
magic@[::1]