CSV dosyalarında virgül neden kötü bir kayıt ayırıcı / sınırlayıcıdır?


32

Bu makaleyi okuyordum ve bu sorunun doğru cevabını merak ediyorum.

Aklıma gelen tek şey, belki de bazı ülkelerde ondalık ayırıcının virgül olmasıdır ve CSV'de veri paylaşırken sorun olabilir , ancak cevabımdan gerçekten emin değilim.


6
Neredeyse herhangi bir sınırlayıcı virgülten iyidir. Bunun nedeni, virgülle ayrılmış dosyalar bazı veri ayrıştırma araçlarına okunduğunda, virgüllerin noktalama işaretleriyle karıştırılarak alanların veya sütunların "düzenini" bozmasıdır.
Mike Hunter,

33
Bir sinik, bu makalenin bir SAS puf parçası olduğuna dikkat çekerek, SAS'ın virgülle CSV dosyalarını işlerken sorun yaşayabileceğini düşünebilir :-).
whuber

3
@whuber - SAS (deneyimlerime göre), CSV dosyalarında, virgül olup olmadığına bakılmaksızın, SAS'ın sevmediği her garip şey için büyük miktarda el kodlaması gerektirerek mücadele edebilir.
Jeremy Miles,

8
Her zamankinden daha belirsiz sınırlayıcılar arayışında bir çaresizlik var - borular, pilcrowlar, dikenler - bir standardın üzerinde hemfikir olmak ve bunu takip etmek, insanların sınırlandırılmış metin dosyalarında veri alışverişinde bulunmanın tek güvenli yolu olduğunu gösteriyor. Ve evrensel bir standart, bazılarının başka bir işe koyulması gerekmeyeceği varsayımına dayanmak yerine, herhangi bir metin dizesinin temsil edilmesine (RFC4180'de olduğu gibi) izin vermelidir.
Scortchi - Eski Monica

2
(a) .csv dosyalarını sıklıkla içe aktardım. (b) İnsanlara, verileri içerisinde virgül varsa .csv kullanmamalarını öneririm. Bunlar birbiriyle çelişmez. (B) bazı mahallelerde açıklamaya ihtiyaç duyması talihsiz bir durumdur.
Nick Cox

Yanıtlar:


33

CSV format özelliği RFC 4180'de tanımlanmıştır . Bu özellik yayınlandı çünkü

CSV dosyalarının çok çeşitli yorumlarına izin veren, resmi bir şartname bulunmamaktadır.

Ne yazık ki, 2005'ten beri (RFC'nin yayınlanma tarihi) hiçbir şey değişmedi. Hala çok çeşitli uygulamalarımız var. RFC 4180'de tanımlanan genel yaklaşım, virgül gibi karakterleri tırnak içine alan alanları içine almaktır, ancak bu öneri her zaman farklı yazılımlar tarafından karşılanmamaktadır.

Sorun, çeşitli Avrupa bölgelerinde virgül karakterinin ondalık sayı olarak işlev görmesidir, bu yüzden 0,005bunun yerine yazarsınız 0.005. Yine de diğer durumlarda, basamak gruplarını işaret etmek için boşluk yerine virgül kullanılır, örneğin 4,000,000.00( buraya bakın ). Her iki durumda da virgül kullanmak, muhtemelen csv dosyalarından veri okumada hatalara yol açar, çünkü yazılımınız 0,005, 0,1iki sayı mı yoksa dört farklı sayı mı olduğunu gerçekten bilmez ( buradaki örneğe bakın ).

Son olarak, en az değil, metni metin dosyanızda saklarsanız, o zaman virgüller metinde, örneğin noktalı virgüllerden daha yaygındır; bu nedenle, metniniz tırnak içine alınmazsa, bu tür verilerin kolayca hatalarla okunabilmesi için .

