Delphi indy10 http服务器和ExtJS表单提交
我有一个问题我不知道如何解决。
我有一个 Indy10 HTTP 服务器。我在许多应用程序中使用过 Indy9 和 Indy10 HTTP 服务器,从未遇到过任何问题。但现在我使用 Indy10 HTTP 服务器和 ExtJS javascript RAI 框架。
问题是当我提交包含非 ansi 字符的数据时。例如,当我提交字母“č”,这是 1250 代码页中的一个字母(斯洛文尼亚语、克罗地亚语...)时,我在 Indy 中的“未解析参数”下得到以下内容 -> “%C4%8D”。这是 utf-8 编码中“č”字母的正确十六进制表示。我的所有页面都是 utf-8,并且向 Indy 提交表单数据时从未遇到过任何问题。我调试了代码,发现实际上得到了这样的字节序列:[37, 67, 52, 37, 56, 68]。这是字符串“%C4%8D”的字节表示形式。当然,Indy 无法将其正确编码为 UTF-16。举个例子。实际的表单字段:
FirstName=črt
提交时是这样的:
FirstName=%C4%8Drt
我不知道如何解决这个问题。我查看了 ExtJS 论坛,但没有关于这个主题的内容。有人知道这类问题吗?
编辑:
如果我对参数和 JSON 进行编码,它们会正确到达。我也尝试对参数进行 URL 解码,但结果不正确。也许我错过了什么。我会再看看这个。是的,ExtJS URL 似乎对参数进行了编码
EDIT2:
好的,我发现了更多。我对比了帖子数据的实际内容。它是这样的:
Delphi 2006 (Indy10): FirstName=%C4%8D
Delphi 2010 (Indy10): FirstName=%C4%8D
在这两种情况下,未解析的参数是相同的。我在 BDS2006 中打开了 ParseParams 它们被正确解析,但在 2010 下则不然。这是用 delphi 封装的 Indy10。这个版本有bug还是我做错了什么?
EDIT3:
我下载了 Indy10 的最新夜间版本。还是同样的问题。
EDIT4:
我被迫接受我自己的答案。
I have a problem I don't know how to solve.
I have an Indy10 HTTP server. I have used both Indy9 and Indy10 HTTP servers in many applications and never had any problems. But now I am using Indy10 HTTP server with ExtJS javascript RAI framework.
The problem is when I submit data that contains non-ansi characters. For instance when I submit letter "č" which is a letter in 1250 codepage (slovenian, croatian...) I get the following in Indy under "unparsed params" -> "%C4%8D". This is correct hexadecimal representation of the "č" letter in utf-8 encoding. All my pages are utf-8 and I never had any problems submiting form data to Indy. I debugged the code and saw that I actually get a sequence of bytes like this: [37, 67, 52, 37, 56, 68]. This is the byte representation of the string "%C4%8D". But of course Indy cannot encode this correctly to UTF-16. So as an example. The actual form field:
FirstName=črt
comes out like this when submited:
FirstName=%C4%8Drt
I don't know how to solve this. I looked at ExtJS forums, but there is nothing on this topic. Anybody know anything about this kind of problem?
EDIT:
If I encode params ad JSON they arrive correctly. I also tried to URL decode the params, but the result is not correct. Maybe I missed something. I will look at this again. And yes it seems that ExtJS URL encodes the params
EDIT2:
Ok, I have discovered more. I compared the actual content of the post data. It is like this:
Delphi 2006 (Indy10): FirstName=%C4%8D
Delphi 2010 (Indy10): FirstName=%C4%8D
In both case the unparsed params are identical. I have ParseParams turned on and in BDS2006
they are correctly parsed, but under 2010 they are not. This is Indy10 bulked with delphi. Is there a bug in this version or am I doing something wrong?
EDIT3:
I downloaded the latest nightly build od Indy10. Still the same issue.
EDIT4:
I am forced to accept my own answer.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我正在使用 Delphi 7 并迁移到 Indy 10。我发现葡萄牙语字符可能存在问题,并通过更改以下源解决了这个问题:
end;
I´m using Delphi 7 and migrate to Indy 10. I found likely problem with portuguese characters and solve this changing the source below:
end;
就这个话题来回答一下。
这绝对不能像在 unicode 下那样工作。 Indy 在内部使用 unicode 字符串。问题在于参数被解码为 TStringList 时。问题是
在“TIdHTTPRequestInfo.DecodeAndSetParams”中找到的行:。它无法正确解码参数,可能是因为它正在处理 unicode 字符串。
我发现的解决方法是使用“HTTPApp.pas”中的“HTTPDecode”。
但我无法相信这样一个常见的任务无法正常工作。有人可以确认这确实是一个错误还是我只是做错了什么?
To answer on this topic.
This is definitely not working as it should under unicode. Indy uses unicode strings internally. The problem is when parameters are decoded to TStringList. The problem is the line:
found in the "TIdHTTPRequestInfo.DecodeAndSetParams". It does not decode params correctly, probably because it is working over unicode strings.
The workaround I found is to use "HTTPDecode" from "HTTPApp.pas".
But I cannot believe that such a common task is not working correctly. Can someone confirm this is really a bug or am I just doing something wrong?
看起来该字符串是 URL 编码的,因此您使用以下代码进行解码:
编辑
似乎存在解码器无法将双字节正确解码为单个字符的情况。查看源代码,如果字符的编码类似于 %UC48D,它似乎确实可以正确解码,但在我的测试中,它仍然无法正确解码。有趣的是,TidURI.ParamsEncode 函数生成正确的编码,但在最新版本的 Indy 10 中使用正确的例程,该编码是不可逆的。
It appears the string is URL encoded, so you use the following code to decode:
edit
It appears there is a case where the decoder does not properly decode the double bytes as a single character. Looking at the source, it does appear that it would decode properly if the character is coded like %UC48D but in my testing this still does not decode properly. What is interesting is that the TidURI.ParamsEncode function generates the proper encoding, but this encoding is not reversible using the proper routines in the latest version of Indy 10.