อักขระขึ้นบรรทัดใหม่ (มักเรียกว่าการสิ้นสุดบรรทัด , สิ้นสุดบรรทัด ( EOL ), บรรทัดถัดไป ( NEL ) หรือการขึ้นบรรทัดใหม่ ) เป็นอักขระควบคุมหรือลำดับของอักขระควบคุมใน ข้อกำหนด การเข้ารหัสอักขระเช่นASCII , EBCDIC , Unicodeเป็นต้น อักขระขึ้นบรรทัดใหม่ใช้เพื่อบ่งบอกถึงจุดสิ้นสุดของบรรทัดข้อความและจุดเริ่มต้นของบรรทัดใหม่^{[ 1 ]}

ในช่วงกลางศตวรรษที่ 19 ก่อนการประดิษฐ์เครื่องพิมพ์โทรเลขและเครื่องส่งโทรเลข ผู้ใช้งาน รหัสมอร์สหรือผู้ส่งโทรเลขได้คิดค้นและใช้รหัสมอร์สเพื่อเข้ารหัสการจัดรูปแบบข้อความที่มีช่องว่างในข้อความที่เป็นทางการ โดยเฉพาะอย่างยิ่งรหัสมอร์สBT (mnemonic break text) ซึ่งแสดงโดยการต่อกันของตัวอักษร "B" และ "T" ในรหัสมอร์ส โดยไม่มีช่องว่างระหว่างตัวอักษรตามปกติ จะถูกใช้ในรหัสมอร์สเพื่อเข้ารหัสและระบุบรรทัดใหม่หรือส่วนใหม่ในข้อความที่เป็นทางการ

ต่อมา ในยุคของเครื่องโทรพิมพ์ สมัยใหม่ ได้มีการพัฒนาชุดรหัสควบคุมอักขระมาตรฐาน (ASCII) เพื่อช่วยในการจัดรูปแบบข้อความที่มีช่องว่าง ASCII ได้รับการพัฒนาขึ้นพร้อมกันโดยองค์การมาตรฐานสากล (ISO) และสมาคมมาตรฐานอเมริกัน (ASA) ซึ่ง ASA เป็นองค์กรก่อนหน้าของสถาบันมาตรฐานแห่งชาติอเมริกัน (ANSI) ในช่วงปี 1963 ถึง 1968 ร่างมาตรฐานของ ISO สนับสนุนการใช้การขึ้นบรรทัดใหม่โดยใช้การขึ้นบรรทัดใหม่แบบCR + LFหรือLF เพียงอย่าง เดียวในขณะที่ร่างมาตรฐานของ ASA สนับสนุนเฉพาะCR + LFเท่านั้น

ลำดับCR + LFมักใช้ในระบบคอมพิวเตอร์รุ่นแรกๆ หลายระบบที่ใช้เครื่องพิมพ์Teletype— โดยทั่วไปคือ Teletype รุ่น 33 ASR—เป็นอุปกรณ์คอนโซล เนื่องจากลำดับนี้จำเป็นสำหรับการวางตำแหน่งเครื่องพิมพ์เหล่านั้นที่จุดเริ่มต้นของบรรทัดใหม่ การแยกการขึ้นบรรทัดใหม่เป็นสองฟังก์ชันนั้นปกปิดข้อเท็จจริงที่ว่าหัวพิมพ์ไม่สามารถกลับจากด้านขวาสุดไปยังจุดเริ่มต้นของบรรทัดถัดไปได้ทันเวลาเพื่อพิมพ์อักขระถัดไป อักขระใดๆ ที่พิมพ์หลังจากCRมักจะพิมพ์เป็นรอยเปื้อนตรงกลางหน้ากระดาษในขณะที่หัวพิมพ์ยังคงเคลื่อนแคร่กลับไปยังตำแหน่งแรก “วิธีแก้ปัญหาคือการทำให้การขึ้นบรรทัดใหม่เป็นสองอักขระ: CRเพื่อเคลื่อนแคร่ไปยังคอลัมน์ที่หนึ่ง และLFเพื่อเคลื่อนกระดาษขึ้น” ^{[ 2 ]}ในความเป็นจริง มักจำเป็นต้องส่งอักขระเติมพิเศษ —CR หรือNUL ที่ไม่จำเป็น —ซึ่งจะถูกละเลย แต่ให้เวลาหัวพิมพ์เคลื่อนไปยังขอบด้านซ้าย จอแสดงผลวิดีโอรุ่นแรกๆ หลายจอยังต้องการเวลาหลายอักขระเพื่อเลื่อนจอแสดงผล

ในระบบดังกล่าว แอปพลิเคชันต้องสื่อสารโดยตรงกับเครื่องพิมพ์โทรเลขและปฏิบัติตามข้อกำหนดของเครื่อง เนื่องจากแนวคิดเรื่องไดรเวอร์อุปกรณ์ที่ซ่อนรายละเอียดฮาร์ดแวร์ดังกล่าวจากแอปพลิเคชันยังไม่ได้รับการพัฒนาอย่างดี ดังนั้น ข้อความจึงถูกเขียนขึ้นเป็นประจำเพื่อให้ตรงตามความต้องการของเครื่องพิมพ์โทรเลข ระบบมินิคอมพิวเตอร์ส่วนใหญ่ของDECใช้ข้อกำหนดนี้CP/Mก็ใช้เช่นกันเพื่อพิมพ์บนเทอร์มินัลเดียวกันกับที่มินิคอมพิวเตอร์ใช้ จากนั้นMS-DOS (1981) ก็ได้นำCR + LFของCP/M มาใช้ เพื่อให้เข้ากันได้ และข้อกำหนดนี้ก็ถูกสืบทอดไปยังระบบปฏิบัติการ Windows ของ Microsoft ในภายหลัง

