[fpc-devel] Unicode support (yet again)

[Luiz Americo Pereira Camara]

On 16/9/2011 14:24, Luiz Americo Pereira Camara wrote:
> On 16/9/2011 14:03, Luiz Americo Pereira Camara wrote:
>> On 16/9/2011 09:36, Marco van de Voort wrote:
>>> he UTF8 -> UTF16 conversion is done
>>> All the routines you name (fileexists, filegetattr etc) will become
>>> rawbytestring and accept both utf8 and utf16, and then only in the
>>> implementation figure out if conversion is necessary. (to the 
>>> encoding of
>>> the OS)
>>>
>>
>> Better.
>
> I took a look at the Delphi An Unicode document by Marco Cantu and a 
> get doubt about the implementation with RawByteString:
>
> Assume the implementation under windows of FileGetAttr:
>
>

[..]

> with RawByteString (need the conversion - but how ?????):

Nevermind i found the answer at 
http://www.micro-isv.asia/2008/08/using-rawbytestring-effectively/

"Then |ShowCodePage(A)| will display 1252, and |ShowCodePage(F)| will 
display 65001. The StringCodePage function gets the code page 
information stored in the string at runtime, not the declared code page, 
which is 65535 for RawByteString. This means that StringCodePage is only 
meaningful when calling it on a string variable that actually holds a 
string. If it doesn’t hold a string, StringCodePage cannot retrieve the 
code page, and it will always return the default code page."

The codepage of a RawByteString at runtime will keep the previous 
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the 
RawbyteString CodePage (65535) as a though previously

So the implementation would be:

function FileGetAttr(const FileName: RawByteString): Longint;
begin
SetCodePage(FileName, 1200, True);
Result:=Integer(Windows.GetFileAttributesW(PWideChar(FileName)));
end;

This way the version using UnicodeString parameter would have the 
benefit of being less verbose and use the possible optimizations of the 
implicit encoding conversion.

Luiz