XML для файлов конфигурации, почему?

Question

Почему так много проектов используют XML для файлов конфигурации?

Answer 1

Спасибо за ваши ответы. Этот вопрос, как наивно, как это может показаться на первый взгляд, не был таким наивным :)

Лично мне не нравятся XML для конфигурационных файлов, я думаю, что людям трудно читать и изменять, а компьютерам сложно для синтаксического анализа, потому что он настолько общий и мощный.

Файлы INI или файлы на основе Java отлично подходят только для самых простых приложений, требующих вложенности. общие решения, чтобы добавить вложение в эти форматы выглядеть следующим образом:

level1.key1=value 
level1.key2=value 
level2.key1=value 

не очень красиво, много избыточности и трудно перемещать вещи между узлами.

JSON - не плохой язык, но он разработан для простого анализа компьютеров (это действительный JavaScript), поэтому он не дико используется для файлов конфигурации.

JSON выглядит следующим образом:

{"menu": { 
    "id": "file", 
    "value": "File", 
    "popup": { 
    "menuitem": [ 
     {"value": "New", "onclick": "CreateNewDoc()"}, 
     {"value": "Open", "onclick": "OpenDoc()"}, 
     {"value": "Close", "onclick": "CloseDoc()"} 
    ] 
    } 
}} 

На мой взгляд, это слишком завален запятые и кавычки.

YAML хорош для конфигурационных файлов, вот пример:

invoice: 34843 
date : 2001-01-23 
bill-to: &id001 
    given : Chris 
    family : Dumars 

однако, мне не нравится его синтаксис слишком много, и я думаю, что с помощью пробелов для определения областей сделать вещи немного хрупкими (подумайте о вставке блока в другой уровень гнездования).

Несколько дней назад я начал писать свой собственный язык для конфигурационного файла, я его окрестил Swush.

Вот несколько образцов: как простых пар ключ-значение:

key:value 
key:value2 
key1:value3 

или как более сложный и прокомментированы

server{ 
    connector{ 
     protocol : http // HTTP or BlahTP 
     port : 8080  # server port 
     host : localhost /* server host name*/ 
    } 

    log{ 
     output{ 
      file : /var/log/server.log 
      format : %t%s 
     } 
    } 
} 

Swush поддерживает строки в простой форме выше, или в кавычках - что позволяет использовать пробелы и даже новые строки внутри строк. Я собираюсь добавить массивы в ближайшее время, нечто вроде:

name [1 2 b c "Delta force"] 

Существует реализация Java, но более реализаций приветствуются. :). проверить сайт для получения дополнительной информации (я рассмотрел большую часть этого, но Java API предоставляет несколько интересных функций, таких как селекторы)

Answer 2

XML - это хорошо разработанный и принятый стандарт, который упрощает чтение и понимание, чем проприетарные форматы конфигурации.

Кроме того, стоит понимать, что сериализация XML является распространенным инструментом, доступным на большинстве языков, что делает данные об объектах сэкономить очень просто для разработчиков. Зачем строить свой собственный способ сохранения иерархии сложных данных, когда кто-то еще выполнил эту работу за вас?

.NET: http://msdn.microsoft.com/en-us/library/system.xml.serialization.aspx

PHP: http://us.php.net/serialize

Python: http://docs.python.org/library/pickle.html

Java: http://java.sun.com/developer/technicalArticles/Programming/serialization/

Answer 3

Поскольку разборе XML относительно легко, и если ваша схема ясно указанная, любая утилита может легко читать и писать информацию в к нему.

Answer 4

Поскольку XML звучит круто и предприимчиво.

Редактировать: Я не понимал, что мой ответ был настолько расплывчатым, пока комментатор не попросил определение enterpriseisey. Citing Wikipedia:

[...] термин «enterprisey» намерен выйти за пределы концерна «избыточна для небольших организаций», подразумевает программное обеспечение является слишком сложным, даже для крупных организаций и простых, проверенных решений доступный.

Я хочу сказать, что XML является модным словом и, как таковое, используется чрезмерно. Несмотря на другие мнения, XML не просто разобрать (просто посмотрите на libxml2, его исходный пакет gzipped в настоящее время превышает 3 МБ). Из-за количества избыточности также неприятно писать вручную. Например, Wikipedia lists XML configuration как одна из причин снижения популярности jabberd в пользу других реализаций.

Answer 5

Еще один момент, если у вас есть файл XSD (файл схемы) для описания вашего файла конфигурации, для вашего приложения тривиально проверить файл конфигурации.

Answer 6

