Soru Yapılandırma dosyaları için XML neden?


Neden bu kadar çok proje yapılandırma dosyaları için XML kullanıyor?


44


Menşei


Bir gün, birisi yapılandırma problemini XML ile çözmeye karar verdi. Şimdi iki problemi vardı. - B T
Neden projeyi sormak daha iyi olabilir x, y, ve z (yani, jabberd), "çok fazla" projenin bunları neden kullandığını değil, XML yapılandırmasını kullanır. Daha sonra elde edeceğiniz cevaplar, gerçeklere ve kayıtlara dayandırılabilir, ancak yine de "subjektif olarak kullanılacak olan yapılandırma dosyaları için XML kullanmanın hangi zorunlulukları vardır?" - Iiridayn


Cevaplar:


Bu önemli bir soru.

Çoğu alternatif (JSON, YAML, INI dosyaları) Daha kolay XML'den ayrıştırmak için.

Ayrıca, her şeyin kaynak olduğu Python gibi dillerde - yapılandırmanızı açıkça etiketlenmiş bir Python modülüne koymak daha kolaydır.

Yine de, bazı insanlar XML'in JSON veya Python üzerinde bir avantajı olduğunu söyleyecektir.

XML ile ilgili önemli olan, XML sözdiziminin "evrenselliği" nin, bir uygulamaya özgü bir yapılandırma dosyası yazarken gerçekten çok fazla uygulanmadığıdır. Bir yapılandırma dosyasının taşınabilirliği önemli olmadığından, bazı Python üyeleri yapılandırma dosyalarını Python'a yazar.


Düzenle

Bir yapılandırma dosyasının güvenliği önemli değil. "Python'da bir Python programının yapılandırılması bir güvenlik riskidir" argümanı, Python'un önceden yüklenmiş ve kaynak olarak çalıştırıldığı gerçeğini görmezden geliyor gibi görünüyor. Kaynağa sahip olduğunuzda neden bir yapılandırma dosyasında karmaşık bir kesmek çalışır? Sadece kaynağı kır.

Arkadaşların, "birisinin" uygulamanızı yapılandırma dosyası aracılığıyla kesebileceğini söylediğini duydum. Kim bu "birileri"? Sysadmin? DBA? Geliştirici? Konfigürasyon dosyalarına erişimi olan çok fazla gizemli "birisi" yok.

Python konfigürasyon dosyasını haksız amaçlarla ele geçirebilecek herkes muhtemelen keylogger'ları, sahte sertifikaları veya diğer daha ciddi tehditleri yükleyebilir.


38



Yapılandırma dosyasının taşınabilirliği önemli değil, doğru. Ancak, yapılandırma dilinin etki alanının güvenlik nedenleriyle kısıtlanması önemlidir; Tam donanımlı genel amaçlı bir dil, çoğu yapılandırma gereksinimi için çok geniştir ve bu durumlarda gereksiz bir güvenlik riski taşır. - bignose
Bignose Yapılandırmaya "en çok yapılandırma gereksinimleri" erişim kaynağına erişim anlamına gelir. Geri kalan durumlarda, dilin beyaz listeye alınmış bir alt kümesinin oluşturulması yeterli olmalıdır (yani dizeler, değişkenleri tanımlamak, geçerli dilbilgisi alt kümesini bile kabul edebilir). YAGNI. - Iiridayn
Bignose eski bir konu ama Python felsefesiyle aynı fikirdeyim ki bu da ben de aynı fikirdeyim. "Kullanıcıya güven." İşe alma moronları, kendinizi kötü dil seçenekleriyle korumayı denemekten daha güvenli tutacaktır. - Erik Reppen
@Iiridayn Küçük bir güvenlik kaygısı var, ancak perspektifte kalmanın oldukça önemli olduğuna inanıyorum. Python'da yazılmış ayrıcalıklı bir programınız varsa Python kod dosyalarını, ayrıcalıklı olmayan kullanıcılardan yapılandırma dosyaları olarak yalnızca sınırlı bir görev kümesi yapmak için çalıştıran bir programınız varsa, bu, keyfi komut yürütme istisnasıyla önemsiz bir yerel ayrıcalık yükselmesidir. Yazılımın büyük çoğunluğu için geçerli değildir, ancak güvenlik görevlileri gerçekten paranoyak olma eğilimindedirler ve bir sistemin her parçasını mümkün olduğu zaman kötüye kullanmaya daha az meyilli hale getirmek için tartışırlar. - mtraceur


  1. XML ayrıştırması kolaydır. Çoğu dilde kullanılabilen birkaç popüler, hafif, dikkatli ve / veya ücretsiz XML ayrıştırma kütüphanesi vardır.
  2. XML okunması kolaydır. Bu, insan tarafından okunabilir bir biçimlendirme dilidir, bu yüzden bilgisayarların yazabileceği kadar insanlar için yazması da kolaydır.
  3. XML belirtildi. Herkes ve köpeği iyi bir XML yazmayı bilir, bu yüzden sözdizimi hakkında bir karışıklık yoktur.
  4. XML popülerdir. Yol boyunca bir yerlerde, bazı Önemli İnsanlar, XML'in “gelecek” olduğu fikrini bastırmaya başladı ve birçok insan bunu satın aldı.
  5. XML, çift yönlü bir formattır. Bu boşluk, yorum ve sipariş korunur. Biçimlendirmeyi korurken programlı olarak yükleyebilir, değiştirebilir ve kaydedebilirsiniz. Bu, kullanıcıların uygulamalarını yapılandırmak için kullanabilecekleri araçlar için önemlidir. Orijinal olarak XML'in çıkarılmasının nedenlerinden biri (dünya daha teknik hale geldi, bu yüzden daha az ihtiyaç duyuldu).
  6. XML'de isteğe bağlı şema doğrulaması var. Araçlar ve karmaşık yapılandırma formatları için önemlidir.
  7. XML'de ad alanları vardır. Bu, diğer yapılandırmaların veya ek açıklamaların ayrıştırmayı etkilemeyle gömülmesine izin verir. Diğer yapılandırma biçimlerinde, bu genellikle, özel yorum veya özellik adı kesmesiyle yapılır.