ระบบปฏิบัติการ Multics เริ่มพัฒนาในปี 1964 และใช้LF เพียงอย่างเดียวเป็นตัวขึ้นบรรทัดใหม่ Multics ใช้ไดรเวอร์อุปกรณ์เพื่อแปลงอักขระนี้เป็นลำดับใดก็ตามที่เครื่องพิมพ์ต้องการ (รวมถึงอักขระเติมช่องว่าง เพิ่มเติม ) และไบต์เดียวนั้นสะดวกกว่าสำหรับการเขียนโปรแกรม สิ่งที่ดูเหมือนจะเป็นตัวเลือกที่ชัดเจนกว่า – CR – กลับไม่ได้ถูกนำมาใช้ เนื่องจากCRมีฟังก์ชันที่มีประโยชน์ในการพิมพ์ทับบรรทัดหนึ่งด้วยอีกบรรทัดหนึ่งเพื่อสร้าง เอ ฟ เฟกต์ ตัว หนา ขีดเส้นใต้และขีดฆ่าที่สำคัญกว่านั้น การใช้LFเพียงอย่างเดียวเป็นตัวจบบรรทัดได้ถูกรวมเข้าไว้ในร่างมาตรฐานISO/IEC 646 ในที่สุดแล้ว Unixปฏิบัติตามแนวทางของ Multics และต่อมา ระบบ ที่คล้าย Unixก็ปฏิบัติตาม Unix สิ่งนี้ทำให้เกิดความขัดแย้งระหว่าง Windows และระบบปฏิบัติการ ที่คล้าย Unix โดยที่ไฟล์ที่สร้างขึ้นบนระบบปฏิบัติการหนึ่งไม่สามารถจัดรูปแบบหรือตีความได้อย่างถูกต้องโดยระบบปฏิบัติการอื่น (ตัวอย่างเช่นสคริปต์เชลล์ UNIXที่เขียนในโปรแกรมแก้ไขข้อความของ Windows เช่นNotepad ^{[ 3 ] [ 4 ]} )

แนวคิดของการขึ้นบรรทัดใหม่ (CR) และการขึ้นบรรทัดใหม่ (LF) มีความเกี่ยวข้องกันอย่างใกล้ชิด และสามารถพิจารณาแยกกันหรือรวมกันก็ได้ ในสื่อทางกายภาพของเครื่องพิมพ์ดีดและเครื่องพิมพ์ จำเป็นต้องใช้การเคลื่อนที่ สองแกนคือ "ลง" และ "ขวาง" เพื่อสร้างบรรทัดใหม่บนหน้ากระดาษแม้ว่าการออกแบบเครื่องจักร (เครื่องพิมพ์ดีดหรือเครื่องพิมพ์) จะต้องพิจารณาแยกกัน แต่ตรรกะเชิงนามธรรมของซอฟต์แวร์สามารถรวมเข้าด้วยกันเป็นเหตุการณ์เดียวได้ นี่คือเหตุผลที่การขึ้นบรรทัดใหม่ในการเข้ารหัสอักขระสามารถกำหนดได้เป็นCRและLFรวมเข้าด้วยกันเป็นหนึ่งเดียว (โดยทั่วไปเรียกว่าCR+LFหรือCRLF)

ชุดอักขระบางชุดมีรหัสอักขระขึ้นบรรทัดใหม่แยกต่างหากตัวอย่างเช่นEBCDIC มีรหัสอักขระ NLนอกเหนือจากรหัสCRและLF UnicodeนอกเหนือจากรหัสควบคุมASCII CRและLFแล้ว ยังมีรหัสควบคุม "ขึ้นบรรทัดใหม่" ( NEL ) รวมถึงรหัสควบคุมสำหรับเครื่องหมาย "ตัวคั่นบรรทัด" และ "ตัวคั่นย่อหน้า" Unicode ยังมีอักขระที่พิมพ์ได้สำหรับแสดงภาพการป้อนบรรทัด ␊ การขึ้นบรรทัดใหม่ ␍ และรหัสควบคุม C0 อื่นๆ (รวมถึงอักขระขึ้นบรรทัดใหม่ทั่วไป ␤) ในบล็อก รูปภาพควบคุม

