Hello,
Thanks for replies, I will try to explain this in other way:
My system code page is windows-1250. When a string is sent to a COM
component, it is somehow converted to UTF-16. Thus FPC knows how to do
the conversion. Now I know that I am receiving text in UTF-8. Thus I
called UTF8ToANSI to uselessly convert the UTF-8 to ANSI and then FPC
converted it to UTF-16 to make COM happy.
Although it worked well in many cases, a data loss may occur.
So to reformulate this question, how to avoid this useless conversion
step? I thought that setting the default code page to UTF-8 just do the
trick.
Dňa 23. 11. 2015 o 17:29 Jonas Maebe napísal(a):
Lubos Pintes wrote on Mon, 23 Nov 2015:
I am developing a console application which receives an UTF-8 encoded
text through stdin.
The text is, after possible modification, sent to SAPI5. The SAPI5
generated interface wrappers have parameters of type string.
In FPC 2.6.4, I used UTF8toANSI on various places and that worked
well. Now after reading about FPC 3.x's unicode support, I thought
that adding this line say after begin in the main program could be
enough:
SetMultiByteConversionCodePage(CP_UTF8);
It however doesn't work.
That routine sets the default code page for ansistrings. It does not
change I/O.
How can I solve this without conversion to ANSI?
The code page can be set per I/O channel:
http://www.freepascal.org/docs-html/3.0.0/rtl/system/settextcodepage.html (and
Michael: I just noticed a typo on that page, under "Description" it says
GetTextCodePage instead of SetTextCodePage)
Jonas
_______________________________________________
fpc-pascal maillist -
fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
