سطر جديد

تتضمن العديد من بروتوكولات الاتصالات نوعًا من اصطلاحات الأسطر الجديدة. وعلى وجه الخصوص، تستخدم البروتوكولات التي نشرتها فرقة عمل هندسة الإنترنت (IETF) عادةً تسلسل ASCII CRLF.

في بعض البروتوكولات القديمة، قد يتبع السطر الجديد رمز التحقق أو رمز التكافؤ.

يحدد معيار Unicode عددًا من الأحرف التي يجب أن تتعرف عليها التطبيقات المتوافقة كفواصل للأسطر: ^{[ 9 ]}

قد يبدو الأمر معقدًا للغاية مقارنةً بنهجٍ مثل تحويل جميع فواصل الأسطر إلى حرف واحد (مثل LF )، ولكن نظرًا لأن يونيكود مصمم للحفاظ على جميع المعلومات عند تحويل ملف نصي من أي ترميز موجود إلى يونيكود والعكس ( سلامة البيانات ذهابًا وإيابًا )، فإن يونيكود يحتاج إلى إجراء نفس التمييزات بين فواصل الأسطر التي تُجريها الترميزات الأخرى. على سبيل المثال، يحتوي ترميز EBCDIC على الأحرف NL و CR و LF ، لذا يجب أن تكون جميعها موجودة أيضًا في يونيكود.

تقع معظم أحرف وتسلسلات الأسطر الجديدة ضمن عناصر التحكم C0 في ترميز ASCII (أي أن رموز Unicode الخاصة بها تصل إلى 0x1F ). أما أحرف الأسطر الجديدة الثلاثة التي تقع خارج هذا النطاق - NEL و LS و PS - فغالبًا لا تتعرف عليها البرامج كأسطر جديدة. على سبيل المثال:

• يتعرف JSON على CR و LF كمسافات بيضاء، لكنه لا يتعرف على أي أحرف سطر جديد أخرى. ^{[ 10 ]} لا يمكن أن تظهر عناصر التحكم C0 بدون تهريب داخل السلاسل النصية، ولكن يمكن أن تظهر أي أحرف فاصل أسطر أخرى. ^{[ 11 ]}
• لا يتعرف معيار ECMAScript إلا على CR و LF و LS و PS كفواصل أسطر. ^{[ 12 ]} تاريخيًا، لم تكن فواصل الأسطر غير المُهرّبة مسموحة في السلاسل النصية، ^{[ 13 ]} ولكن تم تغيير ذلك في ES2019 للسماح باستخدام LS و PS غير المُهرّبة في السلاسل النصية ^{[ 12 ]} للتوافق مع JSON. ^{[ 14 ]}
• كان YAML 1.1 يتعرف على الثلاثة كفواصل أسطر؛ أما YAML 1.2 فلم يعد يتعرف عليها كفواصل أسطر من أجل التوافق مع JSON . ^{[ 15 ]}
• لا يتعامل برنامج المفكرة في نظام التشغيل ويندوز ، وهو محرر النصوص الافتراضي لنظام التشغيل مايكروسوفت ويندوز ، مع أي من NEL أو LS أو PS كفواصل أسطر.
• يتعامل برنامج gedit ، وهو محرر النصوص الافتراضي لبيئة سطح المكتب GNOME ، مع LS و PS كفواصل أسطر، ولكن ليس NEL .

يتضمن نظام يونيكود بعض الرموز الرسومية المصممة لعرض حرف مرئي للمستخدم لقارئ المستند، وبالتالي لا يتم التعرف عليها كسطر جديد:

• U+23CE ⏎ رمز العودة
• U+240A ␊ رمز تغذية الخط
• U+240D ␍ رمز إرجاع السطر
• U+2424 ␤ رمز السطر الجديد

في لغة HTML ، تُعتبر فواصل الأسطر مسافات بيضاء، وتُعامل عمومًا ^{بنفس طريقة معاملة} المسافات. ^{[ 16 ]} تُنشأ الفقرات باستخدام نسخ منفصلة من عنصر HTML ، ويتحكم محرك العرض في الفصل المادي بين الفقرات. ^{[ 17 ]}<p>

يمكن إنشاء فواصل الأسطر بشكل صريح باستخدام عنصر HTML . ولتسهيل قراءة صفحات الويب بواسطة برامج قراءة الشاشة، توصي وثائق HTML بعدم استخدام هذا العنصر لتقسيم الفقرات. وبدلاً من ذلك، تقترح مصادر مثل MDN Web Docs استخدام هذا العنصر للقصائد . ^{[ 18 ]}<br>

