ILSSerializer Interfaz
Definición
Importante
Parte de la información hace referencia a la versión preliminar del producto, que puede haberse modificado sustancialmente antes de lanzar la versión definitiva. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.
Proporciona LSSerializer una API para serializar (escribir) un documento DOM en 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- Atributos
- Implementaciones
Comentarios
Proporciona LSSerializer una API para serializar (escribir) un documento DOM en XML. Los datos XML se escriben en una cadena o en un flujo de salida. Los cambios o correcciones realizados durante la serialización solo afectan a los datos serializados. El Document objeto y sus elementos secundarios nunca se modifican mediante la operación de serialización.
Durante la serialización de datos XML, la corrección del espacio de nombres se realiza como se define en [DOM Level 3 Core], apéndice B. [DOM Level 2 Core] permite cadenas vacías como un URI de espacio de nombres real. Si el namespaceURI valor de de es una Node cadena vacía, la serialización los tratará como null, ignorando el prefijo si existe.
LSSerializer acepta cualquier tipo de nodo para la serialización. En el caso de los nodos de tipo Document o Entity, se creará XML con formato correcto cuando sea posible (se garantiza el formato correcto si el documento o la entidad procede de una operación de análisis y no cambia desde que se creó). La salida serializada para estos tipos de nodo es como un documento XML o una entidad XML externa, respectivamente, y es una entrada aceptable para un analizador XML. Para todos los demás tipos de nodos, el formulario serializado depende de la implementación.
Dentro de , DocumentFragmento que se serializan, Nodes se procesan como se indica a continuación <los nodos ul><li>Document, incluida la declaración XML (a menos que el parámetro "xml-declaration" se establezca falseen ) y un subconjunto de DTD, si existe en el DOM.EntityDocument Escribir un Document nodo serializa todo el documento. <Los nodos /li>Entity<>, cuando se escriben directamente mediante LSSerializer.write, genera la expansión de la entidad, pero no se realiza ninguna corrección del espacio de nombres. La salida resultante será válida como una entidad externa. </li><li> Si el parámetro " entities" está establecido trueen , EntityReference los nodos se serializan como una referencia de entidad del formato " &entityName;" " en la salida. Se omiten los nodos secundarios (la expansión) de la referencia de entidad. Si el parámetro " entities" se establece falseen , solo se serializan los elementos secundarios de la referencia de entidad. EntityReference los nodos sin elementos secundarios (ningún nodo correspondiente Entity o los nodos correspondientes Entity no tienen elementos secundarios) siempre se serializan. </li><li>CDATAsections que contiene caracteres de contenido que no se pueden representar en la codificación de salida especificada se controlan según el parámetro " split-cdata-sections". Si el parámetro se establece trueen , CDATAsections se dividen y los caracteres no representables se serializan como referencias de caracteres numéricos en contenido normal. No se especifica la posición exacta y el número de divisiones. Si el parámetro se establece falseen , los caracteres no representables de un CDATAsection objeto se notifican como "wf-invalid-character" errores si el parámetro " correcto" está establecido trueen . El error no se puede recuperar: no hay ningún mecanismo para proporcionar caracteres alternativos y continuar con la serialización. <Los nodos /li><li>DocumentFragment se serializan mediante la serialización de los elementos secundarios del fragmento de documento en el orden en que aparecen en el fragmento de documento. </li li><> Todos los demás tipos de nodo (Element, Text, etc.) se serializan en su formato de origen XML correspondiente. </li></ul><p b>>< Nota:</b> La serialización de un Node no siempre genera un documento XML bien formado, es decir, un LSParser podría producir errores irrecuperables al analizar la serialización resultante.
Dentro de los datos de caracteres de un documento (fuera del marcado), los caracteres que no se pueden representar directamente se reemplazan por referencias de caracteres. Las apariciones de "<" y "&" se reemplazan por las entidades predefinidas & Lt; y & Amp;. Otras entidades predefinidas (& gt;, & apos;, y & quot;) es posible que no se use, excepto cuando sea necesario (por ejemplo, usar & Gt; en casos como ']]>'). Los caracteres que no se pueden representar directamente en la codificación de caracteres de salida se serializan como referencias de caracteres numéricos (y dado que los estándares de codificación de caracteres suelen usar representaciones hexadecimales de caracteres, mediante la representación hexadecimal al serializar referencias de caracteres se recomienda).
Para permitir que los valores de atributo contengan comillas simples y dobles, el apóstrofo o el carácter de comillas simples (') se puede representar como "& apos;", y el carácter de comillas dobles (") como "& quot;". Los nuevos caracteres de línea y otros caracteres que no se pueden representar directamente en los valores de atributo de la codificación de caracteres de salida se serializan como referencia de caracteres numéricos.
Dentro del marcado, pero fuera de los atributos, cualquier aparición de un carácter que no se pueda representar en la codificación de caracteres de salida se notifica como un DOMError error irrecuperable. Un ejemplo sería serializar el elemento < LaCa\u00f1ada/> con encoding="us-ascii". Esto dará como resultado una generación de " DOMError wf-invalid-character-in-node-name" (como se propone en " con el formato correcto").
Cuando se solicita estableciendo el parámetro " normalize-characters" en LSSerializer true, la normalización de caracteres se realiza según la definición de caracteres totalmente normalizados incluidos en el apéndice E de [XML 1.1] en todos los datos que se van a serializar, tanto los datos de marcado como de caracteres. El proceso de normalización de caracteres afecta solo a los datos a medida que se escriben; no modifica la vista del DOM del documento una vez completada la serialización.
Las implementaciones son necesarias para admitir las codificaciones "UTF-8", "UTF-16", "UTF-16BE" y "UTF-16LE" para garantizar que los datos sean serializables en todas las codificaciones que todos los analizadores XML deben admitir. Cuando la codificación es UTF-8, si se serializa o no una marca de orden de bytes, o si la salida es big-endian o little-endian, depende de la implementación. Cuando la codificación es UTF-16, si la salida es big-endian o little-endian depende de la implementación, pero se debe generar una marca de orden de bytes para salidas que no sean de caracteres, como LSOutput.byteStream o LSOutput.systemId. Si no se genera la marca de orden de bytes, se notifica una advertencia "byte-order-mark-needed". Cuando la codificación es UTF-16LE o UTF-16BE, la salida es big-endian (UTF-16BE) o little-endian (UTF-16LE) y no se genera la marca de orden de bytes. En todos los casos, la declaración de codificación, si se genera, corresponderá a la codificación usada durante la serialización (por ejemplo encoding="UTF-16" , aparecerá si se solicitó UTF-16).
Los espacios de nombres se fijan durante la serialización, el proceso de serialización comprobará que las declaraciones de espacios de nombres, los prefijos de espacio de nombres y el URI del espacio de nombres asociado a elementos y atributos son coherentes. Si se encuentran incoherencias, se modificará la forma serializada del documento para quitarlas. El método utilizado para realizar la corrección del espacio de nombres al serializar un documento es el algoritmo definido en el Apéndice B.1, "Normalización del espacio de nombres", de [DOM Level 3 Core] .
Al serializar un documento, el parámetro "discard-default-content" controla si se serializan o no los datos no especificados.
Al serializar, los errores y las advertencias se notifican a la aplicación a través del controlador de errores (LSSerializer.domConfigel parámetro " error-handler"). Esta especificación no intenta definir de ninguna manera todos los posibles errores y advertencias que pueden producirse al serializar un nodo DOM, pero se definen algunos casos comunes de error y advertencia. Los tipos ( DOMError.type) de errores y advertencias definidos por esta especificación son: <dl><dt>"no-output-specified" [fatal]</dt<>dd Raised> al escribir en si LSOutput no se especifica ningún resultado en .LSOutput </dd><dt>"unbound-prefix-in-entity-reference" [fatal]</dt><dd> Se genera si el parámetro de configuración " espacios de nombres" está establecido en y se hace referencia a true una entidad cuyo texto de reemplazo contiene prefijos de espacio de nombres sin enlazar en una ubicación donde no hay enlaces para los prefijos del espacio de nombres. </dd><dt>"unsupported-encoding" [fatal]</dt><dd> Se genera si se encuentra una codificación no admitida. </dd></dl>
Además de generar los errores y advertencias definidos, se espera que las implementaciones generen errores y advertencias específicos de la implementación para cualquier otro error y casos de advertencia, como errores de E/S (archivo no encontrado, permiso denegado,... etc.
Vea también la especificación de carga y guardado del modelo de objetos de documento (DOM) de nivel 3.
Documentación de Java para org.w3c.dom.ls.LSSerializer.
Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el proyecto de código Project y que se usan según los términos Creative Commons 2.5 Attribution License.
Propiedades
| DomConfig |
Proporciona |
| Handle |
Obtiene el valor JNI del objeto Android subyacente. (Heredado de IJavaObject) |
| JniIdentityHashCode |
Devuelve el valor de |
| JniManagedPeerState |
Estado del mismo nivel administrado. (Heredado de IJavaPeerable) |
| JniPeerMembers |
Compatibilidad con la invocación y el acceso de miembros. (Heredado de IJavaPeerable) |
| NewLine |
Proporciona |
| PeerReference |
Devuelve una JniObjectReference de la instancia de objeto Java ajustada. (Heredado de IJavaPeerable) |
Métodos
| Disposed() |
Se llama cuando se ha eliminado la instancia. (Heredado de IJavaPeerable) |
| DisposeUnlessReferenced() |
Si no hay referencias pendientes a esta instancia, llama a |
| Finalized() |
Se llama cuando se ha finalizado la instancia. (Heredado de IJavaPeerable) |
| SetJniIdentityHashCode(Int32) |
Establezca el valor devuelto por |
| SetJniManagedPeerState(JniManagedPeerStates) |
Proporciona |
| SetPeerReference(JniObjectReference) |
Establezca el valor devuelto por |
| UnregisterFromRuntime() |
Anule el registro de esta instancia para que el tiempo de ejecución no lo devuelva de invocaciones futuras Java.Interop.JniRuntime+JniValueManager.PeekValue . (Heredado de IJavaPeerable) |
| Write(INode, ILSOutput) |
Serialice el nodo especificado como se ha descrito anteriormente en la descripción general de la |
| WriteToString(INode) |
Serialice el nodo especificado como se ha descrito anteriormente en la descripción general de la |
| WriteToURI(INode, String) |
Método de conveniencia que actúa como si |
Métodos de extensión
| JavaCast<TResult>(IJavaObject) |
Realiza una conversión de tipos comprobados en tiempo de ejecución de Android. |
| JavaCast<TResult>(IJavaObject) |
Proporciona |
| GetJniTypeName(IJavaPeerable) |
Proporciona |
| WriteAsync(ILSSerializer, INode, ILSOutput) |
Proporciona |
| WriteToURIAsync(ILSSerializer, INode, String) |
Proporciona |