a one and a two

1、注重性价比 2、慧眼识好货 3、掏钱时不勉强不将就事后不后悔 4、购物就是购物不和情绪发泄扯上关系 5、看上什么过两小时或者两天甚至两周再看看是不是还想买 6、多给自己出选择题两样只能买一样今天只能花多少哪个可暂时不买

简介

一般而言，非美国公民或居民所收取的美国来源收入，均须缴纳美国税款。作为在美国的证券经纪商，嘉信理财必须为非美国人客户预扣美国来源收入的美国所得（入息）税。

为了符合美国国税局 ("IRS") 的报税规定，非美国人必须向国税局及嘉信理财递交国税局表格 W-8BEN，申报所居国家以证实其为非美国公民或居民的身份。嘉信将根据客户在国税局表格 W-8BEN 上所申报的居住国家，预扣非美国人客户的美国税款。

如果帐户没有存备每名与帐户有关人士的有效国税局表格 W-8BEN 及附以所需的证明文件，嘉信便必须预扣帐户内 30% 的全部出售所得以及因公司重组所产生的其它现金收入。在没有有效国税局表格 W-8BEN 的情况下，嘉信亦必须预扣非美国人客户帐户内最高税率 (30%) 的税款，该税率高对一般居住在与美国有税务协议国家的居民的税率。嘉信将每年以国税局表格 1042-S，向国税局及帐户报告 W-8BEN 表格上涵括的资料。 请参阅国税局 Publication 515，以取得更多关于适用于非美国居民税率的资料。

确定非美国人身份

非美国人（或非美国居民外籍人士 "non-resident alien"）是指不属于美国公民或美国合法居民的人士。外国人包括非居民外籍个别人士 ("non-resident alien individual")、外国公司、外国合伙人、外国信托、外国遗产、以及其它不属于美国人的人士。

如帐户内有任何持有人为美国公民或合法美国居民，该帐户可能不会被列为非美国居民帐户，而必须开设为美国居民帐户，并会将该名美国人客户的姓名列为首位帐户持有人。须申报的帐户活动会使用该名美国人帐户持有人的纳税编号报税，而该名美国人帐户持有人必须在国税局表格 W-9 上，证实其纳税编号。

客户必须自行确定他们是否美国居民。嘉信不能为客户确定其所居地。不过，如果嘉信得悉帐户持有人是美国人，直至收到该名帐户持有人的国税局表格 W-9 前，所有适当的帐户活动将会按照适用于尚未证实为美国帐户的预扣税率计算。

什么是美国来源收入？

概括而言，在美国税务规定下的“美国来源收入”释义为来自由美国公司或美国注册共同基金发出的证券的股息及利息收入。此外，来自美国国库债券及美国联邦机构债券的所得利息亦为美国来源收入。因此，在某程度上，如您有来自美国公司、美国注册共同基金、美国国库债券或美国联邦机构债券的股息或利息，其数额将包括在我们必须送交国税局的每年报税表内。

什么是非美国居民外籍人士预扣税 (Non-Resident Alien Withholding or NRA Withholding)？

一般而言，一名外国人必须为其美国来源收入缴纳美国税款。必须缴税的投资收入包括美国公司分派的股息收入，以及某些利息收入。非美国人的税率是 30%，不过，视乎该名外国人的国家与美国之间的税务协议，税率可能低于 30% 或者获豁免税款。国税局规定嘉信须从付给外国人的收入中预扣本项税款（“非美国居民外籍人士预扣税”NRA Withholding）。

在美国的证券经纪商必须每年以国税局表格 1042-S，向国税局申报所有该公司每个帐户的美国来源收入。所有给外国人的收入（包括非美国居民外籍人士、外国机构及政府），亦可能受到非美国居民外籍人士预扣税的规定。

您应咨询您的税务顾问，以确定您帐户内任何所得收入的预扣税款，是否符合视乎您所居地而定的外国税款减免资格。

国税局表格 W-8BEN 与非美国居民外籍人士预扣税 (NRA Withholding)

为了预扣正确的税款（税率一般由 0% 至 30% 不等，视乎帐户持有人的所居国家），非美国人客户必须向嘉信提供有效的国税局表格 W-8BEN，并附以国税局或嘉信规定的所需证明文件。

在向嘉信递交国税局表格 W-8BEN 后、或在原来的国税局表格 W-8BEN 上更改资料后的第三年的 12 月 31 日之前，客户必须重新证明其非美国人所居地身份。如果我们没有每名帐户持有人的有效国税局表格 W-8BEN 纪录，我们必须以最高税率（现时为 30%）预扣帐户内股息及利息的税款。此外，我们亦必须预扣帐户的出售所得及其它收入的 30% 税款。

请用英文填写

W-8表格PDF版下载W-8表格PDF版下载 Part I

1.帐户名称 (Name of individual or organization that is the beneficial owner) -> 请填写您的姓名或第一帐户的帐户名称

2. 国籍 (Country of incorporation or organization) -> 请填写您的国籍