• ระบบEBCDIC— ส่วนใหญ่เป็นระบบเมนเฟรม ของ IBMรวมถึงz/OS ( OS/390 ) และIBM i ( OS/400 )—ใช้NL (New Line, 0x15 ) ^{[ 8 ]}เป็นอักขระที่รวมฟังก์ชันของการขึ้นบรรทัดใหม่และการขึ้นบรรทัดใหม่ท้ายบรรทัด อักขระ Unicode ที่เทียบเท่า ( ) เรียกว่าNEL (Next Line) EBCDIC ยังมีอักขระควบคุมที่เรียกว่าCRและLFแต่ค่าตัวเลขของLF ( 0x25 ) แตกต่างจากที่ใช้โดย ASCII ( 0x0A ) นอกจากนี้ EBCDIC บางรุ่นยังใช้NLแต่กำหนดรหัสตัวเลขที่แตกต่างกันให้กับอักขระ อย่างไรก็ตาม ระบบปฏิบัติการเหล่านั้นใช้ระบบไฟล์แบบเรคอร์ดซึ่งจัดเก็บไฟล์ข้อความเป็นหนึ่งเรคอร์ดต่อบรรทัด ในรูปแบบไฟล์ส่วนใหญ่ จะไม่มีการจัดเก็บตัวจบบรรทัดไว้จริง ๆ0x85
• ระบบปฏิบัติการสำหรับซีรี่ส์ CDC 6000กำหนดให้การขึ้นบรรทัดใหม่คืออักขระหกบิตที่มีค่าเป็นศูนย์สองตัวขึ้นไปที่อยู่ท้ายคำ 60 บิต บางการกำหนดค่าก็กำหนดให้อักขระที่มีค่าเป็นศูนย์คือ อักขระ โคลอนด้วย ส่งผลให้โคลอนหลายตัวอาจถูกตีความว่าเป็นการขึ้นบรรทัดใหม่ได้ ขึ้นอยู่กับตำแหน่ง
• RSX-11และOpenVMSก็ใช้ระบบไฟล์แบบบันทึกข้อมูลเป็นเรคอร์ดเช่นกัน โดยจัดเก็บไฟล์ข้อความเป็นหนึ่งเรคอร์ดต่อหนึ่งบรรทัด ในรูปแบบไฟล์ส่วนใหญ่ จะไม่มีการจัดเก็บตัวคั่นบรรทัดไว้ แต่ ระบบ จัดการเรคอร์ด (Record Management Servicesหรือ RMS) สามารถเพิ่มตัวคั่นบรรทัดให้กับแต่ละบรรทัดได้อย่างโปร่งใสเมื่อแอปพลิเคชันเรียกใช้ข้อมูลนั้น เรคอร์ดเหล่านั้นสามารถมีอักขระตัวคั่นบรรทัดเดียวกันได้ ซึ่งอาจถือเป็นข้อดีหรือข้อเสียก็ได้ ขึ้นอยู่กับแอปพลิเคชันนั้นๆ RMS ไม่เพียงแต่จัดเก็บเรคอร์ดเท่านั้น แต่ยังจัดเก็บเมตาเดตาเกี่ยวกับตัวคั่นเรคอร์ดในบิตต่างๆ ของไฟล์ เพื่อทำให้เรื่องซับซ้อนยิ่งขึ้น (เนื่องจากไฟล์อาจมีเรคอร์ดที่มีความยาวคงที่ เรคอร์ดที่มีคำนำหน้าเป็นจำนวน หรือเรคอร์ดที่ลงท้ายด้วยอักขระเฉพาะ) บิตเหล่านี้ไม่ใช่บิตทั่วไป ดังนั้นถึงแม้ว่าจะสามารถระบุได้ว่าCR LFหรือLFหรือแม้แต่CRเป็นตัวคั่นบรรทัด แต่ก็ไม่สามารถแทนที่รหัสอื่นๆ ได้
• ระบบปฏิบัติการ เมนเฟรมรุ่นแรกๆ บางระบบใช้ความยาวบรรทัดคงที่ในระบบดังกล่าว จะถือว่ามีการสิ้นสุดบรรทัดโดยปริยายทุกๆ 72 หรือ 80 ตัวอักษร เป็นต้น ไม่มีการจัดเก็บอักขระขึ้นบรรทัดใหม่ หากมีการนำเข้าไฟล์จากภายนอก บรรทัดที่สั้นกว่าความยาวบรรทัดจะต้องเติมด้วยช่องว่าง ในขณะที่บรรทัดที่ยาวกว่าความยาวบรรทัดจะต้องถูกตัดทอน วิธีการนี้เลียนแบบการใช้บัตรเจาะรูซึ่งแต่ละบรรทัดจะถูกจัดเก็บไว้ในบัตรแยกกัน โดยปกติจะมี 80 คอลัมน์ในแต่ละบัตร และมักจะมีหมายเลขลำดับอยู่ในคอลัมน์ที่ 73-80 ระบบเหล่านี้จำนวนมากเพิ่มอักขระควบคุมการ ขึ้นบรรทัดใหม่ ไว้ที่จุดเริ่มต้นของ ระเบียน ถัดไปซึ่งอาจระบุว่าระเบียนถัดไปเป็นการต่อเนื่องจากบรรทัดที่เริ่มต้นโดยระเบียนก่อนหน้า หรือเป็นบรรทัดใหม่ หรือควรพิมพ์ทับบรรทัดก่อนหน้า (คล้ายกับCR ) บ่อยครั้งที่นี่เป็นอักขระการพิมพ์ปกติ เช่นดังนั้นจึงไม่สามารถใช้เป็นอักขระตัวแรกในบรรทัดได้ เครื่องพิมพ์บรรทัดรุ่นแรกๆ บางเครื่องจะตีความอักขระเหล่านี้โดยตรงในระเบียนที่ส่งมาให้#

โปรโตคอลการสื่อสารหลายตัวมีรูปแบบการขึ้นบรรทัดใหม่ที่เฉพาะเจาะจง โดยเฉพาะอย่างยิ่ง โปรโตคอลที่เผยแพร่โดยInternet Engineering Task Force (IETF) มักใช้ลำดับ ASCII CRLF

ในโปรโตคอลรุ่นเก่าบางแบบ บรรทัดใหม่อาจมีอักขระตรวจสอบความถูกต้องหรืออักขระเทียบค่าตามหลังมา

