Search this book | Previous | Table of contents | Next

Decoding and reading the input in your scripts


This section explains how to decode and read the contents of variables once they have been sent to your scripts.

As you may have noticed from the previous sections, the actual data sent by the client application through the server and received by your scripts look pretty cryptic. If you used the .script technique or the GET method in your FORMS, then every space in your original input got translated into a plus sign (+). You also may have noticed the names of your variables, a few equals signs (=), and a few ampersands (&) as well. This translation process is a part of the Uniform Resource Locator specification and is all a consequence of the GET method. For example, a piece of the search arguments may look like this:

textField=This+is+a+simple+text+field&passwordField=watermellon
If you used the POST method in your FORMs, then more translations occur. Specifically, all the reserved characters for URLs get translated into their hexadecimal equivalents. An example of the POST arguments could include:
addition=2+%2B+3+%3D+5
This translates to:
addition=2 + 3 = 5
These translation processes make the content of your search arguments and/or POST arguments difficult to humanly read. Furthermore, in order to do any processing on the contents of these variables you need to parse out the necessary information. This section describes how to accomplish this goal.

The hard way to translate (decode) these search and POST arguments is through the judicious use of repeat loops and various incarnations of the AppleScript's text item delimiters command. Frankly, this is just too difficult.

The next easiest way to decode and parse the search and/or POST arguments is through the combined use of two OSAX: Decode URL and Tokenize. Both of these OSAX are free and described in the next chapter, "OSAX for WWW scripting", but they have been superseded by the following OSAX.

Parse CGI is the OSAX of choice when it comes to decoding and parsing your search and/or POST arguments. This shareware tool is indispensable. Its cost is well worth the time and effort is saves you in, to turn a corporate phrase, "opportunity costs."

To demonstrate how to use Parse CGI, the following FORM is used to send input to a new script Dear Santa.


What would you like to say to Santa Claus?

Sign your name.

Send or reset the message.


Here is the FORM in raw HTML. Note the METHOD is POST and therefore the contents of the FORM are encoded and will be passed to the script as POST arguments. Note also the values of the NAME fields ("comment" and "signature"):

<HR>

<FORM ACTION="../scripts/dear-santa.cgi" METHOD=POST>

What would you like to say to Santa Claus?<br>
<TEXTAREA NAME="comment" ROWS=4 COLS=65>Dear Santa,

I have been very good this year.
Please send me an Internet connection for Christmas this year.
</TEXTAREA><p>

Sign your name.<br>
<INPUT TYPE="text" NAME="signature" VALUE="Cybernaut" SIZE=40 MAX=40><p>

Send or reset the message.<br>
<INPUT TYPE="submit" VALUE="Send"> <INPUT TYPE="reset" VALUE="Reset">

</FORM>

<HR>

Here is the script used to analyze the example:

-- process the AppleEvent sent to this script by the server
on «event WWW*sdoc» given «class post»:post_args
	
	-- practice good error trapping
	try
		
		-- define the HTTP header as usual
		set LF to ASCII character (10)
		set CR to return
		set CRLF to CR & LF
		set http_10_header to "HTTP/1.0 200 OK" & CRLF & ¬
			"Server: MacHTTP" & CRLF & ¬
			"MIME-Version: 1.0" & CRLF & ¬
			"Content-type: text/html" & CRLF & CRLF
		
		-- decode the data from the POST arguments
		set theFORMData to parse CGI arguments post_args
		
		-- extract each variable from the FORM data
		set theComment to CGI field "comment" from theFORMData
		set theSignature to CGI field "signature" from theFORMData
		
		-- return the results as an HTML file
		return http_10_header & ¬
			"<html>" & ¬
			"<head>" & ¬
			"<title>Reply</title>" & ¬
			"</head>" & ¬
			"<body>" & ¬
			"<b>post_args</b>: " & post_args & "<p>" & ¬
			"<b>comment</b>: " & theComment & "<p>" & ¬
			"<b>signataure</b>: " & theSignature & ¬
			"</body" & ¬
			"</html>"
		
	on error msg
		
		-- return the error as an HTML document
		return http_10_header & ¬
			"</html><head><title>Error</title></head>" & ¬
			"<body><h1>Error</h1>" & ¬
			"An error occured: " & msg & ¬
			"</body></html>"
		
	end try
	
end «event WWW*sdoc»

(Whew!) There are three important points to be made about this script.

First, since the FORM used the POST method, the server-defined AppleEvent keyword post had to be used to initialize the post_args variable. This was done on the second line of the script.

Next, the POSTed data needed to be decoded and parsed into a set of variable/data records. This was done with the line:

set theFORMData to parse CGI arguments post_args
The result is an AppleScript list put into the variable theFORMData.

Third, using the NAME attributes of the FORM, each one of the INPUT elements were extracted from the AppleScript list, in this case, theFORMData. This procedure was done with the following AppleScript:

set theComment to CGI field "comment" from theFORMData
set theSignature to CGI field "signature" from theFORMData
To bring the script home, the raw POST arguments, as well as the parsed variables were formatted into an HTML document and returned.

While this script does not perform any useful function, it demonstrates the best method to-date on how to extract the POST arguments sent to your server's scripts. At the same time, there are a few more options possible from the Parse CGI OSAX. These other options account for SELECT MULTIPLE INPUT elements. They also account for possibility that a particular element may have been given a null value. These options are left up you to explore and are described in the OSAX's dictionary.

Finally, these procedures would be exactly the same if you were to use the GET method in your scripts or the ISINDEX technique of getting input, except you would perform the parse CGI arguments command on the search arguments instead of the POST arguments.


Search this book | Previous | Table of contents | Next

This page was first published on September 26, 1995. Feel free to send comments.