3. 帐户种类 (Type of beneficial owner) -> 个人帐户请选 Individual -> 共同帐户必须填写两份 W-8 BEN, 帐户持有人及共同子持有人都必须填写 -> 监护人帐户, 被监护人必须有美国社会安全号码, 不需填写W-8BEN

4. 永久居住地址 Permanent residence address -> 外国帐户需有填写非美国住址

5. 邮寄地址 Mailing address -> 如果不同与您的居住地址

6. 美国赋税编号 (没有者不需填写) U.S.Taxpayer identification number. -> 如果您有美国税务编号请填写

7. 外国赋税编号 (选择性提供) Foreign tax identifying number

8. 第一理财帐户号码 Reference number(s)

Part II 如果您的国家与美国有关税优惠, 请圈选 a 并填写国籍. 中国大陆, 新加坡必须填写 Part II 台湾, 香港特区不须填写 Part II

Part III (选择性提供)

Part IV 签名 Sign Here

表格用途： 本表格适用于非美国居民向美国国税局申报美国所得税减免时使用。如果您所居住的国家为美国的税务减免互惠国， 您便可能符合减税或免税的资格。请到美国国税局网站 www.irs.gov 做进一步了解。请将您的 W8 表格寄到史考特证 券，不要送到美国国税局。 表格不适用于： 应使用表格 ? 非美国居民本年度在美国居住超过 183 天(含 183 天)，但持有 F，J，M，Q 签证者不在此限。如您持有上述 种类签证，请在此注明签证类别： ? 美国公民，永久居民或美国税法所定义的外国居民………………………………………………………………W9 ? 申报税务减免的个人与美国有经贸往来………………………………………………………………………W-8ECI 详细资料请查阅美国国税局 W-8BEN 英文版全文说明。 表格填写简单说明： 第一部分：所得个人资料 第1 点：姓名。 第2 点：国籍。 第3 点：所得单位种类：个人请勾选 Individual; 若为共同账户请分别填写 W-8BEN。 第4 点：永久居住地址（请勿使用邮政信箱 PO Box 或转寄地址，还有国家名称请勿简写。） 第5 点：邮寄地址（如果不同于永久地址请另填写，国家名称请勿简写）。 第6 点：美国税号 SSN，ITIN 或 EIN 号码（如果您需要填写）。 第7 点：外国税号（如果有）。 第8 点：扣缴单位使用的参照号码。 第二部分：税务减免申报（若适用） 第9 点：确认以下勾选的均使用 ? 勾选 a 项：如果所得期间所得申报人居住在 （国家名称），其为美国的税务减免互惠国。 第三部分：申明 本人申明以上所填资料属实而且完整。 ? 本人（或授权人）为本表格所提及的所有所得申报人。 ? 所得个人不是美国税法规定的美国申报人（US Person)。 ? 本人的所得不属美国的贸易或商业行为。 ? 本人确实符合美国的税务减免互惠的资格。 除此之外，在此申明，预扣税款单位有权预扣我的税款。 签名栏（SIGN HERE)：所得个人或授权人签名/日期/（月日年）/授权代理。 注意： ? 在交出 W-8BEN 表格后您的身份若有变更（变成美国公民或居民），请于 30 天内主动通知预扣税款单位。 ? W-8BEN 表格的有效期为签署年起至第三年年底止。 ? W-8BEN 的中文简要说明仅为方便华人客户提供。本公司客户须以美国国税局所提供之英文原本为准。您可 到史考特证券表格中心下载 W-8BEN 英文版全文说明或到美国国税局网站 www.irs.gov 做进一步暸解

What would be a good SEO strategy?

