Różnice:

1. YAML, w zależności od tego, jak go używasz, może być bardziej czytelny niż JSON
2. JSON jest często szybszy i prawdopodobnie nadal współpracuje z większą liczbą systemów
3. możliwe jest bardzo szybkie napisanie "wystarczająco dobrego" parsera JSON
4. zduplikowane klucze, które są potencjalnie poprawnym JSON, są zdecydowanie nieprawidłowym YAML.
5. YAML ma mnóstwo funkcji, w tym komentarze i kotwice relacyjne. Składnia YAML jest odpowiednio dość złożone i może być trudne do zrozumienia.
6. możliwe jest zapisanie struktur rekurencyjnych w yaml: {a: &b [*b]}, które będą pętlować w nieskończoność w niektórych konwerterach. Nawet przy detekcji kołowej "bomba yaml" jest nadal możliwa (zobacz bomba xml).
7. ponieważ nie ma odniesień, nie jest możliwe serializowanie złożonych struktur za pomocą odniesień do obiektów w JSON. Serializacja YAML może być zatem bardziej wydajna.
8. w niektórych środowiskach kodowania, użycie YAML może pozwolić atakujący do wykonuje dowolny kod .

Uwagi:

1. Programiści Pythona są na ogół wielkimi fanami YAML, ze względu na użycie wcięć, zamiast składni bracketed, do wskazania poziomów.
2. wielu programistów uważa przywiązanie "znaczenia" do wcięć za zły wybór.
3. Jeśli format danych będzie opuszczał środowisko aplikacji, przetwarzany w interfejsie użytkownika lub wysyłany w warstwie wiadomości, JSON może być lepszym rozwiązaniem wybór.
YAML może być używany bezpośrednio do skomplikowanych zadań, takich jak definicje gramatyczne, i często jest lepszym Wyborem niż wymyślanie nowego języka.

Omijanie teorii ezoterycznej

To odpowiada na tytuł, a nie na szczegóły, ponieważ większość po prostu czyta tytuł z wyniku wyszukiwania w google, tak jak ja, więc uznałem, że konieczne jest wyjaśnienie z perspektywy Web Developera.

1. YAML używa wcięć spacji, które są znane programistom Pythona.
2. Programiści JavaScript kochają JSON, ponieważ jest podzbiorem JavaScript i może być bezpośrednio interpretowany i zapisywany wewnątrz JavaScript, wraz z użyciem skrócony sposób deklarowania JSON, nie wymagający podwójnych cudzysłowów w kluczach przy użyciu typowych nazw zmiennych bez spacji.
3. Istnieje mnóstwo parserów, które działają bardzo dobrze we wszystkich językach zarówno dla YAML, jak i JSON.
4. Format whitespace YAML może być znacznie łatwiejszy do przyjrzenia się w wielu przypadkach, ponieważ formatowanie wymaga bardziej czytelnego dla człowieka podejścia.
5. biała przestrzeń YAML jest bardziej zwarta i łatwiejsza do obejrzenia, może być zwodniczo trudna do ręcznego edytowania, jeśli nie masz widoczne białe znaki lub wskaźniki linii wcięć w edytorze.
JSON jest znacznie szybszy do serializacji i deserializacji ze względu na znacznie mniej funkcji niż YAML do sprawdzenia, co umożliwia mniejszy i lżejszy kod do przetwarzania JSON.
6. powszechnym błędnym przekonaniem jest to, że YAML potrzebuje mniej interpunkcji i jest bardziej zwarty niż JSON, ale jest to całkowicie fałszywe. Białe znaki są niewidoczne, więc wydaje się, że jest mniej znaków, ale jeśli policzysz rzeczywiste białe znaki, które aby YAML mógł być poprawnie zinterpretowany wraz z odpowiednim wcięciem, YAML wymaga więcej znaków niż JSON. JSON nie używa białych znaków do reprezentowania hierarchii lub grupowania i może być łatwo spłaszczony z niepotrzebnymi białymi znakami usuwanymi w celu bardziej kompaktowego transportu.

Słoń w pokoju: sam Internet

