Diskussion:Textdatei/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Textdatei/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Textdatei/Archiv#Thema_1

Bearbeiten mit MSWord möglich

Die Aussage "Das Öffnen eines .txt Files im Windows Word ist jedoch nicht möglich." ist so nicht ganz richtig. Im Menüpunkt "Datei/Öffnen" von MS Word öffnet sich eine Ordner-Ansicht. Dort gibt es die Drop-Down-Box "Dateityp", die u.a. den Eintrag "Textdateien" enthält. Dann werden auch alle Dateien mit Endung ".txt" im aktuellen Ordner angezeigt. Man kann Textdateien öffnen, ändern und wieder speichern.
(Der vorstehende Beitrag stammt von Hhdw – 10:00, 11. Mär. 2004 (CEST) – und wurde nachträglich signiert.)

Artikel komplett Überarbeitet

Habe den Artikel komplett ueberarbeitet. Jetzt ist meines Erachtens vor allem noch folgendes zu tun:

• Die Zeichensatzproblematik muss ausfuehrlicher und verstaendlicher dargestellt werden, vor allem unter praktischen Gesichtspunkten; dabei sollen jedoch zu starke Ueberlappungen mit dem noch auszubauenden Artikel Zeichensatz vermieden werden.
• Die Problematik der verschiedenen Steuersequenzen fuer den Zeilenumbruch unter den Betriebssystemklassen Unix/Windows/Mac muss erlaeutert werden.

-- 141.30.230.88 00:49, 18. Sep 2004 (CEST)

Inhalt verschoben

Es gibt jetzt (wie in der englischen Ausgabe) einen Artikel Binär- und Textdatei, der beide Formate (Binärdatei und Textdatei) direkt gegenüberstellt. Den Inhalt von hier habe ich dort eingearbeitet und dementsprechend einen Redirect dorthin angelegt. --Mfg Doodee 19:43, 5. Okt 2004 (CEST)

Guter Ansatz, aber hier ist seit zwei Jahren nichts passiert. Der Text aus Binär- und Textdatei befand sich immer noch in den Artikeln Textdatei und Binärdatei. Ich habe die redundanten Texte aus den Artikeln entfernt und stattdessen einen Verweis auf Binär- und Textdatei eingefügt. 80.136.79.183 11:51, 7. Nov. 2006 (CET)

CR bei Mac OS

Einiges an diesem Artikel erscheint mir zweifelhaft. Insbesondere wird beim MAC doch nicht CR statt LF oder CRLF benutzt. Oder etwa doch ???

Ich werde die zweifelhaften Aussagen jedenfalls jedenfalls entfernen.

Benutzer:Fsswsb 13.03.06

Doch doch, also ich hab das auch mal gehört, daß (vor)MacOS(X) dort CR als Zeilenumbruch verwendet wurde. Ich kann das aber nicht mit 100%iger Sicherheit sagen, da ich ein Mac noch nie so weit in die Eingeweide gefaßt habe. :-) ..und einen Mac-User, der diesen Sachverhalt genau kennt, wird man bestimmt auch nur seeehr schwer finden. ;-)

Gruß .. Spawn 00:52, 4. Mai 2006 (CEST)

Ich habe schon mehrfach solche Dateien gesehen und konvertieren müssen. Ihr könnt ja im Mac-Laden eures Vertrauens mal nachfragen, ob sie noch eine alte MacOS-Installations-CD haben, vielleicht gibts auf denen ja noch README-Dateien oder sowas, an denen ihr das verifizieren könnt. :-) --RokerHRO 07:51, 4. Mai 2006 (CEST)

Umleitung von ASCII-Datei

Hallo, hab den gesamten (restlichen) Inhalt nun vom (ehem.) Artikel ASCII-Datei (und nun auch von dessen Diskussionsseite) hierher verschoben, da das sonst zwei redundante Artikel (und Diskussionen) ergeben würde.
Gruß .. Conrad 11:57, 25. Mai 2006 (CEST)

Umleitung von Plaintext -> Textdatei

Hallo, der Artikel für Plaintext redirectet momentan auf diesen Artikel. Finde ich verwirrend da man mit "Plaintext" sich auch auf Protokolle beziehen kann die Daten in lesbarem Text anstatt (binaer) kodiert übertragen. Siehe zum Beispiel auch en:Text-based in der englischsprachigen Wikipedia. Ich schlage vor einen Artikel Plaintext oder Text-Format zu behalten, etwas ähnliches/alternatives habe ich nicht gefunden in Kategorie:Datenformat. - 83.254.215.231 15:53, 13. Jan. 2008 (CET)

Habe eine neue Seite Text-Format angelegt. 83.254.215.231 22:22, 13. Jan. 2008 (CET)

Möchte den Artikel überarbeiten (s.u.). Was wir dann mit Text-Format bzw. Plaintext machen, entscheiden wir anschließend. Ok?--Cactus26 08:07, 17. Jan. 2008 (CET)

Trage Deinem Einwand Rechnung und habe einen eigenständigen Artikel Plain text angelegt, in dem ich auch die relevanten Inhalte aus Text-Format übernommen habe. en:Text-based hat aber mMn nicht viel mit dieser Sache hier zu tun, hier geht es um Anwendungen mit einer textorientierten Oberfläche als Ggs. zu einem GUI. Werde Text-Format nun löschen lasssen, da ich das Lemma so nicht für sinnvoll halte.--Cactus26 11:27, 19. Jan. 2008 (CET)

Danke, ist ne gute Lösung! - 83.254.215.231 02:57, 24. Jan. 2008 (CET)

Überarbeitung 01/2008

Möchte den Artikel überarbeiten. Abschließend werde ich ihn einem Review unterziehen. Mithilfe ist willkommen, wir sollten uns dann abstimmen. Vorgesehene Gliederung:

• Geschichte
• Abgrenzung
• Kennzeichnung des Zeilenendes
• Zeichencodierungen
• Austausch zwischen unterschiedlichen Systemen
• Auszeichnungssprachen

--Cactus26 08:07, 17. Jan. 2008 (CET)

OK:

Beim Austauch von Textdateien als Anhang einer E-Mail können Unstimmigkeiten auftreten. Das Problem liegt dabei meist beim Absender, da dessen Mail-Client häufig die Codierung der Textdatei nicht korrekt ermitteln kann und so keine entsprechende oder eine falsche Information in die Mail einträgt. Im Prinzip sind die meisten heute gebräuchlichen Mail-Clients in der Lage, die Codierung im Bedarfsfall zu konvertieren.

Liegt das Problem nun beim Absender, oder wurde es inzwischen behoben? Und was ist das genaue Problem etzt eigentlich? Ich finde, die Formulierung ist etwas zu schwammig, aber mir fällt grad auch nix besseres ein... --Rohieb 会話 +/- 01:57, 31. Jan. 2008 (CET)

Aber ich denke, soweit ist in dem Artikel alles drin, was zu sagen ist. Was mir noch aufgefallen ist: der Artikel beinhaltet mir noch zu viele Wörter wie "häufig", "viel/e" o.ä. Da sollte man entweder noch genauer werden, oder die Worte wegstreichen. Aber dazu bin ich glaube ich grad zu müde :D --Rohieb 会話 +/- 02:21, 31. Jan. 2008 (CET)

Zum Problem "E-Mail beim Absender" habe ich noch einen Satz ergänzt. Das Problem ist auf absehbare Zeit nicht so ohne weiteres zu lösen, wenn Du an web-basierte Mail-Clients denkst, die tun vermutlich viel, um die Codierung zu "erraten", aber so ganz kann das mMn nicht klappen.--Cactus26 07:57, 31. Jan. 2008 (CET)

Steuerzeichen: Escape-Sequenzen

