今天我遇到了一个很奇怪的textrain行为。一整天都在修复它,但我还是找不到解决方案。非常感谢您的帮助,所以提前谢谢。在
我正在创建一个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脚本发送数据(“comments”字段)。 但是。。。 不知怎么的,我总是得到两个换行符,或者两个CrLf,最后存储在数据库中。 但奇怪的是,当我调试请求时,有一些奇怪的东西(在FireFox+Firebug和Chrome+DevTools中都有)。在
例如,我通过textarea编写并发送评论内容:
c
c
c
在url加密数据中,我看到c%0D%0Ac%0D%0Ac
所以它必须是cCrLfcCrLfc
但当我将未加密的var从FireBug(DevTools)复制到NotePad++时,它显示了以下内容:
cCRLF
CRLF
cCRLF
CRLF
cCRLF
CRLF
为什么它在解码格式中翻倍?! 当然,当我把结果从数据库打印回浏览器时,我会得到所有的双折线。 (当我通过“datastoreviewer”查看实体的这个TextProperty时,它被写成“c c c”)。在
还有一件事:
我有一个flash应用程序,它向同一个python脚本发送post请求,并且flash的textbox中的所有换行都被正确地写入。
但是,如果我尝试通过browser-s界面中的textarea打开该数据库实体并保存它(而不进行编辑),那么我收到的所有换行符都会再次加倍。在
有什么解决办法吗?在
谢谢。在
根据规范,在浏览器实践中,用户在textarea中输入一个换行符,作为一个crlf对,%-编码为%0D%0A。这很可能就是您的服务器端脚本得到的结果,尽管您可以通过转储它获得的原始数据来验证这一点。接下来会发生什么取决于脚本及其与数据库的交互。在
在不同的操作系统和程序中有不同的换行约定,最常见的是CR-lone、LF-alone和crlf-pair,最后一种是Internet实践。因此,一些软件组件很可能会将crlf解释为两个独立的控制字符,每个字符都表示一个换行符,然后在某个时候,每个字符都被规范化为crlf(或者看起来像crlf的东西)。在
相关问题 更多 >
编程相关推荐