i am required to simulate a carriage return (0A) to save into the database from a web application so that i can prove that the system is not cleaning data causing some issues, this needs to be entered in the browser as a plain text, are we able to do this?
I don't know what you are trying to achieve, but here's an article that uses CHAR() function in SQL query http://msdn.microsoft.com/en-us/library/ms187323.aspx
insert into mytable(mytext) values('Dear Sir:' + CHAR(13)+CHAR(10) + 'This is')
Line feed char(10)
Carriage return char(13)
Line feed char(10) is correct
Carriage return char(13) is giving issues.
From this question: What character represents a new line in a text area
By HTML specifications, browsers are required to canonicalize line
breaks in user input to CR LF (\r\n).
Hence, you can't insert any other style of newline through a browser.
Related
I receive a file from internet, and the lines are separated by 0x0D char
I display it using this tool
https://www.fileformat.info/tool/hexdump.htm
When I read that file into Rexx using "linein()", all the file comes into one sigle line. Obviously linein() works fine when file has 0x0D0A as End Of Line char.
How do I specify to Rexx to split lines using 0x0D char instead of 0x0D0A ?
Apart from getting the file sent to you with proper CRLF record markers for Windows instead of the LF used in Unix-like systems there are a couple of ways of splitting the data - but neither will read the file a record at a time but will extract each record from the long string read in.
1 - Use WORDPOS to find the position of the LF and SUBSTR to remove that the record
2 - Use PARSE to split the data at the LF position
One way to read one record at a time is to use CHARIN to read a byte at a time until it encounters the LF.
I've read that to use fflush() function in oracle, every line in the output should end with a new line character. Will put_line() automatically introduce a new line character that needs fflush() to work ?
What is the new line character (\r\n or \n or depends on OS) that fflush() needs ? And what is the new line (\r\n or \n or depends on OS) character that put_line() introduces if at all it does ?
Yes, put_line() adds the required new line character(s). From the documentation for put_line():
This procedure writes the text string stored in the buffer parameter to the open file identified by the file handle. The file must be open for write operations. PUT_LINE terminates the line with the platform-specific line terminator character or characters.
That's really the difference between put() and put_line():
No line terminator is appended by PUT; use NEW_LINE to terminate the line or use PUT_LINE to write a complete line with a line terminator.
It's slightly confusing that the description of fflush() refers to just "a newline character" while put_line() refers to "line terminator character or characters", but they do mean the same thing - to flush the buffer must end with the operating-system line terminator character(s).
Note that it means the database server's operating system, not your client operating system, since utl_file (and all PL/SQL) is on the server and doesn't know anything about the client environment. It's generally safer to use put_line() or new_line() than to manually add \n or \r\n; even if you know the OS your database is running on now, it may move to a different OS one day.
There are lots of questions asking what the correct order of the carriage return and new line characters is on Windows (it's \r\n) but I have not found any real explanation as to why this is the case.
\n is the new line character, and \r is carriage return. So, if you have \r first, which returns the cursor to the beginning of the current line - and then \n afterwards, wouldn't that logically insert the \n at the beginning of the current line and just move the current line down one instead of creating a line after?
I mean I understand that when simply writing these to a file it doesn't really matter, but when parsing/reading and outputting the text, it seems backwards to me.
The order is a homage to the typewriter days.
Early mechanical printers were too slow to return the carriage in the time it took to process one character. Therefore the time spent sending the line feed was not wasted (often several more characters had to be sent to ensure the carriage return had happened before sending a printing character). This is why the carriage return was always sent first.
Link: http://en.wikipedia.org/wiki/Carriage_return
I am pasting text from a windows plain text file to a text_area. The following regex works on that text in rails only when I manually remove the CRLF line returns from the text in wordpad:
#scan.raw.scan(/(?<=stamps\|\|[a-z,0-9,A-Z])(.*?)(?=\|time)/).each do |body|
The gsub I found in various forums to remove line endings is leaving something behind that confuses the regex:
(from the model)
before_create :remove_returns
def remove_returns
#get rid of pesky carriage returns
raw.gsub!(/\r\n?/, "")
end
The line returns show as CRLF when I open the plain text file in question in Notepad++.
Another clue: the output from the rails console when I call the object shows the line returns as some kind of tab-like character, or maybe two spaces, but when I view the object in the show view in the browser it appears as though the character has been removed, even though the regex still does not function.
The problem turned out to be that I was removing the line endings with a before_create method in the model, followed by another method (also before_create) that was relying on having the line endings removed. I performed the action in the controller followed by a "save!" instead.
def create
#scan = Scan.new(params[:scan])
#eliminate pesky carriage returns
#scan.raw.gsub!(/\r\n?/, "")
#scan.raw.gsub("\u000a","")
#scan.raw.gsub!("\u000d","")
#scan.raw.gsub!("\u0009","")
#scan.raw.gsub!("\u000c","")
#scan.raw.gsub!("\u0085","")
#scan.raw.gsub!("\u2028","")
#scan.raw.gsub!("\u2029","")
#scan.raw.gsub!(/0A\0A/u,"")
#scan.save!
I am using SAS's FILE statement to output a text file having fixed format (RECFM=F).
I would like each row to end in a end-of-line control character(s) such as linefeed/carriage return. I tried the FILE statement's option TERMSTR=CRLF but still I see no end-of-line control characters in the output file.
I think I could use the PUT statement to insert the desired linefeed and carriage return control characters, but would prefer a cleaner method. Is it a reasonable thing to expect of the FILE statement? (Is it a reasonable expectation for outputting fixed format data?)
(Platform: Windows v6.1.7600, SAS for Windows v9.2 TS Level 2M3 W32_VSPRO platform)
Do you really need to use RECFM=F? You can still get fixed length output with V:
data _null_;
file 'c:\temp\test.txt' lrecl=12 recfm=V;
do i=1 to 5;
x=rannor(123);
put #1 i #4 x 6.4;
end;
run;
By specifying where you want the data to go (#1 and #3) and the format (6.4) along with lrecl you will get fixed length output.
There may be a work-around, but I believe SAS won't output a line-ending with the Fixed format.