Thanks Ralf. Yes, this is what I am doing - telling the parser to read UTF8 and working in 8 bit. I am only dealing with European languages. URLs, phrases and keywords, tested German, French and Spanish - all OK before the new update warning through to the end of the procedure. So the fact that this assigned string is already testing correct before casting to a RawByteString should make no difference? - as RawByteString does nothing to what is assigned to it, it is entirely character neutral? J. -----Original Message----- From: yunqa-bounce@xxxxxxxxxxxxx [mailto:yunqa-bounce@xxxxxxxxxxxxx] On Behalf Of Delphi Inspiration Sent: 02 May 2012 18:22 To: yunqa@xxxxxxxxxxxxx Subject: [yunqa.de] Re: New DIUnicode warning On 02.05.2012 17:12, Jon Burnham wrote: > To explain a bit more, this is a UTF8 response string derived from an > ANSI read response (using a RealThinClient HTTP client control which > is ANSI based internally). Hence the decoding. > > This is the call to the procedure. > > semrushget(Utf8Decode(TRtcDataClient(Sender).Read)); I don't know what string type TRtcDataClient.Read returns. If it's 8-bit (AnsiString, RawByteString), pass it on to TDICsvParser.SetSourceBufferAsStrA(); If it is 16-bit (UnicodeString, WideString), pass it to TDICsvParser.SetSourceBufferAsStrA(); and set TDICsvParser.ReadMethods := Read_UTF_16_LE; Ralf > So, from what you are saying, is that I should cast the response as a > RawByteString throughout, starting at the point above, instead of > using UTF decoding? How can I safely do this ? I worry that I am > currently looking at ANSI => UTF8 => RawByteString. There must also be > some inefficiencies here too. > > Obviously, I have confirmed problems with some data character > conversion without the utf8 decoding. _______________________________________________ Delphi Inspiration mailing list yunqa@xxxxxxxxxxxxx //www.freelists.org/list/yunqa _______________________________________________ Delphi Inspiration mailing list yunqa@xxxxxxxxxxxxx //www.freelists.org/list/yunqa