JavaScript tak wyraźnie dominuje w sieci przez ogromny margines i deweloperzy JavaScript wolą używać JSON jako formatowanie danych w przeważającej mierze wraz z popularnymi interfejsami API sieci web, więc trudno jest argumentować użycie YAML nad JSON podczas programowania sieciowego w ogólnym sensie, ponieważ prawdopodobnie zostaniesz przegłosowany w środowisku zespołowym. W rzeczywistości większość programistów internetowych nie jest nawet świadoma istnienia YAML, nie mówiąc już o używaniu go.

Jeśli robisz jakiekolwiek programowanie internetowe, JSON jest domyślnym sposobem, aby przejść, ponieważ nie krok tłumaczenia jest potrzebne podczas pracy z JavaScript, więc musisz wymyślić lepszy argument do użycia YAML nad JSON w tym przypadku.

To pytanie ma 6 lat, ale o dziwo, żadna z odpowiedzi nie odnosi się do wszystkich czterech punktów (szybkość, pamięć, wyrazistość, przenośność).

Speed

Oczywiście jest to zależne od implementacji, ale ponieważ JSON jest tak szeroko stosowany i tak łatwy w implementacji, ma tendencję do uzyskiwania większego natywnego wsparcia, a co za tym idzie szybkości. Biorąc pod uwagę, że YAML robi wszystko, co robi JSON, plus ciężarówka więcej, jest prawdopodobne, że z wszystkich porównywalnych implementacji obu, JSON jeden będzie szybszy.

