У меня есть два приложения, написанные на Java, которые общаются друг с другом, используя XML-сообщения по сети. Я использую синтаксический анализатор SAX на принимающей стороне, чтобы вернуть данные из сообщений. Одним из требований является встраивание двоичных данных в сообщение XML, но SAX это не нравится. Кто-нибудь знает как это сделать?
ОБНОВЛЕНИЕ: Я получил эту работу с классом Base64 из библиотеки кодеков Apache Commons , на случай, если кто-то еще попробует что-то подобное.
Вы можете кодировать двоичные данные, используя base64, и поместить их в элемент Base64; ниже статья довольно хорошая по этому вопросу.
Может быть, закодировать их в известный набор - что-то вроде base 64 - популярный выбор.
Попробуйте Base64 кодирование / декодирование ваших двоичных данных. Также загляните в разделы CDATA
Я обычно кодирую двоичные данные с помощью MIME Base64 или URL-кодирования .
XML настолько универсален ...
<DATA>
<BINARY>
<BIT index="0">0</BIT>
<BIT index="1">0</BIT>
<BIT index="2">1</BIT>
...
<BIT index="n">1</BIT>
</BINARY>
</DATA>
XML похож на насилие - если он не решает вашу проблему, вы не используете его в достаточной мере.
РЕДАКТИРОВАТЬ:
Кстати: Base64 + CDATA, вероятно, лучшее решение
(РЕДАКТИРОВАТЬ 2:
Кто бы ни изменял мне, пожалуйста, также измените реальный ответ. Мы не хотим, чтобы какая-то бедная душа пришла сюда и фактически внедрила мой метод, потому что это был самый высокий рейтинг на SO, верно?)
Base64 - действительно правильный ответ, но CDATA - нет, это в основном говорит: «это может быть что угодно», однако это не должно быть просто что-то, это должны быть двоичные данные в кодировке Base64. Схема XML определяет двоичный файл Base 64 как примитивный тип данных, который вы можете использовать в своем xsd.
xs:base64Binary
типа данных, который является правильным типом для использования. Вы также можете Uuencode свои оригинальные двоичные данные. Этот формат немного старше, но он делает то же самое, что и кодировка base63.
Любое двоичное кодирование текста сделает свое дело. Я использую что-то подобное
<data encoding="yEnc>
<![CDATA[ encoded binary data ]]>
</data>
У меня была эта проблема только на прошлой неделе. Мне пришлось сериализовать PDF-файл и отправить его внутри XML-файла на сервер.
Если вы используете .NET, вы можете преобразовать двоичный файл непосредственно в строку base64 и вставить его в элемент XML.
string base64 = Convert.ToBase64String(File.ReadAllBytes(fileName));
Или есть метод, встроенный прямо в объект XmlWriter. В моем конкретном случае мне пришлось включить пространство имен типа данных Microsoft:
StringBuilder sb = new StringBuilder();
System.Xml.XmlWriter xw = XmlWriter.Create(sb);
xw.WriteStartElement("doc");
xw.WriteStartElement("serialized_binary");
xw.WriteAttributeString("types", "dt", "urn:schemas-microsoft-com:datatypes", "bin.base64");
byte[] b = File.ReadAllBytes(fileName);
xw.WriteBase64(b, 0, b.Length);
xw.WriteEndElement();
xw.WriteEndElement();
string abc = sb.ToString();
Строка abc выглядит примерно так:
<?xml version="1.0" encoding="utf-16"?>
<doc>
<serialized_binary types:dt="bin.base64" xmlns:types="urn:schemas-microsoft-com:datatypes">
JVBERi0xLjMKJaqrrK0KNCAwIG9iago8PCAvVHlwZSAvSW5mbw...(plus lots more)
</serialized_binary>
</doc>
Хотя остальные ответы в основном хороши, вы можете попробовать другой, более экономичный способ кодирования, например, yEnc. ( ссылка yEnc на Википедию ) С помощью yEnc вы также можете получить контрольную сумму прямо из коробки. Читайте и ссылки ниже. Конечно, поскольку XML не имеет собственного типа yEnc, ваша XML-схема должна быть обновлена для правильного описания закодированного узла.
Почему : из-за стратегий кодирования base64 / 63, uuencode et al. Кодировки увеличивают объем данных (накладные расходы), которые необходимо хранить и передавать, примерно на 40% (по сравнению с 1-2% у yEnc). В зависимости от того, что вы кодируете, 40% накладных расходов может стать проблемой.
yEnc - аннотация в Википедии: https://en.wikipedia.org/wiki/YEnc. yEnc - это схема кодирования двоичного текста для передачи двоичных файлов в сообщениях на Usenet или по электронной почте. ... Дополнительным преимуществом yEnc перед предыдущими методами кодирования, такими как uuencode и Base64, является включение контрольной суммы CRC для проверки того, что декодированный файл был доставлен без изменений.
Накладные расходы Base64 составляют 33%.
Затраты BaseXML для XML1.0 составляют всего 20% . Но это не стандарт и только реализация на C. Проверьте это, если вас интересует размер данных. Обратите внимание, что, однако, браузеры имеют тенденцию реализовывать сжатие, так что оно менее необходимо.
Я разработал его после обсуждения в этой теме: Кодирование двоичных данных в XML: альтернативы base64 .
Если у вас есть контроль над форматом XML, вы должны вывернуть проблему наизнанку. Вместо того, чтобы прикреплять двоичный XML, вы должны подумать о том, как заключить документ, состоящий из нескольких частей, одна из которых содержит XML.
Традиционное решение для этого - архив (например, tar). Но если вы хотите сохранить вложенный документ в текстовом формате или если у вас нет доступа к библиотеке архивирования файлов, существует также стандартизированная схема, которая широко используется в электронной почте и HTTP, которая является составной / MIME с несколькими частями Content-Transfer-Encoding: двоичный .
Например, если ваши серверы обмениваются данными по протоколу HTTP и вы хотите отправить многокомпонентный документ, основным из которых является документ XML, который ссылается на двоичные данные, связь HTTP может выглядеть примерно так:
POST / HTTP/1.1
Content-Type: multipart/related; boundary="qd43hdi34udh34id344"
... other headers elided ...
--qd43hdi34udh34id344
Content-Type: application/xml
<myxml>
<data href="cid:data.bin"/>
</myxml>
--qd43hdi34udh34id344
Content-Id: <data.bin>
Content-type: application/octet-stream
Content-Transfer-Encoding: binary
... binary data ...
--qd43hdi34udh34id344--
Как и в приведенном выше примере, XML ссылается на двоичные данные во включающем множестве, используя cid
схему URI, которая является идентификатором заголовка Content-Id. Издержки этой схемы будут просто заголовком MIME. Аналогичная схема также может быть использована для ответа HTTP. Конечно, в протоколе HTTP у вас также есть возможность отправить многокомпонентный документ в отдельный запрос / ответ.
Если вы хотите избежать переноса данных в несколько частей, используйте URI данных:
<myxml>
<data href="data:application/something;charset=utf-8;base64,dGVzdGRhdGE="/>
</myxml>
Но это накладные расходы base64.