Problem with linefeed

[Kasi Gadde]

Hi Guys,
I have a problem with linefeed character. In my application users entered data in the text box(JSP) and while saving in oracle database linefeed characters got appeneded to the data. Is there any chance we can enter linefeed character through JSP textbox. I am not able to re-produce the same. I appreciate any help.

Best Regards,
Kasi Gadde

[Bear Bibeault]

Please do all of our eyes a favor and adjust your display name to be mixed or lower case. The all uppercase is rather jarring.

There is no way the user can enter a newline into a text input. Even if cut/paste is used, the browser will either truncate the paste at the newline, or substitute spaces for them.

Are you sure it's a text input that you're talking about? Text areas do allow newlines.
[ July 31, 2008: Message edited by: Bear Bibeault ]

[Bear Bibeault]

P.S. There is no such thing as a "JSP text box". It's all HTML.

[Kasi Gadde]

Thanks a lot. If I give tabs in the textbox then square boxes are appended to the string but as you said I am not able to enter new line characters.
Ofcourse its HTML text box, I accept friend.

[Bear Bibeault]

So where are the linefeeds (or newlines -- they're not the same character, by the way) coming from? It's highly unlikely they're coming from the form submit (here's an exercise: how can you find out for sure?). Looks like it's time to trace through your code finding the point at which the unwanted characters appear.

[Kasi Gadde]

Even I wanted to go through the code to find out from where this linefeed or newline has come. I am sure its a new line because when I copy that value from the table and paste it in the editor the cursor moved to the next line. Because of this day-end programs got failed. I will find sometime this week-end to go through the code. I am thankful for your replies.

[Tom Katz]

I have a textarea in a JSP which will display message data bytes as strings. This is an MQ message editor. What I'm finding is that if the bytes '0A' are present in the message data, they'll display the same as if the bytes are '0D 0A'.

Everything's fine until the user posts the form - then any end_of_lines (sorry if my wording's off) are translated to '0D 0A'. In the case where the original bytes were '0A' that means extra bytes are added to the message data.

Not sure if this is a java, encoding, or HTML issue (or none, or all

Any insight would be appreciated.

thanks,
Tom

(PS: Not to hijack this thread or anything, but I believe I'm having nearly the same issue, and rather than opening a new topic, thought I'd try in here since it's pretty recent - if bad form, please let me know.)

[Ulf Dittmer]

Tom,

0D is a carriage return, while 0A is a linefeed (a.k.a newline). While Unix uses only a linefeed to indicate a line break, Windows uses a carriage return followed by a linefeed. So you may well see both versions in different places, although they really mean the same thing. Most applications understand this problem, and can work with either variant, but some still don't.

I can't tell from your post whether this is causing an actual problem, though, or if it's just a nuisance.
[ August 15, 2008: Message edited by: Ulf Dittmer ]

[Tom Katz]

Thanks Ulf, Yes, I'm learning a lot about control characters today.

It is more than a nuisance since the actual data length of the message is changed when this occurs. There is also a hex editor that when used, can deal correctly with the values. It's just an issue that the textarea, when posted, converts any line breaks into the CR/LF version. Currently it has no way to know what the original bytes were. I"m wondering if my pageEncoding value, if changed, could alter this behavior. Maybe base it off the MQMD.Encoding value of the original message.
[ August 15, 2008: Message edited by: Tom Katz ]