Beim späten MS-DOS und unter AmigaOS waren ANSI-Escape-Sequenzen (siehe Disk dort) als deviceübergreifende Steuerbefehle im Einsatz. Die Form war immer Esc[x (x ein Buchstabe) oder aufwendiger Esc[...;. Dabei war Esc das einzige nicht druckbare Zeichen, alle anderen Zeichen der Sequenzen bestanden aus druckbaren Zeichen. Ich muss bloß die ANSI-Nummer mal heraussuchen. Sollte man das evtl. noch mit erwähnen? --PeterFrankfurt 01:38, 25. Jan. 2008 (CET)

Ich denke nicht, dass es einen ANSI-Standard gab. Was Du meinst ist vermutlich ESC/P (Epson Standard Code for Printers). Zur Nadeldruckerzeit war das ein Quasi-Standard (siehe auch en:ESC/P und [1]). AmigaOS kenne ich nicht, kann nicht beurteilen, ob dort ESC/P verwendet wurde, vermute es aber. Ich bin nur eben zwiegespalten, das in Textdatei zu ergänzen (in Escape-Sequenzen könnte man aber was ergänzen), da es doch sehr Vergangenheit ist.--Cactus26 06:51, 25. Jan. 2008 (CET)

Nee, nee, nix Esc/P. Wirklich ANSI. Ich fange gerade an zu googeln (ANSI + "esc["), und der allererste Treffer behandelt ANSI-Esc-Sequenzen-Treiber für OS/2 ([2]), Stichwort ANSI.SYS für die CONFIG.SYS (OS/2 wie auch MS-DOS). Einer der späteren Treffer behandelte die ANSI-Sequenzen im VT100 (Manual: [3]), und dort steht auch die genauere Bezeichnung:

ANSI X3.41-1974 and X3.64-1977 --PeterFrankfurt 22:06, 25. Jan. 2008 (CET)

Ich war dann mal so frei und habe das als Unterkapitel eingebaut. --PeterFrankfurt 22:50, 25. Jan. 2008 (CET)

Kannte diesen Standard noch nicht, danke für die Info. Aber ob es in den Artikel Textdatei gehört? Wäre Escape-Sequenz da nicht ausreichend? Hm. Terminalansteuerung gehört mMn weniger hierher als ESC/P. Wenn, dann müsste ESC/P auch noch hier her. Beides ist auch schon recht antik.... --Cactus26 12:15, 26. Jan. 2008 (CET)

Habe das mal ein wenig gestrafft. Alles weitere gehört mMn in Escape-Sequenzen. Insbesondere würde ich dort ESC/P und Terminalansteuerung trennen. Ich hoffe, Du fühlst Dich durch meine Änderung nicht auf den Schlips getreten und schaust Dir die Sache dennoch einmal an.--Cactus26 07:51, 31. Jan. 2008 (CET)

Review vom 22. Januar bis 25. Februar 2008

Es war für mich sehr überraschend, wie viel es doch ist, was es zu so etwas scheinbar trivialem wie einer Textdatei zu sagen gibt. Da dank der guten Vorarbeit anderer praktisch schon alle Stichworte in der ursprünglichen Version des Artikels enthalten waren, konnte ich diesen recht leicht neu strukturieren und ein wenig ergänzen. Und dabei musste ich mich an einigen Stellen verkeifen, noch einen Schritt weiter zu gehen. Mein Ziel war, diesen Artikel in weiten Teilen laienverständlich zu halten. Ich bitte natürlich auch um kritisches Feedback von den Fachleuten, bitte aber darum, wohl abzuwägen ob das eine oder andere hier noch rein muss, da der Artikel sonst vermutlich schnell ausufern kann, weil er eben sehr allgemein und plattformübergreifend ist.--Cactus26 18:05, 22. Jan. 2008 (CET)

Ich geh mal mit dem feinen Kamm drüber:

„Das Gegenstück dazu stellt eine Binärdatei dar, deren Codierung in anderer beliebiger Weise zu interpretieren ist.“—Fachliche Haarspalterei: Weder Datei noch Daten schreiben eine spezifische Kodierung vor, es sind ja nur Bitketten, zu denen sich beliebig viele „sinnvolle“ Interpretationen konstruieren lassen. Besser fände ich etwas in Richtung „bei der die Daten mit anderen Codierungen interpretiert werden“.

Abschnitt Geschichte: könnt man vielleicht in ’nem Halbsatz ergänzen: Textdateien wurden direkt an Terminals übertragen, aber was passierte mit Binärdaten?

„in ein Byte umgesetzt, also eine Gruppe von 8 Bit, die so 256 verschiedene Zeichen ermöglichte.“—Nö. Um es mit dem ISO-C-Standard zu sagen, ist ein Byte eine “addressable unit of data storage large enough to hold any member of the basic character set of the execution environment”. Das waren bei manchen Terminals iirc 5 (6?) Bit. Oktette haben sich zwar durchgesetzt, pauschal richtig ist das aber nicht.

„kann man auf Systemen, die eine solche Codierung verwenden, Binärdateien daran erkennen, dass Codierungen auftauchen, die das vom ASCII unbenutzte 8. Bit verwenden.“—Wie Emails mit unkodierten Umlauten drin? ;)

Abschnitt „Harter“ und „weicher“ Zeilenumbruch: Äääähh, was hat dieser gesamte Absatz mit Textdateien zu tun?

Abschnitt Austausch zwischen unterschiedlichen Systemen: Der Teil zum Datentransfer wirkt recht antik (FTP ist ja ziemlich obsolet), den Satz „Im Prinzip sind die meisten heute gebräuchlichen Mail-Clients schon in der Lage, die Codierung im Bedarfsfall zu konvertieren.“ würd ich kurzerhand streichen, die Abschwächungen „im Prinzip“ und „die meisten heute“ machen den Satz ziemlich wertlos.

Abschnitt Weitergehende Verwendung von Textdateien: Mir persönlich zu essayartig, aber das ist wohl auch Geschmackssache.

HTH, —m∇h 08:38, 25. Jan. 2008 (CET)

Dein Feedback hilft auf jeden Fall, danke dafür. Zu den einzelnen Punkten:

• "Codierung ... zu interpretieren": Stimmt. Formulierung ist Käse, habe es angepasst ("deren Inhalt...")
• "Textdateien an Terminals übertragen": Ich verstehe nicht ganz, worauf Du mit Deinem Hinweis "und Binärdaten" hinaus willst.
• "8 Bit sind ein Byte": Zugegebenermaßen erst bei Bearbeitung dieses Artikels ist mir wieder bewusst geworden, dass das Gesetzt 8Bit=1Byte eigentlich nicht stimmt. Hältst Du das für so wichtig, dass Du mich zu "also eine Gruppe von im Regelfall 8 Bit" zwingen willst?
• "Harter und weicher Zeilenumbruch": Es gibt drei Gründe, warum ich es ergänzt habe: 1.) CR/LF wird hier sehr ausführlich behandelt (was ich wichtig finde) und da passt es der Vollständigkeit halber hervorragend dazu; 2.) Wenn man Textdateien in einem Editor bearbeitet, der Zeilen automatisch umbricht, ist wichtig, diesen Unterschied zu kennen. 3.) Beim Kopieren von Inhalten aus Textdateien in Textverarbeitung ist der Zusammenhang ebenfalls wichtig;
• Uiih, FTP ist ziemlich obsolete, Hm. Fühle mich alt. Aber: Wie auch immer, die Problematik, dass man bei der Datenübertragung angegeben muss, ob es eine Text- oder Binärdatei ist, hat wohl noch Bestand, zumindest in den Umgebungen, die ich kenne. Und darum geht es mir hier. Wenn Du Modernes hier anzufügen hast, gerne.
• Im Prinzip sind die meisten heute gebräuchlichen Mail-Clients schon in der Lage, die Codierung im Bedarfsfall zu konvertieren. - Streichen, aufgrund zu vieler Relativierungen. Ja, stimmt schon, ohne diese habe ich mich den Satz nicht getraut, weil ich den Überblick nicht habe. Dennoch finde ich ihn nicht ganz wertlos. Wie ist Dein Wissensstand hier, hältst Du eine der Relativierungen für entbehrlich?
• "Weitergehende Verwendung von Textdateien", "zu essayartig". Kann Deine Kritik nachvollziehen, denke Du meinst v.a. den 2. Absatz. Hm. Gefällt mir aber ganz gut, ist mir auch ein Anliegen, die "Tendenz zu immer mehr Textdateien" zu erläutern.

--Cactus26 10:13, 25. Jan. 2008 (CET)

Hi. Ich hab schon einmal ein paar Formulierungen zu Beginn des Artikels etwas geglättet, die vorher doch etwas umständlich und verschachtelt waren. In dieser Hinsicht kann glaube ich im gesamten Artikel noch einiges getan werden. Wenn ich die Zeit finde, werd ich die Tage nochmal genauer − auch und vor Allem inhaltlich − reviewen. Gruß, --norro 16:49, 26. Jan. 2008 (CET)

Ich danke Dir für Deine Glättungen der Einleitung. Irgendwie habe ich die wohl zu oft umgebaut. Ich denke (hoffe), dass der Rest streckenweise besser ist, aber wenn Dir dort auch noch Verbesserungen in dieser Art einfallen, gerne.--Cactus26 10:25, 27. Jan. 2008 (CET)

ohne von der sache irgendetwas zu verstehen - darf man flat file wirklich so übersetzen, wie im eingangsteil geschehen? ich seh schon, dass dies auch bei leo so praktiziert wird, aber stimmt das auch? eine flat tax, oder eine flat rate sind ja auch nicht flach oder eben, sondern eingeebnet - und das ist ein unterschied; pauschaliert würde man in österreich dazu sagen. gruß Scops 15:42, 29. Jan. 2008 (CET)

Freut mich sehr, dass Du Dir den Artikel angesehen hast. "Eingeebnet" trifft es hier nicht, denn die Datei war schon immer flach, sie wird ja nicht flach gemacht. Ich verstehe das "flach" hier als Metapher, im Sinne von "ohne Struktur", also wie eine Tapete ohne Struktur im Vergleich zu einer Strukturtapete.--Cactus26 16:06, 29. Jan. 2008 (CET)

Habe bei der Gelegenheit die Definition von plain text und flat file mir nochmal angesehen und nochmal überarbeitet, die traf bisher nämlich mMn nicht ganz den wesentlichen Aspekt.--Cactus26 16:13, 29. Jan. 2008 (CET)

Hab nach der Einleitung aufgegeben:

• deren Inhalt ohne spezielle Verfahren oder Computerprogramme in Text umgesetzt werden kann - Um binär gespeicherte Daten darzustellen, braucht es immer Hard- und Software, also immer spezielle Verfahren. Was soll denn darstellen hier heißen? Drucken und Anzeigen benötigt immer spezielle Verfahren. Das wird so nichts!
• Die Datei ist dabei direkt in einem Zeichensatz codiert – beispielsweise ASCII oder Unicode – der im Regelfall dem des Systems entspricht, auf dem die Datei gespeichert ist - Welchem System (OS, Dateisystem, ???) Ein Dateisystem muss keinen bestimmten Zeichensatz aufweisen. Für die Darstellung sind Shell, GUI, Editor oder andere Komponenten verantwortlich, das hat nicht unbedingt etwas mit dem OS zu tun.
• Ein solches Dateiformat ist die einfachste Form, in der Text gespeichert werden kann. - Unicode ist sicher nicht die einfachste Form in der ein in lateinischen Buchstaben geschriebener Text gespeichert werden kann; mathematische Texte dagegen können selten (ohne Transformation) in Textdateien gespeichert werden!

Ich weiß da leider keinen Ausweg, aber mir scheint, dass die ganze Einleitung vollkommen anders aufgezogen werden muss. Verständlich wird der Begriff Textdatei doch eigentlich nur aus der Geschichte der IT - bevor moderne Betriebssysteme wie Unix oder DOS (Modern Operating Systems ist der Titel eines Lehrbuches von Tanenbaum, er zählt DOS ausdrücklich dazu) eingesetzt wurden, hatte jede Datei eine spezielles Format das mit einer bestimmten Anwendung verknüft war. Textdateien waren in diesem Zusammenhang Dateien, die auf Textterminals dargestellt werden konnten. Da Textterminals heute nur noch als Emulation existieren, ist der Begriff Textdatei heute an sich obsolet. --21:15, 29. Jan. 2008 (CET)

Ich verstehe Dich nicht. Du scheinst in der Einleitung schon alle Fragen beantwortet haben zu wollen. Dass das nicht möglich ist, ohne die Einleitung auf die Länge des ganzen Artikels zu erweitern, ist wohl klar (wozu dann der Rest?). In der Einleitung muss man sich dann halt um manche Punkte etwas "herummogeln", um nicht gleich mit der Tür ins Haus zu fallen. Zu den einzelnen Punkten:

• "Das soll heißen, dass es in diesem Fall vergleichsweise einfach ist, die Binärdaten in Text umzusetzen, im Regelfall eben ein Byte in ein Zeichen. Dass das mit Unicode komplizierter geworden ist, scheinst Du ja zu wissen. Aber ich finde, mit etwas gutem Willen, kann man auch als IT-Fachmann verstehen was gemeint ist ("darstellen" steht übrigens nicht im Artikel).
• "System" ist hier natürlich unscharf, aber was soll man denn sagen? Betriebssystem wäre vielleicht eine Alternative (stellst Du hinten auch in Frage, als ob jede Shell und jeder Editor ihre eigene Codierung verwenden würden), stimmt aber auch nicht in allen Konstellationen. Auch wird ASCII und Unicode auf vielen Systemen heute parallel verwendet. Aber der für den Benutzer stellt es sich eben meist so dar, als hätte ein System einen Zeichencode.
• "Unicode ist sicher nicht die einfachste Form": Du hättest weiterlesen müssen....
• "Begriff ist obsolete". Ist er nicht, er wird ja massiv verwendet. Die Problematik der Unschärfe des Begriffs wird ausführlich im Artikel behandelt.

--Cactus26 07:14, 30. Jan. 2008 (CET)

Ich versuch es mal anders herum anzugehen: Die Einleitung (genauer gesagt, der erste Absatz) ist extrem unscharf, so dass eigentlich weder Fachmensch noch Laie etwas davon hat. Ich stimme Dir nicht zu, dass ein enzyklopädischer Artikel sich in der Einleitung um die schwierigen Definitionsfragen herummogeln darf, zumindest nicht indem er unbestimmt bleibt.

Zunächst lässt die Einleitung offen, wie Text im Kontext Textdatei verstanden werde will, dabei steht das doch wunderbar im Artikel Text: Text benötigt zu seiner Darstellung eine Schrift, deren Zeichen Phoneme, Silben oder Wörter bzw. Begriffe kodieren.. Eine Textdatei kodiert also Schriftzeichen, und zwar ausschließlich! (BTW: Steuerzeichen kann mal als Schriftzeichen auffassen, die noch eine zweite Bedeutung tragen.) Das wäre weder unbestimmt noch unklar. Und schon sind Aussagen wie deren Inhalt ohne spezielle Verfahren oder Computerprogramme in Text umgesetzt werden kann gar nicht mehr notwendig. Hauptsächlich verwendete Codes waren/sind EBCDIC, ASCII, Unicode, .... - wozu muss ich das System erwähnen? Von einem unbestimmten Begriff System hat der Leser keinen Mehrwert (außer dass sich jeder darunter vorstellen mag, was er will). Und danach könnte erwähnt werden, daß viele Grafikkarten, Drucker und andere Ausgabegeräte bereits mit entsprechenden Code-Tabellen ausgestattet sind, so dass die codierten Schriftzeichen durch einfachen Tabellen-Lookup umgesetzt werden können. (Das funktioniert übrigens auch bei Braille.)

Jetzt klarer, um was es mir geht? --Burkhard 21:26, 30. Jan. 2008 (CET)

