¿Se recomienda utilizar algo distinto de XML para mi archivo de configuración?

Estoy diseñando una pequeña herramienta que requeriría un archivo de configuración de algún tipo. El archivo de configuración en mi caso es realmente más una base de datos, pero debe ser ligero, y si es necesario, el usuario final debería encontrarlo fácilmente editable. Sin embargo, también contendrá muchas cosas. (dependiendo de ciertos factores, podría ser 1Mb o más)

Decidí que preferiría usar texto simple, en lugar de intentar usar SQLite o algo así. Sin embargo, con el uso de texto, también tengo que lidiar con la variedad de formatos. Hasta ahora, mis opciones son

• XML
• JSON
• Formato personalizado

Los datos en mi archivo son bastante simples y consisten en la mayoría de las cosas de tipo clave-valor. Entonces, un formato personalizado no sería tan difícil ... pero prefiero no tener que preocuparme por escribir el soporte para él. Nunca he visto JSON utilizado para archivos de configuración. Y XML aumentaría el tamaño del archivo sustancialmente, creo. (También simplemente no me gusta XML en general).

¿Qué debo hacer en este caso?

Factores a considerar:

• Este archivo de configuración se puede cargar en un servicio web (por lo que el tamaño es importante)
• Los usuarios deben poder editarlo a mano si es necesario (la facilidad de edición y lectura es importante)
• Debe poder generar y procesar automáticamente (la velocidad no importa mucho, pero no es demasiado lenta)
• Las "claves" y los "valores" son cadenas simples, pero deben escaparse porque pueden contener cualquier cosa. (Unicode y escapar tiene que funcionar fácilmente)
• Múltiples archivos de configuración. Básicamente, cada archivo de configuración está vinculado a un "proyecto"

Creo que YAML es la mejor opción para su caso. A mi entender, YAML es el formato estándar de facto para los archivos de configuración que deben editarse a mano. Muchos lenguajes de programación tienen una biblioteca para leer y / o escribir YAML. JSON está estrechamente relacionado con YAML, pero es un poco menos fácil de escribir que YAML, y se usa más para la comunicación entre el servidor web y el programa cliente.

Si usa JSON, las personas no podrán comentar partes de la configuración para probar cosas diferentes. Para mí, eso es un factor decisivo.

También significa que no puede proporcionar un archivo de configuración de muestra bien comentado para que los usuarios lo personalicen.

XML es estándar y si puede proporcionar un esquema, sus usuarios se lo agradecerán.

Después de ver sus requisitos y ver que no le gusta XML, le aconsejaría que vaya con JSON. Debo admitir que solo he tratado con XML y JSON, por lo que no puedo hablar de ningún otro formato de configuración común.

JSON es realmente fácil de escribir, y si está formateado correctamente, fácil de leer. Google simplemente AMA a JSON para el uso de la configuración en sus herramientas. Además, JavaScript puede convertirlo en objetos de forma nativa.

Un archivo de "propiedades" es bueno para clave / valor ya que el formato en sí mismo es clave / valor. Es simplemente 1 línea por clave / valor. El primer signo = en la línea divide la clave y el valor.

Será más pequeño que un archivo XML equivalente ya que el único formato es el separador "=" y el carácter de nueva línea. En un archivo XML, el marcado podría ocupar tanto espacio como el contenido en sí. Literalmente podría significar la diferencia entre una carga de 1 MB y 2 MB. La compresión ayuda, pero aún está por delante si comienza con poco.

Las bibliotecas existentes pueden manejar el acceso a los archivos de propiedades. Pero es tan trivial que puedes hacer el tuyo en unos minutos. Campanas y silbatos en menos de una hora.

IP=11.22.33.44
BuildNumber=5.02.004
MaxFrameRate=50

Algunas buenas respuestas aquí ya. Pero si estuviera en su lugar, antes de lanzar XML por la borda, consideraría los siguientes puntos:

• XML es muy compatible con .NET Framework y herramientas de terceros, para JSON deberá elegir una biblioteca de terceros y ver si cumple con todos sus requisitos.

• Si necesita edición manual solo en algunos casos excepcionales, XML probablemente sufrirá sus necesidades. Si hay mucha edición por hacer y su lista de opciones de configuración tiene una complejidad particular, sus usuarios probablemente necesiten algún tipo de aplicación de configuración / opción basada en el diálogo, lo que significa que no importa si el formato XML subyacente es 100 % fácil de usar. Si no desea escribir tal cosa, al menos puede recomendar algún tipo de editor XML a sus usuarios. Herramientas como el bloc de notas XML o las herramientas XML para Notepad ++ funcionan bien para muchas personas.

• Supongo que las posibilidades de que sus usuarios finales hayan visto algún tipo de XML antes son mayores que las de haber visto JSON antes, lo que les facilitará un poco su comprensión (si es que realmente tienen que hacerlo).

• JSON no admite comentarios, lo que puede dificultar la edición manual