1. XML легко разбирается. В большинстве языков доступно несколько популярных, легких, функциональных и/или бесплатных библиотек анализа XML.
2. XML легко читается. Это очень удобочитаемый язык разметки, поэтому людям легко писать, а также писать на компьютерах.
3. XML хорошо указан. Каждый и его собака знают, как писать приличный XML, поэтому нет никакой путаницы в синтаксисе.
4. XML является популярным. Где-то в пути некоторые важные люди ™ начали подталкивать идею о том, что XML является «будущим», и многие покупают его.
5. XML - двунаправленный формат. Это пробелы, комментарии и порядок сохраняются. Вы можете программно загружать, изменять, а затем сохранять его, сохраняя форматирование. Это важно для инструментов, которые пользователи могут использовать для настройки своих приложений. Это одна из причин, по которой XML первоначально взлетел (мир стал более техническим, так что это меньше нужно).
6. XML имеет факультативную проверку схемы. Важно для инструментов и сложных форматов конфигурации.
7. В XML есть пространства имен. Это позволяет встраивать другие конфигурации или аннотации без эффекта синтаксического анализа. В других конфигурационных форматах это обычно делается как с специальными комментариями или описанием свойств.

В качестве побочного примечания я не пытаюсь защитить XML. Он использует его, и я буду использовать его в проекте, когда вернусь к этому. Во многих случаях, хотя и особенно в файлах конфигурации, единственное преимущество, которое он имеет, это стандартизованный формат, и я думаю, что это намного перевешивается многочисленными недостатками (т. Е. Слишком многословными). Однако мои личные предпочтения не имеют значения - я просто отвечал, почему некоторые люди могут использовать XML в качестве формата файла конфигурации. Я лично никогда не буду.

Answer 7

Ну, XML - это спецификация общего назначения, которая может содержать описания, вложенную информацию и данные о чем-то. И есть много API-интерфейсов и программного обеспечения, которые могут его проанализировать и прочитать.

Таким образом, очень легко описать что-то формально, что известно кросс-платформой и приложениями.

Answer 8

Его поскольку XML позволяет вам в основном создать собственную семантическую разметку, которая может быть прочитана парсером, созданным практически на любом языке. Дополнительным преимуществом является то, что файл конфигурации, написанный в XML, можно использовать в проектах, в которых вы используете два или более языков. ЕСЛИ вы должны были создать файл конфигурации, где все было определено как переменные для определенного языка, оно, очевидно, будет работать только на этом языке.

Answer 9

Это важный вопрос.

Большинство альтернатив (файлы JSON, YAML, INI) являются проще для анализа XML.

Кроме того, в таких языках, как Python - где все является источником, проще просто разместить свою конфигурацию в четко обозначенном модуле Python.

Однако некоторые люди скажут, что XML имеет некоторое преимущество перед JSON или Python.

Что важно в XML, так это то, что «универсальность» синтаксиса XML на самом деле не очень подходит при написании файла конфигурации, специфичного для приложения. Поскольку переносимость файла конфигурации не имеет значения, некоторые пользователи Python записывают свои файлы конфигурации в Python.

---

Редактировать

Безопасность конфигурационного файла не имеет значения. «Конфигурация Python в Python - это риск безопасности», похоже, игнорирует тот факт, что Python уже установлен и запущен как источник. Зачем обрабатывать сложный хак в файле конфигурации, когда у вас есть источник? Просто взломайте источник.

Я слышал, как люди говорили, что «кто-то» может взломать ваше приложение через файл конфигурации. Кто этот «кто-то»? Системный администратор? DBA? Разработчик? Не так много таинственных «чей-то» с доступом к файлам конфигурации.

И любой, кто мог взломать конфигурационный файл Python для гнусных целей, возможно, установил кейлогеры, поддельные сертификаты или другие более серьезные угрозы.

Answer 10

Главное преимущество XML и причина, по которой это так популярно, - это то, что оно популярно в мире Java и поэтому все корпоративные приложения, написанные в java, используют его, а также потому, что веб-сервисы и мыло основаны на xml, и они широко используются в корпоративных приложениях.

И до сих пор JSON и все другие форматы не так хорошо поддерживаются в отрасли, за исключением приложений ajax. Кроме того, JSON не имеет языка схемы или определенного parsing api, как XML.

Даже если грубо говоря, JSON не нуждается в тоннах материала xml, по крайней мере, не так, и я говорю в веб-сервисах, когда я говорю это ...

Answer 11

Вот некоторые исторические причины:

• W3C по переехавшие из строительных инструментов в Perl для Java
• Фонд Apache переехавшие из строительных инструментов в Perl для Java
• Java имеет много XML APIs
• Конфигурация может быть выполнена в Java
• Конфигурация через XML и properties files предназначена для разработчиков, отличных от Java

JTidy Конфигурация конфигурации tidy является ярким примером этого.

Answer 12

Одна из причин, которая не была указана в других ответах, - это кодировка Unicode/text/name. Нужна ли китайская строка в файле? Нет проблем. Это может показаться тривиальным, но когда XML был введен, это не так. Очевидно, что нет в файлах INI.

Другое дело - это первое, что дало нам возможность иметь структурированные данные со списками, словарями или любым другим, что вы хотите, который одновременно обрабатывается машиной и человеком.

У этого есть недостатки, но что еще вы могли бы использовать? Ямль выглядит великолепно, но я боюсь представить его в проектах, над которыми я работаю, потому что я просто вижу в своем воображении все эти проблемы с людьми, которые помещают пробел в неправильное место или слияние инструментов, не заботящихся о них.