لتسهيل إنشاء برامج قابلة للنقل ، توفر لغات البرمجة بعض التجريدات للتعامل مع الأنواع المختلفة من تسلسلات الأسطر الجديدة المستخدمة في بيئات مختلفة.

توفر لغة C تسلسلات الهروب\n (سطر جديد) و \r(إرجاع المؤشر إلى بداية السطر). مع ذلك، ليس من الضروري أن تكون هذه التسلسلات مكافئة لأحرف التحكم ASCII LF و CR . يضمن معيار C سمتين فقط:

1. كل من هذه التسلسلات الهروبية يرتبط برقم فريد محدد بواسطة التنفيذ ويمكن تخزينه في قيمة حرف واحد.
2. عند الكتابة إلى ملف أو عقدة جهاز أو مقبس/مخزن مؤقت في وضع النص ، \nتُترجم البيانات تلقائيًا إلى تسلسل الأسطر الجديد الأصلي الذي يستخدمه النظام، والذي قد يتجاوز حرفًا واحدًا. عند القراءة في وضع النص، يُترجم تسلسل الأسطر الجديد الأصلي مرة أخرى إلى تسلسل الأسطر الجديد \n. في الوضع الثنائي ، لا تُجرى أي ترجمة، ويُخرج التمثيل الداخلي الناتج عن عملية \nالكتابة مباشرةً.

في أنظمة تشغيل يونكس ، حيث نشأت لغة C، يكون تسلسل السطر الجديد الأصلي هو ASCII LF ( 0x0A )، لذا تم تعريفه ببساطة على هذه القيمة. وبما أن التمثيل الداخلي والخارجي متطابقان، فإن الترجمة التي تتم في وضع النص لا تُحدث أي تغيير ، ولا يوجد في يونكس مفهوم لوضع النص أو الوضع الثنائي. وقد دفع هذا العديد من المبرمجين الذين طوروا برامجهم على أنظمة يونكس إلى تجاهل هذا التمييز تمامًا، مما أدى إلى كتابة شفرة برمجية غير قابلة للنقل إلى منصات مختلفة.\n

يُفضّل تجنّب استخدام دالة fgets () من مكتبة C القياسية في الوضع الثنائي، لأنّ أي ملف لا يُكتب وفقًا لاتفاقية سطر جديد في أنظمة يونكس سيُقرأ بشكل خاطئ. كذلك، في الوضع النصي، أي ملف لا يُكتب وفقًا لتسلسل سطر جديد الأصلي للنظام (مثل ملف أُنشئ على نظام يونكس ثم نُسخ إلى نظام ويندوز) سيُقرأ بشكل خاطئ أيضًا.

من المشاكل الشائعة الأخرى استخدام \nبروتوكول إنترنت يفرض استخدام رمز ASCII CR + LF لإنهاء الأسطر. تعمل الكتابة إلى دفق نصي بشكل صحيح على أنظمة ويندوز، لكنها تُنتج رمز LF فقط على أنظمة يونكس، ورمزًا مختلفًا تمامًا على أنظمة أخرى. يُعد استخدام الوضع الثنائي أفضل قليلًا.\n\r\n

توفر العديد من اللغات، مثل C++ و Perl و ^{[ 19 ]} و Haskell، نفس تفسير \nC. يحتوي C++ على نموذج إدخال/إخراج (I/O) بديل حيث يمكن استخدام المعالج std::endl لإخراج سطر جديد (ويقوم بتفريغ مخزن البيانات).

توفر لغات البرمجة Java و PHP [ ^{20 ]} و Python ^{[ 21 ]} التسلسل (لـ ASCII CR + LF ). وعلى عكس لغة C، تضمن هذه اللغات تمثيل القيمتين U+000D و U+000A على ^{التوالي} .\r\n

لا تُترجم دوال الإدخال/الإخراج في مكتبة فئات جافا هذه القيم تلقائيًا إلى تسلسلات أسطر جديدة خاصة بالمنصة عند الإدخال أو الإخراج. بدلاً من ذلك، توفر هذه الدوال وظائف لكتابة سطر كامل تُضيف تلقائيًا تسلسل الأسطر الجديدة الأصلي، ووظائف لقراءة الأسطر تقبل أيًا من CR أو LF أو CR + LF كفاصل أسطر (انظر BufferedReader.readLine() ). يمكن استخدام الدالة System.lineSeparator() لاسترداد فاصل الأسطر الأساسي. ويتم إدراج هذا الفاصل تلقائيًا عند استخدام مُحدد التنسيق في .%nSystem.out::printf

مثال:

String eol = System.lineSeparator ( ); String lineColor = "Color: Red " + eol ;

تدعم لغة بايثون ميزة "دعم الأسطر الجديدة الشاملة" بشكل افتراضي، والتي تُترجم جميع اصطلاحات إنهاء الأسطر الثلاثة الشائعة ( \n, \r, \r\n) إلى اصطلاح بايثون القياسي \nعند فتح ملف للقراءة، وعند استيراد الوحدات، وعند تنفيذ ملف. ويمكن التحكم بهذه الميزة باستخدام الوسيطة newlineفي open()الدالة عند فتح الملف. ^{[ 22 ] [ 23 ]}

أنشأت بعض لغات البرمجة متغيرات وثوابت وإجراءات فرعية خاصة لتسهيل إدخال أسطر جديدة أثناء تنفيذ البرنامج. في بعض اللغات ، مثل PHP و Perl ، يُشترط استخدام علامات اقتباس مزدوجة لإجراء استبدال الهروب لجميع تسلسلات الهروب، بما في ذلك `--` \nو`-- \r`. في PHP، لتجنب مشاكل التوافق، يجب إصدار تسلسلات الأسطر الجديدة باستخدام الثابت PHP_EOL. ^{[ 24 ]}

مثال بلغة C# :

string eol = Environment.NewLine ; string lineColor = "Color: Red" + eol ; string eol2 = " \n" ; string lineColor2 = " Color: Blue" + eol2 ;

تتسبب اصطلاحات الأسطر الجديدة المختلفة في عرض ملفات النصوص التي تم نقلها بين أنظمة من أنواع مختلفة بشكل غير صحيح.

يظهر النص في الملفات التي تم إنشاؤها باستخدام البرامج الشائعة في أنظمة التشغيل الشبيهة بنظام Unix أو نظام التشغيل Mac OS الكلاسيكي على شكل سطر واحد طويل في معظم البرامج الشائعة في نظامي التشغيل MS-DOS و Microsoft Windows لأن هذه البرامج لا تعرض فاصل أسطر line feedواحد .carriage return

وعلى العكس من ذلك، عند عرض ملف مصدره جهاز كمبيوتر يعمل بنظام ويندوز على نظام يشبه نظام يونكس، قد يتم عرض CR الإضافي كفاصل سطر ثانٍ، أو كـ ^M ، أو كـ <cr> في نهاية كل سطر.

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

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

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

تُلزم معظم بروتوكولات الإنترنت النصية (بما في ذلك HTTP و SMTP و FTP و IRC وغيرها الكثير) باستخدام تسلسل ASCII CR + LF ( , 0x0D 0x0A ) على مستوى البروتوكول، ولكنها توصي التطبيقات المتسامحة بالتعرف على LF المنفرد ( , 0x0A ) أيضًا. على الرغم من هذا المعيار المُحدد، تستخدم العديد من التطبيقات خطأً تسلسل الهروب لسطر جديد ( LF ) بدلاً من التركيبة الصحيحة لتسلسل الهروب لسطر جديد وتسلسل الهروب لإرجاع المؤشر ( CR + LF ) (انظر قسم "سطر جديد في لغات البرمجة" أعلاه). يؤدي هذا الاستخدام غير المقصود لتسلسلات الهروب الخاطئة إلى مشاكل عند محاولة التواصل مع الأنظمة التي تلتزم بالتفسير الأكثر صرامة للمعايير بدلاً من التفسير المتسامح المُقترح. أحد هذه الأنظمة غير المتسامحة هو وكيل نقل البريد qmail الذي يرفض بنشاط قبول الرسائل من الأنظمة التي تُرسل LF منفردة بدلاً من CR + LF المطلوبة . ^{[ 25 ]}\r\n\n\n\r\n

ينص تنسيق رسائل الإنترنت القياسي ^{[ 26 ]} للبريد الإلكتروني على ما يلي: "يجب أن يظهر حرفا CR وLF معًا فقط كـ CRLF؛ ولا يجوز ظهورهما بشكل منفصل في نص الرسالة". وقد أدت الاختلافات بين تطبيقات SMTP في كيفية تعاملها مع حرفي LF و/أو CR المجردين إلى هجمات انتحال SMTP، والتي تُعرف باسم "تهريب SMTP". ^{[ 27 ]}

