I found the problem to be the different in line feeds. The testers were cutting and pasting from a Word Document into the HTML form. I believe the line feeds from Windows is a "\r\n". Javascript doesn't count the \r as an extra character where Perl and Oracle do. Removing the\r seemed to solve the problem. | [reply] |
I believe the line feeds from Windows is a "\r\n"
That also happens to be the line feed used by the HTTP protocol (officially, anyway -- most HTTP servers and clients will accept simple \n line feeds, but it's not 100% correct). Your web client is probably where the \r\n line feeds are coming from in this case, not necessarily Windows.
| [reply] |
Newlines
In most operating systems, lines in files are terminated by newlines.
Just what is used as a newline may vary from OS to OS. Unix tradition-
ally uses "\012", one type of DOSish I/O uses "\015\012", and Mac OS
uses "\015".
Perl uses "\n" to represent the "logical" newline, where what is logi-
cal may depend on the platform in use. In MacPerl, "\n" always means
"\015". In DOSish perls, "\n" usually means "\012", but when accessing
a file in "text" mode, STDIO translates it to (or from) "\015\012",
depending on whether you're reading or writing. Unix does the same
thing on ttys in canonical mode. "\015\012" is commonly referred to as
CRLF.
So to be picky a "\r\n" on Windows should give you "\015\015\012" and not "\015\012".
s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
| [reply]
[d/l]
[select] |