Yan not olarak, XML'i savunmaya çalışmıyorum. Onun kullanımları var ve ben buna geri döndüğümde onu bir projede kullanacağım. Birçok durumda, özellikle de özellikle yapılandırma dosyaları, sahip olduğu tek avantaj, standart bir format olmasıdır ve bence bu, çok sayıda dezavantajla (yani, çok fazla verimsiz) daha ağır basmaktadır. Ancak, kişisel tercihlerim önemli değil - Sadece bazı kişilerin neden XML'i bir yapılandırma dosyası formatı olarak kullanmayı seçebileceğini açıklıyorum. Şahsen asla yapmayacağım.


30



Tüm noktaların genel olarak XML'in geçerli avantajları olduğunu düşünüyorum; Ancak, yapılandırma dosyaları ile ilişkiyi göremiyorum. Birçok durumda, basit bir ini dosyası, ayrıştırması kolay olacak ve XML'den yazmak ve okumaktan çok daha kolay olacak şekilde yapılandırma için yapacaktır. - Dirk Vollmar
@divo - INI dosyaları Windows merkezli ve diğer platformlarda Windows'a göre daha iyi destekleniyor. Unix, Unix'te diğer platformlardan daha iyi desteklenen kendi Unix merkezli konfigürasyon dosya formatlarına sahiptir. XML, her yerde eşit olarak desteklenme avantajına sahiptir. Ayrıca, XML daha hiyerarşik yapıya izin verir - INI dosyaları XML gibi derin iç içe geçmeye izin vermez. - Chris Lutz
1, 3 ve 4 numaralı noktaları kabul ediyorum. Ama "XML'in okunması kolay, insan tarafından okunabilir bir biçimlendirme dilidir, bu yüzden insanlar için yazması kolaydır"; şüphesiz sen jest misin? Şu anda habersiz olduğum "insan" kelimesinin farklı bir tanımı var mı? - bignose
Bazı insanlar için okumak için ne kadar zor <özellik özniteliği "> bar </ property> beni şaşırtmak asla başarısız olmaz. Aynen lanetlenmiş metrik sistem gibi! - annakata
Aslında XML'in ayrıştırılmasının zor olduğunu düşünüyorum. Ben de onu insan tarafından okunabilir bir format olarak görmüyorum. - elcuco


Çünkü XML kulağa hoş geliyor ve enterprisey.

Düzenleme: Cevabımın çok belirsiz olduğunu anlayamadım. enterprisey. Vikipedi:

[...] “enterprisey” terimi, büyük organizasyonlar için bile yazılımın çok karmaşık olduğunu ve daha basit ve kanıtlanmış çözümlerin mevcut olduğunu ima etmek için “daha ​​küçük organizasyonlar için aşırı” endişesinin ötesine geçmeyi amaçlamaktadır.

