PowerShell 中的字符串比较似乎不起作用
我正在尝试将一个数组中的字符串与另一个数组中的每个字符串进行比较。当前的方法是有效的,因为我已经使用更简单的变量对其进行了测试,并且它可以正确地检索它们。但是,我需要它进行比较的字符串似乎不受比较的影响。
该方法如下:
$counter = 0
for ($num1 = 0; $num1 -le $serverid_oc_arr.Length; $num1++) {
for ($num2 = 0; $num2 -le $moss_serverid_arr.Length; $num2++) {
if ($serverid_oc_arr[$num1] -eq $moss_serverid_arr[$num2]) {
break
}
else {
$counter += 1
}
if ($counter -eq $moss_serverid_arr.Length) {
$unmatching_serverids += $serverid_oc_arr[$num1]
$counter = 0
break
}
}
}
对于第一个数组中的每个字符串,它在第二个数组中的所有字符串之间迭代并比较它们。如果它找到相等,它将中断并转到第一个数组中的下一个字符串。如果不存在,则对于每个不等式,它都会添加到计数器中,并且每当计数器达到第二个数组的长度(意味着第二个数组中没有找到等式)时,它就会将相应的字符串添加到假定的第三个数组中最后检索与第二个数组中的任何内容都不匹配的所有字符串。然后计数器再次设置为 0 并中断,以便它可以从第一个数组转到下一个字符串。
这在理论上是没问题的,而且在实践中也适用于更简单的字符串,但是我需要它使用的字符串是服务器 ID,如下所示:
289101b4-3e6c-4495-9c67-f317589ba92c
因此,脚本似乎完全忽略了比较,只是将所有字符串从将第一个数组放入第三个数组中,并在最后检索它们(有时还从第一个和第二个数组中检索一些随机字符串)。
我尝试过的另一种具有类似结果的方法是:
$unmatching_serverids = $serverid_oc_arr | Where {$moss_serverid_arr -NotContains $_}
任何人都可以发现我在任何地方可能犯的错误吗?
I am trying to compare strings from one array to every string from the other. The current method works, as I have tested it with simpler variables and it retrieves them correctly. However, the strings that I need it to compare don't seem to be affected by the comparison.
The method is the following:
$counter = 0
for ($num1 = 0; $num1 -le $serverid_oc_arr.Length; $num1++) {
for ($num2 = 0; $num2 -le $moss_serverid_arr.Length; $num2++) {
if ($serverid_oc_arr[$num1] -eq $moss_serverid_arr[$num2]) {
break
}
else {
$counter += 1
}
if ($counter -eq $moss_serverid_arr.Length) {
$unmatching_serverids += $serverid_oc_arr[$num1]
$counter = 0
break
}
}
}
For each string in the first array it is iterating between all strings in the second and comparing them. If it locates equality, it breaks and goes to the next string in the first array. If it doesn't, for each inequality it is adding to the counter and whenever the counter hits the length of the second array (meaning no equality has been located in the second array) it adds the corresponding string to a third array that is supposed to retrieve all strings that don't match to anything in the second array in the end. Then the counter is set to 0 again and it breaks so that it can go to the next string from the first array.
This is all okay in theory and also works in practice with simpler strings, however the strings that I need it to work with are server IDs and look like this:
289101b4-3e6c-4495-9c67-f317589ba92c
Hence, the script seems to completely ignore the comparison and just puts all the strings from the first array into the third one and retrieves them at the end (sometimes also some random strings from both first and second array).
Another method I tried with similar results was:
$unmatching_serverids = $serverid_oc_arr | Where {$moss_serverid_arr -NotContains $_}
Can anyone spot any mistake that I may be making anywhere?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的代码的问题主要是使用
-le
而不是-lt
,集合索引从0
开始,集合的Length
或Count
属性从1
开始。这导致$null
值被添加到您的结果集合中。除了上述内容之外,如果不满足以下条件,
$counter
永远不会重置:您需要在内部 for 循环外部添加一个
$counter = 0
防止这种情况发生。除了证明其有效的测试用例之外,您还可以在下面找到相同的算法,稍微改进。
作为侧面,可以使用
.ExceptWith(..)
方法 来自HashSet;类:
The issue with your code is mainly the use of
-le
instead of-lt
, collection index starts at0
and the collection'sLength
orCount
property starts at1
. This was causing$null
values being added to your result collection.In addition to the above,
$counter
was never getting reset if the following condition was not met:You would need to a add a
$counter = 0
outside inner for loop to prevent this.Below you can find the same, a little bit improved, algorithm in addition to a test case that proves it's working.
As side, the above could be reduced to this using the
.ExceptWith(..)
method fromHashSet<T>
Class:我为此找到的有效答案如下:
它和其他方法之间没有明显的差异(特别是对于 for 循环,这只是一个简化的变体),但不知何故它工作正常。
The working answer that I found for this is the below:
No obvious differences can be seen between it and the other methods (especially for the for-loop, this is just a simplified variant), but somehow this works correctly.