Pourquoi une chaîne renvoyée par un objet JTextField ne reconnaît-elle pas les caractères spéciaux?

Question

Donc, je ne faisais que déconner avec certains JTextFields, en essayant d'imprimer ce que je tapais sur eux sur un retard, y compris les caractères spéciaux. J'ai utilisé un javax.swing.Timer pour utiliser l'ActionListener.

public void actionPerformed(ActionEvent arg0) { 
    // inputs is an array of 10 JTextFields 
    for(int i = 0 ; i < inputs.length;i++) 
    { 
     System.out.println(inputs[i].getText().toString()); 
    } 
    System.out.println("\n\n"); // space between each print to the console 
} 

Mais la console finit par imprimer exactement ce qui est dans le JTextField. (Par exemple, au lieu d'imprimer une nouvelle ligne, il imprime juste \ n) Le texte gauche est ce qui est imprimé à la console, et le droit est le JTextFields contenu dans les «entrées».

Avez-vous besoin de faire quelque chose de spécial avec JTextFields?

Answer 1

Il n'y a pas de caractères spéciaux ici. La seule chose en Java qui traduirait vos séquences d'échappement en les caractères spéciaux correspondants est le compilateur, si elles se sont produites dans les littéraux de chaîne.

Answer 2

J'ai écrit un petit test pour déboguer, et je vois ce que vous décrivez (non dans JTextField, mais dans Scanner, mais le symptôme est similaire). Le résultat dans deux situations semble incohérent, mais nous pouvons en savoir un peu plus sur le mécanisme de traitement et d'échappement des caractères Java.

package com.WindThunderStudio.PrintLine; 

import java.util.Scanner; 

public class Tester { 
    public static void main(String[] args) { 
     System.out.println("Line 1"); 
     System.out.println("\n"); 
     System.out.println("Line 2"); 
     //output: 
     //  Line 1 
     // 
     // 
     // 
     //  Line 2 
     Scanner scanner = new Scanner(System.in); 
     while (scanner.hasNextLine()) { 
      System.out.println(scanner.nextLine()); 
     } 
     //output: "\n" for "\n", no line feed added. 
    } 
} 

Certains débogage nous amène à savoir que lors de l'exécution de la ligne de

System.out.println("\n"); 

la chaîne est traitée sans échapper, par exemple,

[<line_feed>] 

, si l'on regarde dans le débogueur Java Panneau "Variable" lorsque nous sommes dans le code source de JDK. Rien de cette chaîne n'est changé, donc aucun symbole n'est échappé.

Cependant, quand on lit l'entrée du Scanner, (dans cette situation, je suppose qu'il est très bien aussi bien avec votre cas, parce que la lecture de Scanner et de JTextField sont à la fois l'entrée utilisateur lecture du flux System.in standard, et produire les même « incompatibilité »), la chaîne « \ n » seront traités comme

[\\, n] // (the char '\' is escaped properly) 

, et aucun saut de ligne est détecté. Être plus concret, nous parlons de la méthode write(String s) dans la classe java.io.PrintStream:

private void write(String s) { 
    try { 
     synchronized (this) { 
      ensureOpen(); 
      textOut.write(s); 
      textOut.flushBuffer(); 
      charOut.flushBuffer(); 
      if (autoFlush && (s.indexOf('\n') >= 0)) 
       out.flush(); 
     } 
    } 
    catch (InterruptedIOException x) { 
     Thread.currentThread().interrupt(); 
    } 
    catch (IOException x) { 
     trouble = true; 
    } 
} 

Parce que le caractère « \ » est automatiquement échappé, il ne sera pas liée à « n » et rien comme " \ n "est détecté, donc aucun nouveau saut de ligne n'est ajouté et l'entrée est imprimée telle quelle.

Il me rend curieux fait maintenant pourquoi traiter JDK ces deux sources de caractères de façon différente, et je suppose que lors de l'impression avec un Java String à partir du code, le compilateur Java voit déjà bien échappé (si l'on ajoute des caractères spéciaux dans une String, il faut leur échapper correctement pour passer la compilation, tu te souviens?). Mais pour l'entrée de l'utilisateur, il est donc plus important de leur échapper tel quel, de ne pas vérifier sa "signification" dans le système.