Xml может быть сжат с </> для окончания элементов?
Я получил сообщение об ошибке: NotSupportedException: этот поток не поддерживает операции поиска.
почему бы не упростить получение изображения, если вы хотите получить байтовый массив:
byte[] imageBytes
using (var webClient = new WebClient()) {
imageBytes = webClient.DownloadData("http://yourimage");
}
14 ответов
Это не допустимый XML. Закрывающие тэги нужно назвать. Это потенциально подвержено ошибкам иначе, и откровенно я думаю, что это было бы менее читаемо Ваш путь.
В отношении Вашего разъяснения об этом являющемся нестандартным нарушением стандарта XML для сохранения несколько байтов это - невероятно плохая идея по нескольким причинам:
- Это нестандартно и возможно должно будет поддерживаться далеко в будущем;
- Стандарты существуют по причине. Стандарты и конвенции имеют много силы и наличия "пользовательского XML" разряды там с графическими дизайнерами Башни Слоновой кости, которые вынуждают программистов записать замену пользовательской кнопки, потому что стандартный не может сделать, любое странное, замечательное и запутывающее поведение было выдумано;
- Сжатие Gzip является легким и намного более эффективным и не повредит стандарты. Если Вы видите gzip поток октета, существует не принятие его для XML. Настоящая проблема с краткой схемой, которую Вы имеете, состоит в том, что она все еще имеет наверху, таким образом, некоторый плохой не подозревающий синтаксический анализатор может сделать ошибку размышления ее допустимого и разбомбить с другой, вводящей в заблуждение ошибкой;
- Теория информации: сжатие работает путем удаления дублирования информации. Если Вы делаете это вручную, это делает gzip сжатие не более эффективным, потому что тот же объем информации представлен;
- Существуют значительные издержки при преобразовании документов и из этой схемы. Это не может быть сделано со стандартным синтаксическим анализатором XML, таким образом, необходимо было бы эффективно записать собственный синтаксический анализатор XML и outputter, который понимает эту схему (на самом деле, преобразование в этот формат может быть сделано с синтаксическим анализатором; возвращение его является более трудным), который является большой работой (и большим количеством ошибок).
При необходимости в лучшем сжатии и более легком парсинге можно попытаться использовать атрибуты XML:
<person firstname="Joe" lastname="Plumber" />
Если бы Вы записали стандартную программу сжатия, которая сделала это, то да, Вы могли сжать поток и восстановить его в другом конце.
Причины это не сделано:
- намного лучше схемы сжатия агностика XML уже существуют (с точки зрения степени сжатия, и вероятно с точки зрения ЦП и пространства - определенный документ UTF-8 на 7 Н получил бы 14%-е сжатие, но потребовал бы, чтобы пространство байтов по крайней мере на 2 Н распаковало, а не постоянное пространство, требуемое большинством алгоритмов распаковки.
- намного лучше XML осведомленные схемы сжатия уже существуют (Google 'двоичный файл xml'). Для схемы осведомленное сжатие схемы на основе ASN.1 дают намного лучше, чем сокращение размера, посвященного указанию на тип элемента наполовину.
- декомпрессор должен проанализировать нестандартный XML и сохранить стопку открытых тегов, с которыми он встретился. Таким образом, если Вы не включаете его вместо синтаксического анализатора, Вы удвоили стоимость парсинга. При включении его вместо синтаксического анализатора Вы смешиваете различные слои, который склонен вызвать беспорядок в какой-то момент
Как Вы говорите, это не XML, итак, почему заставляют его даже быть похожим на XML? Вы уже потеряли способность использовать любые синтаксические анализаторы XML или инструменты. Я был бы также
Если размер данных является какой-либо проблемой вообще, XML не для Вас.
То, что Вы описываете, является SGML, который использует </> закончить ближайший предыдущий непустой тег.
Есть ли любая причина почему
Отвечая на Ваш вопрос философски, SGML действительно позволял </> близкие теги. Были дебаты о разрешении этого в стандарт XML. Обоснование для отклонения его состояло в том, что исключение имен от конечных тэгов будет иногда приводить к меньшему количеству читаемого XML. Так, это - "причина почему".
Трудно разбить уровни сжатия существующего текста, но одним преимуществом Вашей схемы "сжатия" является XML, остается человекочитаемым на проводе. Другое преимущество состоит в том, что, если необходимо ввести XML вручную (например, для тестирования), это - (незначительное) удобство не должным быть закрыть конечные тэги. Таким образом, это более человеческое перезаписываемый, чем стандартный XML. Я говорю "незначительный", потому что большинство редакторов сделает строковое завершение для Вас (например, ^n и ^p в энергии).
Разделять близкие теги: самый простой должен использовать что-то вроде этого: s_</[a-zA-Z0-9_$]+>_</>_ (это не право QName regex, но Вы получаете идею).
Добавить их назад: Вам нужен специальный синтаксический анализатор, потому что SAX и другие синтаксические анализаторы XML не распознают это (поскольку это не "XML"). Но (самый простой) парсинг просто должен распознать открытые имена тега и закрыть имена тега.
have a stack.
scan the XML, and output it, as-is.
if you recognize an open tag, push its name.
if you recognize close tag, pop to get its name, and
insert that in the output (you can do this even when there is a proper close tag).
BTW (в ответ на комментарий выше), это работает, потому что в XML близкий тег может только когда-либо соответствовать новому открытому тегу. То же как вложенные круглые скобки.
Однако я думаю, что Вы правы, что кто-то уже, конечно, сделал это. Возможно, проверьте репозитории Perl или Python?
Править: Можно далее опустить запаздывать </>, таким образом, Ваш пример становится (когда синтаксический анализатор видит EOF, он добавляет близкие теги для того, что оставляют на стеке):
<person>
<firstname>Joe</>
<lastname>Plumber
Даже если бы это было возможно, то могло бы только занять больше времени проанализировать, потому что теперь синтаксический анализатор должен разработать то, что закрывается и должно будет продолжать проверять, корректно ли это.
Если Вы хотите сжатие, XML высоко gzip'able.
Извините, не в спецификации. Если у Вас есть большой XML-файл, Вы лучше сжимаетесь через zip, gzip и такой.
Можно быть интересно читать о различных форматах тега в SGML. Например, следующим мог быть допустимый SGML:
<p/This paragraph contains a <em/bold/ word./
К счастью, разработчики XML приняли решение опустить эту конкретную главу безумия.
Есть ли какая-либо причина, Вы не используете YAML или JSON?
Не используя gzip или ничто как этот, я просто заменил бы каждый тег более коротким tagname прежде, чем отправить и перед использованием xml на конце получения. Таким образом Вы получили бы что-то вроде этого:
<a>
<b>Joe</b>
<c>Plumber</c>
</a>
Создание его очень простой в использовании любой стандартный синтаксический анализатор для итерации через все узлы и замена nodeNames соответственно.
Да, xml является видом og тяжелый формат. Но это имеет определенные преимущества.
Если Вы думаете, что xml к тяжелому для Вашего использования, взгляните на JSON вместо этого. Это - легкий вес, но имеет меньше функциональности, чем xml.
И если Вы хотите действительно маленькие файлы, используйте двоичный формат ;-).
Не беспокойтесь оптимизацией в тексте своего XML и ухудшающий чтение/запись перфекта/простоты. Использование выкачивает сжатие для сжатия полезной нагрузки между клиентом и сервером. Я сделал некоторые тесты, и сжатие нормального 10k XML-файла приводит к 2.5k плач. Удаление всех имен конечного тэга конечной точки понижает исходный размер файла к 9k, но когда-то выкачало, это снова 2.5k. Это - очень хороший пример, что основанное на словаре сжатие является простым способом сжать полезные нагрузки между конечными точками. "" и "" (почти) использует то же пространство в сжатых данных.
Единственное исключение было бы то, если файлы/данные являются очень маленькими, то менее сжимаемый.