Estoy exportando bases de datos grandes en formato xml. Esta información XML debe comprimirse en el formato más pequeño posible. He escuchado mucho acerca de Efficient XML (EXI) y me preguntaba si hubo una implementación de .NET para poder llamar desde el código ....NET Implementación de XML eficiente
¿Alguien tiene un ejemplo de esto ya que los recursos en línea parecen ser un bit sparse ...
Tal implementación existe. La compañía que creó un predecesor del formato de intercambio XML eficiente (AgileDelta) offers an Efficient XML library, que incluye la versión .Net. Aunque no parecen publicar el precio.
The official EXI site no incluye ninguna otra implementación de .Net.
Nagasena tiene tanto .Net (escrito en C#) como la implementación de Java de la especificación EXI. –
Resulta que Microsoft creó su propio formato XML/codificación binario llamado MC-NBFX (pegadizo eh). Esto es parte del framework .NET y WCF desde .NET 3.0. Para más información ver:
Otra opción es ejecutar una aplicación Java a través IKVM para producir un ensamblado de .NET. Abiertas las implementaciones de Java fuente que pude encontrar son:
Daré un +1 por la respuesta informativa. Pero le gusta decir que adherirse a MC-NBFX es el único binario XML disponible que no lo es. Ya sabes, pero la respuesta es un poco confusa sobre eso. –
Esa entrada del blog "WSF Binary XML and dictionaries" tiene información realmente útil que no conocía. ¡Gracias por compartir eso! –
¿Hay alguna razón desea que el formato más pequeño posible? XML no está realmente diseñado para la optimización de la compresión. La respuesta de @Svick es de facto por ahora si lo que quieres son archivos de fácil acceso.
se puede encontrar una gran cantidad de lo que están pidiendo aquí: Best compression algorithm for XML?
EXI es grande si lo desea se archiva datos de los que se accederá con regularidad. De lo contrario, si su objetivo es archivar a largo plazo, simplemente use una utilidad de compresión. BESO.
dice que quiere eficiencia. Piensa en el texto XML. Necesitará convertir digamos un número entero en representación decimal ASCII, lo que consume recursos, antes de eso, ejecutará un compresor zip en todo el archivo nuevamente, reduciendo la eficiencia. El XML binario puede ser eficiente y hay algunas implementaciones de él. Hay formatos más efectivos, pero está pidiendo XML, así que este es el camino. –
Mi problema principal con los formatos binarios es que pueden no ser compatibles a largo plazo. Parece que quiere archivar datos pero aún así mantenerlos accesibles. Cómo debe archivarlo depende de la frecuencia con la que espera acceder a él. No estoy en desacuerdo con el hecho de que el XML binario ofrece algunas ventajas de eficiencia (se cubrió bien en otros comentarios). Estoy más preocupado acerca de por qué quiere hacer lo que está haciendo. Creo que comprimir las exportaciones de bases de datos como XML ofrece una solución de almacenamiento a largo plazo que no será propensa a cambios en los estándares una década más tarde, lo que puede valer la ineficiencia añadida. – VoteCoffee
XML binario es eficiente ya sea en el poder de procesamiento y el tamaño no se basa en la opinión es un hecho. Al usar source, _en términos de tamaño, puede reducir el tamaño en un 80% _ (http://en.wikipedia.org/wiki/Fast_Infoset). De todos modos, sé que te refieres a que quiere un intercambio a largo plazo, pero hay estándares que definen algunos XML binarios, el uso de uno u otro pensamiento se comprometerá, y luego se basará en la opinión en algún punto. –
XML binario es el camino a seguir (y hay una cierta implementación) si necesita pegar al estándar XML.
JSON, aunque no sea XML, se perderá con los números. Ex 32 bits unsigned int El valor máximo será representado por 10 bytes en JSON. En casi todos los formatos binarios esto será de 4 bytes. Esto se aplicará a la fecha/hora y así sucesivamente.
Cualquier XML binario decente que tenga tipos de elemento/atributo estándar debería dar un tamaño y una eficacia de procesamiento mucho mejores. Si puede reutilizar etiquetas, como un diccionario en un archivo comprimido, como lo está exportando de una tabla, también será una buena característica.
Nagasena tiene tanto .Net (escrito en C#) como implementaciones de Java de la especificación EXI.
¡Pero es tan críptico! Y carece de C# doc/tuto. Pude (casi a ciegas) encontrar la forma de codificar XML a EXI, pero dejé de recuperar XML después de que el ensamblado me arrojara una excepción de referencia nula no controlada sin motivo aparente. – Jerther
Eso no suena bien. Bueno, de todos modos, aquí está el [enlace directo] (https://sourceforge.net/projects/openexi/) al proyecto de código abierto real. – James
Parece que controla tanto el código que comprime el XML como el código que lo descomprime más adelante. ¿No sería mejor si lo "comprimiste" guardándolo en algún formato que no sea XML y luego lo "descomprima" convirtiéndolo a XML? – svick
Me gustaría algo como JSON para ahorrar en esos bytes. Dudo que la codificación de la información ayude mucho? –
@PatrickMagee JSON guardará solo en etiquetas de cotizaciones y etiquetas de cierre, además de no ser parte del estándar XML. Esto está lejos de cualquier formato binario, mi respuesta tiene más información. –