Perché i caratteri di “controllo” sono illegali in XML 1.0?

Ci sono una varietà di caratteri che non sono legalmente codificabili in XML 1.0, ad es. U+0007 (‘bell’) e U+001B (‘escape’). La maggior parte di quelli interessanti sono i caratteri di “controllo” non bianchi.

È chiaro da (ad esempio) questa domanda e altri che è la specifica XML che è il problema – ma qualcuno può illuminarmi sul motivo per cui la specifica XML vieta questi caratteri?

Sembra che potrebbe essere richiesto che siano codificati in  , ad esempio come  e  rispettivamente, ma forse c’è una ragione pratica per cui i personaggi erano proibiti piuttosto che essere tenuti alla fuga?

I soccorritori hanno suggerito che c’è qualche motivazione per evitare i caratteri di controllo della trasmissione, ma Unicode include molti altri caratteri di controllo (considerate U+200C “zero width non joiner”). Riconosco che non ci può essere una buona ragione per questo comportamento, ma mi piacerebbe comunque capirlo meglio.

È particolarmente frustrante perché quando quei valori dei caratteri appaiono in altri formati di dati di codifica , finisco per “duplicare” i nuovi documenti XML che devono codificarli.

La mia comprensione è che questa gamma è bloccata sulla base del fatto che un linguaggio di markup non dovrebbe avere alcuna necessità di supportare i caratteri di trasmissione e controllo del stream e includerli creerebbe un problema per qualsiasi editor e parser nella conversione binaria.

Sto faticando a trovare qualcosa di ex cathedra su questo da Tim Bray e altri però.

modifica: alcune discussioni sui caratteri di controllo e una vaga ammissione non erano esattamente eccessivamente ingegnerizzati:

Alle 09:27 del 17/06/00 -0500, Mark Volkmann ha scritto:

Non ho mai visto una discussione sul motivo per cui la maggior parte dei caratteri di controllo ASCII, come un feed di moduli, non è consentita nei documenti XML. Qualcuno può dirmi la ragione di questa decisione o indicarmi una specifica. questo lo spiega?

Non sono sicuro che lo faremmo allo stesso modo se lo facessimo di nuovo. Non vedo che facciano alcun danno reale. Chiaramente, se stai ottimizzando un linguaggio di marcatura del contenuto altamente interoperabile (e XML è) è legittimo essere sospettosi di cose come la tabulazione verticale e il backspace e così via … ma allora come può essere coerente lasciare in \ n e DEL e così via? -Tim

È stato tanto tempo fa, ma il mio ricordo migliore è che non hanno una rappresentazione grafica e nemmeno una semantica concordata. Selezionando un paio a caso, vediamo U + 0006 “Riconoscimento” o U + 0016 “Pausa sincrona” … cosa significano questi? Unicode non dice. Anche quando tutti sostenevano di supportare ASCII, non c’era interoperabilità intorno a questa robaccia. Si suppone che XML riguardi l’interoperabilità.

L’esperienza è stata che le persone che vogliono usare queste cose vogliono davvero confondere i dati binari nei loro elementi XML (e la prossima cosa che vogliono è includere U + 0000 NULL), che è stato un esplicito non-objective di XML dal giorno 1. Se vuoi rappresentare i numeri 0x6 o 0x16, ci sono molti buoni modi per farlo che non infangano la nozione di “personaggio”.

Sembra che potrebbe essere richiesto che siano codificati in escape, ad esempio come & # x0007; e & # x001B;

Puoi fare esattamente questo in XML 1.1, per tutti tranne \ 0.

Probabilmente è tempo di riassumere, anche con una vista su XML 1.1.

Quali punti di codice del carattere di controllo ci sono in Unicode?

  • U+0000 a U+001f , ereditato da ASCII.
  • U+007F , ereditato da ASCII
  • U+0080 a U+009F , ereditato da Latin-1
  • vari intervalli di scopo speciali, standardizzati esplicitamente per Unicode e per lo più utili soprattutto in contesti non di markup. Qui vengono discussi blocco per blocco, compresi i motivi per cui e come usarli o non usarli in XML e cosa fare se li incontri comunque.

In che modo XML guarda quei personaggi di controllo?