Ich denke, wir haben hier tatsächlich einen grundlegend unterschiedlichen Blickwinkel. Du gehst von einer ordentlichen formalen Definition des Begriffs "Textdatei" aus (wobei ich nicht weiß, woher Du die nimmst). Die gibt es aber mMn nicht. Insofern ist auch nicht genau spezifiziert, was Text eigentlich ist, hier ist die Verlinkung des Artikel Text mehr als ausreichend. Eine Textdatei kodiert also Schriftzeichen, und zwar ausschließlich: Woher nimmst Du das? Würde ich mich nicht trauen zu behaupten. Ich habe hier versucht zu dokumentieren, was jemand meint, der mit Computern zu tun hat, wenn er von Textdatei spricht ("schick mir das mal als Textdatei"). Das mit dem "System" in der Einleitung ist nicht schön, da gebe ich Dir recht. Vielleicht habe ich oder jemand anderes noch eine Idee, wie man das besser formulieren kann, ohne in der Einleitung den Rahmen zu sprengen. Mit Deinem Ausflug in die Technik vergallopierst Du Dich nach meinem Wissenstand ein wenig. Eine Codetabelle haben Grafikkarten im GUI-Zeitalter bestenfalls noch aus Gründen der Kompatibilität, außerdem gehört Tabellen-Lookup und ähnliche Verfahren mMn nicht in einen Artikel "Textdatei". Ob die Einleitung nun weder für Laien noch für Fachmann was bringt, möchte ich erst einmal abwarten. Mein Ziel war tatsächlich das Gegenteil, ich wollte es beiden Recht machen. Gruß --Cactus26 08:22, 31. Jan. 2008 (CET)

Laß es mich mal so ausdrücken: Wenn Du nach ausführlichem Studium der Lehrbücher, dem Lesen möglichst mehrerer anderer Interwikiartikel und gründlichem Überlegen, womöglich durch vorbereitende Artikelarbeit im BN, zu dem Ergebnis gekommen sein solltest, daß diese Form der unbestimmten Definition, die mehrdeutige und nicht fassbare Begriffe verwendet, die beste aller möglichen Einleitungen darstellt, dann hast Du natürlich nicht nur das Recht sondern auch die Pflicht, sie mit allen Dir zur Verfügung stehenden Argumenten zu verteidigen. --Burkhard 23:14, 8. Feb. 2008 (CET)

Will nur kurz noch folgendes loswerden: Ich habe sicherlich keine Doktorarbeit über dieses Thema gemacht, komme aber nach allem was ich bislang gesehen habe zu dieser Auffassung. Ich kann Deinen Standpunkt ja nun durchaus nachvollziehen, auch wenn er sich bislang nicht direkt auf den Artikel ausgewirkt hat, ist das für die Zukunft durchaus denkbar. Ich bin bei diesem Thema bislang noch gar nicht auf die Idee gekommen, dass es einer Definition bedarf, was den Text denn eigentlich ist, da der Begriff schon aus technischer Sicht so uneinheitlich verwendet wird. Ich bin zum jetzigen Zeitpunkt schon weiterhin überzeugt, dass der Versuch, die Sache von dieser Seite aufzuziehen, nicht hilfreich wäre, aber zuvor war mir die Möglichkeit dieses Blickwinkels nicht einmal bewusst.--Cactus26 07:24, 11. Feb. 2008 (CET)

Zum Bild Fehlerhafte Darstellung: das schreibt man an dieser Stelle mit s, auch wenn es schön wäre, hier ein falsch codiertes ß darzustellen. Außerdem ist das von doppelt. 80.146.107.57 10:09, 1. Feb. 2008 (CET)

Danke für den Hinweis. War wohl orthografisches Wunschdenken. Aber das "ß" brauchen wird schon, auch wenn's scheußlich ist.--Cactus26 11:00, 1. Feb. 2008 (CET)

Absicht

Was ist eine Textdatei? Jede Datei die mit der Absicht erstellt wurde, einen Text für andere zugänglich (d.h. lesbar) zu machen. Der Ersteller muss sich darauf verlassen können, dass der potentielle Leser diese Datei ohne "Klimmzüge" lesen kann. Für Ersteller und Leser sind die im "Hintergrund" getroffenen Vereinbarungen und Normen (häufig historisch bedingt) im Allgemeinen unerheblich. Im Unterschied zu Bilddateien, Datenbankdateien, Tondateien, kompilierten Programmdateien usw. kommt es nur auf die Darstellung von Buchstaben und die Formatierung von Wörtern und Sätzen (Textgestaltung) an.-- Kölscher Pitter 12:14, 3. Mär. 2008 (CET)

Das ist nicht richtig, da der Informatikfachbegriff "Textdatei" eine STRUKTUR beschreibt. Eine Datei in der ein oder mehrere Zeilen von so etwas vorkommen

2r3kr/p2q1p1p/3BnP1Q/2pb1N2/3n4/P2p2P1/1P3P1P/R3R1K1 w - - 0 1

ist auch eine Textdatei. Es handelt sich um die FEN-Notation des Schachspiels, welche die Stellung auf dem Brett beschreibt. Das w weiter hintern beschreibt, wer am Zug ist ( w = white). Die kryptisch anmutenden Symbole zwischen den "/" beschreiben die Stellung von Reihe 8 absteigend zu Reihe 1 auf dem Schachfeld. Kleine Buchstaben sind schwarze Figuren, grosse weiße Figuren, Zahlen Leerfelder. Also fangen wir an: In Reihe 8 zwei Leerfelder, dann ein schwarzer Turm (r Rock), dann drei Leerfelder, dann der schwarze König (k king) dann ein weiterer schwarzer Turm (r Rock) fertig, weiter mit Schachreihe 7 usw..

Nach einem Zug ergibt sich eine neue Situation auf dem Schachfeld, die man in einer neuen Zeile in gleicher Notation darstellt. Die FEN-Notation erlaubt es, Millionen von Schachspielen nach "Stellung schon mal vorgekommen" effizient zu durchsuchen. Die FEN-Notation des Schachspiels ist eine Textdatei mit einer Zeile nach jedem Zug, der die gesamte neue Stellung auf dem Brett beschreibt. Mit Begriffen wie "Wörter", "Sätze" usw. kommt man da nicht weiter. Die Datenstruktur "Textdatei" hat mit dem umgangssprachlichen Verständnis von "Text" verwirrenderweise nichts zu tun. --Hgn-p 22:22, 3. Mär. 2008 (CET)

Dein (schönes) Beispiel ist kein Gegenargument. Natürlich ist das eine Textdatei. Und wenn du jetzt etwas auf russisch aufgeschrieben hättest, hätte ich beim Lesen auch Probleme. Es hätte sogar verschlüsselt sein können. Wenn ich als Leser weiß, wie ich damit umgehen soll, dann ist der Zweck erfüllt. Autocad hat ein Format für Zeichnung (DXF), das man lesen kann. Das ist mühsam und die Datei ist unnötig groß. Mit jedem Edior kann ich da zielgerecht ändern.-- Kölscher Pitter 01:50, 4. Mär. 2008 (CET)

Dein Definitionsversuch ist interessant. Das ist mal was neues. Laut Deiner Definition wäre aber eine DOC-Datei (binäres MS Word Dateiformat), die nur Text enthält, eine Textdatei. Man könnte das so definieren, bestimmt gibt es auch Leute, die das so interpretieren. Dem Sprachgebrauch unter ITlern entspricht das allerdings nicht. Ich weiß nicht, ob es sinnvoll ist, "Absicht" derart zu betonen. Die Absicht, dass der Dateiinhalt vom Empfänger so verstanden wird, wie er gemeint ist, hat man immer, natürlich auch bei Textdateien.--Cactus26 06:49, 4. Mär. 2008 (CET)

Ihr kommt euch selbst in die Quere: Eine Worddatei ist keine Textdatei? Was dann? Plain Text? Flat file? Das ist alles unpräzise. Dokumente im PDF oder als Postscript. Was ist das? Dann habe ich als Datenbank eine Datei im cdf-Format. Kann man mit einem Editor reinschauen. Ist eine "Textdatei" nicht etwas, was die Sekretärin früher mit der Schreibmaschine erstellt hätte. Es gab sogar elektrische Schreibmaschinen mit Speicher.-- Kölscher Pitter 09:13, 4. Mär. 2008 (CET)PS: Lies mal einen arabischen Brief. Die schreiben von rechts nach links. Mit dem Ascii-Format kannst du nichts anfangen. Können Araber keine "Textdatei" erstellen?-- Kölscher Pitter 09:28, 4. Mär. 2008 (CET)

Ich verstehe Deinen Definitionsansatz schon. Wahrscheinlich ist das tatsächlich die dem Laien einleuchtenste Form, die am wenigsten technisch ist. Allerdings ist diese Definition in der IT ungebräuchlich. Die Definition beißt sich mit dem MIME Medientyp "Text" (siehe z.B [4]), den alle unterschwellig irgendwo im Hinterkopf haben (nicht alle von Dir genannten Fälle sind dem Medientyp "Text" zuzuordnen). Überhaupt kommt mir gerade, dass es vielleicht mal interessant ist, wie das dort definiert wird. In RFC4288 steht unter 4.2.1 folgendes:

  The "text" media type is intended for sending material that is
  principally textual in form.  A "charset" parameter MAY be used to
  indicate the charset of the body text for "text" subtypes, notably
  including the subtype "text/plain", which is a generic subtype for
  plain text defined in [RFC2046].  If defined, a text "charset"
  parameter MUST be used to specify a charset name defined in
  accordance to the procedures laid out in [RFC2978].
  Plain text does not provide for or allow formatting commands, font
  attribute specifications, processing instructions, interpretation
  directives, or content markup.  Plain text is seen simply as a linear
  sequence of characters, possibly interrupted by line breaks or page
  breaks.  Plain text MAY allow the stacking of several characters in
  the same position in the text.  Plain text in scripts like Arabic and
  Hebrew may also include facilities that allow the arbitrary mixing of
  text segments with opposite writing directions.

  Beyond plain text, there are many formats for representing what might
  be known as "rich text".  An interesting characteristic of many such
  representations is that they are to some extent readable even without
  the software that interprets them.  It is useful to distinguish them,
  at the highest level, from such unreadable data as images, audio, or
  text represented in an unreadable form.  In the absence of
  appropriate interpretation software, it is reasonable to present
  subtypes of "text" to the user, while it is not reasonable to do so
  with most non-textual data.  Such formatted textual data should be
  represented using subtypes of "text".

Das ist doch vielleicht mal ein Ansatzpunkt, das ist aus meiner Sicht eine recht brauchbare Definition. Zu beachten ist allerdings, dass der Scope hier im Vergleich zum Artikel eingeschränkter ist, da hier nur ASCII-verwandte Codierungen betrachtet werden, die interne Welt der Großrechner bleibt unberücksichtigt.--Cactus26 10:30, 4. Mär. 2008 (CET)

Sehr gut. Plain Text ist eine reine Buchstabenfolge ohne Textformatierungen. Auch arabische Texte fallen darunter, auch wenn die Richtung umgekehrt ist. Welcher Buchstabencode (character set) verwendet wird, ist gleichgültig.

Rich text ist plain text plus Formatiercodes.

Auf jeden Fall weg von der Definition über Ascii oder Unicode. Die sind möglich, aber keine zwingende Voraussetzung. Die "interne Welt" ist hier unerheblich.

Man könnte so anfangen: Alle Textdateien basieren auf einem Buchstabenvorrat (character set).-- Kölscher Pitter 11:53, 4. Mär. 2008 (CET)

PS; "is intended" das ist die Absicht.-- Kölscher Pitter 12:03, 4. Mär. 2008 (CET)

Da hast Du Recht. Der erste Satz dieser Definition erinnert schon stark an Deinen ersten Satz. Allerdings gilt das nicht unbedingt für den folgenden Teil. Mir gefällt vor allem der zweite Abschnitt der Definition ganz gut, der das Problem der Unschärfe recht hübsch löst, allerdings ist das nicht ganz leicht verlustfrei zusammenzufassen und zu übersetzten. Sinnvollerweise sollte man die Definition im Artikel auf zwei Teile aufteilen. Den ersten zu Beginn, den zweiten im Abschnitt "Abgrenzung von Binär- und Textdateien".--Cactus26 12:10, 4. Mär. 2008 (CET)

In dem vom Hauptautor selbst vorgetragenem Zitat steht wieder diese von mir seit Tagen vergeblich geforderte Formulierung "a linear sequence of characters, possibly interrupted by line breaks or page breaks."

Ich stimme zu, dass die Codierung im gesamten Lemma ausser im Abschnitt "Geschichte" nichts zu suchen hat. Das ist schlichtweg off topic. In der KLA hat die Argumentation nichts bewirkt.

Mit Begriffen wie Buchstabenvorrat muss man vorsichtig sein. Im allgemeinen gibt es keine scharf definierten Einschränkungen und "Zeichen" wäre besser. Erst die Qualifizierung einer Textdatei als deutsch, französisch, englisch, arabisch, Java Quellcode, HTML, ShellScript, Schachnotation, ....... schränkt die erlaubte Zeichenmenge auf die Syntax der Sprache oder Notation ein. In der Praxis haben wir es selten oder nie mit Textfiles in ihrer allgemeinsten Form zu tun, sondern immer mit einer die erlaubten Zeichen einschränkenden Zeichenuntermenge einer speziellen Sprache.

Rich text ist nicht plain text plus Formatiercodes. Die Metasprache zu Zeichenformatierung, Textlayout und Textstruktur (Qualifizierung von Textteilen als Fussnote, Überschrift,...) muss vielmehr selbst eine Textform haben, wie z.B. im RTF-Format Rich Text Format. Im DOC- oder PDF-Format ist das nicht so. Im übrigen sind letztere Containerdateien, die auch in den Text eingebettete Bilder und Grafiken nach aussen kapseln.--Hgn-p 12:23, 4. Mär. 2008 (CET)

Absicht2

Wer hier Hauptautor ist, ist mir wurscht. Als die Computer das laufen lernten, da konnte ich schon deutsch. Und "off topics" interessiert mich nicht. Ob Buchstabenvorrat (wie seinerzeit bei den Setzern) oder Zeichenvorrat ist Geschmackssache. Vielleicht hätte ich statt "Absicht" besser "Zweck" sagen sollen. Ürsprünglich wurde alles dem Fernschreiber abgeguckt.-- Kölscher Pitter 13:47, 4. Mär. 2008 (CET)

Was du mit "Absicht" und "Zweck" meinst, ist denke ich die Beschränkung des Inhalts und damit dessen Interpretierbarkeit auf die Zeichenmenge und Syntax einer natürlichen oder formalen Sprache oder einer Notationskonvention. Wenn eine Textdatei, eine Sequenz von Zeichen strukturiert in Zeilen , der Grammatik einer spezifischen Sprache entspricht, hat sie einen interpretierbaren Inhalt. Die deklarierte Zugehörigkeit zu einer speziellen Sprache oder Notation ist meist nur durch die Dateiendung wie .txt, .xml, .sc , .pgn, .fen, .ini, .bat, ....... ersichtlich und erfordert häufig das Vorwissen des Benutzers zur Erstellung der Datei. Theoretisch und mit einigem Aufwand kann man natürlich prüfen, ob der Inhalt mit Zeichensatz und Regeln einer bekannten Sprache oder Notationskonvention harmoniert. --Hgn-p 14:42, 4. Mär. 2008 (CET)

Ich werde versuchen, wenn sich die Sache ein wenig beruhigt hat, in Ruhe aus der MIME-Definition und unter Berücksichtigung des hier diskutierten eine überarbeitete Einleitung zu erarbeiten, die mit restlichen Artikel konsistent ist.--Cactus26 16:04, 4. Mär. 2008 (CET)

@Hgn-p, deine Sätze muss ich zweimal lesen. Richtig ist: Erfahrene Benutzer erkennen an der Endung, ob es sich um eine Textdatei handelt oder handeln könnte. Der Computer ist aber schon lange über das Stadium hinaus, wo man auf so was achten muss. Sicherlich ist richtig: man sagt ich habe dir eine Worddatei geschickt und nicht eine .doc-Datei. Vermutlich meinen wir beide dasselbe.-- Kölscher Pitter 16:33, 4. Mär. 2008 (CET)

Gescheiterte KLA Disk vom 4. März 2008

Als Textdatei bezeichnet man in der Informationstechnik eine Datei, deren Inhalt ohne spezielle Verfahren oder Computerprogramme in Text umgesetzt werden kann.

Dank der guten Vorarbeit und Unterstützung anderer waren praktisch schon alle Stichworte in der ursprünglichen Version des Artikels enthalten, ich habe diesen lediglich neu strukturiert und ein wenig ergänzt. Mein Ziel war, diesen Artikel in weiten Teilen laienverständlich zu halten. Aber auch den Fachleuten möchte ich hier eine hilfreiche Zusammenstellung der relevanten Aspekte bieten.--Cactus26 06:33, 25. Feb. 2008 (CET)

Abwartend Insbesondere der Intro-Text muss imho besser gestaltet werden. Rezipienten ohne eine Ahnung, was eine Textdatei sein könnte, werden da denke ich nur verwirrt. Sätze wie deren "...Inhalt in anderer Weise zu interpretieren ist, wobei es viele Varianten und prinzipiell keinerlei Einschränkungen gibt." sind ohne jeden Informationswert. Der Intro-Text kann zudem kaum die Aufgabe haben, zu beschreiben, was der Gegenstand nicht ist. Für Rezipienten mit etwas Computer-Vorwissen sollte man dann auch besser auf die weit verbreiteten *.doc und *.rtf - Dateien eingehen, die die meisten vermutlich mit dem Begriff Textdatei verbinden.--Hgn-p 11:00, 25. Feb. 2008 (CET)

Wie wäre es mit einem Intro-Text auf dieser Basis:

Als Textdatei bezeichnet man in der Informationstechnik eine generische Datei, die als Container ausschließlich Textzeichen sowie ergänzende Sonderzeichen wie z.B. Zeilenende oder Seitenvorschub enthält. Die Datei ist dabei direkt in einem Zeichensatz codiert – beispielsweise ASCII oder Unicode – der im Regelfall dem des Systems entspricht, auf dem die Datei gespeichert ist.

Ist zur Auswertung des Inhalts zudem keine Kenntnis einer speziellen Notation erforderlich, bezeichnet man den Inhalt häufig als plain text (engl. für einfachen Text oder Klartext, häufig verwendete Dateiendung .txt ). Der Begriff Textdatei bezeichnet einen speziellen Typ von Containerdatei, der Begriff plain text einen speziellen Inhalt von Textdateien. Textdateien sind nicht auf den Inhalt plain text beschränkt. Eine RTF-Datei (*.rtf) ist ein Beispiel einer komplexer strukturierten Textdatei, die neben dem eigentlichen Text auch Metatext zur Beschreibung der Formatierung und der Textstruktur enthält. Textverarbeitungssoftware speichern Text und Metainformationen häufig nicht in Textdateien, sondern in proprietären Formaten in Binärdateien, wie z.B. das Format *.doc von Microsoft Word.

Der Begriff Binärdatei wird als Gegenstück zu Textdatei verwendet, wobei Textdateien jedoch spezielle, auf den Textzeichensatz beschränkte Binärdateien sind.

--Hgn-p 18:04, 25. Feb. 2008 (CET)

Noch eine Anregung: Die Gliederungsstruktur würde ich in "klassische Textdateien/plain text" und "strukturierte Textdateien" ordnen. Sätze wie In einer Textdatei können keine besonderen Formatierungen wie beispielsweise Hervorhebungen durch Fettdarstellung festgelegt werden gelten nur für klassische Textdateien mit Inhalt plain text.--Hgn-p 19:21, 25. Feb. 2008 (CET)

Hm, also, es mag Geschmackssache sein, aber ich kann Deiner Einleitungsvariante keine Vorteile abgewinnen. Ich verstehen nicht, was Du Dir von der Einführung der Begriffe "generisch" und "Container" hier versprichst. Auch die Aufnahme von RTF in die Einleitung halte ich für unangebracht, so verbreitet/bekannt ist dieses Format nicht. "Propriätär" halte ich auch für ungünstig, da sowohl Text- als auch Binärformate proprietär sein können.

Deine Anregung in Bezug auf die Gliederung ist interessant, ich habe mich allerdings bewusst dagegen entschieden, da doch viele Aspekte wie Zeilenumbruch, CR/LF, Zeichencodierung, Dateiübertragung usw. diesen beiden Varianten gemein sind.--Cactus26 06:31, 26. Feb. 2008 (CET)

Wie du es formulierst und aufbaust, bleibt dir belassen. Es gibt jedoch einige Fakten, die aus dem Text klarer hervorgehen sollten, als das momentan der Fall ist:

a) Textdateien sind eine Untermenge der Binärdateien

b) Erlaubte Zeichen in Textdateien sind eine Untermenge des Zeichensatzes, nämlich der alphanumerischen Zeichen zuzüglich weniger Steuerzeichen

c) Es gibt schwach strukturierte Textdateien (plain text), die ausser Zeilenumbrüche usw. keine Struktur auffweisen, und komplex strukturierte Textdateien mit einer inneren Syntax zum Zweck maschineller Verarbeitungen oder Interpretationen (script-files, rtf, xml, csv, .......)

d) Mit populären Textverarbeitungen erstellte Textdokumente werden häufig nicht in Textdateien gespeichert, sondern in Binärdateien (z.b. doc).

Das ist m.E. der Kern, den der Intro-Text und das Lemma wiederspiegeln sollten. Dann würde ich zum besseren Verständnis Beispiele von einigen Textfile-Typen wie plain, csv, rtf, xml, ... einbauen. (s. Lemma RTF-Files) --Hgn-p 10:15, 26. Feb. 2008 (CET)

 Pro Ich finde den Artikel tadellos und einwandfrei. --FrancescoA 11:01, 25. Feb. 2008 (CET)

Hgn-ps Kritik kann ich teilweise nicht verstehen, ich würde doc oder rtf-Dateien nicht als Textdateien bezeichnen. Kleinere Unstimmigkeiten sind noch drin, mir gefällt z.B. nicht:

• UTF-8 wird irgendwie zu komplex dargestellt und die Zeichenkodierung und deren Probleme werden m.M.n. zu umfangreich beschrieben, passen denke ich auch nicht wirklich zum Thema, da Zeichenkodierugen ja nicht nur bei Textdateien relevant sind.
• Den Abschnitt Ansehen, Bearbeiten und Drucken von Textdateien halte ich für oberflächlich, überflüssig und nicht zum Thema passend.
• Die Einleitung finde ich ebenso nicht wirklich gelungen und allgemeinverständlich.

Da das aber keine Exzellenz-Kandidatur ist, trotzdem  Pro, wenn auch knapp nach mehr gefundenen Unstimmigkeiten jetzt  Kontra. -- Jonathan Haas 11:51, 25. Feb. 2008 (CET)

Rtf verwendet doch (ausser Microsoft selbst wahrscheinlich) sowieso niemand, oder? :) Diese doc Dateien sind sowieso Binärdateien und erscheinen nur in der Anzeige als Textdateien. In dem Artikel geht es aber um Textdateien als Dateien an sich und weniger um die Interpretationen der einzelnen Dateiformate IMHO. --FrancescoA 11:58, 25. Feb. 2008 (CET)

Natürlich sind *.doc keine Textdateien im Sinne der Informatik. Aber eben darum sollte man im Intro-Text statt diesem umständlichen von mir zitierten Satz auf den Punkt kommen und an das (falsche) Vorwissen der Rezipienten anknüpfen. Wenn man schon im Intro-Text eine Negativdefinition (was es nicht ist) anbringen will, dann wäre hier eine verständliche Abgrenzung zu *.doc Files als Beispiel angebracht. Der erste Satz des Lemma stimmt im übrigen auch nicht; ohne Computerprogramme kann man keine Textdatei in lesbaren Text umsetzen.--Hgn-p 12:12, 25. Feb. 2008 (CET)

>Quetsch>Der erste Satz stimmt schon, es heißt "spezielle ... Computerprogramme">/Quetsch>--Cactus26 13:19, 25. Feb. 2008 (CET)

Richtig, dieser Satz ist eigentlich schon sehr gespreizt und (wahrscheinlich) damit auch nichtssagend. Ohne Computerprogramme geht am Computer nichts. Auch das Betriebssystem und das BIOS sind Computerprogramme. --FrancescoA 12:56, 25. Feb. 2008 (CET)

RTF-Files sind im Unterschied zu DOC-Files natürlich Textdateien. Das eignet sich gut, um den Unterschied zu verdeutlichen und zu verdeutlichen, warum RTF-Files zum Dokumentaustausch zwischen Textverarbeitungen dienen. Auch kann man den Unterschied deutlich machen zwischen a) Sichbarmachung und Editierung der Daten in RTF-Dateien bestehend aus Textinhalten und Angaben zur Formatierung usw. und b) Auswertung der Angaben für eine formatgetreue Textdarstellung.--Hgn-p 12:23, 25. Feb. 2008 (CET)

Da stimme ich auch zu. --FrancescoA 12:56, 25. Feb. 2008 (CET)

Mmmh, irgendwie fehlt mir da jetzt docx und das Äquivalent von OpenOffice, da ja hier über XML wieder die Rückführung zu "Textdateien" einsetzt. Oder sehe ich das falsch? --Tusculum 12:27, 25. Feb. 2008 (CET)

RTF ist nach wie vor der Standard für Dokumentenaustausch, da die Verbreitung von XML-fähigen Textverarbeitungen sich noch in Grenzen hält. Es geht nur um die Aufzeigung des Unterschiedes prorietäre Dokumentdateien zu Textdateien. Um eine RTF-Datei, klar eine Textdatei, zu editieren braucht man natürlich einen Editor und ein Computerprogramm. Um sie intelligent zu editieren oder darzustellen, brauch man einen komplexen Editor, der die Formatierungsinformationen nicht textuell darstellt, sondern in einer GUI-Umgebung umsetzt. Eine mit Word editierbare RTF-Datei ist und bleibt eine Textdatei, eine mit WORD erstellte DOC-Datei ist hingegen keine Textdatei. Dto. OpenOffice.--Hgn-p 12:39, 25. Feb. 2008 (CET)

Rückmeldung zu den aufgelaufenen Punkten:

• Einleitung: Ich halte es hier schon für wichtig (nachdem der 1. Teil der Einleitung ja definiert, was Textdateien sind), dass auch abgegrenzt wird, was eben Textdateien nicht sind. Die Kurzdefinition für Binärdateien ist vermutlich nicht so gelungen, ich überlege mir da noch was habe ich überarbeitet. Auch der Hinweis, dass Doc-Dateien keine Textdateien sind, ist wahrscheinlich tatsächlich in der Einleitung sinnvoll (habe was ergänzt, allerdings stellt sich hier gleich wieder das von Tusculum abgesprochene Problem, dass Textverarb. mittlerweile auch XML zur Speicherung verwenden). RTF halte ich in der Einleitung für zu weit führend, die Abhandlung in "Weitere Dateiformate" halte ich für ausreichend.
• UTF-8: Das Thema habe ich deshalb so breit ausgetreten, weil vielen (auch Fachleuten) glaube ich gar nicht so bewusst ist, dass mit dem mittlerweile sehr verbreiteten UTF-8 die Abgrenzung zur Binärdatei sehr schwierig wird. Meist wird das durch die Editoren derart gekapselt, dass man nicht mitbekommt, was sich heutzutage unter einer geöffneten Textdatei so alles verbergen kann.
• Abschnitt "Ansehen, Bearbeiten und Drucken von Textdateien": Mir war (und ist) die Tabulator-Problematik dabei sehr wichtig und ich hielt diesen Abschnitt für geeignet, das unterzubringen. Auch hielt ich einen ein paar allgemein Sätze über dieses Thema nicht für verkehrt.
• Problematik docx und OpenOffice: Genaugenommen stimmt der Hinweis von Tusculum schon. Nach der umfassenderen Definition des Artikels sind diese Formate Textdateien, da sie XML-Dateien sind. Um Laien nicht vollständig zu verwirren, habe ich das bisher unterschlagen. Man muss es so sehen: Die direkte Bearbeitung von docx ist "möglicher" als die von doc. Ich kenne das Format nicht im Detail (gilt auch für OpenOffice), aber ich vermute mal, dass schon eine genaue Kenntnis des internen Aufbaus des Formats nötig ist, um solche Dateien direkt manipulieren zu können, so dass in der Praxis es kaum einen Unterschied macht, ob eine Datei nun im "doc" oder "docx" Format vorliegt. Bösartig kann man es auch so sehen: Man kann jede Binärdatei in eine XML-Datei umwandeln (das CDATA-Tag mal ausgenommen,.das wäre zu dreist), wenn man Byte für Byte in der Form "<BYTE>FF</BYTE>" codiert. Zurück zum Thema: Ich schaue mal, ob ich den Hinweis, dass es Speicherformate von Textverarbeitungen gibt, die XML verwenden und damit eigentlich "Textdateien" sind, im Artikel unterbringen kann, ohne dass es zu kompliziert wird.

--Cactus26 13:12, 25. Feb. 2008 (CET)

Danke, hielt mich nach dem Kommentar von Hgn-p schon für einen Doofie, obwohl ich beruflich ständig mit so etwas zu tun habe ;-) --Tusculum 16:56, 25. Feb. 2008 (CET)

@Cactus26, ich kann mich leider nicht so ganz mit deiner Einstellung anfreunden.

• @UTF-8: Ich stimme dir da einfach nicht zu. UTF-8 halte ich einfach für nicht wirklich komplex. Sicherlich ist es komplexer, als einfach für jedes Zeichen 1 Byte zu verwenden, ansonsten ist es aber genau das gleiche, wie bei jeder anderen Textkodierung. Problematisch wäre höchstens noch die Byte Order Mark. Ja klar, es gibt viel mehr Zeichen, als bei älteren Kodierungen und die Anforderungen an die Verarbeitungsprogramme sind höher, aber bis auf die variable Zeichenlänge ist es das gleiche. Ein verarbeitendes Programm braucht man eh, weil die Datei ja immer irgendwie kodiert wird. Auch wie schon von anderen im Review angemerkt, finde ich die Erklärungen zu CR/LF und den harten/weichen Zeilenumbrüchen für zuweit vom Thema abschweifend. Sicherlich sollte darauf hingewiesen werden, aber nicht so.

UTF-8: Ich sehe das als fundamentale Komplexitätssteigerung, dass in einer Datei ein Zeichen nicht mehr in einem Byte, ja sogar nicht einmal mehr in einer konstanten Anzahl Bytes kodiert wird. Welche Programmiersprache kann eine solche Codierung direkt verarbeiten? Selbst beim Lesen einer Textdatei ist eine Konvertierung nötig, um sie verarbeiten zu können. Wenn Du das nicht so siehst, kann ich es nicht ändern.--Cactus26 07:57, 27. Feb. 2008 (CET)

UTF-8-Dateien werden von Programmiersprachen und Editoren intern häufig in UTF-16 konvertiert, wo ein Zeichen dann eine feste Breite kriegt. Ansonsten müssen alle Kodierungen (evtl. je nach Definition mit Ausnahme der System-Standard-Kodierung) irgendwie dekodiert werden um sie Darzustellen. -- Jonathan Haas 11:40, 27. Feb. 2008 (CET)

CR/LF: Stimmt schon, der Zusammenhang ist indirekt. Aber ich hatte (und habe) das Gefühl, dass dieser Artikel eine Stelle sein könnte, in der man diese Problematik zusammenhängend abhandeln kann. Ziel das Artikels ist alles zusammenzustellen, was rund um den Begriff Textdatei von Interesse sein könnte, um hier eine Aufstellung aller interessanten Aspekte.--Cactus26 07:57, 27. Feb. 2008 (CET)

• @Letzter Abschnitt: Gegen die Tab-Problematik hab ich nichts, aber was interessiert es, dass es Editoren mit Syntaxhilighting und Druckfunktion gibt? Das gehört vielleicht eher in einen Artikel zum Texteditor. Nochmal zum Tab: Klar gibt es das Problem, aber das ist kein Problem der Textdatei. Deren Eigenschaft ist ja gerade, dass diese (heute) keine komplexeren "Steuerzeichen" enthalten und nicht irgendeine spezielle Spezifikation oder Format (mit Ausnahme der Kodierung) haben. Was Texteditoren mit Zeilenumbrüchen und Tabs machen ist also eher deren Sache, und hat nur indirekt mit Textdateien zu tun.

Syntaxhighlighting: Halte ich in diesem Zusammenhang für interessant, da man sich fragen kann, woher die Information kommt, was hervorgehoben wird. Das sind in diesem Fall eben keine Formatinformationen. Dies ist Dir sicherlich klar, aber anderen vielleicht nicht. Überhaupt habe ich bei diesem Artikel den Eindruck, dass jeden was anderes interessiert oder stört. Es ist schwierig, es hier allen recht zu machen. --Cactus26 07:57, 27. Feb. 2008 (CET)

Ach, darauf beziehst du das. Die Info, dass die "Farbinfo" nicht in der Datei gespeichert wird ist möglicherweise schon sinnvoll, sollte dann aber vielleicht eher in den Abschnitt kommen, indem steht, was eine Textdatei ist und was nicht. -- Jonathan Haas 11:40, 27. Feb. 2008 (CET)

Weitere Sachen, die mir jetzt aufgefallen sind:

• »Zudem existiert die Konvention, am Beginn einer Datei mittels spezieller Bytefolgen (sogenannte Byte Order Marks) kenntlich zu machen, welche Unicode-Codierung verwendet wird.« Naja, soweit ich das beurteilen kann sind BOMs bei UTF-8 kaum verbreitet, insbesondere weil die eben in älteren Editoren und vielen Webbrowsern (welche ja auch HTML-Textdateien darstellen) Probleme machen, indem sie die BOM anzeigen. Wenn du anderer Meinung bist, belege den Sachverhalt bitte.

BOM ist verbreiteter, als man denkt. Bereits Notepad unter Windows 2000 schreibt eine BOM, wenn man beim SaveAs den ensprechenden Code auswählt. Als weiterer Beleg vielleicht dieser Link, wo es darum geht (wenn ich es richtig überflogen habe), bei der Dateierstellung unter .Net zu verhindern, dass eine BOM geschrieben wird. Auf meinem Rechner, vor dem ich gerade sitze, können alle Editoren das BOM interpretieren, außer EDIT unter einem DOS-Fenster, aber das kann man wohl nicht verlangen.--Cactus26 07:57, 27. Feb. 2008 (CET)

Editoren kennen die/das BOM üblicherweise. Browser und Programmiersprachen wie gesagt eher weniger. Und gerade das Bestrebungen existieren, das BOM zu unterdrücken, zeigt eigentlich auch, dass es Probleme macht. -- Jonathan Haas 11:40, 27. Feb. 2008 (CET)

• @File Transfer: Es schadet prinzipiell auch nicht, Textdateien binär zu kopieren, man muss halt nur auf dem Zielsystem wissen, welche Zeichenkodierung verwendet wird. Das kann entweder über das Datenübertragungsprotokoll passieren, z.B. bei HTTP über die Content-Type-Angabe, es kann auch in der Datei stehen (z.B. BOM oder META-Tag) oder man verlässt sich eben darauf, dass das Zielsystem/Programm standardmäßig oder automatisch die richtige Kodierung verwendet. -- Jonathan Haas 16:31, 26. Feb. 2008 (CET)

Klar kann man Textdateien auch binär übertragen und anschließend im Zielsystem konvertieren. Die erfordert, wie Du auch beschreibst, dass die Codierung in der Datei selbst eingetragen ist (ein BOM dabei zu interpretieren, ist aber eher geraten als gewusst). Der HTTP Weg ist auch ein wenig gemogelt, den zur Interpretation des entsprechenden Tags muss ja zumindest bekannt sein, dass der vorliegende Code eine ASCII-Variante ist, der Spaß funktioniert ja nur, da die ersten 127 Zeichen ja überall übereinstimmen und diese Tags nur diese verwenden. Läge die Datei in EBCDIC vor, hättest Du verloren. Aber wie auch immer. Würdest Du solche Erläuterungen im Artikel für nützlich halten?--Cactus26 07:57, 27. Feb. 2008 (CET)

Oder es erfordert eben einfach, dass man weiß dass das Zielsystem die Datei genauso verarbeitet wie das aktuelle und dass eine Konvertierung (die übrigens auch durchaus verlustbehaftet sein kann und deshalb nicht leichtfertig automatisch durchgeführt werden sollte) nicht nötig sein wird. @ HTTP-Weg: Nö, der HTTP-Header hat ja ne festgelegte Kodierung, wahrscheinlich ASCII. Für den HTML-Meta-Tag trifft dein Beispiel zwar zu, das ist allerdings nur ein Fallback, zudem dürften solche exotischen Kodierungen wie EBCDIC (was ich übrigens garnicht kenne, wahrscheinlich bin ich zu jung) in modernen Systemen und insbesondere im Internet kaum/nicht verbreitet sein. @Nützlich: Nein, nicht direkt, weil das auch etwas weit abschweift. Nur so wie es jetzt ist, kann man es m.M.n. auch nicht stehen lassen. Vielleicht sollte man ne Geschichtskomponente in den Artikel reinbringen, dann könnte man so Kodierungsprobleme und automatische Konvertierungen beim FTP eher in den historischen Teil packen und das UTF-8-Zeug eher in den moderneren. Natürlich waren Textdateien früher das gleiche wie heute, aber das Einsatzgebiet, die Bearbeitungsmöglichkeiten usw. haben sich schon leicht verändert. Heute wird soweit ich das beurteilen kann z.B. kaum die Kodierung konvertiert, sondern die Editoren und Anzeigeprogramme können einfach mit den vielen Kodierungen umgehen. Dabei bleibt natürlich das Problem, das man irgendwie die Kodierung erkennen muss (was einfach nicht zuverlässig möglich ist) und ich kann mir vorstellen, dass solche Probleme früher, vor der Win3.1-Zeit, nicht so stark verbreitet waren (wobei ich das nicht sicher sagen kann). -- Jonathan Haas 11:19, 27. Feb. 2008 (CET)

Ich führe die Diskussion der Übersicht halber mal hier weiter und greife die aus meiner Sicht offenen Punkte mal einzeln auf (habe hoffentlich keinen vergessen):

• BOM: Gerade dass es Probleme macht, macht es vielleicht erwähnenswert, finde ich.
• Syntaxhighlighting, Abschnitt "Ansehen, Bearbeiten und Drucken von Textdateien": In diesem Abschnitt habe ich so alles "liegengebleibene" untergebracht. Das Highlighting bei der Entscheidung zu erwähnen, was eine Textdatei nicht ist, ist prinzipiell auch möglich, führt dort vorn aber recht weit. Ich hielt die Lösung, das alles im letzen Abschnitt unterzubringen für praktisch und hübsch. Aber mit dieser Meinung bin ich wohl recht allein. Es ist nur die Frage, wohin mit der "Tab-Problematik" dieses Abschnitts (die mir sehr, sehr wichtig ist). Auch halte ich die Abhandlung hier für angebracht. Eine Alternative wäre der Artikel Tabulator. Wobei der sich im jetzigen Zustand nur mäßig eignet. Aber warum stört es hier? So ausschweifend ist es ja nicht. Und ich habe mal unterstellt, dass sich einige vielleicht beim Öffnen von Textdateien oft fragen, warum die so "zerfranst" aussehen und die Einrückung so dämlich ist und gar nicht wissen, dass das mit dem Tab zu tun hat. Auch deshalb ist vielleicht eine Erwähnung in diesem Artikel sinnvoll.
• HTTP/HTML: Du hast schon recht, hier EBCDIC zu erwähnen ist rein hypothetische Klugscheißerei, so weit ich weiß ist hier ASCII für die ersten 127 Zeichen im Protokoll bereits definiert (siehe [5]). Ich hatte halt schon die (vielleicht etwas antiquierten) Probleme hier im Kopf, wenn man gar nicht weiß, was Trumpf ist, wie das bei ASCII/EBCDIC eben der Fall ist.
• Bedeutung gänzlich unterschiedlicher Codierungen. Aus allen Deinen Äußerungen wird offensichtlich, dass die Problematik der gänzlichen Inkompatibilität der Codierungen nicht für bedeutend hältst. Dein Fokus liegt klar auf den "ASCII-Derivaten" (da beziehe ich Unicode mit ein). Früher zumindest hatte die EBCDIC-Welt von IBM schon eine Bedeutung. Ich hatte auch schon lange nichts mehr damit zu tun, aber die IBM-Mainframes gibt es ja noch.
• Dateikonvertierung, Filetransfer: Im Abschnitt "Austausch zwischen unterschiedlichen Systemen" wird folgendes erwähnt: Der Austausch von Dateien, die nur die ersten 128 Zeichen des ASCII verwenden, ist auf Systemen, die diese oder eine daraus abgeleitete Codierung verwenden, meist recht problemlos.. Damit ist genau das gemeint, was Du oben beschreibst, nämlich dass oft keine Konvertierung nötig ist. Du hast aber recht, es kann Fälle geben, in denen man keine Konvertierung durchführen sollte, wenn die Datei auf dem speichernden System nur gespeichert und selbst nicht verwendet wird. Ich hielt das nicht für bedeutend, aber das habe ich möglicherweise unterschätzt. Ich habe mal einen Satz ergänzt, prüfe ihn bitte. Überhaupt ist dies sicher der Abschnitt, bei dem ich mich am unwohlsten fühle, da ich nicht gerade Spezialist auf diesem Gebiet bin. Mein Wissen ist da recht alt, stamm aus der Zeit, als die IBM-Welt noch eine Bedeutung hatte. Welche Bedeutung EBCDIC heute hat, kann ich leider nicht genau einschätzen.

--Cactus26 14:13, 27. Feb. 2008 (CET)

Das Lemma hat den Titel Textdateien und die Aufgabe, positiv zu beschreiben, was das ist und welche Untergruppen von Textdateien es gibt. Die eingehende Beschäftigung mit Codierungen ist ebenso Themaverfehlung wie Hinweise zur Zweckmässigkeit von Fließtext versus harten Zeilenschaltungen. Es hat nichts mit Textdateien zu tun und ist einzig und allein eine Frage der Funktionalität des weiterverarbeitenden Programmes, wie z.B. verfahren wird, wenn Textzeilenlänge und druckbare Zeichen auf der breite des Papiers oder der darstellbare Zeichen in einer Zeile einer Anzeigebox einer GUI-Oberfläche differieren; also Einfügen zusätzliche Zeilenschaltungen, Verschlucken des Restes oder virtuelles Erweitern mit einem Scroll-Bar. Mit den diversen Dateisystemen wie Fat, Fat32, NTFS, Reiser4, ext2, ...... beschäftigt sich das Lemma ja auch nicht, obwohl jedes dieser Dateisysteme einen anderen Inhalt von gespeicherten Textdateien impliziert. Betrachtet wird eine idealisierte, aus der Betriebssystemverwaltung extrahierte Datei. Analog ist die Codierung irrelevant. Eine Textdatei ist eine Untermenge der binären Dateien, deren Nutzdaten interpretiert mit der zu Grunde liegenden Codierung nur aus der Untermenge der alphanumerischen Zeichen ergänzt um wenige erlaubte Sonderzeichen besteht. Dann sollten die Geschichte beschrieben werden und die verschiedenen Typen wie schwach strukturierte Textdateien (plain text) und stark strukturierte Textdateien(XML, CSV, ...). Codierungsprobleme beim Datenaustausch haben nichts mit dem Lemma zu tun. Auch wenn ich mich wiederhole: "..ohne spezielles Programm als Text darstellbar" ist eine unmögliche Definition einer Textdatei in der Grauzone zwischen falsch und missverständlich. Genau wie sich auf jedem System ein einfacher Editor befindet, befindet sich da auch ein Webbrowser. Aus Sicht der Rezipienten solcher Artikel ist weder ein Editor wie Notepad, noch ein Webbrowser ein "spezielles Programm". Rezipienten können die unterschiedliche Komplexität nicht unbedingt einschätzen, sondern verstehen unter "spezielles Programm" unter Umständen "gekauft, nachinstalliert". Sprachanalytisch ist andererseits jedes Programm speziell. Das Lemma ist in der bestehenden Form imho näher am "Überarbeiten"-Tag als am "Lesenswert"-Sternchen.--Hgn-p 15:21, 27. Feb. 2008 (CET)

Ich wüsste nicht, dass es eine Vorschrift gibt, dass ein "Lemma" (du meinst ein Artikel) ein Thema positiv zu beschreiben hat. Welcher Weg einfacher ist, sollte dem Thema überlassen bleiben. Außerdem ist der erste Teil der Einleitung positiv, der zweite Teil eine Abgrenzung. So sollte es mMn auch sein.

Hier von "Themaverfehlung" zu sprechen, erinnert ein wenig an Schulaufsatz. Ich bin durchaus der Meinung, dass ein Artikel auch die am Rand liegenden Aspekte mit beschreiben sollte, sofern sie im Zusammenhang mit diesem Thema von Belang sind. Das ist in vielen Fällen sogar nötig, damit der Artikel überhaupt zu verstehen bzw. der Inhalt richtig eingeordnet werden kann. Noch dazu ist keiner der angesprochenen Punkte wirklich redundant. Ich halte nach wie vor alle angesprochenen Punkte in Verbindung mit Textdateien für interessant. Du bis hier anderer Meindung, das respektiere ich. Allerdings kann ich mit dem Satz Betrachtet wird eine idealisierte, aus der Betriebssystemverwaltung extrahierte Datei nichts anfangen, was willst Du damit sagen? Auch ist eine Textdatei nicht unbedingt eine Untermenge einer Binärdatei, da sich der Begriff "Binärdatei" ja gerade dadurch definiert, dass er das Gegenstück zur Textdatei ist. Die Formulierung "...ohne spezielles Programm als Text darstellbar" ist wohl tatsächlich missverständlich, Du hast sie offensichtlich falsch verstanden. Aus Sicht der Rezipienten solcher Artikel ist weder ein Editor wie Notepad, noch ein Webbrowser ein "spezielles Programm": Eben!--Cactus26 15:58, 27. Feb. 2008 (CET)

Die Wikipedia-Definition von Binärdateien ergibt klar und korrekt, dass Textdateien eine Untermenge sind.

Eine Textdatei auf dem Datenspeicher eines spezifischen Betriebssystemes und Dateisystemes enthält zwischen Begin-Of-File-Marke und End-Of-File-Marke eine Fülle von Binärinformationen wie z.B. Verlinkung der Speicherblöcke, Prüfsummen, Admin-Angaben zu Eigentümer, letzte Änderung, Erstellung, ...... . Bei der Definition einer Textdatei bleibt das alles ausser Betracht; nur über die Nutzdaten erfolgt die Definition. Sogar eine Chiffrierung/Dechiffrierung kann auf Betriebsystemebene erfolgen, so dass die tatsächlich gespeicherte Datei eine reine Binärdatei ist. "Textdatei" ist ein logisches Datenobjekt der Anwendungsebene.

Ohne eine Menge Software kann man auf Datenträgern gespeicherte Textdateien überhaupt nicht als Text darstellen. Wenn man dann alles, was man ohne spezielle Programme, aber mit üblichen "Bordmitteln" als Text darstellen kann, als Textdatei definiert, ist es falsch. Die einzig richtige Definition einer Textdatei ist die Beschränkung der Nutzdaten auf alphanumerische Zeichen plus die paar erlaubten Sonderzeichen.--Hgn-p 16:59, 27. Feb. 2008 (CET)

Zur Abgrenzung Binärdatei/Textdatei ist alles gesagt, denke ich. Nun gehst Du auf das physische Speicherformat los und wirfst hier mit einer Menge Begriffen um Dich. Aber ist das hier relevant? Natürlich ist allein schon eine Datei eine Abstraktion, da stecken heute schon viele Schichten dazwischen. Das gilt aber für eine Binär- und Textdatei gleichermaßen. Auch eine Binärdatei wird chiffriert, wenn ein solches Verfahren aktiviert ist. Für den Artikel ist aber wohl ausreichend, dass als Datei anzusehen, was man im Windows beispielsweise mit dem API OpenFile bekommt. Alle Schichten, die da drunter verborgen sind, sollten hier nicht interessieren.--Cactus26 17:26, 27. Feb. 2008 (CET)

Das war meine Rede und eben darum sollte man eine Textdatei als logisches Datenobjekt einer Sequenz alphanumerischer Zeichen definieren und das Zeichencodierungsthema genau wie das Thema der physisch gespeicherten Datei klein halten. Eine typische "README" - Datei ist und bleibt aus Sicht der Anwendungsebene eine Textdatei, gespeichert in einem komprimierten Ordner unter NTFS ist es aber keine.--Hgn-p 18:17, 27. Feb. 2008 (CET)

Ich bin hier, wie gesagt, anderer Meinung: Eine Textdatei bleibt eine Textdatei, auch wenn sie in einem komprimierten Ordner gespeichert ist (ob chiffriert oder komprimiert, s.o.). Bei einer "von Hand" komprimierten Datei könnten wird drüber diskutieren, aber wenn die Komprimierung gekapselt durch das Betriebssystem erfolgt, dann mMn nicht. Aber letztlich ist das alles nicht sonderlich von Belang (schön, dass wir drüber gesprochen haben ;-) ) --Cactus26 07:31, 28. Feb. 2008 (CET)

Halt, nehme letzteres zurück. "Komprimierung" ist ja tatsächlich ein interessantes Stichwort. Man könnte erwähnen und erläutern, warum bei Textdateien die Komprimierungsrate typischerweise höher ist als bei Binärdateien. Was meinst Du?--Cactus26 08:17, 28. Feb. 2008 (CET)

Es geht um Textdateien und das ist zweifelsohne eine wichtige Eigenschaft solcher Dateien und gehört zum Thema. Primär geht es aber um eine exzyklopädietaugliche Definition einer Textdatei. Diese kann imho nur noch auf der Ebene logischer Datenobjekte als Sequenz alphanumerischer Zeichen erfolgen. --Hgn-p 10:51, 28. Feb. 2008 (CET)

Wenn du chiffrierte, komprimierte,..... Textdateien weiter als Textdateien sieht, müsstest du folgende Definition wählen: Ein Textdatei ist eine Datei, die aus Sicht der Anwendungsebene nach Extrahierung aus dem Dateisystem des Datenspeichers und gegebenenfalls Dechiffrierung und Dekomprimierung durch Systemsoftware eine Sequenz aus ausschliesslich alphanumerischen Zeichen und den Sonderzeichen (....) darstellt. Wenn man mit einem Hex-Editor an Plattenblöcken rumfummelt, kann man kaum feststellen, ob ein Block zu einer chiffrierten oder komprimierten Textdatei gehört.--Hgn-p 11:37, 28. Feb. 2008 (CET) Sachlich und sprachlich korrekt handelt es sich bei segmentierten, komprimierten, chiffrierten ... Textdateien aber um isomorphe Abbildungen von Textdateien, die selbst jedoch keine Textdateien sind.--Hgn-p 14:43, 28. Feb. 2008 (CET)

Aha. Einer der Gründe, warum die Computerwelt sich so schwer tut, von Laien verstanden zu werden, liegt mMn darin, dass einige Informatiker bei Nichtexistenz einer einheitlichen Definition dazu neigen, sich eine auszudenken, die möglichst viele beeindruckende Fachtermini kombiniert und schwer als Unsinn zu enttarnen ist.--Cactus26 16:29, 28. Feb. 2008 (CET)

MS Encarta definiert Datei als „benannte, als Einheit betrachtete Datenmenge“ und Textdatei als „Datei, die nur aus alphanumerischen Zeichen besteht“. Da die Datenmenge ja eine Ordnung hat (1.,2.,3.,… Zeichen), habe ich es genauer Sequenz genannt. Ausgedacht ist da nichts. Aber du könntest ja mal die Quelle deiner Definition, die du vehement verteidigst, verraten. Da habe ich den Verdacht auf „ausgedacht“, weil es einfach unhaltbar ist. „Als Textdatei bezeichnet man in der Informationstechnik eine Datei, deren Inhalt ohne spezielle Verfahren oder Computerprogramme in Text umgesetzt werden kann.“ Welche relevante Literatur verwendet diese Definition? Ellenlange Diskussionen machen aber keinen Sinn, wenn der Hauptautor wenig Bereitschaft zu Verbesserungen zeigt, dieses hier ist ja eine Abstimmung. Ich stimme mit  Kontra. Das Lemma ist in einigen Punkten fehlerhaft und muss überarbeitet werden.--Hgn-p 18:01, 28. Feb. 2008 (CET)

Meine obige Äußerung ist natürlich auf mich genauso anwendbar, bin ja auch Informatiker und kann nicht aus meiner Haut. Meine Definition stützt sich vor allem auf Dale Lewis (siehe auch englischer Artikel). Mir ist auch aufgefallen, dass an vielen Stellen der Begriff viel präziser definiert wird und mit einem physischen Speicherformat assoziiert wird. Dabei wird aber häufig bereits übersehen, dass es neben ASCII auch noch andere Codierungen gibt. Auch wird das dem in der Praxis verwendeten Begriff in keiner Weise gerecht. Ich habe einen Zusatz in der Einleitung ergänzt, der verdeutlichen soll, dass Textdatei viel eher ein "Konzept" darstellt, als ein Speicherformat. Meine Ansicht nach sind Definitionsversuche, die versuchen auszuzählen, welche Zeichen denn nur in einer Textdatei vorkommen dürfen und was nicht, nicht zweckmäßig, da sie viel zu viele Wenns und Abers enthalten müssten, wollten sie abdecken, was es tatsächlich so alles gibt. Ich kann Deine Anregungen nicht im Artikel umsetzen, denn würde ich Dir folgen, müsste ich ihn neu schreiben (sagst Du ja auch so). Ich stehe aber weiterhin hinter dieser Art von Definition, auch wenn man im WWW zahlreiche andere findet, die eine vermeintlich klare Definition anbieten.--Cactus26 07:08, 29. Feb. 2008 (CET)

Das Lemma im englischen Wiki ist besser, hat trotzdem derzeit ein Überarbeiten-Tag wegen sachlicher Ungenauigkeit und benutzt die akzeptable Definition Text files are sequences of readable characters such as letters, digits, punctuation, or whitespace; and control characters such as section boundaries, rendering instructions for different languages, line feeds and carriage returns. --Hgn-p 13:19, 29. Feb. 2008 (CET)

(BK,Ich entferne mal die Einrückung)

1. Für die Datei ist es völlig unerheblich, ob das Dateisystem komprimiert. Natürlich ist auch eine Textdatei auf einem komprimierten NTFS-Ordner ne Textdatei. Schwieriger ist das ganze schon bei einer Datei wie Bla.txt.gz, da will ich mich nicht festlegen.
2. Den englischen Artikel zu nennen ist etwas merkwürdig. Dieser hat z.B. nen fetten Überarbeitungsbaustein. Zudem steht da ja schon, was mit Hgn-ps Definition halbwegs übereinstimmt: „Text files are sequences of readable characters such as letters, digits, punctuation, or whitespace; and control characters“ <- Diese Definition finde ich ehrlich gesagt ganz passend. Zumindest wird da nichts irgendwie dubios in Text umgesetzt. Andererseits steht in dem Artikel auch, dass Textdateien keine Binärdateien sind, was zwar im allgemeinen Sprachgebrauch ganz OK sein kann und vielleicht auf einfach Definitionssache ist, was ich aber dennoch so nicht in den Artikel schreiben würde.
3. Die Definition, welche Zeichen in einer Textdatei vorkommen dürfen ist tatsächlich blöd. Sparsam verwendet darf wohl jedes Zeichen in einer Textdatei enthalten sein, z.B. wenn man eben dieses erklärt. Und Binärdateien bestehen ja auch größtenteils aus lesbaren Zeichen (wer würde mit Ausnahme der Steuerzeichen nicht-lesbare Zeichen in einer Zeichenkodierung definieren?). Binärdateien haben die nur nicht in einer als Text lesbaren Form angeordnet. -- Jonathan Haas 13:24, 29. Feb. 2008 (CET)

In den Punkten 1 und 3 stimmen wir ja weitestgehend überein, wenn ich Dich richtig verstehe. Den englischen Artikel habe ich mir wohl nicht genau geung angesehen, ich bezog mich dabei auf den Satz This broad two-level distinction is widely recognized and applied in computing, even though it can be misleading, and subject to differing interpretation der Einleitung.--Cactus26 13:41, 29. Feb. 2008 (CET)

Ergänzung von mir:

Die heute erfolgte Ergänzung zu docx-Files ist imho sachlich falsch. Dieses Format ist keine Textdatei bestehend aus Metatext und Text, sondern eine komplexe Containerdatei. Als Beispiel erwähne ich mal, dass im Text integrierte Grafiken und Fotos Bestandteil der Datei sind.

Zum Vorschreiber möchte ich einwenden, dass es einfach unterschiedliche Sichten sind, die sprachlich eben entsprechend sauber getrennt werden müssen. Aus der Sicht der Anwendungsebene ist und bleibt eine Textdatei eine Textdatei, auch wenn komplexe Transformationsprozesse zum Zwecke der segementierten, umcodierten, kompromierten oder chiffrierten Speicherung die Datei umkehrbar in eine Nicht-Textform wandeln. Für die Anwendungsebene wird immer transparent eine Textdatei, also eine Sequenz der erlaubten Zeichenmenge, zur Verfügung gestellt. Auf Systemebene hat man es hingegen mit Binärdateien zu tun. Ein Readme-Datei in einem komprimierten, chiffrierten NTFS-Verzeichnis ist aus Sicht des Anwenders transparent eine Textdatei, aus Sicht der Systemprogrammierer eine Binärdatei, die keineswegs auf die erlaubte Zeichenmenge von Textdateien beschränkt ist. Es handelt sich da nicht um Widersprüche, sondern unterschiedliche Sichten und die Definitionsfrage, ob man eine Sache nach einem umkehrbaren Transformationsprozess weiter mit ihren ursprünglichen Eigenschaften bezeichnet. --Hgn-p 14:18, 29. Feb. 2008 (CET)

Die Sicht eines Systemprogrammierers interessiert IMHO herzlich wenig. Eine Datei muss weder auf irgendeinem komplexen Dateisystem liegen noch überhaupt auf einem Datenträger existieren. Aus Sicht des Systemprogrammieres sind alle Dateien Binärdateien, einen Systemprogrammierer interessiert der Inhalt solcher Dateien auch überhaupt garnicht. Man muss halt nur dafür sorgen, dass die Anwendungsprogramme die Dateien lesen können, das ist aber völlig unabhängig von deren Inhalt. Es gibt keine Funktion, mit der man Textdateien erkennen und irgendwie anders verarbeiten könnte. -- Jonathan Haas 14:38, 29. Feb. 2008 (CET)

Es ist je eine Abstimmung und kein Review. Angesichts der Vielzahl von Problemen wie eine unhaltbare Definition, zahlreiche Ungenauigkeiten bis zu sachlich falschen Darstellungen und abschweifende, kaum zum Lemma gehörende Inhalte bei geringer Bereitschaft des Hauptautors zu Änderungen sehe ich keine Chance, das Lemma inerhalb der Abstimmungszeit in eine akzeptable Form zu bringen. Du hast begründet mit Contra gestimmt, ich auch. --Hgn-p 15:08, 29. Feb. 2008 (CET)

Es ist eben keine Abstimmung, jedenfalls nicht nur, sondern auch ne begründete Diskussion. Ich halte es jedenfalls für sinnvoll, den Artikel nochmal etwas länger ins Review zu stecken. Auf die Kommentare zum alten Review wurde soweit ich das sehen kann auch nicht wirklich eingegangen. -- Jonathan Haas 16:02, 29. Feb. 2008 (CET)

Ich stimme zu. Bei gescheiterter Lesenswert-Wahl muss es mit einem Review weitergeben und angesichts der auch von dir festgestellten Unstimmigkeiten ist ein Überarbeiten-Baustein wohl notwendig.--Hgn-p 16:36, 29. Feb. 2008 (CET)

Nun, in ein paar Punkten scheinen wir ja einen Konsens zu erzielen, in ein paar anderen (zugegebenermaßen fundamentalen nicht). Also noch einmal eine Stellungnahme:

• docx-Files (@hgn-p): Ich stimme Dir zu, dass man diese Datei als Container-Datei interpretieren kann. Ich stimme Dir nicht zu, dass der Artikel falsch ist (woher nimmst Du die beneidenswerte Sicherheit für solche Aussagen?). Lass mich hier zu ein (zugegebenermaßen hypothetisches) Beispiel erzeugen: Unterstellt es gäbe ein "Word For UNIX" und man wollte eine Docx-Datei von Windows nach UNIX übertragen, müste man in dem Tool, das man zur Übertragung benutzt, eine CheckBox mit der Aussage "Textdatei"(oder einen vergleichbaren Schalter) ankreuzen, um für die eigentlich notwendige Ersetzung von CR/LF zu erzwingen.
• Aus Sicht eines Systemprogrammierers sind alle Dateien Binärdateien: Das stimmt so sicher nicht. Überhaupt: Was ist eigentlich die korrekte Definition eines "Systemprogrammierers"?
• Es gibt keine Funktion, mit der man Textdateien erkennen könnte: Stimmt. Zumindest keine sichere. Deshalb haben ja "Profi-Tools" zur Dateiübertragung eine Auswahlmöglichkeit, ob Text- oder Binärdatei, die der Benutzer erfassen muss.
• Auf die Kommentare im Review wurde nicht eingegangen: Das stimmt so mMn nicht. Ich scheine nur tatsächlich mit meinem Blickwinkel hier alleine zu sein. Ich versuche es nochmals auf den Punkt zu bringen:
  • Es gibt keine eindeutige Definition, was eine Textdatei ist und was nicht.
  • Die Einleitung ist aus diesem Grund zu Beginn unscharf, um dem Rest des Artikels nicht zu widersprechen. Ich sehe bis jetzt keine bessere Lösung.
  • Der Artikel versucht als Alternative, alle Randaspekte aufzuführen, die mit dem unscharfen Begriff Textdatei zu tun haben, um so ein Bild von diesem Begriff zu erzeugen

Im Review und auch hier wurde immer wieder versucht, mich von einer knappen, einfachen (die möglichen Zeichen aufzählenden) Definition zu überzeugen. Das halte ich nicht für zweckmäßig, nach wie vor.--Cactus26 17:43, 29. Feb. 2008 (CET)

• @Systemprogrammierer: Stimmt, die Formulierung ist nicht gelungen. Sagen wir besser aus sich eines Computers
• @Definition: Möglich. Nur ist die aktuell im Artikel enthaltene Definition nicht wirklich OMA-freundlich und auch nicht besonders logisch. Siehe oben.
• @Einleitung: Sie ist nicht unscharf sondern unlogisch und unverständlich.
• @Randaspekte: Das ist keine Lösung. Wenn etwas schwer zu definieren ist, sollte man die vorhandenen Definitionen erläutern, irgendwie auf einen gemeinsamen Nenner bringen und sich vielleicht auch nicht zu sehr an der Definitionsproblematik aufhalten. Man kann ja einfach irgendne gut formulierte Def. nehmen und darauf hinweisen, dass es andere gibt. Ganz schlecht ist es meiner Meinung nach wenn das Hauptthema nciht klar definieren kann, sich dann ich Kleinigkeiten und entfernten Randgebieten zu verlieren.
• @Review: Wir stimmen überein, dass eine Definition, die Textdateien auf die enthaltenen Zeichen beschränkt, ziemlich schwachsinnig ist.
• Was mir jetzt noch aufgefallen ist: »Das Problem liegt dabei meist beim Absender, da dessen Mail-Client häufig die Codierung der Textdatei nicht korrekt ermitteln kann, vom Benutzer aber diese Angabe aus Gründen der Benutzerfreundlichkeit nicht fordert«. Hallo, sein wann lesen Mail-Clients Textdateien ein? Normalerweise gibt man den Text doch einfach in ein Eingabefeld ein. Und da weiß das Programm wohl schon welche Kodierung es verwendet. (Mal ganz davon abgesehen, ich würde Kodierung mit K schreiben.) -- Jonathan Haas 19:12, 29. Feb. 2008 (CET)

Warum die Einleitung unlogisch sein soll, erschließt sich mir nicht. Unlogisch und unscharf widersprechen sich ja fast. Es sind während des Reviews und auch hier durchaus einige Punkte genannt worden, aus denen ich Verbesserungen ableiten konnte. Die Einleitung hat sich ja durchaus verändert. Ob diese nun laienverständlich ist, weiß ich nicht, es hat sich ja kein wirklicher Laie zu Wort gemeldet, wäre auch viel verlangt gewesen, in Anbetracht der anstrengenden, mit Fachwörtern durchsetzen Diskussion. Anderen Anregungen konnte ich hingegen nichts abgewinnen. Hierzu gehört auch Jonathans, hallo, letzter Vorschlag. Du solltest genauer lesen, es geht um Anhänge von E-Mails, nicht die Mail selbst. Selbst webbasierte Mail-Clients erlauben das Anhängen von Dateien und diese haben es schwer, die Codierung einer Textdatei sicher zu bestimmen. Über das "K" bei Codierung hätten wir reden können, damit ist für mich keine Ideologie verknüpft. Hauptsache einheitlich.--Cactus26 07:14, 3. Mär. 2008 (CET)

Jonathan Haas hat weitgehend zusammengefasst, dass es so nicht geht. Ich versuche es ein letztes Mal, den verhaltenen Änderungswillen des Hauptautors zu überwinden: Hier in Wikipedia steht im Lemma Datei : Eine Datei ist ein strukturierter Bestand inhaltlich zusammengehöriger Daten. Wenn jetzt ein Lemma Textdatei angelegt wird, muss man sagen, was die spezielle Strukturierung einer Textdatei ausmacht. Ein Blick in gängige Werke oder die Klassenbibliotheken zur Bearbeitung von Textfiles von Programmiersprachen hilft weiter: Eine Sequenz von Zeichen, strukturiert durch Steuerzeichen in Teilmengen, die man Zeilen nennt. Ist die erlaubte Zeichenmenge, die Syntax und Semantik des Inhaltes weiter nach dem Regeln einer speziellen Sprache limitiert, handelt es sich um in Zeilen strukturierten Text in deutscher, spanischer, französicher, ... Sprache oder um den Quellcode einer formalen Sprache wie C++, Java, Shellscript, ..... . So einfach ist das und das verstehen auch Laien.--Hgn-p 10:43, 3. Mär. 2008 (CET)

Ich stimme damit mehr oder weniger überein. Nur die Zeilentrennung durch Steuerzeichen finde ich nicht wirklich passend. Das klingt irgendwie so, als wenn es keine einzeiligen Textdateien gäbe und ist meiner Einschätzung nach auch nicht so grundlegend wichtig, dass es in die Einleitung gehört. Die Notwendigkeit von Zeilenübrüchen hast du bestimmt aus einer Programbibliothek, die Textdateien einliest und dann Zeilenweise verarbeitet. Das ist aus Programmierersicht sicherlich richtig und wichtig (weiß ich ja als Hobby-Programmierer auch selber), aber aus der Außenperspektive ist es eher unrelevant. Wie das mit der Zeilentrennung funktioniert, kann man vielleicht irgendwie "konservativer" weiter unten im Artikel erklären. Das Problem ist aber immernoch die Abtrennung zu Nicht-Textdateien. Selbst wenn man die Zeilendefinition drinlässt, wären auch alle Binärdateien (im engeren Sinne) Textdateien, sofern da zufälligerweise ein paar Zeilenumbrüche drin sind. Was spräche gegen eine Definition, dass Textdateien von Menschen lesbaren Text in einer Sprache oder Programmiersprache enthalten? Diese Definition ist sicher noch nicht ausgereift, kann aber vielleicht als Ergänzung zu oberer Definition benutzt werden. -- Jonathan Haas 12:58, 3. Mär. 2008 (CET)

Eine Textdatei ohne Zeilenstrukturierung ist ein zulässiger Sonderfall. "lesbar" ist unglücklich, da es m.E. ein Erkennen von Wörtern und ein semantisches Verständnis impliziert. Tatsächlich ist nur das Erkennen von Zeichen notwendig.

Man darf mit der Deinition nicht hinten anfangen. Natürlich ist jede Binärdatei als einzeilige Textdatei interpretierbar, wenn man ohne Beschränkung der erlaubten Zeichen den Inhalt z.B. als Zeichen aus dem ca. 65.000 Zeichen des Vorrats von Unicode interpretiert. Das wird nur bei einer durch Digitalisierung von Musik entstandenen Datei nie Sinn machen. Deswegen muss man an den Anfang gehen, und eventuell ergänzen, dass die definierte Datenstruktur Textdatei aus den wohlgeformten Ausdrücken einer natürlichen Sprache, einer formalen Sprache oder einer Notationskonvention erzeugt wurde. Da hat man dann alles abgehandelt. Wenn jemand nach einer Notationskonvention Gen-Sequenzen als Buchstabensalat in Zeilen von Textdateien speichert, ist das ohne dieses Vorwissen nicht verstehbar. Lesbar ist das nur im Sinne der Identifizierung einzelner Zeichen, was sich wiederum nicht von fehlinterpretierten Binärdateien in Textform unterscheidet. --Hgn-p 14:19, 3. Mär. 2008 (CET)

Artikel ist nicht lesenswert (Version) --Ticketautomat 00:04, 5. Mär. 2008 (CET)