什么会导致perl cgi脚本错误地将发布的表单数据解释为UTF-8编码？

我正在研究导致Perl CGI脚本向数据库写入错误值的错误的原因

这个perl脚本从另一个系统（不是浏览器）接收数据，该系统肯定使用ISO-8859-1编码。写入数据库时出现的错误数据如下所示：

Gro�Gr�nF�rbung�sterreich

应该是什么时候

GroßGrünFärbungÖsterreich

我发现我可以通过修改脚本使用

decode（'utf8'，$xyz）

而不是

$xyz

来创建这样一个错误的数据库条目。因此，我的问题是：是否有任何影响，例如HTTP头、环境变量、配置文件等，会导致perl CGI模块隐式地进行解码

原始源代码：

my $ack = new CGI;
my $xyz = $ack->param( 'xyz' );

在某些情况下，明显表现为：

use Encode qw(decode encode);
my $ack = new CGI;
my $xyz = decode('utf8',$ack->param( 'xyz' ));

---

您应该将来自perl程序本身外部的所有数据作为原始数据字节（八位字节）处理。如果随后使用假定的编码明确地对其进行

解码

，用perl（其本机格式）对其进行处理，并使用您希望的编码对其进行

编码

以将其放在程序之外（如您的情况下放在数据库中），那么您是安全的。其他一切都可能出错，正如你所看到的

---

当使用句柄（如文件或套接字）时，您可以通过使用PerlIO层来实现这一点，因此您不必明确使用解码/编码。

您应该很高兴没有

ẞ在那里。：）正如我所同意的，现在我很高兴能找到出问题的确切情况。您是否考虑过“损坏”发生在从perl到数据库的部分？你的DB编码是什么，你用什么来写它等等。。。如果输入肯定是iso-8859-1，那么您的DB编码也是吗？尤其是结尾的'-X'部分有时是罪魁祸首，这可能与utf8无关。只是一个想法。。。。。。当然，我也在一边说教喝水，一边喝酒——如果不必要的话，我几乎从不按我的建议去做。真丢脸。我也考虑过db层发生损坏的可能性，但如果这是原因，它可能会一直发生。嗯，也许这是数据处理中的一个操作，您将输入与启用utf8的字符串混合在一起（取决于不总是发生的操作）-将结果字符串升级为启用utf8标志的字符串。如果您的db编写例程使用此标志来决定其行为，这可以解释它。但在这一点上，这只是猜测的工作，对不起。