Hiçbir şey virgüllerin daha iyi olmasını veya CSV dosyalarının yukarıda açıklanan sorunlara karşı koruma sağlayan RFC 4180'in tavsiyelerine uygun olarak kullanıldığı kadarıyla alan ayırıcılarını daha iyi hale getiremez. Bununla birlikte, alanları tırnak işaretleri içine almayan basitleştirilmiş CSV formatını kullanma riski varsa veya öneri tutarsız bir şekilde kullanılabilirse, diğer ayırıcılar (örneğin noktalı virgül) daha güvenli bir yaklaşım gibi görünmektedir.


6
RFC 4180 tarafından tanımlandığı gibi gerçek CSV standardını uygulayan herhangi bir yazılım kesinlikle herhangi bir dizenin nasıl yorumlanacağını kesinlikle bilir. Daha ,nadir bir ayırıcı yerine kullanılmasının argümanı verileri engellediği için her zaman kaçmak zorunda olduğunuz için doğrudur. Ve tabii ki, CSV'nin nasıl çalıştığını bildiklerini ama gerçekten işe yaramadığını sanan insanlar var.
Voo

2
Evet @Voo ama çünkü "csv" dosyalar böyle kaotik bir şekilde kullanılmaktadır o virgül kullanmak yerine bunların örneğin noktalı virgül diğer ayırıcılar kullanmamayı daha güvenlidir. OP sorusunun cevabı budur. Noktalı virgüllerde (veya diğer virgül dışı) virgüllerle karşılaştırıldığında "daha iyi" bir şey yoktur, bunlar çoğu zaman yalnızca daha güvenlidir.
Tim

2
Yorumlarınıza @Voo +1. Ancak, CSV kullanan hiç kimse gerçekten şişirilmiş veri dosyalarını önemsemez!
whuber

17

Teknik olarak virgül, ayırıcı olarak kullanılacak herhangi bir karakter kadar iyidir. Biçimin adı doğrudan değerlerin virgülle ayrıldığını belirtir (Virgülle Ayrılmış Değerler).

CSV formatının açıklaması ayırıcı olarak virgül kullanıyor.

Virgül içeren herhangi bir alan çift alıntı yapılmalıdır. Bu, verileri okumak için sorun yaratmaz. Açıklamadaki 6. maddeye bakınız :

  1. Satır kesmeleri (CRLF), çift tırnak işaretleri ve virgüller içeren alanlar çift tırnak işaretleri içine alınmalıdır.

Örneğin, işlevler read.csvve write.csvR'den varsayılan olarak ayırıcı olarak virgül kullanıyorlar.


4
Bu en iyi cevap, valuesvirgülle ayrılmış olduğu anlamına gelir . formattingSayıları avrupalı ​​isteyen diğerleri standard, yukarıdaki 6. maddeyi doğru bir şekilde belirttiğiniz gibi, bu csv için bir sorun değildir . "Doğru kullanım" dan sapmalar herhangi bir veri formatıyla mevcuttur. Mesele şu ki - verilerinizi bilin. Diğerleri bahsetti tabveya ;sınırlandırdı, ancak bunlar kullanıcı tarafından girilen verilerle uğraşırken virgüllerle aynı sorunlara sahip olabilir (belki bir form aracılığıyla ve bir veritabanıyla ele geçirilmiş olarak - insanların girdiği serbest metin giriş alanlarıyla uğraşmak zorunda kaldım) yağ parmaklı tab... içinde berbat) var
Adrian Torrie

Tim'in cevabı şimdi sağlanan @djhurio bilgisini içerecek şekilde düzenlendi.
Adrian Torrie

11

Rakamlarla rakam ayırıcı olmasının yanı sıra, birçok ülkede adresin (müşteri adresi vb. Gibi) bir parçasını oluşturur. Bazı ülkelerde kısa iyi tanımlanmış adreslere sahip olmakla birlikte, diğerlerinde, aynı satırda iki virgül de dahil olmak üzere uzun sarma adresleri vardır. İyi CSV dosyaları, tüm bu verileri çift tırnak içine alır. Fakat aşırı basit, kötü yazılmış ortaklar, okuma ve farklılaştırma için yeterli değildir. (O zaman, şiirden alıntı gibi verilerin bir parçası olarak çift tırnak kullanma problemi vardır).


