Подтвердить что ты не робот

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

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

4b9b3361

ОТВЕТЫ

Ответ 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 предоставляет несколько интересных функций, таких как селектор).

Ответ 2

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

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

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

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

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

Edit

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

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

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

Ответ 3

  • XML легко разбирается. На большинстве языков доступно несколько популярных, легких, функциональных и/или бесплатных библиотек анализа XML.
  • XML легко читается. Это очень удобочитаемый язык разметки, поэтому людям легко писать, а также писать на компьютерах.
  • Хорошо указан XML. Каждый и его собака знают, как писать приличный XML, поэтому нет никакой путаницы в синтаксисе.
  • XML популярен. Где-то по пути некоторые важные люди ™ начали подталкивать идею о том, что XML является "будущим", и многие покупают его.
  • XML - двунаправленный формат. Это пробелы, комментарии и порядок сохраняются. Вы можете программно загружать, изменять, а затем сохранять его, сохраняя форматирование. Это важно для инструментов, которые пользователи могут использовать для настройки своих приложений. Это одна из причин, по которой XML первоначально взлетел (мир стал более техническим, так что это меньше необходимо).
  • XML имеет необязательную проверку схемы. Важно для инструментов и сложных форматов конфигурации.
  • XML имеет пространства имен. Это позволяет встраивать другие конфигурации или аннотации без эффекта синтаксического анализа. В других конфигурационных форматах это обычно делается как с специальными комментариями хака или изменением имени свойства.

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

Ответ 4

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

Изменить: я не понимал, что мой ответ был настолько расплывчатым, пока комментатор не попросил определение предприятия. Цитирование Wikipedia:

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

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

Ответ 5

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/

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Вот несколько исторических причин:

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

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

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