Diskussion:Textdatei

Dieser Artikel war am 12. Februar 2011 der Artikel des Tages.

Zum Archiv

Wie wird ein Archiv angelegt?

Mutig

Ich war mutig und habe eine neue Einleitung verfasst und hoffe, dass sie "omatauglich" ist.-- Kölscher Pitter 10:47, 5. Mär. 2008 (CET)

Na ja, so ganz einig bin ich mit Deiner Einleitung nicht. Sie widerspricht einigen Teilen des Artikels. Gibst Du mir die Chance, diese (unter Berücksichtigung Deines Standpunkts) nochmal zu bearbeiten oder soll ich mich aus diesem Artikel zurückziehen?--Cactus26 11:24, 5. Mär. 2008 (CET)

Auf keinen Fall zurückziehen. Auch du sollst mutig sein.-- Kölscher Pitter 11:26, 5. Mär. 2008 (CET)

Mut ist nicht das Problem, ich bin nur ein wenig müde.... --Cactus26 11:28, 5. Mär. 2008 (CET)

OK. Ich war etwas respektlos. Aber auch das gehört zum Wiki-Prinzip. Das müssen wir alle ertragen. Und sollte etwas "gut" sein, dann kann es immer noch "besser" werden.-- Kölscher Pitter 11:39, 5. Mär. 2008 (CET)

Überarbeiten

Das Lemma muss überarbeitet werden, näheres siehe gescheiterte Lesenswertkandidatur.

Erfolgte Überarbeitungen am Introtext am 5. März sind sachlich falsch, ohne Quellenangabe und unenzyklopädisch in der Formulierung (Buchstabensalat).

Zu unterscheiden sind Textdatei als definierte Datenstruktur der Informatik (Fachbegriff) und umgangssprachliche Verwendungen.

Ob etwas ein "Buchstabensalat" ist oder nicht, hängt davon ab, ob der Auswerter die Grammatik der Sprache oder Notation kennt. Siehe mein Beispiel einer wohlgeformten Textdatei mit der FEN-Notation oben, die ohne diese Kenntnis "Buchstabensalat" ist.

Textdateien werden keineswegs nur mit dem Ziel erstellt, einem menschlichen Empfänger lesbaren Text zu präsentieren. Gegenbeispiele sind die CSV-Dateien oder INI-Dateien von Windows 98, die dem Datenaustausch zwischen Computerprogrammen dienen oder deren Datenversorgung mit z.B. Konfigurationseinstellungen.--Hgn-p 13:16, 5. Mär. 2008 (CET)

Informatik und Fachbegriffe? Das ist ein haariges Thema. Denn das ist zur Zeit alles im Fluss. Wir befinden uns mitten in einer Revolution. Ich glaube, ich schließe mich Cactus an und werde auch müde. Denn ich ahne so dunkel, dass aus dem Artikel zwar kein Buchstabensalat aber eine Textwüste wird, die niemanden interessiert.-- Kölscher Pitter 13:51, 5. Mär. 2008 (CET)

Ich denke, man sollte erst mal gelassen abwarten, wie Cactus26 die gescheiterte Lesenswertwahl auswertet und seine obige gute Idee, auf Grund der technischen Dokumente die Sache zu überarbeiten, umsetzt. Zumindest meine Kernkritik sehe ich in den Tecdoc's abgehandelt.--Hgn-p 22:41, 5. Mär. 2008 (CET)

Ich werde morgen eine Definition auf Basis der MIME-Definition für den Medientyp Text versuchen (@Hgn-p: Freut mich zu hören, dass eine solche Definition auch in Deinen Augen eine Chance hat). @Kölscher Pitter: Je länger ich über Deinen abstrahierenden Definitionsansatz nachdenke, um so mehr Zweifel kommen mir. Wenn Du Textverarbeitungen und PDF einbeziehst, stellt sich die Frage, ob und wie viele Bilder oder Grafiken enthalten sein dürften, damit das ganze noch als Textdatei durchgeht. Interessant ist schon, dass bislang keine zwei der an der Diskussion beteiligten, wirklich dieselbe Definition zu Grunde legen. Es gibt halt keine "offizielle". Die meisten liegen aber schon in der Richtung des MIME-Medientyps "Text".--Cactus26 07:04, 6. Mär. 2008 (CET)

Es gibt halt keine "offizielle". Völlig richtig. Es gibt aber auch keine exakte. Acrobat- und Word-Dateien sind keine "reinrassigen" Textdateien. Gemeinsam haben sie aber die Absicht der Ersteller, dass es "Kommunikationsdateien" sind. In Abgrenzung zu Programmdateien und Datenbanken. Die Verknüpfung mit einem Zeichenvorrat ist entscheidend. Ich bleibe dabei: IT hat nur wenige Begriffe, die exakt (und dauerhaft) definierbar sind. Mit demgleichen Prinzip (separate, genormte Zeichentabelle plus Anwenderdatei) kann man auch Musiknoten schreiben. Es kommt nur darauf an, wie die Pixel auf den Schirm oder Drucker kommen.-- Kölscher Pitter 09:48, 6. Mär. 2008 (CET)

Es ist sicher nicht so, dass ich Deinen Standpunkt nicht respektiere. Es gibt keine exakte Definition, aber es gibt einen gewissen Konsens der im Umlauf befindlichen Definitionen. Und zu dem steht Deine Definition im Widerspruch. Das denke ich, kann ich nach allem was ich mittlerweile recherchiert und auch sonst hinter mir habe durchaus behaupten. Hast Du ein Problem, wenn ich die Definition in diesem Sinne nochmals überarbeite?--Cactus26 11:14, 6. Mär. 2008 (CET)

Prinzipiell habe ich kein Problem damit. Wenn ich deine Version sehe, werde ich sie vielleicht kritisieren.-- Kölscher Pitter 11:47, 6. Mär. 2008 (CET)

Nur noch mal zur Klarheit: Wir sind keine Normierungsgremium für die Neudefinition des Begriffes Textdatei. Eine Enzyklopädie muß sich auf vorhandene, relevante Quellen stützen. Dabei muß man mit zwei Problemen umgehen a) eine unterschiedliche Definition/Verwendung des Begriffes in verschiedenen Bereichen und b) eine geschichtlich durch technischen Fortschritt bedingte Wandlung des Begriffes. Also Aufzählung der Bedeutungen, aber nicht Vereinheitlichung.

@Kölscher Pitter  : Ob etwas Buchstabensalat ist oder relevante Information, hängt davon ab, ob es aus den regulären Ausdrücken einer natürlichen oder formalen Sprache erzeugt wurde und ob der Rezipient die Grammatik kennt. Was für den einen wüster Buchstabensalat ist, erkennt der andere sofort als Notierung von Gensequenzen nach den Anfangsbuchstaben der Aminosäuren. Da z.B. digitalisierte Musik nicht aus den regulären Ausdrücken einer Sprache erzeugt wurde, wird man bei der Interpretation als Text auch nie einen Sinn festmachen können. Wenn du Textdateien mit sinnvollem Inhalt definieren willst, musst du nicht vom Ergebnis (Buchstabensalat), sondern von der Quelle her definieren: Erzeugt aus der erlaubten Zeichenmenge und Syntax einer natürlichen oder formalen Sprache oder einer Notationskonvention. Nur dann ist eine Zuordnung der Zeichen zu Bedeutung/Sinn möglich.--Hgn-p 12:28, 6. Mär. 2008 (CET)

Die Hersteller verwenden für .doc, .pdf - Dateien usw. völlig korrekt den Begriff "Dokumentdateien", denn es sind keine Textdateien. Die umgangssprachliche Falschverwendung des Begriffes Textdatei für diese Dateien kann man erwähnen, es steht uns aber nicht zu, diese Falschverwendung ohne externe Quellenstützung enzyklopädisch zu legitimieren.--Hgn-p 12:36, 6. Mär. 2008 (CET)

Zitat aus Wiki: Ein elektronisches Dokument wird in der Regel nur dann als wirksam behandelt, wenn der Aussteller eine qualifizierte elektronische Signatur angefügt hat, die ihn zweifelsfrei als Urheber des Dokuments legitimiert und die mit den übermittelten Daten so verknüpft ist, dass eine nachträgliche Veränderung des Dokuments erkannt werden kann. Viel Spaß damit.-- Kölscher Pitter 14:26, 6. Mär. 2008 (CET)

Ein neuer Versuch. Ein paar Anmerkungen zur Überarbeitung:

• Ich habe darüber nachgedacht, die Reihenfolge der Abschnitte "Geschichte" und "Abgrenzung von Binär- und Textdateien zu tauschen". Was meint ihr?
• den Abschnitt "Quelltext für Computerprogramme" habe ich entfernt, da das Entwicklern ohnehin klar ist und andere vermutlich nicht interessiert. Wenn jemand das anderes sieht, kann ich ihn gerne wieder ergänzen.
• Abstraktere Definition (alles ist Textdatei, was Text präsentiert): Ich sehe es so, dass die "Glanzzeiten" des Begriffs Textdatei in seiner heutigen (im Artikel dargestellten Form) vorbei sind. Allerdings ist die abstrakte Definition keine rechte Alternative, diese scheint mir nutzlos. Die heutige Definition dagegen ist für den Endbenutzer relativ nutzlos bis unpraktisch (das ist wohl das, worauf K.P. hinweist), da der Benutzer per Doppelklick sowohl bei einer PDF- als auch bei einer TXT-Datei den Text sieht, der Rest ist ihm wurscht. Derzeit würde ich aber behaupten, dass der Begriff in seiner heutigen Form zumindest innerhalb der IT noch sehr präsent und auch notwenig ist. Aber auch das kann sich ändern, UTF-8 scheint mir schon so eine Art "Sargnagel" der "klassischen" Textdatei zu sein, eine solche Datei überschreitet nach meinem Gefühl schon die Grenze zur Binärdatei, sobald sie mehr als die ersten 127 Zeichen des ASCII verwendet. Vielleicht ist bald auch ein Acrobat Reader "on the chip", dann wird's immer schwieriger mit dem Begriff Textdatei, dass heißt, der Artikel wird immer länger um den Begriff überhaupt noch definieren zu können und irgendwann werfen wir ihn weg.
• Codierung vs. Kodierung: Ich sehe das leidenschaftslos. Sollen wir auf "K" umsteigen?

--Cactus26 08:52, 7. Mär. 2008 (CET)

Cactus, weite Teile deiner Ausführungen sehe ich auch so. Meine Schlussfolgerung: wir müssen so weit wie möglich abstrahieren und so der Falle entgehen, dass die Begriffe sich ändern.-- Kölscher Pitter 10:42, 7. Mär. 2008 (CET)

Kritik

Habe ja verspochen Kritik zu üben:

• Textdatei .....prinzipiell in Textform stilistisch nicht schön (Text ist Text)

geändert.--Cactus26 14:18, 7. Mär. 2008 (CET)

• Stichwort Buchstabe oder Alphabet fehlt. Das ist das Element eines Textes.

Sind mMn zu einschränkend, finde dies durch Zeichen (alias Schriftzeichen) besser repräsentiert.--Cactus26 14:18, 7. Mär. 2008 (CET)

• Stichwort Pixel fehlt. Hierdurch entstehen die "Elemente des Textes"

Ist mir viel zu weit weg von Textdatei, hat wegen mir noch einen Bezug Schriftart, aber selbst da gibt es Vektorgrafiken, die den Bezug doch sehr indirekt machen.--Cactus26 14:18, 7. Mär. 2008 (CET)

Einspruch. Allein wegen der Historie. Beim Senden von Bytewert 65 haut die Schreibmaschine den Buchstaben "A" ans Papier. Schirm und Drucker setzen das aus Pixeln zusammen. Gerade das ist ein wesentliches Computerprinzip. Alles zerhacken in die kleinstmöglichen Elemente und dann wieder zusammenpuzzeln.-- Kölscher Pitter 16:58, 7. Mär. 2008 (CET)

• Gegenstück einer Textdatei..... Wieso "Gegen"?

Binär- und Textdatei sind Begriffe, die ohne einander nicht leben können. Beide Begriffe sind ohne das Gegenstück mehr oder weniger sinnlos. Wenn alle Dateien Binärdateien sind, wozu brauche ich dann noch den Begriff?--Cactus26 14:18, 7. Mär. 2008 (CET)

Alles wird binär gespeichert. Das Gegenstück (zu binär) wäre eine Speicherung mit mehrwertigen Einheiten. Vielleicht ist das in ferner Zukunft einmal technisch möglich. Binärdatei ist also ein Oberbegriff, kein Gegenstück (zu Text). Erst aus dem Zusammenhang wird klar: aha, das ist Text und aha, das ist Programm.-- Kölscher Pitter 17:12, 7. Mär. 2008 (CET)

Klar wird alles binär gespeichert, aber wozu der Begriff Binärdatei, wenn er ein Oberbegriff ist und alle Dateien somit Binärdateien sind? Dann wäre der Begriff Datei ausreichend, da dann Binärdatei=Datei. Mehrwertige Logik mit mehr als zwei Zuständen ist wohl irrelevant, zumindest in Verbindung mit Speicherformaten. --Cactus26 17:34, 7. Mär. 2008 (CET)

Nachtrag: Und die Darstellung im Artikel entspricht dem, wie die Begriffe verwendet werden und stellt obendrein den Widerspruch noch dar, dass alles eigentlich binär ist. Was willst Du mehr?--Cactus26 17:42, 7. Mär. 2008 (CET)

Ich hoffe jetzt sind wir zusammen. Das Vorwort "Binär" ist derzeit tatsächlich überflüssig. Auch das ist historisch zu sehen. Man dachte noch in "analogen" Kategorien. "Binär" hat nur was mit dem Speicherprinzip zu tun. Nichts aber mit Inhalt und Zweck.-- Kölscher Pitter 18:24, 7. Mär. 2008 (CET)

• Spezifika wie .pdf usw. nicht in die Einleitung

geändert.--Cactus26 14:18, 7. Mär. 2008 (CET)

Mir fällt bestimmt noch mehr ein. -- Kölscher Pitter 10:29, 7. Mär. 2008 (CET)

Ich habe mal eine kleine Änderung am Introtext selbst angebracht. Den Rest schaue ich mir am Wochenende an.

Ich kann nicht zustimmen, das Textdateien ein auslaufendes Modell sind. Es gibt mehr davon den je als Logdateien, Protokolldateien, Scriptdateien, Spielständenotations usw. usf.. Und dann denke man an den HTML-Quellcode - alles Textdateien ! 95% des Internets (statische HTML-Seiten, Internet-Server-Scripts (PHP,...) , ...... sind Textdateien !!! Es ist das am weitesten verbreitete Dateiformat. --Hgn-p 11:20, 7. Mär. 2008 (CET)

Fällt schwer, aber andere Artikel verwenden auch die Schreibweise Kodierung, s. Ascii, Unicode --Hgn-p 11:40, 7. Mär. 2008 (CET)

Wie würdest du eine Datei "kategorisieren" die folgendes enthält:

sehr viel Text, Bilder, Noten, Hörbeispiele, interaktive Schaltflächen, technische Zeichnungen, Link-Infos usw. Willst du definieren: Eine Textdatei ist eine Datei die nur Text beinhaltet. Wenn ja, dann musst du dich damit abfinden: solche Dateien sterben aus. Es ist eindeutig ein Trend erkennbar zur Integration (alles in einem, keine Spezialisierung). -- Kölscher Pitter 11:42, 7. Mär. 2008 (CET)

Dein Beispiel ist nach der Definition des Artikels eindeutig keine Textdatei. Dennoch sterben die Textdateien nicht aus, eher ist eine Zunahme zu verzeichnen (wie Hgn-p oben schreibt), allerdings nicht auf der Endbenutzer-Ebene und deshalb reden wir aneinander vorbei. Auf technischer Ebene sind die Textdateien eindeutig mehr geworden in den letzten Jahren. Dennoch könnte es sein, dass der Begriff ausstirbt, nicht etwas, weil es keine mehr gibt, sondern weil die Grenzen verschwimmen. Auch wenn in 20 Jahren alle Dateien XML-Dateien sind, ist der Begriff "Textdatei" irgendwie sinnlos.--Cactus26 14:24, 7. Mär. 2008 (CET)

Der Intro-Text ist m.E. jetzt in Ordnung mit einer kleinen Ausnahme: Der Nachsatz mit den flat files gehört raus. Auch sequentielle Dateien, die beispielsweise aus den Indextabellen usw. einer Datenbank extrahiert sind, bezeichnet man als flat files im Unterschied zur Anordnung der Daten in der Datenbank. Das sind jedoch Binärdateien. Ein Kalenderdatum wird beispielsweise nicht in der druck- und lesebaren Form, sondern in der Binärdarstellung gespeichert. Auch komplexe Objekte wie Bildschirmforms mit Actionsbuttons, Menüs, diversen Dialogfeldern usw. können als binäre "flat file" sequentialisiert werden. Der Begriff sollte hier gar nicht auftauchen.

Die Einfachheit der Bearbeitung von Strings ( = Zeilen einer Textdatei), dafür vorhandene Klassen in allen Programmiersprachen und neue Techniken wie sich selbst beschreibende Strukturen (XML Textfile) werden Textfiles zur wichtigsten Datenstruktur überhaupt machen. Intelligente Qualitätssicherungssysteme haben als Input Textfiles: Den Quellcode von C++, PHP und sonstiges Files. Ich finde es grundsätzlich gut, dass du das Wikipedia-Mauerblümchen "Textfile" adoptiert hast. Vom Image dieser "readme" - Dateien muss man sich gedanklich mal entfernen. Die wichtigen Internet-Server und deren untergeordnete Interpreter für Script-Sprachen sind allein im Prinzip komplexe Programme, die hauptsächlich Textfiles verarbeiten, erzeugen oder weiterleiten. --Hgn-p 15:57, 7. Mär. 2008 (CET)

Uff, wir kommen uns näher. Ich denke, wir brauchen auch nicht weiter über die Zukunft von Textdateien und dem Begriff "Textdatei" philosophieren, wir sind uns einig, dass er derzeit eine Bedeutung hat, die zumindest nicht vernachlässigbar ist, und in dieser sind wir uns ja auch weitgehend einig. Zum Hinweis "Flat File": Wahrscheinlich hast Du da Recht, mir ist der Begriff Flat-File in letzter Zeit nicht in Verbindung mit binärem Inhalt begegnet, ich habe en:Flat file kurz überflogen, was Deine Aussage aber bestätigt.--Cactus26 16:33, 7. Mär. 2008 (CET)

Anmerkungen Kandidatur 2009/12

Benutzer:Succu

Aus der Kandidatur-Disk. übertragen:

• Ein knackige Definition fehlt: Plain text in RFC 4288 wäre vielleicht ein guter Ansatz und vermeidet Aussagen wie „Das Gegenstück zur Textdatei stellt eine Binärdatei dar“.
• „Eine Textdatei ist im Gegensatz zu einer Binärdatei ohne die Verwendung spezieller Software lesbar“ - das trifft lediglich für Plain text zu, aber nicht für Datenaustauschformate wie beispielsweise SYLK, da diese (wie auch XML) auch Semantik beinhalten.
• „am gebräuchlichsten sind hierbei ASCII oder Unicode“. - Was ist mit EBCDIC oder ANSI?
• „Umgangssprachlich werden gelegentlich alle Dateien als „Textdatei“ bezeichnet...“ - diese Abgrenzung (im Gegensatz zu Binärdateien) finde ich wesentlich wichtiger.
• Der Geschichtsabschnitt ist mager. Sätze wie „In der Anfangszeit der elektronischen Datenverarbeitung war die Unterscheidung zwischen Text- und Binärdateien einfacher und von größerer Bedeutung als heute“ bedürfen eines Nachweises oder solche wie „Früher wurde dabei praktisch ausschließlich ein Zeichen immer direkt in ein Byte umgesetzt...“ sind ohne weiters nicht verständlich.

Was mir sonst noch so aufällt schreib ich auf die Disk des Artikels. Aber wahrscheinlich erst im nächsten Jahr. - Nix für ungut --Succu 21:52, 29. Dez. 2009 (CET)

---

Danke schon mal für Deine Anmerkungen. Im einzelnen:

• Eine knackige Definition: Die gibt es halt nicht, das wäre einfach. Man kann sich hier nur darin versuchen zu beschreiben, was ist meist in etwa gemeint, wenn jemand von "Textdatei" spricht ("Schick mir das mal als Textdatei!"). Ich habe in der Zwischenzeit einige Definitionsversuche gesehen (in der Literatur, im Web, teilweise hier als Quelle verwendet). Es gibt da auch Widersprüche, aber es gibt doch eine deutliche Tendenz, die auch meiner persönlichen Erfahrung mit diesem Begriff entspricht. Schwammig bliebt es jeden Fall.
• „Eine Textdatei ist im Gegensatz zu einer Binärdatei ohne die Verwendung spezieller Software lesbar“. Hier ist die Frage, was "lesbar" heißt. SYLK und XML ist schon lesbar, auch wenn man nicht ersteht, wozu es eigentlich gut sein soll (aber das ist ja häufig so...).
• EBCDIC und ANSI kommen unten
• „Umgangssprachlich werden gelegentlich alle Dateien als „Textdatei“ bezeichnet...“ : Verstehe ich Dich richtig, Du hältst die Definition "alles ist Textdatei, was in irgend einer Form dem Endbenutzer eine lesbaren Text präsentiert" für bedeutender?
• Geschichte der Textdatei, mager. Na ja. In der Literatur beschäftigt sich kaum jemand mit so etwas profanem wie einer "Textdatei". In vielen Büchern wird der Begriff verwendet und nicht mal ansatzweise definiert. Mir ist auch noch nichts begegnet, das sich mit der Geschichte der Textdatei beschäftigt, außer vielleicht das, aber das ist in der Tat sehr eigenwillig und scheint nur eine sentimentale Aufarbeitung der früheren textbasierten BBS (wie auch http://www.textfiles.com/)
• Nachweis für "früher war die Unterscheidung zwischen Text- und Binärdateien .... von größerer Bedeutung als heute, Nachweis. Schwierig, habe ehrlich gesagt schon vergeblich danach gesucht. Zweifelst Du an der Aussage an sich?
• „Früher wurde dabei praktisch ausschließlich ein Zeichen immer direkt in ein Byte umgesetzt...“ Habe ich umformuliert, besser?

Freue mich auf Dein weiteres Feedback, vlt. kannst Du mich ja bei der Suche guter Quellen für den Geschichtsteil auch ein wenig unterstützen. Ich habe nur noch auf dem Speicher meine Uraltliteratur, verspreche mir aber von deren Sichtung nicht viel außer Staub. --Cactus26 11:11, 30. Dez. 2009 (CET)

Die Einleitung liest sich schon deutlich besser. Da du unter Geschichte schreibts „...warum sich in Textdateien Steuerzeichen wie „Zeilenvorschub“ oder „Wagenrücklauf“ finden können“ wäre es m.E. besser wenn der Begriff „Steuerzeichen“ dort auftauchen würde. Etwa so: Etwa so die durch Steuerzeichen, wie bespielsweise Zeilen- und Seitenwechsel, untergliedert sein kann. Da wären dann die gebräuchlichen TABs noch mit abgedeckt. Den Einschub „wie beispielsweise mit Notepad unter Microsoft Windows“ würde ich heraussnehmen, sonst ist die UNIX/LINUX-Fraktion möglicherweise verschnupft (Emacs).

Im Abschnitt Geschichte solltest du noch das Jahr der Einführung von Unicode erwähnen und den Zeitpunkt zu dem UTF Bestandteil der RFCs des Webkonsortiums wurde. Mal schaun ob ich noch etwas wichtes zu Geschichte finde. Vielleicht lohnt hier die Erwähnung von vi und EDLIN.

Ich würde die Bezeichnung "Textdatei" für ein Dateiformat stärker gewichtet im Artikel sehen wollen. Beispielsweise ist das Rich Text Format eine Textdatei in deinem Sinn, aber ohne einen Dateibetrachter nutzlos für den Benutzer.

Ich veruche mal im Laufe des Tages die restlichen Abschnitte genauer zu lesen.

Dir noch ein verspätetes "Gesundes Neues" --Succu 08:26, 2. Jan. 2010 (CET)

Wünsche Dir auch ein Gutes Jahr 2010! Zu Deinen Punkten:

• Erwähnung "Steuerzeichen" in der Einleitung: Habe ich umgesetzt. Du hast Recht, sonst bleibt das vlt. zu nebulös. Das "beispielsweise" habe ich weggelassen, da das "wie" mMn allein schon ausreichend sein müsste
• Erwähnung "notepad", Gefahr der Unix-Fraktions-Verschnupfung: Würde ich gerne drinlassen. Mein Argument (neben der Verbreitung von Windows): Wer Unix/Linux benutzt, weiß was ein Texteditor ist und braucht das Bsp. nicht, bei Windows gilt das nicht
• Datum der Einführung von Unicode. Weiß nicht. Hier ist das mMn nicht so entscheidend . Wichtiger wäre, wann Unicode Einzug bei der Codierung für Textdateien gehalten hat. Das ist vermutlich einiges später und war schleichend. Für Windows wäre das wohl seit Windows 2000, da hat Notepad erstmals Unicode unterstützt.
• "RTF ist eine Textdatei in meinem Sinne": Ist sie, aber das "meine" ist unangebracht, ich habe das nicht definiert (da überschätzt Du mich). Ich bin ein wenig zufällig zum Thema Textdatei gekommen, das war vor etwa einem Jahr, als der Artikel einen Redundanzbst. trug und ich ihn auf der ToDo-Liste hatte. Da YMS die Redundanz bereits erledigt hatte, als ich mich der Sache widmen wollte, habe ich den Artikel halt ausgebaut, um auch was beizutragen. Seitdem bin ich aber sensibilisiert und nehme die Verwendungen des Begriffs in Literatur und Web sehr bewusst zur Kenntnis. Ich möchte schätzen, dass 95% der Verwendungen des Begriffs der im Artikel dargelegten Definition entsprechen. Hier in der WP werde ich dagegen erstaunlich oft mit der Meinung konfrontiert, eine Textdatei sei alles, was dem Benutzer in irgend einer Form einen Text präsentiert, wie immer es gespeichert ist. Bei einer solchen Definition wäre der Begriff in der Tat genauso sinnvoll wie der Begriff "Liebesbriefdatei". Diese Definition findet sich meist in Büchern oder Webseiten der Art "Computer für Dummies", die es einfach machen wollen, indem sie es falsch machen.

Erstaunlich finde ich, welche kontroversen und teilweise emotionalen Diskussionen es hier beim Thema "Textdatei" gibt. Das soll aber nicht heißen, ich hätte keine Lust auf eine konstruktive Diskussion. Worauf ich allerdings keine Lust mehr habe, ist eine Diskussion bei der es nur um die Zurschaustellung des eigenen Wissens geht. Der Trieb dazu ist bei Informatikern weit verbreitet, das weiß ich, aber im RL reicht mir das eigentlich. Ich weiß aber, dass wir uns gut genug kennen, dass diese Gefahr bei Dir nicht besteht. Umso gespannter bin ich auf Dein Feedback.--Cactus26 13:45, 2. Jan. 2010 (CET)

Zum Glück bin ich kein Informatiker ;), aber technologielastige- und wenig lösungsbezogene Diskussionen kenne ich zu genüge aus meiner Arbeitsalltag. Also erstmal Asche auf mein Haupt, das ich den Artikel nicht eher komplett zu Ende gelesen habe.

Ich denke inhaltlich ist alles drin was für lesenswert rein muß.

Die Abgrenzung zu Textverarbeitungsdateien die zusätzlich die Textformatierung speichern (Textverarbeitungsformate wie RTF, PDF, PS, etc.) und Datenaustauschformaten (CSV u.a.) hast du dargestellt. Das mir die Abgrenzung wichtig erschien hat wohl eher mit meiner eigenen intensiveren Beschäftigung mit etlichen dieser Formate zu tun.

Das Stichwort „Fernschreiber“ wäre vielleicht im Geschichtsabschnitt noch sinnvoll. Nochmal zu Unicode: Eher was für die Exzellenz-Auszeichnung. Es brauchte ja erstmal Unicode-basierte Betriebssysteme (wie beispielsweise WinNT) bevor sich Textdateien auf dieser Grundlage etablieren konnten.

Im Abschnitt „Kennzeichnung mittels Steuerzeichen“ solltest du evtl. den Fallstrick gegen das weniger prosaische Wörtchen Problem o.ä, austauschen. Ich persönlich würde die beiden Abschnitte „Kennzeichnung des Zeilenendes“ und „Andere Steuerzeichen“ und einer gemeinsamen Überschrift, z.B. „Steuerzeichen“, zusammenfassen.

„Austausch zwischen unterschiedlichen Systemen“: da fallen mir noch die Stichworte Webbrowser (wg. Codierung) und Firewall im Zusammenhang mit der heutigen Bedeutung (XML) von Textdateien ein. Vielleicht läßt sich da noch etwas ergänzen.

Ich hoffe die paar Kleinigkeiten helfen noch ein wenig. Ich werde ganz sicher in der Zukunft genauer hinschauen, wenn in der Literatur von einer Textdatei die Rede ist. --Gruß Succu 18:03, 2. Jan. 2010 (CET)

Wenn Du über etwas interessantes in diesem Zusammenhang stößt, lass es mich wissen. Es ist in der Tat ungemein schwierig, bei diesem Thema gezielt zu suchen, weil es fast immer beiläufig abgehandelt wird, wenn überhaupt. Zu Deinen Punkten:

• "Fernschreiber" habe ich im Geschichtsabschn. ergänzt und noch etwas weiter ausgeführt. Der Ursprung für CR/LF ist ja der Baudot-Code, diese Zeichen wurden dann in ASCII (und EBCDIC) übernommen.
• Über die genaue Historie, wann Unicode welche Bedeutung hatte (insbesondere in Bezug auf Textdateien), kann ich im Moment nichts Detailliertes sagen. Werde da nochmal forschen..
• "Fallstrick" ist wirklich für das CR/LF-Problem etwas übertrieben. Als ich das schrieb, dachte ich an die Implementierung der Funktion setpos der C-Runtime-Bibl. eines Windows-Compilers, die ich mal im Sourcecode bewundert habe. Welche Kurven die für den Textmodus fliegen muss, um den scheinbar korrekten Dateioffset zu ermitteln, ist beeindruckend. Aber dass das so kompliziert ist, liegt daran, dass man sich bei Implementierung der DOS- und Windows-Compilern entschieden hat, so zu tun, als hätte die Datei wie unter UNIX nur ein LF (damit es kompatibel ist). Aber beim normalen Austausch von Dateien spielt es heute fast keine Rolle mehr, die meisten Editoren kommen heute mit unpassenden CR/LF-Konstellationen ganz gut zurecht.
• Webbrowser/Firewall: Der Zusammenhang zwischen Webbrowser und Dateien ist vielleicht doch etwas indirekt. Aber Firewalls sind möglicherweise durchaus ein zu erwähnender Aspekt, da diese wohl auch ein Grund sind, warum Textformate bei Dateien populär wurden. Ich suche mal, ob ich dazu eine Quelle findet, diese Vermutung bestätigt.

--Cactus26 15:45, 3. Jan. 2010 (CET)

Benutzer:Mnh

Aus der Kandidatur-Disk. übertragen:

Momentan noch ohne Wertung (nur ausschnittsweise gelesen), nur ein paar Punkte:

• „Unter Windows wird dem Namen einer Textdatei in der Regel die Endung .txt angehängt.“ – Nö. Das trifft nur dann zu, wenn man Scripte, Quelltexte (HTML z.B.) und Co ignoriert, das sind jedoch auch „Textdateien“.
• „Unter Unix, Linux und verwandten Systemen wird das Zeilenende alleine mittels LF gekennzeichnet.“ – Nö. Es werden ebenfalls CR+LF verwendet, das ist für diverse Protokolle nämlich nötig. Stichwort: rfc822. Spätestens mit „Auch eine im [PDF-Format] vorliegender Text ist keine Textdatei, weil diese binär codierte Formatinformationen enthält.“ wird das aber absurd (und hat'n Typo), eine gespeichterte Mail bleibt Text, auch wenn da uuencode/Base64-kodiertes Binärzeug drin ist. „Für den in einer Textdatei enthaltenen Text können keine besonderen Formatierungen wie beispielsweise Hervorhebungen durch Fettdarstellung festgelegt werden.“ stimmt übrigens auch nicht, einerseits gibt es Syntax-Highlighting, das ganz genau das macht, zum anderen gibt/gab es ANSI control codes (sowas wie ^[[1;32;40m wenn ich die Syntax noch richtig im Kopf hab), mit denen die Darstellung auf Textterminals aufgehübscht wurde.
• „Der Medientyp text kennzeichnet dabei Textdateien.“ – Diese Aussage halte ich einfach für Mist. text/* kennzeichnet *Datenentitäten*, nicht Dateien. Letztere sind vom Filesystem bereitgestellte Datencontainer, deren Metadaten und Eigenschaften interessiert MIME nicht. Wesentlich ist einzig das Format der Daten darin. Böse mnhs behaupten gar, dass der Begriff „Textdatei“ deshalb im Grunde ziemlich fragwürdig ist, über „umgangssprachliche Bezeichnung für eine Datei mit Textdaten“ käme ich beim Schreiben nicht hinaus.
• Fragen am Rande: Ist eine named pipe, hinter der ein Text schreibender daemon sitzt, eine Textdatei? Was ist mit /dev/mnhprint, der örtlichen Druckerdatei, die bei Leseversuchen „Hugo ist doof!<CR><LF>“ ausgibt, schreibend aber normal funktioniert? Textdatei?

Viele Grüße, —mnh•∇• 04:39, 30. Dez. 2009 (CET)

---

Danke für Dein Feedback. Im einzelnen:

• Unter Windows nicht immer Endung ".txt": Stimmt, ich wollte hier keine (endlose) Auflistung aller möglichen Dateierweiterungen (insbes. wenn man die in Auszeichnungsprachen einbezieht) und nur eine (die repräsentativste) herausgreifen. Habe "in der Regel" durch "häufig" ersetzt.
• Unter UNIX ebenfalls CRLF. Das wäre mir neu. Vorsicht: rfc822 bezieht sich auf Messages, nicht auf Dateien.
• Eine in Base64 gespeicherte Mail bleibt Text. Hier hast Du im doppelten Sinne Recht. In der Einleitung steht, dass der Begriff verschwommen ist, weil er auf unterschiedlichen Abstraktionsebenen verwendet werden kann. Das ist hier der Fall. Meine ich den eigentlichen Mail-Inhalt oder meine ich das physische Speicherformat der Mail?. In diesem Fall ist es egal, weil beides Text ist, auch das Base64-Format besteht ja nur aus Zeichen.
• ANSI control codes. Auch hier hast Du Recht, ich kann nur wiederholen, die Abgrenzung ist schwierig. Im Abschnitt "Andere Steuerzeichen" wird diese Problematik behandelt. Dieser Sachverhalt wird wie viele Aussagen des Artikels am Anfang etwas schwammig behandelt. Sie werden erst später konkretisiert. Dies scheint mir aber nötig, um Laien nicht gleich mit der vollen Breite aller Variationsmöglichkeiten zu überfordern.
• „Der Medientyp text kennzeichnet dabei Textdateien.“ – Aussage ist Mist.
  Stimmt wohl. Habe Textdateien mal durch "Text" ersetzt. Mir ist durchaus klar, dass der Medientyp ein Konzept ist, dass nicht nur für Dateien angewandt wird. Wenn eine Datei als Anhang einer Mail verschickt wird, bezieht er sich aber auf die Datei. Der Medientyp beschreibt, wenn er in dieser Weise verwendet wird, recht präzise, was eine Textdatei ist. Da es an präzisen Definition mangelt, hielt ich es für nützlich, hier so ausführlich auf den Medientyp einzugehen.
• "Der Begriff Textdatei ist fragwürdig": Ist er, ohne Frage. Aber es gibt ihn. Und ich wollte mich der Herausforderung stellen, hier einen Versuch zu unternehmen, dieses schwammige Ding zu beschreiben. Eine knackige Definition gibt es halt nicht, das wäre einfach. Man kann sich hier nur darin versuchen zu beschreiben, was ist meist in etwa gemeint, wenn jemand von "Textdatei" spricht ("Schick mir das mal als Textdatei!"). Ich habe in der Zwischenzeit einige Definitionsversuche gesehen (in der Literatur, im Web, teilweise hier als Quelle verwendet). Es gibt da Widersprüche (es gibt durchaus auch die Aussage, Dateien mit der Endung ".doc" seien Textdateien), aber es gibt doch eine deutliche Tendenz, die auch meiner persönlichen Erfahrung mit diesem Begriff entspricht. Der Artikel ist in Details immer angreifbar und die Diskussionen darüber führen zu wenig bis nichts, wenn sie in Rechthaberei ausarten.

Nachtrag: Bin gerade über eine neue Quelle gestolpert, die mich inspiriert hat, diesen Sachverhalt besser auf den Punkt zu bringen (letzter Absatz im Abschnitt Geschichte). Nach weiterer Literaturrecherche kann ich nur sagen, der Begriff wird massiv verwendet, es fehlt häufig an einer vernüftigen Definition, Dein obiges „umgangssprachliche Bezeichnung für eine Datei mit Textdaten“ triff die übliche Verwendung des Begriffs kaum.--Cactus26 15:21, 31. Dez. 2009 (CET)

• Fragen am Rande: Mit diesen dehnst Du die Abgrenzungsproblematik auch noch darauf aus, was eigentlich eine Datei ist. Da möchte ich Dich zum Autor des Artikels "Datei" verweisen, dieser Frage möchte ich mich nicht auch noch stellen.

--Cactus26 10:09, 30. Dez. 2009 (CET)

Ein Byte = 8 Bit?

Früher, heißt es, wurden Zeichen immer in jeweils einem Byte abgebildet, und dass seien 8 Bit. Früher, so wie ich das weiß, war ein Byte definiert als die Anzahl der Bits, die ein Zeichen halten können, und es gab Maschinen mit 6-Bit-Bytes und auch solche mit 9-Bit-Bytes. --Joachim Pense (d) 14:54, 30. Dez. 2009 (CET)

Das ist mir tats. neu. Zwei mir verfügbare recht alte Lexika (1988 und 1989) behaupten zweifelsfrei 1 Byte = 8 Bit (ggf. ein zus, Prüfbit, das tut aber hier nichts zur Sache). Mal unabhängig davon, ob das nun für einen Artikel Textdatei überhaupt relevant ist: Hast Du eine Quelle dafür?--Cactus26 17:51, 30. Dez. 2009 (CET)

Erstmal den Artikel Byte. Da werden UNIVAC-Maschinen mit 9-Bit-Bytes erwähnt. Die englische WP schreibt Various implementations of C and C++ define a byte as 8, 9, 16, 32, or 36 bits und gibt auch Referenzen. hier kommen Bytes mit 6 und 7 Bit vor (die dann als 6-Bit-Byte etc. bezeichnet werden). Hier steht auch was. --Joachim Pense (d) 18:00, 30. Dez. 2009 (CET)

Deine Aussage stimmt wohl, wobei ich nicht alle Quellen hier ernst nehmen möchte. Aber die im engl. Artikel en:Byte angegebene Quelle (Buchholz 1962 (großes PDF)) ist eindeutig. Ich war nicht sicher, ob man die kleinste Adressierungseinheit damals schon Byte genannt hat, aber man hat es offensichtlich. Ich behaupte mal, dass das hier kaum relevant ist. Insbesondere die Aussage, dass verschiedene C und C++ Implementierungen unterschiedliche Byte-Längen verwenden, ist sonderbar, ich programmiere diese Sprachen nicht erst seit gestern und mir ist noch keine solche über den Weg gelaufen (auch nicht bei 64-Bit Compilern!), ANSI-C definiert obendrein das Byte als 8-Bit. Ich würde mal sagen, dass es in den Zeiten, in denen mit der Byte-Größe noch wirklich experimentiert wurde, noch kaum Dateien gab (eher Lochkartenstapel), geschweige denn den Begriff Textdatei. Das "früher" im Artikel bezieht sich also bereits auf Zeiten, in denen das 8-bitige Byte bereits Gesetz war. Ich habe die Aussage 1 Byte=8Bit nun relativiert. Weiter müssen wir dieses Fass hier nicht aufmachen, finde ich. Aber danke für diesen Hinweis, man lernt nie aus.--Cactus26 18:32, 30. Dez. 2009 (CET)

Die Texte bestanden halt aus Großbuchstaben, da haben 6 Bit ausgereicht. Viel Erfolg noch! --Joachim Pense (d) 18:42, 30. Dez. 2009 (CET)

Die Wiege war natürlich der Fernschreiber. Die Sekretärin fertigte einen Probeausdruck zusammen mit einem Lochstreifen an. Der Boss las Korrektur und mit sieben Bits ging es auf die Reise. Ein Byte (ein Zeichen) waren 7 Bits. Nicht lange. Die Fernschreiber auf den Schrott und die ersten Computer hatten einen "erweiterten" Zeichenvorrat mit 8 Bits.-- Kölscher Pitter 13:04, 7. Jan. 2010 (CET)

So hat es sich wohl abgespielt. Als die Computer in die "Domäne der Fernschreiber" vordrangen, war 1Byte=8bit schon etabliert. Dies war wohl eher durch technische Aspekte der ALU motiviert als durch Texte, da Rechner früher ja wirklich zum Rechnen verwendet wurden..--Cactus26 15:41, 7. Jan. 2010 (CET)

Richtig. Es musste eine Zweier-Potenz sein. Also 2 hoch 3.-- Kölscher Pitter 17:32, 8. Jan. 2010 (CET)

Zeichenkodierung

Ich habe ja leider keine Ahnung vom Thema, aber dennoch den Eindruck, dass der Abschnitt "Zeichenkodierung" etwas euro- bzw. lateinschriftzentrisch ist. Weltweit sind doch noch mehr Kodierungen als die genannten verbreitet, siehe z. B. Kategorie:Zeichenkodierung für die chinesische Schrift und Kategorie:Zeichenkodierung für die japanische Schrift-- Katakana-Peter 16:30, 6. Jan. 2010 (CET)

Da hast Du wohl recht. Eine gewisse lateinzentrierung finde ich allerdings auch angebracht. Im Abschnitt "Zeichenkodierung" selbst würde ich die älteren nicht-lateinischen Codierungen weiterhin eher nicht erwähnen, aber man könnte deutlicher darauf hinweisen, dass Unicode dies heute abdeckt (ich denke, dass sich bei nicht-lateinischen Systemen Unicode besonders schnell durchsetzen konnte). Im Abschnitt "Geschichte" könnte man vlt. aber hierzu auch etwas ergänzen, ich muss da aber erst ein wenig recherchieren. Danke für Dein Feedback.--Cactus26 11:47, 7. Jan. 2010 (CET)

Nachtrag: Habe jetzt mal das ergänzt. Was hälst Du davon? Mal schauen, ob ich noch an anderer Stelle darauf eingehe.--Cactus26 14:41, 7. Jan. 2010 (CET)

Kandidatur-Diskussion vom 29.12.2009 - 8.1.2010 (Lesenswert)

Ein in der IT nicht selten verwendeter Begriff, der jedoch sehr selten klar definiert wird, zudem wird der Begriff nicht zuletzt durch viele auf dem Textformat basierende Auszeichnungssprachen (z.B. XML) und die zunehmende Verbreitung von Unicode immer verschwommener. Dennoch scheint er (noch) eine gewissen Bedeutung zu besitzen, wie sie Zugriffszahlen zeigen (ein ausgeprägter "Werktagsartikel"). Der Artikel hat schon mal kandidiert, damals haben wir uns vielleicht in der Diskussion etwas verzettelt, woran ich sicher auch nicht unschuldig war. Ich habe den Artikel jetzt noch mal durchgesehen, etwas gestrafft und finde, dass er die mit diesem Thema zusammenhängenden Aspekte ganz gut darstellt. Es interessiert mich sehr, ob jemand etwas damit anfangen kann.--Cactus26 15:49, 29. Dez. 2009 (CET)

• Für exzellent reicht es nicht, aber  Lesenswert ist er. --Morten Haan 17:56, 29. Dez. 2009 (CET)

• Die 7/8-Bit-Problematik fehlt nicht nur, sondern wird mit der Behauptung, früher wären es "praktisch ausschließlich immer" 8 Bit gewesen, direkt abgestritten. Tatsächlich sind viele Textdateien bis heute praktisch auf 7 Bit beschränkt. --84.151.14.225 19:21, 29. Dez. 2009 (CET)

Ja, ja, hatte ich rausgeworfen (gilt halt nur für ASCII, für EBCDIC galt das nie), nehme es reumütig wieder auf, zufrieden?--Cactus26

•  Lesenswert liest sich ganz nett und flüssig. Könnte aber ein paar Füllwörter weniger haben. Mir gefällt er, ohne Experte für Dateiformate zu sein, aber etwas Vorkenntnis zu haben. … blunt. 20:50, 29. Dez. 2009 (CET)
•  Lesenswert. Was mir gefällt: Der Artikel kommt ganz gut auch ohne Fachchinesisch aus. Selbst ich, als nicht ITler habe verstanden, um was es geht. Daher voll und ganz Lesenswert (als Laie). -- Grüße aus Memmingen 20:57, 29. Dez. 2009 (CET)

•  Abwartend Ich hab nur quer gelesen, aber einige Punkte sind mir aufgefallen (hauptsächlich aus der Einleitung):

• Ein knackige Definition fehlt: Plain text in RFC 4288 wäre vielleicht ein guter Ansatz und vermeidet Aussagen wie „Das Gegenstück zur Textdatei stellt eine Binärdatei dar“.
• „Eine Textdatei ist im Gegensatz zu einer Binärdatei ohne die Verwendung spezieller Software lesbar“ - das trifft lediglich für Plain text zu, aber nicht für Datenaustauschformate wie beispielsweise SYLK, da diese (wie auch XML) auch Semantik beinhalten.
• „am gebräuchlichsten sind hierbei ASCII oder Unicode“. - Was ist mit EBCDIC oder ANSI?
• „Umgangssprachlich werden gelegentlich alle Dateien als „Textdatei“ bezeichnet...“ - diese Abgrenzung (im Gegensatz zu Binärdateien) finde ich wesentlich wichtiger.
• Der Geschichtsabschnitt ist mager. Sätze wie „In der Anfangszeit der elektronischen Datenverarbeitung war die Unterscheidung zwischen Text- und Binärdateien einfacher und von größerer Bedeutung als heute“ bedürfen eines Nachweises oder solche wie „Früher wurde dabei praktisch ausschließlich ein Zeichen immer direkt in ein Byte umgesetzt...“ sind ohne weiters nicht verständlich.

Was mir sonst noch so aufällt schreib ich auf die Disk des Artikels. Aber wahrscheinlich erst im nächsten Jahr. - Nix für ungut --Succu 21:52, 29. Dez. 2009 (CET)

Habe Dir schon mal hier geantwortet.--Cactus26 11:14, 30. Dez. 2009 (CET)

Für  Lesenswert reicht es mir jetzt nach den vielen kleinen Änderungen, da inhaltlich alle wesentlichen Punkte behandelt werden. --Succu 18:10, 2. Jan. 2010 (CET)

Momentan noch ohne Wertung (nur ausschnittsweise gelesen), nur ein paar Punkte:

• „Unter Windows wird dem Namen einer Textdatei in der Regel die Endung .txt angehängt.“ – Nö. Das trifft nur dann zu, wenn man Scripte, Quelltexte (HTML z.B.) und Co ignoriert, das sind jedoch auch „Textdateien“.
• „Unter Unix, Linux und verwandten Systemen wird das Zeilenende alleine mittels LF gekennzeichnet.“ – Nö. Es werden ebenfalls CR+LF verwendet, das ist für diverse Protokolle nämlich nötig. Stichwort: rfc822. Spätestens mit „Auch eine im [PDF-Format] vorliegender Text ist keine Textdatei, weil diese binär codierte Formatinformationen enthält.“ wird das aber absurd (und hat'n Typo), eine gespeichterte Mail bleibt Text, auch wenn da uuencode/Base64-kodiertes Binärzeug drin ist. „Für den in einer Textdatei enthaltenen Text können keine besonderen Formatierungen wie beispielsweise Hervorhebungen durch Fettdarstellung festgelegt werden.“ stimmt übrigens auch nicht, einerseits gibt es Syntax-Highlighting, das ganz genau das macht, zum anderen gibt/gab es ANSI control codes (sowas wie ^[[1;32;40m wenn ich die Syntax noch richtig im Kopf hab), mit denen die Darstellung auf Textterminals aufgehübscht wurde.
• „Der Medientyp text kennzeichnet dabei Textdateien.“ – Diese Aussage halte ich einfach für Mist. text/* kennzeichnet *Datenentitäten*, nicht Dateien. Letztere sind vom Filesystem bereitgestellte Datencontainer, deren Metadaten und Eigenschaften interessiert MIME nicht. Wesentlich ist einzig das Format der Daten darin. Böse mnhs behaupten gar, dass der Begriff „Textdatei“ deshalb im Grunde ziemlich fragwürdig ist, über „umgangssprachliche Bezeichnung für eine Datei mit Textdaten“ käme ich beim Schreiben nicht hinaus.
• Fragen am Rande: Ist eine named pipe, hinter der ein Text schreibender daemon sitzt, eine Textdatei? Was ist mit /dev/mnhprint, der örtlichen Druckerdatei, die bei Leseversuchen „Hugo ist doof!<CR><LF>“ ausgibt, schreibend aber normal funktioniert? Textdatei?

Viele Grüße, —mnh·∇· 04:39, 30. Dez. 2009 (CET)

Danke für Dein Feedback. Habe hier versucht, Deine Fragen zu beantworten.--Cactus26 10:14, 30. Dez. 2009 (CET)

• Kommentar: Dateien enthalten nie Schriftzeichen, insofern ist die Einleitung eine en:Lie-to-children --Pjacobi 14:33, 31. Dez. 2009 (CET)
•  Lesenswert, ein paar Hinweise noch:

• feste Zeilenlänge: Ergänzung, daß die Länge bekannt sein muß (übliche Werte?)
• "... Inhalt wird nach einer für die jeweilige Datei fest vorgegebenen Regel in Text umgewandelt": Hier sollte erwähnt werden, daß der Leser der Datei diese Regel kennen muß, der Datei sieht man das ja nicht an.
• Zeichencodierung: hier könnte die Anzahl der codierten Zeichen angegeben werden.
• Zeichencodierung/Unicode: Den Hinweis zu UTF-8/16 in der Liste würde ich in den Absatz über Unicode verschieben (vielleicht auch den Absatz über falsche Codierung mit dem Unicode-Absatz tauschen). Außerdem könnte erläutert werden, daß die ersten 128 Zeichen bei UTF-8 wie in ASCII in einem Byte gespeichert werden und für weitere Zeichen zusätzliche Bytes verwendet werden.
• Verwendung von Textdateien: Es könnte noch etwas mehr zum Datenaustausch (Ex-/Import) sowie zum Quellcode von Programmen geschrieben werden.
• das "genaugenommen" hab ich ersetzt, da es ja keine "genaue" Definition gibt
• ist PDF ein Nachfolger von PostScript? -- 80.146.127.214 15:14, 6. Jan. 2010 (CET)

Danke für Deine Verbesserungen und Deine Anregungen. Zu Deinen Punkten:

• Feste Zeilenlänge, Zeilenlänge muss bekannt sein: Habe ich umgesetzt
• "Leser muss die Regel kennen": "Der Leser (=Benutzer)" ist etwas unpräzise, meist ist es ja das System, dass die Codierung erkennt. Zudem werden dabei diverse Heuristiken verwendet, mit denen Editoren z.B. die Codierung "erraten", zum anderen gibt es seit Unicode die Byte Order Mark. Das an dieser Stelle zu erläutern, scheint mir aber zu ausufernd, der Hinweis weiter unten ("Wird eine Textdatei unter Verwendung einer falschen Zeichencodierung interpretiert") scheint mir ausreichend und ohne sich zu verzetteln auf diese Problematik hinzuweisen.
• Angabe der Anzahl der codierten Zeichen angeben: Das würde ich hier lieber den verlinkten Artikeln überlassen, sonst muss man sich hier möglicherweise noch der Problematik Steuerzeichen/druckbare Zeichen u.ä. stellen.
• Zeichencodierung/Unicode: Die Anregungen habe ich versucht umzusetzen, bitte prüfe es nochmal.
• Mehr zum Import/Export, Quellcode: Spontan habe ich dazu keine tolle Idee, ich denke nochmal drüber nach.
• "PDF Nachfolger von Postscript". Kann man so vlt. nicht sagen, obwohl PDF Postscript wohl verdrängen wird. Bin da kein Spezialist, meine (unfundierte) Meinung ist, dass Postscript "Drucker-fokussiert" ist, PDF hingegen einen eher interaktiveren Fokus hat, die Anwendungsgebiets-Überschneidung ist allerdings beträchtlich.

Viele Grüße --Cactus26 15:30, 7. Jan. 2010 (CET)

•  Lesenswert obwohl ich den Artikel nicht gerade für sehr spannend halte, aber das liegt wahrscheinlich am Thema Bei Bearbeiten und ansehen würde ich aufgrund des umfangreichen Themas schon einen Hinweis auf einen Hauptartikel setzen. Hauptartikel: Texteditor. Textdateien kann man auch verwenden, um reinen Text abzuspeichern. Beim Editieren ist man oft viel schneller und später kann man zb in Openoffice den Text schöner formatieren. Oder auch zum Vorbereiten von emails ist oft ein Texteditor gut geeignet. Aber nicht so wichtig und braucht im Artikel vielleicht gar nciht extra erwähnt werden. Sonst finde ich den Artikel solide. Vielleicht ein bisschen zuviel bezug zu Microsoft, aber das ist ja nach wie vor auch das verbreitetste Betriebssystem und wird wahrscheinlich auch so bleiben. --FrancescoA 15:29, 6. Jan. 2010 (CET)

Das mit dem "Hauptartikel" habe ich umgesetzt. Im übrigen teile ich viele Deiner Einschätzungen, aber für was sich Textdateien eignen, ist wohl zum großen Teil subjektiv.--Cactus26 15:30, 7. Jan. 2010 (CET)

Der Artikel in dieser Version ist Lesenswert. --Vux 01:39, 8. Jan. 2010 (CET)

Weitere Anmerkungen 80.146.x.x

Nachtrag zu meinen obigen Anmerkungen: Die Anzahl der codierten Zeichen wird im weiteren Artikel als bekannt vorrausgesetzt oder man kann indirekt darauf schließen ("da Unicode weit mehr als 256 verschiedene Zeichen definiert" -> die anderen Codierungen (vermutlich) maximal 256; "nicht Bestandteil der ersten 128 standardisierten Zeichen des ASCII" -> ASCII: 128, ISO 8859: 128+weitere). Ich fände es daher besser, wenn in der Liste wenigstens grob die Zeichenanzahl (128/7 Bit; 128+128/8 Bit; >>256) angegeben wird.

Zur Kenntnis der richtigen Codierung: auch das kann man - wie Du schreibst - indirekt aus dem Artikel lesen (s. Verwendung einer falschen Zeichencodierung und Austausch zwischen unterschiedlichen Systemen). Ich weiß jedoch nicht, ob es einem OMA-Leser bewußt ist, daß man die Codierung der Datei erstmal gar nicht ansehen kann. Und ist die Verwendung von Byte Order Marks schon Konvention oder nur eine Möglichkeit? Was hältst Du von einem Beispiel wie dem folgenden:

57 69 6B 69 70 65 64 69 61 0A   Dateiinhalt binär (HEX)
W  i  k  i  p  e  d  i  a  LF   ASCII und ISO 8859
ï  Ñ  ,  Ñ  ø  Á  À  Ñ  /  RPT  EBCDIC 500 und 273

Ich habe im Artikel noch etwas umgestellt, so daß in der Liste der Codierungen nur Unicode und im folgenden Absatz die Umsetzung Unicode<->Bytefolge behandelt wird. Der Einzelnachweis bezog sich doch auf die Verbreitung von UTF-8? 80.146.93.208 14:15, 8. Jan. 2010 (CET)

Zunächst: Deine Änderung im Artikel kann ich nachvollziehen, dass mit der Quelle war so gedacht und ich sehe Deine Version als Verbesserung an.

• "Expliziter Hinweis bei den Codierungen, wie viel Zeichen möglich". Ich weiß nicht. Mir taucht die Zahl 256 ohnehin schon fast zu oft im Artikel auf, nicht an allen Stellen scheint es mir 100% korrekt, wenn man es pedantisch sieht. Die ersten 3 der Liste sind 7/8 Bit Codes. Das 8 Bit 256 Zeichen ermöglichen, wird mMn fast schon zu oft erwähnt (u.a. beim Unicode in diesem Abschnitt). Dass es bei 7-Bit die Hälfte ist, nun gut, das könnte man vlt. noch irgendwo unterbringen, wobei ich mich schwer tue einzuschätzen, ob das eine Information ist, die ein Laie tats. vermisst. Hättest Du eine Idee, wo man das sinnvoll ergänzen könnte?

• "Kenntnis der richtigen Codierung". Wenn man weiter ausführen wollte, dass man einer Textdatei nicht unbedingt ansieht, wie sie codiert ist, würde ich es direkt beim bisherigen Hinweis tun wollen ("wenn man eine unter Verwendung der falschen Zeichencodierung..."). Vorziehen würde ich einen solchen Hinweis nicht wollen, dazu ist es mMn zu selten ein Problem. Bei Deinem Beispiel glaube ich, dass es ohnehin nur die verstehen, die das Beispiel gar nicht brauchen ("hex" wird meiner Erfahrung nach bei vielen Laien stigmatisiert, wo das auftaucht, geben sie auf). Interessanter wäre vielleicht ein Vergleich von UTF-8 interpretiert als Windows-1252 (das kann vorkommen, wenn die BOM fehlt oder vom verarbeitenden Programm nicht beachtet wird). Das wäre dann aber nichts für Laien, zudem sehr MS-lastig. Wie verbreitet die BOM wirklich ist, weiß ich nicht genau. In Unix ist sie offentsichtlich verpönt, Microsoft setzt sie sehr konsequent ein.

--Cactus26 15:01, 9. Jan. 2010 (CET)

Artikel des Tages

Ich habe diesen Artikel für den 12.02.2011 als Artikel des Tages vorgeschlagen. Gruß, --Gamma127 13:12, 5. Feb. 2011 (CET)

also entschuldigung, ich bin unter der email adresse haust48387@aol.com per email zu erreichen. eine seitenlange diskussion macht den inhalt eines artikels nicht besser. ich kann nur soviel dazu sagen: eine textdatei ist eine binärdatei, die durch spezielle programme auf "sichtgeräten" in menschenlesbare form gebracht wird. sie ist nicht mehr und nicht weniger als eine binärdatei. was wiederum die frage aufwirft was überhaupt dateien, bzw. bitblöcke in elektronischen speichermedien sind. (nicht signierter Beitrag von 89.204.137.253 (Diskussion) 14:58, 12. Feb. 2011 (CET))

Deine Defintion ist ja nicht grundsätzlich falsch, im Artikel steht nichts, was Deiner Aussage widersprechen würde. Ich vermute nur, dass keiner, der nicht schon vorher wusste, was eine Textdatei ist, mit Deiner Definition etwas anfangen kann. Was eine Datei ist, ist eine andere Frage und gehört nicht in den Artikel Textdatei.--Cactus26 16:13, 12. Feb. 2011 (CET)

Zeichensatz und Zeichencodierung

In dem Artikel werden die beiden Begriffe teilweise wieder vergewaltigt. Unicode ist immer noch keine Zeichenkodierung und wird es auch nie sein. Siehe auch: http://www.joelonsoftware.com/articles/Unicode.html --87.171.122.246 21:42, 12. Feb. 2011 (CET)

Wo stört Dich welche Formulierung?--Cactus26 09:51, 13. Feb. 2011 (CET)

Eine habe ich verbessert, in der Einleitung war es wirklich verfälschend verkürzt.--Cactus26 11:23, 13. Feb. 2011 (CET)

Kritik!!!

Eine Textdatei ist eine Datei (Binärdatei), deren Inhalt durch andere Dateien (Binärdateien), auch Programme genannt, als Text auf Sichtgeräten (Drucker, Monitor) dargestellt werden kann. -- h. aust 89.204.137.158 12:42, 13. Feb. 2011 (CET)

Zur Untemauerung dieser Aussage, dass eine Textdatei ein Dateiformat darstellt, möchte ich auf folgenden Link angeben: http://www.itwissen.info/uebersicht/lexikon/Text-Dateien.html?page=0

Falls sie weiterhin diesen Unsinn verbreiten, sollten sie zumindest das "in der Informationstechnologie" herausnehmen, Außer sie betrachten Buchdruck als Informationstechnologie und Bücher als Textdateien, das ist allerdings unwahrscheinlich, da sie auf den modernen Begriff Infomationstechnologie (früher EDV) verweisen! Ich halte es nachwievor für unangebracht und unverantwortlich diesen Begriff in dieser Weise zu "mißbrauchen"! -- h.aust (nicht signierter Beitrag von 89.204.137.182 (Diskussion) 12:36, 17. Apr. 2011 (CEST))

Troll? Wenn der erste Satz ein zu kritisierender Inhalt sein soll: Der kommt nicht vor. Wenn der erste Satz eine korrigierte Form der Definition einer Textdatei sein soll, dann ist die schlicht und ergreifend falsch, im Artikel wird es vollkommen korrekt dargestellt: Im engeren Sinn versteht man darunter Dateien, die nur direkt druckbare Zeichen enthalten, erst im erweiterten Sinn auch Binärdateien (.pdf, .doc usw.), die sich dann durch zusätzlichen Aufwand in eine Textwiedergabe umsetzen lassen können. Insofern erachte ich die Darstellung im angegebenen Link auch als nicht korrekt (bzw. von Ihnen als zu verkürzt interpretiert) und weiß mich darin mit den anderen hier beteiligten Autoren einig. --PeterFrankfurt 02:33, 18. Apr. 2011 (CEST)

gudn tach!

@h. aust: ich habe nicht verstanden (und anscheinend geht es PeterFrankfurt da aehnlich wie mir), was genau am artikel von Ihnen kritisiert wird. koennten Sie das bitte praezisieren? -- seth 00:57, 24. Apr. 2011 (CEST)

Abgrenzung Binärdatei/Textdatei in Einleitung

Zum Edit-War i.Z. mit der Aussage 'Auch Textdateien sind binär gespeichert': Es geht hier um die (sinnvolle) Aussage, dass auch Textdateien in einem Binärformat (oder 'binär') gespeichert werden. Der Leser soll dies wissen, sonst könnte bei ihm die Frage entstehen, wie denn nun Textdateien gespeichert aussehen; denn nur Binärdateien würde er mit 'binär' assoziieren. Zusätzlich wäre also auch ein Hinweis nützlich, warum eine Binärdatei 'Binärdatei' heißt. Was hier (siehe 18:53, 11. Jun. 2013) schon mal vorgeschlagen war.
--VÖRBY (Diskussion) 08:59, 13. Jun. 2013 (CEST);
Anlass als Präfix ergänzt: --VÖRBY (Diskussion) 09:58, 14. Jun. 2013 (CEST)

Ich hoffe, Du hast nichts dagegen, dass ich den Text der Absatzüberschrift geändert habe. Mein folgender Vorschlag, den ich parallel zu Deinem Beitrag entwickelt habe, dürfte Deine Anregungen beinhalten, wenn ich es richtig sehe.--Cactus26 (Diskussion) 09:25, 13. Jun. 2013 (CEST)

Ich hoffe, es ist möglich, hier noch mal zu einer sachlichen Auseinandersetzung zurückzukommen.

1. zunächst: die Abgrenzung zur Binärdatei ist entscheidend und sollte in der Einleitung angesprochen werden.
2. Es sollte auch vermittelt werden, dass der Begriff "Binärdatei" eigentlich eine Abstraktion darstellt, da das Speicherabbild aller Dateien binär ist (ich bin überzeugt, dass ist vielen nicht klar)
3. Diese Abstraktion, die die Unterscheidung ermöglich, liegt in der Interpretation des Speicherabbilds
4. der Begriff "physisch" mag fehlinterpretierbar sein. Ich glaube zwar kaum, dass der Begriff in Verbindung mit "Datei" falsch aufgefasst werden kann, da "Datei" eine Abstraktion ist, die unabhängig vom wirklichen physischen Speichermedium ist. Insofern wäre "physisch" hier in gewissem Sinne metaphorisch aufzufassen (was im IT-Slang üblich ist). Das Adjektiv wegzulassen ("Interpretation des Inhalts" macht die Erläuterung sinnlos, da die Abstraktionsebene dann nicht festgelegt wird und nahe liegend ist, sie mit dem Inhalt der Textdatei den Text zu assoziieren. Eine Alternative wäre "binär" ("Interpretation der Daten" ist keine Alternative, da hier ebenfalls die Abstraktionsebene nicht festgelegt wird
5. Kausalität (die Begriffe Binär- und Textdatei werden komplementär verwendet, weil ... Interpretation ... im Vordergrund). Zugegeben, hier wird eine Ebene übersprungen und der bezug ist etwas unscharf. Da die Interpretation im Vordergrund steht, macht der Begriff "Binärdatei" überhaupt erst richtig Sinn und ermöglicht so erst eine Abgrenzung beider Typen (Lsg.vorschlag s.u.)
6. Gedankenfaden wird unterbrochen. Ein Gedankenfaden besteht zweifellos, unterbrochen wird er nicht, da das Thema ja nicht gewechselt wird. Die Satzumstellung aufgrund "Kausalität" dürfte aber zudem auch hier für Verbesserung sorgen (siehe Vorschlag unten). (Man könnte den Faden sogar verstärken, indem man die vorige Aussage aufgreift. Allerdings ist etwas schwierig, dass das nicht zu kompliziert gerät (und wieder angreifbare Kausalitäten beinhaltet). Mir gelingt im Moment keine "druckreife" Formulierung, der Gedanke wäre, dass keine speziellen Programme erforderlich sind, weil die Interpretation als sequentielle Zeichenfolge vergleichsweise unkompliziert ist, weil sie von keinen (naja, fast) zusätzlichen Konventionen/Definitionen/Annnahmen abhängt.)

Also mein Vorschlag wäre folgender:

Im Grunde ist auch das Speicherabbild von Textdateien binär, allerdings steht die Interpretation des binären Inhalts im Vordergrund und die Begriffe werden meist komplementär verwendet.

Ganz überraschend ist es vielleicht nicht, dass zu diesem eigentlich ausgesprochen banalen IT-Begriff so viele Meinungen existieren. Etwas überraschend ist dann aber doch, dass sich die meisten der Richtigkeit ihres Meinung dann so sicher sind. Ich möchte bitten, dass ihr bei allen subjektiven Vorlieben bedenken solltet, dass der derzeitige Inhalt schon einen Kompromiss aus vielen Meinungen darstellt, er wurde schon an einigen Stellen repliziert, war bereits ADT. So ganz falsch kann er nicht sein. --Cactus26 (Diskussion) 09:25, 13. Jun. 2013 (CEST)

Liebe Mitdiskutanten,

Bitte mal ehrlich. Ist so eine spezielle Frage denn wirklich in der Einleitung zu klären?

Ich halte es für ziemliche Haarspalterei, die Frage, wie man den Speicherauszug einer Textdatei, die dazu in einem Editor geladen werden müsste, überhaupt hier zu klären. Darauf wird sich niemals eine zufriedenstellende Antwort finden lassen, die dazu noch der Belegpflicht standhält.

Überhaupt driftet das ganze in meinen Augen schon sehr in die Richtung der TF. Außerdem ist es gemäß WP:ART auch überhaupt nicht nötig, dermaßen ins Detail zu gehen.

Eine Unterscheidung zwischen Text- und anderen Datei ist durchaus wichtig, aber das lässt sich nicht durch diesen Spezialfall erläutern. Ich schlage vor, diesen Satz einfach herauszunehmen. Es spielt einfach keine Rolle. --Plankton314 (Diskussion) 11:11, 13. Jun. 2013 (CEST)

Bin auch der Meinung, dass wir hier um eine recht triviale Sache einen gigantischen 'Heckmeck' veranstalten. Im hier ursächlichen "Edit-War" ging es lediglich um die m.E. wichtige Aussage, dass auch Textdateien "als Bits und Bytes gespeichert sind". Vielleicht kann man das auch noch einfacher sagen?

Zusätzlich wäre (als 'Gedankenfortführung') eine Erklärung nützlich, weshalb nur diese anderen Dateien 'Binärdateien' genannt werden: in irgendeiner Disk wurde das auch mal gefragt. Antwort siehe oben (08:59, 13. Jun. 2013). --VÖRBY (Diskussion) 12:23, 13. Jun. 2013 (CEST)

Meine Vermutung ist mittlerweile, ihr stört Euch am "Speicherabbild". Meine Intention in der Verwendung dieses Begriffs lag darin, einen Begriff zu verwenden, der nicht festlegt, ob die Datei sich nun im Hauptspeicher oder auf einem Datenträger befindet. Ich wollte ihn als Synonym im Sinne von "Repräsentation im Speicher bzw. auf Datenträger" verstanden wissen (dieser Bergiff hat aber eine hier mgölciherweise irritierende andere Konnotation). Die Repräsentation im Speicher ist vermutlich wirklich nicht wichtig, "gespeichert" der urspr. Version war schon ausreichend. Die saubere Abgrenzung von der Binärdatei halte ich aber für essentiell (mir ist nicht klar, ob Euer Problem mit der Ersetzung des "Speicherabbilds" erledigt ist, wenn nein, dann begründe ich das noch).

Neuer Vorschlag:

Das Gegenstück zur Textdatei stellt eine Binärdatei dar. Im Grunde werden auch Textdateien binär gespeichert, allerdings steht die Interpretation des binären Inhalts im Vordergrund und die Begriffe werden meist komplementär verwendet.

Wenn es so formuliert ist, kann man das 2. binär auch weglassen, ohne das es missverstanden werden sollte.--Cactus26 (Diskussion) 14:40, 13. Jun. 2013 (CEST)

1. Satz kurz und gut.

2. Satz: Vielleicht unklar, ob "Die Interpretation des binären Inhalts" für Text oder Binär gelten soll? Wobei ich meine, der 'binäre Inhalt' wird doch immer interpretiert; meintest du damit vielleicht "alle Bitkombinationen"? Das 'allerdings' erscheint mir auch nicht ganz klar.

Mein Vorschlag, aus deinem abgeleitet:

Das Gegenstück zur Textdatei stellt eine Binärdatei dar. Im Grunde werden auch Textdateien binär gespeichert, doch können in Binärdateien alle Bitkombinationen auftreten; die Interpretation des binären Inhalts steht also im Vordergrund. Dementsprechend werden die Begriffe komplementär verwendet.

"Mühsam ernährt sich das Eichhörnchen." --VÖRBY (Diskussion) 17:23, 13. Jun. 2013 (CEST)

Den Hinweis, ob ich mit "binärem Inhalt" alle Bitkombinationen meine, verstehe ich nicht (meine ich nicht). Natürlich wird der Inhalt immer interpretiert, die Aussage soll nur klarmachen, dass das Interpretationsverfahren das Entscheidende ist (vlt. sollte man "steht im Vordergrund" in "ist entscheidend" ändern). Der Hinweis, dass in Binärdateien alle Bitkombinationen auftreten können, ist zwar prinzipiell richtig, wirft aber verschiedene Fragen/Probleme auf (1. für verschiedene Binärdateien muss das nicht gelten (z.B. BCD-Daten); 2. Es gibt Codierungen, bei denen auch in Textdateien alle Bitkombinationen auftreten können). Gegen das "deshalb" hätte ich nichts.--Cactus26 (Diskussion) 18:10, 13. Jun. 2013 (CEST)

Bezug: Erster Disk-Beitrag hier im Abschnitt: Am Ende des 'Lösch-Kriegs' verblieb ja nun im Artikel der Passus, dass auch Textdateien binär gespeichert sind. Das ist die Hauptsache, wenn auch das "Jedoch" sprachlich unpassend erscheint und zumindest aus meiner Sicht das "Speicherabbild" und die "Interpretation des physischen Inhalts im Vordergrund" einfacher ausgedrückt werden könnten. Besser ginge es in der Wikipedia immer irgendwie. --VÖRBY (Diskussion) 17:40, 14. Jun. 2013 (CEST)

Ich habe mir nochmal die Einleitung durchgelesen und fand dabei, dass bereits die einführende Definition - auch wenn sie scheinbar scharf klingt - vollkommen unscharf und dazu noch unbelegt ist. Ein Zeichensatz umfasst nicht notwendigerweise nur Zeichen aus denen Text (menschlicher Sprache) besteht. Auch wirft es Fragen auf, ob bspw. base64-kodierte Daten auf einmal eine Textdatei wären.

Überhaupt finde ich, dass die ganze Diskussion zwar berechtigt ist, aber leider etwas über das Ziel hinausschießt. Natürlich ist es legitim, sich zu überlegen, wie man eine Textdatei von anderen Dateien abgrenzen kann oder wie sich die Darstellung des Inhalts unterscheidet. Es ist jedoch nicht die Aufgabe von uns Wikipedia-Autoren, solche Definitionen und Unterscheidungen selbst zu fällen!

Ich fürchte, wir driften hier deutlich Richtung WP:TF ab. Natürlich verleitet ein scheinbar "einfaches" Thema, wie "Textdatei" dazu, einfach mal hinzuschreiben, was es ist. Das geht dann damit weiter, dass, darauf aufbauend, versucht wird, ebendiese Abgrenzungen zu machen. Quellenbasiert ist das Ganze jedoch bis jetzt nicht.

Die Belegpflicht greift erst ab einer gewissen Komplexität des Sachverhalts. Wie zB. im englischssprachigen Artikel en:Text file, zu schreiben, dass die Datei elektronischen Text enthält, fällt sicherlich noch unter "allgemeinkundig". Aber Deutungen darüber, wie eine bestimmte Darstellung von Textdateien nun genannt werden, sollten mE. dann doch so langsam belegt werden.

Wir sollten uns hier bei o. g. "Spezialitäten" nicht darum streiten, was man wie nennen kann, sondern höchstens darüber, wie verschiedene Quellen, diesen Begriff oder die Darstellung beschreiben. Alles darüber hinaus ist im Grunde nur Begriffsetablierung! Bis jetzt existiert - insbesondere zu Aussagen im zweiten Abschnitt - keine Quelle. Das für sich würde bereits eine Entfernung begründen. --Plankton314 (Diskussion) 17:21, 17. Jun. 2013 (CEST)

Hallo, wir sollten nicht nochmal von vorne anfangen. Du hast recht, dass da einiges unscharf definiert oder nicht belegt ist. Konkret zu zwei deiner Anmerkungen:

• 'Zeichensatz' ist lediglich die Präzisierung für die Aussage, dass eine Textdatei nur Zeichen ... enthalten kann. Sonst könnte jemand fragen "was ist ein Zeichen"? Das halte ich also für trivial und nicht belegpflichtig.
• Zweiter Absatz: Zumindest das 'Textdatei auch binär gespeichert' ist ein 'trivialer Sachverhalt' - der deshalb ebenfalls nicht belegpflichtig ist. Hier ist der Hinweis aber trotzdem wichtig.

Wenn man besser formulieren kkönne oder sogar Belege fände, wäre das natürlich super. In Anbetracht der vergangenen, unangemessen breiten Diskussion (alle hatten wohl einen guten Willen) sollten wir es aber ansonsten mal gut sein lassen. Grüße von --VÖRBY (Diskussion) 17:37, 17. Jun. 2013 (CEST)

Ein Zeichensatz beschränkt seine Zeichen nicht auf die Elemente eines Textes. Diese Beschreibung weicht den Begriff Textdatei auf, weil (gerade in Sachen Computer) jedes Zeichen zwangsläufig aus einem Zeichensatz stammt. Eine Textdatei beschränkt sich auch nicht (spezialisierend) auf Zeichen, sondern eben (verallgemeinernd) auf (idR. menschlich lesbaren) Text. Zeichen sind eine damit notwendige Bedingung, aber eben keine hinreichende.

Insofern kann man erstmal nicht mehr über eine Textdatei sagen, als dass sie (idR. menschlich lesbaren) Text enthält, ggf. dazu noch, dass es sich um E-Text handelt.

Diese Definition, die sich darüber hinaus noch auf Zeichensätze und sequentielle Folgen erstreckt, ist mMn. nicht mehr trivial. Ebenso der Satz "Im Grunde ist auch das Speicherabbild [...]".

Es bringt einfach nichts, hier über persönliche Auffassungen zu diskutieren, sondern es soll hier nur etabliertes Wissen wiedergegeben werden. Wir können nur zu dem Schluss kommen, dass, wenn es darüber bereits solche Diskussionen gibt, es wohl nicht mehr als trivial angesehen werden kann und demzufolge zu belegen ist. Kann es das nicht werden, müssen wir so ehrlich gegenüber dem Leser sein und solche Aussagen entfernen bzw. auf ein trivialeres Maß reduzieren. --Plankton314 (Diskussion) 18:58, 17. Jun. 2013 (CEST)

Im Text steht "darstellbare Zeichen eines Zeichensatzes", das sind also nicht nur "Zeichen". Auch mit "sequentielle Folge" ist das mMn noch 'trivial'. Mit dem "Speicherabbild" und der "Interpretation des physischen Inhalts" hatte ich auch leichtes Magengrummeln (wg. der OMA). Ich bin jetzt mal so frei, die Texte direkt zu ändern. Schau mal ob das aus deiner (eurer) Sicht besser ist. Aber Diskutieren führt nur in "schon durchlaufene Schleifen". --VÖRBY (Diskussion) 19:16, 17. Jun. 2013 (CEST)

Sorry, Lemma ist noch gesperrt. --VÖRBY (Diskussion) 19:18, 17. Jun. 2013 (CEST)

gudn tach!

du kannst die passagen herkopieren und abaendern. -- seth 22:15, 17. Jun. 2013 (CEST)

Ich schlage vor, zunächst auf die Version vom 6. Juni zurückzugehen. Diese Version ist das Ergebnis einiger Anregungen und Reviews, es sind zahlreiche Meinungen hier eingeflossen und diskutiert worden, sie ist als Basis insofern geeignet. Dann möchte ich in Ruhe auf die inzwischen vorgebrachten Anmerkungen, Anregungen und Kritikpunkte eingehen. Dazu brauche ich etwas Zeit, weil es ein wenig her ist, dass ich den Artikel geschrieben habe und mich intensiver mit dem Thema befasst habe. Ich bitte darum, mir diese einzuräumen.--Cactus26 (Diskussion) 07:48, 18. Jun. 2013 (CEST)

Einverstanden. Meine Ergänzung 'sequentielle Folge' vom 9.6. war sicher soweit sinnvoll und kann auch mit (meine damalige Quelle war ungeeignet) belegt werden. Den (monierten) Hinweis auf Zeichensatz könnte man eliminieren, indem der Ausdruck 'darstellbare Zeichen' auf den von mir dort eingetragenen Anker Zeichensatz#darstellbar verlinkt wird. Ansonsten finden sich im Web überwiegend URLs, die den Ausdruck 'Textdatei' einfach und selbstverständlich (i.S. von 'nur Zeichen') benutzen, ohne ihn aber zu definieren, schon gar nicht eindeutig. Viel Erfolg! --VÖRBY (Diskussion) 09:25, 18. Jun. 2013 (CEST)

Einleitung überarbeiten

(direkte Fortsetzung der vorausgehenden Diskussion)

Mittlerweile sind Plankton und ich durch E-Mail-Korrespondenz zu einem gemeinsames Verständnis des Problems gekommen. Dabei ist uns klar geworden, dass nicht die Quellenlage das eigentliche Problem ist, sondern dass der Artikel die beiden Kategorien der Interpretation des Begriffs nicht klar genug herausarbeitet:

• umgangssprachliche Interpretation, orientiert sich am Inhalt, wird im Artikel bisher durch den letzten Abschnitt der Einleitung ("...die mit dem Ziel erstellt wurden, dem Benutzer einen lesbaren Text zu präsentieren.") abgedeckt.
• fachsprachliche Bedeutung, orientiert sich ausschließlich am Dateiformat, nur diese wird ansonsten im Artikel behandelt, diese ist gemeint, wenn man z.B. nach "als Textdatei speichern" googelt (). Diese Definition ist wesentlich präziser, im Ggs. zur ugs. Interpretation gibt es hier ganz klar einen gemeinsamen Nenner der verschiedenen Quellen.

Sowohl Plankton als auch VÖRBY (erkennbar in der Disk. hier: ) lagen mit ihrer Einschätzung zuvor irgendwo zwischen beiden Interpretationen. Dies bewirkt offensichtlich, dass man den letzten Abschnitt der Einleitung nicht richtig wahrnimmt/einordnet und damit den ganzen Artikel infrage stellt. Beide Interpretationen haben eigentlich nichts miteinander zu tun, das wird offensichtlich nicht klar.

Für die fachsprachliche Bedeutung habe ich in den letzten Tagen einige recht brauchbare Quellen gefunden (scheint sich gegenüber dem Zustand vor 3 Jahren verbessert zu haben), für die ugs. Bedeutung ist dies schwieriger, insbesondere die Abgrenzung zw. beiden Interpretationen wird sich nur indirekt belegen lassen, da dies offensichtlich noch nicht sauber analysiert/ausgearbeitet/publiziert wurde.

Ich schlage vor, dass ich (nach Rücksetzen des Artikels wie besprochen) eine Einleitung ausarbeite, die versucht, wesentlich früher und klarer den Unterschied zw. diesen beiden Interpretationen herauszuarbeiten. Ich habe da schon ein paar Ideen, weiß aber nicht, ob ich das nicht vor meinem Urlaub (nächste Woche von So. bis So.) hinbekomme. Bitte also ein wenig um Geduld.--Cactus26 (Diskussion) 15:16, 19. Jun. 2013 (CEST)

Hallo und Danke für die Arbeit! Auch in diesem Lemma (wie so oft) gibt es unterschiedliche Interpretationen (umgangssprachlich/fachsprachlich); ich hatte es mal i.e.S vs. i.w.S. genannt. Diese Tatsache wird ja bereits mit "nicht in allen Fällen eindeutig" beschrieben. Das Problem scheint mir aber, dass

1. diese Aussage selbst uneindeutig ist (was sagt sie wirklich aus?),
2. die beiden Interpretationen nicht klar voneinander getrennt sind und
3. sich die Kriterien zur Bestimmung des Lemmas über alle 4 Abschnitte der Einleitung verteilen. Ja, im letzten Absatz erwartet niemand mehr ein 'Kriterium'.

Ja, die Lösung besteht in der klaren Teilung der beiden Sichtweisen. Möglichst inkl. Belegen oder Hinweis auf fehlende oder unterschiedliche Definitionen in den Quellen. Unser 'Streitthema' "alles wird binär bespeichert" gilt für beide Varienten. ÜBERARBEITEN! --VÖRBY (Diskussion) 16:02, 19. Jun. 2013 (CEST)

Hallo zusammen,

Ich stelle hier einfach mal meinen Vorschlag zur Einleitung ein:

Als Textdatei wird in der Informationstechnik eine Datei bezeichnet, deren Inhalt nur aus den darstellbaren Zeichen eines Zeichensatzes besteht. Ihr Inhalt kann zusätzlich durch Steuerzeichen wie Zeilen- oder Seitenwechsel gegliedert sein.

Umgangssprachlich werden gelegentlich Dateien als „Textdatei“ bezeichnet, die ausschließlich lesbaren Text enthalten. Solche Dateien können mit einem einfachen Texteditor betrachtet und bearbeitet werden.

Das Gegenstück zur Textdatei ist die Binärdatei, die beliebige Werte enthalten kann und in einem bestimmten Dateiformat gespeichert ist. Die Klassifizierung von Dateien als Text- und Binärdateien ist nicht in allen Fällen eindeutig.

Die Menge der verfügbaren Zeichen wird durch die verwendete Zeichenkodierung bestimmt. Am gebräuchlichsten sind ASCII oder UTF8, eine Kodierung des Unicode. Häufig wird die Zeichenmenge zudem durch eine natürliche oder formale Sprache eingeschränkt, in welcher der Textinhalt verfasst ist. Sind zur Auswertung des Inhalts einer Textdatei weder besondere Verarbeitungsschritte noch die Kenntnis einer speziellen Notation erforderlich, wird der Inhalt als Plain text bezeichnet. Textdateien, die eine bestimmte Notation erfordern – wie beispielsweise HTML-Dateien – können zwar mit einem einfachen Texteditor bearbeitet werden, es gibt jedoch hierfür oft spezielle Programme, die die Bearbeitung erleichtern – beispielsweise durch besondere Syntaxhervorhebung oder automatische Formatierungen.

Es ist im Grund nur eine (sprachlich) gekürzte Version der bisherigen Einleitung.

Das Beispiel mit dem Textverarbeitungsprogramm habe ich ausgelassen, weil ich nicht wusste, wo man das einstellen sollte. --Plankton314 (Diskussion) 15:25, 21. Jun. 2013 (CEST)

Hallo ich hatte den Stand der Diskussion anders verstanden:

• Die engere Definition ("fachsprachlich") sagt ~ das, was in deinem ersten Satz steht: nur darstellbare Zeichen + STZ gespeichert
• Die Umgangssprache ("nicht in allen Fällen eindeutig") sagt auch dann "Textdatei" wenn dem Benutzer nur Texte präsentiert werden sollen - zum Beispiel mit Word, d.h. mit ganz anderen Bitkombinationen als in einem Zeichensatz als darstellbar definiert.
• Die Aussage "binär gespeichert" gilt für beide Varianten ohne Unterschied.

Der Einleitungstext sollte entsprechend klare Aussagen bieten. Den Rest habe ich mir jetzt gar nicht angesehen, darum hatten wir nicht diskutiert. Grüße von --VÖRBY (Diskussion) 19:14, 21. Jun. 2013 (CEST)

Habe leider, wie bereits angekündigt, die nächsten Tage keine Zeit. Hoffe, ihr habt Geduld bis nach meinem Urlaub.--Cactus26 (Diskussion) 09:15, 22. Jun. 2013 (CEST)

Neue Einleitung

Habe nun die versprochene Überarbeitung gemacht. Durch die Disk. ist mir selbst vieles klarer geworden, v.a. dass die Interpretation das entscheidende ist (auch wenn das bei Euch bislang nicht auf Gegenliebe gestoßen ist, ich bin mir sicher und habe dafür ja nun auch explizite Quellen). Zudem dass sich der fachsprachliche Begriff am Dateiformat orientiert, der ugs. am Inhalt.

Zunächst ein paar Anm. zu Planktons Entwurf:

• Als Textdatei wird in der Informationstechnik eine Datei bezeichnet, deren Inhalt nur aus den darstellbaren Zeichen eines Zeichensatzes besteht. Die Betonung des "darstellbaren" finde ich als ersten Satz sehr unglücklich. Man muss sich folgendes vergegenwärtigen: Dass der ASCII-Code (und somit alle Derivate) überhaupt nicht darstellbare Zeichen enthält, ist der Historie geschuldet, als Inhalte direkt über die Leitung an ein Terminal bzw. Drucker geschickt wurden. Für den Begriff Textdatei ist weniger entscheidend, dass sich der Inhalt auf darstellbare Zeichen beschränkt als vielmehr, dass der Inhalt als Zeichen eines Zeichensatzes zu interpretieren ist.
• Umgangssprachlich werden gelegentlich Dateien als „Textdatei“ bezeichnet, die ausschließlich lesbaren Text enthalten. Solche Dateien können mit einem einfachen Texteditor betrachtet und bearbeitet werden. Das ist wohl ein Versehen, genau andersrum ist es richtig, fachsprachliche können mit einem Editor bearbeitet werden, umgangssprachliche nicht unbedingt.
• Das Gegenstück zur Textdatei ist die Binärdatei, die beliebige Werte (=Byteinhalte) enthalten kann Wie oben. Auch eine Textdatei kann beliebige Werte enthalten (siehe z.B. UTF8), die Interpretation ist entscheidend.

Offen bleibt nun folgendes:

• die ugs. Verwendung lässt sich nur indirekt belegen. Es ist schwer, nach solchen Verwendungen zu suchen. Zwei Fälle habe ich: ,
• Hinweis, dass der Rest des Artikels sich nur auf die fachsprachliche Def. bezieht. Nötig? Wie?
• Begriff "fachsprachlich": Einen besseren gelingt es mir nicht zu finden. "Technisch" finde ich etwas irreführend, so low level ist es ja nun auch wieder nicht.

--Cactus26 (Diskussion) 14:40, 2. Jul. 2013 (CEST)

Nach BK: Gut gworden!

Ich persönlich würde (noch) mehr auf die Zweckbestimmung abzielen: Eine Textdatei ist dazu gedacht, von einem Menschen gelesen zu werden, und ihr Inhalt ist so beschaffen, dass das mit minimalem Aufwand (auf dem jeweiligen System) geschehen kann. Typischerweise ist der Inhalt lesbarer Klartext einer menschlichen Sprache. Ein Binärformat ist vielleicht zufällig halbwegs lesbar, aber das ist nicht seine Bestimmung. Binärformate sind von Anfang an nicht als menschenlesbarer Text gedacht, sondern als Eingabe für ein Programm. Deshalb ist es allenfalls zufällig lesbar, weil bei der Spezifikation des Formates kein Gedanke an Lesbarkeit für Menschen berücksichtigt wurde. (Programme, die untereinander in Textdateien kommunizieren, gibt es natürlich auch. Primärer Adressat ist eine andere Maschine, aber das Format ist so spezifiziert, dass es auch von Menschen gelesen werden kann. Siehe XML und ähnliche.)

Noch eine Eigenschaft, die ich für bedeutend halte: pure Textdateien sind (immer nur auf ihrem nativen System) perfekt leicht lesbar, weil die nötigen Programme (typischerweise) schon mit dem Betriebssystem geliefert werden, oder sogar völlig verzichtbar sind.

(Unter MS-DOS konnte man mit Konsolbefehl eine Textdatei erezugen (C:\>COPY con: test.txt). Das geht sogar heute noch in einem CMD-Fenster von Windows. (Falls Du es Probieren willst: Strg-Z beendet den Eingabemodus und erzeugt die Datei). Der zugehörige "Lesebefehl" ist "c:\>Type test.txt")

Probleme gibt es nur, wenn man Textdateien zwischen Systemen austauscht: Z. B. sehen Unix/Linux-Dateien unter DOS immer doof aus, weil unter Linux das Zeilenende etwas anders codiert ist. Früher hätte es sogar noch weitere Probleme geben können, weil es Maschinen gab, die nicht nach ASCII, sondern nach EBCDIC codiert haben. --Pyrometer (Diskussion) 15:36, 2. Jul. 2013 (CEST)

Inhaltlich kommen jetzt die unterschiedlichen Defintionen klar zum Ausdruck. Passt also. Nur nochmal kurz zu 'Interpretation': Ob man "Textdatei" mit 'der Inhalt ist als Zeichen eines Zeichensatzes zu interpretieren' definieren muss? Ist mE (mind. für den Laien) zu kompliziert ausgedrückt. Es SIND (einfach gesagt) nur Zeichen (gem. Zeichensatz) drin, bei Binärdateien kann es Alles sein. Aber wir können das nun m.E. beenden. --VÖRBY (Diskussion) 20:53, 2. Jul. 2013 (CEST)

@Pyrometer: Danke für Dein Lob, freue mich sehr darüber verstanden zu werden, insbesondere da ich das Gefühl hatte, dass wir bislang alle ein wenig aneinander vorbeigeredet haben. Vlt. könnte tats. noch etwas mehr auf die Intention eingehen, allerdings würde ich das nicht in der Einleitung tun, die ist ohnehin schon sehr lang, der Hinweis zur Bearbeitbarkeit durch einen Texteditor sollte hier reichen. Am Ende des Geschichtsabschnitts steht schon eine Anmerkung in dieser Richtung. Weiterhin gibt es den Abschnitt "Verwendung von Textdateien", zum Austausch von Textdateien gibt es "Austausch zwischen unterschiedlichen Systemen". Wo siehst Du da noch Ergänzungsbedearf? Ich denke auch nochmal drüber nach, ob mir hier noch was einfällt (Ich bin im übrigen unter Kollegen als "Kommandozeilenfetischist" verschrien, insofern sagst Du mir mit dem COPY CON... nicht unbedingt was neues, "kein Programm" ist, wenn man pedantisch ist, vielleicht nicht ganz korrekt, der "Editor" ist in diesem Fall cmd.exe (bzw. früher command.com)).--Cactus26 (Diskussion) 08:02, 3. Jul. 2013 (CEST)

@VÖRBY: Gerade auch für den Laien kann man mMn nicht auf die Interpretation des binären Inhalts verzichten. Wenn man den Abstraktionsgrad offen lässt, würde eine PDF-Datei, die z.B. "Hallo" enthält, ebenfalls als Textdatei durchgehen, denn deren "Inhalt" besteht ja ausschließlich aus Text, in ihr sind nur Zeichen eines Zeichensatzes "drin".--Cactus26 (Diskussion) 08:02, 3. Jul. 2013 (CEST)

Ich glaube, du verstehst nicht was ich meine: Natürlich geht es um den Inhalt, aber muss man das "Interpretation des binären Inhalts" nennen? Genügt nicht "enthält nur ..."? Diese "Hallo-PDF" wäre nach umgangssprachlicher Definition eine Textdatei, ok. Wenn man ihren Inhalt aber mit einem Hex-Editor anschaut (ich sage bewusst nicht 'interpretiert'), erkennt man wohl sehr viele, nicht darstellbare Zeichen; 'fachsprachlich' ist das also eine Binärdatei.

Ergänzung: Wenn das 'identifiziert' heißen würde, könnte ich damit etwas anfangen: Die Bits werden als Zeichen identifiziert, und zwar gemäß einem bestimmten Zeichensatz. Aber 'interpretiert' kann ich hier nur schwer einordnen. Sorry, nochmal ein Versuch. --VÖRBY (Diskussion) 17:55, 3. Jul. 2013 (CEST)

Zum Problem mit den beiden Bezeichnungen: Ich denke, der Begriff wird aus der 'fachsprachlichen' Sicht definiert. Das muss man aber nicht explizit so nennen, es genügt wenn daneben gesagt wird, dass "umgangssprachlich" auch eine abweichende Definition verwendet wird.

Wenn niemand sonst Anstoß an der 'Interpretation'-Formulierung nimmt, soll es mir recht sein. Gruß von --VÖRBY (Diskussion) 09:18, 3. Jul. 2013 (CEST)

Interpretiert ist (im Ggs. zum mir hier völlig schleierhaften "identifiziert") genau das richtige Wort, beide Quellen verwenden es, auch die Betonung von "Bits" ist irreführend. Ein weiterer Versuch: Der binäre Inhalt "42C3A472" (hex) in einer mit UTF8 codierten Textdatei ist als "Bär" zu interpretieren (4 Byte entsprechen 3 Zeichen, da das "ä" zwei Byte beansprucht). Interpretiert man denselben binären Inhalt als Integer bei Unterstellung von Little Endian (höchstwertiges Byte hinten) ist der binäre Inhalt als die Zahl 1923400514 zu interpretieren. Sowohl für Textdateien (andere Codierungen) als erst recht für Binärdateien gäbe es viele weitere Interpretationsmöglichkeiten dieses binären Inhalts. Jetzt klarer?--Cactus26 (Diskussion) 16:40, 4. Jul. 2013 (CEST)

Man kann 'interpretiert' sagen und das ist auch korrekt. Es erschien mir nur komplizierter als "enthält". EOD, Danke für die Mühe.--VÖRBY (Diskussion) 17:29, 4. Jul. 2013 (CEST)

Im Großen und Ganzen halte ich die Neufassung der Einleitung für eine Verbesserung, ich persönlich finde sie verständlicher. (Wobei das jetzt auch daran liegen kann, dass ich weiß, was sie mir sagen will :) ). Und vor allem abstrahiert sie etwas mehr von den technischen Details.

Ein paar Sachen, sollte mE. dennoch mal überdacht/überarbeitet werden:

• (wie VÖRBY) Die Unterscheidung in einerseits "binären Inhalt" im ersten Absatz und "Inhalt der Datei" ist etwas verwirrend bzw. unscharf. Soweit ich es sehe, ist mit dem Ersten der "rohe" Dateiinhalt (in Form von Bits und Bytes) gemeint und mit dem zweiten der "eigentliche" Inhalt, also die eher Information, die die Datei enthält. Das sollte irgendwie unterschieden werden, auch wenn mir gerade dazu nichts Sinnvolles einfällt.
• Wenn das Dateiformat den ausschlaggebenden Unterschied macht, sollte dessen Nennung nicht erst im zweiten Absatz bei einem Vergleich zur weiteren Bedeutung auftauchen.

--Plankton314 (Diskussion) 16:46, 3. Jul. 2013 (CEST)

Ich kann Deine Punkte vollkommen nachvollziehen, denke ich.

• Abstraktionsgrad von "Inhalt": Ich habe mal alle vorkommen von Inhalt in der Einleitung gesucht:
  • 1-3: "Interpretation des binären Inhalts". Darauf folgt nach dem Doppelpunkt noch zweimal "Inhalt" hier fände ich es schon etwas pedantisch das "binär" nochmal davorzusetzen, es sollte klar sein
  • "primär am Inhalt der Datei": Wirklich problematisch. Hier habe ich mal "für den Endbenutzer sichtbaren" vorne ergänzt, im Gegenzug im Folgesatz den Benutzer herausgenommen.
  • "beim Inhalt kann es sich beispielsweise auch um ASCII-Art": Hier habe ich Inhalt schlicht weggelassen, es ist nicht nötig, durch den vorausgehenden Halbsatz ohnehin klar, eher verwirrend
  • "und zur Auswertung des Inhalts" Wirklich schlecht formuliert, unnötig missverständlich, habe es durch "Verständnis der Bedeutung" ersetzt.
• "Dateiformat" weiter vorne: Stimmt schon, wäre nicht schlecht. Anderseits fand ich es geschickt, es zu Beginn des 2. Absatzes zu nehmen, da es dort auf jeden Fall hin muss (als Gegenstück zur sich am "Nutzungsinhalt" der Datei orientierenden ugs. Verw.). Sonst hätte man es doppelt. Meinst Du wirklich, es muss unbedingt vor? Wenn ja, in welchen Satz würdest Du es unterbringen?

--Cactus26 (Diskussion) 17:06, 4. Jul. 2013 (CEST)

Keine Trennung zwischen Umgangssprachlich vs. Fachsprachlich und mangelnder Bezug zur Realität?

Leider sehr lang geworden, daher gleich los.

Dinge, die mich beim Lesen dieses Artikels stören und m.E. nicht so sein sollten, unsortiert, Nummerierung als Referenz.

1. Eigentlich wollte ich wissen, was es mit dem Auswahlfeld "Codierung" in den Speicheroptionen vom "Editor" unter Windows auf sich hat. Diese sind: ANSI, Unicode, Unicode Big Endian, UTF-8. Im Artikel findet man das Wort "ANSI" genau 2 mal und es hat nichts mit dem Gesuchten zu tun. Im ENGLISCHSPRACHIGEN ARTIKEL findet man hingegen sofort das, was ich dazu wissen wollte.
2. Habe die gesamte Diskussionsseite gelesen und scheinbar passt der Artikel nicht (mehr?) zum Diskutierten: War das Wichtigste nicht erstmal abzugrenzen, was umgangssprachlich und fachsprachlich mit dem Begriff gemeint ist? Wieso ist diese Trennung dann nicht in der Einleitung?
3. Widersprüchlich ohne Not, anscheinend teilweise fehlender Bezug zur unterschiedlichen Wortbedeutung und auch Fehlgewichtung bei Auswahl und Reihenfolge von Informationen. Dazu der Haupttext. Einfach, was mir eben sofort beim schnellen Lesen schon negativ aufgefallen ist..

Gedankengang Lesen und Testen:

Artikel in Einleitung: "Als Textdatei wird in der Informationstechnik eine Datei bezeichnet, die darstellbare Zeichen enthält und zum Speichern, Bearbeiten, zur Datenübertragung und Lesen dient."

Darstellbar. Genauer im Abschnitt "Allgemeineines": "Bei einer Textdatei wird der Inhalt als sequenzielle Folge von Zeichen eines Zeichensatzes interpretiert... ...Folglich ist eine Textdatei im Gegensatz zu einer Binärdatei... ... kann mit einem einfachen einfachen Texteditor – wie beispielsweise mit Notepad unter Windows betrachtet und bearbeitet werden."

--> Dann schau ich doch mal, was es alles so für Textdateien gibt und öffne die mal mit dem Notepad/ Editor. Aber beim Scrollen nehme ich Dinge wahr und bleibe immer wieder hängen.

Zunächst stolpere ich über Folgendes - Abschnitt "Abgrenzung von Binär- und Textdateien": "Unter Windows und macOS wird dem Namen einer Textdatei meist die Endung .txt angehängt" Das wirkt extrem falsch!... " Multipurpose Internet Mail Extensions (MIME) definieren sogenannte Medientypen... ...Medientyp text kennzeichnet dabei Text... ...Bei Textdateien... ...lautet die vollständige Typangabe text/plain."

Stolpere nochmal: "Eine mit einer Textverarbeitung... ...erstellte Datei ist im Normalfall keine Textdatei" War klar, weil Grafikinhalt möglich. "Auch ein im... Format (PDF, .pdf) ... vorliegender Text ist keine Textdatei."

Stolpere nochmal, Abschnitt "Zeichencodierung": War die Aufgabe: Schreibe diesen Abschnitt ohne Verweis auf den Namensgeber des letzten Stand von ASCII (Artikelzitat: "zuletzt im Jahr 1986 (ANSI X3.4-1986))" , Benenne die Zeichencodierung, die Windows in Westeuropa benutzt ohne das Wort zu verwenden, das im Program im Auswahlmenü dafür verwendet wird. Artikel Windows-1252 erster Satz "Windows-1252 (auch Codepage 1252, cp1252, Westeuropäisch (Western European) oder ANSI)" Herzlichen Glückwunsch dazu, die zuletzt zuständige Organisation für ASCII und die Bezeichnung der Codierung im Standard Text Editor des meist verwendeten Betriebssystems und in allen Sprachen, die die lateinische Schrift verwenden, komplett vermieden zu haben. Schulnote 1 mit Sternchen. ASCII wurde von der ASA entwickelt und das ist eine Vorgängerbezeichnung von ANSI - American National Standards Institute, das ist in den USA, was DIN in Deutschland ist. Unterschied ist: Microsoft, Apple, Google, Internet, Intel, Amazon, ebay, Spotify, Netflix, Facebook, Twitter/X, Instagram, YouTube, das Internet, Wikipedia, GPS vs. Äääähmm SAP. Mittlerweile arbeiten alle nationalen Normungsinstitute zusammen, in der ISO zusammen und nennen ihre Veröffentlichungen ISO12345. Es wird also weder ein Bezug zu offizieller Normung noch zum konkreten Betriebsystem hergestellt. Welche Einstellung möglicherweise sinnvoll wäre und weshalb kann man so ganz sicher nicht aus dem Artikel ableiten, da der konkrete Bezug völlig fehlt.

Und stolpere schon wieder, Abschnitt "Verwendung von Textdateien": "Textdateien können... ...komplexere Daten...übermitteln. Die Datei ist... ...wird durch ein bestimmtes Programm weiterverarbeitet oder durch einen Systemadministrator gepflegt." Gefühlt sind die meisten Betriebssystemdateien von Windows Textdateien, aber vlt. haben die auch nur das Editorsymbol zugeordnet, die Tausenden "Migrationsdateien" (zum Fixen von irgendeiner Sicherheitslücke beim Update mal entstanden) sind auf jeden Fall klar und veständlich lesbar...

--> Aber jetzt kommen endlich die Hinweise auf Dateitypen zum Ausprobieren.

Und jetzt gibt es keine passenden Worte für meine Gefühle und Gedanken.

Abschnitt "Weitere Dateiformate": "Die wichtigsten Dateiformate für Textdateien sind:

1. Textdatei, Endung *.txt  !!! Die WICHTIGSTE !!! TXT-Dateien !!! Nicht die ganzen anderen Dateien, wobei dem Text nach unklar ist, ob HTML eigentlich dazugehört. Tip: Hyper TEXT Markup Language heißt das.

.xls und .pdf kommen auch ganz unten. Wer braucht schon Webseiten, Tabellenkalkulationen und elektronische Rechnungen und Unterschriften - also das Internet - wenn man auch Telex und Lochkarten nehmen kann, damit kann man auch Verträge schließen, auch ohne Lochkarte, direkt, Lochkarte spart nur Telefongebühren. Wer es so richtig eilig hat, der verhandelt direkt am Telex miteinander. Man muss nur aufpassen, dass man nicht tippt, wenn der andere tippt, sonst hat man Buchstabensalat. So beobachtet im Speditionsalltag einer großen internationalen Spedition Anfang der 90er, in dem es keinen einzigen Computer gab.

Getestet kann ich weder .pdf, noch .odp mit Editor oder Wordpad lesen, hatte ich auch schon mal mit einem vernünftigen Texteditor irgendwann getestet. Ggf. sind da lesbare Brocken zur Formatierung drin, aber manchmal auch nicht, viel Symbole manchmal anscheinen asiatische Schriftzeichen.

Dieser Artikel wirkt auf mich insgesamt irreführend.

Das Internet basiert im Prinzip aus jeder Menge Protokollen und dem Austausch von Textdateien (Webseiten und E-Mails: html) und somit sind diese Schlüsselelement für die dritte/ vierte industirelle Revolution, je nachdem, wie man zählt (Mechanisierung, Automatisierung, Digitalisierung/ Vernetzung). Schon mal irgendetwas hergestellt? Computerized Numerical Control (dt. rechnergestützte numerische Steuerung).

Geschichte (Auszug):

1794–1800	Die erste Metalldrehmaschine wurde gebaut.
1808	Joseph Marie Jacquard benutzte gelochte Blechkarten zur automatischen Steuerung von Webmaschinen.
1863	Erfindung des Lochstreifens (Papier als Datenträger) von Henri Fourneaux.
1946	John W. Mauchly und John Presper Eckert lieferten den ersten elektronischen Digitalrechner an die US-Armee.
1949–1952	Erste numerisch gesteuerte Maschine von John T. Parsons (USA) in Zusammenarbeit mit dem Massachusetts Institute of Technology für die U.S. Air Force entwickelt.
1954	Erste industriell hergestellte NC von der Bendix Corporation (USA), aufgebaut mit ca. 300 Röhren.
1959	Einführung der NC in Europa (Messe Hannover)

Was sind Nummern? Text. Also, wurde die Programmierung von Werkzeugmaschinen mittels Textdateien ca. 8 Jahre erfunden nachdem moderne Metallverarbeitung im Maschinenbau begonnen hatte, 1808! Textdateien schon seit der ersten industriellen Revolution.

Übrigens, als Bezug: Der “Adler” fuhr 1835 auf sechs Kilometern zwischen Nürnberg und Fürth – die erste Eisenbahn in Deutschland, deutlich später.

Wenn man Monsieur Jacquard abstreiten möchte, dass er damit Textprogrammierung erfunden hat, dann aber nur, weil man sich an modernen Begriffen aufhängt. Zurück zur Begrifssbestimmung in der Einleitung zum Vergleich:

"Als Textdatei wird in der Informationstechnik eine Datei bezeichnet, die darstellbare Zeichen enthält und zum Speichern, Bearbeiten, zur Datenübertragung und Lesen dient."

Datei - gebohrte oder gestanzte Blechkarte. Blechkarte, Lochkarte,Speicherkarte. Wortherkunft scheint klar.

darstellbare Zeichen - Blechkarten 1808 kenne ich nicht. Telex Lochstreifenmuster kann man so auffassen.

Speichern - Bohren oder Stanzen ist Schreiben und Speichern; Bearbeiten - mehr Löcher und längere Schlitze sicherlich; Datenübertragung - nicht im engeren Sinn; Lesen - ich habe gesehen, wie jemand den Lochstreifen beim Drucken vom Telex gelesen/ entziffert hat, in Übertragungsgeschwindigkeit, d.h. ziemlich zügig. Die Lochblechkarten vom Monsieur Jacquard kann ich nicht einschätzen, aber da er diesen Programmiercode erfunden hat wird er auf jeden Fall Teile davon direkt "lesen" haben können.

Textdateien sind also prinzipiell uralt und daher ist es wichtig, fachlich von umgangssprachlich zu trennen.

Nochmal zurück zu den wichtigsten Dateiformaten:

"Abschnitt "Weitere Dateiformate": "Die wichtigsten Dateiformate für Textdateien sind:"

Also nicht .html, weil keiner Webseiten oder E-Mails braucht, keine CNC-Programme, weil die ja numerisch sind und nicht textlich oder so. Wie war das jetzt mit den Textdateien .pdf und .odt, die ich im Editor nicht lesen kann?

Es stand ja auch schon im Artikel, dass. .pdf eben keine Textdateien sind, aber schauen wir mal in den Artikel "Internet Media Type", denn Textdateien sind ja laut diesem Artikel vom MIME-Typ "text/plain"

Und was sind .pdf, .odt und .docx (Word, auch im Artikel als Textdatei gelistet)?

application/pdf, application/vnd.oasis.opendocument.text, application/vnd.openxmlformats-officedocument.wordprocessingml.document. Das ist ja nicht text.

Sondern: "application – für uninterpretierte binäre Daten, Mischformate (z. B. Textdokumente mit eingebetteten nichttextuellen Daten) oder Informationen, die von einem bestimmten Programm verarbeitet werden sollen." Uninterpretierte BINÄRE DATEN, Mischformate, die von einem bestimmte Programm verarbeitet werden. Also ich brauche einen Interpreter, keinen Editor oder ein Programm, keinen Editor, außer einer hat Interpreter oder Programm namentlich als "Editor" bezeichnet.

Oh und HTML? "text/html" Dazu steht im Artikel "von der Struktur her verwandt mit XML" Also ist XML jetzt auch noch älter als HTML oder wichtiger? Weil das in der Tabelle steht und HTML drunter unter den ganzen wichtigen Textdateien, die keine sind.

Die Leute, die hier diskutiert haben und den Artiekl aufgebaut, die haben Ahnung und ich glaube nicht, dass das damals deren Arbeitsstand war. Der Artikel hat genau die Probleme, deren Lösung sie dort diskutiert haben.

Daher mein Vorschlag:

Macht zwei Artikel. Einen für die umgangssprachliche Textdatei. Die es ja gibt, siehe die falsche Liste. Und einen Artikel für die fachbegriffliche Textdatei. Jeweils in beide einmal oben schreiben, um welche es geht und dann die andere jeweils nie wieder erwähnen. Das ist m.E die einzige Möglichkeit zu verhindern, dass das hier wieder verwässert.

Sorry für die Überlänge, aber es ist einfach so traurig. Hier sind Leute, die haben Ahnung und eigentlich könnte so ein Artikel viel kürzer und viel verständlicher und mit viel mehr Realitätsbezug sein. Wenn man am Ende noch nicht mal weiß, dass HTML Dateien Textdateien sind, sondern dass nur so erahnt, weil das unerklärlicherweise nicht in der Tabelle ist und ganz unten. Weil .txt Dateien wichtiger sind, für die Versionshinweise vom neuen HTML Editor vielleicht... --~2026-22433-3 (Diskussion) 23:20, 11. Jan. 2026 (CET)

Stimme dem zu.

Der Begriff Textdatei ist sagt eigentlich noch weniger aus als plain text. Es wäre sinnvoller einfach kurz und knapp zu erklären, was alles gemeint sein könnte und dann zB auf eine Liste an Textformaten zu verweisen, anstatt sie alle aufzuzählen und dann auch noch ausführlich zu beschreiben. Was soll irgendjemand diesem Artikei entnehmen? Textdatei ist auch kein Fachausdruck auf den irgendjemand Anspruch erhoben hat oder erheben kann, sondern bezeichnet einfach nur eine Datei mit Text drinnen. Alles andere ist kontextabhängig. Programmierer denken an Reintext. Büroleute an OpenDocument. Informatiklehrer, die vom Staat bezahlt werden, denken erstmal an Extensible Markup Language. --~2026-33102-54 (Diskussion) 12:23, 15. Jun. 2026 (CEST)

Plain text kann ein Teil einer Datei sein, oder ein Datenbereich im RAM, der von einem Programm gerade bearbeitet und/oder gespeichert wurde/wird. Z.B. kann die Passworteingabe zum Entschlüsseln von Daten als plain text (Reintext) gespeichert werden. Das ist aber keine Textdatei.

Auch gibt es kodierte "Textdateien", die keine Textdateien im ursprünglichen Sinn sind. Beispiel: eine E-Mail-Datei, die Base64-Kodierung enthält. Diese kann man mit einem Texteditor öffnen, ja sogar bearbeiten, aber das ganze ist für den Menschen nicht als Text lesbar -- es ist kodiert. Und damit keine Textdatei. Im programmiertechnischen Sinn ist es jedoch eine Textdatei -- nur sind diese "Textdaten" (plain text) nicht vom Menschen interpretierbar.

Die Unschärfe gibt es: Word-Dateien sind unter DOS früher als Textdateien wahrgenommen worden, obwohl sie im programmiertechnischen Sinn Binärdateien sind. Genauso wenig werden programmiertechnische Textdateien, die eine Markup Language enthalten, nicht als Textdateien angesehen, weil ihr Zweck die maschinelle Verarbeitung ist.

Also. Nein, stimme nicht zu.

Das ganze lässt sich aber sehr schnell lösen. Alles, was hier steht, ist nämlich sinnfrei ohne WP:BLG. Ein Beleg muss als Basis dienen, nur so kann man den Artikel kritisieren und schließlich verbessern oder korrigieren. Ohne ist es nur Schwurbelei.

Auf ein Wiedersehen. ‣Andreas•⚖ 14:15, 15. Jun. 2026 (CEST)

> Plain text kann ein Teil einer Datei sein, oder ein Datenbereich im RAM

Korrekt. Aber eine Plain-Text-Datei ist eine Datei, die Plain-Text enthält.

> Auch gibt es kodierte "Textdateien", die keine Textdateien im ursprünglichen Sinn sind.

Steht auch im Plain Text Artikel. Also wenn er mal gesichtet wird.

> Word-Dateien sind unter DOS früher als Textdateien wahrgenommen

Für normale Menschen ist es eine Textdatei. Will aber nicht dafür oder dagegen argumentieren. Es ist mir nicht wichtig und ich habe das in meinen Änderungen auch nicht behauptet. --~2026-35044-78 (Diskussion) 14:34, 15. Jun. 2026 (CEST)

Nochmal: Plain text ist keine Datei. Dass eine Textdatei im Regelfall lesbare Zeichen enthält, ist auch klar.

Für normale Menschen ist was eine Textdatei? Eine Word-Datei?

Kein Problem, bitte bring eine Quelle gem. WP:BLG.

‣Andreas•⚖ 14:45, 15. Jun. 2026 (CEST)

https://www.adobe.com/de/acrobat/resources/document-files/open-doc.html

„Das OpenDocument Format, auch ODF abgekürzt, ist ein offenes Dateiformat für Office Dokumente wie Textdateien“

Hättest du auch in 2 Sekunden selber herausfinden können. --~2026-35044-78 (Diskussion) 14:53, 15. Jun. 2026 (CEST)

Abschnitt #Allgemeines:

Im Gegensatz zu dieser fachsprachlichen Definition des Begriffs Textdatei, bei der das Dateiformat ausschlaggebend ist, orientiert sich die umgangssprachliche Verwendung des Begriffs häufig primär am für den Endbenutzer sichtbaren Inhalt der Datei: Dabei werden etwas unscharf alle Dateien als „Textdatei“ bezeichnet, die mit dem Ziel erstellt wurden, einen lesbaren Text zu präsentieren, unabhängig davon, in welcher Form sie gespeichert werden.

Hättest du bei aufmerksamem Durchlesen selbst feststellen können.

‣Andreas•⚖ 15:27, 15. Jun. 2026 (CEST)

Wie ich gesagt habe. Es kommt auf den Zusammenhang an.

> Genauso wenig werden programmiertechnische Textdateien, die eine Markup Language enthalten, nicht als Textdateien angesehen, weil ihr Zweck die maschinelle Verarbeitung ist.

Auch hier kommt es auf den Zusammenhang an. Es kann sehr wohl als Textdatei betrachtet werden oder als Gegenstück dazu verwendet werden. --~2026-35044-78 (Diskussion) 15:45, 15. Jun. 2026 (CEST)

Und weiter? Was genau passt dir also nicht am Artikel, bitte mit Bestätigung (=Quelle)? ‣Andreas•⚖ 15:47, 15. Jun. 2026 (CEST)

Das paßt mir nicht am Artikel: „Es wäre sinnvoller einfach kurz und knapp zu erklären, was alles gemeint sein könnte und dann zB auf eine Liste an Textformaten zu verweisen, anstatt sie alle aufzuzählen und dann auch noch ausführlich zu beschreiben. Was soll irgendjemand diesem Artikei entnehmen?“ --~2026-35044-78 (Diskussion) 15:57, 15. Jun. 2026 (CEST)

Gib ein konkretes Beispiel, dann kann ich -- und andere Autoren -- dir besser folgen. Dass deine Beiträge in der Vergangenheit nicht verständlich waren, zeigt sich daran, dass sie zurückgesetzt werden. Also, was genau willst du warum ändern? ‣Andreas•⚖ 17:40, 15. Jun. 2026 (CEST)

Gemeint sein kann je nach Bezug:

- eine Datei, die nur reinen Text für Menschen enthält

- eine Datei, in einem auf reinem Text aufbauendem Format: Link auf Liste oder direkt aufzählen: JSON, CSV, DSV, TSV, HTML, XML, MathML, SVG, .ini/.conf, Markdown, Logs, Codedateien aller Programmiersprachen, Dateien von Buildsystemen, YAML, TOML, manche Dateiformate zur Speicherung einer Email von gewissen E-Mail-Clients ...

- Textdokumente von Textverarbeitungsprogrammen wie ODF (.odt), OOXML (.docx), und wie sie alle heißen.

Der Artikel sollte das widerspiegeln und nicht so ein Durcheinander präsentieren. --~2026-35130-02 (Diskussion) 21:05, 15. Jun. 2026 (CEST)

Gerne. Quelle bitte. ‣Andreas•⚖ 21:13, 15. Jun. 2026 (CEST)

Gerne. Aber für welche Behauptung genau? Sonst suche ich die falsche heraus und du bist unzufrieden. --~2026-35130-02 (Diskussion) 21:14, 15. Jun. 2026 (CEST)

https://developer.mozilla.org/de/docs/Learn_web_development/Core/Scripting/JSON

„Ein JSON-String kann in einer eigenen Datei gespeichert werden, die im Grunde genommen nur eine Textdatei mit der Erweiterung .json und einem MIME-Typ von application/json ist.“ --~2026-35130-02 (Diskussion) 21:24, 15. Jun. 2026 (CEST)

Das widerspricht dem aktuellen Inhalt des Artikels nicht.

Einen Beleg brauchst du für die Definition, was eine Textdatei deiner Meinung nach sei, ich zitiere:

- eine Datei, die nur reinen Text für Menschen enthält

- eine Datei, in einem auf reinem Text aufbauendem Format: Link auf Liste oder direkt aufzählen: JSON, CSV, DSV, TSV, HTML, XML, MathML, SVG, .ini/.conf, Markdown, Logs, Codedateien aller Programmiersprachen, Dateien von Buildsystemen, YAML, TOML, manche Dateiformate zur Speicherung einer Email von gewissen E-Mail-Clients ...

- Textdokumente von Textverarbeitungsprogrammen wie ODF (.odt), OOXML (.docx), und wie sie alle heißen.

Ich habe keine solche Definition von Textdatei finden können. Diese schließt auch alles, was nicht gelistet ist, aus, weil dies Definitionen nun einmal so an sich haben. Und das ist eindeutig falsch.

In diversen Büchern über das Programmieren kann sich der Entwickler dafür entscheiden, Daten in entweder Binärdateien oder Textdateien zu speichern, oder auch gemischt in Binärdateien mit Bereichen, die "plain text" enthalten (was dann insgesamt aber Binärdateien sind). Entscheidet sich der Entwickler für eine Textdatei, muss er z.B. einen Integer-Wert 123 statt in einen Byte (char, 1 Byte; oder bei 16-Bit-Interger eben in zwei Bytes) in eine Binärdatei als ASCII (oder einer anderer Kodierung) mit 3 Bytes in eine Textdatei speichern, nämlich als '1' '2' '3', binär dargestellt:

Binärdatei: 01111011, ergibt ASCII: {

Textdatei: 00110001 00110010 00110011, ergibt ASCII: 123

Textdatei vs. Binärdatei sagt erstmal nur aus, dass der Inhalt menschenlesbar ist und nur Text/Zahlen sowie bestimmte Steuerzeichen (Newline) enthält, es gibt jedoch keine exklusive Liste dazu, was Textdateien wären. Vorallem "eine Datei, die nur keinen Text für Menschen enthält" ist extrem irreführend, wenn die Daten doch eigentlich für ein Programm sind, und der Mensch diese Datei möglichst in Ruhe lassen soll. Was soll das überhaupt heißen, "für Menschen"? Das heißt, ein Programm einer Katzenklappe, in dem eine Konfigurationsdatei als Textdatei abgelegt ist, die über ein UI konfiguriert wird (der Benutzer die Textdatei als am besten in Ruhe lässt), ist nicht für den Menschen, sondern für das Haustier -- für die Katze...

Nein, du betreibst hier WP:TF. Bitte recherchiere zuerst, dann wirst du feststellen, dass deine eigene persönliche klare Definition von dem, was du unter einer Textdatei verstehst, keineswegs belegt ist, und daher auch nicht zu 100% stimmt. In der Praxis macht das vielleicht nichts aus, weil es in 99% der Fälle, die dir in deinem Leben begegnen, zutrifft, deswegen ist es jedoch nicht automatisch richtig. Außerdem kann es ja sein, dass es für andere, die in anderen Bereichen auf Textdateien treffen, nicht mehr zu 99% stimmt...

Also, bitte, bleiben wir 1. bei Recherche, 2. bringen wir Belege, und ändern dann damit 3. den Artikel.

‣Andreas•⚖ 21:50, 15. Jun. 2026 (CEST)

Ach so. Du hängst dich immer noch daran auf. Wenn Textdateien von Textverarbeitungsprogrammen nicht zur IT gehören, wozu dann? Ich kann sie ja schlecht aus dem Computer herausholen und sie auf den Tisch stellen. Sie existieren nur digital und sie sind Dateien mit Text und der aktuelle Artikel erwähnt sie auch. --~2026-35130-02 (Diskussion) 21:56, 15. Jun. 2026 (CEST)

https://www.dwds.de/wb/Textdatei

Hier ist eine gute Quelle. --~2026-35130-02 (Diskussion) 21:59, 15. Jun. 2026 (CEST)

Okay, dem halte ich entgegen Dateiformate einfach erklärt: Unterschied zwischen Textdateien und Binärdateien: Übersicht der wichtigsten binären Dateiarten ... Sonstige proprietäre Binärformate • Dokumentenformate (Office)

Außerdem: DOC vs. DOCX: Unterschiede und Möglichkeiten der Konvertierung 1. DOC-Dateien sind ein proprietäres Binärformat. 2. DOCX-Dateien sind zwar im Grunde strukturierte XML-Daten, aber im Grunde sind es ZIP-Dateien. Was sind ZIP-Dateien? Genau: Binärdateien. Zitat: DOCX ... verwendet das XML-basierte Dateiformat, das die Dokumentdaten in einer strukturierteren und interoperablen Weise organisiert. ... DOCX speichert das Dokument in einem offenen XML-Format, das anschließend in einem komprimierten Zip-Format archiviert wird.

Textdokumente wie DOCX sind daher keine Textdateien.

‣Andreas•⚖ 22:12, 15. Jun. 2026 (CEST)

Sowohl, doc als auch docx und odt-Dateien sind allesamt Binärdateien. Daß darin in einer ZIP mehrere XML-Dateien schlummern, spielt keine Rolle. Sie sind deshalb Textdateien, weil das Wort mehrere Bedeutungen hat. Sie enthalten den Text, den der Nutzer der Textverarbeitungssoftware sieht und bearbeitet. Da ist kein Widerspruch. Es gibt ein Schloß in deiner Haustür, ein Schloß, das ein Gebäude ist und ein Vorhängeschloß. Das sind alles sehr verschiedene Dinge, aber trotzdem ist jedes ein Schloß in seinem Sinnzusammenhang.

Sie können also in einem Zusammenhang keine Textdateien sein und in einem anderen Zusammenhang sehr wohl. Also beides gleichzeitig. Du liegst nicht falsch, aber auch nicht richtig. --~2026-35130-02 (Diskussion) 22:18, 15. Jun. 2026 (CEST)

Deine Unterbedeutung schreibt der DWDS sogar „reinem Text“ (plain text) zu. Da steht: „mit Adjektivattribut: eine reine Textdatei“ --~2026-35130-02 (Diskussion) 22:31, 15. Jun. 2026 (CEST)

Das steht im Abschnitt #Allgemeines genau so da (Hervorhebung von mir):

Im Gegensatz zu dieser fachsprachlichen Definition des Begriffs Textdatei, bei der das Dateiformat ausschlaggebend ist, orientiert sich die umgangssprachliche Verwendung des Begriffs häufig primär am für den Endbenutzer sichtbaren Inhalt der Datei: Dabei werden etwas unscharf alle Dateien als „Textdatei“ bezeichnet, die mit dem Ziel erstellt wurden, einen lesbaren Text zu präsentieren, unabhängig davon, in welcher Form sie gespeichert werden. Bei den von üblicher Textverarbeitungs- oder Publishingsoftware bei Speicherung erzeugten Dateien handelt es sich jedoch häufig um komplexe Dateiformate, die neben dem Text Metainformation zur Beschreibung des Textlayouts, der Struktur und der verwendeten Schriften enthalten; zudem können Bilder oder Grafiken eingebettet sein. Deshalb handelt es sich um keine Textdateien im fachsprachlichen Sinn, da die Dateiformate häufig binär sind und zur Anzeige eine spezielle Software erforderlich ist.

In der IT ist eine Textdatei jedoch eine Datei, die ... siehe Einleitung des Artikels.

‣Andreas•⚖ 22:36, 15. Jun. 2026 (CEST)

Nachtrag: darum heißt es meist auch "Textdokument" statt Textdatei. ‣Andreas•⚖ 22:38, 15. Jun. 2026 (CEST)

Stimmt. Aber es geht auch anders herum. Eine LICENSE.txt-Datei ist ein rechtlich verbindliches Textdokument.

Es gibt Zahlenschlösser für Fahrräder und Zahlenschlösser für Tresore. Kannst ja mal drüber schlafen.

Übrigens muß die Textdatei nicht lesbar sein. Eine Datei die nur Base64 enthält könnte durchaus vom Betriebssystem oder einem Identifikationsprogramm in der Benutzeroberfläche als Textdatei identifiziert werden. Es stimmt ja auch. Es ist ASCII drinnen. Text. Manch Programm könnte es sogar als reinen Text ausweisen. Der Benutzer würde trotzdem sagen, das kann er nicht lesen und vielleicht sogar, daß es kein Text ist. Beide haben Recht. Eine Textdatei ist eine Datei mit Text. Laut Unicodestandard ist alles „gültige UTF-8“ Text. Auch BEL. Ein Zeichen, das früher nicht dargestellt wurde und in einigen Anwendungen einen Signalton auslöst. Die IT-Definition von Text ist auch ziemlich lose. „Reiner Text“ schließt aber nicht lesbare zeichen meist implizit aus. Der Unicodestandard zählt zu „plain text“ noch einige Control Codes hinzu, die ich nicht hinzuzählen würde, aber im Grunde sagt er, daß plain text lesbare Zeichen verwendet. --~2026-35130-02 (Diskussion) 22:46, 15. Jun. 2026 (CEST)

Du vermischt Inhalt und Datei. Die Datei ist das Gefäß, nicht der Inhalt. Die LICENSE.txt ist eine Textdatei, die ein Textdokument enthält, weil der Lizenztext ein Dokument ist. Base64 ist nicht wirklich menschenlesbar, weil es aber in Text kodiert ist (das macht Base64 ja gerade aus), ist es eben, wenn man es in eine Datei speichert, dann eine Textdatei. Das findet man z.B. bei .eml-Dateien, also E-Mails, wenn ein E-Mail-Client diese Art von Dateien überhaupt noch unterstützt (Mozilla Thunderbird tut es, Outlook nicht). E-Mails in .eml-Dateien sind im Grundsatz menschenlesbar, obwohl Teile davon kodiert sind (Base64). Anders OOXML: diese ZIP-Dateien beinhalten zwar XML-Daten (die Dokumentstruktur), aber auch Binärdaten (ein eingebettetes JPEG-Bild als Binärdatei). Dabei könnte man das JPEG-Bild ja ebenfalls Base64-kodieren... Aber wozu? Das resultierende Format ist ohnehin binär, weil gezippt.

Was du schreibst, ist alles sehr interessant, aber eben nicht für den Artikel, und auch nicht belegbar... Sorry. ‣Andreas•⚖ 22:59, 15. Jun. 2026 (CEST)

Eine Datei ist ein benannter Satz von Bytes; das Dateiformat legt fest, wie diese Bytes zu interpretieren sind. Deshalb ist es nicht korrekt, die Datei als rein passives „Gefäß“ abzutun. Das Format in der Datei ist entscheidend. Es spielt auch keine Rolle, ob die Datei überhaupt auf einem dauerhaftem Speichermedium ist. Streng genommen ist ein Dateiformat ein Datenformat. Die HTML in deinem Browser ist nicht zwangsläufig auf deiner SSD gespeichert.

Namensendungen mit Punkt sind auch nur eine Windowskonvention. Dort entscheiden sie auch nur, was passiert, wenn du draufklickst. Wenn ein Programm sie tatsächlich öffnet, richtet es sich gewöhnlich nach dem Inhalt.

Base64 ist ein Text‑Encoding für Binärdaten. Technisch ist Base64 eine binär‑zu‑text‑Kodierung, die Binärdaten in einem druckbaren ASCII‑Alphabet abbildet. Die Ausgabe ist Textzeichen, aber ohne Dekodierung bleibt der Inhalt semantisch unverständlich.

„Dabei könnte man das JPEG-Bild ja ebenfalls Base64-kodieren“

Dann ist es eine Textdatei. Aber keine reine Textdatei. Siehe DWDS.

„Anders OOXML: diese ZIP-Dateien“

ZIP-Dateien sind Binärdateien. Streitet keiner ab. Es kommt hat auf den Kontext an, ob Textdatei im Gegensatz zu Binärdatei steht oder nicht. --~2026-35130-02 (Diskussion) 23:25, 15. Jun. 2026 (CEST)

Und wie willst du, derart darüber nachgedacht, den Artikel verbessern? Mit dem darüber Nachdenken allein geht das nicht. Du brauchst Quellen. Wenn du nun Fachbücher über Dateien (IT-Bereich) und Textdateien (IT-Bereich) suchst, wirst du finden, dass es immer auf Textdatei versus Binärdatei hinausläuft. Daher:

Als Textdatei wird in der Informationstechnik eine Datei bezeichnet, und so weiter...

Weil von Anwendern der IT aber oft unscharf eine Textdatei "im Wörds" aufgemacht wird, das sie "im Microsoft" verwenden, wird hier im Abschnitt Allgemeines auch darauf eingegangen, weil die Wikipedia immer versucht, umfassend zu informieren. Wir wollen aber nicht uninformieren.

‣Andreas•⚖ 07:48, 16. Jun. 2026 (CEST)

Wie ein anderer schon geschrieben hat: Bezug zur Realität --~2026-35394-87 (Diskussion) 13:35, 16. Jun. 2026 (CEST)

Der Bezug zur Realität sind die Fachbücher, die den Artikelgegenstand betreffen und vom Artikel referenziert werden (WP:BLG). Sich eine Realität ausdenken, die nirgends abgebildet ist (außer in unseren Köpfen), entspricht nicht den Kriterien der Wikipedia. ‣Andreas•⚖ 16:00, 16. Jun. 2026 (CEST)

„Der Bezug zur Realität sind die Fachbücher“

Sind sie nicht. Es gibt dafür auch ein Wort. Fachi... Ich sags lieber nicht. --~2026-35394-87 (Diskussion) 17:47, 16. Jun. 2026 (CEST)

Falls sich irgendjemand wundert. Das Wort war Fachinformatiker und ganz bestimmt nicht irgendetwas anderes. --~2026-35394-87 (Diskussion) 17:48, 16. Jun. 2026 (CEST)

Alle Theoriefindungsvorwürfe streite ich ab. Ich kann alles gut belegen und ich finde das überheblich. --~2026-35130-02 (Diskussion) 22:04, 15. Jun. 2026 (CEST)

Kein Problem. Ich hätte gerne bessere Belege. Ich halte gerne dagegen. ‣Andreas•⚖ 22:12, 15. Jun. 2026 (CEST)

Es ist müßig hier weiter zu diskutieren. Machen wir es doch bitte umgekehrt: zitiere zuerst eine Quelle gem. WP:BLG und bringe dann, damit, deinen Änderungswunsch mit ein. Nicht umgekehrt. Quellen zu suchen für das, was du glaubst, da macht wohl kein anderer mit. Das musst du schon selbst erledigen. ‣Andreas•⚖ 14:47, 15. Jun. 2026 (CEST)

Hab ich jetzt gemacht --~2026-35044-78 (Diskussion) 14:55, 15. Jun. 2026 (CEST)

Das stand bereits im Artikel. ‣Andreas•⚖ 15:27, 15. Jun. 2026 (CEST)

An Y2kbug

Meine Kürzungen entsprechen Wikipedia:Wie_schreibe_ich_gute_Artikel#Artikelumfang_und_Verweise

Die Abschnitte enthalten, wie du selbst bereits festgestellt hast, Ungenauigkeiten.

Wie ich geschrieben habe, sind die Themen zu komplex, um sie in jedem leicht verwandten Artikel nochmal fehlerfrei in ganzer Länge zu beschreiben.

Ich widerspreche überhaupt nicht, daß die Inhalte nützlich sind. Nur stehen sie eben schon in den Hauptartikeln. --~2026-35044-78 (Diskussion) 15:15, 15. Jun. 2026 (CEST)

Die Ungenauigkeiten ergeben sich aus der Materie. Die Wikipedia soll das abbilden, was es gibt. Wenn der Artikelgegenstand, das Lemma, selbst ungenau ist, ist das auch im Artikel so vorzufinden.

Kürzungen sind immer möglich, sollten aber gut begründet sein und nicht ohne die Hauptautoren durchgeführt werden. Die haben sich nämlich wirklich Mühe gegeben, den Artikel so zu erstellen, dass er all das beinhaltet, was die Autoren bei ihrer Recherche zum Thema finden konnten. Du solltest mehr als nur WP:GA angeben, wenn du größere Teile inklusive deren Belegangaben entfernst und durch unbelegte Teile, die ebenfalls der Kritik unterworfen sind, ersetzt.

Genau dafür sind die Diskussionsseiten da (WP:DISK). Das funktioniert aber nur, wenn du hier konkret deine Kürzung vorstellst, und begründest.

‣Andreas•⚖ 15:31, 15. Jun. 2026 (CEST)

Das Wort Textdatei ist nachweislich ungenau. Steht im Artikel selber mit zwei Belegen. „Jedoch ist insbesondere auch durch die vielfältige Verwendung von Textdateien der Begriff selbst unzweckmäßiger und unschärfer geworden.“

Weil der Begriff ungenau ist, sollte der Artikel nicht allzu lang und irreführend sein, sondern auf die Verschiedenen genaueren Bedeutungen, die er im Zusammenhang haben kann, hinweisen. --~2026-35044-78 (Diskussion) 15:38, 15. Jun. 2026 (CEST)

Der Artikel behandelt in erster Linie die Textdatei im Fach der IT, wie den Begriff Profis verstehen. Dass die Allgemeinheit das nicht so genau nimmt, steht drin, ändert aber nichts an der fachlichen Richtigkeit dessen, was hier beschrieben steht. Ist das nicht der Zweck, dass man sich hier informieren kann, was die Fachwelt hinter dem Begriff versteht? ‣Andreas•⚖ 15:41, 15. Jun. 2026 (CEST)

Als Profi kann ich dir sagen, daß der Begriff ungenau ist. Wenn ich eine Plaintextdatei genau beschreiben wollte, würde ich sagen: Die Datei ist UTF-8, kein BOM, LF-Zeilenende. Dann weiß ich und jeder andere genau, was drinnen ist. --~2026-35044-78 (Diskussion) 15:48, 15. Jun. 2026 (CEST)

Hey, cool, dann ist der Artikel ja gut gemacht. ‣Andreas•⚖ 17:34, 15. Jun. 2026 (CEST)

Ja, eben nicht. Ein ungenauer Begriff verdient einen kurzen Artikel mit Deutungshilfe. Nicht so einen Quatsch wie:

„Bei Unicode existiert zudem die Konvention, am Beginn einer Datei mittels spezieller Bytefolgen (sogenannte Byte Order Marks) kenntlich zu machen, welche Unicode-Codierung verwendet wird. Dies ist auch deshalb nötig, da auf vielen Systemen – auch unter Windows – die bisherige auf ASCII basierende Codierung und Unicode parallel verwendet werden. Bei einer solchen Codierung beginnt die Grenze zur Binärdatei zu verschwimmen.“

Das liest sich so, als würde es UTF-8 BOM anpreisen, was, wie ich im BOM-Artikel erläutert habe, genau das Gegenteil von dem ist, was der Unicodestandard möchte. BOM muß bei UTF-16 zur Bytereihenfolge herhalten und bei UTF-8 ist es im Grunde eine Todsünde.

Ich habe mir da schon Gedanken gemacht und das alles gelesen, bevor ich Änderungen vorgenommen habe. --~2026-35130-02 (Diskussion) 18:40, 15. Jun. 2026 (CEST)

Das ist alles sehr nett, aber kannst du das bitte mit Literatur hinterlegen? Denn wenn jeder hier das schriebe, worüber er sich Gedanken gemacht hat, dann ist Wikipedia ein WP:Theoriefindungsportal -- und genau das wollen wir nicht.

Worum geht es hier? Um Textdateien. Ob BOM eine Todsünde ist oder nicht, ändert wohl nicht den Fakt, dass UTF ob seiner Mehr-Byte- (man könnte auch "mehr-Wort"-, weil früher mal waren es "Words", also Worte, nicht Bytes) -Kodierung alleine zu ungenau ist, da es ja Least Significant vs. Most Significant First gibt. Dieses Problem ist im Artikel Unicode zu erörtern. UTF-16LE vs. UTF16-BE würde den Artikel sprengen, da gebe ich dir recht, aber es geht hier um Textdateien und alles, was man da vorfindet. Was findet man vor? ASCII. ISO 8859-1(5). EBCDIC. Und eben auch Unicode, und mit letzterem auch BOM.

‣Andreas•⚖ 19:29, 15. Jun. 2026 (CEST)

Hab ich bereits auf der BOM-Seite. https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-23/#G19635 --~2026-35130-02 (Diskussion) 19:46, 15. Jun. 2026 (CEST)

UTF-16 ist heute auch veraltet. Keiner baut absichtlich Anwendungen mehr, die UTF-16 benutzen und nicht gezwungen sind mit irgendeiner veralteten API zu arbeiten.

„Was findet man vor?“

Hauptsächlich UTF-8. iirc sind über 98% aller Webseiten jetzt UTF-8. BOM-Marken sind dabei selten. Beim Zeilenende muß man noch eine Münze werfen, ob es LF oder CRLF ist. CR ist seit 25 Jahren tot und trifft man auch nicht mehr an. JEDES Nicht-Microsoft-Produkt heute verwendet LF. IBM Power verwendet auch UTF-8 und LF. --~2026-35130-02 (Diskussion) 19:52, 15. Jun. 2026 (CEST)

Belege? ‣Andreas•⚖ 20:04, 15. Jun. 2026 (CEST)

Zu was genau? Das mit den 99% ist zum Beispiel auf der englischen Wikipedia belegt. en:UTF-8 https://w3techs.com/technologies/cross/character_encoding/ranking --~2026-35130-02 (Diskussion) 20:11, 15. Jun. 2026 (CEST)

Über 99% der Menschen sind keine Nobelpreisträger. Was willst du damit belegen? ‣Andreas•⚖ 20:22, 15. Jun. 2026 (CEST)

Nobelpreisträger haben scheinbar auch keine Ahnung von Textkodierungen und keine leicht findbaren Aussagen darüber in den letzten 40 Jahren gemacht. --~2026-35130-02 (Diskussion) 20:28, 15. Jun. 2026 (CEST)

?!?!? ‣Andreas•⚖ 20:30, 15. Jun. 2026 (CEST)

Deine Behauptung „Die gesamte Linux- bzw. Unix-Welt setzt auf UTF-8, während Windows auf UTF-16 setzt (bzw. ursprünglich auf UCS-2 setzte, dem Vorläufer von UTF-16)“ ist auch nicht ganz korrekt. Auch deine Smartwatch, Playstation, Nintendo Switch, Display im Auto benutzt vorwiegend UTF-8 und LF-Zeilenumbruch in Dateien, selbst wenn sie Qt verwenden und intern wegen dem veralteten Unterbau UTF-16 benutzen. Da wird halt hin- und herkonvertiert, aber die Dateien sind UTF-8.

Microsoft bevorzugt heute für Dateien ebenfalls UTF-8 und nicht erst seit gestern. Office Open XML gibt es seit 2006 und MS Office schrieb ausschließlich UTF-8 in die gezippten XML-Dateien. Immer mehr "A" Windows-APIs unterstützen zudem UTF-8. Vorher wurden sie für ANSI Codepages verwendet. Windows 8 oder so hat CP_UTF8 hinzugefügt und nun kann man die Aufgabe der Konvertierung dem System überlassen, anstatt in jeden Programm UTF-16 Zeug einzubauen. Die Unterstützung hat sich in den letzten Versionen deutlich gebessert. --~2026-35130-02 (Diskussion) 21:53, 15. Jun. 2026 (CEST)

Die Smartwatch, Playstation, Nintendo usw. sind meist Unix-basiert, und daher nutzen sie heute UTF-8 (früher z.B. ISO 8859-1).

Der entscheidende Punkt ist aber ein ganz anderer: hier auf WP:DISK kann ich schreiben, was ich will, auch jeden Blödsinn. Das muss nicht belegt sein. Aber in den Artikel darf es so nicht, denn dafür muss es eben belegt sein.

Hier tauschen sich die Autoren auch gerne mal über (missverstandene) Zitate aus Belegen aus, und streiten darüber, wie man das korrekt formuliert. Das kann durchaus eine so Winzigkleinigkeit wie ein "und" oder ein "oder" sein, oder ein Beistrich. Zur Auslegung muss dann ein Konsens entstehen, damit das in den Artikel kann. Und das ist natürlich nicht in Stein gemeißelt: wenn sich eine erneute Diskussion ergibt, die die Formulierung (die Information) als eindeutig falsch identifiziert, wird es korrigiert. Und das ist auch gut so. Aber eines Vorbringens von Belegen bedarf es immer, wobei die Belegpflicht bei dem liegt, der die Änderung will. Also in diesem Fall: du. ‣Andreas•⚖ 22:01, 15. Jun. 2026 (CEST)

Ich hab gar nicht behauptet, daß alles was ich schreibe in den Artikel muß. Im Gegenteil. Es muß weniger in den Artikel. Ich habe die drei Möglichkeiten für die Bedeutung von Textdatei gut beschrieben und belegt. Du hast gar keine Belege erbracht und weichst jeglichen Argumenten mit WP: verweisen aus. Wie ich schon geschrieben habe, ist der Artikel nicht gut belegt und die Buchbelege sind ziemlich nutzlos, selbst wenn sie stimmen. Zu diesem Thema haben große Unternehmen, bekannte Programmierer und Normungsinstitute viel geschrieben. --~2026-33102-54 (Diskussion) 07:47, 16. Jun. 2026 (CEST)

Wenn man einen guten, umfassenden Texteditor wie Notepad++ verwendet, kommen einem allerlei Dinge unter, die ein Artikel über Textdateien erklären sollte. Die Geschichte dahinter einzuarbeiten, macht auch Sinn.

Wenn es dir wirklich ernst ist, dann arbeite hier auf der Diskussionsseite heraus, warum du was in was kürzt, argumentativ untermauert und mit der Möglichkeit, dass alle Mitautoren darauf reagieren können. Diese haben nämlich all die Informationen eingearbeitet, weil es ihnen als wichtig erschien, weil sie es selbst wissen wollten, was es damit aufsich hat. Kürzen des Kürzens willen finde ich keine gute Idee. ‣Andreas•⚖ 07:53, 16. Jun. 2026 (CEST)

Außerdem hast du Unrecht. Siehe AROS und Haiku. Beide keine Unixderivate oder Unixlikes. Nutzen UTF-8 und LF. Du hast einfach keine Ahnung Mann. Windows unterstützt LF auch in immer mehr APIs und Systekanwendungen. zB in Powershell. --~2026-33102-54 (Diskussion) 07:55, 16. Jun. 2026 (CEST)

Haiku ist ein BeOS-Klon. BeOS:

#Geschichte: Noch 1997 konnte man auf der Website von Be lesen, dass BeOS als Betriebssystem entwickelt wurde, welches den alten Ballast abschüttelt und das beste aus der Welt von Unix, Mac OS und AmigaOS aufgreift...

BeOS hat viele Konzepte von Unix übernommen, man sollte sich aber gewahr sein, dass 1997 Unicode unter Unix noch nicht sehr weit verbreitet war. Dennoch, die Entscheidung für UTF-8, wie sie in der Unix-Welt getroffen wurde, hat BeOS bzw. OpenBeOS und Haiku vermutlich übernommen.

Dass beim Amiga dieselbe Entscheidung getroffen wurde, ist kein Argument dagegen.

Lustig finde ich in dem Zusammenhang, dass du auf der einen Seite mit "99% der Welt nutzt Windows, und da ist es so und nicht anders" argumentierst, andererseits dann aber absolute Nischen wie BeOS und AmigaOS aufgreifst.

Was Unix betrifft: viele Betriebssysteme sind von Unix stark beeinflusst, darunter MS-DOS ab Version 2.0 und natürlich BeOS. Bei AmigaOS kenne ich mich zu wenig aus.

Was den Artikel Textdatei betrifft, so sollten zumindest die Unterschiedlichkeiten Erwähnung finden. Deshalb haben wir im Abschnitt #Kennzeichnung des Zeilenendes eine exemplarische Auflistung, was es gibt und wo es in etwa genutzt wird. Würde klassisches Mac OS dasselbe verwenden wie andere System wäre wohl dessen Erwähnung nicht notwendig gewesen. Da es aber das einzige System ist, dass es genau umgekehrt wie Unix macht, ist die Erwähnung sinnvoll. Das Thema ist ja gerade "Textdatei", und das macht einen wesentlichen Unterschied.

Dass Windows endlich LF unterstützt, hat vermutlich mehrere Gründe, Microsoft hat sich diesbezüglich aber ganz schön lange geziert. Ich weiß also nicht, was das mit Textdatei zu tun hat. Wenn, dann hat es mit Windows zu tun, der Windows-API, oder von mir aus mit dem Windows Editor. Oh, warte, da steht ja was...

Editor (Windows)#Zeichenkodierungen und Zeilenendungen: Das Programm konnte bis Windows 10 1803 nur mit windowsspezifischen Zeilenendungen (CRLF) umgehen, seither kann der Editor auch mit CR (Mac OS Classic) und LF (Unix) umgehen.

‣Andreas•⚖ 09:23, 16. Jun. 2026 (CEST)

Das ganze Gelaber über Unix ist ziemlicher Schmarrn. BSD ist Unix und alle anderen Systeme sind genau gleichermaßen "unixartig". Einschließlich Windows.

„Microsoft hat sich diesbezüglich aber ganz schön lange geziert“

Nicht wirklich. Die C-Programmiersprache hat Zeilenkonvertierung bei Textdateien schon unterstützt. Mit Windows Vista (2006) kam vernünftige Unicodeunterstützung und Unterstützung für LF als Zeilenumbruch in der neuen WPF UI. Win32 kann nicht mehr geändert werden. Alle neueren UIs seitdem auch. Das schlimmste war halt notepad.exe, woran MS nichts geändert hat. Wurde halt seit Windows 1.0 nur portiert und ist hauptsächlich ein Wrapper um das Win32-Textbearbeitungsfeld, welches von vielen Anwendungen benutzt wird und sich nicht verändern darf. Man müßte also einen komplett neuen Editor schreiben und das hat Microsoft ewig aufgeschoben, aber letztendlich gemacht. --~2026-33102-54 (Diskussion) 11:52, 16. Jun. 2026 (CEST)

Ehrlich gesagt kann ich dir nicht genau sagen, wieso Microsoft im Editor die C-Zeilenkonvertierung umging. WordPad hat sein Windows 95 LF-Zeilenumbrüche konvertiert und dann richtig dargestellt. --~2026-35394-87 (Diskussion) 13:38, 16. Jun. 2026 (CEST)

Wenn du unter Windows eine Textdatei speicherst, hat sie eine gewisse Form. Und die ist hier beschreiben. Das ist die Konvention. Dass es in bestimmten Fachbereichen, etwa der Programmierung, anders aussieht, ist nicht repräsentativ für die Konvention des Betriebssystems. Dass Notepad unter Windows selbst beim Öffnen die Darstellung nie hinbekommen hat (bis 2019),war nur die Krönung dieser Konvention. Unter Unix muss man Dateien mit CRLF u.U. auch zuerst umwandeln, damit die Darstellung nicht fehlerhaft ist. Das ist kein Schmarrn, sondern das, was den Artikelgegenstand direkt betrifft: Textdateien. ‣Andreas•⚖ 16:03, 16. Jun. 2026 (CEST)

Keine Ahnung wo du dein Unix hernimmst, aber die CRLF-Darstellung war auf Linux in zB. gedit vor 20 Jahren super supi. Angeblich auch schon zu Release 1999 LG --~2026-35394-87 (Diskussion) 16:47, 16. Jun. 2026 (CEST)

Beleg?

Ich kann dir sagen, dass das CR-Zeichen bei jedem Zeilenende im Editor zu sehen ist. Die Darstellung funktioniert mit less, ja, aber nicht jedes Programm kann mit CRLF umgehen, wenn es LF erwartet. Beispiel? Resolving Windows Line Endings (CRLF) Issues in Shell Scripts – /bin/bash^M: no such file or directory

Also echt jetzt. Mir wird diese Diskussion nun zu müßig. Trag was zum Artikelgegenstand bei -- "Textdatei" -- und liefere Quellen, bleib bei der Sache, oder bitte geh einfach.

‣Andreas•⚖ 17:13, 16. Jun. 2026 (CEST)

Jeder Editor ist also in deiner Welt ein TUI-Programm in einem Terminalemulator? --~2026-35394-87 (Diskussion) 17:18, 16. Jun. 2026 (CEST)

Was ist mit dir?

1. Kommt auf den Editor an, aber die guten zeigen ^M am Zeilenende an. Unter Windows tun sie das nicht, ist ja dort als CRLF das Zeilenende, unter Unix ist CR eben als ^M dargestellt. Oder: Ich kann dir sagen, dass das CR-Zeichen bei jedem Zeilenende im Editor zu sehen ist.

2. Nicht jedes Unix-Programm kann damit so gut umgehen (wie ein Editor, oder wie less). Es gibt Programme auf dem jeweiligen Betriebssystem, die damit ein Problem haben, wenn eine Textdatei (wie unter Windows z.B. die AUTOEXEC.BAT, oder unter Unix ein Shellskript, aber auch so machen Konfigurationsdatei wie etwa INI-Dateien --> allesamt Textdateien) das falsche Zeilenende aufweist. Oder: Die Darstellung funktioniert mit less, ja, aber nicht jedes Programm kann mit CRLF umgehen, wenn es LF erwartet.

3. Als gutes Beispiel: Shellskripte.

Bitte versuch wenigstens sinnerfassend zu lesen, gehe von guten Absichten aus und sei konstruktiv. Wenn du nur die Konfrontation suchst, den Artikel aber gar nicht wirklich verbessern willst, ist hier für mich EOD. Auf wiedersehen. ‣Andreas•⚖ 17:23, 16. Jun. 2026 (CEST)

„aber die guten zeigen ^M am Zeilenende an.“

Ja, aben nicht. gedit (gui) tat es nicht. emacs (tui) tat es nicht. Dein Editor ist kacke, wenn er ^M zeigt. Außer es handelt sich um Dateien mit gemischten Zeilenenden (verschiedene Konventionen in der selben Datei), die generell überall als Problemfall betrachtet werden. --~2026-35394-87 (Diskussion) 17:26, 16. Jun. 2026 (CEST)

Dein Editor ist kacke, wenn ein Skript nach dem Speichern nicht mehr funktioniert. Oder wenn die Datei eines anderen Systems nach dem Speichern dort nicht mehr funktioniert. So oder so, genau aus diesem Grund ist die unterschiedliche Konvention im Artikel Textdatei gut aufgehoben. Der ganze Abschnitt passt so detailliert, wie er ist.

Wenn du eine Sache hier und jetzt bestätigt hast, dann die Güte des Artikels, und dass eine Kürzung wirklich eine schlechte Idee ist. Danke dafür.

EOD.

‣Andreas•⚖ 17:29, 16. Jun. 2026 (CEST)

„Dein Editor ist kacke, wenn ein Skript nach dem Speichern nicht mehr funktioniert.“

Das geschieht doch gar nicht. Im Gegensatz zu Microsoft, werden die Zeilenumbrüche nicht umgewandelt, sondern die Konvention wird automatisch erkannt und ist frei einstellbar und speichert in der erkannten oder eingestellten Weise. Die Zeilenumbrüche werden als Umbrüche in der Zeile dargestellt. So ist es auch vorgesehen. Jetzt wirst du aber echt fantasiereich mit deinen Anschuldigungen gegen deinen Fantasiefeind „Unix“, den du in jedem Betriebssystem siehst, das nicht Microsoft Windows heißt. --~2026-35394-87 (Diskussion) 17:37, 16. Jun. 2026 (CEST)

Übrigens unterstützt Emacs CRLF seit 1997 Version 2.0.1 https://www.whitman.edu/mathematics/emacs_doc/emacs_194.html#:~:text=For%20example%2C%20if%20the%20file,%2Dunix --~2026-35394-87 (Diskussion) 17:24, 16. Jun. 2026 (CEST)

Du hast also erkannt, dass Linux rund 20 Jahre früher dran war als Windows. Toll. Und wie verbessert das den Aritkel Textdatei? Sollte das nicht in den Artikel Emacs? ‣Andreas•⚖ 17:27, 16. Jun. 2026 (CEST)

Du hast geschrieben:

„Ich kann dir sagen, dass das CR-Zeichen bei jedem Zeilenende im Editor zu sehen ist. Die Darstellung funktioniert mit less, ja, aber nicht jedes Programm kann mit CRLF umgehen, wenn es LF erwartet.“

und behauptet man würde in Linuxprogrammen ein ^M bei Windows-Zeilenenden sehen. Das ist erstunken und erlogen. Und ich habe es belegt. --~2026-35394-87 (Diskussion) 17:40, 16. Jun. 2026 (CEST)

Das Entfernen der Belege bei den Kürzungen die ich durchgeführt habe entspricht Wikipedia:Belege „Entbehrlich sind Belege, wenn etabliertes Wissen wiedergegeben wird und auf der Hand liegt, wo man dieses nachlesen kann.“

Die gekürzten Stellen waren „Zeichenkodierung“ und „Zeilenumbruch“ --~2026-35044-78 (Diskussion) 16:05, 15. Jun. 2026 (CEST)

Die sollten aber nicht gekürzt werden. Anders als bei plain text ist dies ein Merkmal einer Textdatei, die ein wesentliches Merkmal darstellt und auch immer wieder beim Austausch zwischen Systemen für Probleme sorgt. Notepad unter Windows konnte z.B. lange Zeit keinen Unix-Zeilenumbruch verarbeiten, was ein Problem ist. Auch, wenn man diesen beim Speichern verändert, ist ein Problem. Ein professioneller Texteditor wie Notepad++ bietet darum auch die Möglichkeit, das Zeilenende festzulegen. Das gehört definitiv zu Textdatei. ‣Andreas•⚖ 17:39, 15. Jun. 2026 (CEST)

Gut, auf die Kompabilitätssache bei Zeilenumbrüchen kann man noch eingehen. Verstehe ich. Aber nicht so ausführlich wie jetzt. Wie sollen EBCDIC-Zeilenumbrüche denn hier helfen? Das ist ja der Sonderfall aller Sonderfälle. --~2026-35130-02 (Diskussion) 18:45, 15. Jun. 2026 (CEST)

Sagt wer? Kannst du das mit Quellen untermauern? Ich würde argumentieren, dass es auf IBM Mainframes der Normalfall ist. ‣Andreas•⚖ 19:30, 15. Jun. 2026 (CEST)

Kann sich halt nicht jeder leisten. Nur IBM Z/Architecture Systeme verwenden das. Wird nur von ein paar hundert Unternehmen in Deutschland eingesetzt. Es ist sicher sehr wichtig, aber für das allgemeine Verständnis von Textdateien ganz sicher nicht. --~2026-35130-02 (Diskussion) 19:41, 15. Jun. 2026 (CEST)

Textdateien gibt es vielen unterschiedlichen Systemen, und wenn man eine alte DOS-Floppy-Disk mit einer README.TXT findet, dann ist das wder mir LF noch mit UTF-8. Es ist sicher nicht essentiell für das Verständnis von Textdateien, aber es ist eben einer der möglichen Fälle, und warum sollte man sich auf 98% der Systeme beschränken? Dieses Argument ist keines, denn dann könnte man sich jeglichen Artikel über Exoten ersparen. ‣Andreas•⚖ 20:06, 15. Jun. 2026 (CEST)

Weil es in den Artikeln Zeichenkodierung und Zeilenumbruch und den Artikeln zu den Kodierungen selbst besser aufgehoben ist. Mit weniger Fehlern und unbelegtem Halbwissen. --~2026-35130-02 (Diskussion) 20:09, 15. Jun. 2026 (CEST)

Und sucht man im Artikel zur Textdatei vieles von dem, was man eigentlich finden sollte. Wenn man z.B. eine Datei unter Windows speichert und unter Linux Probleme damit hat. Oder eine Textdatei in Windows 98 öffnen will und das dann alles kaputt aussieht. ‣Andreas•⚖ 20:21, 15. Jun. 2026 (CEST)

„Wenn man z.B. eine Datei unter Windows speichert und unter Linux Probleme damit hat.“

In einem Texteditor? Nein. So blöd war nur notepad.exe.

„Oder eine Textdatei in Windows 98 öffnen will und das dann alles kaputt aussieht.“

Kein Unicodesupport. Heute verwendet aber keiner mehr Windows 98. Funktioniert auch gar nicht mehr auf Computern neuer als 2010. Damit kannst du nur noch im Emulator herumspielen. --~2026-35130-02 (Diskussion) 20:25, 15. Jun. 2026 (CEST)

Das heißt, mit deinen Argumenten können wir dann die Artikel zu allen alten Windows-Versionen und die Emulatoren gleich dazu löschen. ?!?!?

Nein. Hol dir bitte eine WP:3M, denn ich mach da nicht mit. Kein Konsens. ‣Andreas•⚖ 20:30, 15. Jun. 2026 (CEST)

Das habe ich überhaupt nicht angedeutet. Ich bin immer noch der Meinung, daß es halt in den Hauptartikel alles besser aufgehoben ist. Der ganze Artikel Textdatei will sich die ganze Welt aneignen, hat aber nur 29 Belege und 5 davon sind das selbe nicht frei zugängliche Buch „Sascha Kersken: IT-Handbuch für Fachinformatiker. Galileo Computing, Bonn 2009“. Also nichts gegen Sascha Kersken. Er ist bestimmt ein netter Kerl. Jedoch sind das alles gut öffentlich zugänglich dokumentierte Themen mit vielen kostenlosen Internetseiten für jeden Teilaspekt. --~2026-35130-02 (Diskussion) 20:36, 15. Jun. 2026 (CEST)

UTF-8 BOM

Es steht ausdrucklich in meinem Beleg:

Sofware developers: „If producing UTF-8, include a BOM only if explicitly directed to do so, or if a BOM is known to be required by a protocol.“

Text authors:

Blabla. Du darfst deine .txt mit BOM versehen, wenn du anderen Windows-Nutzern mit notepad.exe irgendwas schreiben sollst oder ein Protokoll es zwingend voraussetzt.

Otherwise, do not include a BOM.

Das ist eine generelle Warnung vor UTF-8 BOM und nicht anders zu verstehen. Es ist erlaubt und du sollst auch nicht bestehende Protokolle brechen, aber wenn du die Wahl hast, dann tus nicht. --~2026-35378-45 (Diskussion) 22:14, 16. Jun. 2026 (CEST)

Rücksetzen und Neuanfang

Nachdem ich die Änderungen des unangemeldeten Benutzers nicht sichten werde, aus den angegebenen Gründen (siehe Diskussionen darüber bzw. WP:VM#Seiten Plain text und Textdatei), hier mein Vorschlag zur Auflösung:

1. Wenn nötig (hängt von der Einsicht des Benutzers ab): Teilsperre der Seiten Textdatei und Plain text (und eventuell noch weitere)
2. Rücksetzen des Artikels auf den Zustand Spezial:Diff/267988886
3. Einzelnes Einbringen der gewünschten Änderungen nach erfolgreiche Diskussion inklusive Konsens, der den Regeln der Wikipedia entspricht (vor allem Belege).

Das schließt insbesondere das Vermeiden eines Edit-War mit ein!

• Zurücksetzen ohne Beleg, bzw.
• Zurücksetzen des Zurücksetzens, wenn der Beleg anderes ausgelegt wird -- ohne enstprechende Disksussion und konsens, gegebenenfalls mit WP:3M

Zusätzlich habe ich in diesem Bezug die Bitte, dass der Benutzer sich jeweils als derselbe erkenntlich macht, z.B. durch Voranstellen eines selbst gewählten immer gleichen Pseudonyms vor die Signatur. Das erleichtert die Zusammenarbeit ungemein.

Ansonsten habe ich auch kein Problem damit, wenn ein anderer erfahrener Wikipedianer mit Fachwissen aus dem IT-Bereich hier übernimmt. ‣Andreas•⚖ 12:28, 18. Jun. 2026 (CEST)

Ich verstehe deine Kritik. Du bist der Überzeugung, daß Textdatei (text file) ein absolut eindeutig definierter Fachbegriff ist und alle anderen falsch liegen. Ich denk jedoch, daß kein Normungsinstitut sich je über dieses weit verwendete zusammengesetzte Namenwort beschwert hat. Ich habe keine Probleme damit, daß der Artikel reine Textdateien abhandelt, jedoch sollte er an die Verwendung im Sprachgebrauch neutral herangehen und nicht eigene Auffassung.

Daß UTF-8 Bom heute nicht mehr empfohlen wird ist gut belegt und nicht frei auslegbar. Da steht man soll es nicht tun, es sei dens man arbeitet mit Altlast oder Protokollen, die es vorgeben. Wenn du das anders siehst, zitiere bitte den Textabschnitt, den du anders verstehst, sonst kann ich weder darüber nachdenken, darauf antworten oder meine Ansicht ändern. Weil du notepad.exe oft als Argument nimmst: Software soll keinen BOM einfügen, wenn nicht vom Protokoll benötigt oder dazu angewiesen. Und wer weist notepad.exe dazu an einen bom einzufügen? Keiner. Eine Textdatei ist auch kein Protokol. Folglich hält sich MS nicht an die Empfehlung von Unicode.

Außerdem hab ich kein Konto. D.h. du kannst mich so oft zurücksetzen wie du magst und ich kann ohne deine Zustimmung nichts veröffentlichen und ich will auch keine anderen Wikipedianer in unseren Diskurs hineinziehen. Reg dich nicht auf. Ich versuche dir meine Ansicht zu unterbreiten. --~2026-33102-54 (Diskussion) 14:16, 18. Jun. 2026 (CEST)

1. Wer ist ~2026-33102-54?

2. Du verstehst meine Kritik offenbar überhaupt nicht. Meine Kritik ist, dass du Belege für deine Behauptungen brauchst. Dass du denkst, ich wäre der Überzeugung, dass Textdatei absolut eindeutig definiert sei, bestätigt, dass du nichts von dem verstanden hast, was ich versucht habe, dir zu vermitteln.

Ich denke ja gerade NICHT, dass ich recht hätte und alle anderen falsch lägen. Ich denke jedoch, dass die Information, die du eingebaut hast, in der Quelle gar nicht steht. Das ist -- wenn du so willst -- das genaue Gegenteil, denn wenn, dann ist es deine Überzeugung, die du durchzuboxen versuchst, und DU denkst, DU hättest recht, und alle anderen lägen falsch. Und außerdem denkst DU, du müsstest niemanden überzeugen, wenn er sagt, dass das so gar nicht in der referenzierten Quelle steht, und beginnst einen Edit-War.

3. Im Detail: BOM-UTF-8 frei auslegbar. Ja, so steht es in der von dir verlinkten Quelle: dort steht, was man tun, wenn ein Programm das macht/braucht, und was man tut, wenn ein Programm das nicht macht/braucht. Nirgends steht dort, dass von BOM generell abgeraten wird. "The UTF-8 encoding scheme permits, but does not require, a BOM to be present." heißt ja, vereinfacht übersetzt: "UTF-8 erlaubt BOM, erfordert es jedoch nicht". Desweiteren steht, dass BOM in bestimmten Systemen, die mehrere Kodierungen unterstützen, durchaus nützlich sein kann: "BOM may be useful to differentiate text encoded in one of a few possible character encodings." Das heißt, den Satz "In UTF-8 gibt es einen UTF-8-BOM, der ursprünglich zur vereinfachten Kodierungserkennung dienen sollte, heute aber vom Unicodestandard als nicht sinnvoll und problematisch eingestuft wird." kannst du damit gar nicht belegen. Denn das Gegenteil ist der Fall: je nach System wird BOM bei UTF-8 sogar als sinnvoll eingestuft. Die Nachteile, wie dass es inkompatible Software gibt und dass es bei vielen kleinen Dateien unnötig (mehr) Speicherplatz verbraucht, sind angegeben. Von einem "Problem" lese ich nichts, nur von Inkompatibilitäten.

4. Aber darum geht es auch nicht: es geht um deine Art, wie du damit umgegangen bist. Du hast einen Edit-War angefangen. Das heißt für mich, dass du nicht mitarbeiten willst, sondern deine Meinung, deine Ansicht, deine Interpretation durchdrücken willst. Und das ist schon mal grundsätzlich regelwidrig.

5. Daher: ändere dein Vorgehen. Zumindest, wenn ich hier tätig werden soll. Sonst kann ich nur 1. als Erstmaßnahme deine Änderungen nicht sichten, und als weitere Maßnahme, wenn ich mal genügend Zeit für Recherche habe, das Groß deiner Änderungen wieder löschen oder so abändern, dass es mit den von mir gefundenen Quellen gem. WP:BLG übereinstimmt.

‣Andreas•⚖ 14:50, 18. Jun. 2026 (CEST)

1. Ich bin immer noch der selbe Arsch

2. ok

3. „BOM may be useful to differentiate text encoded in one of a few possible character encodings.“ ist aus dem Teil für UTF16. „je nach System wird BOM bei UTF-8 sogar als sinnvoll eingestuft.“ das steht nicht unter Guidelines for Use of a BOM in UTF-8. Da steht:

"Software developers: If consuming UTF-8, recognize and discard a BOM. If producing UTF-8, include a BOM only if explicitly directed to do so, or if a BOM is known to be required by a protocol"

4. In Ordnung. Ich bin damit falsch umgegangen.

5. bitte mache meine änderung in diesem artikel rückgängig.ich glaube man braucht ein konto da steht: Die Änderung konnte nicht rückgängig gemacht werden, da der betroffene Abschnitt zwischenzeitlich verändert wurde. --~2026-33102-54 (Diskussion) 15:22, 18. Jun. 2026 (CEST)

Auf Deutsch: Softwareentwickler: Wenn Sie UTF-8 verarbeiten, erkennen Sie ein BOM und verwerfen Sie es. Wenn Sie UTF-8 erzeugen, fügen Sie ein BOM nur dann ein, wenn Sie ausdrücklich dazu aufgefordert werden oder wenn bekannt ist, dass ein BOM von einem Protokoll verlangt wird. --~2026-33102-54 (Diskussion) 15:25, 18. Jun. 2026 (CEST)

BOM wurde für utf16 erfunden. Deshalb heißt es Byte-Reihenfolge-Markierung und nicht Kodeierungs-Erkennungs-Markierung. --~2026-33102-54 (Diskussion) 15:44, 18. Jun. 2026 (CEST)

Auch auf Windows haben viele Programme Probleme mit der Verarbeitung von einem BOM. Z.B. Winget https://github.com/microsoft/winget-cli/issues/5502

Winget existiert nur für Windowsadministration und BOM-Unterstützung wurde dann widerwillig 2025 hinzugefügt, nachdem es erst als not planned geschlossen wurde. --~2026-33102-54 (Diskussion) 16:00, 18. Jun. 2026 (CEST)

cmd.exe kann einen BOM auch nicht verarbeiten und notepad.exe wird einen hineinwerfen auch wenn du nur ascii speicherst, wenn du die Standardeinstellung nicht änderst. --~2026-33102-54 (Diskussion) 16:08, 18. Jun. 2026 (CEST)

Wow. 1. Soll ich dich jetzt wirklich Arsch nennen? Ich hoffe, du hast ein besseres Pseudonym.

2. Warum nicht gleich so?

Das hätte ich anders gelesen, insofern, als dass es offenbar viel Software gibt die a) BOM nicht erkennt ("recognizes"), und b) daher darstellt bzw. zu verarbeiten versucht, und nicht verwirft ("discard"). Mit anderen Worten: BOM-aware software verwirft die Kodierung, während Software, die BOM nicht kennt (bzw. verarbeitet = BOM als Byte Mark Order nicht erkennt), die drei Bytes als Text/Daten verarbeitet und damit dann Probleme hat.

Das heißt: (und dafür sind diese Diskussionsseiten HIER da) ich hätte gerne, dass du das anders formulierst.

‣Andreas•⚖ 16:26, 18. Jun. 2026 (CEST)

Ich nahm an du wußtest das, weil ich meine schon zu Vista-Zeiten damit Probleme gehabt zu haben. Der Groll sitzt tief in mir in drinnen. --~2026-33102-54 (Diskussion) 16:30, 18. Jun. 2026 (CEST)

Wie soll ich das wissen. Und zweitens: was hat das mit UTF-8-BOM im Allgemeinen zu tun? Anders ausgedrückt: wenn man nur Vista einsetzt und keine Textdateien anderer Systeme nutzt, hat man damit auch keine Probleme: die Systeme haben einen Standard, an den sie sich selbst sowieso halten. Nur wer mit "auswertigen Standards" daher kommt, kriegt dann Probleme. Das war immer schon so. Ich würde aber nicht hergehen, und die Probleme, die ich mit FAT und DOS-Dateien unter Linux hatte, als Fakt in den Artikel zu packen. Was soll das?

Die Richtung ist umgekehrt, obwohl natürlich das, was du zu wissen glaubst, dein Ausgangspunkt ist:

1. Recherche. Du wirst vielleicht, wenn du neutral an die Sache herangehst (und du schreibst ja, du würdest), oft erkennen müssen, dass das in der Wahrnehmung der Welt, in Fachbüchern und fachlich brauchbaren Quellen, nicht so abgebildet ist. Oder du lernst noch etwas.

2. Mit dem neuen Gesamtbild nach der Recherche willst du den Artikel verbessern, suchst dazu aber brauchbare Quellen. Im Zweifel nutzt du die Diskussionsseite und fragst dein Mitautoren: wie seht ihr das? Kann man das so schreiben? Zusammen kommt man dann meist auf eine brauchbare Formulierung.

3. Einarbeiten in den Artikel.

Und nicht umgekehrt. Und auch nicht mit Annahmen. Ich dachte du würdest, hättest...

Ich habe ja auch gedacht, du hättest verstanden, dass ein Revert mit der Information, dass das so nicht da steht, weiterer Zusammenarbeit auf der Diskussionsseite bedarf, um das zu besprechen. Bearbeitungskommentare wie "Lies doch XYZ, da seht's doch" in einem Revert helfen da nun mal nicht weiter. Ich hätte wirklich gedacht, du hättest verstanden, dass es andere nicht so lesen wie du. Oder, dass du deine(n) Mitautor(en) vielleicht auf die Sprünge helfen musst, damit sie deine Gedankengänge verstehen. (Du hast noch nicht auf meine gerade eben formulierte Auslegung der Quelle reagiert.)

Ich bitte dich, sachlich zu bleiben. Kommentare wie "dann ist dein Editor kacke" und dann mit "ich hatte unter Vista damit Probleme" stehen sich diametral gegenüber: dann ist dein Vista also kacke, denn ich hatte unter Linux keinerlei derartige Probleme. Außerdem will ich sehen, was wirklich in einer Textdatei ist, das heißt, dass ich ^M als Zeilenende von DOS sehe, ist gut. Mein Editor zeigt vermutlich auch die drei Bytes BOM an, was mir auch hilft, denn dann weiß ich, dass da einer drin ist. Wenn mein Zielsystem dann dieses Format erwartet, mache ich das nicht mit automatischer Konvertierung (oder dem Wegwerfen "discard" des BOM) kaputt, denn das System, auf dem die Datei dann funktionieren soll, will das vielleicht genau so serviert bekommen.

All das ist dir aber völlig egal. Und dabei sind wir noch beim Diskutieren. Belege sind da noch gar nicht zu 100% in eine Formulierung verarbeitet.

‣Andreas•⚖ 17:27, 18. Jun. 2026 (CEST)

Wenn du nur Vista benutzt und keine Textdateien überträgst hast du immer noch Probleme mit utf-8 bom. Wie gesagt cmd.exe kann es nicht verarbeiten. Wenn du eine .bat schreibst und mit bom speicherst, dann wird cmd.exe die Ausführung abbrechen und dir sagen es sei kein gültiger Befehl und wenn du eine Datei öffnest wird der BOM Teil deiner Variable. Das ist absolut fatal. Auch bei zahlreichen anderen Anwendungen. Gleiches mit VBS und JScript, Powershell 1.0, PHP 5.2 / 5.3, IIS 6 / IIS 7 ASP / ASP.NET, Windows Task Scheduler (Vista) XML task definitions, Windows INI parser, und unzähligen weiteren.

Außerdem ist ms kein Verfechter von utf8 bom mehr und das uwp windows store notepad das mit windows 11 geliefert wird nutzt utf8 ohne bom standardmäßig. --~2026-33102-54 (Diskussion) 17:51, 18. Jun. 2026 (CEST)

Übrigens war ich die längste Zeit Windowsnutzer und hab Windows Server auf meinem Desktop betrieben. Ich bin nicht religiös. --~2026-33102-54 (Diskussion) 18:00, 18. Jun. 2026 (CEST)

Wie soll ich bitte unter Vista eine Textdatei mit BOM speichern können? ‣Andreas•⚖ 18:38, 18. Jun. 2026 (CEST)

Vileleicht sollte ich das erläutern: in der gui von Notepad.exe steht nur "UTF-8", aber gemeint ist utf8 mit bom. Ohne bom gabs nicht mal zur Auswahl, so schlecht ist Notepad.

xp: https://www.sqlsnippets.com/en/img-Unicode-Windows-XP-image-1.png

7: https://i.sstatic.net/tIViq.png

utf8 gabs schon auf xp zur Auswahl. --~2026-33102-54 (Diskussion) 18:59, 18. Jun. 2026 (CEST)

zu den Bildern: unicode war ms-slang für utf16le. unicode big endian war utf16be. Die Bezeichnungen sind falsch und irreführend. Alle UTF-Kodierungen sind Unicode. --~2026-33102-54 (Diskussion) 19:06, 18. Jun. 2026 (CEST)

Klingt nach einer Inkonsistenz im Microsoft-Betriebssystem. Ziemlich stark. (Schwach... von Microsoft.) Bessere Quellen sind dennoch erforderlich, weil es ja auch um die Relevanz geht: Wenn die Fachpresse diesen ziemlich blöden Fehler in Windows (im Editor) nicht aufgegriffen und darüber berichtet hat, ist er offenbar nur eine Randerscheinung (corner case) und nicht relevant genug für den Artikel. Diese Information kann aber in die Formulierungen einfließen, aber nur am Rande. Sie darf keine "Absolut-Information" werden, auf den sich einer Artikelabschnitt, oder ein Absatz, bezieht.

Und die Frage bleibt: was hat das mit "Textdatei", dem Artikelgegenstand, zu tun? Soll ich nun solche Corner Cases auch für VMS aus den 1980er Jahren heraussuchen? Dürfen die dann auch in den Artikel? Warum immer nur Windows? Auf 90% aller Server läuft doch Unix oder ein Unixoides System, und Textdateien sind nicht nur für Windows-Nutzer interessant...

‣Andreas•⚖ 19:47, 18. Jun. 2026 (CEST)

Probleme mit BOM sind keine Randerscheinung, sondern damals wie heute allgegenwärtig und genauso wie du Notepad++ für dich entdeckt hast war ich früher auch ein Fan von Notepad++. Es gab auch noch viele andere Editoren. Jeder hat halt erstmal einen Haufen Third-Party-Software installiert. Nur Anfänger hantierten mit dem eingebauten Kram. Auch Antivirus und Systemwartungsprogramme kamen damals immer aus dritter Hand. Mein Vater ist ein normaler Anwender. Er benutzt keinen Editor und auch kein Notepad++. Er benutzt gar nichts. So ist das halt mit den meisten Windowsnutzern. Wenn du überhaupt reine Textdateien bearbeitet hast warst du damals schon Poweruser.

Das ein Programm, hingegen nicht ohne BOM-Marke funktioniert ist der echte Corner-case und betrifft wahrscheinlich nur eine Handvoll.

Beispiele von Ärgernissen die etwas her sind:

„UTF-8 in FrontPage 2000, 2002 und 2003“

FrontPage 2000 unterstützt das UTF-8-BOM nicht:

https://schneegans.de/frontpage/utf-8/

2008:

https://www.html.de/threads/komisches-zeichen-i.16359/

von 2007 w3c über Windows Notepad:

https://www.w3.org/International/questions/qa-utf8-bom.de.html

2005:

„BUGFIX: RTF-Daten und Daten, die mit dem UTF-8 Byte Order Mark (BOM) 0xEFBBBF beginnen, werden von FileEdit jetzt korrekt geladen, das heißt nicht mehr interpretiert.“

http://janmatuschek.de/FileEdit

2013:

https://simonstamm.de/kodierung-utf-8-ohne-bom/

2011:

https://software-lupe.de/tipp/utf-8-ohne-bom-mit-notepad/

2006:

„Wenn Sie Unicode mit UTF-8-Kodierung verwenden möchten, sollten Sie sichergehen, dass Sie einen Unicode-fähigen Editor verwenden. Beim Speichern achten Sie darauf, die Daten ohne BOM zu speichern. Denn die BOM kann bei einigen Browsern und auch bei serverseitigen Skriptdateien zu Problemen führen.“

https://webkrauts.de/artikel/2006/zeichens%C3%A4tze-und-zeichenkodierungen.html

https://www.golem.de/news/insider-build-18298-windows-10-preview-verbessert-notepad-und-touch-tastatur-1812-138178.html

„Er unterstützt jetzt UTF-8 ohne Byte Order Mark und“

KI sagt, daß es damals auch in deutschen Fachzeitschriften Artikel gab, aber die waren damals noch aus Papier und jetzt sind sie hinter einer Paywall:

https://www.heise.de/select/ct/archiv --~2026-33102-54 (Diskussion) 20:27, 18. Jun. 2026 (CEST)

Okay. Das sollten wir im Abschnitt #UTF-8 mit Byte Mark Order (BOM) besprechen. Nur so viel: wenn Windows mit dem Editor UTF-8-Dateien mit BOM erstellt hat, der Rest der Windows-Programme damit dann aber Probleme hatte, dann sollte das in einen Windows-Artikel. Was man hier erwähnen kann, ist nur eines: nämlich dass UTF-8 mit BOM nicht mit jeder Software kompatibel ist. Nur das ist belegbar. Selbst der Grund, nämlich, dass die BOM-Markierung nicht erkannt und irrtümlich als Daten interpretiert wird, bedarf meiner Meinung nach noch etwas mehr Recherche. Und dann kommt es, schließlich (also, als Output unserer gemeinsamen Arbeit), auf die Formulierung an, auf die wir uns einigen (können).

Aber, bitte: weiter im korrekten Abschnitt, damit wir auch wirklich was weiter bekommen. ‣Andreas•⚖ 21:30, 18. Jun. 2026 (CEST)

„irrtümlich“

Das ist kein Irrtum oder ein Fehler, sondern der Grundzustand. Es ist ein Naturgesetz. Du bist kein Programmierer. Ich wünschte so sehr, ich könnte es dir erklären, aber das wird nichts, weil du von Softwareentwicklung nicht viel verstehst. Der Utf8-bom hätte sich nie durchsetzen können. Vergessen wirs. Nichts gegen dich. --~2026-33102-54 (Diskussion) 23:28, 18. Jun. 2026 (CEST)

Du hängst dich an einem Wort auf. Tu das nicht.

Programmierer verwenden in der Regel nicht Notepad. Nicht einmal Power User tun das, weil Notepad zu rudimentär ist und daher für viele Zwecke ungeeignet. Auch, wer Webseiten betreibt, wird diese nicht in Notepad verfassen.

Gib dem Windows-Editor doch bitte nicht so eine große Bühne. ‣Andreas•⚖ 00:17, 19. Jun. 2026 (CEST)

Es ging &m die Tragweite eines BOMs beim Lesen durch Anwendungen. Du verstehst es nicht, weil du keine Anwendungen schreibst. --~2026-33102-54 (Diskussion) 08:39, 19. Jun. 2026 (CEST)

Nochmal: mir ist schon klar, dass Anwendungen mit BOM ein Problem haben könnten. Aber: 1. speichert der Editor in der Standardeinstellung NICHT UTF-8 (mit BOM), sondern Windows 1252 oder UCS-2/UTF-16, und 2. müssen Textprogramme (Editoren, Textverarbeitungen) auf jeden Fall mit UTF-8+BOM umgehen können.

Für den Spezialfall, wo ein Anwender Konfigurationsdateien bearbeiten muss, müssen Windows-Anwendungen mit den Standards umgehen können, was da heißt: Windows 1252 oder UTF-16, nicht jedoch UTF-8 (ob mit oder ohne BOM), da das unter Windows Exotenstatus hat. Die Anwender, die glauben, mit dem Windows-Editor unbedingt manuell auf UTF-8 umstellen zu müssen, werden schnell erkennen, dass sie besser einen anderen, besseren Editor verwenden sollten... ‣Andreas•⚖ 08:46, 19. Jun. 2026 (CEST)

Wenn eine kyrillische Sprache eingestellt war, war es aber Windows-1251, nicht Windows-1252. Es war in der Regel nicht sinnvoll in einer Codepage abzuspeichern. Nein, „ANSI“ ist keine Kodierung, da hat MS auch gelogen. Zu DOS-Zeiten nannten sie es ANSI Codepages, was auch falsch ist. --~2026-33102-54 (Diskussion) 08:57, 19. Jun. 2026 (CEST)

Ja. Das kann aber aufgrund fehlender Relevanz nicht in den Artikel. Außerdem ist das "by design" so. In den 1980er Jahren gab es teils überhaupt keine anderen Schriftzeichen als die Englischen, wenn Software nicht einmal übersetzt verfügbar war. MS-DOS 1.0 und 2.0 auf Deutsch zu finden, ist eine Herausforderung. Dann kamen die Codepages auf. In den 1990er Jahren war fast alles lokalisiert -- im negativen Sinn des Wortes: in den Dateisystemen von Microsoft sind die Zeitstempel der Dateien in Lokalzeit gespeichert, was beim Austausch international nicht gerade von Vorteil ist. Ebenso sind Kodierungen nur lokal verfügbar, oder sie müssen manuell umgestellt werden.

In dieser Realität erscheint Windows 9x und Windows NT.

Und auch die ANSI.SYS hat den falschen Namen. Aber das ist egal.

Du brauchst Nachweise gem. WP:BLG, dass diese Kodierungsbenennungen und die Kodierungsprobleme (mit UTF-8) ein echtes Problem waren.

Was ich finden kann, ist, dass es eine Eigenart ist. Das ist etwas systemspezifisches. Es hat aber nicht die Größe, die du dem ganzen offenbar gibst.

‣Andreas•⚖ 09:43, 19. Jun. 2026 (CEST)

Nachtrag: außerdem ist es mir wirklich vollkommen neu, dass der Editor eine BOM schreibt. Die native Kodierung unter Windows ist ja gar nicht UTF-8, sondern Windows 1252 bzw. UCS-2 (UTF-16). Für die meisten praktischen Anwendungen ist Windows 1252 quasi dasselbe wie ISO 8859-1 oder 8859-15, außer man ist der Meinung wirklich die ganzen Sonderzeichen verwenden zu müssen. In den meisten Textdateien stand oft lieber "Euro" statt "€", vielleicht aus diesem Grund. Wir alle wissen, dass erst Unicode dieses Problem gelöst hat. Meiner Erfahrung nach sind viele Textdateien aus Windows UTF-16-kodiert, wofür ich unter Linux das Programm recode benutze, denn Linux ist durch-und-durch UTF-8. Klar, viele Editoren erkennen das und machen das richtig auf, aber gerade bei Textdateien sollte man eben der Konvention des Systems folgen.

Bei nüchterner Betrachtung ist es wirklich nicht so schlimm wie gezeichnet... ‣Andreas•⚖ 00:29, 19. Jun. 2026 (CEST)

„In den meisten Textdateien stand oft lieber "Euro" statt "€"“

Ne, komm. Fang damit nicht an. Es reicht nicht mal für Englisch: –, —, ‘, ’, “, ”, …, café, naïve, résumé, cliché, façade, châteaux, fiancé, fiancée, déjà vu, vis-à-vis, coöperative, reëlect, crème, soufflé, flambé, purée, sauté, pièce de résistance, bête noire, maître d', appliqué, papier-mâché, exposé, blasé, touché, voilà, vis-à-vis, née, passé, risqué, protégé, protégée, entrepôt, déjà, précis, jalapeño, --~2026-33102-54 (Diskussion) 08:50, 19. Jun. 2026 (CEST)

Die Apostrophe funktionieren ja. Zumindest wenn man in der gleichen Region bleibt: Windows 1252 und ISO 8859-1 sind diesbezüglich kompatibel.

Außerdem: nein, in Englischen und Deutschen Texten liest man das sehr selten. Französische Texte... nun ja, keine Ahnung, welche Probleme die Franzosen mit unterschiedlichen Kodierungen hatten. Oder auch nicht. Ich gehen mal davon aus, dass diese Textzeichen keine Probleme machten.

Das Euro-Zeichen ist jedoch bei Windows 12* und ISO 8859* unterschiedlich kodiert. Also... Komm. Mach keinen Elefanten aus einer Mücke.

‣Andreas•⚖ 09:59, 19. Jun. 2026 (CEST)

„in Englischen und Deutschen Texten liest man das sehr selten.“ dann liest du nicht viel Englisch. Keiner schreibt auf Englisch in irgendeinem ordentlichen Schreiben fiancée ohne Akzent. Das ist kein Apostroph. --~2026-33102-54 (Diskussion) 10:06, 19. Jun. 2026 (CEST)

In Word vielleicht nicht, in einer Readme eher schon. Sag mal, aus welcher Galaxie kommst du? Zeig mir ein Microsoft-Dokument in einer Textdatei auf Englisch, wo fiancée steht?

Außerdem, wieder: darum geht es nicht. Alles, was wir hier diskutieren, bringt dem Artikel NICHTS. Du brauchst BELEGE ohne Confirmation Bias, du brauchst RELEVANZ, und dann brauchst du KONSENS. Und du musst dich an die Regeln halten (was Fragen an und Antworten von einer Sprach-KI schon mal ausschließt).

NUR DARÜBER sollten wir hier diskutieren. (Wofür WP:DISK da ist, und nichts anderes.)

‣Andreas•⚖ 10:10, 19. Jun. 2026 (CEST)

Windows XP ist dein Fußballverein und nichts, was ich sage und keine Belege werden dich überzeugen. Du bist ein Dogmatiker. --~2026-33102-54 (Diskussion) 10:21, 19. Jun. 2026 (CEST)

Wenn jeder mit seiner Ansicht, seinen Belegen, alles in der Wikipedia verbreiten könnte, wie du es versuchst, wo wären wir dann? Da kannst du genausogut Trump fragen...

‣Andreas•⚖ 11:29, 19. Jun. 2026 (CEST)

Stell dir vor du erstellst eine Webseite mit PHP. 99% sind UTF-8 Entweder der BOM scheißt dir in den PHP-Parser oder in die Webseite und dann stellte MS IE es falsch dar. Wir sind im Internetzeitalter. --~2026-33102-54 (Diskussion) 09:22, 19. Jun. 2026 (CEST)

Unter Windows wollen die meisten Programme UTF-8 nur dann akzeptieren, wenn ein BOM da ist. Beispiel: Microsoft Excel. Fügt man Text ein, der UTF-8-kodiert ist, aber ohne BOM, dann kommt es zu Fehlern. Ich würde also sagen, dass der Editor alles richtig macht, was UTF-8-BOM betrifft. Es ist eben die Konvention von Windows.

Ob Microsoft gelogen hat, ist egal. Auch, ob Softwareentwickler damit Probleme haben (was Blödsinn ist: Softwareentwickler sind sehr Computer-affin, die haben keine Probleme sondern Lösungen), ist ein Spezialfall. Der typische Windows-Anwender will das Gegenteil: UTF-8 mit BOM, weil sonst unter Windows UTF-8 nicht richtig funktioniert.

Siehe Adding BOM to UTF-8 files, zum Beispiel.

‣Andreas•⚖ 09:35, 19. Jun. 2026 (CEST)

Frag doch Bing Copilot von MS. Du hängst dich an den ungefähr 5 Ausnahmen aus. --~2026-33102-54 (Diskussion) 10:02, 19. Jun. 2026 (CEST)

Das ist nicht Wikipedia-würdig. Ausnahmen gibt es immer.

Wenn du in Windows etwas Windows-fremdes (wie PHP) nutzt (das aus der Unix-Welt stammt), dann kommt es zwangsläufig zu Friktion. So weit muss man da gar nicht gucken: TeX z.B. in anderen Sprachen macht(e) auch Probleme.^refref Diese lassen sich aber lösen, wie du in den referenzierten Quellen lesen kannst.

‣Andreas•⚖ 10:12, 19. Jun. 2026 (CEST)

Frühe Vista/Win7‑Task‑Scheduler‑Versionen hatten Probleme mit UTF‑8‑BOM in MSXML. Sind die jetzt Uuuuuniiiiix? --~2026-33102-54 (Diskussion) 10:28, 19. Jun. 2026 (CEST)

Wie viele Anwender hatten Probleme mit MSXML? Wo sind die entsprechenden Artikel in der Fachpresse, und wie viele Windows-Nutzer sind damals zu Linux oder macOS gewechselt, weil sie diese Probleme endlich hinter sich lassen wollten? Ist deswegen der Linux-Desktop-Marktanteil so dermaßen hoch? (Ich hoffe, du verstehst Spaß.)

‣Andreas•⚖ 11:28, 19. Jun. 2026 (CEST)

Nichts bewegt Windowsnutzer zum freiwilligen Wechsel. Neustes MS Office läuft nur auf Windows. LibreOffice können sie nicht verwenden, aber MS Office eigentlich auch nicht. Ist ihnen aber schnuppe. Wenn man die Ribbonbar in LO einschaltet sieht es fast so aus wie MSOffice. Versuch es doch mal. Es ist kostenlos, quelloffen und verwendet standardmäßig den ODF-Standard, der seit diesem Jahr für öffentliche Verwaltung durch den Deutschland-Stack vorgeschrieben ist. Docx und doc ist jetzt verboten. Linux hat heute immer noch lächerliche 4% und Windows 60%. Mac 14%. Der Rest ist auf ChromeOS oder sonstigen Witzsystemen, die weniger technisches Verständnis erfordern. --~2026-33102-54 (Diskussion) 12:10, 19. Jun. 2026 (CEST)

Ich hätte auch eine Frage. Wieso verwendet Windows Explorer in der englischen Fassung „Text Document“ für eine reine Textdatei? Überrascht mich etwas. Es wirkt so als wären text document und text file am Ende doch nur Synonyme.

https://www.groovypost.com/wp-content/uploads/2018/05/01-Go-to-New-Text-Document-Windows.png --~2026-33102-54 (Diskussion) 14:35, 18. Jun. 2026 (CEST)

Wer ist ~2026-33102-54? ‣Andreas•⚖ 14:51, 18. Jun. 2026 (CEST)

Ich habe die letzten Bearbeitungen nun zurückgesetzt, was aber nur als Ausgangspunkt dienen soll. Zur Bearbeitung hier bitte ZUERST die Diskussion.

• Spezial:Diff/268036028
• Dabei ist die Kürzung Spezial:Diff/267954074, die ich ebenfalls rückgängig gemacht habe, noch gar nicht berücksichtigt. Wenn du gute Gründe dafür vorbringen kannst, kann man auch darüber diskutieren. Meine Meinung ist in der Zusammenfassungszeile dokumentiert: Spezial:Diff/267956842 BCDIC und ASCII sind wichtige Teile der Computergeschichte. Bitte zuerst die Diskussionsseiten nutzen.
• Auch, dass eine Textdatei heute meist UTF-8 wäre, habe ich rückgängig gemacht: Spezial:Diff/267954653. Auf welchen Systemen? Mit welchem Beleg? (speichert nicht gerade Windows meist UTF-16, und Windows ist ja schon schön verbreitet...)

Du kannst entsprechende Diskussionsabschnitte gerne hinzufügen. ‣Andreas•⚖ 19:38, 18. Jun. 2026 (CEST)

UTF-8 mit Byte Mark Order (BOM)

Deine Bearbeitung Spezial:Diff/267965381/267988215:

Original:

Bei Unicode existiert zudem die Konvention, am Beginn einer Datei mittels spezieller Bytefolgen (sogenannte Byte Order Marks) kenntlich zu machen, welche Unicode-Codierung verwendet wird. Dies ist auch deshalb nötig, da auf vielen Systemen – auch unter Windows – die bisherige auf ASCII basierende Codierung und Unicode parallel verwendet werden. Bei einer solchen Codierung beginnt die Grenze zur Binärdatei zu verschwimmen.

Deine Bearbeitung:

Bei UTF-16 existiert zudem eine freiwillige Konvention, am Beginn einer Datei mittels spezieller Bytefolgen (sogenannte Byte Order Marks) kenntlich zu machen, um UTF-16LE und UTF-16BE zu unterscheiden. In UTF-8 gibt es einen UTF-8-BOM, der ursprünglich zur vereinfachten Kodierungserkennung dienen sollte, heute aber vom Unicodestandard als nicht sinnvoll und problematisch eingestuft wird.^ref

Mein Vorschlag:

Bei UTF-16 und UTF-32 existiert zudem eine Konvention, am Beginn einer Datei die Byte-Reihenfolge mittels sogenannte Byte Order Mark zu kennzeichnen. Dadurch kann z. B. UTF-16LE klar von UTF-16BE unterschieden werden. In UTF-8 ist diese Markierung zwar nicht notwendig, kann aber zur Kennzeichnung für Unicode UTF-8 vorhanden sein.^ref

Hier habe ich deine Bearbeitung teils übernommen und nach dem Inhalt derselben Quelle korrigiert.

Das siehst du ja offenbar anders. Und obwohl ich mich viel zu oft wiederhole, tue ich es nicht gerne, aber hier kommt sie, die Begründung: Es gibt Software die a) BOM nicht erkennt ("recognizes"), und b) daher die 3 Bytes des BOM darstellt bzw. zu verarbeiten versucht, und nicht verwirft ("discard"). Mit anderen Worten: BOM-aware software verwirft die Kodierung, während Software, die BOM nicht kennt (bzw. verarbeitet = BOM als Byte Mark Order gerade nicht erkennt), die drei Bytes als Text/Daten verarbeitet und damit dann Probleme hat.

Das heißt nicht, dass dass der Unicode-Standard in Version 17.0.0 die Empfehlung abgibt, BOM grundsätzlich wegzulassen, denn: "The UTF-8 encoding scheme permits, but does not require, a BOM to be present" , vereinfacht übersetzt: "UTF-8 erlaubt BOM, erfordert es jedoch nicht". Auf Systemen, die mehrere Kodierungen unterstützen, kann BOM durchaus nützlich sein: "BOM may be useful to differentiate text encoded in one of a few possible character encodings."

Und von daher brauchen wir hier entweder eine WP:3M, oder wir lassen strittige Punkte weg. Strittig ist: "In UTF-8 gibt es einen UTF-8-BOM, der ursprünglich zur vereinfachten Kodierungserkennung dienen sollte, heute aber vom Unicodestandard als nicht sinnvoll und problematisch eingestuft wird." Das wäre also wegzulassen.

Du bist aber gerne eingeladen, weiter zu recherchieren. Wie gesagt, du wirst Quellen für beides finden. Pass außerdem auf, nicht dem Confirmation Bias zu erliegen. ‣Andreas•⚖ 19:38, 18. Jun. 2026 (CEST)

Textdatei im Alltagssprech

Original:

Im Gegensatz zu dieser fachsprachlichen Definition des Begriffs Textdatei, bei der das Dateiformat ausschlaggebend ist, orientiert sich die umgangssprachliche Verwendung des Begriffs häufig primär am für den Endbenutzer sichtbaren Inhalt der Datei: Dabei werden etwas unscharf alle Dateien als „Textdatei“ bezeichnet, die mit dem Ziel erstellt wurden, einen lesbaren Text zu präsentieren, unabhängig davon, in welcher Form sie gespeichert werden. Bei den von üblicher Textverarbeitungs- oder Publishingsoftware bei Speicherung erzeugten Dateien handelt es sich jedoch häufig um komplexe Dateiformate, die neben dem Text Metainformation zur Beschreibung des Textlayouts, der Struktur und der verwendeten Schriften enthalten; zudem können Bilder oder Grafiken eingebettet sein. Deshalb handelt es sich um keine Textdateien im fachsprachlichen Sinn, da die Dateiformate häufig binär sind und zur Anzeige eine spezielle Software erforderlich ist.

Ersatz von Benutzer "Arsch"?

Laut dem Digitalen Wörterbuch der deutschen Sprache ist die Hauptbedeutung im deutschen Sprachgebrauch eine Datei die Text enthält, unabhängig ihres Dateiformats.^ref Oft sind Textdokumente (z. B. ODF) von Textverarbeitungsprogrammen oder Publishingsoftware gemeint.^{refrefrefrefref} Diese sind gewöhnlich Binärdateien und damit das genaue Gegenteil zu reinen Textdateien, die Plain text oder darauf aufbauende Formate enthalten. Sie sind deshalb meist nicht mit einfachen Texteditoren betrachtbar und bearbeitbar. Zur Klarheit wird bei Binärdateien der Begriff Textdatei in Benutzeroberflächen gemieden und Textdokument verwendet.

Obwohl das ja alles nicht ganz falsch ist, ist es nun umgekehrt aufgezogen. Außerdem ist es auch nicht ganz richtig. Deshalb hier die Diskussionsseite. Denn, ich kenne z.B. nur Word-Dokumente, keine Wort-Textdateien. Ich halte es für übertrieben, es so hinzustellen, als wäre "Textdatei" in der Alltagssprache 1:1 dasselbe wie ein Dokument aus einem Textverarbeitungssystem.

Ich habe hier Das große Computerlexikon, 2018, Markt+Technik Verlag, ISBN 978-3-95982-377-7. Dieses schreibt:

• Dokument
  Als Dokument bezeichnet man einen formatierten Text, einen Brief oder ein ganzes Buch. Dokumente werden mit Textverarbeitungsprogrammen bearbeitet. Im Gegensatz zu reinen Textdateien können Dokumente unterschiedliche Schriftarten, Formatierungen und auch Grafiken enthalten. Ein beliebtes Dateiformat für Dokumente ist das DOC-Format aus Word. Die Endung .doc steht für Document.
• Editor
  Ein Editor ist ein sehr einfaches Programm zum Anzeigen, Erstellen und Bearbeiten reiner Textdateien. In diesen Dateien gibt es weder Formatierungen für Überschriften, Schriftarten oder Textverweise noch enthalten sie Bilder. ... Im Editor können Sie theoretisch jede Datei öffnen und anschauen. Ein sinnvolles Ergebnis sehen Sie allerdings nur bei Textdateien, die Sie an der Dateinamen­erweiterung .txt erkennen. ...
• KDiff3
  Ein Open-Source-Programm zum Vergleichen von zwei oder drei Textdateien mit farbiger Hervorhebung der Unterschiede.
• MadEdit
  Ein Open-Source-Editor für Textdateien mit Syntaxhervorhebung für zahlreiche Programmiersprachen, Sortier- und Zählfunktionen, unterschiedlichen Textcodierungen sowie einem Modus zum Bearbeiten von Binärdateien im Hex-Modus.
• NFO
  Dateierweiterung für Textdateien innerhalb von Archiven, die Installations­hinweise oder andere Informationen enthalten.
• Perl
  Eine plattformunabhängige interpretierbare Programmiersprache, in der man beim Programmieren relativ frei von starren Strukturen ist. Sie wird hauptsächlich für wissenschaftliche Anwendungen sowie zur automatisierten Bearbeitung von Textdateien verwendet. Dazu bietet Perl eine umfangreiche Unterstützung regulärer Ausdrücke.
• Readme.txt
  ... Viele Programmhersteller sind dazu übergegangen, neben dem Handbuch, das meist im PDF-Format vorliegt, noch eine kleine Textdatei mitzuliefern, die die wichtigsten Informationen auf einen Blick enthält sowie ganz neue Programmfunktionen, die noch nicht im Handbuch aufgenommen wurden. ...
• RegexSearch
  Ein Open-Source-Programm zur Suche innerhalb von Textdateien, HTML-Dateien oder Programmquellcodes mithilfe regulärer Ausdrücke.
• Reguläre Ausdrücke
  Zeichenketten, die der Beschreibung von definierten Mengen von Zeichenketten unter Verwendung klarer syntaktischer Regeln dienen. Reguläre Ausdrücke lassen sich z.B. zum Filtern von Listen oder zum Suchen und Ersetzen von Zeichenfolgen in Textdateien verwenden. Verschiedene Editoren, wie auch die Textverarbeitung OpenOffice.org können reguläre Ausdrücke verarbeiten.
• Scan
  Ein Open-Source-Dokumentenmanagementsystem, mit dem sich Office-Dokumente, Textdateien und HTML-Dateien übersichtlich verwalten lassen.
• Script
  Ein Script ist eine Folge von Befehlen, die automatisch abgearbeitet wird. Solche Scripts werden in einfachen Textdateien geschrieben und stellen die einfachste Form des Programmierens dar. ... Die Batchdateien aus MS-DOS waren eine frühe Form von Scripts...
• Text
  Für die Verarbeitung im Computer ist ein Text nur eine Aufeinanderfolge von Buchstaben, Sonderzeichen und Ziffern. Erst durch die menschliche Bearbeitung werden daraus Wörter, Sätze, Abschnitte und endlich auch ein sinnvoller Inhalt. In einem Text sind im engeren Begriff keine Zeichnungen und Bilder enthalten. Durch die Bearbeitung mit einem Editor wird daraus eine Textdatei.
• Textdatei
  Eine Textdatei enthält nur normalen, unformatierten Text. Sie wird mit einem Editor erstellt und besitzt die Dateiendung .txt.
• BAK
  Die Dateierweiterung .bak bezeichnet eine Sicherungskopie einer Textdatei aus der Textverarbeitung (nicht Word). Auch von anderen Programmen werden Back­ups mit dieser Endung versehen.
• Cookie
  ... Diese Cookies werden beim Besuch der entsprechenden Webseite vom Webserver gesendet und im Browser als kleine Textdatei gespeichert. Die gleiche Webseite (und nur diese) kann das Cookie bei einem späteren Besuch lesen und auswerten.
• Dateigröße
  Die Dateigröße wird in Megabyte (MByte/MB), Kilobyte (KByte/kB) und in Byte angegeben. Ein Byte entspricht einem Zeichen, also einem Buchstaben in einer unformatierten Textdatei.

Nimm dir bitte die Zeit, und lasse es dir auf der Zunge zergehen. Denn damit kann ich z.B. auch belegen, dass jedes Zeichen einer unformatierten Textdatei genau einem Byte entspricht. Das ist natürlich, weil wir von Unicode wissen (den es 2018, als das alltagstaugliche "große Computerlexikon" herauskam, auch schon gab), absolut falsch, und dennoch kann ich es belegen.

Verstehst du jetzt vielleicht besser, worauf es ankommt? Finde also gute Quellen (it-service24.com ???), und mehr als eine gute, wenn du was umdrehen willst. Der Begriff ist doch, wie du selbst sagst, sehr ungenau. Da stimme ich dir zu.

Auch ich kann keine Definition des Begriffs "Textdatei" finden. Aber ich finde Fachbücher, die den Begriff verwenden. Vieles von dem, was im "großen Computerlexikon" darüber steht, ist mit diesen Informationen dann aber falsch, und extrem Windows-lastig. Die Welt besteht aber nicht nur aus Windows. Auch auf Linux und Unix (und: die meisten Server laufen darunter!) werden Textdateien verwendet, und da sieht die Sache ganz ganz anders aus als im "großen Computerlexikon" dargstellt.

Ich würde es daher genau umgekehrt machen, wie es vorher war: Im Fach der IT ist eine Textdatei erstmal einfach eine Datei, die nur Text enthält. Mehr nicht. Und, ja, ob der Unschärfe würde ich erwähnen, dass im Alltag auch mal von einer Textdatei gesprochen wird, wenn es sich um ein Dateiformat handelt (was eine Textdatei ja erstmal nicht ist).

Und jetzt geht es darum, das ordentlich zu formulieren. Wie würdest du DAS ORIGINAL umformulieren, damit es leichter lesbar ist? Darüber können wir gerne diskutieren. Und wenn wir uns einig sind, kann es in den Artikel. ‣Andreas•⚖ 19:38, 18. Jun. 2026 (CEST)

Der letzte Satz den ich geschrieben habe scheint leider auch falsch zu sein, denn Windows bezeichnet .txt in der englischen Fassung als Text Document. Da hab ich dumm geschwätzt. Das es zu Textdatei übersetzt wurde andere Formate zu Dokument scheint mehr Zufall zu sein oder Brandinggründe zu haben als fachliche.

Bilder:

https://www.groovypost.com/wp-content/uploads/2018/05/02-Rename-new-text-document.png

https://www.groovypost.com/wp-content/uploads/2018/05/01-Go-to-New-Text-Document-Windows.png --~2026-33102-54 (Diskussion) 19:46, 18. Jun. 2026 (CEST)

3M

• 3M: Ich war so frei, hier mal einen Abschnitt aufzumachen, damit die Diskussion an einer Stelle geführt werden kann. Machen wir es kurz: Ich habe die verlinkten Diskussionen nur überflogen (TL;DR) [Korrektur: Ich habe mich inzwischen eingelesen, siehe den folgenden Abschnitt] und habe von der Sache wenig bis keine Ahnung, aber mE kann das nichts werden, wenn sich nicht alle an die Spielregeln halten. Solange die Abschnittsüberschrift einen drüber noch so formuliert ist wie hier [Korrektur: Durch das Verschieben des Abschnitts ist der Bezug verlorengegangen, gemeint ist das], erübrigt sich jede weitere Diskussion. Der übliche Weg ist dann WP:VM (gabs ja schon: Wikipedia:Vandalismusmeldung#Seiten Plain text und Textdatei (erl.)) und/oder Artikelschutz. Das wäre sehr schade, da mir hier auf beiden Seiten Expertise vorhanden zu sein scheint. Es ist aber niemandem zuzumuten, sich so ein Stress anzutun. Y2kbug hat sich in 20 Jahren WP exakt 0 (Null) Sperren eingehandelt und nach allem was ich sehe liegt es jetzt an unserem anonymen Mitarbeiter, seine Kooperationsbereitschaft unter Beweis zu stellen [Korrektur: WP:Belege, insbesondere Wikipedia:Belege#Grundsätzliches, zu verinnerlichen]. Gutes Gelingen! Gruß --Winkekatze (Winken) 16:43, 19. Jun. 2026 (CEST)

• 3M: Ich äußere mich hier nur zur Frage "DWDS" bzw. Abgrenzung zwischen "fachsprachlicher" und "umgangssprachlicher" Verwendung der Bezeichnung, nicht zu den Punkten "BOM" und "Editor". Die Abgrenzung zwischen den Wortverwendungen ist in der ggw. Fassung des Artikels meiner Ansicht recht gut gelöst: die umgangssprachliche Verwendung wird erwähnt, es wird aber klargemacht, dass der vorliegende Artikel den fachsprachlichen Begriff behandelt. Das ist auch gut so, denn ein Artikel sollte, wenn möglich, nur einen Begriff behandeln und nicht mehrere. Und wir bevorzugen in der Regel fachsprachliche Begriffe. Allgemeine Wörterbücher wie DWDS oder Duden sind für Fachthemen oft nicht die besten Quellen. Gruß, --Yen Zotto (Diskussion) 12:09, 21. Jun. 2026 (CEST)

Diskussion zur 3M

[von der 3M-Seite übertragen]

Ich zitiere von dir in der Diskussionsseite: „habe von der Sache wenig bis keine Ahnung“ Das ist schlecht. Wir sind beide der Auffassung, daß es jemanden mit Ahnung von dem Thema braucht und wollten eigentlich eine Fachentscheidung. Ich hoffe ich sage nichts falsches, aber y2kbug hat sich mehrfach auf die Wichtigkeit des Fachwissens in dem Bereich mit Fachbüchern und so berufen. Wir brauchen jemanden mit Ahnung und wollen beide ein Ergebnis. Wir brauchen jemanden mit Ahnung.

Ich habe die drei Punkte genannt:

Utf8bom schlecht: ja/nein

textdatei nach dwds: ja/nein

windows editor sichtweise: hatte microsoft recht: ja/nein --~2026-33102-54 (Diskussion) 16:54, 19. Jun. 2026 (CEST)

Ja, das ist, was ich meine. Es bedarf einer gewissen Form, bevor Diskussionen erfolgversprechend sind. Der Ton macht die Musik. Ich habe nicht den Eindruck, als ob sich Y2kbug einer inhaltlichen Diskussion verschließen würde. Ansonsten bin ich dann auch mal wieder weg, viel Erfolg! --Winkekatze (Winken) 17:00, 19. Jun. 2026 (CEST)

Dein 20 Jahre-Argument ist ein billiger rethorischer Trick, wiel ich damals noch ein Kind ohne guten Internetzugang war. So könnte ich es ihm unmöglich gleichtun, selbst wenn ich der beste Mensch der Welt wäre.

Älter zu sein bedeutet nicht recht zu haben. Es ist gut daß ihr Freunde seid, aber wir wollen eine dritte Meinung. Das schließt dich dann aus.

Y2kbug verschließt sich sehr wohl vor einer inhaltlichen Diskussion in dem er trotzt reichlich Belegen immer wieder beharrt oder den ursprünglichen Diskussionspunkt nachträglich ändert./verschiebt. --~2026-33102-54 (Diskussion) 17:09, 19. Jun. 2026 (CEST)

Okay, dann nochmal explizit. Wer hat denn die Überschrift „y2kbug hat den artikel duch sein windows fanboying sabotiert“ gewählt? Mit Y2kbug hatte ich noch nie etwas zu tun, wie kommst du darauf? Das ist aber genau die Art von Unterstellung, die jedes Diskussionsklima vergiftet. Ich wäre überrascht, wenn sich das hier viele Leute freiwillig antun. Ich bin regelmäßig auf 3M zu finden und möchte nur helfen. Mein „billiger rethorischer Trick“ hat inhaltlich natürlich keine Aussagekraft, zeigt aber, dass der Benutzer offenbar zu kooperativem Handeln fähig ist. Letztlich ist Artikelarbeit immer eine Frage der WP:Belege. Falls es verschiedene Meinungen gibt, können die auch nebeneinander im Artikel dargestellt werden. Wir schreiben nicht Die Wahrheit™, sondern das, was reputable Veröffentlichungen schreiben. Gibt es die nicht, ist es vielleicht WP:Theoriefindung. Gruß --Winkekatze (Winken) 17:29, 19. Jun. 2026 (CEST)

In meinen Änderungen im Verlauf der Artikel sind zahlreiche belege und auf Diskussion:Textdatei sind alleine 20 links. Ich weiß auch nicht wieso du Editor als Ort ausgewählt hast, wenn der meiste Konflikt in Textdatei stattfand. Die Änderungen an Editor waren Erkenntnisse aus der Debatte um Textdatei. Im Grunde fand dort die große Diskussion statt und hier haben wir uns noch mal um den selben Kram gestritten, der dort schon erwähnt war. --~2026-33102-54 (Diskussion) 17:39, 19. Jun. 2026 (CEST)

Danke für den Hinweis, ich habe es hierher verschoben, das passt besser. --Winkekatze (Winken) 17:58, 19. Jun. 2026 (CEST)

Beide Meinungen nebeneinander finde ich auch nicht falsch. Ich bin im Grunde Inklusionist. --~2026-33102-54 (Diskussion) 17:44, 19. Jun. 2026 (CEST)

Der Grund wieso ich ihm das unterstellt habe ist, weil er sich auf der Textdateidiskussionseite über „Unix“ lustig gemacht hat, aber ich habe Unix nicht erwähnt und meiner Meinung nach haben heutig Systeme mit Unix wenig zu tun. --~2026-33102-54 (Diskussion) 17:54, 19. Jun. 2026 (CEST)

So, ich habe mich jetzt mal etwas intensiver mit der bisherigen Disk befasst. Meiner Meinung nach ist folgendes der Knackpunkt: Die Art von Belegen, die hier einen Stich machen könnten, wären „[...] wissenschaftliche Publikationen, insbesondere Standardwerke, begutachtete Veröffentlichungen und systematische Übersichtsarbeiten, die für das Fachgebiet des jeweiligen Lemmas relevant sind [..].“ (Wikipedia:Belege#Grundsätzliches, Punkt 1.).

Dies ist ein Lesenswerter Artikel (jedenfalls die Version von 2010), genügt also erhöhten Standards. Um hier etwas zu ändern, brauchst du schon sehr gute Belege. Ich kann nicht ausschließen, das mir etwas entgangen ist, aber oben wurde so etwas bisher nicht gebracht. Viele Links, aber eben keine Standardwerke. Als Beispiel wurde versucht, die Verwendung des Begriffs mit dem DWDS zu belegen. An sich eine gute Quelle, schlägt aber auf keinen Fall Fachliteratur. --Winkekatze (Winken) 18:38, 19. Jun. 2026 (CEST)

Danke. Mehr kann ich auch nicht dazu sagen. Ich habe etliche Male auf WP:BLG verwiesen. Und ich habe etliche Male um eine inhaltliche Diskussion gebeten. ‣Andreas•⚖ 19:26, 19. Jun. 2026 (CEST)

Ist der DWDS also nichts Wert? Schon wieder beharren und Belege verwerfen. Mag ich gar nicht. https://www.dwds.de/wb/Textdatei

Die englische Fachliteratur spicht von Plain Text und schränkt die Bedeutung von text file auch nicht immer ein, sondern nur da, wo eh schon von plain text gesprochen wird.

https://en.wikipedia.org/wiki/Talk:Text_file

Im englischen ist es genauso hart umkämpft, was text file ist, weil es einfach nicht genauer spekifiziert, was es ist.

Außerdem ist der Artikel Editor kein als lesenswert ausgezeichneter Artikel.

Und nichts davon hat mit dem BOM zu tun. Darüber haben wir am längsten geredet. Wir brauchen immer noch jemanden der eine Ahnung hat. --~2026-33102-54 (Diskussion) 20:13, 19. Jun. 2026 (CEST)

Nein. Wir brauchen Belege und müssen uns an die Regeln halten. Wenn dabei herauskommt, dass BOM nicht so wichtig ist, dann kann es im Artikel auch nur eine Randnotiz sein, oder man kann es ganz streichen (wegen fehlender Relevanz). Dies festzulegen obliegt einer sachlichen, inhaltlichen Diskussion, die hier aber bis jetzt komplett gefehlt hat. Du kannst den Text, den du einbringst, nicht mit Belegen stützen, die diesen Stellenwert gemäß unseren Regeln nun einmal nicht haben. Die Beweispflicht liegt am Autor, der den Text einbringt. Das hast du bist jetzt nicht getan. In einem solchen Fall ist es besser, dies nicht in den Artikel einzubringen. ‣Andreas•⚖ 20:20, 19. Jun. 2026 (CEST)

@ „Ist der DWDS also nichts Wert?“

Habe ich das geschrieben? Ich glaube nicht. Der „Wert“ einer Quelle bemisst sich am Kontext, also daran, was konkret damit belegt werden soll. Mit dem DWDS lässt sich belegen, dass eine Verwendung in einem bestimmten Sinne existiert, das war aber nicht die Frage, oder? Maßgeblich ist – wie gesagt – Fachliteratur. Gruß --Winkekatze (Winken) 23:50, 19. Jun. 2026 (CEST)

Was hab ich nicht alles gegeben an Fachliteratur. Golem, W3C, Unicodestandard. Wurde alles mit füßen getreten. Bilder vom Speicherdialog in Notepad in xp und 7. Der Microsoft Product Manager von Winget wie er auf github schreibt: „I don't see any reason to do extra work to support a BOM when it isn't required.“ und dann das Ding zumacht. --~2026-33102-54 (Diskussion) 20:21, 19. Jun. 2026 (CEST)

Zitat ist von hier.

https://github.com/denelon

https://github.com/microsoft/winget-cli/issues/5502 --~2026-33102-54 (Diskussion) 20:23, 19. Jun. 2026 (CEST)

Das hat er dann duch seine Bearbeitung meines Beitrags zu Editor verdreht, daß der Artikel aussagt, daß neue Software gerne und gut den UTF-8 BOM unterstützt. Das ist absolut gelogen und Tatsachenverdrehung --~2026-33102-54 (Diskussion) 20:25, 19. Jun. 2026 (CEST)

Ich finde es auch nicht in Ordnung, daß die brandneue RCE-Sicherheitslücke von diesem Jahr in Editor in eine Unterüberschrift verschoben wurde, um sie zu verstecken. --~2026-33102-54 (Diskussion) 20:32, 19. Jun. 2026 (CEST)

Die geschichte zu wann utf8 bom eingeführt wurde und wann utf8 ohne bom eingeführt wurde im notepad wurde auch aus geschichte entfernt obwohle es eigentlich eindeutig dort hingehört. Er will halt nicht, daß man darüber liest. Wieso auch immer. --~2026-33102-54 (Diskussion) 20:46, 19. Jun. 2026 (CEST)

Schau mal unter Editor (Windows)#Zeichenkodierungen und Zeilenendungen nach, erster und zweiter Absatz. ‣Andreas•⚖ 21:17, 19. Jun. 2026 (CEST)

Off-topic verschoben nach Diskussion:Editor (Windows)#Diskussion zur 3M. ‣Andreas•⚖ 22:49, 19. Jun. 2026 (CEST)