İki XML belgesini yapıştırın, formatlayın ve yan yana karşılaştırın. Pretty-print, doğrulama ve namespace farkındalıklı vurgulama yerleşik.
İki XML belgesini karşılaştırmak için tarayıcı içinde çalışan ücretsiz bir araç. Eski bir pom.xml'i sola, yenisini sağa yapıştırın, değişiklikler element bazında öne çıkar. Hiçbir şey makinenizden ayrılmaz.
Diff'in kendisi karakter düzeyinde, doğrulama ise tarayıcının yerel DOMParser'ı üzerinden yapılır. Her panelin Format düğmesi XML'i tutarlı girinti ile yeniden akıtır. Canlı doğrulama; siz yazarken bozuk biçimli işaretlemeyi, eşleşmeyen etiketleri ve kırık entity referanslarını işaretler.
Bir kod incelemesinde 4.000 satırlık bir Spring application context açıp class niteliği değişen tek bean'i aramaya çalıştıysanız, bu sizi oraya saniyeler içinde götüren araçtır. Düz nesir için metin diff aracımız doğru seçim. Anahtar/değer çiftli yapısal veriler için JSON diff, nesne yeniden sıralamasını XML'in başaramayacağı kadar temiz ele alır.
Diff karakter düzeyinde çalışır, sonra anlamsal bir ardıl işleme geçişi vurguları kaydırır, böylece rastgele noktalama yerine etiket adları, nitelikler ve metin içeriği üzerine otururlar. Eklemeler sağ panelde yeşil, silmeler sol panelde kırmızı görünür.
XML'in spec'in açıkça belirttiği bir-iki tuhaflığı vardır ve iki dosyayı metin olarak karşılaştırırken hepsi can sıkar. XML 1.0 spesifikasyonu, bir element üzerindeki nitelik sırasının anlamlı olmadığını söyler, dolayısıyla bir parser için <img src="a.png" alt="x"/> ve <img alt="x" src="a.png"/> aynıdır. Bir metin diff'i yer değiştirmeyi yine de işaretler. Yapısal karşılaştırma olmadan kalıcı bir çözüm yoktur; pratik geçici çözüm, nitelik sırasını sabit tutmak için her iki tarafı aynı araçla formatlamaktır.
Namespace'ler bir kat daha ekler. Aynı URI'yi farklı önek'lere bağlayan iki belge Namespaces in XML 1.0'a göre eşdeğerdir, ama bir metin diff'i her ns1: ile ns2: takasını değişiklik olarak boyar. İki tarafı formatlayın, birinde önek'i hizalayın ve tekrar diff alın. Diff'ten önce namespace'leri ve nitelik sırasını normalleştiren bir pipeline için XSLT 3.0'a veya Canonical XML uyarınca bir kanonikleştirme adımına bakın.
İki metin paneli, bir diff. Kayıt yok, yükleme yok, sunucuya gidip dönüş yok.
Eski XML'i sola, yeni XML'i sağa yapıştırın. Veya iki taraftan birinde Yükle'ye tıklayarak doğrudan bir .xml, .pom, .config ya da .svg dosyası yükleyin. Örnek düğmesi, aracı önce iş başında görmek isterseniz her iki paneli küçük bir pom.xml ile doldurur.
Her panelde Format'a tıklayarak tutarlı girinti ve satır kırılmalarıyla pretty-print yapın. Bu, boşlukları normalleştirir, böylece diff Windows CRLF dosyası ile Unix LF dosyasından gelen format gürültüsüne değil, gerçek içerik değişikliklerine odaklanır. DOMParser belgenizi well-formed kabul ettiğinde doğrulama rozeti yeşile döner.
Silmeler solda kırmızı vurgu ile, eklemeler sağda yeşil vurgu ile görünür. Her iki tarafı da kaydırabilirsiniz, diğeri eşlik eder. Her başlıktaki değişiklik sayaçları, diff'in element adları, nitelik değerleri ve metin içeriği boyunca bulduğu farklı düzenleme sayısını söyler.
Bir Dependabot PR'si on beş Maven koordinatını tek seferde yukarı çeker. Eski pom.xml'i yenisiyle karşı karşıya yapıştırarak gerçek yükseltmeleri doğrulayın: spring-boot-starter-web 3.1.5'ten 3.2.1'e taşındı, jackson-databind 2.15.3'ten 2.16.0'a, ve yeni bir micrometer-registry-prometheus bağımlılığı eklendi. Diff sürüm sıçramalarını belirgin hale getirir, böylece onaydan önce changelog ile çapraz kontrol edebilirsiniz.
Bir refactor sonrası bir servis düşmeye başladığında neden çoğu zaman applicationContext.xml içinde class niteliği veya yapıcı argümanı değişmiş tek bir bean'dir. Çalışan revizyonu HEAD'e karşı yapıştırın; diff class="com.acme.OldDataSource" ile class="com.acme.HikariDataSource" takasını anında yüzeye çıkarır, çevredeki <property> etiketleri de hangi yapılandırmanın birlikte kaydığını söyler.
Dün çalışan bir SOAP entegrasyonu bugün Fault döndürüyor. Her iki zarfı paket logger'ınızdan veya WireMock kayıtlarından alın, diff'e bırakın, sorunlu element öne fırlar: <currencyCode> USD'den eksik bir elemente dönüşmüş, ya da soap:Envelope üzerindeki bir namespace bildirimini upstream servis sessizce değiştirmiş. Yan yana görünüm olmadan bunu 800 satırlık bir XML'de bulmak umutsuzdur.
Bir release göndermeden önce, izin yayılmasını yakalamak için AndroidManifest.xml'i önceki etikete karşı diff'leyin. Üçüncü taraf bir SDK güncellemesiyle sızmış yeni bir <uses-permission android:name="android.permission.READ_CONTACTS"/> tam olarak Play Store'un incelemede işaretleyeceği türdendir. Diff aynı zamanda <intent-filter> elementlerindeki ve android:exported bayraklarındaki değişiklikleri de yüzeye çıkarır; güvenlik incelemelerinin sık odak noktaları.
Bir feed okuyucu, kaynak RSS 2.0'dan Atom 1.0'a geçtiği veya bir yayıncı yeni bir <media:thumbnail> namespace'i eklediği için bozulur. Çalışan feed'in bir snapshot'ını saklayın, canlı feed'e karşı diff'leyin, yapısal değişiklik saniyeler içinde belirir. OPML import'ları ve channel düzeyindeki metaverinin elementler arasında kaydığı podcast feed'leri için aynı akış.
Bir .docx, içinde XML olan bir zip'tir. Bir sözleşmenin iki sürümünü açın, word/document.xml üzerinde diff çalıştırın, ve Word'ün değişiklik takip işaretlemesi araya girmeden gerçek metin düzenlemelerini görürsünüz. Bir paralegal, redline ile uyumlu olduğunu söylediği "temiz" bir kopya gönderdiğinde işe yarar; XML hangi paragraf elementlerinin kaydığını ve hangi run düzeyi biçimlendirmenin değiştiğini söyler.
Bu aracın en sık ortaya çıkardığı parsing sınır durumları için kısa bir kopya kâğıdı. Tümü W3C XML spec'lerine dayalı.
| Topic | What this tool does |
|---|---|
| Nitelik sırası | XML 1.0 spec'ine göre anlamlı değildir. Bir parser için <a x="1" y="2"/>, <a y="2" x="1"/>'a eşittir. Metin diff'i takası işaretler; sırayı sabit tutmak için iki tarafı formatlayın. |
| Namespace'ler | URI bağlı, önek'le takma adlı. Aynı URI'yi farklı önek'lere bağlayan iki belge eşdeğerdir. Namespaces in XML 1.0'a bakın. |
| CDATA bölümleri | <![CDATA[ ... ]]> ile sarmalanmış harfi harfine metin. Parser içeride etiketleri ve entity'leri yorumlamaz. ]]> dizisi bir CDATA bloğunun içinde görünemez. |
| Karışık içerik | Elementler metni, çocuk elementleri ve boşluğu herhangi bir sırada içerebilir. <p>Merhaba <b>dünya</b>!</p> karışık içeriktir ve oradaki boşluk anlamlıdır. |
| Yorumlar | <!-- yorum -->. İçeride -- içeremez. Çoğu işlemci tarafından çıkarılır ama bu diff'te metin olarak korunur. |
| Encoding ve BOM | <?xml version="1.0" encoding="UTF-8"?> ile bildirilir. UTF-8 BOM gizli bir ilk karakterdir; satır 1'de bir karakterlik hayalet diff'lerin yaygın nedeni. |
| XML 1.0 - 1.1 | Hemen herkes XML 1.0 kullanır. Sürüm 1.1, element içeriğinde ek Unicode kontrol karakterleri için destek ekler; pratikte nadir görülür. |
| Entity referansları | Beş yerleşik: & < > ' ". Aksanlı harfler için é gibi sayısal karakter referansları da geçerlidir. Kendi kendini kapatan <br/> ile açık <br></br> eşdeğerdir. |
Evet, her ikisi de görünür. Bir metin diff'i karakterleri satır satır karşılaştırır, dolayısıyla yeniden formatlama, niteliklerin yeniden sıralanması veya elementler içindeki boşluklar, belge mantıksal olarak özdeş olsa bile fark olarak görünür. İki panelde de önce Format'a tıklarsanız diff gerçek içerik değişikliklerine odaklanır. Derinlemesine yuvalanmış çocuklara sahip element ağaçları için XSLT veya Canonical XML üzerinden yapısal karşılaştırma bir sonraki adımdır; bu araç, o karmaşıklık olmadan pratik XML incelemelerinin %95'ini halleder.
Hayır, XML parser'ı için değil. XML 1.0 spec'i niteliklerin sırasının anlamlı olmadığını söyler, dolayısıyla <img src="a.png" alt="x"/> ve <img alt="x" src="a.png"/> aynı elementi temsil eder. Karakter diff'i ham metni gördüğü için yeniden sıralamayı yine de işaretler. Çare, diff'ten önce nitelik sırasının tutarlı olması için iki tarafı aynı araçla formatlamak, ya da pipeline'ı kontrol ediyorsanız Canonical XML normalleştirmesini uygulamaktır.
Namespace'ler URI tabanlıdır, ama belgede onları kısa önek'lere bağlarsınız. http://maven.apache.org/POM/4.0.0'ı farklı önek'lere bağlayan iki dosya, Namespaces in XML spec'ine göre eşdeğerdir, ama metin diff'i her önek takasını değişiklik olarak işaretler. Pratik çare iki dosyayı formatlamak ve iki tarafta da eşleşen önek'ler kullanmaktır. Otomatik pipeline'lar için bir Canonical XML geçişi bunu normalize eder.
Evet. CDATA bölümleri, parser'a yorumlanmaması söylenmiş metin içeriğinden başka bir şey değildir, dolayısıyla <![CDATA[<b>raw</b>]]> içindeki harfi harfine karakterler olarak karşılaştırılır. Uzun CDATA blokları (script etiketleri, gömülü HTML, SQL) temiz biçimde diff'lenir. Tek tuzak, bir CDATA bölümünün içine ]]> koyamamanızdır; verileriniz o diziyi içeriyorsa kaynağın onu iki CDATA bloğuna bölmesi gerekir, bunu da diff yazıldığı gibi gösterir.
XML'i dönüştürmek veya karşılaştırmadan önce normalleştirmek istediğinizde (çocukları sıralamak, yorumları atmak, namespace'leri kanonikleştirmek) XSLT kullanın. İki belirli dosya arasında nelerin değiştiğini görmek istediğinizde bu diff'i kullanın. İkisi tamamlayıcıdır: gürültülü makine tarafından üretilmiş XML için XSLT ön geçişi artı bu diff güçlü bir akıştır. Çoğu kod inceleme kullanım durumu için (pom.xml, AndroidManifest, application context) tek başına diff yeter.
Bir miktar. <?xml version="1.0" encoding="UTF-8"?> bildirimi belge metninin parçasıdır, dolayısıyla UTF-8'i UTF-16 ile değiştirmek tek satırlık bir diff olarak görünür. Tam başta bir UTF-8 byte order mark (BOM), bazı editörlerin çıkardığı bazılarının koruduğu tek bir gizli karakterdir; hayalet diff'lerin yaygın bir kaynağıdır. İki dosya aynı görünüyor ama diff satır 1 karakter 0'da bir değişiklik gösteriyorsa, BOM'dan şüphelenin ve bilinen bir encoding ayarıyla yeniden kaydedin.
XML'iniz tarayıcınızdan çıkmaz. Parser, formatter ve diff'in tümü makinenizde, yerel olarak çalışır. Girdiniz üzerinde analiz, log veya "yardımsever" bir bulut gidiş-dönüşü yok. Parsing ve doğrulama tarayıcının yerel DOMParser'ını kullanır ve takip ettiğimiz spec W3C XML 1.0'dır. Formatın kendisi hakkında arka plan okuması Wikipedia'da.