ILSSerializer Interfaccia
Definizione
Importante
Alcune informazioni sono relative alla release non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.
Un LSSerializer oggetto fornisce un'API per la serializzazione (scrittura) di un documento DOM in FORMATO XML.
[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
- Implementazioni
Commenti
Un LSSerializer oggetto fornisce un'API per la serializzazione (scrittura) di un documento DOM in FORMATO XML. I dati XML vengono scritti in una stringa o in un flusso di output. Le modifiche o le 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 è Node una stringa vuota, la serializzazione li tratterà 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 un Documentoggetto , DocumentFragmento Entity in fase di serializzazione, Nodes vengono elaborati come indicato di seguito <vengono scritti i nodi ul><li>Document , inclusa la dichiarazione XML (a meno che il parametro "xml-declaration" non sia impostato su false) e un subset DTD, se presente nel DOM. La scrittura di un Document nodo serializza l'intero documento. <I nodi /li>Entity<>, se 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 di entità del modulo " &entityName;" nell'output. I nodi figlio (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 figli (nessun nodo corrispondente Entity o i nodi corrispondenti Entity non hanno figli) vengono sempre serializzati. </li>CDATAsections<> contenente 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><vengono>DocumentFragment 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 modulo di origine XML corrispondente. </li></ul><p 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 a caratteri. Le occorrenze di '<' e '&' vengono sostituite dalle entità predefinite & Tenente; e & Amp;. Le altre entità predefinite (& gt;, & apos;, e & quot;) potrebbe non essere utilizzato, tranne dove necessario (ad esempio, utilizzando & 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 quando si serializzano i riferimenti di carattere è consigliato).
Per consentire ai valori di attributo 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 degli attributi nella codifica dei caratteri di output vengono serializzati come riferimento a caratteri numerici.
All'interno del markup, ma all'esterno degli attributi, qualsiasi occorrenza di un carattere che non può essere rappresentata nella codifica dei caratteri di output viene segnalata come errore DOMError irreversibile. Un esempio è la serializzazione dell'elemento < LaCa\u00f1ada/> con encoding="us-ascii". 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 i dati di tipo carattere. Il processo di normalizzazione dei caratteri influisce solo sui dati mentre vengono scritti; 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 un contrassegno di ordine dei byte sia serializzato o se l'output sia 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 corretti 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 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 comuni di errore e avviso. I tipi ( DOMError.type) di errori e avvisi definiti da questa specifica sono: <dl><dt"no-output-specified" [fatal]<>/dt dt><dd> Raised durante la scrittura in un LSOutput oggetto se non viene specificato alcun output in .LSOutput </dd><dt/dt><"unbound-prefix-in-entity-reference" [fatal]<> dd> Generato 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 qualsiasi altro errore e casi 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 .See also the Document Object Model (DOM) Level 3 Load and Save Specification.
Documentazione java per org.w3c.dom.ls.LSSerializer.
Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dal Android e usato in base ai termini descritti in 2.5 Attribution License Creative Commons 2.5 Attribution License.
Proprietà
| DomConfig |
Un |
| Handle |
Ottiene il valore JNI dell'oggetto Android sottostante. (Ereditato da IJavaObject) |
| JniIdentityHashCode |
Restituisce il valore di |
| JniManagedPeerState |
Stato del peer gestito. (Ereditato da IJavaPeerable) |
| JniPeerMembers |
Supporto per l'accesso ai membri e la chiamata. (Ereditato da IJavaPeerable) |
| NewLine |
Un |
| PeerReference |
Restituisce un JniObjectReference oggetto dell'istanza dell'oggetto Java di cui è stato eseguito il wrapping. (Ereditato da IJavaPeerable) |
Metodi
| Disposed() |
Chiamato quando l'istanza è stata eliminata. (Ereditato da IJavaPeerable) |
| DisposeUnlessReferenced() |
Se non sono presenti riferimenti in sospeso a questa istanza, chiama |
| Finalized() |
Chiamato quando l'istanza è stata finalizzata. (Ereditato da IJavaPeerable) |
| SetJniIdentityHashCode(Int32) |
Impostare il valore restituito da |
| SetJniManagedPeerState(JniManagedPeerStates) |
Un |
| SetPeerReference(JniObjectReference) |
Impostare il valore restituito da |
| UnregisterFromRuntime() |
Annullare la registrazione di questa istanza in modo che il runtime non lo restituisca dalle chiamate future Java.Interop.JniRuntime+JniValueManager.PeekValue . (Ereditato da IJavaPeerable) |
| Write(INode, ILSOutput) |
Serializzare il nodo specificato come descritto in precedenza nella descrizione generale dell'interfaccia |
| WriteToString(INode) |
Serializzare il nodo specificato come descritto in precedenza nella descrizione generale dell'interfaccia |
| WriteToURI(INode, String) |
Metodo pratico che agisce come se |
Metodi di estensione
| JavaCast<TResult>(IJavaObject) |
Esegue una conversione del tipo verificato dal runtime Android. |
| JavaCast<TResult>(IJavaObject) |
Un |
| GetJniTypeName(IJavaPeerable) |
Un |
| WriteAsync(ILSSerializer, INode, ILSOutput) |
Un |
| WriteToURIAsync(ILSSerializer, INode, String) |
Un |