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.
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.
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.
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.
(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.)
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 ]
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 ]
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop