Diskussion:CSV (Dateiformat)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „CSV (Dateiformat)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Trennzeichen ?

Ich habe in keiner weiteren Quelle etwas dazu gefunden, dass das Trennzeichen auch (z. B. mit "?") maskiert werden darf. Darum habe ich den Hinweis darauf entfernt. --Jens 21:15, 8. Dez 2004 (CET)

da es keinen allgemeinen standard dafür gibt, kann man das genauso maskieren, wie es der datenimporteur vorsieht. --217.7.68.91 09:40, 1. Aug 2006 (CEST)

Toter Link

Deutsche Bundesbank! (nicht signierter Beitrag von 92.79.150.147 (Diskussion) 11:58, 17. Okt. 2013 (CEST))

noch erwähnbar

Vorteil der csv: auch vom menschen lesbar. eigentlich nur für ein- und zweidimensionale sinnvoll.

ein- und zweidimensionale menschen? --93.198.83.157 13:19, 22. Sep. 2017 (CEST)

"unabhängig von ... "

Das CSV-Format ist unabhängig von Zeichencodierung, [..] und Zeilenumbruchszeichen.

Eine interessante Behauptung. Bitte näher erläutern. --62.225.62.65 10:20, 5. Apr 2005 (CEST)

--- Zu oben --- - Dem CSV Format an sich ist es egal, ob die Zeichencodierung nun ASCII (7-bit), ISO-Latin-1 (2,...9), UTF-8 oder UTF-16 ist. - Genauso ist egal, ob nun eine Zeile (im CSV also ein neuer Datensatz) mit LF, CR oder CRLF getrennt wird.

bei fester feldanzahl benötigt man überhaupt keinen zeilenumbruch. --217.7.68.91 09:40, 1. Aug 2006 (CEST)

Trennzeichen innerhalb der CSV

Kommt das Trennzeichen innerhalb der Datei vor (zumindest bei Excel 2003), so geschieht folgendes: (Stand: 1. Januar 2005)

Inhalt	Gespeichert als
;	";"
""";""";;	""""""";"""""";;"
"""""	""""""""""""

Zuerst dachte ich, es werde immer darauf geachtet, ob zwischen zwei Trennzeichen eine gerade Anzahl Anführungszeichen (") erscheint, und wenn nicht, widr keine neue "Zelle" "gebildet". beim zweiten Beisopiel stimmt dies jedoch nicht.

Wie wird entschieden, ob mit dem Semikolon (;) eine neue Zelle beginnt oder nicht? --Saippuakauppias 19:48, 30. Apr 2006 (CEST)

Das hält sich genau an den RFC 4180 Standard (bis auf die Verwendung von Semikolon zur Trennung statt des Kommas): enthält ein Feldwert Anführungszeichen, ein Trennzeichen oder einen Zeilenumbruch, so wird er auf jeden Fall erstmal mit Anführungszeichen umgeben. Darin vorkommende Anführungszeichen werden dann nochmal "escaped", indem sie verdoppelt werden. --Shepard 14:23, 26. Mär. 2007 (CEST)

csv, "comma" vs. "character" und dsv

in der englischen wikipedia werden csv und dsv separat betrachtet. zu "dsv" siehe auch [1].
das "c" in csv steht fuer "comma"; als abkuerzung fuer "character" oder "colon" wird es nur sehr selten angesehen; siehe auch rfc4180 und [2]. auch die anderssprachigen wikipedias wie die franz., die niederl., die ital. und die span. sprechen nur von "comma". das sollte imho auch hier im artikel klarer gesagt werden. -- 84.56.237.139 09:40, 5. Feb. 2007 (CET)

im deutschen ist dsv IMHO unüblich. --Suricata 10:12, 5. Feb. 2007 (CET)

TSV (tab separated values) ist aber schon relativ gängig. Andererseits - in deutschsprachigen Benutzerobeflächen wird CSV/TSV/etc oft einfach nur als "Text" bezeichnet.

Relativ gängig? Bin seit 20 Jahren Software-Entwickler und lese hier gerade zum ersten Mal von "TSV". :) --93.198.83.157 13:22, 22. Sep. 2017 (CEST)

Ich bin auch der Meinung, dass die Deutung des "c" als "character jeder Grundlage entbehrt. Das Schlimme ist, dass sich so etwas verselbständigt und Gefahr läuft, durch die Erwähnung schon wahr zu werden. Ich bekam von einem Kunden vor einiger Zeit eine als .csv deklarierte Tabulator-getrennte Datei. Auf meine Nachfrage hin wurde ich auf diesen Wikipedia-Artikel verwiesen: Ein Tabulator sei ein "Character" und es sei sowieso nicht festgelegt, wie der Feldtrenner in einer CSV-Datei sei. Zum einen ist ein Tabulator genau genommen nicht einmal ein "Character", sondern ein unsichtbares Zeichen. Zudem hieße das auch, dass jeder beliebige Buchstabe oder eine Ziffer als Feldtrenner verwendet werden könnten und es wäre immer noch eine CSV-Datei. Diese Begriffsanarchie ist nicht hilfreich und unrealistisch. Ich habe die Deutung "Character Separated Values" daher entfernt. Jemand sagte mir, als ich das erzählte, dass er das auch mal "irgendwo bei Microsoft" gelesen habe. Selbst wenn das stimmt, spreche ich dieser Interpretation ganz entschieden die Richtigkeit ab. (Mmaass) (20:15, 11. Jul 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

@Mmaass: Was Du persönlich über dieses Thema denkst, ist hier nicht relevant. Solches nennt man hier Theoriefindung und hat in Artikeln nichts verloren ;-). Du musst solche Behauptungen mit Quellen belegen. Ich habe in den Artikel drei Quellen eingearbeitet, die das Gegenteil bezeugen. Darunter ein Fachbuch und die IT-Abteilung der Deutschen Bundesbank, die ebenfalls Ahnung von diesem Thema haben sollte. Die Erklärung im Fachbuch war einfach: Da CSV nicht normiert sei, und ausser Kommata noch andere Zeichen (beispielsweise Semikolon) gebräuchlich seien, hieße es öfter auch "Character" - Zu den Charakteren gehört auch der von Dir abgelehnte Tabulator. Er ist der ASCII-"control character" mit dem Wert 09. -- Zartonk Was möchtest du loswerden? 23:08, 12. Jul. 2009 (CEST)

@Zartonk: Es ist wirklich schade, was hier passiert. Du bist offenbar auf einem Rachefeldzug, weil - außer Dir - keiner Deinen Artikel "Voting for Plano" für relevant hält und die berechtigte Löschung ansteht. Zudem der einzig sachliche Inhalt darin bereits in einem anderen Artikel erscheint. Und nun gehst Du her und konzentrierst Dich darauf, den Kritikern, die Du greifen kannst, mal systematisch zu zeigen, das hier alles möglich ist. Du opferst jede Aufrichtigkeit und Sachlichkeit auf dem Altar Deines persönlichen Feldzuges. Nun gut. Ich kann nur wiederholen, dass die unverhohlene Aggressivität Deines Verhaltens von Deinem Signatur-Claim "Was willst Du loswerden?" sehr gut belegt wird. Es ist schade, dass für Dich ganz offenbar nicht die Bewahrung und Schaffung von Wissen, sondern "Recht haben" und persönliche Angriffe im Vordergrund stehen.

Zur Sache: Grundsätzlich wird ein Fehler wie der, "csv" als "character separated values" zu explodieren, nicht allein dadurch richtig, dass ihn - vorgeblich - viele machen. Im Gegenteil ist genau dieses "zusammengekochte" Scheinwissen, das Quantität der Quellen vor Qualität setzt, das Problem. Etwas wird nicht dadurch wahr oder richtig, dass es möglichst häufig genannt oder geglaubt wird. Es gibt zahlreiche sachliche Anhaltspunkte, die der Deutung "character" einfach ganz klar widersprechen.

Auch große Unternehmen, wie z.B. die Deutsche Bundesbank, machen Fehler oder übernehmen Fehler von anderen. Gerade denen passiert so etwas. Dafür gibt es unzählige Beispiele. Die wissenschaftliche Relevanz dieser Informationsschrift ist nicht all zu hoch anzusetzen. Sie enthält keinerlei Hinweise auf die Person oder Qualifikation des Autors oder der Autorin. Das Erscheinungsdatum 04.082008 liegt zeitlich deutlich nach dem Wikipedia-Artikel. Es ist überhaupt nicht auszuschließen, dass der Autor/die Autorin diese falsche Deutung einfach von hier übernommen hat. Wäre das so, hätte bereits die Selbstreferenzierung stattgefunden, vor der ich so warne. Und der Feldtrenner ist -auch bei der Bundesbank - mit ziemlicher Sicherheit ein Semikolon oder ein Komma.

Ähnliches gilt für die FAQ-Antwort von STRATO. Was ist die Qualifizierung dieser Quelle? Allein die Tatsache, dass es STRATO ist, reicht mir absolut nicht aus. Im Gegenteil ist das genau der Beleg für meine These, dass sich die Falschdeutung verbreitet. Wer ist der Autor? Woher hat er oder sie das mit dem "character"? Was ist den faktisch der Feldtrenner? Ein Semikolon oder ein Komma. Ganz sicher.

Es ist ja nicht so, dass diese Autoren die Deutung erfunden haben oder selbst darauf gekommen sind. Und wenn, dann wäre das ein Beleg dafür, dass hier Willkür herrscht. Das "Fachbuch" kann ich jetzt nicht prüfen, weil es mir nicht vorliegt, werde es aber bei nächster Gelegenheit tun. Jeder kann ein Buch schreiben und darin etwas behaupten. Auch hier ist nur entscheidend, woher der Autor diese Deutung hat und wie er sie nennt. Leider bist Du beim Zitieren auch in anderen Fällen nicht sehr präzise gewesen und schreibst Zitate falsch ab oder änderst z.B. "ansonst" zu "sonst". Das mag im genannten zu vernachlässigen sein, spricht aber Bände über die Präszision und Wissenschaftlichkeit der Beweisführung. Zudem kann man das Zitat durchaus so lesen, dass es mein These stützt. Genauer gesagt, kann man es eigentlich kaum anders verstehen. Der Autor verweist hier einzig empirisch darauf, dass csv auf eine bestimmte Art verstanden wird. Mit keinem Wort aber, dass das die eigentliche Bedeutung der Abkürzung ist.

Und in diesem Wikipedia-Artikel geht es ausdrücklich um die wahre Bedeutung des "c" in "csv", nicht um Eselsbrücken, Merkhilfen oder nachgeschobene Erklärungen, oder sprachevolutionäre Phänomene mit denen man sich etwas scheinbar besser merken kann. Der Autor schreibt (wenn Dein Zitat vollständig und richtig ist): "Die häufigste Variation ist der Austausch des Kommas durch ein anderes Trennzeichen, weswegen CSV oft auch als Akronym für Character Separated Values verstanden wird". Das Zitat brichst Du dann ab, was ich für bedenklich halte, aber das steht auf einem anderen Blatt. Der Autor schreibt ganz deutlich "verstanden wird". Ob das damit gleichzusetzen ist, dass das "c" für "chracter" steht, stelle ich vehement in Zweifel. Es wird so "verstanden"! Das mag wohl sein, aber wir bewegen uns hier auf dünnem Eis. Wo und von wem wird das so verstanden? Zudem ist zu klären, ob es sich um eine Übersetzung handelt und der Übersetzer möglicherweise selbständig etwas ergänzt hat.

Weil Du aber alles daran setzen wirst, mir persönlich - ohne Rücksicht auf die Sache Wikipedia und die Vernunft - zu schaden, halte ich es nicht für sinnvoll, dass ich in dieser Sache weiter Zeit investiere. Vielleicht rufen andere Dich zur Ordnung - Du bist ja nicht nur in diesem Artikel in dieser Manier unterwegs - oder Du kommst selbst zur Vernunft.

