ILSSerializer Interfaccia

Definizione

[Android.Runtime.Register("org/w3c/dom/ls/LSSerializer", "", "Org.W3c.Dom.LS.ILSSerializerInvoker")]
public interface ILSSerializer : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("org/w3c/dom/ls/LSSerializer", "", "Org.W3c.Dom.LS.ILSSerializerInvoker")>]
type ILSSerializer = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Attributi

RegisterAttribute

Implementazioni

IJavaObject IJavaPeerable IDisposable

Commenti

Un LSSerializer oggetto fornisce un'API per la serializzazione (scrittura) di un documento DOM in XML. I dati XML vengono scritti in una stringa o in un flusso di output. Eventuali modifiche o correzioni apportate durante la serializzazione influiscono solo sui dati serializzati. L'oggetto Document e i relativi elementi figlio non vengono mai modificati dall'operazione di serializzazione.

Durante la serializzazione dei dati XML, la correzione dello spazio dei nomi viene eseguita come definito in [DOM Level 3 Core] , Appendice B. [DOM Level 2 Core] consente stringhe vuote come URI dello spazio dei nomi reale. Se l'oggetto namespaceURI di è una Node stringa vuota, la serializzazione li considererà come null, ignorando il prefisso, se presente.

LSSerializer accetta qualsiasi tipo di nodo per la serializzazione. Per i nodi di tipo Document o Entity, verrà creato codice XML ben formato quando possibile (la forma corretta è garantita se il documento o l'entità proviene da un'operazione di analisi ed è invariato dopo la creazione). L'output serializzato per questi tipi di nodo è rispettivamente un documento XML o un'entità XML esterna ed è un input accettabile per un parser XML. Per tutti gli altri tipi di nodi il modulo serializzato dipende dall'implementazione.

All'interno di , Documento in fase di serializzazione, DocumentFragment vengono elaborati come segue Entityi nodi ulNodes<li>< vengono scritti, inclusa la dichiarazione XML (a meno che il parametro "xml-declaration" non sia impostato su >) e un subset DTD, se presente nel DOM.Documentfalse La scrittura di un Document nodo serializza l'intero documento. <I nodi /li><li>Entity , quando scritti direttamente da LSSerializer.write, generano l'espansione dell'entità, ma non viene eseguita alcuna correzione dello spazio dei nomi. L'output risultante sarà valido come entità esterna. </li><li> Se il parametro " entities" è impostato su true, EntityReference i nodi vengono serializzati come riferimento all'entità del formato " " &entityName;nell'output. I nodi figlio (l'espansione) del riferimento all'entità vengono ignorati. Se il parametro " entities" è impostato su false, vengono serializzati solo gli elementi figlio del riferimento all'entità. EntityReference i nodi senza elementi figlio (nessun nodo corrispondente Entity o i nodi corrispondenti Entity non hanno elementi figlio) vengono sempre serializzati. </li><contenente>CDATAsections i caratteri di contenuto che non possono essere rappresentati nella codifica di output specificata vengono gestiti in base al parametro " split-cdata-sections". Se il parametro è impostato su true, CDATAsections vengono suddivisi e i caratteri non rappresentabili vengono serializzati come riferimenti a caratteri numerici nel contenuto ordinario. La posizione esatta e il numero di divisioni non sono specificati. Se il parametro è impostato su false, i caratteri non rappresentabili in un CDATAsection vengono segnalati come "wf-invalid-character" errori se il parametro " ben formato" è impostato su true. L'errore non è recuperabile: non esiste alcun meccanismo per fornire caratteri alternativi e continuare con la serializzazione. <I nodi /li><li>DocumentFragment vengono serializzati serializzando gli elementi figlio del frammento di documento nell'ordine in cui vengono visualizzati nel frammento di documento. </li><li> Tutti gli altri tipi di nodo (elemento, testo e così via) vengono serializzati nel formato di origine XML corrispondente. </li></ul>

<b Nota:>/b<> La serializzazione di un Node oggetto non genera sempre un documento XML ben formato, ad esempio un LSParser potrebbe generare errori irreversibili durante l'analisi della serializzazione risultante.

All'interno dei dati di tipo carattere di un documento (al di fuori del markup), tutti i caratteri che non possono essere rappresentati direttamente vengono sostituiti con riferimenti di carattere. Le occorrenze di '<' e '&' vengono sostituite dalle entità predefinite e lt; e & amp;. Altre entità predefinite (& gt;, & apos;, e & quot;) potrebbe non essere usato, tranne dove necessario (ad esempio, uso di & gt; in casi come ']]>'). Tutti i caratteri che non possono essere rappresentati direttamente nella codifica dei caratteri di output vengono serializzati come riferimenti a caratteri numerici (e poiché gli standard di codifica dei caratteri usano in genere rappresentazioni esadecimali di caratteri, usando la rappresentazione esadecimale durante la serializzazione dei riferimenti a caratteri è incoraggiato).

