📄 ch12.htm
字号:
<TR><TD>
<BLOCKQUOTE>
<FONT COLOR=#000000>You can find utility </FONT>programs on the Internet that can help you efficiently create .map files. For Microsoft Windows users, try looking for them at Stroud's Consummate Winsock Application List:
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><A HREF="http://www.cwsapps.com">http://www.cwsapps.com</A></FONT></TT>
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>A Tale of Two Web Browsers</B></TD></TR>
<TR><TD><FONT COLOR=#000000>While preparing for </FONT>this chapter, I took a good, hard look at how imagemaps were handled by Web browsers, and I made some very interesting observations. In a variety of trial circumstances, my two trial browsers, Netscape
3.04b and Microsoft Internet Explorer 2.0, both had a very tough time properly determining the boundaries of the imagemaps I constructed.
<P>
Both could handle finding the upper-left corner of my images pretty well, but the bottom-right corner (reflecting on both the bottom and right sides of the image) was quite elusive to them; though I knew my test image was 200<FONT
FACE="Symbol">¥</FONT>100 pixels in size, I could get both browsers to tell me that I had clicked on pixel (202,103), for instance. Things got even less intuitive and more bizarre when I started doing things like setting <TT><FONT
FACE="Courier">BORDER=20</FONT></TT>, or <TT><FONT FACE="Courier">HEIGHT=50 WIDTH=50</FONT></TT>, or playing around with <TT><FONT FACE="Courier">HSPACE</FONT></TT> and <TT><FONT FACE="Courier">VSPACE</FONT></TT>.
<P>
Even worse, there was no consistency between how the two browsers reacted. For instance, with <TT><FONT FACE="Courier">BORDER=50</FONT></TT>, with Netscape I found that a click on the upper-left corner of the border would show 0,0 on the screen before
clicking but would pass -20,-20 to the imagemap handler! MSIE didn't show anything on the screen before clicking but passed 0,0 when I tried clicking on the upper-left part of the oversized border.
<P>
And so, my advice is: As with everything else on the Web, take imagemaps with a grain of salt. It might be helpful for you to remember the limits of Web browsers when creating .map files and imagemap handlers.
</TD></TR>
</TABLE></CENTER>
<P>
<H2><A NAME="ClientSideImagemapsandMagicMIMETyp"><FONT SIZE=5 COLOR=#FF0000>Client-Side
Imagemaps and Magic MIME Types</FONT></A></H2>
<P>
The best and worst labor-saving devices are those things that
save you the trouble of thinking. Thinking is difficult and time
consuming, and if you can get the job done without as much thought
as you might normally have to invest, then great. However, by
accepting someone else's prepackaged thought, you can fall into
the trap of accepting the limits they decided to put on the problem.
This undesirable condition runs rampant in the field of imagemap
handling.
<P>
As I've vented before in this chapter, canned imagemap code is
far too good. It's reasonably easy to install, easy to use, sufficiently
powerful enough that it covers just about all imagemap cases,
and allows people to forget that imagemaps can be treated as a
creative CGI challenge. But it gets even worse; the canonical
imagemap format has been considered a "standard" to
the point where some Web browsers and servers now have special
features that allow you to bypass imagemap.cgi altogether. These
features are client-side imagemaps and the .map Magic MIME type.
<H3><A NAME="ClientSideImagemaps">Client-Side Imagemaps</A></H3>
<P>
Newer versions of Netscape, Microsoft Internet Explorer, and Spyglass
Mosaic support a variant on the idea of an imagemap called a client-side
imagemap. This technique places the burden of processing the x,y
pair produced by the <TT><FONT FACE="Courier">ISMAP</FONT></TT>
attribute on the Web browser (the client) rather than on a remote
CGI program. As far as a Web page developer is concerned, this
is accomplished through completely nonstandard, nonsupported extensions
to HTML.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
The implementation of client-side imagemaps discussed here does not have much to do with the proposed HTML 3.0 draft on client-side imagemaps, which is tied to the <TT><FONT FACE="Courier"><FIG></FONT></TT> tag. However, virtually no browser supports
this style of client-side imagemaps while three of the biggest support the client-side imagemap system proposed by Spyglass-the system I talk about here. It practically reigns supreme. *sigh*
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
A client-side map is defined within the body of an HTML file.
The logic of the map structure is very similar to that found in
the .map files used by the ncSA imagemap.cgi program. I will include
a portion of an HTML file as an example and discuss it here. You
can see this example in action at
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><A HREF="http://www.anadas.com/">http://www.anadas.com/</A></FONT></TT>
</BLOCKQUOTE>
<P>
As you can see in Figure 12.3, the mouse-pointer shows its "pointing
hand" disposition as it is positioned to click on a client-side
imagemap. Note that the URL this click will invoke is displayed
at the bottom of the screen. This URL display appears only with
client-side imagemaps and not server-side imagemaps.
<P>
<A HREF="f12-3.gif" ><B>Figure 12.3:</B> <I>A client-side imagemap about to be invoked.</I></A>
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><MAP NAME=anyname><BR>
<AREA SHAPE=rect COORDS="0,0, 117,133" HREF=http://www.anadas.com/?minisearch>
<BR>
<AREA SHAPE=rect COORDS="118,0, 212,133" HREF=http://www.anadas.com/products/>
<BR>
<AREA SHAPE=rect COORDS="213,0, 306,133" HREF=http://www.anadas.com/?company>
<BR>
<AREA SHAPE=rect COORDS="307,0, 419,133" HREF=http://www.anadas.com/?quotes>
<BR>
<AREA SHAPE=default HREF=http://www.anadas.com><BR>
</MAP></FONT></TT>
</BLOCKQUOTE>
<P>
Here's a quick review of this syntax:
<UL>
<LI><FONT COLOR=#000000>To define a Spyglass style client-side
imagemap, start it with a </FONT><TT><FONT FACE="Courier"><MAP
NAME=anyname></FONT></TT> tag and end it with a <TT><FONT FACE="Courier"></MAP></FONT></TT>
tag.
<LI><FONT COLOR=#000000>For each geometrical shape, have an</FONT>
<TT><FONT FACE="Courier"><AREA SHAPE=anyshape></FONT></TT>
tag. Valid shapes are rect, circle, poly, and point-the same as
are valid with the ncSA imagemap program.
<LI><FONT COLOR=#000000>The coordinates of the shapes are described
within the </FONT><TT><FONT FACE="Courier">COORDS=area</FONT></TT>.
<LI><FONT COLOR=#000000>A </FONT><TT><FONT FACE="Courier">SHAPE=default</FONT></TT>
may be added. If this is not included, a click in an area not
defined by any <TT><FONT FACE="Courier">SHAPE</FONT></TT> will
not invoke any action.
<LI><FONT COLOR=#000000>An </FONT><TT><FONT FACE="Courier">HREF</FONT></TT>
must be specified as the action resulting from a click in the
<TT><FONT FACE="Courier">SHAPE</FONT></TT>.
<LI><FONT COLOR=#000000>To attach this client-side map to an image,
follow the format </FONT><TT><FONT FACE="Courier"><IMG SRC="images/mapped_image.gif"
USEMAP="#anyname"></FONT></TT>. Note that the <TT><FONT FACE="Courier">#anyname</FONT></TT>
associated with the <TT><FONT FACE="Courier">USEMAP</FONT></TT>
attribute must match the name assigned in the <TT><FONT FACE="Courier"><MAP></FONT></TT>
tag.
</UL>
<P>
A complete review of Spyglass-style client-side imagemaps can
be found online at
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><A HREF="http://www.spyglass.com/techspec/tutorial/img_maps.html">http://www.spyglass.com/techspec/tutorial/img_maps.html</A></FONT></TT>
</BLOCKQUOTE>
<H4>But Master, How Can I Depend on Client-Side Imagemaps When
So Many Browsers Don't Support Them?</H4>
<P>
An excellent question, grasshopper! The answer is that you don't
have to. You can set up a redundant scheme whereby an image is
tied to both a client-side and a server-side imagemap.
<P>
To do this, you must define a map in your HTML file as I talked
about earlier. You must also create a .map file and store it on
the server. Then, reference the image with the following:
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><A HREF="/cgi-bin/imagemap.cgi/pathinfo/file.map"><IMG
SRC="images/Âmapped_image.gif" USEMAP="#anyname"
ISMAP></A></FONT></TT>
</BLOCKQUOTE>
<P>
As always, insert an appropriate URL for the imagemap.cgi executable,
the <TT><FONT FACE="Courier">pathinfo</FONT></TT>, and map file
names.
<P>
When this format is used, the client-side imagemap is executed
if the browser being used supports client-side imagemaps. If it
doesn't, then all HTML having to do with client-side imagemaps
is ignored and then the markups relating to server-side imagemaps
kick in.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Caution</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
While this scheme certainly works, it can become an annoyance to maintain current map information in both the .map file and in the HTML file. There's no automatic way to deal with this; you'll just have to discipline yourself to do it.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<H3><A NAME="ThemapMagicMIMEType">The .map Magic MIME Type</A>
</H3>
<P>
Some CGI programmers are lucky enough to be able to control their
httpd configuration, either directly or by being "tight"
with the sysadmin. If you happen to be among these lucky few,
then this section could be of use to you. Even if you aren't,
you might be fortunate enough to have a sysadmin who pays special
attention to their httpd.
<P>
By way of a small refresher, the World Wide Web is a client/server
environment. Your Web browser (Netscape, Mosaic, MSIE, or Lynx)
is the client. Each time you try to load a Web page, it makes
a request of the Web server.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
<FONT COLOR=#000000>A Web server is also </FONT>known as an httpd, sometimes capitalized to HTTPd. This is an acronym standing for HyperText Transfer Protocol daemon. In the world of UNIX, a daemon is a program that lurks in the background and performs
system-related tasks that don't require any human intervention. Daemons are generally started at boot-time. An httpd is a daemon responsible for dealing with, or serving, hypertext transfer protocol requests.
</BLOCKQUOTE>
<BLOCKQUOTE>
I will discuss only the ncSA and Apache UNIX Web servers because they are</BLOCKQUOTE>
<UL>
<LI>Highly available
<LI>Widely installed and used
<LI>Well documented
<LI>Reasonably powerful
<LI>Completely free
<LI>Very similar to each other
</UL>
<BLOCKQUOTE>
Everything you ever wanted to know about these two Web servers can be found at</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier"><A HREF="http://hoohoo.ncsa.uiuc.edu/">http://hoohoo.ncsa.uiuc.edu/</A><BR>
<A HREF="http://www.apache.org/">http://www.apache.org/</A></FONT></TT>
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
The ncSA and Apache Web servers are quite configurable. One of
the more interesting sections when configuring one of these Web
server is the "Magic MIME Type" area. This can be found
in the ~/conf/srm.conf file, where ~ represents the home-level
directory of the Web server installation, also known as ServerRoot.
I'll quote a portion of this file here:
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Caution</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
ServerRoot and DocumentRoot are two different configuration variables. For instance, a system might have ServerRoot set at /var/www and DocumentRoot at /var/www/docs. ServerRoot is defined in the httpd.conf file while DocumentRoot is defined in the
srm.conf file.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<BLOCKQUOTE>
<TT><FONT FACE="Courier"># The following are known to the server
as "Magic Mime Types" They allow<BR>
# you to change how the server perceives a document by the extension.
<BR>
# The server currently recognizes the following mime types for
server side<BR>
# includes, internal imagemap, and CGI anywhere. Uncomment
them to use them.<BR>
# Note: If you disallow (in access.conf) Options Includes ExecCGI,
and you<BR>
# uncomment the following, the files will be passed with the magic
mime type<BR>
# as the content type, which causes most browsers to attempt to
save the<BR>
# file to disk.<BR>
<BR>
#AddType text/x-server-parsed-html .shtml<BR>
#AddType text/x-imagemap .map<BR>
#AddType application/x-httpd-cgi .cgi</FONT></TT>
</BLOCKQUOTE>
<P>
The .map Magic MIME type is supported by the new ncSA/1.5 httpd
and in the beta release of Apache httpd 1.1. It is unlikely that
your sysadmin will upgrade to either of these newer httpds without
it being brought explicitly to their attention, but beware! Sysadmins
are quick to anger and their vengeance is mighty.
<P>
This about says it all except for the conclusion: Removing the
<TT><FONT FACE="Courier">#</FONT></TT> character from the front
of any of these lines and then rebooting the httpd will give you
access to that Magic MIME type. If you enable .shtml as a Magic
MIME type, then server-parsed HTML files can be accessed outside
of directories that are specifically assigned to this role. Enabling
the .cgi line will allow the Web server to run CGI files in directories
outside of /cgi-bin/. Enabling the .map line will give you awesome
cosmic powers!
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Enabling the .map line won't give you awesome cosmic powers. However, enabling the .cgi Magic MIME type can be very useful. You might find that this doesn't work the first time around, though. The .cgi Magic MIME type depends somewhat on the setting of a
line in the accces.conf file. If you have any problems with enabling the .cgi line in srm.conf, check to see if your access.conf file has an</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">Options Includes ExecCGI</FONT></TT>
</BLOCKQUOTE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -