To make sure that the query gets through, we have to encode some characters so that they are not lost. For example, spaces are turned into + signs. Other characters are encoded in hex so that an ampersand in a field is encoded as three characters, eg %26. Other wacky characters, including a pound sign, are encoded as their Windows ANSI character set value. Although the user will see this encoding in the URL that your browser shows, the server usually does the decoding before presenting the information to your program.
As you can imagine, a URL can become pretty big with this method, so POST is recommended in which the data is sent separately from the URL, though encoded in the same way. We'll see how to pick up the information later.
The URL that is run when a form is completed has the same job - providing a response to the browser - except that the program has some extra input informing you of what the user said.
Before we proceed, it is very much worth while noting that you can add parameters, even to ordinary references to executables as URLs. If you have an executable URL of "http://wwwexe/dynamic.exe" you can pass it sub-directories and queries. Sub-directories are obvious, you just say "http://wwwexe/dynamic.exe/option1" and your program will receive /option1 as its "Logical Path" parameter. Queries, as noted above, are a question mark followed by any parameter(s), which must be encoded as described above; for example "http://wwwexe/dynamic.exe?pound+sign=%A3". Your program will receive a query both as a command line argument and as its "Query String" parameter.
Together these provide two different methods of passing parameters to a program. This is a useful technique when one program is re-used, ie you tell where it is called from by seeing which parameters have been passed.
For forms, I would suggest only using sub-directories in the ACTION URL. This is partly because queries can be used for GET results, but mainly because the image map support always returns its results using a query string.