Using Oracle 11g, CF 10.
I'm trying to understand how and why CF/Oracle is changing saved paragraphs. If the following content is saved into a clob field, from a textarea input:
This is paragraph 1.
This is paragraph 2.
This is paragraph 3.
When output to the page, using:
<p>
<cfoutput>#ParagraphFormat(myTable.myCLOBfield)#</cfoutput>
</p>
It is formatted like so:
This is paragraph 1. This is paragraph 2.
This is paragraph 3.
When I copy the saved filed directly from the results of a query and paste it into Notepad,
with View All Characters turned on, I can see that the formatting is the same as the original input, and that all CRLFs are where I expect to see them.
It seems like Oracle is converting the CRLFs into chr(10)s. Using
regexp_replace(myCLOBfield, chr(13) || chr(10), 'HEY', 1, 0) myCLOBfield
doesn't result in anything being replaced. However, using
regexp_replace(myCLOBfield, chr(10), 'HEY', 1, 0) myCLOBfield
does find all CRLFs and replaces them with 'HEY'. But I'm mystified why pasting the contents into Notepad then shows CRLFs and formats them properly, while ParagraphFormat loses the first line break.
It seems like the most consistent solution is to replace all double chr(10)s with singles, and then replace all single chr(10)s with doubles, so I always get a double line break, and all new paragraphs are separated by a single line. I did it like so:
regexp_replace(regexp_replace(myCLOBfield, chr(10) || chr(10), chr(10), 1, 0), chr(10), chr(10) || chr(10), 1, 0) myCLOBfield
which results in the following (acceptable) formatting:
This is paragraph 1.
This is paragraph 2.
This is paragraph 3.
Anybody have a better idea of how to retain the original formatting?
Related
I'm creating an ssrs form in oracle sql on which I need to list an address. New lines have to remain in the address however I can't find the way of removing new lines at the end of the address.
Example of what I have:
10 Donkey Kong,
London,
XX1 1XX
new line
new line
Example of what I want:
10 Donkey Kong,
London,
XX1 1XX
Oracle version: 11g - release 11.2
I tried already:
trim(both chr(10) from (trim(both chr(13) from a.address)) - it doesnt make any difference
substr(a.address,1,length(translate(a.address,'d'||chr(10)||chr(13),'d'))) - translate checks how many spaces is in the whole address and substring only returns part of the address because it cuts more than it should
Thanks
Found an answer :D
Regex to the rescue.
regexp_replace(a.address,'[' || chr(10) || chr(13) || ' ]+$', '')
I would still like to know why trim didn't work. Any idea ?
You might be able to use REGEXP_REPLACE here with the pattern \s+$ here:
UPDATE yourTable
SET address = REGEXP_REPLACE(address, '\s+$', '');
I can speculate a few reasons why your trim approach is failing. First of all, perhaps not every column value has CRLF (CHR(10) || CHR(13)). Instead, it could have a Linux line ending, which is just CHR(13). Or, there could be other types of whitespace present at the end. The answer I gave is simpler and should cover you in all edge cases.
I am generating a CSV file from a Microsoft SQL database that was provided to me, but somehow there are invalid characters in about two dozen places throughout the text (there are many thousands of lines of data). When I open the CSV in my text editor, they display as red, upside-down question marks (there are two of them in the attached screenshot).
When I copy the character and view the "find/replace" dialog in my text editor, I see this:
\x{0D}
...but I have no idea what that means. I need to modify my script that generates the CSV so it strips these characters out, but I don't know how to identify them. My script is written in Classic ASP.
You can also use RegEx to remove unwanted characters:
Set objRegEx = CreateObject(“VBScript.RegExp”)
objRegEx.Global = True
objRegEx.Pattern = “[^A-Za-z]”
strCSV = objRegEx.Replace(strCSV, “”)
This code is from the following article which explains in details what it does:
How Can I Remove All the Non-Alphabetic Characters in a String?
In your case you will want to add some characters to the Pattern:
^[a-zA-Z0-9!##$&()\\-`.+,/\"]*$
You can simply use the Replace function and specify Chr(191) (or "¿" directly):
Replace(yourCSV, Chr(191), "")
or
Replace(yourCSV, "¿", "")
This will remove the character. If you need to replace it with something else, change the last parameter from "" to a different value ("-" for example).
In general, you can use charmap.exe (Character Map) from Run menu, select Arial, find a symbol and copy it to the clipboard. You can then check its value using Asc("¿"), this will return the ASCII code to use with Chr().
When entering 'a' in Gforth, the ASCII number of the character (the same number which would be put onto the stack by using the key word and pressing a) is put onto the stack.
This does not work for example with ' ' (space). Instead:
' ' ok
.s <1> 34384939008 ok
The number “should” be 32. What explains this behavior? And what can be done about it – aside from manually putting the ASCII number corresponding to ' ' (space) on the stack?
This 'a' syntax is quite new to Forth. It's added as an extension on top of the traditional syntax which parses everything into whitespace-delimited tokens. So 'a' is one atomic token, which is then parsed as a character literal.
Now, ' ' isn't an atomic token, since it contains a space character. Rather, it's parsed as two ' tokens. It's actually perfectly valid Forth code, because ' is a Forth word (called "tick"). In your example, the first tick operates on the second. The result, 34384939008, is the xt for '.
What to do instead? The traditional words for getting the ASCII code of a character is CHAR or [CHAR]. The first works in interpreted mode, and the second in compiled mode. BUT they don't work for the particular case of the space character, because again, all whitespace is parsed away.
However, there is another word which pushes the ASCII code space character: BL.
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.
I know line feeds in Foxpro are CHR(10) + CHR(13), but when creating an import record comma delimited, I need to imbed the line feed into the field, when I add the CHR(10) + CHR(13) into the .txt file it puts an actual line feed into the import record rather than being embeded.
Any examples of syntax you can give me:
** This example does not work! can I get an example of how to embed these line feeds correctly?
Sam Jenkins + CHR(13) + CHR(10) + Address1 + CHR(13) + CHR(10) + Address2
Thanks - Evan
Maybe I don't understand the ops question but....
ASCII encoding:
CHR(10) = Newline/Linefeed
CHR(13) = Carriage return
Most text file viewers will will move the cursor down one line and to the left margin when they encounter a CHR(13)CHR(10). Your file may be correct, it's just that whatever you are using to view it is respecting the characters. If the text was quote enclosed and the viewer respected that, you might get the display you want otherwise the viewer wouldn't know when a CrLf is embedded or the real end of line.
Sorry, you're not going to get around text files representing linefeed+carriage return as anything other than what they are. I'd suggest some sort of workaround. Maybe you can encode them like C does, "\n" would work fine in VFP and a text file. You'd have to decode it in the consuming application though.
Your specific example seems very strange. If I was writing a comma delimited file, I'd seperate the fields with commas "Name, Addr1, Addr2" instead of lfcr. Then VFP would import that with a simple append from x type csv.
If you're trying to read from a file where the fields are seperated onto different lines, you're going to have to do more work. If you're lucky, the file always uses the same number of fields and you can just count line numbers to know which field you're on. (line 1 is name, line 2 is addr1, line3 addr2, line4 city-state-zip, line5 next name...) If that was the case, I'd use a loop and some local variables and then gather them into a blank table row.