มาตรฐานUnicodeกำหนดอักขระจำนวนหนึ่งที่แอปพลิเคชันที่สอดคล้องควรรับรู้ว่าเป็นตัวจบบรรทัด: ^{[ 9 ]}

แม้ว่าอาจดูซับซ้อนเกินไปเมื่อเทียบกับวิธีการอื่น เช่น การแปลงตัวจบบรรทัดทั้งหมดให้เป็นอักขระตัวเดียว (เช่นLF ) แต่เนื่องจาก Unicode ถูกออกแบบมาเพื่อรักษาข้อมูลทั้งหมดเมื่อแปลงไฟล์ข้อความจากการเข้ารหัสที่มีอยู่ใด ๆ ไปเป็น Unicode และกลับกัน ( ความสมบูรณ์ของการแปลงไปกลับ ) Unicode จึงจำเป็นต้องแยกความแตกต่างระหว่างการขึ้นบรรทัดใหม่ที่ใช้โดยการเข้ารหัสอื่น ๆ ตัวอย่างเช่นEBCDICมี อักขระ NL , CRและLFดังนั้นทั้งสามตัวนี้จึงต้องมีอยู่ใน Unicode ด้วย

อักขระและลำดับขึ้นบรรทัดใหม่ส่วนใหญ่จะอยู่ในกลุ่มควบคุม 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 ]}
• โปรแกรม Notepad ของ Windows ซึ่งเป็น โปรแกรมแก้ไขข้อความเริ่มต้นของMicrosoft Windowsไม่ถือว่า อักขระ NEL , LSหรือPSเป็นการขึ้นบรรทัดใหม่
• gedit ซึ่งเป็น โปรแกรมแก้ไขข้อความเริ่มต้นของสภาพแวดล้อมเดสก์ท็อปGNOME จะถือว่าLSและPSเป็นการขึ้นบรรทัดใหม่ แต่NELไม่ใช่

Unicode มีสัญลักษณ์ บางตัว ที่ออกแบบมาเพื่อแสดงอักขระที่ผู้ใช้มองเห็นได้แก่ผู้อ่านเอกสาร ดังนั้นสัญลักษณ์เหล่านั้นจึงไม่ถูกมองว่าเป็นอักขระขึ้นบรรทัดใหม่:

• U+23CE ⏎ สัญลักษณ์กลับ
• U+240A ␊ สัญลักษณ์สำหรับป้อนสาย
• U+240D ␍ สัญลักษณ์สำหรับส่งคืนสินค้า
• U+2424 ␤ สัญลักษณ์สำหรับขึ้นบรรทัดใหม่

ในHTMLการขึ้นบรรทัดใหม่ถือเป็นช่องว่างและโดยทั่วไปจะ^ได้รับการปฏิบัติไม่ต่างจากช่องว่าง^{[ 16 ]}ย่อหน้าถูกสร้างขึ้นโดยใช้ส่วนประกอบ HTML ที่แยกจากกันโดยการแยกย่อหน้าทางกายภาพจะถูกควบคุมโดยเอนจินการ^{แสดงผล[ 17 ]}<p>

สามารถสร้างการขึ้นบรรทัดใหม่ได้อย่างชัดเจนโดยใช้แท็ก HTML <br>เพื่ออำนวยความสะดวกให้โปรแกรมอ่านหน้าจอสามารถตีความหน้าเว็บได้ เอกสาร HTML แนะนำไม่ให้ใช้แท็กนี้สำหรับการแบ่งย่อหน้า แต่แหล่งข้อมูลต่างๆ รวมถึงMDN Web Docsแนะนำให้ใช้แท็กนี้สำหรับบทกวีแทน^{[ 18 ]}

เพื่อให้การสร้างโปรแกรมที่พกพา ได้สะดวกง่ายขึ้น ภาษาโปรแกรมจึงมีนามธรรมบางอย่างเพื่อจัดการกับลำดับการขึ้นบรรทัดใหม่ประเภทต่างๆ ที่ใช้ในสภาพแวดล้อมที่แตกต่างกัน

ภาษาซีมีลำดับอักขระหลีก\n (ขึ้นบรรทัดใหม่) และ\r(ขึ้นต้นบรรทัดใหม่) อย่างไรก็ตาม อักขระเหล่านี้ไม่จำเป็นต้องเทียบเท่ากับอักขระควบคุม ASCII LFและCRมาตรฐานของภาษาซีรับประกันเพียงสองคุณลักษณะเท่านั้น:

1. ลำดับการหลีกเลี่ยงแต่ละลำดับนี้จะแมปไปยังหมายเลขเฉพาะที่กำหนดโดยระบบ ซึ่งสามารถจัดเก็บไว้ในค่าอักขระ เดียวได้
2. เมื่อเขียนข้อมูลลงไฟล์ โหนดอุปกรณ์ หรือซ็อกเก็ต/FIFO ในโหมดข้อความข้อมูล\nจะถูกแปลงอย่างโปร่งใสเป็นลำดับขึ้นบรรทัดใหม่ดั้งเดิมที่ระบบใช้ ซึ่งอาจยาวกว่าหนึ่งตัวอักษร เมื่ออ่านข้อมูลในโหมดข้อความ ลำดับขึ้นบรรทัดใหม่ดั้งเดิมจะถูกแปลงกลับเป็นข้อมูลเดิม\nในโหมดไบนารีจะไม่มีการแปลงใดๆ และการแสดงผลภายในที่สร้างขึ้นโดยข้อมูล\nจะถูกส่งออกโดยตรง

