[chuuminggg]

For a part without a submitted file name, the curl request snippet puts the part's content directly into -F 'name=content'. curl gives some characters in an -F value a special meaning, so the command doesn't always send the documented content:

Part content	Generated option	What curl does
{"description": "foo; bar"}	-F 'metadata={"description": "foo; bar"}'	Sends {"description": "foo (truncated at ;)
@alice	-F 'mention=@alice'	Tries to upload the file alice and fails (exit code 26)
<b>bold</b>	-F 'note=<b>bold</b>'	Tries to read the field's content from the file b>bold</b> and fails (exit code 26)
(optional)	-F 'note=(optional)'	Starts a multipart/mixed subpart instead of sending the text

A ; anywhere in the value is the most likely case in practice, as it's common in JSON or text parts.

curl allows an -F value to be enclosed in double quotes. Within the quotes, \ escapes " and \, and none of the characters above has a special meaning. This PR quotes the value only when it's needed: when it starts with @, <, (, or ", or contains ;. Other values are written as before, so existing snippets don't change. A ;type= for the part's content type is still appended after the closing quote:

-F 'metadata="{\"description\": \"foo; bar\"}"'
-F 'note="(optional)";type=text/plain'

I checked each of the new expected commands with curl 8.16.0 against a local server that echoes the request body, and each one sends the original content. --form-string was another option, but it can't be combined with ;type=, so the part's content type would be lost.

I've based this on 4.0.x, as that's where #1058 changed the same method. The same problem exists in 3.0.x.

A submitted file name that contains ; or " (for example -F 'file=@a;b.png') has a similar problem. I've left it out to keep this change focused, but I'm happy to handle it as well.