Jednakże, biorąc pod uwagę, że plik YAML może być nieco mniejszy niż jego odpowiednik JSON (z powodu mniejszej liczby znaków " i ,), jest możliwe, że wysoce zoptymalizowany parser YAML może być szybszy w wyjątkowych okolicznościach.

Pamięć

W zasadzie stosuje się ten sam argument. Trudno zrozumieć, dlaczego Parser YAML byłby bardziej wydajny w pamięci niż parser JSON, jeśli reprezentują te same dane struktura.

Wyrazistość

Jak zauważyli inni, programiści Pythona preferują YAML, programistów JavaScript w stosunku do JSON. Zrobię te spostrzeżenia:

• łatwo zapamiętać całą składnię JSON, a tym samym być pewnym zrozumienia znaczenia dowolnego pliku JSON. YAML nie jest do końca zrozumiały dla żadnego człowieka. Liczba subtelności i przypadków krawędzi jest ekstremalna.
• ponieważ kilka parserów implementuje cały spec, to nawet trudniej mieć pewność co do znaczenia danego wyrażenia w danym kontekście.
• Brak komentarzy w JSON to w praktyce prawdziwy ból.

Przenośność

Podsumowanie

JSON jest zwycięzcą pod względem wydajności (jeśli dotyczy) i interoperacyjności. YAML jest lepszy dla plików utrzymywanych przez człowieka. HJSON to przyzwoity kompromis, choć ze znacznie mniejszą przenośnością. JSON5 jest bardziej rozsądnym kompromisem, z dobrze zdefiniowaną składnią.

Uważam, że YAML jest łatwiejszy w oczach: mniej nawiasów, "" itp. Chociaż jest irytacja tabs w YAML... ale można to zrozumieć.

Jeśli chodzi o wydajność / zasoby, nie spodziewałbym się dużych różnic między tymi dwoma.

Furthermore, mówimy o plikach konfiguracyjnych, więc nie spodziewałbym się wysokiej częstotliwości kodowania/dekodowania, nie?

Jeśli nie potrzebujesz żadnych funkcji, które YAML ma, a JSON nie, wolałbym JSON, ponieważ jest bardzo prosty i jest szeroko obsługiwany (ma wiele bibliotek w wielu językach). YAML jest bardziej złożony i ma mniejsze wsparcie. Nie sądzę, że szybkość parsowania lub użycie pamięci będzie bardzo różne, a może nie duża część wydajności programu.

GIT i YAML

Coraz częściej wiele projektów programistycznych używa repozytoriów git do dystrybucji i archiwizacji. Podczas gdy historia repo w git może równie dobrze przechowywać pliki JSON i YAML, metoda "diff" używana do śledzenia i wyświetlania zmian w pliku jest zorientowana liniowo. Ponieważ YAML jest zmuszony być zorientowany liniowo, wszelkie małe zmiany w pliku YAML są łatwiejsze do zobaczenia przez człowieka.

Prawdą jest oczywiście, że pliki JSON mogą być "upiększone" poprzez sortowanie łańcuchów / kluczy i dodawanie wcięć. Ale to nie jest domyślne i jestem leniwy.

Osobiście zazwyczaj używam JSON do interakcji system-system. Często używam YAML do plików konfiguracyjnych, statycznych i śledzonych. (Generalnie unikam też dodawania anchorów relacyjnych YAML. Życie jest zbyt krótkie, by upolować pętle.)

Również, jeśli prędkość i przestrzeń są naprawdę problemem, ja też nie używam. Może zechcesz spojrzeć na BSON.

Technicznie YAML oferuje znacznie więcej niż JSON (YAML v1.2 to superset JSON):

• komentarze

• Kotwice i dziedziczenie-przykład 3 identycznych elementów:

  item1: &anchor_name
    name: Test
    title: Test title
  item2: *anchor_name
  item3:
    <<: *anchor_name
    # You may add extra stuff.
  

• ...

Przez większość czasu ludzie nie będą używać tych dodatkowych funkcji, a główna różnica polega na tym, że YAML używa wcięć , podczas gdy JSON używa nawiasów . To sprawia, że YAML jest bardziej zwięzły i czytelny (dla wyszkolonych oko).

Który wybrać?

• YAML dodatkowe funkcje i zwięzła notacja sprawiają, że jest to dobry wybór dla plików konfiguracyjnych (pliki nie dostarczane przez użytkownika).
• JSON ograniczone funkcje, szerokie wsparcie i szybsze parsowanie sprawiają, że jest to doskonały wybór dla interoperacyjności i danych dostarczonych przez użytkownika .

Ponieważ to pytanie jest teraz szczególnie widoczne podczas wyszukiwania YAML i JSON, warto zwrócić uwagę na jedną rzadko cytowaną różnicę między tymi dwoma: license. JSON twierdzi, że posiada licencję , do której użytkownicy JSON muszą się stosować (w tym dwuznaczne prawnie "powinno być używane dla dobra, nie dla zła"). YAML nie ma takiego roszczenia licencyjnego, a to może być ważna różnica (dla Twojego prawnika, jeśli nie dla Ciebie).

Czasami nie musisz decydować się na jedno nad drugim.

W Go, na przykład, możesz mieć oba w tym samym czasie:

type Person struct {
    Name string `json:"name" yaml:"name"`
    Age int `json:"age" yaml:"age"`
}

Uważam, że zarówno YAML, jak i JSON są bardzo skuteczne. Jedyne dwie rzeczy, które naprawdę dyktują, kiedy jedna jest używana nad drugą, to jedna, z czym język jest używany najbardziej popularnie. Na przykład, Jeśli używam Java, Javascript, będę używać JSON. W przypadku Javy użyję ich własnych obiektów, które są w zasadzie JSON, ale brakuje im niektórych funkcji, i przekonwertuję je na JSON, jeśli będę tego potrzebował lub zrobię to w JSON. Robię to, ponieważ to jest powszechne w Javie i ułatwia innym Programistów Javy, aby zmodyfikować mój kod. Drugą rzeczą jest to, czy używam go dla programu do zapamiętywania atrybutów, lub jeśli program otrzymuje instrukcje w postaci pliku konfiguracyjnego, w tym przypadku użyję YAML, ponieważ jest bardzo łatwy do odczytania przez człowieka, ma ładnie wyglądającą składnię i jest bardzo łatwy do modyfikacji, nawet jeśli nie masz pojęcia, jak działa YAML. Następnie program przeczyta go i przekonwertuje na JSON, lub cokolwiek jest preferowane dla tego języka.

W końcu to bez znaczenia. Zarówno JSON, jak i YAML są łatwo odczytywane przez każdego doświadczonego programistę.