Kuljetuksen palautus (CR) ja rivinvaihto (LF) liittyvät läheisesti toisiinsa, ja niitä voidaan tarkastella joko erikseen tai yhdessä. Kirjoituskoneiden ja tulostimien fyysisessä mediassa tarvitaan kaksi liikkumisakselia ”alas” ja ”poikki” uuden rivin luomiseksi sivulle. Vaikka koneen (kirjoituskoneen tai tulostimen) suunnittelussa on tarkasteltava niitä erikseen, ohjelmiston abstrakti logiikka voi yhdistää ne yhdeksi tapahtumaksi. Siksi uusi rivi merkkien koodauksessa voidaan määritellä CR ja LF yhdeksi yhdeksi (kutsutaan yleisesti nimellä CR + LF tai CRLF ).

Jotkut merkistö antaa erillisen uuden rivin merkkikoodin. Esimerkiksi EBCDIC tarjoaa NL-merkkikoodin CR- ja LF-koodien lisäksi. Unicode tarjoaa ASCII CR- ja LF-ohjauskoodien lisäksi myös ”seuraavan rivin” (NEL) ohjauskoodin sekä ohjauskoodit ”rivierotin” ja ”kappaleenerotin” -merkkeille.

• EBCDIC-järjestelmät – pääasiassa IBM: n keskusyksikköjärjestelmät, mukaan lukien z / OS (OS / 390) ja i5 / OS (OS / 400) – käytä NL (New Line, 0x15) -merkkiä, joka yhdistää rivinsiirron ja kuljetuksen toiminnot palata. Vastaavaa Unicode-merkkiä ( 0x85 ) kutsutaan nimellä NEL (seuraava rivi). EBCDIC: ssä on myös ohjausmerkkejä nimeltään CR ja LF, mutta LF: n numeerinen arvo (0x25) eroaa ASCII: n (0x0A) käyttämästä arvosta. Lisäksi jotkut EBCDIC-variantit käyttävät myös NL: ää, mutta osoittavat merkille eri numeerisen koodin. Nämä käyttöjärjestelmät käyttävät kuitenkin ennätyspohjaista tiedostojärjestelmää, joka tallentaa tekstitiedostot yhtenä tietueena riviä kohden. Suurimmassa osassa tiedostomuotoja yhtään rivinvaihtajaa ei tosiasiallisesti ole tallennettu.
• CDC 6000 -sarjan käyttöjärjestelmät määrittelivät uuden rivin kahdeksi tai useammaksi nolla-arvoiseksi kuusibittiseksi merkiksi 60-bittisen sanan lopussa. Joissakin kokoonpanoissa määritettiin myös nolla-arvoinen merkki kaksoispiste-merkiksi, minkä seurauksena useita kaksoispisteitä voidaan tulkita uudeksi riviksi sijainnista riippuen.
• RSX-11 ja OpenVMS käyttävät myös ennätyspohjaista tiedostojärjestelmää. , joka tallentaa tekstitiedostot yhtenä tietueena riviä kohden. Useimmissa tiedostomuodoissa rivinvaihtajia ei tosiasiallisesti ole tallennettu, mutta tietueiden hallintapalvelutoiminto voi lisätä läpinäkyvästi jokaiselle riville päätelaitteen, kun sovellus noutaa sen. Itse tietueet voivat sisältää samat rivinvaihtomerkit, joita voidaan joko pitää ominaisuutena tai haittana sovelluksesta riippuen. RMS ei vain tallentanut tietueita, vaan myös tallensi metatietoja tietueiden erottimista eri bitteinä, jotta tiedosto vaikeuttaisi asiaa entisestään (koska tiedostoilla voi olla kiinteät pituiset tietueet, tietueet, joihin on lisätty lukumäärä, tai tietueet, jotka on päättynyt tietyllä merkillä ). Bitit eivät olleet yleisiä, joten vaikka ne voisivat määritellä, että CRLF, LF tai jopa CR oli linjan päättäjä, se ei voinut korvata muuta koodia.
• Jotkut varhaiset keskusyksiköt käyttivät kiinteää linjan pituutta. järjestelmät. Tällaisessa järjestelmässä implisiittinen rivin loppu oletettiin esimerkiksi 72 tai 80 merkin välein. Uuden rivin merkkiä ei tallennettu. Jos tiedosto tuotiin ulkomaailmasta, rivin pituutta lyhyemmät viivat oli täytettävä välilyönteillä, kun taas viivan pituutta pitemmät viivat oli katkaistava. Tämä jäljitti rei’itettyjen korttien käyttöä, joihin kukin rivi tallennettiin erilliselle kortille, yleensä 80 saraketta kullakin kortilla, usein järjestysnumeroilla sarakkeissa 73–80. Monet näistä järjestelmistä lisäsivät vaununhallintamerkin seuraavan tietueen alkuun; tämä voi osoittaa, oliko seuraava tietue jatko edelliselle tietueelle aloitetulle riville vai uusi rivi vai pitäisikö se tulostaa edellinen rivi (samanlainen kuin CR). Usein tämä oli normaali tulostusmerkki, kuten # , jota ei näin ollen voitu käyttää rivin ensimmäisenä merkkinä. Jotkut varhaisen rivin tulostimet tulkitsivat nämä merkit suoraan heille lähetetyissä tietueissa.