• Si el tamaño realmente es un problema para cargar los datos en un servicio web, considere usar la compresión de datos

En realidad, si piensa en estos puntos, y no quiere usar XML de todos modos, entonces vaya con JSON. El uso de XML o JSON ya le proporciona formas estándar de escapar de cadenas, formas estándar de extender su estructura de configuración posteriormente y bibliotecas listas para leer y escribir esos formatos; no hay necesidad de reinventar la rueda con ningún "formato personalizado".

En lo que respecta a los archivos de configuración, "1Mb o más" es ciertamente grande, y la necesidad de escapar de las cadenas y mantener muchas citas coincidentes no juega bien con los humanos. Es por eso que para los archivos de configuración grandes que necesitan ser mantenidos por humanos, definitivamente debería considerar definir un formato personalizado y construir un analizador personalizado. Aquí hay un artículo sobre el tema de los humanos que tienen que escribir XML: los humanos no deberían tener que asimilar XML .

Cuando los analizadores y generadores de analizadores estaban en su infancia, se podía argumentar por no construir uno personalizado diciendo que construir un lenguaje personalizado es demasiado complejo. Ahora que los generadores de analizadores excelentes y muy simples han madurado, no hay excusa: puede crear un analizador personalizado en cuestión de unas pocas horas, a la par del tiempo que le tomaría construir un analizador para un lenguaje basado en XML ^* .

Aquí hay un pequeño tutorial que explica el proceso de creación de un analizador personalizado con ANTLR . Está en Java, pero ANTLR también admite C #.

JSON es una buena opción por su flexibilidad, facilidad de lectura y edición fuera de su programa, y ​​la amplia disponibilidad de bibliotecas de análisis para admitirlo. Es compatible con la jerarquía, se presta a una compatibilidad simple hacia adelante / hacia atrás que un archivo que simplemente guarda datos en secuencia no lo hace. Creo que también tiene técnicas fáciles para convertir entre clases Java y datos de archivos y luego viceversa. Mucha gente conoce y ha codificado este formato, y el formato es importante para otros programas con los que probablemente necesitará trabajar en el futuro.

Muchos sistemas se basaban en el formato .ini, y son bastante fáciles de analizar si estaba escribiendo un analizador desde cero.

csv puede codificarse rápidamente y funciona con muy poca sobrecarga, pero tiene problemas de flexibilidad, compatibilidad hacia adelante / hacia atrás.

Usar el registro era una práctica común en Windows.

El uso de cookies es común para el desarrollo web.

Para una función de utilidad, tal vez solo use texto de formato libre que coincida con sus opciones de línea de comando, solo léalo y haga una matriz de cadenas argv a partir de él.

No uses XML.

XML es un lenguaje de marcado. Cuando se utiliza para el lenguaje de serialización o configuración, XML tiene un problema fundamental, es decir, que los atributos y el contenido de texto de un elemento pueden describir lo mismo. Debe decidir entre atributos y contenido de texto. Además, XML es innecesariamente detallado, por ejemplo, necesita especificar el nombre del elemento dos veces (abrir, cerrar).

Use XML para lo que significa: como lenguaje de marcado. Los archivos de configuración no requieren un lenguaje de marcado.

No uses JSON tampoco.

JSON es maravilloso como formato de serialización de datos. Sin embargo, JSON carece de comentarios. Eso, para mí, es un factor decisivo. Además, debes escapar de todas las ocurrencias del "personaje.

No uses INI.

Los archivos INI tienen un problema fundamental: carecen de estructuras de datos anidadas. La única noción de anidamiento es que una etiqueta puede tener varios atributos. Eso es solo 1 nivel de anidamiento. En casos de uso de la vida real, he encontrado esta limitación extremadamente molesta. He trabajado como parte de un proyecto donde la configuración estaba en archivos INI, y los dolores son mayores.

Use un lenguaje personalizado si es posible.

Si tiene acceso a herramientas generadoras de analizadores como Lex y Yacc, utilice un lenguaje personalizado. No estoy seguro de cuál es el estado de los generadores de analizadores en .NET, pero para el código C, elegiría Lex y Yacc. La curva de aprendizaje al principio puede ser un poco empinada (Lex y Yacc no son las herramientas más fáciles de usar), pero el tiempo invertido para aprender vale la pena.

Si el lenguaje personalizado no es factible, use YAML.

Y AML, como dice el nombre, un In't m arkup l anguage. Es un lenguaje de serialización que se debe a sus propiedades aceptables para los archivos de configuración, ya que admite comentarios. YAML no es innecesariamente detallado como XML: no requiere especificar el nombre del elemento dos veces (abrir, cerrar). YAML no tiene el problema de atributo vs. contenido de texto de XML.

Considere pro.per.ty = value también.

Si desea una configuración similar a INI, donde se admite el anidamiento, considere un formato que consta de pro.per.ty=valuepares (pares clave-valor), donde la clave puede tener varios niveles anidados, utilizando el .carácter como separador.