We rise up for the things we believe in over and over again

Очередной день, очередные тесты. Вводим в тестовую среду виртуалку с Win 7 в качестве клиентской ОС и начинаем править скрипт таким образом, чтобы результирующие файлы были в нужной кодировке и читались как серверами, так и клиентами.
Смотрим на исходные файлы "живых" политик:
Printers.xml - UTF8
GPT.ini - Windows-1251.

Лезем скрипт, находим там строку

После чего меняем ее на вот такую конструкцию:

Через Stream Writer мы запишем Printers.xml в нужной кодировке - UTF8. Она НЕ равна Unicode, в котором Powershell соберется записать файл по-умолчанию.
С GPT.ini все проще. В инструкции

просто добавляем требуемую кодировку:

После чего gpupdate на клиентах, и наблюдаем красивые безошибочные журналы System и Application.
Дело за проверкой в боевых условиях. Нужна тестовая политика уже там.

@музыка: Ryan Farish - Sunshine in the Rain

@темы: PowerShell, Scripting

Комментарии
13.11.2016 в 11:07

Тотальная неудачница и убийца жёстких дисков.
Вообще, INI файлы могут быть в UTF-16, но такие должны читаться только через юникодные функции вроде GetPrivateProfileString() прочими программами. Вот тут можно ознакомиться:

http://www.freebasic.su/src/inifiles.xhtml

/* Хотя, может быть другие программы, если будут использовать ANSI версии функций, просто получат сконвертированные данные. Тоесть Windows обеспечит прозрачность, но всякие иероглифы программы читать всё равно, разумеется, не смогут. */
13.11.2016 в 11:14

Тотальная неудачница и убийца жёстких дисков.
Не совсем поняла, что ты делаешь с XML, но MSXML умеет прекрасно читать с и писать файлы с диска (а читать может и с других источников вроде HTTP). Кодировка указывается при создании нового дерева через что-то вроде такого:



После этого библиотека парсит инструкцию и правильно выбирает кодировку.

/* Возможно, есть более модный способ, но у меня этот уже давно, и он работает ^^' */
13.11.2016 в 12:53

We rise up for the things we believe in over and over again
что ты делаешь с XML
Да ничего особо извращенного:

всего лишь прочитает уже имеющийся файл, оформит дерево. Хотя и знаю, что правильнее это делать так:

После всех изменений вызываем стандарнтный метод XmlDocument.Save(), но засада его именно в том, что он пишет только в Unicode, а это неприемлемо. Похоже на hard-code. В качестве параментров этот метод принимает только цель, куда писать. Это может быть поток, может быть файл, может быть io.Writer (xml или text). Чтобы сказать, как именно писать, приходится прибегать к ухищрениям. Одно из них - в моем методе. Другое - в твоем :)
13.11.2016 в 13:26

Тотальная неудачница и убийца жёстких дисков.
Мой правильнее. Тем более что по стандарту заголовок должен быть, а если кодировка не указана, то это – неопределённое состояние, если мне не изменяет память. Кроме того, это не ухищрение, как стандартный процесс формирования дерева. Если XML уже содержал правильный заголовок, то ничего добавлять не нужно, и файл через save() будет сохранён в указанной кодировке.
13.11.2016 в 13:31

We rise up for the things we believe in over and over again
Если XML уже содержал правильный заголовок
Содержал. Там все стандартное. XML version 1.0, encoding UTF-8.

файл через save() будет сохранён в указанной кодировке
После чего групповая политика накрывается медным тазом :) Поверь, я только за, если бы не пришлось обращаться ко всяким writer'ам и прочей нечисти. But hey, cousin! It doesn't happen! (c) G. Carlin
Приду сегодня вечером на работу - покажу тебе примеры этих файлов из своего тестового домена, поглядишь-порадуешься :)
13.11.2016 в 13:43

Тотальная неудачница и убийца жёстких дисков.
Содержал. Там все стандартное. XML version 1.0, encoding UTF-8.

Я начинаю терять ощущение реальности. Насколько я помню, в изначальном скрипте у тебя XML формировался прямо в коде, а тут он сначала откуда-то читается, а потом как-то модифицируется. Что получается на входе? И каким должен быть выход?
13.11.2016 в 14:02

We rise up for the things we believe in over and over again
в изначальном скрипте у тебя XML формировался прямо в коде
Да, но не весь. "Влоб" формировалась только новая нода, описывающая новый принтер. А вставлялось это все в уже имеющийся в каталоге SYSVOL файл. Собственно, последняя версия скрипта занимается ровно тем же самым, только ноду формирует не в виде текста, а при помощи свойств и методов самого msxml.
Итого на входе имеем существующий xml файл:

На выходе должны получить его же, но в конец должен быть добавлен новый блок SharedPrinter, чем скрипт и занимается с самого начала.
13.11.2016 в 22:35

Тотальная неудачница и убийца жёстких дисков.
Окей, а что ты подразумеваешь под «Юникодом», в котором сохраняется файл через save()?