Luego de mucho luchar pudimos encontrar el arreglo de este inconveniente que agunos lectores de esta web han tenido. Si tienes algún detalle que compartir no dejes de dejar tu información.
Solución:
PowerShell 3.0 tiene el nuevo comando Invoke-RestMethod:
http://technet.microsoft.com/en-us/library/hh849971.aspx
mas detalle:
A partir de Powershell 5.0, si no antes, curl es un alias para Invoke-WebRequest.
PS> Get-Alias -Definition Invoke-WebRequest | Format-Table -AutoSize
CommandType Name Version Source
----------- ---- ------- ------
Alias curl -> Invoke-WebRequest
Alias iwr -> Invoke-WebRequest
Alias wget -> Invoke-WebRequest
Para usar el comando sin alias…
PS> Invoke-WebRequest -Uri https://localhost:443/
PS> Invoke-WebRequest -Uri https://www.google.com
Así que devuelva varias propiedades de la solicitud de la siguiente manera…
PS> Invoke-WebRequest -Uri https://www.google.com StatusCode : 200 StatusDescription : OK Content : curlya no es un alias paraInvoke-WebRequest(el aliaswgettambién se elimina). En su lugar, useInvoke-WebRequestdirectamente.PS> Get-Alias -Definition Invoke-WebRequest | Format-Table -AutoSize CommandType Name Version Source ----------- ---- ------- ------ Alias iwr -> Invoke-WebRequestCurl ya no es un alias para Invoke-WebRequest (probado en Powershell 6.2.3), a pesar de un aparente rechazo de una moción en un RFC "para eliminar los alias curl y wget de Windows PowerShell".
Ese RFC señala "Los alias wget/curl ya se eliminaron de PowerShell Core, por lo que el problema [of having those aliases] estaba limitado a Windows PowerShell".
En la conclusión, el equipo de Powershell también alienta a los usuarios a "no confiar en los alias en los scripts".
Como @v6ak ha señalado en los comentarios usando
curlywgeten PowerShell (5.0 o anterior) puede ser un problema en: invocar involuntariamente el curl real o wget si se instalan uno al lado del otro; y, en todo caso, provoca confusión.Nueva codificación
Se recomienda actualizar el "núcleo" de Powershell (6.x o superior) para aprovechar la codificación predeterminada
utf8NoBOMcuando usasInvoke-WebRequest(y muchos otros comandos de salida de texto). Si uno estuviera haciendo esto explícitamente, podría hacer algo como:Invoke-WebRequest ` -Uri https://raw.githubusercontent.com/fancyapps/fancybox/master/dist/jquery.fancybox.min.js ` | Select-Object -ExpandProperty Content ` | Out-File jquery.fancybox.min.js ` -Encoding utf8NoBOMSin embargo, incluso cuando se usa un comando más corto e implícito...
Invoke-WebRequest ` -Uri https://raw.githubusercontent.com/fancyapps/fancybox/master/dist/jquery.fancybox.min.js ` -OutFile jquery.fancybox.min.js... codificación con
utf8NoBOMse hará (puede verificar esto, por ejemplo, abriendo el archivo guardado en Visual Studio Code y observando "UTF-8" en la barra de estado).archivos guardados con
utf8NoBOMtienden a causar menos problemas cuando viajan a través de varios ecosistemas. Por supuesto, si necesita alguna otra codificación, puede establecer alguna alternativa explícitamente.En Powershell 5.0 y baje el
utf8NoBOMla codificación no estaba disponible, y mucho menos la predeterminada.Detalles:
- Powershell 6, Referencia, Microsoft.PowerShell.Utility, Out-File, Parámetros, -Codificación
- Powershell 6, Novedades, Novedades en Powershell Core 6.x, Cambios importantes en Powershell Core 6.0, "Cambiar $OutputEncoding para usar la codificación UTF-8 NoBOM en lugar de ASCII #5369"
El excelente blog Command Line Kung Fu tiene una publicación donde comparan curl, wget y los comandos relacionados de PowerShell
En una palabra:
(New-Object System.Net.WebClient).DownloadString("http://www.example.com/hello-world.html","C:hello-world.html")
O, si su versión de Powershell/.Net no acepta 2 parámetros para DownloadString:
(New-Object System.Net.WebClient).DownloadString("http://www.example.com/hello-world.html") > "C:hello-world.html"
Acuérdate de que tienes la capacidad de comentar .