บนระบบปฏิบัติการUnix ซึ่งเป็นต้นกำเนิดของภาษา C ลำดับการขึ้นบรรทัดใหม่แบบดั้งเดิมคือ ASCII LF ( 0x0A ) ดังนั้นจึงถูกกำหนดให้มีค่าดังกล่าว เนื่องจากการแสดงผลภายในและภายนอกเหมือนกัน การแปลงที่ทำในโหมดข้อความจึงไม่มีผลอะไรและ Unix ก็ไม่มีแนวคิดเกี่ยวกับโหมดข้อความหรือโหมดไบนารี นี่ทำให้โปรแกรมเมอร์หลายคนที่พัฒนาซอฟต์แวร์บนระบบ Unix เพิกเฉยต่อความแตกต่างนี้โดยสิ้นเชิง ส่งผลให้โค้ดไม่สามารถพกพาไปยังแพลตฟอร์มอื่นได้ \n

ควรหลีกเลี่ยง การใช้ฟังก์ชันfgets ()จากไลบรารีมาตรฐานของภาษา Cในโหมดไบนารี เนื่องจากไฟล์ใดๆ ที่ไม่ได้เขียนด้วยรูปแบบการขึ้นบรรทัดใหม่ของ Unix จะถูกอ่านผิด นอกจากนี้ ในโหมดข้อความ ไฟล์ใดๆ ที่ไม่ได้เขียนด้วยลำดับการขึ้นบรรทัดใหม่ดั้งเดิมของระบบ (เช่น ไฟล์ที่สร้างบนระบบ Unix แล้วคัดลอกไปยังระบบ Windows) ก็จะถูกอ่านผิดเช่นกัน

อีกปัญหาหนึ่งที่พบบ่อยคือการใช้งาน\nเมื่อสื่อสารโดยใช้โปรโตคอลอินเทอร์เน็ตซึ่งกำหนดให้ใช้ ASCII CR + LFสำหรับการจบบรรทัด การเขียนลงในสตรีมโหมดข้อความทำงานได้อย่างถูกต้องบนระบบ Windows แต่จะสร้างเพียงLFบน Unix และสิ่งที่แตกต่างออกไปอย่างสิ้นเชิงบนระบบที่แปลกใหม่กว่า การใช้งานในโหมดไบนารีดีขึ้นเล็กน้อย \n\r\n

ภาษาหลายภาษา เช่นC++ , Perl , ^{[ 19 ]}และHaskellให้การตีความแบบเดียวกัน\nกับ C C++ มีโมเดลอินพุต/เอาต์พุต (I/O) ทางเลือกโดยสามารถใช้ตัวจัดการstd::endlเพื่อส่งออกบรรทัดใหม่ (และล้างบัฟเฟอร์สตรีม)

Java , PHP , ^{[ 20 ]}และPython ^{[ 21 ]}จัดเตรียม\r\nลำดับ (สำหรับ ASCII CR + LF ) ซึ่งแตกต่างจาก C โดยรับประกันว่าจะแสดงค่าU+000DและU+000Aตามลำดับ

เมธอด การรับ/ส่งข้อมูล (I/O) ของJava Class Library ไม่ได้แปลงลำดับการขึ้นบรรทัดใหม่ที่ขึ้นอยู่กับแพลตฟอร์มโดยอัตโนมัติ แต่จะมีฟังก์ชันสำหรับเขียนบรรทัดเต็มซึ่งจะเพิ่มลำดับการขึ้นบรรทัดใหม่ดั้งเดิมโดยอัตโนมัติ และฟังก์ชันสำหรับอ่านบรรทัดที่ยอมรับCR , LFหรือCR + LFเป็นตัวจบบรรทัด (ดูBufferedReader.readLine() ) สามารถใช้เมธอดSystem.lineSeparator() เพื่อดึงตัวคั่นบรรทัดพื้นฐานได้ ซึ่งจะถูกแทรกโดยอัตโนมัติเมื่อใช้ตัวระบุรูปแบบ ใน. %nSystem.out::printf

ตัวอย่าง:

สตริงeol = System.lineSeparator ( ); สตริงlineColor = "Color: Red " + eol ;

Python มีคุณสมบัติ "การสนับสนุนบรรทัดใหม่สากล" ที่เปิดใช้งานโดยค่าเริ่มต้น ซึ่งจะแปลงรูปแบบการขึ้นบรรทัดใหม่ที่พบได้ทั่วไปทั้งสามแบบ ( \n, \r, \r\n) ให้เป็นรูปแบบมาตรฐานของ Python \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บรรทัดใหม่

ในทางกลับกัน เมื่อดูไฟล์ที่มาจากคอมพิวเตอร์ Windows บนระบบที่คล้าย Unix อักขระCR ที่เกินมา อาจแสดงเป็นตัวแบ่งบรรทัดที่สอง เช่น^Mหรือ<cr>ที่ท้ายแต่ละบรรทัด

นอกจากนี้ โปรแกรมอื่นๆ นอกเหนือจากโปรแกรมแก้ไขข้อความ อาจไม่ยอมรับไฟล์บางไฟล์ เช่น ไฟล์การตั้งค่า ที่เข้ารหัสโดยใช้รูปแบบการขึ้นบรรทัดใหม่แบบต่างประเทศ ว่าเป็นไฟล์ที่ถูกต้อง

