Warum normalisiert JTextComponent.setText (String) Zeilenendungen nicht?
Es ist mir kürzlich aufgefallen, dass Java-Textkomponenten Zeilenvorschubzeichen (LF, \n , 0x0A) verwenden, um Zeilenumbrüche intern darzustellen und zu interpretieren. Das war für mich eine Überraschung und setzt meine Annahme voraus, dass die Verwendung von System.getProperty('line.separator') überall unter einem Fragezeichen sinnvoll ist.
Es scheint so zu sein, dass Sie bei der Verwendung der angegebenen Eigenschaft sehr vorsichtig sein sollten, da Sie mit JTextComponent.setText(String) möglicherweise eine Komponente mit unsichtbaren Zeilenumbrüchen (z. B. CRs) erhalten. Dies scheint nicht so wichtig zu sein, es sei denn, der Inhalt der Textkomponente kann in einer Datei gespeichert werden. Wenn Sie den Text mit den Methoden, die von allen Textkomponenten bereitgestellt werden, speichern und in einer Datei öffnen, werden Ihre verborgenen Zeilenumbrüche plötzlich in der Komponente sichtbar, sobald die Datei erneut geöffnet wird. Der Grund dafür scheint zu sein, dass JTextComponent.read(...) method die Normalisierung durchführt.
Warum normalisiert JTextComponent.setText(String) Zeilenenden nicht? Oder eine andere Methode, mit der Text in einer Textkomponente verändert werden kann? Ist System.getProperty('line.separator') eine gute Übung, wenn Sie mit Textkomponenten arbeiten? Ist es überhaupt eine gute Übung?
Ein Code, der diese Frage relativiert:
%Vor%Ein Beispiel, was dieses Programm nach dem Hinzufügen einer neuen Textzeile auf meinem Windows-Rechner speichert (warum das einzelne CR? o_O):
Bearbeiten01
Ich habe es aus der Netbeans-IDE, die JDK1.7u15 64bit (C: \ Programme \ Java \ jdk1.7.0_15) unter Windows 7 verwendet, ausgeführt / debuggte.
2 Antworten
Zunächst lautet die wirkliche Antwort, dass die Designer auf diese Weise das Design für möglich hielten. Sie müssen wirklich sie fragen, um den wahren Grund (e) zu bekommen.
Nachdem ich das gesagt habe:
Also warum normalisiert JTextComponent.setText (String) Zeilenendungen nicht?
Ich denke, dass die wahrscheinlichsten Gründe sind:
-
Es wäre ein unerwartetes Verhalten. Die meisten Programmierer würden erwarten, dass 1 a 'get' für ein Textfeld den gleichen Zeichenfolgenwert zurückgibt, der 'gesetzt' war ... oder der Benutzer eingegeben hat.
-
Wenn sich Textfelder normalisiert haben, hätte der Programmierer große Schwierigkeiten, die Zeilenenden des Originaltextes in Vasen zu erhalten, wo dies wünschenswert ist.
-
Die Designer könnten ihre Meinung irgendwann geändert haben (vgl. das berichtete Verhalten der Methoden
readundwrite), die aus Kompatibilitätsgründen nicht in der Lage waren.
Wie auch immer, wenn Sie eine Normalisierung benötigen, gibt es nichts, was Ihren Code davon abhält, dies mit dem vom Setter abgerufenen Wert zu tun.
Oder eine andere Methode, mit der Text in einer Textkomponente geändert werden kann?
Es wird berichtet (siehe Kommentare), dass read und / oder write Normalisierung durchführen.
Verwenden Sie System.getProperty ('line.separator'), wenn Sie mit Textkomponenten arbeiten? Ist es überhaupt eine gute Übung?
Das hängt vom Kontext ab. Wenn Sie wissen, dass Sie Dateien lesen und schreiben, die auf dieser "Plattform" verarbeitet werden sollen, ist das wahrscheinlich eine gute Idee. Wenn die Datei auf einer anderen Plattform (mit einem anderen Zeilentrennzeichen) gelesen werden soll, ist es möglicherweise eine schlechte Idee, sie zu normalisieren, um sie an die Konvention des aktuellen Rechners anzupassen.
1 - Die Tatsache, dass andere Methoden wie read und write sich anders verhalten als , hat keinen Einfluss darauf. Sie sind keine "Getter" und "Setter". Ich spreche darüber, wie Leute von "Gettern" und "Setter" erwarten, dass sie sich verhalten ... nichts anderes. Außerdem sollten nicht erwarten, dass sich alles genauso verhält, es sei denn, es wird angegeben, dass dies der Fall ist. Aber offensichtlich ist der Teil des Problems hier, dass die Spezifikation ... die Javadocs ... zu diesen Fragen schweigt.
Die andere Möglichkeit ist, dass das von @predi berichtete Normalisierungsverhalten tatsächlich in den Reader / Writer -Objekten ...
Die Verwendung des Systemzeilentrenners ist fraglich. Ich würde nur verwenden, um Textdateien im plattformspezifischen Format zu schreiben.
Beim Lesen schleudere ich einfach jedes <\ r> weg (CR), um Windows / Mac / Unix in Unix-Stil-Zeilenumbrüche umzuwandeln. Intern würde ich niemals etwas anderes als '\ n' (LF) verwenden, um auf Zeilenumbrüche hinzuweisen - es ist eine Verschwendung von Speicher und macht die Verarbeitung von Text nur noch schmerzhafter.
Tags und Links java swing jtextcomponent