I'm using Delphi XE2 and Indy 10.5.8.0. I have an instance of TIdHttp and I need to add a custom header to the request. The header value has commas in it so it's getting parsed automatically into multiple headers. I don't want it to do that. I need the header value for my custom header to still be one string and not split based on a comma delimiter.
I have tried setting IdHttp1.Request.CustomHeaders.Delimiter := ';' with no success. Is there a way to make sure the header doesn't get split up?
procedure SendRequest;
const HeaderStr = 'URL-Encoded-API-Key VQ0_RV,ntmcOg/G3oA==,2012-06-13 16:25:19';
begin
IdHttp1.Request.CustomHeaders.AddValue('Authorization', HeaderStr);
IdHttp1.Get(URL);
end;
I am not able to reproduce this issue using the latest Indy 10.5.8 SVN snapshot. The string you have shown gets assigned as a single line for me.
With that said, by default the TIdHeaderList.FoldLines property is set to True, and lines get folded on whitespace and comma characters, so that would explain why your string is getting split. Near as I can tell, there have not been any logic changes made to the folding algorithm between your version of Indy and the latest version in SVN.
Related
With IdFTP, the server i'm connecting to is not using UTF-8, but ANSI. There's nothing special about my code, i simply set Host, Username, Password and Connect to server. Then i call List method with no parameters. Iterating through DirectoryListing gives me incorrect results for file names. My sample directory name encoded in local code page (CP-1250) is:
aąęsśćńółżźz
I thought i'll be able to "fix" file name field by converting it to AnsiString and setting code page but it seems to be already broken - memory dump of DirectoryListing[I].FileName:
a ? ? s ? ? ? ?? ?? z
6100 FDFF FDFF 7300 FDFF FDFF FDFF 8FDB DFDF 7A00
Manipulating with GIdDefaultAnsiEncoding or IOHandler.DefStringEncoding (after Connect, before List) makes no difference. I don't want to mess in IdFTP or IdGlobal code because i'm using it with other projects that involve Unicode and these works perfectly. Delphi XE2 or XE7.
As you can see FData contains raw file name in a 2 bytes per char string:
Even if i set IOHandler.DefStringEncoding to any TIdTextEncoding that is FIsSingleByte = True, FMaxCharSize = 1. However it looks promising because #$009F is "ź" in CP-1250, but i'm not looking for a per server, temporary solution. I expected Indy to handle this correctly after setting IOHandler.DefStringEncoding and GIdDefaultAnsiEncoding based on server capabilities (UTF-8 or ANSI with specified encoding).
Total Commander connection log:
Your server supports the MLSD command. Total Commander is sending the MLSD command and not the older LIST command. This is good, because MLSD has a standardized format (see RFC 3659), which includes support for embedded charset information. If no charset is explicitly stated, UTF-8 must be used.
You did not show the command/response log for TIdFTP, but the fact that the TIdFTPListItem.Data property is showing MLSD formatted output data means TIdFTP.List() is also using the MLSD command (by calling TIdFTP.ExtListDir() internally). The output shown does not include an explicit charset attribute, so TIdFTP will decode the filename as UTF-8.
However, the raw filename data that is shown in the TIdFTPListItem.Data property is NOT the correct UTF-8 encoded form of the directory name you have shown (even when stored as a raw 8-bit encoded UnicodeString - which is what TIdFTP.ExtListDir() does internally before parsing it). So the problem is either:
your FTP server is not converting the directory name from CP-1250 to UTF-8 correctly in the first place. Considering that Total Commander appears to be able to handle the listing correctly, this is not likely.
TIdFTP is not storing the raw UTF-8 octet data correctly before parsing it. This is more likely.
Hard to say which is actually the case since you did not show the raw listing data that is actually being transmitted. And you did not specify which exact version of Delphi and Indy you are using, either. Assuming the server is transmitting UTF-8 correctly, you might simply be using an older Indy version that does not handle the UTF-8 transmission correctly. AFAIK, the current version available (10.6.2.5270 at the time of this writing) should be able to handle it, as long as you are using Delphi 2009 or later. If you can provide a Wireshark capture of the raw listing data, I can check if there are any logic issues in TIdFTP that need to be fixed or not.
My team was looking for quick solution that i had to provide. My solution is based on this post: http://forums2.atozed.com/viewtopic.php?p=32301#p32301 and this question: Converting UnicodeString to AnsiString
Once FTP listing is finished i do overwrite FileName property via function that extracts file name from Data, and then convert String to RawByteString with correct code page. Fix is applied only if server doesn't support UTF-8. This way i'm able to move around FTP - ChangeDir, Get, Put etc. without problems.
I am using TIdMessage and when I assign empty subject e.g. IdMsg->Subject = ""; outgoing message does not have "Subject:" header.
If I add subject by having a space e.g. IdMsg->Subject = " "; then the message has Subject: header even though it trims the space - the output is not: "Subject:[sp][sp][cr][lf]" but it is "Subject:[cr][lf]". This is clearly not consistent with the rest of headers which all have a space after the colon and before actual data so the empty subject should be "Subject:[sp][sp][cr][lf]".
I understand that the TIdMessage tries to optimize message by removing headers or trimming them but it is just being too smart here.
Is there a way to force having a Subject header with 2 spaces behind it (without editing the TIdMessage source code)?
For those wondering about the reason - I want to make sure that dumb email reading programs/scripts correctly interpret as "empty subject" which is the reason for all of this and not as something else and removing Subject: header is not much of an optimization anyway.
Your space character actually survives the encoding process when TIdMessageClient is generating the header data being sent, but then the space is getting trimmed by TIdHeaderList when it is parsing the final header data and folding long headers to fit within email line length restrictions. Each line generated for a given header by the folding process gets right-trimmed, and since your header data only consists of whitespace, it gets discarded.
The only way to disable that folding is to set the TIdMessage.LastGeneratedHeaders.FoldLines property to False, which is not advisable unless you know your headers will always be short enough to never need folding.
Another option is to set the TIdMessage.Subject to a blank string, and then use the TIdMessage.ExtraHeaders property instead. You will have to use ExtraHeaders.Add() instead of ExtraHeaders.Values so that the string is added as-is and avoids folding:
Msg.ExtraHeaders.Add('Subject: ');
Does Indy9 have any way to get a specific raw email header (say, "Subject" or "From") which still includes the transfer-encoding (ie: has not been mangled by DecodeHeader on older versions of Delphi with poor Unicode support), or would I have to parse the entire email header manually to extract this information?
The TIdMessage.RawHeaders property is what you are looking for, eg:
Subject := IdMessage1.RawHeaders.Values['Subject'];
I have solved the problem, calling IdMessage1.Headers.Values['Subject'] BEFORE calling IdMessage1.ProcessHeaders gives different results than after.
I need your help. Please help me.
I have Delphi 2010
I try to idHTTP.Get a file with Unicode text (Russian) from site into MemoryStream on English version of Windows 7.
Then I load this MemoryStream with Unicode text into, for example, Memo.
If I set the Russian language as "Language for non-Unicode programs" in Control Panel the text appear properly in Memo. But if I set Enlish - I get wrong characters (*$^#~!#).
How can I load Russian text in Unicode with idHTTP.Get from site and show it properly in any Windows (Chinese, English etc.)???
Thank you for help!!!
I suggest updating to a recent Delphi version that is Unicode enabled.
Update: It looks like the memorystream actually contains AnsiText in a specific code page instead of real Unicode text. You can declare an appropriate AnsiString variable with that codepage, load the text into that variable and then load the variable into the memo.
It is hard to tell more without seeing the real data.
TMemo expects Unicode (UTF-16 encoded) text. If you download the text using the version of TIdHTTP.Get() that fills a TStream, then you are downloading the raw (usually Ansi encoded) text, and then are responsible for manually decoding that to Unicode before then assigning that to the TMemo.
Assuming the webserver is specifying a correct charset for the text in the response headers, then use the version of TIdHTTP.Get() that returns a String instead. TIdHTTP will detect the charset and decode the raw data into Unicode for you, eg:
Memo1.Text := IdHTTP1.Get('http://addr_here');
Update to D2009 or higher
Use components that support unicode (I remember TMS offers some components)
Set the character set / code page correctly for the language you are using
I am assigning a string to a custom type I have declared, which I Read/Write using the TTreeViews Node.Data property. I read and write to and from the node, something like this:
Read: RichEdit1.Lines.Text := TMyData(TreeView1.Selected.Data).MyString;
Write: TMyData(TreeView1.Selected.Data).MyString := RichEdit1.Lines.Text;
This works perfect for plain strings, I want to allow Rich Formatted text to be stored in the string, without losing the formatting. I managed to do this by using Streams on the RichEdit, because I am saving my database using the Freeware Zeos Lib (SQL) I get Unknown Token errors (likely from the RTF tags). How can I save without the errors?
UPDATE
I have managed to get it saving correctly without erroring now, using Base64 Encoding/Decoding as suggested by Sylverdrag. This encodes my strings removing the bad characters.
Check out http://delphi.about.com/od/adptips2003/a/bltip1203_5.htm
(My original answer was for C# - misread your question)