Conversor curl
Convierte un comando en código

Qué hace un conversor curl

Un comando curl escribe una solicitud como línea de comandos. Este conversor curl convierte esa línea en código que puedes meter en un proyecto. Por eso la cabecera que copiaste de devtools conserva su valor exacto, y dejas de reescribirla.

De un pegado salen cuatro cosas. Primero, la solicitud en sí: método, dirección, cabeceras y cuerpo, leídos de vuelta para que los revises. Después, el código en el idioma que elegiste. Luego, las opciones que curl habría aplicado, como seguir redirecciones o un tiempo de espera. Por último, una lista de todo lo que el lector tuvo que decidir por su cuenta.

Esa última lista importa más de lo que parece. Una suposición silenciosa dentro del código generado es un error que encuentras en producción. Así que la página imprime cada decisión junto al código.

No instalas nada y no envías nada. Así que pegas un comando, lees el código y cierras la pestaña cuando te convenga.

Cómo lee un conversor curl un comando

El trabajo se divide en tres pasadas. Primero, la página parte el comando en palabras como lo haría un shell. Después lee cada palabra como opción, valor o dirección. Por último entrega la solicitud a un escritor del idioma que elegiste.

El corte sigue las reglas del shell para el entrecomillado, porque un comando pegado de devtools se apoya en ellas. Un cuerpo dentro de comillas simples es una sola palabra aunque contenga espacios. Una barra invertida al final de una línea la une a la siguiente.

Leer opciones es donde un conversor se gana el sueldo. Como curl lista más de doscientas opciones, solo algunas merecen conservarse. Las que importan cambian lo que ve un servidor. Son el método, las cabeceras, el cuerpo, las cookies, las redirecciones y el tiempo de espera. La página reporta el resto en lugar de adivinarlo.

Los escritores nunca tocan la red. Así que la página funciona sin conexión. También funciona en una máquina sin curl instalado. Un comando puede apuntar a una dirección que tu navegador no alcanza, y la página igual lo convierte.

Por qué el entrecomillado es la parte difícil

Un conversor que solo corta por espacios se equivoca en casi todos los comandos. Como el valor de una cabecera a menudo lleva un espacio, un corte ingenuo lo parte en dos. Entonces el código lleva medio token y la solicitud falla con un 401.

Así que el lector sigue el estado de las comillas mientras recorre la línea. Una comilla doble agrupa una serie de palabras en una, y una comilla simple hace lo mismo sin ningún escape dentro. Solo cuenta una comilla que abre y cierra en los sitios correctos.

La barra invertida es el tercer caso. Fuera de comillas escapa el carácter siguiente, y antes de un salto de línea elimina el propio salto. Por eso un comando pegado en veinte líneas sigue leyéndose como un solo comando.

Qué idiomas escribe

Trece destinos cubren el trabajo que casi todos traen aquí. Para PHP hay cURL básico y el cliente Guzzle. Para Python hay requests. Para JavaScript hay fetch, axios y el módulo http de Node.js. Go, Ruby, Java y C# reciben uno cada uno. Después vienen HTTP sin procesar, una línea curl limpia y JSON.

Cada escritor es una función pequeña sobre el mismo objeto de solicitud. Por eso todos los destinos ven bytes idénticos. El cuerpo que envía el ejemplo de PHP es el cuerpo que envía el de Go. Nada recorta una cabecera por idioma ni reformatea la carga en silencio.

Los escritores de PHP y Python apuntan a código que puedes ejecutar tal cual. Así que el de PHP abre con la etiqueta, define las opciones y cierra el manejador. El de Python importa requests, construye las cabeceras e imprime tanto el estado como el cuerpo.

JavaScript se divide en tres a propósito. Fetch viene en el navegador. Axios trae sus propias comodidades, y el módulo http de Node.js encaja en un script sin dependencias. Así que los tres se ganan un sitio.

Dos destinos son para leer más que para ejecutar. HTTP sin procesar imprime el mensaje como iría por el cable. Esa es la forma más rápida de ver si una cabecera está de verdad. JSON imprime la misma solicitud como datos, lista para un fixture de prueba.

Qué muestra el panel de lectura

Antes de que aparezca ningún código, la página imprime la solicitud que entendió. Nueve hechos reciben una línea cada uno. Cubren el método, la dirección, el número de cabeceras, el tamaño del cuerpo y el tipo de contenido. Después vienen la autorización, las cookies, las opciones y el tiempo de espera.

Las direcciones no son la parte interesante. Más bien, el punto es la comprobación. Una cabecera que se perdió aparece aquí antes de que pegues nada. También un cuerpo que llegó como formulario en vez de JSON. Una contraseña en el sitio equivocado también aparece.

La página imprime la lista de cabeceras completa debajo, una por línea. Por lo tanto comparas lo que enviaría curl con lo que espera tu servidor. Entonces la diferencia se ve en lugar de suponerse.

El panel nombra las opciones con palabras llanas. Quien lee el código no debería tener que saber que -L significa seguir redirecciones. El panel dice follow, insecure, compressed o silent en su lugar.

De devtools a un script en un pegado

La vía habitual es el navegador. Todo navegador grande puede copiar una solicitud como curl. Así que abre el panel de red, haz clic derecho en la llamada que falló, cópiala y pégala aquí. El comando llega con las cabeceras reales, el cuerpo real y las cookies reales.

Esa es también la forma habitual de depurar una llamada privada. Así que reproduces una solicitud fallida como código. Después añades un print y miras qué dice el servidor, en lugar de adivinar desde un panel de red.

Los saltos de línea no importan. Por lo tanto la página lee un comando copiado en veinte líneas igual que lee una sola. La indentación tampoco importa.