Question

今天我遇到了一个非常奇怪的textarea行为。一直在修复它，我仍然无法找到解决方案。非常感谢任何帮助，所以提前谢谢。

我正在创建一个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％0D％0Ac％0D％0Ac
因此它必须是c CrLf c CrLf c 但是，当我将未加密的var从FireBug（DevTools）复制到NotePad ++时，它向我展示了这一点：

c CRLF
的 CRLF
c CRLF
的 CRLF
c CRLF
的 CRLF

为什么它在解码格式中加倍？！当然，当我将结果从数据库打印回浏览器时，我得到了所有这些双断点。（当我通过“数据存储查看器”查看实体的TextProperty时，它被写成“c c c”）。

还有一件事：
我有一个Flash应用程序，它将发送请求发送到同一个python脚本，并且flash的文本框中的所有换行符都被正确写入。但是，如果我只是尝试通过浏览器界面中的textarea打开该数据库实体并保存它（不进行编辑），我会再次将所有换行符加倍。

有没有修复？

谢谢。

Answer 1

根据规范，在浏览器实践中，textarea中用户输入的换行符传输CR LF对，％ - 编码为％0D％0A。这很可能是你的服务器端脚本获得的，尽管你可以通过转储它获得的原始数据来验证这一点。然后会发生什么取决于您的脚本及其与数据库的交互。

在不同的操作系统和程序中有不同的换行约定，最常见的是单独的CR，单独的LF和CR LF对，最后一个是Internet练习。因此，似乎某些软件组件可能会将CR LF解释为两个单独的控制字符，每个控制字符都表示换行符，并且在稍后的某个时间点，每个控制字符都被规范化为CR LF（或者看起来像CR LF的东西））。

TextArea将所有换行符加倍

1 个答案: