Все, что вы хотели знать о хэш-таблицах
Я хочу вернуться на шаг назад и поговорить о хэш-таблицах. Теперь я использую их все время. Вчера вечером я объяснял человеку принцип их работы после встречи с группой пользователей и понял, что я, так же как и мой слушатель, кое-что о них не понимаю. Хэш-таблицы играют очень важную роль в PowerShell, поэтому будет полезно получить о них полное представление.
Примечание.
Оригинал этой статьи впервые был опубликован в блоге автора @KevinMarquette. Группа разработчиков PowerShell благодарит Кевина за то, что он поделился с нами этими материалами. Читайте его блог — PowerShellExplained.com.
Хэш-таблица как коллекция объектов
Я рекомендую рассматривать хэш-таблицу как коллекцию в традиционном определении термина хэш-таблицы. Это определение позволяет получить полное понимание их работы в случае последующего расширенного использования. Если изначально не понять этот момент, впоследствии можно запутаться.
Что представляет собой массив?
Прежде чем перейти к определению хэш-таблицы, нужно сначала рассказать о массивах. В рамках этого обсуждения массив понимается как список или коллекция значений или объектов.
$array = @(1,2,3,5,7,11)
После передачи элементов в массив можно использовать foreach для выполнения итерации по списку или индекс для доступа к отдельным элементам в массиве.
foreach($item in $array)
{
Write-Output $item
}
Write-Output $array[3]
Точно так же можно обновлять значения с помощью индекса.
$array[2] = 13
Я лишь поверхностно изложил понятие массивов, но при переходе к хэш-таблицам это позволит получить о них правильное представление.
Что такое хэш-таблица?
Сначала я приведу основное техническое описание хэш-таблиц, а затем расскажу о других способах их использования в PowerShell.
Хэш-таблица представляет собой структуру данных, во многом похожую на массив, за исключением того, что каждое значение (объект) сохраняется в ней с помощью ключа. Это базовое хранилище ключей и значений. Сначала мы создаем пустую хэш-таблицу.
$ageList = @{}
Обратите внимание, что для определения хэш-таблицы используются фигурные скобки вместо круглых. Затем мы добавляем элемент, используя следующий ключ:
$key = 'Kevin'
$value = 36
$ageList.add( $key, $value )
$ageList.add( 'Alex', 9 )
Имя пользователя — ключ, а его возраст — это значение, которое я хочу сохранить.
Использование квадратных скобок для доступа
После добавления значений в хэш-таблицу можно перенести их обратно, используя тот же ключ (вместо числового индекса как для массива).
$ageList['Kevin']
$ageList['Alex']
Если мне нужно узнать возраст Кевина, я указываю его имя для доступа. Этот подход также можно использовать для добавления или обновления значений в хэш-таблице. Он похож на использование функции add(), описанной выше.
$ageList = @{}
$key = 'Kevin'
$value = 36
$ageList[$key] = $value
$ageList['Alex'] = 9
Кроме того, можно использовать для доступа и обновления значений другой синтаксис. Я расскажу о нем в следующем разделе. Если вы перешли на PowerShell с другого языка, скорее всего, раньше вы использовали хэш-таблицы примерно так же, как показано в этих примерах.
Создание хэш-таблиц со значениями
Пока я создал пустую хэш-таблицу для этих примеров. При создании таблицы вы можете предварительно внести в нее ключи и значения.
$ageList = @{
Kevin = 36
Alex = 9
}
В качестве таблицы подстановки
Реальная ценность этого типа хэш-таблиц заключается в том, что их можно использовать в качестве таблиц подстановки. Вот простой пример.
$environments = @{
Prod = 'SrvProd05'
QA = 'SrvQA02'
Dev = 'SrvDev12'
}
$server = $environments[$env]
В этом примере мы указываем среду для переменной $env и выбираем правильный сервер. Можно использовать switch($env){...} для такого выбора, однако хэш-таблица является не менее удобным способом.
Она становится еще удобнее, если выполняется динамическое построение таблицы подстановки для последующего использования. То есть такой подход рекомендуется выбирать, если требуется создать перекрестную ссылку. Я думаю, это было бы даже более очевидным, если бы PowerShell не обеспечивал настолько эффективную фильтрацию в канале за счет Where-Object. Этот подход стоит рассматривать, если для вас имеет значение производительность.
Я бы не сказал, что это будет быстрее, однако указанный способ обеспечивает соответствие правилу Если производительность имеет значение, попробуйте его использовать.
Множественный выбор
Обычно хэш-таблица рассматривается как пара "ключ-значение", где вы указываете один ключ и получаете одно значение. PowerShell позволяет предоставить массив ключей, чтобы получить несколько значений.
$environments[@('QA','DEV')]
$environments[('QA','DEV')]
$environments['QA','DEV']
В этом примере я использую вышеописанную хэш-таблицу подстановки и указываю три различных стиля массива для получения совпадений. Это скрытое преимущество PowerShell, о котором большинство пользователей не знает.
Итерация хэш-таблиц
Поскольку хэш-таблица представляет собой коллекцию пар "ключ-значение", итерация для них выполняется иначе, чем для массива или обычного списка элементов.
Первое, что следует заметить, — при передаче хэш-таблицы по каналу он обрабатывает ее как один объект,
PS> $ageList | Measure-Object
count : 1
хотя при этом свойство .count сообщает, сколько значений он содержит.
PS> $ageList.count
2
Эту ошибку можно устранить с помощью свойства .values, если вам нужны только значения.
PS> $ageList.values | Measure-Object -Average
Count : 2
Average : 22.5
Зачастую удобнее перечислить ключи и использовать их для доступа к значениям.
PS> $ageList.keys | ForEach-Object{
$message = '{0} is {1} years old!' -f $_, $ageList[$_]
Write-Output $message
}
Kevin is 36 years old
Alex is 9 years old
Далее приведен тот же пример, в котором используется цикл foreach(){...}.
foreach($key in $ageList.keys)
{
$message = '{0} is {1} years old' -f $key, $ageList[$key]
Write-Output $message
}
Мы выполняем обход всех ключей в хэш-таблице и используем их для доступа к значениям. Это общий шаблон, используемый при работе с хэш-таблицами как с коллекциями.
GetEnumerator()
Таким образом, мы приходим к использованию GetEnumerator() для выполнения итерации нашей хэш-таблицы.
$ageList.GetEnumerator() | ForEach-Object{
$message = '{0} is {1} years old!' -f $_.key, $_.value
Write-Output $message
}
Перечислитель выдает каждую пару "ключ-значение" по очереди. Он специально разработан для такого варианта использования. Спасибо Марку Краусу за то, что напомнил мне об этом.
BadEnumeration
Важный момент: вы можете изменить хэш-таблицу в ходе ее перечисления. Если начать с нашего основного примера $environments:
$environments = @{
Prod = 'SrvProd05'
QA = 'SrvQA02'
Dev = 'SrvDev12'
}
Попытка задать для каждого ключа одно и то же значение сервера завершится ошибкой.
$environments.Keys | ForEach-Object {
$environments[$_] = 'SrvDev03'
}
An error occurred while enumerating through a collection: Collection was modified;
enumeration operation may not execute.
+ CategoryInfo : InvalidOperation: tableEnumerator:HashtableEnumerator) [],
RuntimeException
+ FullyQualifiedErrorId : BadEnumeration
Это также приведет к сбою, даже если на первый взгляд все выглядит корректно:
foreach($key in $environments.keys) {
$environments[$key] = 'SrvDev03'
}
Collection was modified; enumeration operation may not execute.
+ CategoryInfo : OperationStopped: (:) [], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException
в этой ситуации хитрость заключается в клонировании ключей до выполнения перечисления.
$environments.Keys.Clone() | ForEach-Object {
$environments[$_] = 'SrvDev03'
}
Хэш-таблица как коллекция свойств
Пока что в нашу хэш-таблицу помещались объекты одинакового типа. Я использовал данные о возрасте во всех этих примерах, а в качестве ключа использовалось имя пользователя. Это отличный способ изучения данных, если в коллекции объектов у каждого объекта есть имя. Еще один распространенный способ использования хэш-таблиц в PowerShell — хранение коллекции свойств, где ключом является имя свойства. В следующем примере я расскажу об этом подробнее.
Доступ на основе свойств
Использование доступа на основе свойств меняет динамику хэш-таблиц и способ их использования в PowerShell. Вот типичный пример, в котором ключи обрабатываются как свойства.
$ageList = @{}
$ageList.Kevin = 35
$ageList.Alex = 9
Как и в примерах выше, в этом примере такие ключи добавляются, если только они еще не существуют в хэш-таблице. В зависимости от того, как определены ключи и какие используются значения, такой способ либо выглядит немного странным, либо идеально решает задачу. До этого момента пример списка данных о возрасте отлично подходил. Теперь нам нужен новый пример.
$person = @{
name = 'Kevin'
age = 36
}
Кроме того, мы можем добавлять атрибуты в $person и обращаться к ним следующим образом.
$person.city = 'Austin'
$person.state = 'TX'
Внезапно оказывается, что эта хэш-таблица начинает работать как объект. Это все еще коллекция, так что все примеры по-прежнему применимы. Мы просто рассматриваем ее с другой точки зрения.
Проверка ключей и значений
В большинстве случаев можно протестировать значение примерно таким способом:
if( $person.age ){...}
Это довольно просто, но для меня оказалось чревато множеством ошибок, потому что я в своей логике не учитывал один важный момент. Я использовал этот метод для тестирования, если был доступен ключ. Если значение равнялось $false или нулю, этот оператор неожиданно возвращал $false.
if( $person.age -ne $null ){...}
Это позволяет решить проблему для нулевых значений, но не сравнивает $null с несуществующими ключами. В большинстве случаев это одно и то же, но для некоторых функций такая процедура необходима.
if( $person.ContainsKey('age') ){...}
Кроме того, мы используем ContainsValue() в ситуациях, когда требуется проверить значение, не имея данных о ключе, или выполнить итерацию для всей коллекции.
Удаление и очистка ключей
Ключи можно удалить с помощью функции .Remove().
$person.remove('age')
Если присвоить им значение $null, просто получится ключ со значением $null.
Для очистки хэш-таблицы чаще всего используется ее инициализация как пустой хэш-таблицы.
$person = @{}
Хотя это вполне рабочий способ, все же рекомендуется вместо него попробовать функцию clear().
$person.clear()
Это один из тех случаев, когда использование функции создает самодокументируемый код, цель которого предельно ясна и понятна.
Все занятные вещи
Упорядоченные хэш-таблицы
По умолчанию хэш-таблицы не упорядочиваются (не сортируются). В традиционном контексте порядок не имеет значения, если для доступа к значениям всегда используется ключ. Возможно, вам потребуется сохранить ранее определенный порядок свойств. К счастью, это можно сделать с использованием ключевого слова ordered.
$person = [ordered]@{
name = 'Kevin'
age = 36
}
Теперь при перечислении ключи и значения сохраняют этот порядок.
Строковые хэш-таблицы
При определении хэш-таблицы в одной строке можно разделять пары "ключ-значение" точкой с запятой.
$person = @{ name = 'kevin'; age = 36; }
Это удобно, если вы создаете их в канале.
Настраиваемые выражения в общих командах конвейера
Существует несколько командлетов, которые поддерживают использование хэш-таблиц для создания настраиваемых или вычисляемых свойств. Как правило, они используются в Select-Object и Format-Table. Хэш-таблицы используют специальный синтаксис, который в развернутом виде выглядит следующим образом.
$property = @{
name = 'totalSpaceGB'
expression = { ($_.used + $_.free) / 1GB }
}
Командлет помечает этот столбец как name. expression — это блок выполняемого сценария, где $_ представляет значение объекта в канале. Далее рассматривается действие сценария.
$drives = Get-PSDrive | Where Used
$drives | Select-Object -Property name, $property
Name totalSpaceGB
---- ------------
C 238.472652435303
Я поместил его в переменную, однако его можно определить как строковый и сократить name до n и expression до e в процессе работы над ним.
$drives | Select-Object -property name, @{n='totalSpaceGB';e={($_.used + $_.free) / 1GB}}
Лично мне не нравится, что команды выполняются долго, и зачастую проявляются нежелательные последствия. Лучше я создам новую хэш-таблицу или pscustomobject со всеми нужными полями и свойствами вместо того, чтобы использовать этот метод со сценариями. Однако там содержится большой объем кода, который выполняет эти задачи, и вам следует помнить об этом. Я имею в виду последующее создание pscustomobject.
Настраиваемое выражение сортировки
Можно легко отсортировать коллекцию, если объекты содержат данные, которые вы хотите использовать как критерий сортировки. Можно либо добавить данные в объект перед сортировкой, либо создать настраиваемое выражение для Sort-Object.
Get-ADUser | Sort-Object -Property @{ e={ Get-TotalSales $_.Name } }
В этом примере я выберу список пользователей и использую специальный командлет, чтобы получить дополнительную информацию исключительно в целях сортировки.
Сортировка списка хэш-таблиц
При наличии списка хэш-таблиц, которые нужно отсортировать, выясняется, что Sort-Object не обрабатывает ключи как свойства. Эту проблему можно решить с помощью настраиваемых выражений сортировки.
$data = @(
@{name='a'}
@{name='c'}
@{name='e'}
@{name='f'}
@{name='d'}
@{name='b'}
)
$data | Sort-Object -Property @{e={$_.name}}
Сплаттинг хэш-таблиц в командлетах
Именно это мне больше всего нравится в хэш-таблицах, однако многие об этом до сих пор не знают. Идея в том, чтобы вместо указания всех свойств в одной строке командлета сначала упаковать их в хэш-таблицу. После этого можно специально присвоить хэш-таблицу функции. Ниже приведен пример создания области DHCP обычным способом.
Add-DhcpServerV4Scope -Name 'TestNetwork' -StartRange '10.0.0.2' -EndRange '10.0.0.254' -SubnetMask '255.255.255.0' -Description 'Network for testlab A' -LeaseDuration (New-TimeSpan -Days 8) -Type "Both"
Если сплаттинг не используется, все это необходимо определять в одной строке. При этом либо приходится прокручивать экран, либо строка разворачивается в произвольном месте. А теперь сравним это с командой, которая использует сплаттинг.
$DHCPScope = @{
Name = 'TestNetwork'
StartRange = '10.0.0.2'
EndRange = '10.0.0.254'
SubnetMask = '255.255.255.0'
Description = 'Network for testlab A'
LeaseDuration = (New-TimeSpan -Days 8)
Type = "Both"
}
Add-DhcpServerV4Scope @DHCPScope
При использовании символа @ вместо $ вызывается операция сплаттинга.
Просто подумайте, насколько легко читать данные в таком примере. Это абсолютно та же команда с теми же значениями. Второй вариант гораздо проще для понимания и использования в дальнейшей работе.
Я всегда использую сплаттинг, если команда становится слишком длинной. Когда я говорю "слишком длинной", я имею в виду, что мне приходится прокручивать экран вправо. Если я выбираю три свойства для функции, велика вероятность, что мне придется переписывать их с использованием хэш-таблицы со сплаттингом.
Сплаттинг для дополнительных параметров
Чаще всего я использую сплаттинг для работы с дополнительными параметрами, которые добавляю в свой сценарий из других источников. Предположим, у меня есть функция, которая переносит вызов Get-CIMInstance, содержащий дополнительный аргумент $Credential.
$CIMParams = @{
ClassName = 'Win32_Bios'
ComputerName = $ComputerName
}
if($Credential)
{
$CIMParams.Credential = $Credential
}
Get-CIMInstance @CIMParams
Для начала я создаю хэш-таблицу с общими параметрами. Потом я добавляю $Credential, если он существует.
Поскольку я использую здесь сплаттинг, мне нужно просто один раз вызвать Get-CIMInstance в коде. Этот конструктивный шаблон абсолютно прозрачен и способен легко обрабатывать множество дополнительных параметров.
Правда, можно просто написать команды так, чтобы разрешить значения $null для параметров. На самом деле вы просто не всегда контролируете остальные вызываемые команды.
Несколько операций сплаттинга
Можно выполнить сплаттинг нескольких хэш-таблиц в один командлет. Если вернуться к первоначальному примеру сплаттинга:
$Common = @{
SubnetMask = '255.255.255.0'
LeaseDuration = (New-TimeSpan -Days 8)
Type = "Both"
}
$DHCPScope = @{
Name = 'TestNetwork'
StartRange = '10.0.0.2'
EndRange = '10.0.0.254'
Description = 'Network for testlab A'
}
Add-DhcpServerv4Scope @DHCPScope @Common
Я использую этот метод, когда у меня будет общий набор параметров, который передается во многие команды.
Сплаттинг для чистого кода
В сплаттинге одного параметра нет ничего плохого, если это помогает очистить код.
$log = @{Path = '.\logfile.log'}
Add-Content "logging this command" @log
Сплаттинг исполняемых файлов
Сплаттинг также эффективен для некоторых исполняемых файлов, использующих синтаксис /param:value. Robocopy.exe, например, содержит отдельные такие параметры.
$robo = @{R=1;W=1;MT=8}
robocopy source destination @robo
Не знаю, действительно ли все это имеет практическую пользу, но, по-моему, это очень интересно.
Добавление хэш-таблиц
Хэш-таблицы поддерживают оператор сложения для объединения двух хэш-таблиц.
$person += @{Zip = '78701'}
Это эффективно только в том случае, если две хэш-таблицы не имеют общего ключа.
Вложенные хэш-таблицы
Хэш-таблицы можно использовать в качестве значений в хэш-таблице.
$person = @{
name = 'Kevin'
age = 36
}
$person.location = @{}
$person.location.city = 'Austin'
$person.location.state = 'TX'
Я начал с базовой хэш-таблицы, которая содержит два ключа. Я добавил ключ location с пустой хэш-таблицей. Затем я добавил два последних элемента в эту хэш-таблицу location. Все это также можно сделать в строке.
$person = @{
name = 'Kevin'
age = 36
location = @{
city = 'Austin'
state = 'TX'
}
}
Это создает ту же хэш-таблицу, которая описывалась выше, и обеспечивает доступ к свойствам таким же образом.
$person.location.city
Austin
Существует множество способов реализации структуры объектов. Ниже показан другой вариант представления вложенной хэш-таблицы.
$people = @{
Kevin = @{
age = 36
city = 'Austin'
}
Alex = @{
age = 9
city = 'Austin'
}
}
В результате можно использовать хэш-таблицы как в качестве коллекции объектов, так и в качестве коллекции свойств. Доступ к значениям по-прежнему легко получить, даже если они вложены любым выбранным методом.
PS> $people.kevin.age
36
PS> $people.kevin['city']
Austin
PS> $people['Alex'].age
9
PS> $people['Alex']['City']
Austin
Я обычно использую свойство Dot, когда рассматриваю хэш-таблицу как свойство. Обычно в моем коде они определяются статически, и я знаю их чисто интуитивно. Если нужно обойти список или программно получить доступ к ключам, я использую квадратные скобки для ввода имени ключа.
foreach($name in $people.keys)
{
$person = $people[$name]
'{0}, age {1}, is in {2}' -f $name, $person.age, $person.city
}
Возможность вкладывать хэш-таблицы обеспечивает большую гибкость и дополнительные возможности.
Просмотр вложенных хэш-таблиц
Как только вы начнете вкладывать хэш-таблицы друг в друга, вам потребуются простые способы их просмотра из консоли. Если я возьму эту последнюю хэш-таблицу, я получу выходные данные, которые будут выглядеть следующим образом, поскольку это максимальная глубина просмотра:
PS> $people
Name Value
---- -----
Kevin {age, city}
Alex {age, city}
Для поиска этих элементов я использую команду ConvertTo-JSON, так как она очень прозрачная, и я часто использую JSON для других задач.
PS> $people | ConvertTo-Json
{
"Kevin": {
"age": 36,
"city": "Austin"
},
"Alex": {
"age": 9,
"city": "Austin"
}
}
Даже если вы не знакомы с JSON, вы сможете просмотреть то, что искали. Существует команда Format-Custom для таких структурированных данных, но мне все-таки больше нравится просмотр в JSON.
Создание объектов
В отдельных случаях требуется только наличие объекта, а использование хэш-таблицы для хранения свойств не решает задачу. Чаще всего требуется просмотр ключей как имен столбцов. pscustomobject упрощает эту задачу.
$person = [pscustomobject]@{
name = 'Kevin'
age = 36
}
$person
name age
---- ---
Kevin 36
Даже если вы изначально не создаете его как pscustomobject, вы всегда можете выполнить его приведение позже при необходимости.
$person = @{
name = 'Kevin'
age = 36
}
[pscustomobject]$person
name age
---- ---
Kevin 36
У меня уже есть подробная статья о PCSCustomObject, которую я рекомендую прочесть после этого. Она основана на большом объеме данных, которые мы получили отсюда.
Чтение и запись хэш-таблиц в файл
Сохранение в CSV-файл
Выше я говорил, в частности, о трудностях с получением хэш-таблицы для сохранения в CSV-файл. Преобразуйте хэш-таблицу в pscustomobject, чтобы правильно сохранить ее в CSV-файл. Это полезно в начале работы с pscustomobject, поэтому порядок столбцов сохраняется. Однако при необходимости его можно привести к pscustomobject в строке.
$person | ForEach-Object{ [pscustomobject]$_ } | Export-CSV -Path $path
Опять же, рекомендую ознакомиться с моей публикацией по использованию PSCustomObject.
Сохранение вложенной хэш-таблицы в файл
Если нужно сохранить вложенную хэш-таблицу в файл, а затем повторно прочитать ее, я использую для этого командлеты JSON.
$people | ConvertTo-JSON | Set-Content -Path $path
$people = Get-Content -Path $path -Raw | ConvertFrom-JSON
В отношении этого метода можно отметить следующие два момента. Сначала JSON записывается в многострочном формате, поэтому мне нужно использовать параметр -Raw, чтобы считать его обратно в одну строку. Второй способ заключается в том, что импортированный объект больше не является [hashtable]. Теперь он является [pscustomobject], и это может стать проблемой, если вы этого не ожидали.
Обращайте внимание на хэш-таблицы с глубоким уровнем вложенности. Преобразование в формат JSON может привести к непредвиденным результатам.
@{ a = @{ b = @{ c = @{ d = "e" }}}} | ConvertTo-Json
{
"a": {
"b": {
"c": "System.Collections.Hashtable"
}
}
}
Используйте параметр Depth, чтобы обеспечить развертывание всех вложенных хэш-таблиц.
@{ a = @{ b = @{ c = @{ d = "e" }}}} | ConvertTo-Json -Depth 3
{
"a": {
"b": {
"c": {
"d": "e"
}
}
}
}
Если вы хотите, чтобы при импорте это был [hashtable], в этом случае вам придется использовать команды Export-CliXml и Import-CliXml.
Преобразование JSON в хэш-таблицу
Если необходимо преобразовать JSON в [hashtable], это можно сделать с помощью JavaScriptSerializer в .NET.
[Reflection.Assembly]::LoadWithPartialName("System.Web.Script.Serialization")
$JSSerializer = [System.Web.Script.Serialization.JavaScriptSerializer]::new()
$JSSerializer.Deserialize($json,'Hashtable')
Начиная с PowerShell версии 6, для поддержки JSON используется NewtonSoft JSON.NET, а также добавлена поддержка хэш-таблиц.
'{ "a": "b" }' | ConvertFrom-Json -AsHashtable
Name Value
---- -----
a b
В PowerShell 6.2 добавлен параметр Depth для ConvertFrom-Json. Значение по умолчанию для параметра Depth — 1024.
Чтение непосредственно из файла
Если у вас есть файл, который содержит хэш-таблицу, использующую синтаксис PowerShell, есть способ импортировать его напрямую.
$content = Get-Content -Path $Path -Raw -ErrorAction Stop
$scriptBlock = [scriptblock]::Create( $content )
$scriptBlock.CheckRestrictedLanguage( $allowedCommands, $allowedVariables, $true )
$hashtable = ( & $scriptBlock )
Он импортирует содержимое файла в scriptblock, а затем проверяет, чтобы перед его выполнением в нем не было других команд PowerShell.
Знаете ли вы, что манифест модуля (файл PSD1) является просто хэш-таблицей?
Ключом может быть любой объект.
Как правило, ключи — это просто строки. Таким образом, мы можем заключить в кавычки все, что угодно, и сделать это ключом.
$person = @{
'full name' = 'Kevin Marquette'
'#' = 3978
}
$person['full name']
Вы можете выполнить практически любые задачи, даже если раньше не знали, что это вообще возможно.
$person.'full name'
$key = 'full name'
$person.$key
Однако тот факт, что вы можете что-то сделать, вовсе не значит, что это нужно делать. Последний вариант выглядит так, как будто ошибка в нем неминуема, и его неправильно поймет любой, кто читает ваш код.
Технически ваш ключ необязательно должен быть строкой, однако его проще воспринимать, если используются только строки. Но индексирование не будет нормально выполняться со сложными ключами.
$ht = @{ @(1,2,3) = "a" }
$ht
Name Value
---- -----
{1, 2, 3} a
Доступ к значению в хэш-таблице по ключу не всегда работает. Например:
$key = $ht.keys[0]
$ht.$($key)
a
$ht[$key]
a
Если ключ является массивом, необходимо заключить переменную $key в часть выражения, чтобы ее можно было использовать с нотацией доступа к членам (.). Или можно использовать нотацию индекса массива ([]).
Использование в автоматических переменных
$PSBoundParameters
$PSBoundParameters — это автоматическая переменная, которая существует только в контексте функции. Она содержит все параметры, с которыми вызывалась функция. Это не совсем хэш-таблица, но достаточно близка к тому, чтобы ее можно было обрабатывать как хэш-таблицу.
Это предполагает удаление ключей и ее сплаттинг в другие функции. Если вы намерены писать функции прокси-сервера, ознакомьтесь со следующими сведениями.
Дополнительные сведения см. в разделе about_Automatic_Variables.
Проблема с PSBoundParameters
Важно помнить, что он включает только значения, передаваемые в качестве параметров. Если у вас также есть параметры со значениями по умолчанию, но они не передаются вызывающей стороной, $PSBoundParameters не содержит этих значений. Обычно этот момент упускается из вида.
$PSDefaultParameterValues
Эта автоматическая переменная позволяет назначить значения по умолчанию любому командлету, не изменяя его. Взгляните на этот пример.
$PSDefaultParameterValues["Out-File:Encoding"] = "UTF8"
При этом в хэш-таблицу $PSDefaultParameterValues добавляется запись, которая задает UTF8 в качестве значения по умолчанию для параметра Out-File -Encoding. Это зависит от сеанса, поэтому его следует поместить в $profile.
Я часто использую этот способ для предварительного присвоения значений, которые я часто ввожу.
$PSDefaultParameterValues[ "Connect-VIServer:Server" ] = 'VCENTER01.contoso.local'
Это также позволяет использовать подстановочные знаки для группового указания значений. Далее описывается несколько способов использования этой операции:
$PSDefaultParameterValues[ "Get-*:Verbose" ] = $true
$PSDefaultParameterValues[ "*:Credential" ] = Get-Credential
Более подробно это рассматривается в отличной статье об автоматических значениях по умолчанию, написанной Майклом Соренсом.
Регулярное выражение $Matches
При использовании оператора -match создается автоматическая переменная с именем $matches, которая содержит результаты сопоставления. Если в регулярном выражении есть какие-либо подвыражения, то в список также включаются соответствующие части совпадений.
$message = 'My SSN is 123-45-6789.'
$message -match 'My SSN is (.+)\.'
$Matches[0]
$Matches[1]
Именованные совпадения
Это одна из моих любимых функций, о которой большинство пользователей не знает. Если используется именованное совпадение регулярного выражения, доступ к совпадению осуществляется по имени в совпадениях.
$message = 'My Name is Kevin and my SSN is 123-45-6789.'
if($message -match 'My Name is (?<Name>.+) and my SSN is (?<SSN>.+)\.')
{
$Matches.Name
$Matches.SSN
}
В приведенном выше примере (?<Name>.*) является именованной частью выражения. Это значение затем помещается в свойство $Matches.Name.
Group-Object -AsHashtable
Одна из малоизвестных возможностей в Group-Object — возможность преобразовать некоторые наборы данных в хэш-таблицу.
Import-CSV $Path | Group-Object -AsHashtable -Property email
Таким образом, в хэш-таблицу добавляются все строки, и указанное свойство используется как ключ для доступа к ним.
Копирование хэш-таблиц
Важно помнить, что хэш-таблицы являются объектами. А каждая переменная — это просто ссылка на объект. Это означает, что создание допустимой копии хэш-таблицы потребует больших усилий.
Присвоение ссылочных типов
Если есть одна хэш-таблица и она присвоена второй переменной, обе переменные указывают на одну и ту же хэш-таблицу.
PS> $orig = @{name='orig'}
PS> $copy = $orig
PS> $copy.name = 'copy'
PS> 'Copy: [{0}]' -f $copy.name
PS> 'Orig: [{0}]' -f $orig.name
Copy: [copy]
Orig: [copy]
Это подчеркивает, что они одинаковые, так как при изменении значений в одной из них также меняются значения в другой. Данное правило также применимо при передаче хэш-таблиц в другие функции. Если эти функции вносят изменения в данную хэш-таблицу, то оригинал также изменится.
Неполные копии, одноуровневые
Если есть простая хэш-таблица, как в нашем примере выше, можно использовать .Clone() для создания неполной копии.
PS> $orig = @{name='orig'}
PS> $copy = $orig.Clone()
PS> $copy.name = 'copy'
PS> 'Copy: [{0}]' -f $copy.name
PS> 'Orig: [{0}]' -f $orig.name
Copy: [copy]
Orig: [orig]
Это позволит нам вносить базовые изменения в одни данные, и эти изменения не повлияют на другие данные.
Неполные копии, вложенные
Такая копия называется неполной, поскольку в нее добавляются только свойства базового уровня. Если одно из этих свойств является ссылочным типом (например, другой хэш-таблицей), то эти вложенные объекты по-прежнему будут указывать друг на друга.
PS> $orig = @{
person=@{
name='orig'
}
}
PS> $copy = $orig.Clone()
PS> $copy.person.name = 'copy'
PS> 'Copy: [{0}]' -f $copy.person.name
PS> 'Orig: [{0}]' -f $orig.person.name
Copy: [copy]
Orig: [copy]
Итак, вы видите, что, несмотря на то, что я клонировал хэш-таблицу, ссылка на person не была клонирована. Чтобы получить вторую хэш-таблицу, которая не связана с первой, необходимо создать полную копию.
Полные копии
Есть несколько способов создать полную копию хэш-таблицы (оставив ее хэш-таблицей). Следующая функция использует PowerShell для рекурсивного создания полной копии:
function Get-DeepClone
{
[CmdletBinding()]
param(
$InputObject
)
process
{
if($InputObject -is [hashtable]) {
$clone = @{}
foreach($key in $InputObject.keys)
{
$clone[$key] = Get-DeepClone $InputObject[$key]
}
return $clone
} else {
return $InputObject
}
}
}
При этом не обрабатываются любые другие ссылочные типы или массивы, но это хорошая отправная точка.
Другой способ — использовать .NET для десериализации таблицы с помощью CliXml, как в следующей функции:
function Get-DeepClone
{
param(
$InputObject
)
$TempCliXmlString = [System.Management.Automation.PSSerializer]::Serialize($obj, [int32]::MaxValue)
return [System.Management.Automation.PSSerializer]::Deserialize($TempCliXmlString)
}
Для очень больших хэш-указателей функция десериализации быстрее, так как она масштабируется. Однако при использовании этого метода следует учитывать некоторые аспекты. Из-за использования CliXml потребляется много памяти, что при клонировании огромных хэш-таблиц может вызвать проблемы. Еще один недостаток CliXml в том, что максимальная глубина вложения ограничена 48 уровнями. Это значит, что если у вас есть хэш-таблица с 48 уровнями вложенных хэш-таблиц, клонирование завершится сбоем и в результате вы ничего не получите.
Что-нибудь еще?
Я кратко охватил большое количество вопросов. Надеюсь, что при каждом прочтении вы будете находить для себя что-то новое. Хотя я рассмотрел весь спектр возможностей этой функции, есть все-таки несколько аспектов, которые в настоящее время могут быть неприменимы. Это вполне приемлемо и ожидаемо. Все зависит от того, насколько активно вы используете PowerShell.
PowerShell
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по