ESC: accepts own xml-files only in UTF-16

[GoogleCodeExporter]

Юникодная версия плагина принимает 
конфигурационные xml-файлы только в 
юникоде.

В некоторых случаях это может быть 
неудобно. 
Например приходится поддерживать 2 набора 
настроек (неюникодные для Far 
1.75)

Как правило в XML допустимо указывать 
кодировку:
<?xml version="1.0" encoding="UTF-8" ?>
(http://en.wikipedia.org/wiki/XML)

Предполагаю что если обработка XML в плагине 
идёт с помощью системных 
функций, то реализовать разных кодировок 
не должно быть сложно.
(это гипотеза - прошу больно не пинать)

Original issue reported on code.google.com by [email protected] on 4 Jun 2009 at 9:14

[VictorVG]

Подобная проблема уже вылезала в ином проекте - Process Hacker (слетали настройки если хоть одно значение было не в Latin-1 записано). Кончилось всё основательной переделкой РН и плагинов. А спецификации XML надо не в вики, а на W3C.org смотреть ибо там первоисточник, а при пересказе возможны искажения смысла.

[zippy1981]

Discovered this on my own. I don't speak Russian, but google translate indicates that this became apparant in ProcessHacker. Do you refer to this project @VictorVG http://processhacker.sourceforge.net/

Regardless, is there an english commentary as to why this exists?

[VictorVG]

Ok! Just see my resolved bug-report [Resolved]:: PerfMonPlugin - problem with non-Latin names Settings as samples on some problem then programs partially supported UNICODE and configuration value using not-Latin character's (old version Process Hacker before v2.36 read/save file "settings.xml" as ANSI).

[zippy1981]

@VictorVG So if I understand correctly the solution is to set the BOM, and the encoding correctly in the <?xml header and then you can encode any way you like?

[VictorVG]

Update solution don't needed, just convert XML up to UTF-8 included BOM signature - Far automatically detected and correctly displayed UTF-8 files have BOM.