Ağ üzerinden XML mesajları kullanarak birbirleriyle iletişim kuran Java dilinde yazılmış iki uygulamam var. Verileri mesajlardan geri almak için alıcı uçta bir SAX ayrıştırıcısı kullanıyorum. Gereksinimlerden biri, ikili verileri bir XML mesajına gömmektir, ancak SAX bundan hoşlanmaz. Bunun nasıl yapılacağını bilen var mı?
GÜNCELLEME: Bunu , başka birinin benzer bir şey denemesi durumunda apache commons codec kitaplığından Base64 sınıfı ile çalıştırdım .
Yanıtlar:
İkili veriyi base64 kullanarak kodlayabilir ve bir Base64 öğesine koyabilirsiniz; aşağıdaki makale bu konuda oldukça iyi bir makale.
XML çok yönlü ...
<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 şiddet gibidir - Sorununuzu çözmezse, yeterince kullanmıyorsunuz demektir.
DÜZENLE:
BTW: Base64 + CDATA muhtemelen en iyi çözümdür
(
DÜZENLEME2 : Kim beni modifiye ederse, lütfen gerçek cevabı da modifiye edin. Zavallı ruhun buraya gelmesini ve aslında benim yöntemimi uygulamasını istemiyoruz çünkü SO'da en yüksek sırada yer alıyordu, değil mi?)
Base64 gerçekten doğru cevap ama CDATA temelde söylüyor ki değil: ancak olmalı, "Bu şey olabilir" değil , sadece bir şey olmak, bu Base64 ikili veri kodlanmış olması gerekir. XML Şeması, Base 64 ikilisini xsd'nizde kullanabileceğiniz ilkel bir veri türü olarak tanımlar .
xs:base64BinaryKullanılacak doğru tür olan veri türünden bahsetmek için ekstra bir nokta .
Bu sorunu daha geçen hafta yaşadım. Bir PDF dosyasını serileştirmem ve bir XML dosyası içinde bir sunucuya göndermem gerekiyordu.
.NET kullanıyorsanız, bir ikili dosyayı doğrudan bir base64 dizesine dönüştürebilir ve bir XML öğesinin içine yapıştırabilirsiniz.
string base64 = Convert.ToBase64String(File.ReadAllBytes(fileName));Veya, XmlWriter nesnesine yerleşik bir yöntem vardır. Benim durumumda, Microsoft'un veri türü ad alanını dahil etmem gerekiyordu:
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 dizisi şuna benzer bir şeye benziyor:
<?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>Genellikle ikili verileri MIME Base64 veya URL kodlamasıyla kodluyorum .
Herhangi bir ikiliden metne kodlama işi halleder. Onun gibi bir şey kullanıyorum
<data encoding="yEnc>
<![CDATA[ encoded binary data ]]>
</data>Base64 ek yükü% 33'tür.
XML1.0 ek yükü için BaseXML yalnızca% 20'dir . Ancak bu bir standart değil ve yalnızca bir C uygulaması var. Veri boyutuyla ilgileniyorsanız kontrol edin. Bununla birlikte, tarayıcıların daha az ihtiyaç duyulacak şekilde sıkıştırma uygulama eğiliminde olduğunu unutmayın.
Bu konudaki tartışmadan sonra geliştirdim: XML içinde ikili verileri kodlama : base64'e alternatifler .
Diğer cevaplar çoğunlukla iyi olsa da, yEnc gibi başka, daha az yer kaplayan bir kodlama yöntemini deneyebilirsiniz. ( yEnc wikipedia bağlantısı ) yEnc ile ayrıca "kutudan çıkar çıkmaz" sağlama toplamı yeteneği elde edin. Aşağıdaki okuyun ve bağlantıları. Elbette, XML'in yerel bir yEnc türü olmadığı için, XML şemanız kodlanmış düğümü düzgün bir şekilde tanımlayacak şekilde güncellenmelidir.
Nedeni : base64 / 63 kodlama stratejileri nedeniyle, uuencode et al. kodlamalar, depolamanız ve aktarmanız gereken veri miktarını (ek yük) yaklaşık% 40 oranında artırır (yEnc'in% 1-2'sine kıyasla). Neyi kodladığınıza bağlı olarak,% 40 ek yük bir sorun olabilir / olabilir.
yEnc - Wikipedia özeti: https://en.wikipedia.org/wiki/YEnc yEnc, ikili dosyaları Usenet'teki mesajlarda veya e-posta yoluyla aktarmak için ikili-metin kodlama şemasıdır. ... uuencode ve Base64 gibi önceki kodlama yöntemlerine göre yEnc'in ek bir avantajı, kodu çözülen dosyanın sağlam teslim edildiğini doğrulamak için bir CRC sağlama toplamının dahil edilmesidir.
Ayrıca, orijinal ikili verileri Uuencode edebilirsiniz. Bu format biraz daha eskidir, ancak base63 kodlamayla aynı şeyi yapar.
XML formatı üzerinde kontrolünüz varsa, sorunu tersine çevirmelisiniz. İkili XML eklemek yerine, biri XML içeren birden çok parçaya sahip bir belgeyi nasıl kapatacağınızı düşünmelisiniz.
Bunun geleneksel çözümü bir arşivdir (örn. Tar). Ancak, çevreleyen belgenizi metin tabanlı bir biçimde tutmak istiyorsanız veya bir dosya arşivleme kitaplığına erişiminiz yoksa, e-posta ve HTTP'de yoğun olarak kullanılan ve çok parçalı / * MIME olan standartlaştırılmış bir şema da vardır. Content-Transfer-Encoding: ikili .
Örneğin, sunucularınız HTTP üzerinden iletişim kuruyorsa ve çok parçalı bir belge göndermek istiyorsanız, birincil belge ikili veriye atıfta bulunan XML belgesidir, HTTP iletişimi aşağıdaki gibi görünebilir:
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--Yukarıdaki örnekte olduğu gibi, XML cid, Content-Id başlığının bir tanımlayıcısı olan bir URI şeması kullanarak çevreleyen çok parçadaki ikili verilere atıfta bulunur . Bu şemanın ek yükü sadece MIME başlığı olacaktır. Benzer bir şema, HTTP yanıtı için de kullanılabilir. Elbette HTTP protokolünde, çok parçalı bir belgeyi ayrı istek / yanıta gönderme seçeneğiniz de vardır.
Verilerinizi çok parçalı olarak sarmamaktan kaçınmak istiyorsanız, veri URI'si kullanmaktır:
<myxml>
<data href="data:application/something;charset=utf-8;base64,dGVzdGRhdGE="/>
</myxml>Ancak bunun base64 ek yükü var.