Zum Abschluss verweise auch auf den mehrfach angeführten Hinweis anderer, dass die Deutung "character" oder "colon" (Doppelpunkt) in keiner anderen Sprache von Wikipedia genannt wird. Vielleicht kommt mir ja jemand zur Hilfe, der rationale Argumente liefern kann, damit diese unselige Zweit- und Drittdeutung "character" oder "colon" hier endgültig verschwindet. Sie ist einfach nur falsch und willkürlich. --mmaass 12:53, 13. Jul. 2009 (CEST) (ich hoffe, hier erscheint jetzt meine Signatur, irgendwie klappte das bisher nicht, es war aber keine Absicht)

Ich habe jetzt die Trefferzeile bei scholar.google.com und books.google.com verglichen. Mein Verdikt:

• CSV als Abkürzung von "character separated values" ist nicht seltener sondern selten (um 5%)
• CSV als Abkürzung von "colon separated values" ist so selten, dass es am Ehesten als Fehler des Autors oder Abschreiben von Wikipedia gedeutet werden kann.

Beachte dass viele Fundstellen zwar von "character separated values" oder "colon separated values" reden, aber nicht behaupten, dass CSV die Abkürzung davon ist.

--Pjacobi 13:05, 13. Jul. 2009 (CEST)

@Pjacobi: Danke, danke! Ich habe mir jetzt doch mal die Mühe der Quellensichtung gemacht und bin auf etwas gestoßen, dass ganz andere Aspekte an den Beiträgen von Zartonk zeigt:

Und hier das vollständige Zitat aus der von Zartonk angeführten Quelle "Das Java 6 Codebook, von Dirk Louis, Peter Müller, S. 259" vor:

"Dem Einsatz des Kommas als Trennzeichen verdankt das Format im Übrigen auch seinen Namen: Comma Separated Values. Allerdings ist das CSV-Format nicht standardisiert, so dass es etliche Abwandlungen gibt. [Absatz] Die häufigste Variante ist der Austausch des Kommas durch ein anderes Trennzeichen, weswegen CSV of auch als Akronym für Character Separated Values verstanden wird (ein prominentes Beispiel hierfür ist Microsoft Excel, welches das Semikolon als Trennzeichen benutzt)."

Ich habe das gewissenhaft aus der Version von "Google bücher" abgetippt. Ich glaube nicht, dass jemand die Passage dort einmontiert hat. Aber andere mögen das bitte in der "Papierversion" nachprüfen.

Wie von mir erwartet und befürchtet, zitiert Zartonk sehr selektiv - um es mal ganz vorsichtig auszudrücken. Härter gesagt könnte man ihm auch vorwerfen, hier nicht zum ersten Mal ein sehr fragwürdiges Spiel auf Kosten der Inhalte von Wikipedia zu spielen und grob irreführend zu agieren. Besonders grotesk ist, dass eben der von ihm zur Beweisführung zitierte Autor unmittelbar vor der von Zartonk herausgepflückten - anders kann man das nicht nennen - Stelle, genau das bestätigt, was ich sage: Das "c" steht ursprünglich für "comma".

Nach wie vor bin ich der Ansicht, dass auch ein Fachbuch kann Fehler enthalten. Das vollständige Zitat belegt jedoch in klaren Worten die Ansicht, die ich (und andere) hier bereits geäußert haben: Das "c" steht für "comma". Alle anderen Deutungen sind nachträglich aufgesetzt und Hilfskonstruktionen, die bestenfalls als Merkhilfe dienen, keinesfalls aber normierend zu verstehen sind.

Deutlicher als im ersten Satz der zitierten Passage geht es wohl nicht. Vielleicht kommt mir mal jemand zur Hilfe und legt diesem "Zartonk" endllich das Handwerk. Er treibt nicht nur in diesem Artikel sein Unwesen.

Der entscheidende Satz steht - das ist bemerkenswert - sogar auf der gleichen Seite unmittelbar vor dem bewussten Zitatstück von Zartonk. Er kann das nicht übersehen, sondern muss es bewusst unterschlagen haben. Und das nur, damit er Recht hat und mir "eins auswischen" kann, nachdem ich vor nicht einmal 2 Tagen sachlich begründet die Deutung "Character" aus dem Artikel entfernt habe? Diese erschreckende, selbstherrlich manipulative Vorgehensweise ist für mich Beleg dafür, dass Zartonk entweder nicht in der Lage ist, wissenschaftlich und seriös zu arbeiten, oder aber Wikipedia ganz bewusst Schaden zufügt. Letzteres ist für mich offensichtlich. Das war kein Versehen!

Die beiden anderen Quellen, die er anführt, sind aus den bereits genannten Gründen nicht relevant und beweiskräftig.--mmaass 14:03, 13. Jul. 2009 (CEST)

Noch ein paar Anmerkungen:

• Excel benutzt hoffentlich das in der Systemeinstellung festgelegte Trennzeichen!
• Es stüde den anderen Programmen auch gut zu Gesichte dieses zu Benutzen, dann gäb's innerhalb einer Plattform (z.B. Windows) weniger Probleme mit dem datenaustausch.
• Haarig wird's sonst immer, wenn Programme aus England/USA und Deutschland (z.B. dt. Excel Version) via CSV Datei austauschen müssen. Das Komma ist nunmal in Deutschland ein Dezimaltrenner und in USA wird es oft zur Trennung von Tausenderstellen (zweck's besserer Lesbarkeit, wir benutzen dafür übrigends .) benutzt.
• Daraus ergibt sich, dass der Originale Autor des CSV Format, falls es wirklich Comma separated values sind ein wohl denkbar schlechtes Trennzeichen (auch für USA!) ausgewählt hat. War wohl kein Mathematiker und hat wohl keine Zahlen mit Nachkommastellen gebraucht.
• Zur Quellenlage: die einzig wirklich relevate QUelle währe doch der "Erfinder" dieses Formates oder? Denn allen anderen könntwe man ja Missverständnis nachsagen oder? Gibt's also alt genuge Quellen? Und: nur weil früher Comma separated die mehrheitliche Deutung war muss das ja, wie einer der Autoren hier schon bemerkte, nicht korrekt sein oder? (ja, ich habe das mal herumgedreht)

--91.37.246.232 21:25, 18. Okt. 2010 (CEST)

Zartonk hat vollumfänglich Recht. Jeder Widerspruch ist nur Gelaber von Leuten ohne EDV-Hintergrund. Selbst irgendwelche RFCs von 2005 sagen relativ wenig aus, da csv ja schon ein paar Jahrzehnte älter ist. --93.198.83.157 13:27, 22. Sep. 2017 (CEST)

Export von CSV aus DBs

Diese Formulierung finde ich extrem unglücklich:
Datenbanksysteme wie z.B. Oracle können CSV-Dateien üblicherweise einlesen und auch exportieren, wobei in der Regel Einstellungen wie Codierung, Trennzeichen, etwaige Textbegrenzungszeichen und Spaltenüberschriften in erster Zeile oder nicht vorgenommen werden können.
Ich nehme an, dass damit gemeint ist, dass man es meistens einstellen kann, aber dass es nicht immer notwendig ist. Sollte klargestellt werden. Lg, --Anitagraser 10:31, 7. Apr. 2008 (CEST)

subjektive Meinung des Autors:

"In CSV-Dateien können Tabellen oder eine Liste unterschiedlich langer Listen abgebildet werden. Kompliziertere, beispielsweise geschachtelte Datenstrukturen können durch zusätzliche Regeln oder in verketteten CSV-Dateien gespeichert werden. Um sie in einer Datei abzuspeichern, eignen sich jedoch andere Formate wie XML oder EDIFACT besser."

Das ist alles andere als Objektiv. XML hat zum reinen Datentransfer schon zuviel Overhead und EDIFACT kann man nur noch als "krank" bezeichnen. Geschachtelte Datenstrukturen oder auch unterschiedliche Inhalte kann man in ner CSV-Datei problemlos abspeichern - man definiert einfach Satzarten. Die Satzart wird immer schön als erstes Feld eines Records ausgegeben und gut ist's. Das wurde jahrzehntelang so gemacht und mir leuchtet nicht ein, warum es schlecht sein soll. Unsinnigen Overhead finde ich viel schlimmer. Eine Zeitlang dachte ich, XML wäre unsinnig - dann hab ich EDIFACT kennengelernt. :D

Ich würde den zitierten Absatz mangels objektiver Aussage ganz entfernen - zumindest aber den letzten Satz.

--217.84.38.84 15:50, 5. Aug. 2008 (CEST)

Die Ausführungen zu zusätzliche Regeln oder in verketteten CSV-Dateien gespeichert sind im Artikel sehr unglücklich.

der Hinweis auf die Mächtigkeit von XML mit dem möglichen Encoding für Sonderzeichen ist dafür viel zu kurzgekommen --95.91.232.218 17:50, 25. Mai 2015 (CEST)

7-bit ASCII gilt weithin als der kleinste gemeinsame Nenner

Wie ein anderer Diskussionsbeitrag bereits aussagt, ist der Zeichensatz nicht relevant. Und die Formulierung: der kleinste gemeinsame Nenner ist schlicht falsch. Sie wird leider weit verbreitet falsch verwendet. Siehe die Diskussion zu kleinster gemeinsamer Nenner. Man kann das auch einfacher ausdrücken und da aber der Zeichensatz nicht relevant ist, also den Zusatz am besten weglassen.--Voluntario 14:49, 21. Nov. 2008 (CET)

Auch bei Codierung in 7-bit ASCII ist der Zeichensatz zur Verarbeitung immernoch relevant

XML kann die verwendete Zeichen-Codierung angeben und ist deshalb besser... (nicht signierter Beitrag von 95.91.232.218 (Diskussion) 18:04, 25. Mai 2015 (CEST))

Doppelhochkomma

Dieses Wort gibt es in der deutschen Sprache nicht. Statt es zu benutzen und dann zu erklären was es bedeuten soll: "Doppelhochkomma (Anführungszeichen)" schreibt man besser einfach nur den richtigen Begriff "Anführungszeichen". -- 85.178.125.55 12:19, 11. Okt. 2009 (CEST)

Besonderheiten beim Excel-Import: "Unicode-Format"

Welche Kodierungsform von "Unicode" ist hier gemeint? (nicht signierter Beitrag von 79.207.135.57 (Diskussion | Beiträge) 16:41, 7. Apr. 2010 (CEST))

Die Angabe Unicode ist nicht wirklich sinnvoll...

Eine Angabe UTF-16 oder UTF-32 wie in der XML möglich ist hilfreicher... (nicht signierter Beitrag von 95.91.232.218 (Diskussion) 18:04, 25. Mai 2015 (CEST))

Lemma: „Character Separated Values“?

Wäre es nicht besser, den Artikel mal nach „Character Separated Values“ zu schieben? Die Abkürzung „CSV“ ist (mal abgesehen vom unschönen Klammerlemma mit „(Dateiformat)“) nämlich nicht besonders aussagekräftig. Zudem wäre es mir zwar noch lieber, hier würde gleich ein deutschsprachiges Lemma verwendet werden (wie z.B. Kommagetrennte Werttextdatei-Format,^[3] Tabulatorgetrennte Werttextdatei-Format^[4] oder um auch gleich alle diese Formate in einem Rutsch zu behandeln „Zeichengetrennte Werttextdatei-Format“, kurz ZWF), aber das Amilemma tut es ja auch – ..schon besser als die Abkürzung. :-) --85.179.129.9 18:58, 8. Aug. 2011 (CEST)

Ein allgemeineres (und natürlich auch aussagekräftigeres) Lemma (als eine nichtssagende Abkürzung, siehe dazu auch unter Hilfe:Lemma) wäre tatsächlich sinnvoller, da so auch die verwandten Dateiformate (also z.B. mit den Trennzeichen Komma, Semikolon, Tabulator und was es sonst noch so für Geschmacksrichtungen gibt) hier gleich (quasi in einem Metadateiformat) mitbehandelt werden könn(t)en ohne dazu jeweils einen ganzen Artikel anlegen zu müssen. Bei den Amis wird dazu übrigens das Lemma „Delimiter Separated Values“ (oder wörtlich Trennzeichengetrennte(s) Werttextdatei(-Format) :-) ) verwendet, da die nämlich genau das selbe Problem haben (siehe auch die Überschneidungshinweise in en:Comma-separated values, en:Tab-separated values oder en:Delimiter-separated values). Zudem müßten dann auch noch die Begriffsklärungsseiten zu den Abkürzungen (CSV, DSV, SSV, TSV) ggf. noch entsprechend ergänzt oder aktualisiert werden. --92.229.55.112 07:52, 9. Aug. 2011 (CEST)

