Quali sono i caratteri di controllo file/gruppo/record/unità separatore e il loro utilizzo?

Question

Unicode definisce più caratteri di controllo da ASCII. http://www.unicode.org/charts/PDF/U0000.pdf

maggior parte di essi sono di solito utilizzati, ma io davvero non riuscivo a vedere qualsiasi utilizzo di separatori (U + 001C ~ U + 001F)

Quali sono loro? Qual è la loro storia? Dove hanno usato per?

Answer 1

Lammert Bies spiega sia il loro utilizzo che la storia.

28 - FS - separatore di file Il file separatore di FS è un codice di controllo interessante , in quanto ci fornisce una visione in modo in cui la tecnologia informatica era organizzato negli anni sessanta. Siamo ora utilizzati per i media ad accesso casuale come RAM e dischi magnetici, ma quando lo standard ASCII è stato definito, la maggior parte dei dati era seriale. Non sto parlando solo delle comunicazioni seriali , ma anche dello storage seriale come le schede perforate, del nastro di carta e dei nastri magnetici. In tale situazione è chiaramente efficace per avere un singolo codice di controllo per segnalare la separazione di due file. Lo standard FS è stato definito per questo scopo.

29 - GS - separatore Archiviazione dati Gruppo è stato uno dei motivi principali per un certo controllo codici per ottenere nella definizione ASCII. I database sono quasi sempre impostati con tabelle, contenenti record. Tutti i record in una tabella hanno lo stesso tipo , ma i record di diverse tabelle possono essere diversi. Il separatore di gruppo GS è definito per separare le tabelle in un sistema di archiviazione dati seriale . Si noti che la tabella delle parole non è stata utilizzata in quel momento e le persone ASCII lo hanno chiamato un gruppo.

30 - RS - Record separatori Da un gruppo (o tabella) dei registri sono separati con RS o registrare separatore.

31 - US - separatore Unità Gli elementi di dati più piccoli da memorizzare in un database sono chiamati unità nella definizione ASCII. Li chiameremmo ora campo .Il separatore di unità separa questi campi in un ambiente di archiviazione dati seriale . Le più recenti implementazioni di database richiedono che i campi della maggior parte dei tipi abbiano una lunghezza fissa . Spazio sufficiente nel record è assegnato per memorizzare il membro più grande possibile di ogni campo, anche se questo non è necessario nella maggior parte dei casi. Ciò comporta una notevole quantità di spazio in molte situazioni. Il codice di controllo statunitense consente a tutti i campi di avere una lunghezza variabile . Se lo spazio di archiviazione dei dati è limitato, come negli anni Sessanta, questo è un buon modo per preservare lo spazio prezioso . D'altra parte è la memoria seriale molto meno efficiente della tabella RAM gestita e implementazioni del disco di tempi moderni. Non riesco a immaginare una situazione in cui i database SQL moderni vengono eseguiti con i dati memorizzati su carta nastro o bobine magnetiche ...

separatore di unità e potrebbe fornire essenzialmente lo stesso scopo, come una virgola in un file CSV file o una scheda in un file delimitato da tabulazioni.

Answer 2

Intendevi che la maggior parte di questi sono solitamente non utilizzati in questi giorni? I caratteri di controllo riguardano principalmente le funzioni di controllo del dispositivo, ma alcuni di essi potrebbero essere stati utilizzati come separatori nei file di testo. Per un rapido riferimento, controlla il mio table of C0 Controls.

I separatori di informazioni sono stati utilizzati per raggruppare i dati in modo semplice, ma in questi giorni, i formati binari o il formato XML vengono utilizzati per l'organizzazione dei dati. Ci sono ancora curiosità, come l'uso interno di U + 001E e U + 001F in Microsoft Word per implementare l'idea del programma di "trattino non brusco" e "trattino opzionale" (come opposto ai caratteri Unicode per scopi simili). Questo illustra principalmente che i programmi possono usare caratteri di controllo in modi strani. I problemi sorgono naturalmente se i caratteri sono inclusi nel testo trasmesso ad altri programmi.