Diskussion:CSV (Dateiformat)

message: 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)
replies: text: 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)
thread_title:  Trennzeichen ? 

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

message: 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)
thread_title:  noch erwähnbar 

message: 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)
replies: text: bei fester feldanzahl benötigt man überhaupt keinen zeilenumbruch. --217.7.68.91 09:40, 1. Aug 2006 (CEST)
thread_title:  "unabhängig von ... " 

message: 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)
replies: text: 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)
thread_title:  Trennzeichen innerhalb der CSV 

message: 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)
thread_title:  Export von CSV aus DBs 

message: 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)
thread_title:  Doppelhochkomma 

message: 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, Tabulatorgetrennte Werttextdatei-Format 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)
replies: text: 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)

text: Dieses „Delimiter Separated Values“ (sowie auch „delimiter-separated values“ oder „delimiter separated values“) scheint im deutschen (noch) relativ ungebräuchlich zu sein (siehe auch  und ), 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)

text: 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)
replies: text:  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)
replies: text:  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)
replies: text: 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)
thread_title:  Lemma: „Character Separated Values“? 

message: 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)
thread_title:  Stundenplan als Beispiel für Felder und Datensätze unbrauchbar 

message: 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)
replies: text: 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)
thread_title:  Mastpoint? 

message: 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. 
:Zustimmung. Ich habe den Satz entfernt. --Trustable (Diskussion) 13:47, 17. Okt. 2013 (CEST)
thread_title:  Formatierung negativer Zahlen 

message: 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)
replies: text: 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)
thread_title:  7 Bit ASCII