在 Perl 中保留 CGI 输入的加号答案

【问题标题】：Preserve plus signs from CGI input in Perl在 Perl 中保留 CGI 输入的加号
【发布时间】：2023-03-27 05:30:01
【问题描述】：

我正在开发一个包含多个表单的 Web 应用程序，用户需要在这些表单上输入通常包含空格和/或加号的数据。

数据一般通过GET请求发送；或通过带有application/x-www-form-urlencoded Content-Type 标头的POST 请求。

我尝试过使用 Perl 的 CGI 模块中的 Vars() 和 param，但这两种方法都坚持将 + 符号转换为空格。

CGI 模块是否提供任何机制来保留+ 标志；还是我应该放弃CGI 并手动解析STDIN 输入？

注意：
由于有大量的表格（超过一百个），并且 CGI 预处理发生在一个集中的实用程序库中，我非常偏向于服务器端解决方案而不是客户端方法（换句话说，我'宁愿在预处理代码上处理一次问题，也不愿在数百个地方添加 JS 噪声）。

提前感谢您提供的任何帮助。

示例：
根据 cmets 的要求，这里是一些触发问题的代码的（简化）示例。

HTML

<form action="/cgi-bin/some-script.pl">
    <input name="some_field" value="1 + 1 is 2">
    <input name="submit" type="submit" value="Submit">
</form>

Perl

use CGI;
my $some_variable = CGI::param('some_field');

用默认值提交表单并运行服务器端代码后，$some_variable的值为"1 1 is 2"（1之间有3个空格，可以是SO站点也可以是浏览器将它们折叠成一个空间）; 期望的结果是在该变量中获得值"1 + 1 is 2"。

【问题讨论】：

也许您可以发布一个最小的 sn-p 代码来说明导致此问题的步骤。
您可以简单地将+ 符号编码为%2B，然后再将其传递给CGI。
@dgw：感谢您的建议，但是这可以在服务器端完成而无需预处理整个输入吗？如问题中所述，服务器端解决方案优于客户端；如果我必须对 perl 脚本中的整个输入进行预处理，那也不会比一直手动解析它好多少。

标签： perl cgi

【解决方案1】：

CGI 参数中的加号表示空格。这在 CGI 规范中。任何向您发送加号以表示其他任何内容的 HTTP 客户端都已损坏。任何处理加号以表示其他任何内容的 HTTP 服务器都已损坏。

所以问题不在于您的 CGI 程序（它正在做正确的事情）。问题出在 HTTP 客户端中，它向您发送加号，打算将它们解释为加号。在 CGI 程序中将加号作为参数发送的正确方法是将其编码为 %2B。这就是你需要解决的问题。

更新：我在 Ubuntu 上使用 Apache 运行了一个简单的测试。

我的 HTML 文件如下所示：

<html>
  <head>
    <title>Test</title>
  </head>
  <body>
    <h1>Test</h1>
    <form action="/cgi-bin/param">
      <input name="some_field" value="1 + 1 is 2">
      <input name="submit" type="submit" value="Submit">
    </form>
  </body>
</html>

我的 Perl 程序如下所示：

#!/usr/bin/perl

use strict;
use warnings;
use 5.010;

use CGI qw[header param];

print header(-type => 'text/plain');

for (param) {
  say "$_ -> ", join ':', param($_);
}

当我访问该页面并点击“提交”按钮时，浏览器转到 URL http://localhost/cgi-bin/param?some_field=1+%2B+1+is+2&submit=Submit 并显示以下内容：

some_field -> 1 + 1 is 2
submit -> Submit

这看起来像我期望看到的行为。浏览器在将加号发送到浏览器时将其正确编码为 %2B。当我访问 Perl 的 CGI 模块时，它会解码该值。

您需要找出您的浏览器（或您用来发送这些请求的任何其他客户端）未遵循 CGI 规范的原因。

【讨论】：

谢谢！经过一些跟踪，似乎整个应用程序中容易包含任何不常见字符的所有字段都在提交之前由一些 JS 进行了预处理。那个 JS 确实是坏了。我想这将归结为修复（并且，为了理智，重构）这几百个脚本。