Lua по сравнению с XML для хранения данных
Многие из нас были ознакомлены в использовании XML для того, чтобы хранить данные. Это - преимущества, и недостатки являются общеизвестными, и я, конечно, не хочу обсуждать их здесь. Однако в проекте я пишу в C++, я также использую Lua. Я был очень удивлен, как хорошо Lua может использоваться, чтобы сохранить и обработать данные. Все же этот аспект Lua менее распознан, по крайней мере, в игровом мире программирования.
Я знаю, что XML имеет, это - преимущества в случаях как передающие данные по Интернету, и в местах, где безопасность играет роль (использование данных, загруженных с сети, например, или загрузки доступных для редактирования пользователем конфигурационных файлов) и наконец в случаях, где те же данные считываются программами в различных языках.
Однако, как только я изучил, как хороший и легкий это должно обработать использование данных Lua (особенно имеющий luabind для поддержки Вас!), я начал задаваться вопросом там, какая-либо причина состоит в том, чтобы использовать XML, чтобы хранить игровые данные, если мы уже используем Lua так или иначе?
Снежная буря, при использовании Lua для сценариев UI, все еще хранит расположение в XML. Причина - что-то, что является только связанным UI?
Каковы недостатки использования Lua как язык хранения данных?
9 ответов
Возможно, это не тот ответ, которого вы ожидали, но он может помочь вам принять решение.
Blizzard (WoW) использует XML для определения пользовательского интерфейса. Это похоже на XAML на C#, просто гораздо менее мощный, и большинство аддонов просто используют XML для загрузки аддона, а затем строят UI в коде lua.
Также WoW фактически хранит аддон "Saved Variables" в .lua файлах.
На мой взгляд, это не так уж и важно. Выбирайте то, что вам нравится и что легко использовать для тех, кто собирается расширить ваш движок.
Хорошая вещь в XML заключается в том, что существует множество инструментов и кода, уже написанных для тестирования, написания и разбора XML, что означает, что это может сэкономить вам некоторое время. Например Схема XML очень полезна для проверки пользовательских файлов (безопасность - это только побочный эффект, хорошо то, что если она пройдет через вашу схему, то данные, скорее всего, будут 100% безопасны и готовы к подключению к вашему движку), и там уже написано достаточно много валидаторов, которые вы можете использовать.
Снова, некоторые пользователи боятся файлов XML (даже если они очень читабельны, может быть, слишком читабельны) и предпочитают что-то "более простое". Если это просто для хранения (а не для настройки), то в большинстве случаев редактировать эти файлы все равно никто не будет. XML также займет больше места, чем lua var dump (не имеет значения, если только у вас не много данных).
Не думаю, что здесь можно ошибиться. Blizzard использует lua для хранения данных, и мне очень нравится, как это работает
.Спасибо за ваши ответы! Я возьму на себя смелость подытожить пункты для будущих справок.
Недостатки использования Lua для хранения данных по сравнению с XML
- Безопасность как при передаче данных, так и при их хранении, особенно при получении данных из неизвестного источника
- Портативность и простота доступа к данным другими инструментами
- Менее полезные существующие инструменты, такие как валидаторы XML Schema
- Меньше поддержки при разборе данных
- Проблемы с круговыми ссылками
- Менее ограничительные -- сложнее обеспечить соблюдение надлежащих конвенций, использование и дизайн
Преимущества использования Lua для хранения данных, по сравнению с XML
- Использование одного языка и для скриптинга, и для данных (нет необходимости в отдельных файлах, нет необходимости в особых случаях при загрузке)
- Меньше кода и зависимостей из-за использования одного языка
- Более многословный и (возможно) более читабельный для человека
- Гораздо более гибкий, и расширяемый (это все-таки язык программирования)
- Данные "выполняются" и могут быть доступны при необходимости, так как находятся в виртуальной машине
- занимает меньше места, особенно если скомпилированы в байткод
Если я что-то пропустил в первом списке, пожалуйста, укажите на это!
Если не безопасность, то считайте, что дисциплина - это дисциплина. Если в файле данных имеется полный набор LUA, то остается возможность добавить логику или поведение в файл данных. Наличие этих сущностей, являющихся как данными, так и поведением, может усложнить управление большим проектом: Допустим, вы построили, например, игровой движок, и целую игру. Теперь Вы хотите удалить весь специфический контент, повторно использовать игровой движок, чтобы сделать новую игру. Если содержимое/данные безопасно отделены от поведения, то это довольно просто. Если в какой-то момент вы решили, что лучшим решением проблемы является хранение функции в виде данных, то все становится немного странно.
Вы, возможно, сможете применить такую дисциплину в своей команде, но если такая возможность есть у пользователя, то она будет использована. Потом вы решаете изменить формат данных, и эти пользовательские расширения не переносятся, потому что они включают lua, который не является данными!
С такими сущностями сложнее манипулировать программно в массовом масштабе.
И есть все остальные проблемы, которые возникают из-за некорректного разделения проблем. Если вы позволите вашим данным и коду смешиваться, все это, вероятно, все еще будет работать, но чем больше запутанных вещей будет становиться, тем сложнее будет их рассуждать.
.Луа - главная победа в хранении данных. Удобный, быстрый и легко конвертируемый в другие форматы при необходимости. (Конвертируемость предполагает, что ваши данные являются представляемыми в других форматах, что если они представляются в XML, то будут.)
Каковы недостатки использования Lua в качестве языка хранения данных?
Я знаю о двух недостатках, значение которых зависит от вашего приложения:
Если у вас есть таблицы Lua, содержащие круговые ссылки, например,
t1.next == t2иt2.prev = t1, то процесс записи ваших структур Lua на диск становится утомительным, и в результате Lua сложнее прочитать, чем простойreturn. (Со мной такого никогда не случалось, и если ваши данные представлены в XML, Этого с вами не случится.)Если у вас есть лот данных, например, если вы пишете инвертированный индекс всей инструкции к Inform 7, то вы можете столкнуться с ограничениями Lua на количество отчетливых констант, которые могут появляться в блоке. Затем нужно разбить все на несколько блоков или функций или прибегнуть к другим решениям. Эта проблема укусила меня, и это огромная заноза в заднице. Я бы хотел написать общее решение, но я не на 100% уверен, что понимаю ограничения, и я еще не разобрался с ними.
Если ваши данные имеют менее 100 000 числовых и строковых литералов, вам не нужно беспокоиться об этой проблеме.
Если скрипты lua доступны пользователю, то подмножество lua, которое вы используете для спецификации данных, должно быть введено в действие, иначе то, что у вас есть - это не просто язык данных, а дыра в безопасности. Проблема внедрения такого подмножества не является тривиальной.
Вы знаете о json? Возможно, это больше похоже на то, что вам нужно.
здесь есть две реализации: http://json.luaforge.net/
and here http://www.chipmunkav.com/downloads/Json.lua
если json не достаточно мощный, то другой вариант - YAML, суперсеть JSON, хотя я не мог сказать, есть ли какие-нибудь приличные реализации этого в Lua.
.Я бы сказал, что самый большой недостаток в том, что другим инструментам сложнее манипулировать этими данными. Если вы храните данные непосредственно в Lua, то вам нужно написать парсер Lua, чтобы манипулировать этими данными автоматически, в то время как в каждой среде есть парсеры и генераторы XML. Это проблема не только для инструментов на других языках; если вы хотите написать GUI для редактирования вашей конфигурации, есть ли у вас инструменты, которые могут разобрать, изменить и переписать данные конфигурации таким образом, чтобы это не повлияло на слияние в вашей системе управления версиями? Это может быть важно для больших проектов с большим количеством людей, которые могут редактировать конфигурацию одновременно.
Тем не менее, эта же идея привела к JSON, который является подмножеством JavaScript, используемым в качестве формата данных. Но в настоящее время существует множество инструментов, поддерживающих JSON, и, вероятно, не так уж много инструментов, поддерживающих синтаксис Lua.
Другая проблема, которая иногда возникает при наличии вашего кода в качестве вашей конфигурации - это то, что люди начинают писать код для генерации конфигурации или для добавления абстракций к вашему конфигурационному файлу. И тогда любой пользователь, который захочет настроить вашу программу, может оказаться в замешательстве, вынужденный научиться программировать и язык программирования в целом, а не относительно простой язык настройки.
.Обычно я держусь подальше от XML, в основном из-за его многословия. Большую часть времени я использую CSV или SQLite для хранения данных. Я использую скриптовые языки, такие как Lua, Python или Scheme, чтобы предоставить пользователю интерфейс для расширения программного обеспечения.
.Я проделал несколько проектов, которые использовали LUA в качестве языка хранения данных / конфигурации данных
ключевым элементом в решении его использованию было «мы уже используем Lua на этот проект?»
Другое дело в том, что Его портативный в любом месте, где вы можете компилировать переводчик LUA. То же самое на всех платформах - нет специальных библиотек XML
JSON - хорошая альтернатива.
Единственный способ использовать XML в эти дни с аннотированным кодом-геном для серии .NET XML или JAXB).
Единственное, что может работать, это (если мы говорим, что пароли просто хэшируются, без добавления какого-либо вида соли для предотвращения атак воспроизведения, если это так, что вы должны знать соль)кстати, получите инструмент атаки словаря, файлы многих слов, цифр и т.д., затем создайте две строки, одна строка - слово, число (в словаре) другой - это хеш слова, и сравните хеши, если вы его получите...
это единственный способ, не переходя в криптоанализ.
-121--577672- Если вы не возражаете против поплавков, вы можете использовать log (x )/регистрация (2) .
Помните, что виртуальная машина Lua и язык очень гибкие. Можно использовать функциональные среды для реализации любой формы безопасности, а затем использовать политику, чтобы избежать запуска «вредоносного» кода. Просто устраните ВСЕ из среды, с которой вы загружаете () свои данные, и единственная опасная вещь, которую могут сделать ваши «данные» - это запустить цикл и записать ЦП.
Другое дело, что вы всегда можете преобразовать таблицу Lua в XML и наоборот, хотя отображение элементов и атрибутов в таблицы Lua приведет к каким-то странным узорам в таблицах.