Najlepszy algorytm kompresji dla XML?

Question

Prawie nic nie wiem o kompresji, więc weź ze mną (to prawdopodobnie głupie i boleśnie oczywiste pytanie).

Powiedzmy, że mam plik XML z kilkoma znacznikami.

<verylongtagnumberone> 
    <verylongtagnumbertwo> 
    text 
    </verylongtagnumbertwo> 
</verylongtagnumberone> 

Teraz możemy powiedzieć, że mam kilka bardzo długich tagów z wieloma atrybutami w moich wielu plikach XML. Muszę je skompresować do jak najmniejszego rozmiaru. Najlepszym sposobem byłoby użycie algorytmu specyficznego dla XML, który przypisuje indywidualne znaczniki pseudonimów takich jak vlt1 lub vlt2. Jednak nie byłoby to tak "otwarte", jak próbuję iść, i chcę użyć wspólnego algorytmu, takiego jak DEFLATE lub LZ. Pomaga także, jeśli archiwum jest plikiem .zip.

Ponieważ mam do czynienia z czystym tekstem (bez plików binarnych, takich jak obrazy), chciałbym algorytmu, który pasuje do zwykłego tekstu. Który z nich produkuje najmniejszy rozmiar pliku (preferowane są bezstratne algorytmy)?

Nawiasem mówiąc, scenariusz jest następujący: Tworzę standard dla dokumentów, takich jak ODF lub MS Office XML, które zawierają pliki XML, spakowane w formacie .zip.

EDYCJA: "Szyfrowanie" było literówką; powinno to spowodować "kompresję".

Answer 1

Istnieje standard W3 (jeszcze nie opublikowany) o nazwie EXI (Efficient XML Interchange).

Powinien być formatem danych do kompresowania danych XML w przyszłości (uznawanym za ostatni niezbędny format binarny). Zoptymalizowany pod kątem XML, kompresuje XML bardziej efektywnie niż jakikolwiek konwencjonalny algorytm kompresji.

Z EXI można operować na skompresowanych danych XML w locie (bez potrzeby dekompresji lub ponownego kompresowania).

EXI = (XML + XMLSchema) jako binarny.

A tu proszę z realizacją opensource (nie wiem, czy to już stabilny):
Exificient

Answer 2

Wygląda na to, że bardziej interesuje Cię kompresja niż szyfrowanie. Czy tak jest? Jeśli tak, this może okazać się interesującą lekturą, nawet jeśli nie jest to dokładne rozwiązanie.

Answer 3

Mam nadzieję, że dobrze zrozumiałem co trzeba zrobić ... Pierwszą rzeczą, chciałbym powiedzieć to to, że nie ma dobra ani zła kompresja algorithmss na tekst - zip, bzip, gzip, rar, 7zip są dobre wystarczy ścisnąć wszystko co ma niską entrpy - tj dużego pliku z małego zestawu znaków. Gdybym musiał z nich skorzystać, wybrałbym 7zip na mój pierwszy wybór, rar jako sekunda i zip jako trzeci. Ale różnica jest bardzo mała, więc powinieneś wypróbować , co jest dla ciebie łatwiejsze. Po drugie - nie mogłem zrozumieć, co próbujesz zaszyfrować. Załóżmy, że jest to plik XML, a następnie najpierw skompresuj go przy użyciu ulubionego algorytmu kompresji , a następnie zaszyfruj go przy użyciu ulubionego algorytmu szyfrowania . W większości przypadków każdy nowoczesny algorytm realizowany na przykład w PGP będzie wystarczająco bezpieczna do niczego. Nadzieję, że pomaga.

Answer 4

Twoje alternatywy są:

• Użyj serwera WWW, który obsługuje kompresję gzip. Automatycznie skompresuje wszystkie wychodzące html. Istnieje jednak niewielka kara CPU.
• Użyj czegoś takiego jak JSON. To drastycznie zmniejszy rozmiar komunikatu. Istnieje również binarny kod XML, ale sam go nie wypróbowałem.

Answer 5

Nawiasem mówiąc, scenariusz jest taki: Tworzę standard dokumentów, jak ODF lub XML MS Office, które zawierają pliki XML, opakowaną w .zip.

następnie sugeruję, aby użyć kompresji .zip, lub użytkownicy będą się mylić.

Answer 6

Inną alternatywą do "skompresować" XML byłoby FI (Szybkie Infoset).

XML przechowywane jako FI, każdy będzie zawierać tag i przypisać tylko raz, wszystkie inne zjawiska odwołują pierwszy, oszczędzając przestrzeń.

Patrz:

Very good article on java.sun.com, i oczywiście
the Wikipedia entry

Różnica w stosunku do exi z punktu widzenia kompresji jest to, że szybko Infoset (będąc strukturze zwykłego tekstu) jest mniej wydajny.

Inna ważna różnica to: FI to dojrzały standard z wieloma implementacjami.
Jeden z nich: Fast Infoset Project @ dev.java.net

Answer 7

Tak, * .zip najlepiej w praktyce. Debiuty Gory'ego zawarte w pokazują, że "optymalne" kompresory nie warte kosztu obliczeniowego & Kompresory specyficzne dla danej domeny nie pokonują zip [średnio].

Nota prawna: Napisałem ten artykuł, który został cytowany 60+ razy według Google.

Answer 8

Żadne z domyślnych nie są idealne dla XML, ale nadal otrzymasz dobre wartości, ponieważ istnieje wiele powtarzalnych.

Ponieważ XML używa wielu powtórzeń (tagów.>), Które mają być mniej niż trochę, więc jest to raczej forma arytmetyczna niż kodowanie Huffmana. Tak więc rar/7zip powinien być znacznie lepszy w teorii. Te algorytmy oferują wysoką kompresję, więc są wolniejsze. Idealnie chciałbyś mieć prostą kompresję z koderem arytmetycznym (który dla XML byłby szybki i zapewniałby wysoką kompresję).