Benim amacım, XML'in bir "bülten" olduğu ve bu şekilde aşırı kullanıldığı. Diğer görüşlere rağmen, XML ayrıştırması kolay değildir (sadece libxml2'ye bakın, gzipli kaynak paketi şu an 3MB'nin üzerindedir). Fazlalık miktarından dolayı, elle yazmak da can sıkıcıdır. Örneğin, Vikipedi listeleri XML yapılandırması popülaritesinin azalmasının sebeplerinden biri olarak jabberd diğer uygulamalar lehine.


24



Neden düşüşler? Alaycı bir cevap olmasına rağmen, XML'in bu kadar popüler olmasının oldukça geçerli bir nedeni var. Tek sebep değil, kesinlikle, ama önemli olan. - Chris Lutz
Desteğin için teşekkürler, Chris. - avakar
Aynı zamanda XML'in basması da popüler gibi görünüyor. Onun yerine ne kullanırsınız, ör. uygulama yapılandırması veya veri aktarımı için İnsanlar nadiren alternatifler sunarlar. Özel durumunuzda özel durumunuz için biraz ayrıntılı olabilir. Ama bu isabeti ayrıştırmak, dönüştürmek, sorgulamak ve doğrulamak için araçlara sahip olacağım. - JonoW
JonoW, XML kesinlikle geçerli kullanımlara sahiptir. Ben kesinlikle yapılandırma dosyaları hakkında konuşuyorum. Çoğu durumda buna inanıyorum key=value sadece yeterli değil, aynı zamanda daha okunaklı ve ayrıştırılması daha kolaydır. - avakar
Avakar, siz basit ayarlar için bir fikir üretiyorsunuz ama XML'in daha iyi olduğu için daha da genişletilebileceğini savunuyorum. Örneğin, aynı ada sahip bir nesne listeniz olabilir (örneğin, bir dizin listesi) - sadece aynı değeri birçok kez çağırır mısınız? bir numara eklemek Aldığım şey, XML'in kolayca takip edilebilen bir standart olmasıdır. - Kenny Mann


XML, gelişmiş konfigürasyon formatlarından daha kolay okunmasını ve anlaşılmasını sağlayan iyi geliştirilmiş ve benimsenmiş bir standarttır.

Ayrıca, XML serileştirme işleminin birçok dilde mevcut olan ve nesnelerin geliştiricilerin için son derece kolay bir şekilde kaydedilmesini sağlayan yaygın bir araç olduğunu anlamaya değer. Birisi sizin için işi daha önce yaptığında neden karmaşık bir veri hiyerarşisini kaydetme yolunuzu kendiniz yaratın?

.AĞ: http://msdn.microsoft.com/en-us/library/system.xml.serialization.aspx

PHP: http://us.php.net/serialize

Python: http://docs.python.org/library/pickle.html

Java: http://java.sun.com/developer/technicalArticles/Programming/serialization/


13



turşu ve xml arasındaki ilişki nedir? - maazza


Cevaplarınız için teşekkürler. Bu soru, ilk bakışta göründüğü kadar naif olarak çok naif değildi :)

Kişisel olarak XML dosyalarını yapılandırma dosyalarını sevmiyorum, insanların okuması ve değişmesi zor oluyor ve bilgisayarların ayrıştırılması çok zor çünkü çok genel ve güçlü.

INI dosyaları veya Java prova dosyaları, yuvalamayı gerektiren en basit uygulamalar için iyidir. Bu biçimlere yuvalama eklemek için ortak çözümler şöyle görünür:

level1.key1=value
level1.key2=value
level2.key1=value

güzel bir manzara değil, çok fazlalık ve düğümler arasındaki şeyleri taşımak zor.

JSON kötü bir dil değildir, ancak bilgisayarların ayrıştırılması kolay olacak şekilde tasarlanmıştır (geçerli JavaScript), bu yüzden yapılandırma dosyaları için çılgınca kullanılmaz.

JSON buna benzer:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}}

Benim düşünceme göre, virgül ve tırnak ile çok dağınık.

YAML yapılandırma dosyaları için iyi, burada bir örnek:

invoice: 34843
date   : 2001-01-23
bill-to: &id001
    given  : Chris
    family : Dumars

bununla birlikte, sözdizimini çok fazla sevmem, ve kapsamları tanımlamak için boşlukları kullanmanın bazı şeyleri biraz kırılgan hale getirdiğini düşünüyorum (bir bloğu farklı bir yuva seviyesine yapıştırmayı düşünün).

Birkaç gün önce konfigürasyon dosyası için kendi dilimi yazmaya başladım. Swush.

İşte birkaç örnek: Basit bir anahtar-değer çiftleri olarak:

key:value
key:value2
key1:value3

ya da daha karmaşık ve yorumlu olarak