Before you launch your site, you should have done the following: - Optimized your <title> tags on each page to contain 1 - 3 keywords - Create unique Meta Tags for each page - Used appropriate markup where necessary (<h1>, <em>, etc.) - Used keywords liberally yet appropriately throughout each page - Designed the navigational structure of the site to channel PR to main pages (especially the homepage) - Used Search Engine Friendly URLs (if necessary) - Created a complete website with plenty of quality content - Used keywords in your domain and url (http://www.keyword1.com/keyword2/keyword3.html)

Immediately after launching your site you should do the following: - Submit your site, by hand, to all major search engines - Submit your site to all free directories (dmoz, yahoo (if applicable), etc..) - Begin a link building campaign (attempting to get keywords in the reciprocal link anchor text)

Finally, as part of an ongoing strategy: - Continually update your website will quality content - Continually seek free and reciprocal links preferably from sites in your genre

* Remember, build your website for human beings; not the search engines!

From:http://www.w3.org/Provider/Style/URI -------------------------------------------------------------------------------- Cool URIs don't change What makes a cool URI? A cool URI is one which does not change. What sorts of URI change? URIs don't change: people change them. There are no reasons at all in theory for people to change URIs (or stop maintaining documents), but millions of reasons in practice. In theory, the domain name space owner owns the domain name space and therefore all URIs in it. Except insolvency, nothing prevents the domain name owner from keeping the name. And in theory the URI space under your domain name is totally under your control, so you can make it as stable as you like. Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running. Then why are there so many dangling links in the world? Part of it is just lack of forethought. Here are some reasons you hear out there:

We just reorganized our website to make it better. Do you really feel that the old URIs cannot be kept running? If so, you chose them very badly. Think of your new ones so that you will be able to keep then running after the next redesign.

We have so much material that we can't keep track of what is out of date and what is confidential and what is valid and so we thought we'd better just turn the whole lot off. That I can sympathize with - the W3C went through a period like that, when we had to carefully sift archival material for confidentiality before making the archives public. The solution is forethought - make sure you capture with every document its acceptable distribution, its creation date and ideally its expiry date. Keep this metadata.

Well, we found we had to move the files... This is one of the lamest excuses. A lot of people don't know that servers such as Apache give you a lot of control over a flexible relationship between the URI of an object and where a file which represents it actually is in a file system. Think of the URI space as an abstract space, perfectly organized. Then, make a mapping onto whatever reality you actually use to implement it. Then, tell your server. You can even write bits of your server to make it just right.

John doesn't maintain that file any more, Jane does.

Whatever was that URI doing with John's name in it? It was in his directory? I see.

We used to use a cgi script for this and now we use a binary program. There is a crazy notion that pages produced by scripts have to be located in a "cgibin" or "cgi" area. This is exposing the mechanism of how you run your server. You change the mechanism (even keeping the content the same ) and whoops - all your URIs change.

For example, take the The National Science Foundation:

NSF Online Documents http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

the main page for starting to look for documents, is clearly not going to be something to trust to being there in a few years. "cgi-bin" and "oldbrowse" and ".pl" all point to bits of how-we-do-it-now. By contrast, if you use the page to find a document, you get first an equally bad

Report of Working Group on Cryptology and Coding Theory http://www.nsf.gov/cgi-bin/getpub?nsf9814

for the document's index page, but the html document itself by contrast is very much better:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Looking at this one, the "pubs/1998" header is going to give any future archive service a good clue that the old 1998 document classification scheme is in progress. Though in 2098 the document numbers might look different, I can imagine this URI still being valid, and the NSF or whatever carries on the archive not being at all embarrassed about it.

I didn't think URLs have to be persistent - that was URNs. This is the probably one of the worst side-effects of the URN discussions. Some seem to think that because there is research about namespaces which will be more persistent, that they can be as lax about dangling links as they like as "URNs will fix all that". If you are one of these folks, then allow me to disillusion you.

Most URN schemes I have seen look something like an authority ID followed by either a date and a string you choose, or just a string you choose. This looks very like an HTTP URI. In other words, if you think your organization will be capable of creating URNs which will last, then prove it by doing it now and using them for your HTTP URIs. There is nothing about HTTP which makes your URIs unstable. It is your organization. Make a database which maps document URN to current filename, and let the web server use that to actually retrieve files.

If you have gotten to this point, then unless you have the time and money and contacts to get some software design done, then you might claim the next excuse:

We would like to, but we just don't have the right tools. Now here is one I can sympathize with. I agree entirely. What you need to do is to have the web server look up a persistent URI in an instant and return the file, wherever your current crazy file system has it stored away at the moment. You would like to be able to store the URI in the file as a check, and constantly keep the database in tune with actuality. You'd like to store the relationships between different versions and translations of the same document, and you'd like to keep an independent record of the checksum to provide a guard against file corruption by accidental error. And web servers just don't come out of the box with these features. When you want to create a new document, your editor asks you for a URI instead of telling you.

You need to be able to change things like ownership, access, archive level security level, and so on, of a document in the URI space without changing the URI.

Too bad. But we'll get there. At W3C we use Jigedit functionality (Jigsaw server used for editing) which does track versions, and we are experimenting with document creation scripts. If you make tools, servers and clients, take note!

This is an outstanding reason, which applies for example to many W3C pages including this one: so do what I say, not what I do.

Why should I care? When you change a URI on your server, you can never completely tell who will have links to the old URI. They might have made links from regular web pages. They might have bookmarked your page. They might have scrawled the URI in the margin of a letter to a friend.

When someone follows a link and it breaks, they generally lose confidence in the owner of the server. They also are frustrated - emotionally and practically from accomplishing their goal.

Enough people complain all the time about dangling links that I hope the damage is obvious. I hope it also obvious that the reputation damage is to the maintainer of the server whose document vanished.

So what should I do? Designing URIs It the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.

URIs change when there is some information in them which changes. It is critical how you design them. (What, design a URI? I have to design URIs? Yes, you have to think about it.). Designing mostly means leaving information out.

The creation date of the document - the date the URI is issued - is one thing which will not change. It is very useful for separating requests which use a new system from those which use an old system. That is one thing which us good to start a URI with. If a document is in any way dated, even though it will be if interest for generations, then the date is a good starter.

The only exception is a page which is deliberately a "latest" page for, for example, the whole organization or a large part of it.

http://www.pathfinder.com/money/moneydaily/latest/

is the latest "Money daily" column in "Money" magazine. The main reason for not needing the date in this URI is that there is no reason for the persistence of the URI to outlast the magazine. The concept of "today's Money" vanishes if Money goes out of production. If you want to link to the content, you would link to it where it appears separately in the archives as

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Looks good. Assumes that "money" will mean the same thing throughout the life of pathfinder.com. There is a duplication of "98" and an ".html" you don't need but otherwise this looks a strong URI).

What to leave out Everything! After the creation date, putting any information in the name is asking for trouble one way or another.

Authors name- authorship can change with new versions. People quit organizations and hand things on. Subject. This is tricky. It always looks good at the time but changes surprisingly fast. I discuss this more below. Status- directories like "old" and "draft" and so on, not to mention "latest" and "cool" appear all over file systems. Documents change status - or there would be no point in producing drafts. The latest version of a document needs a persistent identifier whatever its status is. Keep the status out of the name. Access. At W3C we divide the site into "Team access", "Member access" and "Public access". It sounds good, but of course documents start off as team ideas, are discussed with members, and then go public. A shame indeed if every time some document is opened to wider discussion all the old links to it fail! We are switching to a simple date code now. File name extension. This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension.(how?) Software mechanisms. Look for "cgi", "exec" and other give-away "look what software we are using" bits in URIs. Anyone want to commit to using perl cgi scripts all their lives? Nope? Cut out the .pl. Read the server manual on how to do it. Disk name - gimme a break! But I've seen it.

So a better example from our site is simply

http://www.w3.org/1998/12/01/chairs

a report of the minutes of a meeting of W3C chairpeople.

Topics and Classification by subject I'll go into this danger in more detail as it is one of the more difficult things to avoid. Typically, topics end up in URIs when you classify your documents according to a breakdown of the work you are doing. That breakdown will change. Names for areas will change. At W3C we wanted to change "MarkUp" to "Markup" and then to "HTML" to reflect the actual content of the section. Also, beware that this is often a flat name space. In 100 years are you sure you won't want to reuse anything? We wanted to reuse "History" and "Stylesheets" for example in our short life.

This is a tempting way of organizing a web site - and indeed a tempting way of organizing anything, including the whole web. It is a great medium term solution but has serious drawbacks in the long term

Part of the reasons for this lie in the philosophy of meaning. every term in the language it a potential clustering subject, and each person can have a different idea of what it means. Because the relationships between subjects are web-like rather than tree-like, even for people who agree on a web may pick a different tree representation. These are my (oft repeated) general comments on the dangers of hierarchical classification as a general solution.

Effectively, when you use a topic name in a URI you are binding yourself to some classification. You may in the future prefer a different one. Then, the URI will be liable to break.

A reason for using a topic area as part of the URI is that responsibility for sub-parts of a URI space is typically delegated, and then you need a name for the organizational body - the subdivision or group or whatever - which has responsibility for that sub-space. This is binding your URIs to the organizational structure. It is typically safe only when protected by a date further up the URI (to the left of it): 1998/pics can be taken to mean for your server "what we meant in 1998 by pics", rather than "what in 1998 we did with what we now refer to as pics."

Don't forget the domain name. Remember that this applies not only to the "path" part of a URI but to the server name. If you have separate servers for some of your stuff, remember that that division will be impossible to change without destroying many many links. Some classic "look what software we are using today" domain names are "cgi.pathfinder.com", "secure", "lists.w3.org". They are made to make administration of the servers easier. Whether it represents divisions in your company, or document status, or access level, or security level, be very, very careful before using more than one domain name for more than one type of document. remember that you can hide many web servers inside one apparent web server using redirection and proxying.

Oh, and do think about your domain name. If your name is not soap, will you want to be referred to as "soap.com" even when you have switched your product line to something else. (With apologies to whoever owns soap.com at the moment).

Conclusion Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

See also:

Jacob Nielsen's "Alertbox" rant on the same topic

-------------------------------------------------------------------------------- (back to Etiquette for server administrators, on to Structure of your work) Footnote How can I remove the file extensions... ...from my URIs in a practical file-based web server?

If you are using, for example, Apache, you can set it up to do content negotiation. You keep the file extension (such as .png) on the file (eg mydog.png), but refer to the web resource without it. Apache then checks the directory for all files with that name and any extension, and it can also pick the best one out of a set (e.g. GIF and PNG). (You do not have to put different types of file in different directories, in fact the content negotiation won't work if you do.)

Set up your server to do content negotiation Make references always to the URI without the extension References which do have the extension on will still work but will not allow your server to select the best of currently available and future formats.

(In fact, mydog, mydog.png and mydog.gif are each valid web resources. mydog is content-type-generic. mydog.png and mydog.gif are content-type-specific.)

Of course, if you are building your own server, then using a database to relate persistent identifiers to their current form is a very clean idea -- though beware the unbounded growth of your database.

Hall of flame -- story 1: Channel 7 During 1999, http://www.whdh.com/stormforce/closings.shtml was a page I found documenting school closings due to snow. An alternative to waiting for them to scroll past the bottom of the TV screen! I put a pointer to it from my home page. Come the firt big storm 2000, and I check the page. It says,

"Closings as of . There are currently no closings in effect. Please check back when the weather warrants"

Can't be such a big storm. Funny the date is missing. But then if I go to the home page of the site, there is a big button "school closings" which takes me to http://www.whdh.com/stormforce/ which has a list of many closed schools.

Well, maybe they changed the system which got the closings from the definitive list - but they did not need to change the URI.

Hall of flame -- story 2: Microsoft Netmeeting One of the smarts which came with a growing dependency on the web was that applications could have built-in links back to the manufacturer's web site. This has been used and abused to a great extent, but - you do have to keep the URL the same. Just the other day I tried a link from Microsoft's Netmeeting 2/something client under a menu "Help/Microsoft on the Web/Free stuff" and got an Error 404 - not found response from the server. They have probably fixed it by now...

(c)1998 Tim BL Historical note: At the end of the 20th century when this was written, "cool" was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness. In the rush to stake our DNS territory involved the choice of domain name and URI path were sometimes directed more toward apparent "coolness" than toward usefulness or longevity. This note is an attempt to redirect the energy behind the quest for coolness.

SSI有什么用? 之所以要扯到ssi，是因爲shtml--server-parsed HTML 的首字母缩略词。包含有嵌入式服务器方包含命令的 HTML 文本。在被传送给浏览器之前，服务器会对 SHTML 文档进行完全地读取、分析以及修改。 shtml和asp 有一些相似，以shtml命名的文件里，使用了ssi的一些指令，就像asp中的指令，你可以在SHTML文件中写入SSI指令，当客户端访问这些shtml文件时， 服务器端会把这些SHTML文件进行读取和解释，把SHTML文件中包含的SSI指令解释出来比如：你可以在SHTML文件中用SSI指令引用其他的html文件（#include ），服务器传送给客户端的文件，是已经解释的SHTML不会有SSI指令。它实现了HTML所没有的功能，就是可以实现了动态 的SHTML，可以说是HTML的一种进化吧。像新浪的新闻系统就是这样的，新闻内容是固定的但它上面的广告和菜单等就是用#include引用进来的。

　　目前，主要有以下几种用用途： 　　1、显示服务器端环境变量<#echo> 　　2、将文本内容直接插入到文档中<#include> 　　3、显示WEB文档相关信息<#flastmod #fsize> (如文件制作日期/大小等) 　　4、直接执行服务器上的各种程序<#exec>(如CGI或其他可执行程序) 　　5、设置SSI信息显示格式<#config>(如文件制作日期/大小显示方式) 　　高级SSI<XSSI>可设置变量使用if条件语句。 　 使用SSI 　　SSI是为WEB服务器提供的一套命令，这些命令只要直接嵌入到HTML文档的注释内容之中即可。如： 　　<!--#include file="info.htm"--> 　　就是一条SSI指令，其作用是将"info.htm"的内容拷贝到当前的页面中，当访问者来浏览时，会看到其它HTML文档一样显示info.htm其中的内容。 　　其它的SSI指令使用形式基本同刚才的举例差不多，可见SSI使用只是插入一点代码而已，使用形式非常简单。 　　当然，如果WEB服务器不支持SSI，它就会只不过将它当作注释信息，直接跳过其中的内容；浏览器也会忽略这些信息。 　 如何在我的WEB服务器上配置SSI功能？ 　　在一些WEB服务器上（如IIS 4.0/SAMBAR 4.2），包含 #include 指令的文件必须使用已被映射到 SSI 解释程序的扩展名；否则，Web 服务器将不会处理该SSI指令；默认情况下，扩展名 .stm、.shtm 和 .shtml 被映射到解释程序（Ssinc.dll）。 　　Apache则是根据你的设置情况而定，修改srm.conf如： 　　AddType text/x-server-parsed-html .shtml 将只对.shtml扩展名的文件解析SSI指令 　　AddType text/x-server-parsed-html .html将对所有HTML文档解析SSI指令 　　Netscape WEB服务器直接使用Administration Server(管理服务器)可打开SSI功能。 　　Website使用Server Admin程序中的Mapping标签，扩展名添加内容类型为：wwwserver/html-ssi 　　Cern服务器不支持SSI，可用SSI诈骗法，到http://sw.cse.bris.ac.uk/WebTools/fakessi.html 上下载一个PERL脚本，即可使你的CERN服务器使用一些SSI指令。（不支持exec指令。） 　 SSI指令基本格式 SSI指令基本格式： 程序代码:

<!-– 指令名称="指令参数"> <!-– 指令名称="指令参数"> 如 程序代码:

<!--#include file="info.htm"--> <!--#include file="info.htm"--> 说明: 1．<!-- -->是HTML语法中表示注释，当WEB服务器不支持SSI时，会忽略这些信息。 2．#include 为SSI指令之一。 3．file 为include的参数, info.htm为参数值，在本指令中指将要包含的文档名。

注意:

1．<!--与#号间无空格，只有SSI指令与参数间存在空格。 2．上面的标点=""，一个也不能少。 3．SSI指令是大小写敏感的，因此参数必须是小写才会起作用。 　 SSI指令使用详解

#echo 示范 作用： 将环境变量插入到页面中。 语法： 程序代码:

<!--#echo var="变量名称"--> <!--#echo var="变量名称"-->

本文档名称：程序代码:

<!--#echo var="DOCUMENT_NAME"--> <!--#echo var="DOCUMENT_NAME"--> 现在时间：程序代码:

<!--#echo var="DATE_LOCAL"--> <!--#echo var="DATE_LOCAL"--> 你的IP地址是程序代码:

<!--#echo var="REMOTE_ADDR"--> <!--#echo var="REMOTE_ADDR"-->

#include 示范 作用： 将文本文件的内容直接插入到文档页面中。 语法： 程序代码:

<!--#include file="文件名称"--> <!--#include virtual="文件名称"--> <!--#include file="文件名称"--> <!--#include virtual="文件名称"--> file 文件名是一个相对路径，该路径相对于使用 #include 指令的文档所在的目录。被包含文件可以在同一级目录或其子目录中，但不能在上一级目录中。如表示当前目录下的的nav_head.htm文档，则为file="nav_head.htm"。 virtual 文件名是 Web 站点上的虚拟目录的完整路径。如表示相对于服务器文档根目录下hoyi目录下的nav_head.htm文件；则为file="/hoyi/nav_head.htm" 参数： file 指定包含文件相对于本文档的位置 virtual 指定相对于服务器文档根目录的位置 注意： 1、文件名称必须带有扩展名。 2、被包含的文件可以具有任何文件扩展名，我觉得直接使用htm扩展名最方便，微软公司推荐使用 .inc 扩展名（这就看你的爱好了）。 示例： 程序代码:

<!--#include file="nav_head.htm"-->将头文件插入到当前页面 <!--#include file="nav_foot.htm"-->将尾文件插入到当前页面 <!--#include file="nav_head.htm"-->将头文件插入到当前页面 <!--#include file="nav_foot.htm"-->将尾文件插入到当前页面

#flastmod 和#fsize 示范 作用： #flastmod 文件最近更新日期 #fsize 文件的长度 语法： 程序代码:

<!--#flastmod file="文件名称"--> <!--#fsize file="文件名称"--> <!--#flastmod file="文件名称"--> <!--#fsize file="文件名称"--> 参数： file 指定包含文件相对于本文档的位置 如 info.txt 表示当前目录下的的info.txt文档 virtual 指定相对于服务器文档根目录的位置 如 /hoyi/info.txt 表示 注意： 文件名称必须带有扩展名。 示例： 程序代码:

<!--#flastmod file="news.htm"--> <!--#flastmod file="news.htm"--> 将当前目录下news.htm文件的最近更新日期插插入到当前页面 程序代码:

<!--#fsize file="news.htm"--> <!--#fsize file="news.htm"--> 将当前目录下news.htm的文件大小入到当前页面 　 #exec 示范 作用： 将某一外部程序的输出插入到页面中。可插入CGI程序或者是常规应用程序的输入，这取决于使用的参数是cmd还是cgi。 语法： 程序代码:

<!--#exec cmd="文件名称"--> <!--#exec cgi="文件名称"--> <!--#exec cmd="文件名称"--> <!--#exec cgi="文件名称"--> 参数： cmd 常规应用程序 cgi CGI脚本程序 示例： 程序代码:

<!--#exec cmd="cat /etc/passwd"-->将会显示密码文件 <!--#exec cmd="dir /b"-->将会显示当前目录下文件列表 <!--#exec cgi="/cgi-bin/gb.cgi"-->将会执行CGI程序gb.cgi。 <!--#exec cgi="/cgi-bin/access_log.cgi"-->将会执行CGI程序access_log.cgi。 <!--#exec cmd="cat /etc/passwd"-->将会显示密码文件 <!--#exec cmd="dir /b"-->将会显示当前目录下文件列表 <!--#exec cgi="/cgi-bin/gb.cgi"-->将会执行CGI程序gb.cgi。 <!--#exec cgi="/cgi-bin/access_log.cgi"-->将会执行CGI程序access_log.cgi。 注意： 从上面的示例可以看出，这个指令相当方便，但是也存在安全问题。 禁止方法： ．Apache，将access.conf中的"Options Includes ExecCGI"这行代码删除； ．在IIS中，要禁用 #exec 命令，可修改 SSIExecDisable 元数据库；

#config 作用： 指定返回给客户端浏览器的错误信息、日期和文件大小的格式。 语法： 程序代码:

<!--#config errmsg="自定义错误信息"--> <!--#config sizefmt="显示单位"--> <!--#config timefmt="显示格式"--> <!--#config errmsg="自定义错误信息"--> <!--#config sizefmt="显示单位"--> <!--#config timefmt="显示格式"--> 参数： errmsg 自定义SSI执行错误信息，可以为任何你喜欢的方式。 sizefmt 文件大小显示方式，默认为字节方式("bytes")可以改为千字节方式("abbrev") timefmt 时间显示方式，最灵活的配置属性。 示例： 显示一个不存在文件的大小 程序代码:

<!--#config errmsg="服务器执行错误，请联系管理员，谢谢！"--> <!--#fsize file="不存在的文件.htm"--> <!--#config errmsg="服务器执行错误，请联系管理员，谢谢！"--> <!--#fsize file="不存在的文件.htm"--> 以千字节方式显示文件大小 程序代码:

<!--#config sizefmt="abbrev"--> <!--#fsizefile="news.htm"--> <!--#config sizefmt="abbrev"--> <!--#fsizefile="news.htm"--> 以特定的时间格式显示时间 程序代码:

<!--#config timefmt="%Y年/%m月%d日 星期%W 北京时间%H:%M:%s，%Y年已过去了%j天 今天是%Y年的第%U个星期"--> <!--#echo var="DATE_LOCAL"--> 显示今天是星期几,几月,时区 <!--#config timefmt="今天%A, %B ,服务器时区是 %z，是"--> <!--#echo var="DATE_LOCAL"--> <!--#config timefmt="%Y年/%m月%d日 星期%W 北京时间%H:%M:%s，%Y年已过去了%j天 今天是%Y年的第%U个星期"--> <!--#echo var="DATE_LOCAL"--> 显示今天是星期几,几月,时区 <!--#config timefmt="今天%A, %B ,服务器时区是 %z，是"--> <!--#echo var="DATE_LOCAL"-->

XSSI XSSI（Extended SSI）是一组高级SSI指令，内置于Apache 1.2或更高版本的mod-include模块之中。 其中可利用的的指令有： #printenv #set #if #printenv 作用： 显示当前存在于WEB服务器环境中的所有环境变量。 语法：程序代码:

<!--#printenv--> <!--#printenv--> 参数：无 示例： 程序代码:

<!--#printenv--> <!--#printenv-->

#set 作用：可给变量赋值，以用于后面的if语句。 语法：程序代码:

<!--#set var="变量名"value="变量值"--> <!--#set var="变量名"value="变量值"--> 参数：无 示例： 程序代码:

<!--#set var="color"value="红色"--> <!--#set var="color"value="红色"-->

#if 作用： 创建可以改变数据的页面，这些数据根据使用if语句时计算的要求予以显示。 语法： 程序代码:

<!--#if expr="$变量名=\"变量值A\""--> 显示内容 <!--#elif expr="$变量名=\"变量值B\""--> 显示内容 <!--#else--> 显示内容 <!--#endif"--> <!--#if expr="$变量名=\"变量值A\""--> 显示内容 <!--#elif expr="$变量名=\"变量值B\""--> 显示内容 <!--#else--> 显示内容 <!--#endif"--> 示例： 程序代码:

<!--#if expr="$SERVER_NAME=\"www.e3i5.com\""--> 欢迎光临E代时光。 <!--#elif expr="$SERVER_NAME=\"bbs.e3i5.com\"" --> 欢迎光临E代时光论坛。 <!--#else--> 欢迎光临E代时光。 <!--#endif"--> <!--#if expr="$SERVER_NAME=\"www.e3i5.com\""--> 欢迎光临E代时光。 <!--#elif expr="$SERVER_NAME=\"bbs.e3i5.com\"" --> 欢迎光临E代时光论坛。 <!--#else--> 欢迎光临E代时光。 <!--#endif"--> 注意： 用于前面指令中的反斜杠，是用来代换内部的引号，以便它们不会被解释为结束表达式。不可省略。

1、Config命令

　　Config命令主要用于修改SSI的默认设置。其中：

　　Errmsg：设置默认错误信息。为了能够正常的返回用户设定的错误信息，在HTML文件中Errmsg参数必须被放置在其它SSI命令的前面，否则客户端只能显示默认的错误信息，而不是由用户设定的自定义信息。

　　　　<!--#config errmsg="Error! Please email webmaster@mydomain.com -->

　　Timefmt：定义日期和时间的使用格式。Timefmt参数必须在echo命令之前使用。

　　　　<!--#config timefmt="%A, %B %d, %Y"--> 　　　　<!--#echo var="LAST_MODIFIED" -->

　　显示结果为：

　　　　Wednesday, April 12, 2000

　　也许用户对上例中所使用的%A %B %d感到很陌生，下面我们就以表格的形式总结一下SSI中较为常用的一些日期和时间格式。

　　Sizefmt：决定文件大小是以字节、千字节还是兆字节为单位表示。如果以字节为单位，参数值为"bytes"；对于千字节和兆字节可以使用缩写形式。同样，sizefmt参数必须放在fsize命令的前面才能使用。

　　　　<!--#config sizefmt="bytes" --> 　　　　<!--#fsize file="index.html" -->

　　2、Include命令

　　Include命令可以把其它文档中的文字或图片插入到当前被解析的文档中，这是整个SSI的关键所在。通过Include命令只需要改动一个文件就可以瞬间更新整个站点！

　　Include命令具有两个不同的参数：

　　Virtual：给出到服务器端某个文档的虚拟路径。例如：

　　　　<!--#include virtual="/includes/header.html" -->

　　File：给出到当前目录的相对路径，其中不能使用"../"，也不能使用绝对路径。例如：

　　　　<!--#include file="header.html" -->

　　这就要求每一个目录中都包含一个header.html文件。

　　3、Echo命令

　　Echo命令可以显示以下各环境变量：

　　DOCUMENT_NAME：显示当前文档的名称。

　　　　<!--#echo var="DOCUMENT_NAME" -->

显示结果为：

　　　　index.html

　　DOCUMENT_URI：显示当前文档的虚拟路径。例如：

　　　　<!--#echo var="DOCUMENT_URI" -->

　　显示结果为：

　　　　/YourDirectory/YourFilename.html

　　随着网站的不断发展，那些越来越长的URL地址肯定会让人头疼。如果使用SSI，一切就会迎刃而解。因为我们可以把网站的域名和SSI命令结合在一起显示完整的URL，即：

　　http://YourDomain<!--#echo var="DOCUMENT_URI" -->

　　QUERY_STRING_UNESCAPED：显示未经转义处理的由客户端发送的查询字串，其中所有的特殊字符前面都有转义符"\"。例如：

　　<!--#echo var="QUERY_STRING_UNESCAPED" -->

　　DATE_LOCAL：显示服务器设定时区的日期和时间。用户可以结合config命令的timefmt参数，定制输出信息。例如：

　　<!--#config timefmt="%A, the %d of %B, in the year %Y" --> 　<!--#echo var="DATE_LOCAL" -->

　　显示结果为：

　　Saturday, the 15 of April, in the year 2000

　　DATE_GMT：功能与DATE_LOCAL一样，只不过返回的是以格林尼治标准时间为基准的日期。例如：

　　<!--#echo var="DATE_GMT" -->

　　LAST_MODIFIED：显示当前文档的最后更新时间。同样，这是SSI中非常实用的一个功能，只要在HTML文档中加入以下这行简单的文字，就可以在页面上动态的显示更新时间。

　　<!--#echo var="LAST_MODIFIED" -->

　　CGI环境变量

　　除了SSI环境变量之外，echo命令还可以显示以下CGI环境变量：

　　　　SERVER_SOFTWARE：显示服务器软件的名称和版本。例如： 　　　　<!--#echo var="SERVER_SOFTWARE" --> 　　　　SERVER_NAME： 显示服务器的主机名称，DNS别名或IP地址。例如： 　　　　<!--#echo var="SERVER_NAME" --> 　　　　SERVER_PROTOCOL：显示客户端请求所使用的协议名称和版本，如HTTP/1.0。例如： 　　　　<!--#echo var="SERVER_PROTOCOL" --> 　　　　SERVER_PORT：显示服务器的响应端口。例如： 　　　　<!--#echo var="SERVER_PORT" --> 　　　　REQUEST_METHOD：显示客户端的文档请求方法，包括GET, HEAD, 和POST。例如： 　　　　<!--#echo var="REQUEST_METHOD" --> 　　　　REMOTE_HOST：显示发出请求信息的客户端主机名称。 　　　　<!--#echo var="REMOTE_HOST" --> 　　　　REMOTE_ADDR：显示发出请求信息的客户端IP地址。 　　　　<!--#echo var="REMOTE_ADDR" --> 　　　　AUTH_TYPE：显示用户身份的验证方法。 　　　　<!--#echo var="AUTH_TYPE" --> 　　　　REMOTE_USER：显示访问受保护页面的用户所使用的帐号名称。 　　　　<!--#echo var="REMOTE_USER" --> 4、Fsize：显示指定文件的大小，可以结合config命令的sizefmt参数定制输出格式。

　　　　<!--#fsize file="index_working.html" -->

　　5、Flastmod：显示指定文件的最后修改日期，可以结合config 命令的timefmt参数控制输出格式。

　　　　<!--#config timefmt="%A, the %d of %B, in the year %Y" --> 　　　　<!--#flastmod file="file.html" -->

　　这里，我们可以利用flastmod参数显示出一个页面上所有链接页面的更新日期。方法如下：

　　　　<!--#config timefmt=" %B %d, %Y" --> 　　　　<A HREF="/directory/file.html">File</A> 　　　　<!--#flastmod virtual="/directory/file.html" --> 　　　　<A HREF="/another_directory/another_file.html">Another File</A> 　　　　<!--#flastmod virtual="/another_directory/another_file.html" --> 　　显示结果为： 　　　　File April 19, 2000 　　　　Another File January 08, 2000

　　6、Exec

　　Exec命令可以执行CGI脚本或者shell命令。使用方法如下：

　　　Cmd：使用/bin/sh执行指定的字串。如果SSI使用了IncludesNOEXEC选项，则该命令将被屏蔽。

　　　Cgi：可以用来执行CGI脚本。例如，下面这个例子中使用服务端cgi-bin目录下的counter.pl脚本程序在每个页面放置一个计数器：

　　　<!--#exec cgi="/cgi-bin/counter.pl" -->

现在觉得，人性最可悲的事情就是，总以自己的想法去想别人对你看法，从而导致了过分的自信和自卑，影响了自己的心态。