Dieses „Delimiter Separated Values“ (sowie auch „delimiter-separated values“ oder „delimiter separated values“) scheint im deutschen (noch) relativ ungebräuchlich zu sein (siehe auch [5] und [6]), das in der Überschrift vorgeschlagene Lemma wäre damit also wohl (zur Zeit) am besten für den Artikel hier geeignet, der dann ggf. auch noch entsprechend verallgemeinert werden sollte. --92.229.55.112 08:52, 9. Aug. 2011 (CEST)

Also ich kenne es auch als "Comma Separated Values", wobei das "Comma" eben oftmals Leerzeichen oder Tabulatoren sind... das Format heißt dann weiterhin aber CSV. Beispiel: Python CSV Modul. DSV als Formatbegriff habe ich noch nie gesehen. "Character Separated Values" passt zwar, ist aber ein Backronym. Ich finde der Artikel tut dem Problem mit Formulierungen wie "Abhängig von beteiligter Software und Benutzereinstellungen sind auch Semikolon, Doppelpunkt, Tabulator, Leerzeichen oder andere Zeichen üblich." schon genüge. Der Artikelname umgeht das Problem elegant, indem er eben nur die Buchstaben CSV verwendet. In der Realität haben CSV-Dateien regelmäßig eben genau keine Kommas als Trennzeichen! Mit der größte gemeinsame Nenner ist die beliebte Dateiendung .csv ;-) Als Wikipedia sollten wir eigentlich die üblichen Begriffe verwenden, nicht versuchen hier einen neuen (wenn auch besseren) Begriff zu etablieren. --Chire 17:38, 9. Aug. 2011 (CEST)

Ich denke einmal, daß ich mit meinem Artikelwunsch der Auslöser für diese Diskussion war. Nun, aus meiner Sicht wäre es sinnvoll in einem Artikel, gleich wie er am sinnvollsten heißt, die einzelnen Arten (CSV, DSV, SSV, TSV, etc.) anzusprechen. Ob jetzt CSV der beste Name dieses Artikels ist, kann ich leider nicht beurteilen. Bislang muß man sich durch enwiki wühlen, um hierzu Infos zu erhalten, die ich noch nicht mal richtig verstehe. -- [[kgh]] 00:22, 10. Aug. 2011 (CEST)

Das Problem ist, dass diese Begriffe halt allesamt nicht so wirklich verbreitet sind. Man spricht eben normalerweise immer von CSV - das, wenn man es als "character separated" liest, ja auch alles abdeckt. Keines dieser Formate, ob man sie nun nachträglich "DSV" oder "SSV" getauft hat, war ursprünglich als eigenes "Dateiformat" konzipiert. Selbst in Programmen wie Cut (Unix), die genau für solche Formate geschrieben wurden (es wählt Spalten aus so einer Datei aus), wird nirgendwo dieser Begriff verwendet sondern es ist einfach nur die Rede von "Dateien". Man findet zwar den Begriff eines "delimiters" oder "separators". Im Gegenteil, wenn man mit Google nach "DSV File Format" sucht findet man Schätze wie: "Das DSV-Format ist ein Datenformat, dass speziell für den elektronischen Austausch von Daten im Schwimmsport entwickelt worden ist." Für mich grenzt das hier an Wortschöpfung... und "Trennzeichengetrennte(s) Werttextdatei(-Format)" von Benutzer:FBE2005 (anonym) oben ist seine eigene Wortschöpfung; er versucht sämtliche Fremdsprachenbegriffe zu ersetzen. Als nächstes schlägt er vor den Artikel in "TGW-Format" umzubenennen... --Chire 12:22, 10. Aug. 2011 (CEST)

Oh Entschuldigung. Das hatte er ja schon. ZWF. Ich hoffe ich werde nie jemanden treffen der CSV-Dateien als .zwf abspeichert. --Chire 12:29, 10. Aug. 2011 (CEST)

"der größte gemeinsame Nenner"? :D --93.198.83.157 13:34, 22. Sep. 2017 (CEST)

Kleinster gemeinsamer Nenner?

In der Einleitung ist vom kleinsten gemeinsamen Nenner die Rede. Das ist rein logisch betrachtet eine schwachsinnige Aussage. Es gibt den größten gemeinsamen Nenner (Teiler) (ggT/gcd) und das kleinste gemeinsame Vielfache (kgV/lcm).

Stundenplan als Beispiel für Felder und Datensätze unbrauchbar

Der Stundenplan ist eben kein gutes Bespiel für strukturierte Daten, wie man sie in Datenbanken und auch in CSV-Dateien vorfindet, weil man den Stundenplan ja vertikal liest und nicht horizontal. Die Einteilung in Datensätze (1., 2., 3. Stunde) und Felder (Montag, Dienstag, Mittwoch) ist ziemlich hirnverbrannt. Man kann zwar eine CSV-Datei nach dem gezeigten Muster erstellen und die Datei ergibt dann auch die gewünschte Tabelle, wenn man sie mit Excel öffnet. So eine Tabelle erstellt man jedoch sinnvoller mit Word. Ein Tabellenkalkulationsprogramm braucht man dafür nicht zu bemühen, da es sich nicht um Datensätze handelt. (nicht signierter Beitrag von 80.153.5.110 (Diskussion) 16:22, 7. Sep. 2011 (CEST))

Mastpoint?

RFC 4180 ist von der Network Working Group und meines Wissens als die einzig gültige Spezifikation von CSV bekannt. Das CSV-1203 ist eine Fantasie-Spezifikation geschrieben von unbekannten Leuten mit keinerlei überprüfbarem Informatik-Hintergrund. Vorschlag: Einfach löschen. --Surikat (Diskussion) 07:23, 19. Jun. 2013 (CEST)

Ich will den 1203-Leuten nicht nahe treten, aber verbreitet kann das Zeugs nicht sein. Ích werd's schmeissen, wenn einer mit mördermäßigen Belegen daherkommt, kann man ja nochmals sprechen --RobTorgel (Diskussion) 07:50, 19. Jun. 2013 (CEST)

Formatierung negativer Zahlen

Im Abschnitt: "Formatierung der Datenfelder" Je nach Vorliebe des Anwenders werden zudem negative Werte auf vielfältige Weise dargestellt.

Welche vielfältigen Weisen gibt es denn eine negative Zahl darzustellen? Ich glaube das es sich, auch International, durchgesetzt hat, eine negative Zahl mit einem sogenannten Minus-Zeichen oder auch Subtraktions-Symbol zu beginnen.

Ich denke das die Darstellung negativer Zahlen nun wirklich keine Besonderheiten parat hält. (nicht signierter Beitrag von 85.178.92.190 (Diskussion) 23:07, 19. Jul. 2013 (CEST))

Zustimmung. Ich habe den Satz entfernt. --Trustable (Diskussion) 13:47, 17. Okt. 2013 (CEST)

7 Bit ASCII

Der Artikel ist merkwürdig. Im verlinkten steht nicht allgemein sondern gebräuchlich(wohl eher früher) war es ASCII(was 7 Bits sind, warum die Dopplung?). Dieser war wie vieles ziemlich US-zentrisch, schon die Separierung mittels Komma zeigt das Zahlenformate fehlerhaft dargestellt werden müssen. Nicht umsonst ist die Rede von Texttrennung und Hochkomma, dass Trenner enthalten könnte. Im RFC steht etwas von beliebigen Kodierungen eben auch latin-15 oder UTF-8. Damit einher geht auch das Komma weniger Verwendung findet, weil eben Punkt und Komma bereits für Zahlen in Verwendung sein könnten.--Darktrym (Diskussion) 17:27, 23. Nov. 2014 (CET)

Die Katastrophe ist CSV, nicht der Artikel. Oder verstehe ich dich falsch? Dein Text hier ist auch etwas wirr. --77.6.9.133 15:32, 26. Mai 2020 (CEST)