server{
    connector{
         protocol : http // HTTP or BlahTP
         port : 8080     # server port
         host : localhost /* server host name*/
    }

    log{
        output{
             file : /var/log/server.log
             format : %t%s
        }
    }
}

Swush, yukarıdaki basit formdaki dizeleri ya da tırnak içinde - dizeleri içinde boşlukları ve hatta yeni satırlara izin veren tırnakları destekler. Yakında dizileri ekleyeceğim, bazı şeyler gibi:

name [1 2 b c "Delta force"]

Bir Java uygulaması var, ancak daha fazla uygulama hoş geldiniz. :). daha fazla bilgi için siteyi kontrol et (çoğu zaman kapsaydım, ama Java API'si seçiciler gibi birkaç ilginç özellik sunuyor)


9



Genel bir yapılandırma ayrıştırıcısı yapmaya çalışıyorsanız, belki de iki nokta üst üste işareti eşittir. Böylece, birçok mevcut yapılandırma dosyasını da ayrıştırabilirsiniz. - avakar
Bu iyi bir nokta ve bunu düşündüm. ama sanırım anahtar: değer anahtardan daha okunabilir = değer düşünün: bağlayıcı {protokol: http // HTTP veya BlahTP bağlantı noktası: 8080 # sunucu bağlantı noktası barındırıcısı: localhost / * sunucu ana bilgisayar adı * /} vs: bağlayıcı {protocol = http / / HTTP veya BlahTP bağlantı noktası = 8080 # sunucu bağlantı noktası ana bilgisayarı = localhost / * sunucu ana bilgisayar adı * /} İlk olarak bir tane daha iyi gibi, ne düşünüyorsun? - Omry Yadan
dışarı, yorumlar kod örnekleri için gerçekten kötü. - Omry Yadan
Bu zaten libconfig'te var. - Coyote21
Bu çok uzun bir "cevap", ama soruya cevap vermiyor. Sadece bir tanesini seçmeden önce bir grup farklı veri formatını eleştiriyor. - Quentin


Başka bir nokta, yapılandırma dosyanızı tanımlamak için bir XSD (şema dosyası) varsa, uygulamanızın yapılandırma dosyasını doğrulaması önemsizdir.


8



Herhangi bir şema size bu avantajı getirecektir. XSD tek şema dili değildir. - bortzmeyer
XSD tek şema dili değil - alternatifler neler? - Gill Bates


XML'i ayrıştırma nispeten kolaydır ve şemanınız açıkça belirtilmişse, herhangi bir yardımcı program kolayca bilgi okuyabilir ve yazabilir.


3



Neden yapılandırma için yardımcı programlara ihtiyacımız var? Yapı yardımcı programdı. Şimdi C # ve Java'da bu lanet bir lanet. - Erik Reppen


Eh .., XML, açıklamaları, iç içe geçmiş bilgileri ve bir şeyle ilgili verileri tutabilen genel amaçlı bir belirtimdir. Ve onu ayırabilen ve okuyabilecek birçok API ve yazılım var.

Öyleyse, çapraz platformlar ve uygulamalar bilinen resmi bir şekilde bir şeyi tanımlamak çok kolay.


2



Wah! Benim yazma sırasında 5 cevap: S etkileyici - Saleh Al-Zaid


İşte bazı tarihi nedenler:

  • W3C, Perl’deki Java’dan araçlara taşındı.
  • Apache temeli Perl'deki Java'dan araçlara taşındı.
  • Java çok var XML API'ları
  • Yapılandırma bu nedenle Java'da yapılabilir
  • XML ile yapılandırma ve özellikler dosyaları Java dışındaki geliştiriciler içindir

JTidy yapılandırma vs düzenli Yapılandırma bunun en iyi örneğidir.


1



Bunlar çok zorlayıcı sebepler değil. Java destekli Java desteği Java 1.3 veya 1.4'e eklenmiştir, kesinlikle iyi bir erken seçim değildir. - Omry Yadan
@OmryYadan yaratıcının sloganı hepsini söylüyor: Java + XML / Portable Code + Portable Data. Hindsight 20/20 - Paul Sweatte


Bunun nedeni XML'in temel olarak kendi anlamsal işaretlemenizi yapabilmenize olanak tanımasıdır; bu, hemen hemen her dilde yazılmış bir ayrıştırıcı tarafından okunabilir. Ek bir avantaj, XML'de yazılmış yapılandırma dosyasının, iki veya daha fazla dil kullandığınız projelerde kullanılabilir olmasıdır. Eğer her şeyin belirli bir dil için değişken olarak tanımlandığı bir konfigürasyon dosyası oluşturuyor olsaydınız, açıkçası sadece o dilde çalışırdı.


0