Per consentire ai valori degli attributi di contenere virgolette singole e doppie, il carattere apostrofo o virgolette singole (') può essere rappresentato come "& apos;" e il carattere virgolette doppie (") come "& quot;". I nuovi caratteri di riga e altri caratteri che non possono essere rappresentati direttamente nei valori di attributo nella codifica dei caratteri di output vengono serializzati come riferimento numerico.

All'interno del markup, ma all'esterno degli attributi, qualsiasi occorrenza di un carattere che non può essere rappresentato nella codifica dei caratteri di output viene segnalata come errore DOMError irreversibile. Un esempio è la serializzazione dell'elemento < LaCa\u00f1ada/> con . Ciò comporterà una generazione di " DOMError wf-invalid-character-in-node-name" (come proposto in " ben formato").

Quando richiesto impostando il parametro " normalize-characters" su LSSerializer true, la normalizzazione dei caratteri viene eseguita in base alla definizione di caratteri completamente normalizzati inclusi nell'appendice E di [XML 1.1] su tutti i dati da serializzare, sia i dati di markup che di tipo carattere. Il processo di normalizzazione dei caratteri influisce solo sui dati durante la scrittura; non modifica la visualizzazione dom del documento dopo il completamento della serializzazione.

Le implementazioni sono necessarie per supportare le codifiche "UTF-8", "UTF-16", "UTF-16BE" e "UTF-16LE" per garantire che i dati siano serializzabili in tutte le codifiche necessarie per essere supportate da tutti i parser XML. Quando la codifica è UTF-8, indipendentemente dal fatto che venga serializzato o meno un contrassegno di ordine di byte o se l'output è big-endian o little-endian, dipende dall'implementazione. Quando la codifica è UTF-16, indipendentemente dal fatto che l'output sia big-endian o little-endian sia dipendente dall'implementazione, ma è necessario generare un byte Order Mark per gli output non di caratteri, ad esempio LSOutput.byteStream o LSOutput.systemId. Se il byte order mark non viene generato, viene segnalato un avviso "byte-order-mark-needed". Quando la codifica è UTF-16LE o UTF-16BE, l'output è big-endian (UTF-16BE) o little-endian (UTF-16LE) e il byte Order Mark non viene generato. In tutti i casi, la dichiarazione di codifica, se generata, corrisponderà alla codifica usata durante la serializzazione, ad esempio encoding="UTF-16" se è stato richiesto UTF-16.

Gli spazi dei nomi vengono risolti durante la serializzazione, il processo di serializzazione verificherà che le dichiarazioni dello spazio dei nomi, i prefissi dello spazio dei nomi e l'URI dello spazio dei nomi associati a elementi e attributi siano coerenti. Se vengono trovate incoerenze, la forma serializzata del documento verrà modificata per rimuoverle. Il metodo usato per eseguire la correzione dello spazio dei nomi durante la serializzazione di un documento è l'algoritmo definito nell'Appendice B.1, "Normalizzazione dello spazio dei nomi", di [DOM Level 3 Core] .

Durante la serializzazione di un documento, il parametro "discard-default-content" controlla se i dati non specificati vengono serializzati.

Durante la serializzazione, gli errori e gli avvisi vengono segnalati all'applicazione tramite il gestore degli errori (LSSerializer.domConfigparametro " error-handler"). Questa specifica non tenta in alcun modo di definire tutti gli errori e gli avvisi possibili che possono verificarsi durante la serializzazione di un nodo DOM, ma vengono definiti alcuni casi di errore e di avviso comuni. I tipi ( DOMError.type) di errori e avvisi definiti da questa specifica sono: <dl><dt>"no-output-specified" [fatal]</dt dd><> Raised durante la LSOutputscrittura in un LSOutput oggetto se non viene specificato alcun output in . </dd><dt/dt>"unbound-prefix-in-entity-reference" [fatal]<>< dd> Raised se il parametro di configurazione " namespaces" è impostato su true e un'entità il cui testo sostitutivo contiene prefissi dello spazio dei nomi non associati viene fatto riferimento in un percorso in cui non sono presenti associazioni per i prefissi dello spazio dei nomi. </dd><dt/dt>"unsupported-encoding" [fatal]< dd><> Generato se viene rilevata una codifica non supportata. </dd></dl>

Oltre a generare gli errori e gli avvisi definiti, è previsto che le implementazioni generino errori e avvisi specifici dell'implementazione per eventuali altri casi di errore e di avviso, ad esempio errori di I/O (file non trovato, autorizzazione negata,...) e così via.

Vedere anche Document Object Model (DOM) Level 3 Load and Save Specification (Load and Save Specification).

per org.w3c.dom.ls.LSSerializer.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dalla e usati in base ai termini descritti in Creative License 2.5 Attribution License.