يستطيع بروتوكول نقل الملفات (FTP) تحويل أسطر جديدة تلقائيًا في الملفات المنقولة بين أنظمة ذات تمثيلات أسطر جديدة مختلفة عند النقل في "وضع ASCII". مع ذلك، غالبًا ما يؤدي نقل الملفات الثنائية في هذا الوضع إلى نتائج كارثية: إذ يُترجم أي تسلسل بايتات لسطر جديد - والذي لا يحمل دلالات فاصلة أسطر في هذا السياق، بل هو مجرد جزء من تسلسل بايتات عادي - إلى أي تمثيل سطر جديد يستخدمه النظام الآخر، مما يُتلف الملف فعليًا. غالبًا ما تستخدم برامج FTP بعض الطرق الاستدلالية (مثل فحص امتدادات أسماء الملفات ) لاختيار الوضع الثنائي أو ASCII تلقائيًا، ولكن في النهاية، يقع على عاتق المستخدمين التأكد من نقل ملفاتهم بالوضع الصحيح. في حال وجود أي شك بشأن الوضع الصحيح، يُنصح باستخدام الوضع الثنائي، حيث لن يتم تعديل أي ملفات بواسطة FTP، على الرغم من أنها قد تُعرض بشكل غير صحيح. ^{[ 28 ]}

تُستخدم برامج تحرير النصوص غالبًا لتحويل ملف نصي بين تنسيقات أسطر جديدة مختلفة؛ ويمكن لمعظم برامج التحرير الحديثة قراءة وكتابة الملفات باستخدام اصطلاحات ASCII CR / LF المختلفة على الأقل .

على سبيل المثال، يمكن لمحرر النصوص Vim جعل الملف متوافقًا مع محرر النصوص Notepad في نظام التشغيل Windows.

: تعيين تنسيق الملف = dos wq​

قد لا تكون برامج التحرير مناسبة لتحويل الملفات الكبيرة أو التحويل الجماعي للعديد من الملفات. بالنسبة للملفات الكبيرة (على نظام التشغيل Windows NT)، يُستخدم الأمر التالي غالبًا:

D:\> TYPE unix_file | FIND /V "" > dos_file 

تتضمن البرامج المتخصصة لتحويل الملفات بين اصطلاحات الأسطر المختلفة: unix2dos و dos2unix و mac2unix و unix2mac و mac2dos و dos2mac و flip . ^{[ 29 ]} يتوفر الأمر tr في جميع أنظمة يونكس تقريبًا ، ويمكن استخدامه لإجراء عمليات استبدال عشوائية على الأحرف المفردة. يمكن تحويل ملف نصي من نظام DOS/Windows إلى تنسيق يونكس ببساطة عن طريق إزالة جميع أحرف ASCII CR .

$ tr -d '\r' < ملف الإدخال > ملف الإخراج

أو، إذا كان النص يحتوي فقط على أسطر جديدة من نوع CR ، عن طريق تحويل جميع أسطر CR الجديدة إلى LF باستخدام

$ tr '\r' '\n' < ملف الإدخال > ملف الإخراج

تُنفذ نفس المهام أحيانًا باستخدام awk أو sed أو في لغة Perl إذا كانت المنصة تحتوي على مترجم Perl:

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile # UNIX to DOS (إضافة CRs على أنظمة Linux وBSD التي لا تحتوي على امتدادات GNU) $ awk '{gsub("\r",""); print;}' inputfile > outputfile # تحويل من DOS إلى UNIX (إزالة أحرف CR على أنظمة Linux وBSD التي لا تحتوي على امتدادات GNU) $ sed -e 's/$/\r/' inputfile > outputfile # تحويل من UNIX إلى DOS (إضافة أحرف CR على أنظمة Linux التي تستخدم امتدادات GNU) $ sed -e 's/\r$//' inputfile > outputfile # تحويل من DOS إلى UNIX (إزالة أحرف CR على أنظمة Linux التي تستخدم امتدادات GNU) $ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile # التحويل إلى DOS $ perl -pe 's/\r?\n|\r/\n/g' inputfile > outputfile # التحويل إلى UNIX $ perl -pe 's/\r?\n|\r/\r/g' inputfile > outputfile # التحويل إلى Mac القديم

يمكن لأمر الملف تحديد نوع نهايات الأسطر:

$ file myfile.txt myfile.txt: نص إنجليزي ASCII، مع فواصل أسطر CRLF

يمكن استخدام أمر egrep (grep الموسع) في نظام Unix لعرض أسماء ملفات Unix أو DOS (بافتراض أنها ملفات بنمط Unix وDOS فقط، وليس ملفات بنمط Mac OS الكلاسيكي):

$ egrep -L '\r\n' myfile.txt # عرض ملف بنمط UNIX (منتهي بـ LF) $ egrep -l '\r\n' myfile.txt # عرض ملف بنمط DOS (منتهي بـ CRLF)

تتيح أدوات أخرى للمستخدم تصور أحرف نهاية السطر:

$ od -a myfile.txt $ cat -e myfile.txt $ cat -v myfile.txt $ hexdump -c myfile.txt