Questa è una classificazione diversa.

  • Tab e newline (indipendentemente dalla dipendenza dalla piattaforma di ciò che è una nuova riga) sono buoni. Tutti li usano. Tutti sanno cosa dovrebbero rappresentare. Consentito in quasi tutte le forms conosciute, spesso anche per la bella stampa del markup stesso.
  • U+0000 è il male. Carattere null? Terminatore di stringa? Rumore binario? Antitesi all’interoperabilità e al markup. Proibito in tutte le forms.
  • Qualunque altra cosa? Interoperabilità difficilmente usata e problematica, ma ci sono modi per tollerarli anche senza sapere molto su cosa dovrebbero “controllare”.

Passiamo ora a questa ultima categoria, i codici di controllo corretti. Cioè, il seguente riassunto NON si applica alle tabs e ai newline: U+0009 , U+000a , U+000D , U+0085 , U+2028 .

XML 1.0 consente tutti i suddetti intervalli di caratteri di controllo, eccetto da U+0000 a U+001f , come testo (caratteri inclusi direttamente) e come riferimenti numerici ai caratteri . Consentendo da U+007F a U+009F era apparentemente per omissione e questa incoerenza è stata corretta in XML 1.1, ma viceversa. Hanno persino fornito una spiegazione dettagliata dello standard:

Infine, c’è una notevole richiesta di definire una rappresentazione standard di caratteri Unicode arbitrari nei documenti XML. Pertanto, XML 1.1 consente l’uso di riferimenti di carattere ai caratteri di controllo da # x1 a # x1F, la maggior parte dei quali sono vietati in XML 1.0. Per ragioni di robustezza, tuttavia, questi caratteri non possono ancora essere utilizzati direttamente nei documenti. Al fine di migliorare la robustezza del rilevamento della codifica dei caratteri, i caratteri di controllo aggiuntivi # x7F fino a # x9F, che erano liberamente consentiti nei documenti XML 1.0, ora devono apparire anche solo come riferimenti di carattere. (I caratteri di uno spazio bianco sono ovviamente esenti.) Il minor sacrificio di retrocompatibilità è considerato non significativo. A causa di potenziali problemi con le API, # x0 è ancora vietato sia direttamente che come riferimento di carattere.

Perché Unicode e XML consentono l’uso gratuito di caratteri di controllo simili al markup, a parte i pochi intervalli “ereditati”? Le persone dovrebbero usare il markup per quelli.

Unicode viene anche utilizzato in contesti non di markup ed è un set di caratteri ancora in evoluzione. Sarebbe troppo difficile implementare un processore XML conforms se l’insieme di caratteri non di controllo era un bersaglio mobile.

OK, cosa c’è che non va negli intervalli ereditati, rispetto ai caratteri di controllo specifici per Unicode?

Mancanza di standardizzazione Il consorzio Unicode non ha davvero potuto scegliere quali numeri sono assegnati a quei “personaggi”, o qual è la loro tipica presentazione o significato visivo. La completa retrocompatibilità con ASCII (sul livello UTF-8 codificato) e con Latin-1 (sul livello di assegnazione del codice) forzava l’inclusione cruda di questi punti di codice indipendentemente dai vari significati specializzati e sovraccarichi spesso associati a loro in vari contesti di elaborazione del testo.

Aspetta, stai dicendo che XML non è pensato per essere completamente retrocompatibile con ASCII, a differenza di UTF-8?

Si. È corretto. Hai bisogno di un elemento del documento. Non puoi nemmeno inserire un grezzo < o & . Quindi, perché dovresti mai inserire caratteri di controllo grezzi?

XML è stato progettato appositamente per Unicode (in particolare UTF-8 e UTF-16) e ISO / IEC 10646, entrambi i quali (non sono abbastanza positivo su ISO 10646) contengono i caratteri di controllo di trasmissione / stream che sono stati lasciati da ASCII e i giorni dei terminali basati sui caratteri. Mentre quei personaggi hanno ancora usi, non appartengono a un formato come XML.

Per quanto riguarda queste nuove codifiche che usano quei codici per qualcos’altro, beh, sembra che la specifica XML possa aver bisogno di adattarsi.

Perché stai fuggendo da loro? Questo sembra un buon posto per & bell; e & escape ;. (Non definito, gestito da callback dal parser al tuo codice)