Strumenti di testo e di uso quotidiano · Text Toolkit
CR, LF e CRLF: da dove provengono le terminazioni di riga e perché il testo incollato si interrompe
· Sfondo
terminazioni di riga pulizia del testo esportazioni di dati
Spiega le origini della telescrivente del ritorno a capo e dell'avanzamento riga, perché i sistemi operativi hanno scelto convenzioni diverse e come tali scelte vengono visualizzate come righe vuote doppie e caratteri vaganti nel testo incollato.
L'esportazione con una riga vuota dopo ogni riga: perché un file di un altro sistema viene incollato con il doppio delle righe
Incolli un'esportazione di tre righe e vedi una riga vuota dopo ogni record. Si è tentati di dare subito la colpa a Windows CRLF, ma un'area di testo conforme agli standard normalmente presenta interruzioni di riga in forma normalizzata. Le righe doppie più spesso significano che una conversione precedente trattava il ritorno a capo e l'avanzamento riga come due separatori indipendenti o inserisce una nuova riga aggiuntiva tra i record.
Conserva l'originale finché non sai in quale fase è stato modificato. Confronta la fonte in un editor che possa rivelare i caratteri di controllo, quindi confronta il conteggio delle righe incollate. ToolAcre accetta deliberatamente CRLF, LF e lone CR come un limite ciascuno, quindi un file di tre record non modificato dovrebbe produrre tre righe anziché sei semplicemente perché proviene da Windows.
Una riga vuota in più è un sintomo, non una prova che solo CRLF l'abbia causata
I nomi descrivono azioni fisiche sui terminali di stampa. Un ritorno a capo spostava il carrello all'inizio della riga corrente, mentre un avanzamento riga faceva avanzare la carta alla riga successiva. Erano controlli separati perché ciascuna mozione poteva essere richiesta indipendentemente. ASCII li ha mantenuti come caratteri di controllo CR al decimale 13 e LF al decimale 10.
Gli schermi moderni non spostano più la carta, ma i valori dei byte sono sopravvissuti nei file, nei protocolli e nelle interfacce di programmazione. La cronologia spiega perché CR e LF non sono segni di punteggiatura intercambiabili e perché CRLF è una sequenza di due caratteri. Ciò non significa che ogni applicazione moderna li elabora separatamente; i parser riconoscono comunemente la coppia come una fine di linea logica.
Tre convenzioni: LF su Unix e macOS moderno, CRLF su Windows, CR su Mac OS classico e perché ciascuna sembrava ragionevole
I sistemi Unix e simili a Unix utilizzano convenzionalmente LF per la fine della riga e il moderno macOS segue questa convenzione. I file di testo di Windows utilizzano convenzionalmente CRLF. Il sistema operativo Mac classico utilizzava solo CR, ma Mac OS X ha adottato le basi Unix e LF. Tali scelte rimangono visibili quando gli strumenti scambiano testo semplice senza concordare la normalizzazione.
Nessuna convenzione rende le parole stesse diverse. Il problema appare su un confine il cui lettore si aspetta solo una rappresentazione o si divide ingenuamente su ogni carattere di controllo. Un robusto parser di linea controlla CRLF come coppia prima di controllare CR o LF singoli. ToolAcre fa esattamente questo con il modello ordinato ` | | `, quindi unisce l'output trasformato con LF.
Cosa succede in una casella di testo del browser: come le interruzioni di riga vengono generalmente normalizzate durante l'incolla e dove compaiono ancora caratteri vaganti
HTML definisce una gestione speciale per le interruzioni di riga nei controlli di testo. In un valore textarea, i browser normalizzano CRLF e isolano CR in LF nel valore esposto, mentre l'invio del modulo può applicare le regole dei dati del modulo per le interruzioni di riga. Di conseguenza, un incolla che sembra corretto nella scatola può ancora essere serializzato in modo diverso da un altro livello o copiato nel software con un'altra convenzione.
CR vaganti possono ancora emergere quando il testo bypassa una normale area di testo, quando vengono visualizzati byte di escape come i caratteri letterali `\r` o quando un parser si divide solo su LF e lascia CR attaccato a ciascun campo. Il browser è una fase del percorso, non un servizio di riparazione universale per file, produttori di appunti, API e consumatori di riga di comando.
I browser normalizzano le interruzioni di riga dell'area di testo, ma i formati degli appunti e quelli downstream differiscono ancora
Le righe vuote e i ritorni a capo finali richiedono diagnosi diverse. Rimuovi righe vuote elimina le righe il cui contenuto è vuoto o con spazi bianchi dopo che ToolAcre ha riconosciuto tutti e tre gli stili di fine riga. Ritaglia linee rimuove gli spazi bianchi iniziali e finali da ogni riga. Poiché lo splitter di ToolAcre utilizza un vero separatore CR, normalmente non è necessario tagliare semplicemente per cancellare quel separatore.
Utilizza il taglio solo quando rimangono spazi, tabulazioni o un carattere letterale non utilizzato e controlla il rientro significativo prima di modificarlo. Se il testo contiene `^M` visibile, determina se il visualizzatore sta visualizzando un CR effettivo o quei due caratteri stampabili. Una sostituzione della coperta può danneggiare il contenuto previsto, mentre il controllo dei conteggi prima e dopo fornisce un risultato rivedibile.
Rimuovi righe vuote corregge le righe vuote; il taglio di solito non è necessario dopo che ToolAcre ha diviso correttamente CR
Per un esempio riproducibile, iniziare con tre nomi la cui rappresentazione intermedia danneggiata contiene una riga vuota tra ciascun nome: `Ada`, vuoto, `Grace`, vuoto, `Linus`. Il contatore di parole e caratteri riporta cinque righe. Questo è un input deliberatamente raddoppiato; una sequenza CRLF autentica da sola verrebbe riconosciuta come un limite e non creerebbe quelle righe vuote in ToolAcre.
Scegli Rimuovi righe vuote e l'output diventa tre righe unite con LF. Il contatore ora dovrebbe segnalarne tre. Se i valori importati contengono anche riempimento, esegui Trim Lines separatamente ed esamina il risultato. Separando queste operazioni si dimostra quale difetto è stato risolto in ciascuna azione invece di attribuire ogni pulizia a una vaga conversione dal testo di Windows.
Esempio realizzato: pulire un'esportazione deliberatamente raddoppiata e verificare il conteggio delle righe
La pulizia della fine riga non ripara il ritorno a capo, dove una frase logica è stata deliberatamente interrotta alla larghezza di una colonna. Rimuovere ogni nuova riga da quel materiale unirebbe anche paragrafi reali ed elementi di elenco. Decidi se il confine rappresenta un record, un paragrafo o un avvolgimento visivo prima di applicare un'operazione di linea sull'intero blocco.
Inoltre non diagnostica la codifica dei caratteri. Un contrassegno dell'ordine dei byte UTF-8, diamanti sostitutivi, mojibake e errori di decodifica riguardano il modo in cui i byte diventano caratteri, non se CR o LF separano tali caratteri in righe. Conserva il file originale e identifica la sua codifica con uno strumento appropriato in grado di riconoscere i file prima di trattare simboli visibili strani come terminazioni di riga.
Il takeaway: i finali di riga sono la storia che puoi vedere; gli strumenti di linea e il contatore di Text Toolkit ti consentono di correggere i sintomi in pochi secondi
CR, LF e CRLF sono controlli storici con conseguenze di compatibilità attuali. Il modello mentale più sicuro è una linea di confine logica con diverse rappresentazioni fisiche. Contare i record, ispezionare la convenzione di origine e identificare la fase che ha introdotto righe vuote o mantenuto caratteri di controllo prima di eliminare qualsiasi cosa.
Per il materiale incollato, apri Text Toolkit su `/tools/text/`, annota il conteggio delle righe iniziali, applica Rimuovi righe vuote solo quando le righe vuote sono veramente indesiderate e utilizza le linee di taglio solo per gli spazi bianchi circostanti. Ricontrollare il conteggio e i record dei campioni in seguito. Questo breve controllo trasforma un problema di formattazione invisibile in una trasformazione di testo controllata e reversibile.