UnicodeEdit

Unicode-standardi määrittelee useita merkkejä, jotka yhteensopivien sovellusten tulisi tunnistaa rivin päättäjinä:

LF: Rivinvaihto, U + 000A VT: Pystysuuntainen välilehti, U + 000B FF: Lomakkeen syöttö, U + 000C CR: Kuljetuksen paluu, U + 000D CR + LF: CR (U + 000D), jota seuraa LF (U + 000A) NEL: Seuraava rivi, U + 0085 LS: Rivierotin, U + 2028 PS: Kappaleen erotin, U + 2029

Tämä saattaa tuntua liian monimutkaiselta verrattuna lähestymistapaan, kuten muuntaa kaikki linjaterminaalit yhdeksi merkiksi, esimerkiksi LF. Unicode on kuitenkin suunniteltu säilyttämään kaikki tiedot muunnettaessa tekstitiedosto kaikista olemassa olevista koodauksista Unicodeiksi ja takaisin. Siksi Unicoden tulisi sisältää merkkejä, jotka sisältyvät olemassa oleviin koodauksiin.NL sisältyy EBCDIC-koodiin koodilla 0x15, ja se on usein yhdistetty NEL: ään, joka on C1-ohjausjoukon ohjausmerkki. Sellaisena se on määritelty ECMA 48: ssa ja tunnistettu ISO / IEC 2022 (joka vastaa ECMA 35) -standardien mukaisilla koodauksilla. C1-ohjausyksikkö on yhteensopiva myös ISO-8859-1 -standardin kanssa. Unicode-standardin mukainen lähestymistapa sallii edestakaisen muunnoksen säilyttää tiedot ja antaa sovellusten silti tunnistaa kaikki mahdolliset linjaterminaattorit.

Tunnistetaan ja käytetään yli 0x7F (NEL, LS) suurempia uuden rivin koodeja ja PS) ei usein tehdä. Ne ovat useita tavuja UTF-8: ssa, ja NEL-koodia on käytetty ellipsisymbolina (… ) Windows-1252: ssa. Esimerkiksi:

• ECMAScript hyväksyy LS: n ja PS: n rivinvaihdoksi, mutta pitää U + 0085 (NEL) -väliä rivinvaihdon sijaan.
• Windows 10 ei käsittele NEL: ää, LS: ää tai PS: tä rivinvaihtona sen oletustekstieditorissa, Muistiossa.
• gedit, GNOME-työpöytäympäristön oletustekstieditori. , käsittelee LS: ää ja PS: tä uutena rivinä, mutta ei NEL: nä.
• JSON sallii LS- ja PS-merkit merkkijonoissa, kun taas ECMAScript ennen ES2019: tä käsitteli niitä uudenaikoina ja siten laitonta syntaksia.
• YAML ei enää tunnista niitä erityisiksi versiosta 1.2 alkaen, jotta ne olisivat yhteensopivia JSON: n kanssa.

Unicode-merkit U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (PALAUTA SYMBOLI, ⏎ ), U + 240D (Symboli KULJETUSPALAUTE, ␍ ) ja U + 240A (LINJASYÖTTÖMERKKI, ␊ ) ovat tarkoitettu käyttäjälle näkyvän merkin esittämiseen asiakirjan lukijalle, joten niitä ei tunnisteta uudeksi riviksi.

Escape sequencesEdit

Pakosarja on yhdistelmä merkkejä, jotka ei kuvaa tekstiä; sen sijaan, että se näytetään (tekstinä), sen oletetaan olevan ohjelman sieppaama ja erityistoiminto on tarkoitus suorittaa. Escape-sekvenssejä käytetään myös erikoismerkkien käsittelemiseen (asettaminen, haku, korvaaminen jne.).

OhjelmointikielissäMuokkaa

Kannettavien ohjelmien luomisen helpottamiseksi ohjelmointikielet tarjoavat joitain abstrakteja käsittelemään erityyppisiä uusissa riveissä käytettäviä sekvenssejä, joita käytetään eri ympäristöissä.

C-ohjelmointikieli tarjoaa pakosarjat ”\ n” (uusi rivi) ja ”\ r” (vaunun paluu). Näiden ei kuitenkaan tarvitse vastata ASCII LF- ja CR-ohjausmerkkejä. C-standardi takaa vain kaksi asiaa:

1. Kukin näistä pakosarjoista yhdistyy yksilölliseen toteutuksen määrittelemään numeroon, joka voidaan tallentaa yhteen merkkiarvoon.
2. Kirjoitettaessa tiedostoon, laitesolmuun tai pistorasiaan / fifo tekstitilassa ”\ n” käännetään läpinäkyvästi järjestelmän käyttämään natiiviin uuteen riviin, joka voi olla pidempi kuin yksi merkki. Kun luetaan tekstitilassa, uusi rivi sekvenssi käännetään takaisin \ n ”. Binaaritilassa käännöstä ei suoriteta, ja ”\ n” tuottama sisäinen esitys tulostetaan suoraan.

Unix-alustoilla, joista C on alkanut, natiivi uusi rivisekvenssi on ASCII LF ( 0x0A), joten ”\ n” määriteltiin yksinkertaisesti kyseiseksi arvoksi. Sisäisen ja ulkoisen esityksen ollessa identtisiä, tekstimoodissa suoritettava käännös ei ole käytössä, ja Unixilla ei ole käsitystä tekstitilasta tai binaaritilasta. Tämä on saanut monet ohjelmoijat, jotka ovat kehittäneet ohjelmistonsa Unix-järjestelmissä, jättävät yksinkertaisesti huomiotta erotuksen, mikä johtaa koodiin, jota ei voi siirtää eri alustoille.

C-kirjastofunktioiden () on parasta välttää binaaritilassa koska kaikki tiedostot, joita ei ole kirjoitettu Unixin uuden rivin sopimuksella, luetaan väärin. Myös tekstitilassa kaikki tiedostot, joita ei ole kirjoitettu järjestelmän natiivilla uuden rivin jaksolla (kuten Unix-järjestelmään luotu ja sitten Windows-järjestelmään kopioitu tiedosto), luetaan myös väärin.

Toinen Yleinen ongelma on ”\ n”: n käyttö viestinnässä käyttäen Internet-protokollaa, joka edellyttää ASCII CR + LF: n käyttöä rivien lopettamiseen. ”\ n”: n kirjoittaminen tekstitilavirtaan toimii oikein Windows-järjestelmissä, mutta tuottaa vain LF: n Unix ja jotain aivan erilaista eksoottisemmissa järjestelmissä. ”\ R \ n”: n käyttö binaaritilassa on hieman parempi.

Java I / O -kirjastot eivät käännä näitä avoimesti alustasta riippuvaisiksi uusirivisarjoiksi Tulo tai lähtö: Sen sijaan ne tarjoavat toimintoja kokonaisen rivin kirjoittamiseen, joka lisää uuden natiivin uuden rivin sekvenssin, ja toimintoja rivien lukemiseen, jotka hyväksyvät minkä tahansa CR: stä, LF: stä tai CR + LF: stä rivin päättäjänä (katso BufferedReader.readLine () System.lineSeparator () -menetelmää voidaan käyttää taustalla olevan rivierottimen hakemiseen.

Esimerkki:

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

Python sallii ”Universal Newline -tukeen” avattaessa tiedostoa luettavaksi, kun moduuleja tuotaessa ja tiedostoa suoritettaessa.

Jotkut kielet ovat luoneet erityisiä muuttujia, vakioita ja aliohjelmia helpottaakseen uusia viivoja ohjelman suorituksen aikana. Joillakin kielillä, kuten PHP ja Perl, tarvitaan kaksoislainausmerkit, jotta kaikki pakosekvenssit, mukaan lukien ”\ n” ja ”\ r”, voidaan korvata. PHP: ssä siirrettävyysongelmien välttämiseksi uudet rivisekvenssit tulisi antaa käyttämällä PHP_EOL-vakiota.

Esimerkki C #:

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

Eri rivin muotoiset ongelmat Muokkaa

Vaikka ohjausmerkit on määritelty yksiselitteisesti vastaavassa tekstitiedoston käyttämässä merkkikoodaustaulukossa , on edelleen ongelma: rivinvaihto voidaan asettaa ja näyttää eri tavoin.

Yksittäisen rivinvaihdon merkitsemiseksi Unix-ohjelmat käyttävät rivinvaihtoa , jonka heksadesimaaliarvo ASCII: ssa on 0a , kun taas useimmat MS-DOS: lle ja Microsoft Windowsille yhteiset ohjelmat käyttävät rivinvaihto + rivinvaihto , jonka heksadesimaaliarvo ASCII: ssa on 0d 0a . ASCII: ssa rivinvaihto on erillinen ohjausmerkki.

Erilaiset uuden rivin käytäntöjen vuoksi erityyppisten järjestelmien välillä siirretyt tekstitiedostot näytetään väärin.

Luotuissa tiedostoissa oleva teksti Niiden ohjelmien kanssa, jotka ovat yleisiä Unix-tyyppisessä tai perinteisessä Mac OS: ssä, näkyvät yhtenä pitkänä rivinä useimmissa MS-DOS: lle ja Microsoft Windowsille yhteisissä ohjelmissa, koska ne eivät näytä yhtä rivinvaihto tai yksittäinen rivinvaihto rivinvaihtona.

Päinvastoin, kun tarkastellaan Windows-tietokoneesta peräisin olevaa tiedostoa Unix-tyyppisessä järjestelmässä ylimääräinen CR voidaan näyttää toisen rivinvaihdoksena muodossa ^ M tai nimellä < cr > jokaisen rivin lopussa.

Lisäksi muut ohjelmat kuin tekstieditorit eivät välttämättä hyväksy tiedostoa, esim jotkut määritystiedostot, jotka on koodattu käyttämällä ulkomaista uuden rivin käytäntöä, kelvollisena tiedostona.

Ongelmaa voi olla vaikea havaita, koska jotkut ohjelmat käsittelevät ulkomaisia uusia viivoja oikein, kun taas toiset eivät. Esimerkiksi kääntäjä saattaa epäonnistua epäselvillä syntaksivirheillä, vaikka lähdetiedosto näyttää oikealta, kun se näkyy konsolissa tai muokkausohjelmassa. Unix-tyyppisessä järjestelmässä komento cat -v myfile.txt lähettää tiedoston stdoutiin (yleensä päätelaitteeseen) ja tekee ^ M näkyväksi, mikä voi olla hyödyllistä virheenkorjauksessa. Nykyaikaiset tekstieditorit tunnistavat yleensä kaikki CR + LF-uusien rivien maut ja antavat käyttäjien vaihtaa eri standardien välillä. Verkkoselaimet pystyvät yleensä myös näyttämään tekstitiedostoja ja verkkosivustoja, jotka käyttävät erityyppisiä uusia viivoja.

Vaikka ohjelma tukee erilaisia uuden rivin käytäntöjä, näitä ominaisuuksia ei usein ole riittävästi merkitty, kuvattu tai dokumentoitu. Tyypillisesti valikko tai yhdistelmäruutu, jossa luetellaan erilaiset uuden rivin käytäntöjä, näytetään käyttäjille ilman ilmoitusta, jos valinta tulkitsee, muuntaa väliaikaisesti tai muuntaa pysyvästi uudet viivat. Jotkut ohjelmat muuntavat implisiittisesti avoimiksi, kopioivat, liittävät tai tallentavat – usein epäjohdonmukaisesti.

Useimmat Internetin tekstiprotokollat (mukaan lukien HTTP, SMTP, FTP, IRC ja monet muut) edellyttävät ASCII CR +: n käyttöä. LF (”\ r \ n”, 0x0D 0x0A) protokollatasolla, mutta suosittele, että suvaitsevat sovellukset tunnistavat myös yksinäisen LF: n (”\ n”, 0x0A). Sanellusta standardista huolimatta, monet sovellukset käyttävät virheellisesti C: n uuden rivin pakosekvenssiä ”\ n” (LF) oikean yhdistelmän sijasta vaunun paluumatka ja uuden rivin pakosekvenssit ”\ r \ n” (CR + LF) (katso osio Uusi rivi ohjelmointikielet). Tämä virheellisten pakosekvenssien vahingossa tapahtuva käyttö johtaa ongelmiin, kun yritetään kommunikoida järjestelmien kanssa, jotka noudattavat standardien tiukempaa tulkintaa ehdotetun suvaitsevan tulkinnan sijaan. Yksi tällainen suvaitsematon järjestelmä on qmail-postinsiirtoagentti, joka kieltäytyy aktiivisesti vastaanottamasta viestejä järjestelmiltä, jotka lähettävät paljaita LF-tiedostoja vaaditun CR + LF-tiedoston sijaan.

Sähköpostin vakiotyyppinen Internet-viestimuoto: CR ja LF PITÄÄ esiintyvät vain yhdessä CRLF: nä; Niitä EI SAA esiintyä rungossa itsenäisesti.

Tiedostonsiirtoprotokolla voi muuntaa automaattisesti uuden rivin tiedostoissa, jotka siirretään järjestelmien välillä, joissa on erilainen uuden rivin esitys, kun siirto tapahtuu ”ASCII-tilassa”.Binaaritiedostojen siirtämisellä tässä tilassa on kuitenkin yleensä tuhoisia tuloksia: mikä tahansa uuden rivin tavusekvenssin esiintyminen – jolla ei ole rivin terminaattoreiden semantiikkaa tässä yhteydessä, mutta joka on vain osa normaalia tavujärjestystä – käännetään mihin tahansa uuden rivin esitykseen toinen järjestelmä käyttää, mikä vioittaa tiedostoa tehokkaasti. FTP-asiakkaat käyttävät usein joitain heuristiikkaa (esimerkiksi tiedostopäätteiden tarkistus) valitaksesi joko binäärisen tai ASCII-tilan automaattisesti, mutta loppujen lopuksi käyttäjien on varmistettava, että tiedostot siirretään oikeassa tilassa. Jos oikeassa tilassa on epäilyksiä, on käytettävä binaaritilaa, koska silloin FTP ei muuta tiedostoja, vaikka ne saattavat näkyä väärin.

Muunnos uuden rivin formaattien välilläMuokkaa

Tekstieditoreja käytetään usein tekstitiedoston muuntamiseen eri rivirivimuotojen välillä Useimmat nykyaikaiset toimittajat voivat lukea ja kirjoittaa tiedostoja vähintään käyttämällä erilaisia ASCII CR / LF -käytäntöjä. esimerkiksi editori Vim voi tehdä tiedostosta yhteensopivan Windowsin Muistio-tekstieditorin kanssa. Vim-sovelluksessa

 :set fileformat=dos :wq

Muokkaimet eivät välttämättä sovi suurempien tiedostojen muuntamiseen tai useiden tiedostojen joukkomuuntajaksi. Suuremmille tiedostoille (Windows NT / 2000 / XP) käytetään usein seuraavaa komentoa:

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

Erikoiskäyttöiset ohjelmat muunnettaviksi Eri rivinvaihtotapojen välisiä tiedostoja ovat unix2dos ja dos2unix, mac2unix ja unix2mac, mac2dos ja dos2mac ja flip. tr-komento on käytettävissä käytännöllisesti katsoen kaikissa Unix-tyyppisissä järjestelmissä, ja sitä voidaan käyttää mielivaltaisten korvaustoimintojen suorittamiseen yksittäisillä merkeillä. DOS / Windows-tekstitiedosto voidaan muuntaa Unix-muotoon poistamalla yksinkertaisesti kaikki ASCII CR -merkit

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

tai, jos tekstissä on vain CR-uusia rivejä, kaikkien CR-rivien muuntaminen LF-muotoon

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

Samoja tehtäviä suoritetaan joskus awk-, sed- tai Perl-tiedostoilla, jos alustalla on Perl-tulkki:

Tiedostokomento tunnistaa rivipäätteiden tyypin:

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

Unix egrep (laajennettu grep) -komento voidaan käyttää Unix- tai DOS-tiedostojen tiedostonimien tulostamiseen (olettaen, että vain Unix- ja DOS-tyyliset tiedostot, ei 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)

Muut työkalut antavat käyttäjän visualisoida EOL-merkit:

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