ปัญหานี้อาจสังเกตได้ยาก เนื่องจากบางโปรแกรมจัดการกับอักขระขึ้นบรรทัดใหม่จากรูปแบบอื่นได้อย่างถูกต้อง ในขณะที่บางโปรแกรมทำไม่ได้ ตัวอย่างเช่นคอมไพเลอร์อาจแสดงข้อผิดพลาดทางไวยากรณ์ที่ไม่ชัดเจน แม้ว่าไฟล์ต้นฉบับจะดูถูกต้องเมื่อแสดงบนคอนโซลหรือในโปรแกรมแก้ไขข้อความก็ตาม โปรแกรมแก้ไขข้อความสมัยใหม่โดยทั่วไปจะรู้จัก อักขระขึ้นบรรทัดใหม่แบบ CR + LF ทุกรูปแบบ และอนุญาตให้ผู้ใช้แปลงระหว่างมาตรฐานต่างๆ ได้เว็บเบราว์เซอร์ส่วนใหญ่ก็สามารถแสดงไฟล์ข้อความและเว็บไซต์ที่ใช้อักขระขึ้นบรรทัดใหม่ประเภทต่างๆ ได้เช่นกัน

แม้ว่าโปรแกรมจะรองรับรูปแบบการขึ้นบรรทัดใหม่ที่แตกต่างกัน แต่คุณสมบัติเหล่านี้มักไม่ได้รับการระบุ อธิบาย หรือจัดทำเอกสารอย่างเพียงพอ โดยทั่วไปแล้ว เมนูหรือกล่องคอมโบที่แสดงรายการรูปแบบการขึ้นบรรทัดใหม่ต่างๆ จะปรากฏให้ผู้ใช้เห็นโดยไม่มีการระบุว่าการเลือกนั้นจะตีความใหม่ แปลงชั่วคราว หรือแปลงถาวรหรือไม่ โปรแกรมบางโปรแกรมจะแปลงโดยอัตโนมัติเมื่อเปิด คัดลอก วาง หรือบันทึก ซึ่งมักจะไม่สม่ำเสมอ

โปรโตคอลอินเทอร์เน็ต แบบข้อความส่วนใหญ่(รวมถึงHTTP , SMTP , FTP , IRCและอื่นๆ อีกมากมาย) กำหนดให้ใช้ ASCII CR + LF ( , 0x0D 0x0A ) ในระดับโปรโตคอล แต่แนะนำให้แอปพลิเคชันที่ยอมรับได้รู้จักLF เดี่ยวๆ ( , 0x0A ) ด้วยเช่นกัน แม้จะมีมาตรฐานที่กำหนดไว้ แอปพลิเคชันจำนวนมากใช้ลำดับการหลีกเลี่ยงขึ้นบรรทัดใหม่ของภาษา C ( LF ) อย่างผิดพลาด แทนที่จะใช้การรวมกันที่ถูกต้องของลำดับการหลีกเลี่ยงการขึ้นบรรทัดใหม่และลำดับการหลีกเลี่ยงขึ้นบรรทัดใหม่( CR + LF ) (ดูส่วน " ขึ้นบรรทัดใหม่ในภาษาโปรแกรม"ด้านบน) การใช้ลำดับการหลีกเลี่ยงที่ไม่ถูกต้องโดยไม่ได้ตั้งใจนี้ทำให้เกิดปัญหาเมื่อพยายามสื่อสารกับระบบที่ยึดถือการตีความมาตรฐานที่เข้มงวดกว่า แทนที่จะเป็นการตีความที่ยอมรับได้ตามที่แนะนำ ระบบที่ไม่ยอมรับมาตรฐานดังกล่าวระบบหนึ่งคือเอเจนต์การถ่ายโอนอีเมลqmail ที่ปฏิเสธที่จะรับ ^{ข้อความ}จากระบบที่ส่งLF เปล่าๆ แทนที่จะเป็นCR + LF ที่จำเป็น ^{[ 25} ]\r\n\n\n\r\n

รูปแบบข้อความอินเทอร์เน็ตมาตรฐาน^{[ 26 ]}สำหรับอีเมลระบุว่า: "CR และ LF ต้องปรากฏร่วมกันในรูปแบบ CRLF เท่านั้น จะต้องไม่ปรากฏแยกกันในเนื้อหา" ความแตกต่างระหว่างการใช้งาน SMTP ในวิธีการจัดการอักขระ LF และ/หรือ CR ที่ไม่มีตัวอักษร ทำให้เกิดการโจมตีแบบปลอมแปลง SMTP ที่เรียกว่า "SMTP smuggling" ^{[ 27 ]}

