about_Numeric_Literals
En este artículo se describe la sintaxis y el uso de valores numéricos en PowerShell.
Hay dos tipos de literales numéricos: entero y real. Ambos pueden tener sufijos de tipo y multiplicador.
Los literales enteros se pueden escribir en notación decimal, hexadecimal o binaria.
Los literales hexadecimales tienen el prefijo 0x
y los literales binarios tienen el prefijo 0b
para distinguirlos de los números decimales.
Los literales enteros pueden tener un sufijo de tipo y un sufijo multiplicador.
Sufijo | Significado | Nota |
---|---|---|
y |
tipo de datos de byte firmado | Agregado en PowerShell 6.2 |
uy |
tipo de datos de bytes sin signo | Agregado en PowerShell 6.2 |
s |
tipo de datos short | Agregado en PowerShell 6.2 |
us |
tipo de datos corto sin signo | Agregado en PowerShell 6.2 |
l |
tipo de datos long | |
u |
tipo de datos unsigned int o long | Agregado en PowerShell 6.2 |
ul |
tipo de datos long sin signo | Agregado en PowerShell 6.2 |
n |
Tipo de datos BigInteger | Agregado en PowerShell 7.0 |
kb |
kibibyte (10241) multiplicador | |
mb |
mebibyte (10242) multiplicador | |
gb |
gigibyte (10243) multiplicador | |
tb |
teribyte (10244) multiplicador | |
pb |
petibyte (10245) multiplicador |
El tipo de un literal entero viene determinado por su valor, el sufijo de tipo y el sufijo multiplicador numérico.
Para un literal entero sin sufijo de tipo:
- Si el valor se puede representar mediante el tipo
[int]
, es su tipo. - De lo contrario, si el valor se puede representar mediante el tipo
[long]
, que es su tipo. - De lo contrario, si el valor se puede representar mediante el tipo
[decimal]
, que es su tipo. - De lo contrario, se representa mediante el tipo
[double]
.
Para un literal entero con un sufijo de tipo:
- Si el sufijo de tipo es
u
y el valor se puede representar mediante el tipo[uint]
, su tipo es[uint]
. - Si el sufijo de tipo es
u
y el valor se puede representar mediante el tipo[ulong]
, su tipo es[ulong]
. - Si su valor se puede representar mediante el tipo especificado, ese es su tipo.
- De lo contrario, ese literal tiene un formato incorrecto.
Los literales reales solo se pueden escribir en notación decimal. Esta notación puede incluir valores fraccionarios después de un separador decimal y una notación científica mediante una parte exponencial.
La parte exponencial incluye un "e" seguido de un signo opcional (+/-) y un número que representa el exponente. Por ejemplo, el valor literal 1e2
es igual al valor numérico 100.
Los literales reales pueden tener un sufijo de tipo y un sufijo multiplicador.
Sufijo | Significado |
---|---|
d |
tipo de datos decimal |
kb |
kibibyte (10241) multiplicador |
mb |
mebibyte (10242) multiplicador |
gb |
gigibyte (10243) multiplicador |
tb |
teribyte (10244) multiplicador |
pb |
petibyte (10245) multiplicador |
Hay dos tipos de literales reales: double y decimal. Estos se indican mediante la ausencia o presencia, respectivamente, del sufijo de tipo decimal. PowerShell no admite una representación literal de un valor [float]
. Un literal real doble tiene el tipo [double]
. Un literal real decimal tiene el tipo [decimal]
.
Los ceros finales de la parte de fracción de un literal real decimal son significativos.
Si el valor de los dígitos del elemento exponente en un [double]
literal real es menor que el mínimo admitido, el valor de ese [double]
literal real es 0. Si el valor de los dígitos de la parte exponente en un [decimal]
literal real es menor que el mínimo admitido, ese literal tiene un formato incorrecto. Si el valor de los dígitos de la parte exponente en un [double]
o [decimal]
literal real es mayor que el máximo admitido, ese literal tiene un formato incorrecto.
Nota
La sintaxis permite que un literal real doble tenga un sufijo de tipo largo.
PowerShell trata este caso como un literal entero cuyo valor se representa mediante el tipo [long]
. Esta característica se ha conservado por motivos de compatibilidad con versiones anteriores de PowerShell. Sin embargo, no se recomienda que los programadores usen literales enteros de este formato, ya que pueden ocultar fácilmente el valor real del literal. Por ejemplo, 1.2L
tiene el valor 1, 1.2345e1L
tiene el valor 12 y 1.2345e-5L
tiene el valor 0, ninguno de los cuales es inmediatamente obvio.
Para mayor comodidad, los literales enteros y reales pueden contener un multiplicador numérico, que indica uno de un conjunto de potencias de uso común de 2. El multiplicador numérico se puede escribir en cualquier combinación de letras mayúsculas o minúsculas.
Los sufijos multiplicadores se pueden usar en combinación con cualquier sufijo de tipo, pero deben estar presentes después del sufijo de tipo. Por ejemplo, el 100gbL
literal tiene un formato incorrecto, pero el literal 100Lgb
es válido.
Si un multiplicador crea un valor que supera los valores posibles para el tipo numérico que especifica el sufijo, el literal tiene un formato incorrecto. Por ejemplo, el literal 1usgb
tiene un formato incorrecto, ya que el valor 1gb
es mayor que lo que se permite para el tipo de [ushort]
especificado por el sufijo us
.
PS> 1kb
1024
PS> 1.30Dmb
1363148.80
PS> 0x10Gb
17179869184
PS> 1.4e23tb
1.5393162788864E+35
PS> 0x12Lpb
20266198323167232
PowerShell admite los siguientes aceleradores de tipos:
Nota
Los siguientes aceleradores de tipos se agregaron en PowerShell 6.2: [short]
, [ushort]
, [uint]
, [ulong]
.
La tabla siguiente contiene varios ejemplos de literales numéricos y enumera su tipo y valor:
Número | Tipo | Valor |
---|---|---|
100 | Int32 | 100 |
100u | UInt32 | 100 |
100D | Decimal | 100 |
100l | Int64 | 100 |
100uL | UInt64 | 100 |
100us | UInt16 | 100 |
100uy | Byte | 100 |
100y | SByte | 100 |
1e2 | Doble | 100 |
1.e2 | Doble | 100 |
0x1e2 | Int32 | 482 |
0x1e2L | Int64 | 482 |
0x1e2D | Int32 | 7725 |
482D | Decimal | 482 |
482gb | Int64 | 517543559168 |
482ngb | BigInteger | 517543559168 |
0x1e2lgb | Int64 | 517543559168 |
0b1011011 | Int32 | 91 |
0xFFFFs | Int16 | -1 |
0xFFFFFFFF | Int32 | -1 |
-0xFFFFFFFF | Int32 | 1 |
0xFFFFFFFFu | UInt32 | 4294967295 |
Los literales binarios o hexadecimales demasiado grandes pueden devolverse como [bigint]
en lugar de conmutar por error el análisis, si y solo si se especifica el sufijo n
. Los bits de signo todavía se respetan por encima de incluso [decimal]
intervalos, pero:
- Si una cadena binaria es un múltiplo de 8 bits de longitud, el bit más alto se trata como el bit de signo.
- Si una cadena hexadecimal, que tiene una longitud que es un múltiplo de 8, tiene el primer dígito con 8 o superior, el número se trata como negativo.
Al especificar un sufijo sin firmar en literales binarios y hexadecimales, se omiten los bits de signo. Por ejemplo, 0xFFFFFFFF
devuelve -1
, pero 0xFFFFFFFFu
devuelve el [uint]::MaxValue
de 4294967295.
En PowerShell 7.1, el uso de un sufijo de tipo en un literal hexadecimal ahora devuelve un valor con signo de ese tipo. Por ejemplo, en PowerShell 7.0, la expresión 0xFFFFs
devuelve un error porque el valor positivo es demasiado grande para un tipo de [int16]
.
PowerShell 7.1 interpreta esto como -1
que es un tipo de [int16]
.
Al prefijar el literal con un 0
se omitirá y se tratará como sin signo.
Por ejemplo: 0b011111111
. Esto puede ser necesario cuando se trabaja con literales en el intervalo de [bigint]
, ya que no se pueden combinar los sufijos u
y n
.
También puede negar literales binarios y hexadecimales mediante el prefijo -
. Esto puede dar lugar a un número positivo, ya que se permiten bits de signo.
Los bits de signo se aceptan para números con sufijo BigInteger:
- BigInteger-sufijo hexadecimal trata el bit alto de cualquier literal con una longitud múltiplo de 8 caracteres como bit de signo. La longitud no incluye el prefijo
0x
ni ningún sufijo. - BigInteger-sufijo binario acepta bits de signo en 96 y 128 caracteres, y en cada 8 caracteres después.
Cuando las cadenas se convierten en números, se admiten indicadores de formato hexadecimal adicionales. Esos formatos adicionales no se reconocen como literales.
[int] '0xF' -eq 0xF
[int] '&hF' -eq 0xF
[int] '#F' -eq 0xF
[int] '0b1111' -eq 0b1111
[int] '0b1111' -eq 15
Cualquier comando que parezca un literal numérico válido debe ejecutarse mediante el operador de llamada (&
), de lo contrario, se interpreta como un número. Los literales con formato incorrecto con sintaxis válida como 1usgb
producirán el siguiente error:
PS> 1usgb
At line:1 char:6
+ 1usgb
+ ~
The numeric constant 1usgb is not valid.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : BadNumericConstant
Sin embargo, los literales con formato incorrecto con sintaxis no válida, como 1gbus
, se interpretarán como una cadena completa estándar y se pueden interpretar como un nombre de comando válido en contextos donde se puede llamar a los comandos.
Para acceder a un miembro de un literal numérico, hay casos en los que es necesario incluir el literal entre paréntesis.
- El literal no tiene un separador decimal
- El literal no tiene ningún dígito después del separador decimal.
- El literal no tiene un sufijo
Por ejemplo, se produce un error en el ejemplo siguiente:
PS> 2.GetType().Name
At line:1 char:11
+ 2.GetType().Name
+ ~
An expression was expected after '('.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ExpectedExpression
Los ejemplos siguientes funcionan:
PS> 2uL.GetType().Name
UInt64
PS> 1.234.GetType().Name
Double
PS> (2).GetType().Name
Int32
Los dos primeros ejemplos funcionan sin incluir el valor literal entre paréntesis porque el analizador de PowerShell puede determinar dónde finaliza el literal numérico y se inicia el método GetType.
PowerShell v7.0 cambió la forma en que se analizan los literales numéricos para habilitar las nuevas características.
Si el literal contiene un separador decimal o la notación electrónica, la cadena literal se analiza como un número real.
- Si el sufijo decimal está presente, directamente en
[decimal]
. - En caso contrario, analice como
[Double]
y aplique multiplicador al valor. A continuación, compruebe los sufijos de tipo e intente convertir en el tipo adecuado. - Si la cadena no tiene ningún sufijo de tipo, analice como
[Double]
.
Los literales de tipo entero se analizan mediante los pasos siguientes:
- Determinación del formato radix
- En el caso de los formatos binarios, analice en
[BigInteger]
. - En el caso de los formatos hexadecimales, analice en
[BigInteger]
usando casos especiales para conservar los comportamientos originales cuando el valor se encuentra en el intervalo de[int]
o[long]
. - Si ni binario ni hexadecimal, analice normalmente como un
[BigInteger]
.
- En el caso de los formatos binarios, analice en
- Aplique el valor del multiplicador antes de intentar las conversiones para asegurarse de que los límites de tipo se pueden comprobar adecuadamente sin desbordamientos.
- Compruebe los sufijos de tipo.
- Compruebe los límites de tipo e intente analizar en ese tipo.
- Si no se usa ningún sufijo, el valor se enlaza en el orden siguiente, lo que da lugar a la primera prueba correcta que determina el tipo del número.
[int]
[long]
-
[decimal]
(solo literales base-10) -
[double]
(solo literales base-10)
- Si el valor está fuera del intervalo de
[long]
para los números hexadecimales y binarios, se produce un error en el análisis. - Si el valor está fuera del intervalo de
[double]
para el número base 10, se produce un error en el análisis. - Los valores más altos deben escribirse explícitamente mediante el sufijo
n
para analizar el literal como unBigInteger
.
Anteriormente, los valores enteros más altos se analizaban como double antes de convertirse en cualquier otro tipo. Esto produce una pérdida de precisión en los intervalos más altos. Por ejemplo:
PS> [bigint]111111111111111111111111111111111111111111111111111111
111111111111111100905595216014112456735339620444667904
Para evitar este problema, tenía que escribir valores como cadenas y, a continuación, convertirlos:
PS> [bigint]'111111111111111111111111111111111111111111111111111111'
111111111111111111111111111111111111111111111111111111
En PowerShell 7.0, debe usar el sufijo N
.
PS> 111111111111111111111111111111111111111111111111111111n
111111111111111111111111111111111111111111111111111111
También se deben indicar valores entre [ulong]::MaxValue
y [decimal]::MaxValue
mediante el D
de sufijo decimal para mantener la precisión. Sin el sufijo, estos valores se analizan como [Double]
mediante el modo de análisis real.
Comentarios de PowerShell
PowerShell es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: