[java]Newline character probleem

[JvdS]

Ben op dit moment bezig met een klein client/server programmaatje.
Probleem is nu, dat als er vanaf de client een enter verstuurt wordt, dit in de stringTokenizer terecht komt. Ik wil het kunnen afvangen dat men alleen een enter kan sturen.

stukje code:

code:

BufferedReader in = new BufferedReader(new InputStreamReader(client.getInputStream())); 
String line;                            
while ((line = in.readLine()) != null) 
{ 
   if (!(line.equals("\\n")))
   {
      System.out.println ("line = [" + line + "]");
      ...

Helaas lukt me dit niet. Iemand enig idee?

[djluc]

Misschien heeft het iets met het verschil tussen \n en \r te maken? In PHP regelt de functie trim() dit sort dingen overigens. Die zal er voor java ook vast wel zijn.

[ Voor 43% gewijzigd door djluc op 08-06-2004 21:29 ]

[Alarmnummer]

djluc schreef op 08 juni 2004 @ 21:27:
Misschien heeft het iets met het verschil tussen \n en \r te maken?

\r\n (of andersom) natuurlijk ook niet vergeten he (windows)


Verder check jij trouwens op het voorkomen van \\n en niet op het voorkomen van een \n. Haal er dus 1 \ vanaf en probeer het nog een keer.

[Robtimus]

Uit de API:

public String readLine() throws IOException

Read a line of text. A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed.

Returns:
A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached
Throws:
IOException - If an I/O error occurs

Als je alleen een enter stuurt, levert readLine dus de lege string "".

[ Voor 5% gewijzigd door Robtimus op 08-06-2004 21:36 ]

[misfire]

De methode "in.readLine()" leest een hele regel in, maar niet de line separators (die worden overgeslagen in de opeenvolgende readLine() aanroepen).

Wat in je StringTokenizer terecht komt is dus gewoon een lege string, en niet die newline. Waarschijnlijk gebruik je hier de methode hasMoreTokens() niet voordat je nextToken() doet. Je kunt ook met "(!(line.trim().equals("")" testen op een lege string, waarbij spaties getrimd worden.

[JvdS]

misfire schreef op 08 juni 2004 @ 21:37:
Je kunt ook met "(!(line.trim().equals("")" testen op een lege string, waarbij spaties getrimd worden.

Juist, dat was de oplossing.
Vriendelijk bedankt!

Mod, slotje?

[pjvandesande]

JvdS schreef op 08 juni 2004 @ 21:40:
Mod, slotje?

We sluiten intresanten topics toch niet! Is altijd makkelijk als iemand de search gebruikt en het probleem ook heeft, maar toch nog een vraag.

[Alarmnummer]

Precies.. en als alle topics op slot gingen waar een topicstarter zijn antwoord heeft gevonden.. hadden wij geen topics meer om te kapen

[ACM]

Nog wat kleine, nu niet relevante, denkfoutjes:
"\\n" is expliciet een \ en n
"\n" is een newline-teken, je equals zal nooit dat newline-teken matchen als je probeert "\\n" te matchen met 'newline'

Verder is het handig om het resultaat van System.getProperty("line.separator"); op te halen en te gebruiken voor je vergelijking.

[Alarmnummer]

ACM schreef op 09 juni 2004 @ 10:47:
Verder is het handig om het resultaat van System.getProperty("line.separator"); op te halen en te gebruiken voor je vergelijking.

De server weet niet welke line separator de client gebruikt. En verder is dat nog geen garantie. Ik heb in mijn editor ingesteld dat een enter een \n is maar toch zit ik wel onder windows.

[ Voor 22% gewijzigd door Alarmnummer op 09-06-2004 13:35 ]