2
(+1) Standart, tekrardan iki katına çıkmakta ısrar ederek verinin bir parçası olarak çift tırnak kullanımını sağlar: "Belloc", "Tarantella", "" "Yüksek Pirenelerde" "pire yapan pire. İngiltere'de alıntı yapılan evin adını içeren adres alanlarını bulmak nadir değildir: "Chatsworth", Melton Road, Leamington. (Neden olduğu belli değil: Fowler, "sonuç şu görünüyor: mantıklı insanların '164 Melton Yolu' olarak adlandırdığı evde yaşamak, ancak bir aptal 'Chatsworth' demeyi sever"
demişti

1
@Scortchi Görünüşe göre aynı şiirler 12 yaşındayken (+/- hata). 20. yüzyılın başlarında talihsiz olarak okuduğumun, alt orta sınıfın alışkanlıkları için üst orta sınıfın İngilizce merakını küçük bir grubun ötesinde saydam olmayacağına dair son örneğinizi gizlemekten korkuyorum.
Nick Cox

@NickCox: Sağa on iki ses geliyor. Komik hatırlayamıyorum o olsun bu yıl herhangi şiir okumam şöyle dursun, onlardan herhangi satırları hatırlamak. Fowler'in amacı, gereksiz tırnak işaretlerinin okuyucusu üzerindeki etkisi ile ilgili olmasına rağmen (bkz. Gereksiz quotes.com ), sanırım seçtiği örneklemede züppeğin etkisini görmekte haklısınız. Her neyse, inanıyorum ki, İngilizce adresleri içeren bir CSV dosyası göndermişseniz, dikkatlerime rağmen, açık bir şekilde dikkat etmeniz gereken bir nokta var.
Scortchi - Eski Monica

1
Hindistan'da, ilk evlerini (apartmanları değil) inşa edenlerin, genellikle yerel bir dilde veya Sanskritçe bir cümle içinde yenilikçi bir çiçekli isim bulundurmaları ve "Guru Kripa" gibi çift tırnaklı bir isim vermeleri yaygındır. Genelia D'Souza ve Derek O'Brien gibi isimler de yaygındır. Ardından, hükümetin yeniden numaralandırılması nedeniyle "Eski Kapı No. nnn / Yeni Kapı No. mm / c" diyen adresler, beklenmeyen köşelerde eğik çizgiler ve tek tırnaklar olması nedeniyle adres deposunu daha da karmaşık hale getiriyor.
Whirl Mind

@WhirlMind: Bu ilginç - Çok fazla şey bekledim - beklediğimden daha fazla - İngiltere'deki Scottish Gaelic & Welsh ev isimleri, belki de evinizi isimlendirmek için yerel bir dil seçmeye en yakın olanı.
Scortchi - Monica'yı Yeniden Başlatın

9

@Tim in cevabı doğru olsa da - bir bütün olarak "csv" nin ortak bir standardı olmadığını, özellikle kaçan kuralların tanımlanmadığını, bir programda okunabilen, ancak bir programda okunabilen "formatlara" yol açtığını eklemek isterim. . Bu, güneşin altındaki her "programcı" nın "oooh csv - düşündüğümde" kendi ayrıştırıcımı yapacağım! ve sonra tüm kenar durumlarda özlüyor.

Dahası, csv, meta verileri ve hatta bir sütunun veri türünü saklama yeteneğinden tamamen yoksundur - bu, verileri anlamak için okumanız gereken bazı belgelere yol açar.


5
Evet, standart tools.ietf.org/html/rfc4180 ve diğer birçok format herhangi bir meta veri depolamaz, sadece meta verileri depolamak için tasarlanmamıştır - .txt dosyaları da metin belgeleri hakkındaki meta verileri depolamaz ...
Tim

4
Tim, standart it a standart dışı ,,, yapım daha sık değil göz ardı edilir
Christian Sauer

8
Standartlarla ilgili en güzel şey, aralarından seçim yapabileceğiniz çok fazla olmasıdır. (Çeşitli şekillerde mutasyona uğramış ve atfedilmiştir.)
Nick Cox

