为何PowerShell中bor与bnot运算未得到预期结果？

嘿，我来帮你捋清楚这个问题——你遇到的坑其实是PowerShell的整数类型和位运算特性导致的，和IPv6的128位地址特性不匹配，具体来说有这几个关键点：

1. 整数位数根本不够用 #

IPv6是128位的地址，但PowerShell里默认的整数类型最多是64位（[long]），你用的0xffffffff只是32位的全1值，连IPv6地址的零头都覆盖不了。比如你要处理的/48子网掩码是ffff:ffff:ffff::，对应128位里前48位全1，剩下80位全0，你用32位的掩码去运算，高位的那些位根本没被处理，结果自然不对。

2. ~（二进制非）的行为和你想的不一样 #

PowerShell里的~是对有符号整数做补码运算的，不是无符号的按位取反。举个例子，0xffffffff作为32位有符号整数其实是-1，~-1得到的是0，这和你预期的无符号取反逻辑完全不是一回事。而IPv6的位运算需要的是无符号的128位按位取反，PowerShell默认的整数类型根本做不到这个。

3. 不能直接把IPv6地址当普通整数处理 #

IPv6地址的字符串表示（比如2001:db8:1234::）不能直接转成PowerShell的整数，因为没有原生的128位整数类型，强行转的话会被截断，导致地址信息丢失。

正确的做法：用.NET的IPAddress类处理 #

要正确计算IPv6子网的最后一个地址，得用System.Net.IPAddress类来操作字节数组，这样才能完整处理128位的地址。给你个示例脚本：

# 定义目标网络地址和前缀长度
$networkAddr = [System.Net.IPAddress]::Parse("2001:db8:1234::")
$prefixLength = 48

# 生成子网掩码的字节数组（16字节=128位）
$maskBytes = New-Object byte[] 16
# 先填充前缀长度对应的全1字节
for ($i = 0; $i -lt $prefixLength / 8; $i++) {
    $maskBytes[$i] = 0xff
}
# 如果前缀长度不是8的倍数，处理最后一个字节的剩余位（这里48是8的倍数，所以这段可以忽略，但留着兼容其他前缀）
$remainingBits = $prefixLength % 8
if ($remainingBits -gt 0) {
    $maskBytes[$prefixLength / 8] = [byte](0xff -shl (8 - $remainingBits))
}

# 计算广播地址：网络地址字节 | (~掩码字节)
$networkBytes = $networkAddr.GetAddressBytes()
$broadcastBytes = New-Object byte[] 16
for ($i = 0; $i -lt 16; $i++) {
    # 对字节用-bnot，这时候是无符号的按位取反
    $broadcastBytes[$i] = $networkBytes[$i] -bor (-bnot $maskBytes[$i])
}

# 把字节数组转成IPv6地址
$broadcastAddr = [System.Net.IPAddress]::new($broadcastBytes, [System.Net.Sockets.AddressFamily]::InterNetworkV6)

# 输出结果
$broadcastAddr.ToString()

运行这个脚本就能得到你想要的2001:db8:1234:ffff:ffff:ffff:ffff:ffff了。

简单说就是：别用普通整数硬刚IPv6，用字节数组和.NET的IPAddress类来处理，才能正确搞定128位的位运算。

内容的提问来源于stack exchange，提问作者leeand00