Pojmy návrat vozíku (CR) a posun řádku (LF) jsou úzce spojeny a lze je zvažovat samostatně nebo společně. Ve fyzických médiích psacích strojů a tiskáren jsou k vytvoření nového řádku na stránce zapotřebí dvě osy pohybu, „dolů“ a „napříč“. Ačkoli je konstrukce stroje (psací stroj nebo tiskárna) musí brát v úvahu samostatně, abstraktní logika softwaru je může kombinovat dohromady jako jednu událost. Z tohoto důvodu lze nový řádek v kódování znaků definovat jako CR a LF sloučené do jednoho (běžně se nazývá CR + LF nebo CRLF ).

Některé znakové sady poskytují samostatný nový znakový kód. EBCDIC například poskytuje kromě kódů CR a LF také znakový kód NL. Unicode kromě poskytnutí kontrolních kódů ASCII CR a LF poskytuje také kontrolní kód „dalšího řádku“ (NEL) a také kontrolní kódy pro značky „oddělovač řádků“ a „oddělovač odstavců“.

• Systémy EBCDIC – hlavně systémy sálových počítačů IBM, včetně z / OS (OS / 390) a i5 / OS (OS / 400) – používají NL (New Line, 0x15) jako znak kombinující funkce podávání a přepravy řádků vrátit se. Ekvivalentní znak Unicode ( 0x85 ) se nazývá NEL (další řádek). EBCDIC má také řídicí znaky zvané CR a LF, ale číselná hodnota LF (0x25) se liší od hodnoty používané ASCII (0x0A). Některé varianty EBCDIC navíc používají také NL, ale znaku přiřazují jiný číselný kód. Tyto operační systémy však používají souborový systém založený na záznamech, který ukládá textové soubory jako jeden záznam na řádek. Ve většině formátů souborů nejsou ve skutečnosti uloženi žádní zakončení řádků.
• Operační systémy řady CDC 6000 definovaly nový řádek jako dva nebo více šestibitových znaků s nulovou hodnotou na konci 60bitového slova. Některé konfigurace také definovaly znak s nulovou hodnotou jako znak dvojtečky, což vedlo k tomu, že více dvojteček lze interpretovat jako nový řádek v závislosti na poloze.
• RSX-11 a OpenVMS také používají systém souborů založený na záznamech , který ukládá textové soubory jako jeden záznam na řádek. Ve většině formátů souborů nejsou ve skutečnosti uloženi žádní zakončení řádků, ale služba Record Management Services může transparentně přidat zakončení na každý řádek, když je načtena aplikací. Samotné záznamy mohou obsahovat stejné ukončovací znaky řádků, které lze v závislosti na aplikaci považovat za funkci nebo obtěžování. RMS nejen uložené záznamy, ale také uložená metadata o oddělovačích záznamů v různých bitech, aby soubor ještě více zkomplikoval záležitosti (protože soubory mohly mít záznamy s pevnou délkou, záznamy s předponou počtem nebo záznamy, které byly ukončeny konkrétním znakem ). Bity nebyly obecné, takže i když mohly specifikovat, že terminátorem řádku je CRLF, LF nebo dokonce CR, nemohl nahradit nějaký jiný kód.
• Pevná délka řádku byla používána některými časnými operacemi sálového počítače systémy. V takovém systému se předpokládal implicitní konec řádku například každých 72 nebo 80 znaků. Nebyl uložen žádný znak nového řádku. Pokud byl soubor importován z vnějšího světa, musely být řádky kratší než délka čáry vyplněny mezerami, zatímco řádky delší než délka čáry musely být zkráceny. To napodobovalo použití děrných štítků, na nichž byl každý řádek uložen na samostatnou kartu, obvykle s 80 sloupci na každé kartě, často s pořadovými čísly ve sloupcích 73–80. Mnoho z těchto systémů přidalo na začátek dalšího záznamu znak řízení vozíku; to by mohlo naznačovat, zda byl další záznam pokračováním řádku zahájeného předchozím záznamem, nebo novým řádkem, nebo by měl přetisknout předchozí řádek (podobně jako u CR). Často se jednalo o běžný tiskový znak, například # , který tedy nemohl být použit jako první znak v řádku. Některé tiskárny na začátku řádku interpretovaly tyto znaky přímo v záznamech, které jim byly zaslány.

UnicodeEdit

Standard Unicode definuje počet znaků, které by vyhovující aplikace měly rozpoznat jako zakončení řádků:

LF: Line Feed, U + 000A VT: Vertikální karta, U + 000B FF: Podávání formuláře, U + 000C CR: Návrat vozíku, U + 000D CR + LF: CR (U + 000D) následovaný LF (U + 000A) NEL: Další řádek, U + 0085 LS: Oddělovač řádků, U + 2028 PS: Oddělovač odstavců, U + 2029

To se může zdát příliš komplikované ve srovnání s přístupem, jako je převod všech zakončení řádků na jeden znak, například LF. Unicode však byl navržen tak, aby zachoval všechny informace při převodu textového souboru z jakéhokoli stávajícího kódování na Unicode a zpět. Unicode by proto měl obsahovat znaky obsažené ve stávajících kódováních.NL je součástí EBCDIC s kódem 0x15 a často je mapováno na NEL, což je řídicí znak v řídicí sadě C1. Jako takový je definován ECMA 48 a rozpoznán kódováním v souladu s ISO / IEC 2022 (což je ekvivalent ECMA 35). Řídicí sada C1 je také kompatibilní s ISO-8859-1. Přístup přijatý ve standardu Unicode umožňuje obousměrnou transformaci zachovat informace a zároveň aplikacím umožňuje rozpoznat všechny možné typy zakončení řádků.

Rozpoznávání a používání kódů nového řádku větších než 0x7F (NEL, LS a PS) se často nedělá. Jedná se o více bajtů v UTF-8 a kód pro NEL byl použit jako znak elipsy (… ) ve Windows-1252. Například:

• ECMAScript přijímá LS a PS jako zalomení řádků, ale místo zalomení řádků považuje mezery U + 0085 (NEL).
• Windows 10 ve svém výchozím textovém editoru, v Poznámkovém bloku, nezachází s žádným z NEL, LS nebo PS jako zalomením řádků.
• gedit, výchozí textový editor desktopového prostředí GNOME , považuje LS a PS za nové řádky, ale ne za NEL.
• JSON povoluje znaky LS a PS v řetězcích, zatímco ECMAScript před ES2019 s nimi zacházel jako s novými řádky, a tedy s nelegální syntaxí.
• YAML je již od verze 1.2 nerozpoznává jako speciální, aby byly kompatibilní s JSON.

Znaky Unicode U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (RETURN SYMBOL, ⏎ ), U + 240D (SYMBOL FOR CARRIAGE RETURN, ␍ ) a U + 240A (SYMBOL FOR LINE FEED, ␊ ) jsou určené k prezentaci znaku, který je viditelný pro uživatele čtenáři dokumentu, a nejsou tedy rozpoznáni jako nový řádek.

Escape sekvence Upravit

Escape sekvence je kombinace znaků, které nepředstavuje žádný text; místo toho, aby byl zobrazen (jako text), má být zachycen programem a má být provedena speciální funkce. Escape sekvence se také používají ke zpracování (nastavování, hledání, nahrazování atd.) Speciálních znaků.

V programovacích jazycíchEdit

Pro usnadnění vytváření přenosných programů poskytují programovací jazyky některé abstrakce, které se zabývají různými typy sekvencí nového řádku používaných v různých prostředích.

Programovací jazyk C poskytuje řídicí sekvence „\ n“ (nový řádek) a „\ r“ (návrat na začátek řádku). Není však nutné, aby odpovídaly řídicím znakům ASCII LF a CR. Standard C zaručuje pouze dvě věci:

1. Každá z těchto únikových sekvencí se mapuje na jedinečné číslo definované implementací, které lze uložit do jedné char hodnoty.
2. Při psaní do souboru, uzlu zařízení nebo socket / fifo v textovém režimu je „\ n“ transparentně přeloženo do nativní nové řádkové sekvence používané systémem, která může být delší než jeden znak. Při čtení v textovém režimu je nativní sekvence nového řádku přeložena zpět na „\ n“. V binárním režimu se neprovádí žádný překlad a interní reprezentace vytvořená znakem „\ n“ se vydává přímo.

Na platformách Unix, kde C vznikl, je nativní sekvence nového řádku ASCII LF ( 0x0A), takže „\ n“ bylo jednoduše definováno jako tato hodnota. S interní a externí reprezentací jsou identické, překlad prováděný v textovém režimu je no-op a Unix nemá žádnou představu o textovém režimu nebo binárním režimu. To způsobilo, že mnoho programátorů, kteří vyvinuli svůj software na unixových systémech, toto rozlišení úplně ignorovalo, což vedlo k kódu, který není přenosný na různé platformy.

Funkci knihovny C fgets () je nejlepší vyhnout se v binárním režimu protože jakýkoli soubor, který není zapsán pomocí konvence nového řádku Unix, bude chybně přečten. V textovém režimu bude také chybně čten jakýkoli soubor, který nebyl zapsán s nativní sekvencí nového řádku systému (například soubor vytvořený v systému Unix a poté zkopírovaný do systému Windows).

Další běžným problémem je použití „\ n“ při komunikaci pomocí internetového protokolu, který nařizuje použití ASCII CR + LF pro zakončení řádků. Zápis „\ n“ do proudu textového režimu funguje v systémech Windows správně, ale produkuje pouze LF na Unix a něco úplně jiného na exotičtějších systémech. Použití „\ r \ n“ v binárním režimu je o něco lepší.

Knihovny Java I / O je neprovádějí transparentně do sekvencí nového řádku závislých na platformě místo toho poskytují funkce pro zápis celého řádku, které automaticky přidávají nativní sekvenci nového řádku, a funkce pro čtení řádků, které přijímají některý z CR, LF nebo CR + LF jako zakončení řádku (viz BufferedReader.readLine () Metodu System.lineSeparator () lze použít k načtení podkladového oddělovače řádků.

Příklad:

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

Python při otevírání souboru ke čtení povoluje „Universal Newline Support“, když import modulů a při provádění souboru.

Některé jazyky vytvořily speciální proměnné, konstanty a podprogramy, které usnadňují nové řádky během provádění programu. V některých jazycích, jako je PHP a Perl, jsou k provedení substituce úniku pro všechny únikové sekvence, včetně znaků „\ n“ a „\ r“, vyžadovány uvozovky. Aby se předešlo problémům s přenositelností, měly by se v PHP sekvence nového řádku vydávat pomocí konstanty PHP_EOL.

Příklad v C #:

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

Problémy s různými formáty nové řádkyEdit

Přestože jsou kontrolní znaky jednoznačně definovány v odpovídající tabulce kódování znaků používané textovým souborem , stále existuje problém: existují různé konvence pro nastavení a zobrazení zalomení řádku.

Pro označení jednoho zalomení řádku používají unixové programy posun řádku , jehož hexadecimální hodnota v ASCII je 0a , zatímco většina programů společných pro MS-DOS a Microsoft Windows používá carriage return + line feed , jehož hexadecimální hodnota v ASCII je 0d 0a kód>. V ASCII je návrat vozíku odlišným ovládacím znakem.

Různé konvence nového řádku způsobují nesprávné zobrazení textových souborů, které byly přeneseny mezi systémy různých typů.

Text ve vytvořených souborech u programů, které jsou běžné v Unixu nebo v klasickém Mac OS, se u většiny programů společných pro MS-DOS a Microsoft Windows zobrazují jako jedna dlouhá řada, protože nezobrazují jediný posuv řádku nebo jeden návrat vozíku jako zalomení řádku.

Naopak při prohlížení souboru pocházejícího z počítače se systémem Windows v systému podobném Unixu může být zvláštní CR zobrazen jako zalomení druhého řádku, jako ^ M nebo jako < cr > na konci každého řádku.

Kromě toho programy jiné než textové editory nemusí přijmout soubor, např nějaký konfigurační soubor, kódovaný pomocí cizí konvence nové řádky, jako platný soubor.

Problém může být těžké odhalit, protože některé programy zpracovávají cizí nové řádky správně, zatímco jiné ne. Například kompilátor může selhat s temnými syntaktickými chybami, přestože zdrojový soubor vypadá správně, když je zobrazen na konzole nebo v editoru. V systému podobném Unixu příkaz cat -v myfile.txt odešle soubor na stdout (obvykle terminál) a zviditelní ^ M, což může být užitečné pro ladění. Moderní textové editory obecně rozpoznávají všechny příchutě nových řádků CR + LF a umožňují uživatelům převádět mezi různými standardy. Webové prohlížeče jsou také obvykle schopné zobrazit textové soubory a webové stránky, které používají různé typy nových řádků.

I když program podporuje různé konvence nového řádku, tyto funkce často nejsou dostatečně označeny, popsány nebo zdokumentovány. Uživatelům se obvykle zobrazí nabídka nebo rozbalovací seznam s výčtem různých konvence nového řádku bez označení, zda bude výběr znovu interpretovat, dočasně převést nebo trvale převést nové řádky. Některé programy budou implicitně převádět při otevírání, kopírování, vkládání nebo ukládání – často nekonzistentně.

Většina textových internetových protokolů (včetně HTTP, SMTP, FTP, IRC a mnoha dalších) vyžaduje použití ASCII CR + LF („\ r \ n“, 0x0D 0x0A) na úrovni protokolu, ale doporučujeme, aby tolerantní aplikace také rozpoznaly osamělý LF („\ n“, 0x0A). Navzdory diktovanému standardu používá mnoho aplikací chybně místo nové kombinace únikové sekvence „\ n“ (LF) C místo správné kombinace únikové sekvence konce řádku a únikové sekvence „\ r \ n“ (CR + LF) (viz část Nový řádek v programovací jazyky výše). Toto náhodné použití nesprávných únikových sekvencí vede k problémům při pokusech o komunikaci se systémy dodržujícími přísnější interpretaci standardů namísto doporučeného tolerantního výkladu. Jedním z takových netolerantních systémů je agent pro přenos pošty qmail, který aktivně odmítá přijímat zprávy ze systémů, které odesílají holé LF místo požadovaných CR + LF.

Standardní formát zpráv Internetu pro e-mail: CR a LF MUSÍ vyskytují se pouze společně jako CRLF; NEMUSÍ se v těle zobrazovat samostatně.

Protokol pro přenos souborů může automaticky převádět nové řádky v souborech přenášených mezi systémy s různými reprezentacemi nového řádku, když se přenos provádí v „režimu ASCII“.Přenos binárních souborů v tomto režimu však obvykle má katastrofální výsledky: jakýkoli výskyt sekvence bajtů nového řádku – který v tomto kontextu nemá sémantiku zakončení řádku, ale je pouze součástí normální sekvence bajtů – bude přeložen do jakékoli reprezentace nového řádku jiný systém používá, což účinně poškozuje soubor. Klienti FTP často používají nějakou heuristiku (například kontrolu přípon souborů), aby automaticky vybrali buď binární nebo ASCII režim, ale nakonec je na uživatelích, aby se ujistili, že jsou jejich soubory přeneseny ve správném režimu. Pokud existují pochybnosti o správném režimu, měl by se použít binární režim, protože FTP nebude měnit žádné soubory, i když se mohou zobrazovat nesprávně.

Konverze mezi formáty nového řádkuEdit

Textové editory se často používají pro převod textového souboru mezi různými formáty nového řádku; většina moderních editorů může číst a zapisovat soubory pomocí alespoň různých konvencí ASCII CR / LF. Například editor Vim může vytvořit soubor kompatibilní s textovým editorem Windows Notepad. V rámci vim

 :set fileformat=dos :wq

Redaktoři nemusí být vhodní pro převod větších souborů nebo hromadný převod mnoha souborů. U větších souborů (ve Windows NT / 2000 / XP) se často používá následující příkaz:

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

Speciální programy pro převod soubory mezi různými konvencemi nového řádku zahrnují unix2dos a dos2unix, mac2unix a unix2mac, mac2dos a dos2mac a flip. Příkaz tr je k dispozici prakticky v každém systému podobném systému Unix a lze jej použít k provádění libovolných operací nahrazení jednotlivých znaků. Textový soubor DOS / Windows lze převést do formátu Unix jednoduše odstraněním všech znaků ASCII CR pomocí

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

nebo, pokud má text pouze nové řádky CR, pomocí převod všech nových řádků CR na LF pomocí

$ tr "\r" "\n" < inputfile > outputfile

Stejné úkoly se někdy provádějí pomocí awk, sed nebo v Perlu, pokud má platforma tlumočníka Perl:

Příkaz file může identifikovat typ zakončení řádků:

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

Příkaz Unix egrep (rozšířený grep) lze použít k tisku názvů souborů Unixu nebo DOSu (za předpokladu, že jsou to pouze soubory ve stylu Unixu a DOSu, žádný Mac OS):

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

Další nástroje umožňují uživateli vizualizovat znaky EOL:

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