4

Virgül sınırlayıcıyı çıkarabilir ve bir sekme karakteri kullanabilirseniz çok daha iyi bir başarı elde edersiniz. .CSV isimli dosyayı bırakabilirsiniz ve çoğu programa içeri aktarmak genellikle bir sorun değildir. Dosyanızı içe aktarırken virgül yerine TAB ile sınırlandırılmış olarak belirtin. Verilerinizde virgül varsa, bildiğiniz gibi virgül belirtilirken bir probleminiz olacak.


5
Verilerinizde sekmeler varsa, görüşme uygulanır. Sadece, en azından deneyimlerime göre, daha az muhtemel.
Nick Cox

@Nick ve Gorilla: |Evde yayınlanmış csv benzeri metin dosyalarında (kitap başlıkları ve diğer belge meta verilerinde) sınırlayıcı olarak iyi sonuçlar elde ettim . |Çalıştığım verilerde asla ortaya çıkmaz, bu yüzden herhangi bir alıntı yapmak için kontrol etmeden basitçe bölünen / birleştirilen perl komut dosyaları yazabilirim. Bu, yalnızca MS Access veritabanından kaydedilen meta verilerin işlenmesini içeren tek seferlik bir proje içindi. Daha büyük projeler için veya bu dosya biçiminde uzun süre veri saklamayı planlıyorsanız, daha sağlam bir şey seçin! Bu ayki parti bir şeyleri kırarsa her zaman bir şeyleri değiştirebilirim.
Peter Cordes

@PeterCordes Sana inanıyorum ve ne işe yarıyorsa. Ancak, açıkça kendine has ayraçların maliyeti, bunları başkalarına açıklama ihtiyacı olabilir ve bu tür veri dosyalarını zorlamadan içe aktarabilmelerinin anahtarıdır. Alışılmadık bir dosya biçimiyle karşı karşıya kalındığında, dizeleri rastgele ayırıcılar üzerinde bölebilecek bazı yordamlara, işlevlere veya komutlara erişebilmek gerekir.
Nick Cox

@PeterCordes splitStata için bir komut yazdığımda , diğerlerinin yanı sıra, ne yaptığını ve ne yapmadığını görmek için Perl eşdeğerine baktım. Kaynak kod değil, sadece sunulan işlevsellik.
Nick Cox

1
@NickCox: Bir çok perl fonksiyonu IMO. İşi sizin awk (ki genellikle iyi olan) veya esp. diğer Unix araçları gibi cut, sortve uniq.
Peter Cordes

4

ASCII bize ascii (7) * nix man sayfasından bir snippet'te gösterildiği gibi dört "ayırıcı" karakter sağlar:

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

Bu cevap , kullanım amaçlarına iyi bir genel bakış sağlar.

Elbette, bu kontrol kodları daha popüler sınırlayıcıların insan dostu (okunabilirlik ve girdi) lerinden yoksundur, ancak programlar arasında dahili ve / veya geçici veri alışverişi için kabul edilebilir seçimlerdir.


2
İlginç. Bunları vahşi doğada gördüğümü sanmıyorum ...
Matt Krause

4

Sorun virgül değil; sorun alıntı. Hangi kayıt ve alan sınırlayıcıları kullandığınıza bakılmaksızın, içerikle tanışmak için hazırlıklı olmanız gerekir. Bu yüzden bir alıntı mekanizmasına ihtiyacınız var. VE SONRA, alıntı karakter (ler) inin görünmesi için bir yola ihtiyacınız var.

RFC 4180 standardına uymak her şeyi herkes için kolaylaştırır.

Şahsen bunu yanlış yapan bir programın çıktısını düzeltmek için bir senaryo yazmam gerekti, bu yüzden biraz militanım. "muhtemelen düzeltme", MY verilerim için çalıştığı anlamına gelir, ancak başarısız olacağı durumları görebilirim. (Bu programın savunmasında standarttan önce yazılmıştır.)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.