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

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

44
configuration-files methodology xml

12 ответов

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

большинство альтернатив (JSON, YAML, INI-файлы) являются легче для разбора, чем XML.

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

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

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

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

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

Я слышал, что люди говорят, что "кто-то" может взломать ваше приложение через файл конфигурации. Кто этот "кто-то"? Сисадмин? В дБА? Застройщик? Не так много таинственных "кто-то" с доступом к файлам конфигурации.

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

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

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

30

потому что XML звучит круто и предприимчиво.

Edit: я не понимал, что мой ответ был настолько расплывчатым, пока комментатор не запросил определение enterprisey. Ссылаясь На Википедию:

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

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

24

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/

13

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

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

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

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, но больше реализаций приветствуются. :). проверьте сайт для получения дополнительной информации (я охватил большую часть его, но API Java предоставляет несколько интересных функций, таких как селекторы)

9

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

8

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

3

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

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

2

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

  • W3C перешел от создания инструментов в Perl к Java
  • Apache foundation перешел от создания инструментов в Perl к Java
  • Java имеет много XML API
  • конфигурация поэтому может быть выполнена в Java
  • конфигурация через XML и свойства файлов для разработчиков не Java

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

1

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

0

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

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

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

0

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

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

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

0