โปรโตคอลการถ่ายโอนไฟล์สามารถแปลงบรรทัดใหม่ในไฟล์ที่ถ่ายโอนระหว่างระบบที่มีการแสดงบรรทัดใหม่ที่แตกต่างกันโดยอัตโนมัติเมื่อการถ่ายโอนทำใน "โหมด ASCII" อย่างไรก็ตาม การถ่ายโอนไฟล์ไบนารีในโหมดนี้มักจะส่งผลเสียร้ายแรง: การปรากฏของลำดับไบต์บรรทัดใหม่ใดๆ—ซึ่งไม่มีความหมายของตัวจบบรรทัดในบริบทนี้ แต่เป็นเพียงส่วนหนึ่งของลำดับไบต์ปกติ—จะถูกแปลเป็นรูปแบบบรรทัดใหม่ที่ระบบอื่นใช้ ซึ่งจะทำให้ไฟล์เสียหาย อย่างมีประสิทธิภาพ ไคลเอนต์ FTP มักใช้ หลักการคาดเดา บางอย่าง (เช่น การตรวจสอบนามสกุลไฟล์ ) เพื่อเลือกโหมดไบนารีหรือ ASCII โดยอัตโนมัติ แต่ในท้ายที่สุด ผู้ใช้ต้องตรวจสอบให้แน่ใจว่าไฟล์ของตนถูกถ่ายโอนในโหมดที่ถูกต้อง หากมีข้อสงสัยเกี่ยวกับโหมดที่ถูกต้อง ควรใช้โหมดไบนารี เนื่องจากจะไม่มีไฟล์ใดถูกเปลี่ยนแปลงโดย FTP แม้ว่าไฟล์อาจแสดงผลไม่ถูกต้องก็ตาม^{[ 28 ]}

โปรแกรมแก้ไขข้อความมักใช้สำหรับการแปลงไฟล์ข้อความระหว่างรูปแบบการขึ้นบรรทัดใหม่ที่แตกต่างกัน โปรแกรมแก้ไขข้อความสมัยใหม่ส่วนใหญ่สามารถอ่านและเขียนไฟล์โดยใช้รูปแบบ ASCII CR / LF ที่แตกต่างกันได้เป็นอย่างน้อย

ตัวอย่างเช่น โปรแกรมแก้ไขข้อความVimสามารถทำให้ไฟล์ใช้งานร่วมกับโปรแกรมแก้ไขข้อความ Notepad ของ Windows ได้ ภายใน Vim

 : ตั้งค่ารูปแบบไฟล์เป็น dos  : wq

โปรแกรมแก้ไขข้อความอาจไม่เหมาะสำหรับการแปลงไฟล์ขนาดใหญ่หรือการแปลงไฟล์จำนวนมากพร้อมกัน สำหรับไฟล์ขนาดใหญ่ (บน Windows NT) มักใช้คำสั่งต่อไปนี้:

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

โปรแกรมเฉพาะทางสำหรับการแปลงไฟล์ระหว่างรูปแบบการขึ้นบรรทัดใหม่ที่แตกต่างกัน ได้แก่unix2dosและdos2unix , mac2unixและunix2mac , mac2dosและdos2macและflip ^{[ 29 ]} คำ สั่ง trสามารถใช้งานได้ใน ระบบ ที่คล้าย Unix แทบทุกระบบ และสามารถใช้เพื่อดำเนินการแทนที่อักขระเดี่ยวตามอำเภอใจได้ ไฟล์ข้อความ DOS/Windows สามารถแปลงเป็นรูปแบบ Unix ได้โดยการลบอักขระ ASCII CR ทั้งหมดออกด้วย

$ tr -d '\r' < inputfile > outputfile

หรือหากข้อความมีเฉพาะ ขึ้นบรรทัดใหม่แบบ CRให้แปลงขึ้น บรรทัดใหม่แบบ CR ทั้งหมด เป็นLFด้วย

$ tr '\r' '\n' < ไฟล์อินพุต > ไฟล์เอาต์พุต

บางครั้งงานเดียวกันนี้ก็สามารถทำได้ด้วยawk , sedหรือPerlหากแพลตฟอร์มนั้นมีตัวแปลภาษา Perl:

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile # แปลงจาก UNIX เป็น DOS (เพิ่ม CR บน Linux และระบบปฏิบัติการที่ใช้ BSD ที่ไม่มีส่วนขยาย GNU) $ awk '{gsub("\r",""); print;}' inputfile > outputfile # แปลงจาก DOS เป็น UNIX (ลบ CR บน Linux และ BSD OS ที่ไม่มีส่วนขยาย GNU) $ sed -e 's/$/\r/' inputfile > outputfile # แปลงจาก UNIX เป็น DOS (เพิ่ม CR บน Linux OS ที่ใช้ส่วนขยาย GNU) $ sed -e 's/\r$//' inputfile > outputfile # แปลงจาก DOS เป็น UNIX (ลบ CR บน Linux OS ที่ใช้ส่วนขยาย 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สามารถระบุประเภทของตัวจบบรรทัดได้:

$ file myfile.txt myfile.txt: ข้อความภาษาอังกฤษแบบ ASCII พร้อมตัวจบบรรทัด CRLF

