Czy jest jakiś znany sposób suszenia JSON

Question

Rozważmy tę odpowiedź JSON:

[{ 
    Name: 'Saeed', 
    Age: 31 
}, { 
    Name: 'Maysam', 
    Age: 32 
}, { 
    Name: 'Mehdi', 
    Age: 27 
}] 

Działa to dobrze dla małej ilości danych, ale jeśli chcesz, aby służyć większej ilości danych (powiedzmy wiele tysięcy rekordów dla przykład) wydaje się logiczne, aby jakoś zapobiec powtórzeniom nazw właściwości w odpowiedzi JSON.

I Googled pojęcie (SUSZENIE JSON) i ku mojemu zaskoczeniu, nie znalazłem żadnego odpowiedniego wyniku. Jednym ze sposobów jest oczywiście skompresować JSON za pomocą prostego algorytmu domowej roboty i rozpakować go na stronie klienta przed jego spożywania:

[['Name', 'Age'], 
['Saeed', 31], 
['Maysam', 32], 
['Mehdi', 27]] 

Jednak najlepszym rozwiązaniem byłoby lepsze niż każdy deweloper próbuje wyważać otwartych drzwi . Czy widzieliście dobrze znane, powszechnie akceptowane rozwiązanie tego problemu?

Answer 1

Jednym z rozwiązań jest znany jako algorytm hpack

https://github.com/WebReflection/json.hpack/wiki

Answer 2

Możesz być w stanie korzystać z formatu CSV zamiast JSON, jak można określić tylko nazwy własności raz. Wymagałoby to jednak sztywnej struktury, jak w twoim przykładzie.

JSON nie jest czymś, co nadaje się do SUCHEGO, ponieważ jest już całkiem dobrze zapakowane, biorąc pod uwagę to, co można z nim zrobić. Osobiście użyłem nagich tablic dla danych JSON, które są przechowywane w pliku do późniejszego wykorzystania, ale dla prostych żądań AJAX po prostu pozostawiam go takim, jaki jest.

DRY zwykle odnosi się do tego, co sam piszesz, więc jeśli obiekt jest generowany dynamicznie, nie powinieneś się tym martwić.

Answer 3

Po pierwsze, JSON nie ma być najbardziej kompaktowym sposobem reprezentowania danych. Jest przeznaczony do przetwarzania bezpośrednio w strukturę danych javascript, przeznaczoną do natychmiastowej konsumpcji bez dalszego przetwarzania. Jeśli chcesz zoptymalizować rozmiar, prawdopodobnie nie chcesz, aby opisywał JSON i musisz pozwolić, aby Twój kod zawierał kilka założeń dotyczących obsługi danych i użycia ich oraz wykonania ręcznego analizowania koniec. To te założenia i dodatkowa praca kodowania mogą zaoszczędzić miejsce.

Jeśli nazwy właściwości i format odpowiedzi serwera są już znane z kodem, można po prostu przywrócić dane w postaci tablicy wartości naprzemiennie:

['Saeed', 31, 'Maysam', 32, 'Mehdi', 27] 

lub jeśli jest to bezpieczne założenie, że nazwy don „t zawierać przecinki, można nawet po prostu zwrócić rozdzielany przecinkami ciąg znaków, który można podzielić na to kawałki i trzymać się własnych struktur danych:

"Saeed, 31, Maysam, 32, Mehdi, 27" 

lub jeśli nadal ma to być ważne JSON, które można umieścić ten łańcuch w takiej tablicy, która jest tylko sligh nio lepiej niż mój pierwszej wersji, gdzie same elementy są elementy tablicy:

["Saeed, 31, Maysam, 32, Mehdi, 27"] 

te założenia i zwartość umieścić większą odpowiedzialność za analizowanie danych na własnym javascript, ale to, że usunięcie siebie opisując naturę pełny JSON, z którego zacząłeś, prowadzi do jego bardziej kompaktowego charakteru.

Answer 4

Stosować kompresję gzip, która zazwyczaj jest łatwo wbudowana w większość serwerów sieciowych klientów: &?

Będzie jeszcze trochę (extra) czas & pamięci wygenerować & analizowania JSON na każdym końcu, ale nie zajmie to dużo czasu, aby wysłać przez sieć, a weźmie minimalnego wysiłku wdrożenia w Twoim imieniu.

Może warto, nawet jeśli wcześniej skompresujesz swoje dane źródłowe.

Answer 5

W rzeczywistości dla JSON-a nie ma problemu, że często masz masywny ciąg znaków lub duplikat "właściwości" (ani nie jest on dla XML).

To jest dokładnie to, co komponent duplicate string elimination algorytmu DEFLATE (używany przez GZip).

Podczas gdy większość klientów przeglądarki może akceptować odpowiedzi skompresowane GZip, ruch powrotny do serwera nie będzie możliwy.

Czy to gwarantuje użycie "kompresji JSON" (np. hpack lub innego schematu)?

1. Jest mało prawdopodobne, aby być o wiele szybciej niż wdrożenie kompresję gzip w JavaScript (co nie jest niemożliwe, na stosunkowo szybkiej maszynie można skompresować 100 KB w 250 ms).

2. Ciężko jest bezpiecznie przetworzyć niezaufane wejście JSON. Należy użyć analizy opartej na strumieniu i określić maksymalny próg złożoności, ponieważ może to być niespodzianką dla serwera. Patrz na przykład Armin Ronacher za Start Writing More Classes:

   Jeśli schludny mały serwer WWW jest coraz 10000 żądań na sekundę przez gevent ale używa json.loads wtedy mogę zrobić to prawdopodobnie czołgać się zatrzymał, wysyłając go 16MB dobrze spreparowany i zagnieżdżony JSON, który wyłapuje cały twój procesor.