TextArea 将所有换行符加倍
我今天遇到了 textarea 的一个非常奇怪的行为。 bug修复了一整天，还是没找到解决办法。将不胜感激任何帮助，所以提前致谢。
我正在创建一个 GAE-python 应用程序。 我这里有这个小表格：
<form action="/add" method="post">
<div><textarea name="Name" rows="1" cols="60">name</textarea></div>
<div><textarea name="Email" rows="1" cols="60">email</textarea></div>
<div><textarea name="Comments" rows="6" cols="60">comments</textarea></div>
<div><input type="submit" value="Post"></div>
</form>
我通过 POST 请求向 python 脚本发送数据（“评论”字段）。 但... 不知何故，我总是得到双换行符，或双 CrLf，最后存储在数据库中。 但奇怪的是，当我调试请求时，出现了一些奇怪的情况（在 FireFox+Firebug 和 Chrome+DevTools 中）。
例如，我通过文本区域编写并发送此评论内容：
c
c
c
在 url 加密数据中，我看到 c%0D%0Ac%0D%0Ac
所以它一定是 cCrLfcCrLfc
但是当我将未加密的 var 从 FireBug(DevTools) 复制到 NotePad++ 时，它向我显示：
c CRLF
CRLF
c CRLF
CRLF
c CRLF
CRLF
为什么解码后的格式是双倍的？！ 当然，当我将结果从数据库打印回浏览器时，我得到了所有这些双断线。 （当我通过“数据存储查看器”查看实体的 TextProperty 时，它被写为“cc c”）。
还有一件事：
我有一个 Flash 应用程序，它将后请求发送到同一个 python 脚本，并且 Flash 文本框中的所有换行符都被正确写入。 但是，如果我只是尝试通过浏览器界面中的文本区域打开该数据库实体并保存它（不进行编辑），我会收到所有换行符再次加倍。
有什么解决办法吗？
谢谢。
I've faced a really weird behaviour of textarea today. Have been bugfixing it for the whole day, and I still cannot find the solution. Would appreciate any help, so thanks in advance.
I'm creating a GAE-python app.
And I have this little form here:
<form action="/add" method="post">
<div><textarea name="Name" rows="1" cols="60">name</textarea></div>
<div><textarea name="Email" rows="1" cols="60">email</textarea></div>
<div><textarea name="Comments" rows="6" cols="60">comments</textarea></div>
<div><input type="submit" value="Post"></div>
</form>
And I'm sending data ("comments" field) via POST-request to python script.
But...
Somehow I always get double line-breaks, or double CrLf, in the end which are stored in the database.
But strangely when I debug the request there's something weird (both in FireFox+Firebug, and Chrome+DevTools).
For example I write and send this comments content via textarea:
c
c
c
In the url-encrypted data I see c%0D%0Ac%0D%0Ac
So it must be cCrLfcCrLfc
But when I copy the not-encrypted var from FireBug(DevTools) to NotePad++, it shows me this:
c CRLF
CRLF
c CRLF
CRLF
c CRLF
CRLF
Why is it doubled in the decoded format?!
And of course when I print the result back from Database to Browser I get all those double break-lines.
(when I look at this TextProperty of the Entity via "Datastore Viewer", it is written just as "c c c").
One more thing:
I'm having a flash app which sends post-requests to the same python-script, and all line-breaks made in flash's textboxs are written correctly.
But if I just try to open that database entity via textarea in browser-s interface and just save it (without editing) I receive all line-breaks doubled again.
Is there any fixes of that?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据规范和浏览器实践，文本区域中用户输入的换行符会传输 CR LF 对，% 编码为 %0D%0A。这很可能是您的服务器端脚本获取的内容，尽管您可以通过转储它获取的原始数据来验证这一点。接下来会发生什么取决于您的脚本及其与数据库的交互。
不同的操作系统和程序有不同的换行约定，最常见的是单独CR、单独LF、CR LF 对，最后一种是互联网惯例。因此，某些软件组件似乎可能会将 CR LF 解释为两个单独的控制字符，每个控制字符都表示换行符，并且在稍后的某个时刻，每个控制字符都被规范化为 CR LF （或看起来像 CR LF 的东西） ）。
By the specifications, and in browser practice, a newline in user input in textarea as transmitted a CR LF pair, %-encoded as %0D%0A. Most probably this is what your server-side script gets, though you could verify this by dumping out the raw data it gets. What happens then is up to your script and its interaction with the database.
There are varying newline conventions in different operating systems and programs, the most common being CR alone, LF alone, and CR LF pair, and the last one is the Internet practice. So it seems probable that some software component(s) then interpret CR LF as two separate control characters, each of which indicates a line break, and at some later point each of these is canonicalized to CR LF (or something that looks like CR LF).