Utilizzo dei delimitatori ASCII (29-31) nella programmazione moderna

Question

Attualmente sto costruendo una stringa di chiavi hash (compressa da una mappa) in cui i valori sono delimitati dallo speciale delimitatore ASCII 31 (1F).

questo risolve bene il problema di cercare di indovinare che cosa i caratteri ASCII non saranno utilizzati nei valori di stringa e non hanno bisogno di preoccuparsi di fuga o citando valori ecc

Tuttavia leggendo la storia di sembra essere una reliquia degli anni '60 e non ho visto molti esempi in cui le stringhe sono costruite e gettate a segno con questo carattere speciale, quindi sembra tutto troppo facile.

Ci sono problemi nell'utilizzo di questo delimitatore in un'applicazione moderna?

Attualmente sto facendo questo in un'applicazione C++ non Unicode, tuttavia sono interessato a sapere come questo si applica generalmente in altri linguaggi come Java, C# e con Unicode.

Answer 1

La mappa di 128 caratteri ASCII in basso è completamente impostata nello standard Unicode, inclusi i caratteri 0-> 31. L'unica ragione per cui non si vedono caratteri ASCII speciali in uso nelle stringhe molto spesso è semplicemente a causa di limiti di interfacciamento umano: non visualizzano bene (se non lo sono) quando vengono visualizzati sullo schermo o scritti su file, e non si può facilmente digitarli da una tastiera. Inoltre, non sono consentiti in forma sfuggita all'interno di vari formati di file 'leggibili', come XML.

Per le attività di elaborazione logica all'interno di un programma che non richiedono interazione con l'utente finale, tuttavia, sono perfettamente idonei per qualsiasi utilizzo possibile. Il tuo uso particolare sembra nuovo ed efficiente e penso che dovresti assolutamente correre con esso.

Answer 2

L'applicazione è libera di accettare qualsiasi formato binario che desideri. Tuttavia, se hai bisogno di incorporare dati binari arbitrari nel tuo input, devi sfuggire a qualsiasi delimitatore o altro codice speciale utilizzato dal tuo formato. Questo è vero indipendentemente da quali scegli.

Non ignorerei anche Unicode. È il 2012, ormai è piuttosto sciocco lavorare con un modello obsoleto per gestire il testo. Se i tuoi dati di input sono testuali, gestiscili come tali.

L'unico problema che viene in mente è perché inventare un altro formato invece di utilizzare XML o JSON; o se hai bisogno di una codifica compatta, una variante "binaria" di questi due (Fast Infoset, msgpack, chissà cos'altro) o ASN.1? Ci sono probabilmente un sacco di altri problemi che incontrerai quando fai il tuo da solo che il design e gli strumenti per questi formati sono già stati risolti.