คำสั่ง egrep (extended 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 

มี สองวิธีในการมองบรรทัดใหม่ ซึ่งทั้งสองวิธีมีความสอดคล้องกันในตัวเองคือ บรรทัดใหม่ทำหน้าที่แยกบรรทัดหรือสิ้นสุดบรรทัด หากบรรทัดใหม่ถูกพิจารณาว่าเป็นตัวคั่น จะไม่มีบรรทัดใหม่หลังจากบรรทัดสุดท้ายของไฟล์ โปรแกรมบางโปรแกรมมีปัญหาในการประมวลผลบรรทัดสุดท้ายของไฟล์หากไม่มีบรรทัดใหม่สิ้นสุด ในทางกลับกัน โปรแกรมที่คาดหวังว่าบรรทัดใหม่จะถูกใช้เป็นตัวคั่นจะตีความบรรทัดใหม่สุดท้ายว่าเป็นการเริ่มต้นบรรทัดใหม่ (ว่างเปล่า) ในทางกลับกัน หากบรรทัดใหม่ถูกพิจารณาว่าเป็นตัวสิ้นสุด บรรทัดข้อความทั้งหมดรวมถึงบรรทัดสุดท้ายจะต้องสิ้นสุดด้วยบรรทัดใหม่ หากลำดับอักขระสุดท้ายในไฟล์ข้อความไม่ใช่บรรทัดใหม่ บรรทัดสุดท้ายของไฟล์อาจถือว่าเป็นบรรทัดข้อความที่ไม่เหมาะสมหรือไม่สมบูรณ์ หรือไฟล์อาจถือว่าถูกตัดทอนอย่างไม่เหมาะสม มาตรฐาน POSIXใช้จุดยืนหลัง โดยพิจารณาว่าบรรทัดใหม่เป็นตัวสิ้นสุดบรรทัด^{[ 30 ]}

ในข้อความที่ออกแบบมาเพื่อให้มนุษย์อ่านโดยใช้ซอฟต์แวร์ที่มี ฟังก์ชัน ตัดคำอัตโนมัติ อักขระขึ้นบรรทัดใหม่มักจะต้องจัดเก็บไว้ก็ต่อเมื่อต้องการขึ้นบรรทัดใหม่โดยไม่คำนึงว่าคำถัดไปจะพอดีในบรรทัดเดียวกันหรือไม่ เช่น ระหว่างย่อหน้าและในรายการแนวตั้ง ดังนั้น ในตรรกะของการประมวลผลคำและโปรแกรมแก้ไขข้อความ ส่วนใหญ่ อักขระ ขึ้นบรรทัดใหม่จึงถูกใช้เป็นตัวแบ่งย่อหน้าและเรียกว่า "การขึ้นบรรทัดใหม่แบบแข็ง" (hard return) ซึ่งแตกต่างจาก "การขึ้นบรรทัดใหม่แบบอ่อน" (soft return) ที่สร้างขึ้นแบบไดนามิกเพื่อใช้ในการตัดคำอัตโนมัติและสามารถเปลี่ยนแปลงได้ในแต่ละครั้งที่แสดง ในหลายแอปพลิเคชันจะ มี อักขระควบคุม แยกต่างหาก ที่เรียกว่า "การขึ้นบรรทัดใหม่ด้วยตนเอง" (manual line break) สำหรับบังคับขึ้นบรรทัดใหม่ภายในย่อหน้าเดียวกัน สัญลักษณ์สำหรับอักขระควบคุมการขึ้นบรรทัดใหม่แบบแข็งมักจะเป็นเครื่องหมายพิลโครว์ (¶) และสำหรับการขึ้นบรรทัดใหม่ด้วยตนเองมักจะเป็นลูกศรขึ้นบรรทัดใหม่ (↵)

RI ( U +008D REVERSE LINE FEED, ^{[ 31 ]} ISO/IEC 6429 8D, เลขฐานสิบ 141) ใช้เพื่อเลื่อนตำแหน่งการพิมพ์กลับไปหนึ่งบรรทัด (โดยการป้อนกระดาษแบบย้อนกลับ หรือโดยการเลื่อนเคอร์เซอร์แสดงผลขึ้นหนึ่งบรรทัด) เพื่อให้สามารถพิมพ์อักขระอื่นทับข้อความที่มีอยู่ได้ ซึ่งอาจทำเพื่อทำให้ตัวอักษรหนาขึ้น หรือเพื่อเพิ่มเส้นใต้ ขีดฆ่า หรืออักขระอื่นๆ เช่นเครื่องหมายกำกับเสียงการป้อนบรรทัดแบบย้อนกลับนี้เรียกว่าline starve  ซึ่งเป็นการเล่นคำกับline feed  ใน พจนานุกรม ของแฮกเกอร์^{[ 32 ]}

ในทำนองเดียวกันPLD ( U +008B PARTIAL LINE FORWARD, เลขฐานสิบ 139) และPLU ( U +008C PARTIAL LINE BACKWARD, เลขฐานสิบ 140) สามารถใช้เพื่อเลื่อนตำแหน่งการพิมพ์ข้อความไปข้างหน้าหรือถอยหลังตามสัดส่วนของระยะห่างระหว่างบรรทัดในแนวตั้ง (โดยทั่วไปคือครึ่งหนึ่ง) สามารถใช้ร่วมกันได้สำหรับตัวห้อย (โดยการเลื่อนไปข้างหน้าแล้วถอยหลัง) และตัวยก (โดยการถอยหลังแล้วเลื่อนไปข้างหน้า) และอาจมีประโยชน์สำหรับการพิมพ์เครื่องหมายกำกับเสียงด้วย

• คีย์สุดท้าย
• สิ้นสุดไฟล์
• กดปุ่ม Enter
• ขึ้นหน้าใหม่

• เอกสารอ้างอิง Unicode; ดูย่อหน้า 5.8 ในบทที่ 5ของมาตรฐาน Unicode 4.0 (PDF)
• "อักขระขึ้นบรรทัดใหม่ [NEL] "
• ปริศนาท้ายแถว
• ทำความเข้าใจเกี่ยวกับการขึ้นบรรทัดใหม่ (Newlines)ที่Wayback Machine (เก็บถาวรเมื่อวันที่ 20 สิงหาคม 2549)
• "เรื่องราวตอนจบ"