Linux 之父 Linus Torvalds 的十大名言，你聽說過幾句？
01. Software is like sex: it's better when it's free.
軟件就像性，免費的比花錢的好得多。
02. Microsoft isn't evil, they just make really crappy operating systems.
微軟并不是魔鬼，只是它的操作系統實在太蹩腳了。
03. My name is Linus, and I am your God.
我是 Linus，我是神。Hia Hia Hia。
04. See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too.
要想能夠創造 Linux 這樣得操作系統不只是需要良好得程序員，還得需要一批心理陰暗的混蛋。
05. The Linux philosophy is "Laugh in the face of danger". Oops. Wrong One. "Do it yourself". Yes, that's it.
Linux 的哲學就是“在危險面前放聲大笑”，呵呵，不是這句，應該是“一切靠自己，自力更生”才對。
06. Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen a angry penguin charging at them in excess of 100 mph.
很多朋友和我說那只耪企鵝不配代表 Linux 操作系統，因為他們從來沒見過一只憤怒的企鵝以 100 邁的速度向他們發起攻擊。
07. Intelligence is the ability to avoid doing work, yet getting the work done.
天賦就是事半功倍。
08. When you say, "I wrote a program that crashed Windows", people just stare at you blankly and say, "Hey, I got those with the system, for free".
你驕傲的和別人說“嘿，我寫了個能讓 Windows 崩潰的程序”，他們會說“哥們，我裝 Windows 系統的時候就免費帶著了”。
09. I don't doubt at all that virtualization is useful in some areas. What I doubt rather strongly is that it will ever have the kind of impact that the people involved in virtualization want it to have.
我對虛擬化的技術使用沒有任何懷疑，我懷疑的是他們對人的影響。
10. Now, most of you are probably going to be totally bored out of your minds on Christmas day, and here's the perfect distraction. Test 2.6.15-rc7. All the stores will be closed, and there's really nothing better to do in between meals.
大家在圣誕期間可能會非常無聊，現在有好辦法了，試試內核 2.6.15-rc7 版吧，茶余飯后的好消遣哦。
]]>
局部變量：在過程的內部聲明而具有局部作用域，過程外部任何命令都不能訪問，每次執行過程創建的變量均隨此過程的結束而銷毀。
全局變量：在過程的外部聲明而具有全局作用域，其值能被 ASP 頁面上的任何腳本命令訪問和修改，全部變量隨腳本運行的結束而消亡。
]]>
將參數傳遞給過程有兩種方式：傳址方式和傳值方式。
傳址方式：是指將變量在內存中的地址傳遞給過程，過程可直接修改此變量；當執行返回到調用過程時，變量為修改后的值。
傳值方式：是指將變量的副本值傳遞給過程，過程修改這個副本值，但變量的初始值保持不變；當執行返回到調用過程時，變量仍為傳遞之前的值。
注意：必須以傳址方式傳遞數組，如果試圖以傳值方式傳遞，則會出現語法錯誤。
ByRef 關鍵字：指示參數以傳址方式傳遞，被調用過程或屬性可以更改代碼中參數的基礎變量的值。
ByVal 關鍵字：指示參數以傳值方式傳遞，被調用的過程或屬性不能更改代碼中參數的基礎變量的值。
]]>
表單的 Method 屬性指定傳輸信息的格式，其中有兩種取值 Get（默認值）和 Post，分別指定兩種不同的傳輸方式。
兩者的區別如下：
1. 使用 Get 方式時，瀏覽器將傳遞的值綁定在頁面所有控件上，成為一個查詢字符串，且附在被請求頁面的 URL 上，當這個請求到達 Web 服務器時，其值由 ASP 的 Request.QueryString 集合收集并提供。而使用 Post 方式時，瀏覽器將值包裝進發送服務器的 HTTP 報頭中，通過 Request.Form 集合收集并提供。
2. 使用 Post 方式時，當用戶重新下載表單時，窗體的值將不再保留，其值為空且必須重新輸入。而 Get 方式傳遞的值被存儲為一個鏈接，將被保留。
3. 使用 Get 方式時，瀏覽器或服務器的 URL 字符串長度存在一定的限制，附有長的字符串可能會引起溢出和字符串的某些字符被截掉，同時查詢字符串出現在瀏覽器的地址欄中，暴露了 HTTP 請求中通過 Web 傳遞的一些重要數據。而 Post 無上述缺陷。
4. 使用 Get 方式時，URL 與查詢字符串的結合體不能包含任何空格或其他特殊字符（如 [/][:][?][&] 等），否則 HTTP 請求將出現問題。這些特殊字符是用來分隔 URL 和查詢字符串的部分，雖然 IE 能夠自動正確地將這些特殊字符轉換為加號（+），但其他特殊字符就不能處理了，導致的后果可能會到不了要請求的頁面。此時，必須通過 ASP 服務器對象提供的 URLEncode 方法進行變換處理。而 Post 方式則不存在此類問題。
]]>
將程序按功能分割成若干較小的邏輯部件，這些部件稱為過程。
過程常用于重復或共享的任務，能有效降低程序編寫的復雜性，提高程序執行的效率。
VBScript 的子程序和函數統稱為過程，子程序叫 Sub 過程，函數叫 Function 過程。
兩者區別：
1. Sub 過程由 Sub 語句開始，End Sub 語句結束；Function 過程由 Function 語句開始，End Function 語句結束。
2. Sub 過程執行操作，但是不返回任何值；Function 過程通過過程中的一個或多個語句給過程名賦值，向調用程序返回值。
3. 調用 Sub 過程時，只需輸入過程名或相關參數，也可以使用 Call 語句調用；而調用 Function 過程時，必須將其名稱和參數放在賦值語句的右邊或表達式中。
]]>
Null 與 Empty 不同，Null 值指出變量不包含有效數據，Empty 指出變量未經初始化。
Null 與零長度字符串（""）也不同，零長度字符串往往指的是空串。
IsEmpty(expression)：
該函數返回 Boolean 值指明變量是否已被初始化。
參數 expression 可以是任意表達式，然而由于 IsEmpty() 函數用于判斷一個變量是否已被初始化，故 expression 參數常是一個變量名。
如果變量未初始化或顯式地設為 Empty，則 IsEmpty() 函數返回 True，否則返回 False。
如果 expression 參數包含一個以上的變量，該函數總返回 False。
典型示例：
Dim MyVar,MyCheck
MyCheck=IsEmpty(MyVar) '返回 True
MyVar=Null '賦為 Null
MyCheck=IsEmpty(MyVar) '返回 False
MyVar=Empty '賦為 Empty
MyCheck=IsEmpty(MyVar) '返回 True
MyCheck=IsEmpty(MyVar) '返回 True
MyVar=Null '賦為 Null
MyCheck=IsEmpty(MyVar) '返回 False
MyVar=Empty '賦為 Empty
MyCheck=IsEmpty(MyVar) '返回 True
IsNull(expression)：
該函數返回 Boolean 值，指明 expression 是否包含任何有效數據（Null）。
參數 expression 可以是任意表達式。
如果 expression 為 Null，則 IsNull() 函數返回 True，即表達式不包含任何有效數據，否則返回 False。
如果表達式由多個變量組成，則任何組成變量中的 Null 都會使整個表達式返回 Null。
使用 IsNull() 函數可以判斷表達式是否包含 Null 值。任何包含 Null 的表達式本身就為 Null。
典型示例：
Dim MyVar,MyCheck
MyCheck=IsNull(MyVar) '返回 False
MyVar=Null '賦為 Null
MyCheck=IsNull(MyVar) '返回 True
MyVar=Empty '賦為 Empty
MyCheck=IsNull(MyVar) '返回 False
MyCheck=IsNull(MyVar) '返回 False
MyVar=Null '賦為 Null
MyCheck=IsNull(MyVar) '返回 True
MyVar=Empty '賦為 Empty
MyCheck=IsNull(MyVar) '返回 False
]]>
在 ASP 中常用的把表單數據插入到數據庫中的方法有兩種，一是 ADO 的 AddNew 方法，一是直接使用 SQL 的 Insert Into 語句。
ADO 的 AddNew 方法是將 Insert Into 語句封裝了起來，所以，當對大量數據進行操作時，直接使用 SQL 語句將會大大加快存取數據的速度，因為它減少了 ADO 的“翻譯”時間。
1. 直接使用 SQL 的 Insert Into 語句
直接使用 SQL 語句的優點是速度快、占用的資源少，但缺點是不能傳遞太長的字段內容，而且在字段比較多的情況下不容易檢查錯誤。
值得注意的是，字符串字段值中不能喊有單引號（'），否則會出錯，解決方法是替換單引號（'）為雙引號（"）。
此外，當字段較多時還需要注意前面列表中的字段名和 values 后面的值的順序要一一對應，如果該值為空，可以不填寫，但表示分隔的逗號（,）不能省略。
而且當加入的字段為字符串字段時，必須要在添加內容的前后加上單引號（'）。
另外，在表名的前后打上方括號可以避免與系統表發生沖突，也是保證代碼兼容性的一個良好習慣。
2. 使用 ADO 的 AddNew 方法
使用 ADO 的 AddNew 方法編寫代碼比使用 SQL 的 Insert Into 語句編寫代碼更容易閱讀，而且查找錯誤也要簡單一些。
]]>
ASP 提供了 ADO 內置的 3 個主要對象 RecordSet、Connection 和 Command 對 Web 數據庫進行操作。
其中，Connection 的主要功能是建立與 Web 數據庫的連接；Command 的主要功能是向 Web 數據庫傳送數據查詢的請求；RecordSet 的主要功能是建立數據查詢的結果集。
由于 ADO 幾乎就是為 Web 數據庫應用量身定做的，所以其中的 Command 對象在數據查詢方面具有強大的功能。
它不僅能夠將一般的 SQL 指令送往 Web 數據庫服務器，還能夠傳送帶有參數的 SQL 指令，更重要的是還可以傳送存儲過程，因而能夠開發出更具效率的數據庫網頁。
RecordSet 對象會要求數據庫傳送所有的數據，那么數據量很大的時候就會造成網絡的阻塞和數據庫服務器的負荷過重，因此整體的執行效率就會降低。
利用 Command 對象直接調用 SQL 語句，所執行的操作是在數據庫服務器中進行的，顯然會有很高的執行效率。
特別是在服務器端執行創建完成的存儲過程，可以降低網絡流量，另外，由于事先進行了語法分析，可以提高整體的執行效率。
RecordSet 對象能夠比較好地去理解，但 Command 對象的性能更優越一些，特別是在批量加入數據的情況下。
]]>
ASP 的特點：
01. 無需編譯
ASP 程序直接由 Web 服務器的動態庫 asp.dll 解釋執行，無需編譯和連接。
02. 易于編寫和維護
ASP 源文件為純文本文件，使用常用的文本編輯工具就可以編寫 ASP 程序；同時 ASP 腳本集成于 HTML，編寫和維護均比較方便。
03. 獨立于瀏覽器
由于 ASP 程序在服務器端解釋執行，因此客戶端用戶只需使用系統自帶的瀏覽器，即可瀏覽采用 ASP 設計的網頁。
04. 面向對象
在 ASP 腳本中可以方便地引用系統組件和 ASP 的內置組件，還能定制其他功能強大的 ActiveX 服務器組件。
05. 數據庫操縱功能強大
ASP 提供 ADO 對象，利用其可以創建交互性很強的頁面，實現對后臺數據庫的各項數據操作功能，從而方便用戶控制和管理數據。
06. 執行效率高
ASP 提供最優化的多線程環境，可在一個進程中創建多個線程以同時為多個瀏覽者提供服務，既節約服務器的資源，又提高了程序的執行效率。
07. 語言兼容性強
ASP 能與任何 ActiveX Script 語言相容。除了可使用 VBScript 或 JavaScript 語言以外，還通過插件的方式，使用由第三方所提供的其他腳本語言，如 Perl、Tcl 等。
08. 可擴展性好
ASP 具有很強的擴展性，開發人員可以根據需要使用 Visual Basic 或 Visual C 等多種語言制作組件供 ASP 程序調用。
09. 安全性高
ASP 程序在服務器端執行，客戶端瀏覽器看到的只是 HTML 文件，因此可以避免源程序被泄露。
ASP 工作原理：
01. 用戶在客戶端瀏覽器地址欄中鍵入 ASP 文件名，按下“Enter”鍵觸發 ASP 請求。
02. 瀏覽器將 ASP 請求通過網絡發送給 Web 服務器。
03. Web 服務器接受該請求，并獲取正確的 ASP 文件。
04. Web 服務器將該文件發送給特定的 asp.dll 程序。
05. 程序逐行解析 ASP 文件，將各個代碼段發送到合適的腳本引擎進行編譯并運行，然后將結果寫入 HTML 流，生成靜態 HTML 文件。
06. Web 服務器將 HTML 文件發送給客戶端。
07. 客戶端瀏覽器解釋執行收到的文件，并將其顯示在瀏覽器上。
ASP 開發原則：
01. 采用標準方法：命名約定、目錄結構標準化。
02. 為客戶機/服務器模式而設計。
03. 封裝業務邏輯。
04. 提高資源的利用效率。
05. 使用數據庫維護復雜的狀態。
06. 使用 Server.CreateObject 創建對象。
07. 提供豐富的疑難解答信息：使用錯誤日志保存信息。
08. 測試性能，可伸縮性和可靠性：使用 Web Application Stress Tool 等負載工具進行壓力測試。
09. 增加隔離性。
10. 不要濫用線程公用組。
ASP 技術介紹：
01. ASP 是一個 Web 服務器端開發環境，利用它可以產生和執行動態的、互動的、高性能的 Web 服務應用程序。
02. ASP 可以通過 Microsoft Windows 的 COM/DCOM 獲得 ActiveX 規模支持，通過 DCOM 和 Transcation Server 獲得結構支持。
03. ASP 既不是程序語言，又不是開發工具，而是一種技術框架。
ASP 的功能：
01. 看處理用戶通過瀏覽器提交到 Web 服務器的表單輸入，完成用戶和服務器端的交互過程。
02. 訪問服務器端數據庫，執行相應的錄入、查詢、刪除和修改等操作。
03. 根據服務器的配置讀寫 Web 服務器端的文件。
04. 控制和管理用戶的訪問權限，限制用戶在網站的行為。
05. 記錄訪問者的信息，跟蹤用戶在網站上的活動并將其存入日志文件。
06. 結構 HTML 控件，實現各種形式的網際導航。
ASP 的應用：
01. 建立動態網站。
02. 構筑聊天室、論壇、江湖、虛擬社區等網絡應用程序。
03. 創建站內搜索程序以及網絡搜索引擎。
04. 開發管理系統、辦公系統等信息系統軟件。
05. 開發電子商務。
06. 實現網絡遠程教學。
]]>
Pascal 標記法：
變量名的全部單詞首字母大寫，英文縮寫全部為大寫。
匈牙利類型標記法：
在以 Pascal 標記法命名的變量前附加一個小寫字母（或小寫字母序列），說明該變量的類型。
自定義綜合命名法：
字符：cr
整型：i
長整型：l
單精度型：f
雙精度型：d
字符串型：s
布爾型：b
日期時間：t
數組：a
函數：fn
過程：p
對象：o
集合：c
類：cl
變型（可變化為任意類型）：v
]]>
問題原因：
IIS 早期版本包含通配符 MIME 映射，允許 IIS 處理任何文件而無需考慮擴展名。
IIS 6.0 不包含該通配符 MIME 映射，不能處理在 IIS 元數據庫中的 MimeMap 節點以外定義的任何類型的擴展名。
解決方案：
警告：如果不正確地編輯元數據庫，可能會導致嚴重問題，您可能需要重新安裝使用元數據庫的所有產品。
Microsoft 不能保證能夠解決由于您錯誤地編輯元數據庫而導致的問題，編輯元數據庫需要您自擔風險。
注意：每次編輯元數據庫前都要進行備份。
要為特定擴展名定義 MIME 類型，請執行下列步驟：
1. 在管理工具窗口中雙擊 Internet 信息服務（IIS）管理器，打開 IIS 管理控制臺（MMC），右鍵單擊本地計算機名稱，然后單擊屬性。
2. 單擊 MIME 類型，單擊新建。
3. 在擴展名框中，鍵入所需的文件擴展名（例如：.rmvb）。
4. 在 MIME 類型框中，鍵入“application/octet-stream”。
5. 應用新設置。現在，IIS 可以處理帶有所添加的擴展名的文件。在此示例中，IIS 現在可以處理帶有 .rmvb 擴展名的文件。
6. 重啟 IIS WEB 服務，設置既可生效。
]]>
對于采用 Access 數據庫的網站來說，爆庫是絕對危險！
1. 對 Access 數據庫文件名的設置
在任何 Access 數據庫文件名的前面加上一個 # 號，這樣做在一定程度上避免數據庫被下載。
其原因是瀏覽器在解析 URL 的時候,遇見 # 會以為是錨，這樣瀏覽器就會在頁面中搜索錨點，而不是指向一個文件。
不過有些下載工具還是會嘗試去連接這個 .mdb 數據庫文件，它會將 # 號使用 URL 編碼變為 %23，這樣依然可以下載 .mdb 文件。
2. 對 IIS 服務器進行設置
此方法當然是要對你的網站服務器具有控制權了，如果租用的服務器就沒法使用該辦法了。
使用該方法，就算是知道了 .mdb 數據庫的路徑也完全沒有辦法下載。
首先，選中你的站點，右鍵打開“站點屬性”對話框，選擇“主目錄”標簽，點擊“配置”開打“應用程序配置”對話框。
然后，在“應用程序擴展”中添加一項，“可執行文件”為：C:\WINDOWS\system32\inetsrv\asp.dll，“動作”為“限制”，輸入任意字符串（只要不是 get 或 post）都行，如輸入 haha。
最后，一路“確認”即可。
]]>
Mozilla Public License
MPL License，允許免費重發布、免費修改，但要求修改后的代碼版權歸軟件的發起者。這種授權維護了商業軟件的利益，它要求基于這種軟件的修改都要無償貢獻版權給該軟件。這樣，圍繞該軟件的所有代碼的版權都集中在發起開發人手中。MPL 是允許修改，無償使用的。MPL 軟件對鏈接沒有要求。
BSD 開源協議
BSD 開源協議是一個給于使用者很大自由的協議?？梢宰杂傻氖褂?，修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發布。當發布使用了 BSD 協議的代碼，或則以 BSD 協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：
1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的 BSD 協議。
2. 如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的 BSD 協議。
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD 由于允許使用者修改和重新發布代碼，也允許使用或在 BSD 代碼上進行商業軟件發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選 BSD 協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。
Apache Licence 2.0
Apache Licence 是著名的非盈利開源組織 Apache 采用的協議。該協議和 BSD 類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟件）。需要滿足的條件：
1. 需要給代碼的用戶一份 Apache Licence。
2. 如果修改了代碼，需要在被修改的文件中說明。
3. 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議、商標、專利聲明和其他原來作者規定需要包含的說明。
4. 如果再發布的產品中包含一個 Notice 文件，則在 Notice 文件中需要帶有 Apache Licence?？梢栽?Notice 中增加自己的許可，但不可以表現為對 Apache Licence 構成更改。
Apache Licence 也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售。
GPL
GPL 許可證是自由軟件的應用最廣泛的軟件許可證，可以修改程式的一個或幾個副本或程式的任何部分，以此形成基于這些程式的衍生作品。必須在修改過的檔案中附有明顯的說明（修改此檔案及任何修改的日期）。必須讓發布或出版的作品，包括本程式的全部或一部分，或內含本程式的全部或部分所衍生的作品，允許第三方在此許可證條款下使用，并且不得因為此項授權行為而收費。
LGPL
Linux 就是采用了 GPL。GPL 協議和 BSD、Apache Licence 等鼓勵代碼重用的許可很不一樣。GPL 的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。這也就是為什么我們能用免費的各種 Linux，包括商業公司的 Linux 和 Linux 上各種各樣的由個人，組織，以及商業軟件公司開發的免費軟件了。
GPL 協議的主要內容是只要在一個軟件中使用（“使用”指類庫引用，修改后的代碼或者衍生代碼）GPL 協議的產品，則該軟件產品必須也采用GPL 協議，即必須也是開源和免費。這就是所謂的“傳染性”。GPL 協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢。
由于 GPL 嚴格要求使用了 GPL 類庫的軟件產品必須使用 GPL 協議，對于使用 GPL 協議的開源代碼，商業軟件或者對代碼有保密要求的部門就不適合集成/采用作為類庫/二次開發。
其它細節如再發布的時候需要伴隨 GPL 協議等和 BSD/Apache 等協議的要求類似。
Public Domain
公共域授權。將軟件授權為公共域，這些軟件包沒有授權協議，任何人都可以隨意使用它。
Artistic 許可
使作者保持對進一步開發的控制。
]]>
隨著 Internet 的日益普及，現在基于 B/S 結構的大型應用越來越多，可如何對這些應用進行測試成為日益迫切的問題。有許多測試人員來信問我 B/S 的測試如何做，由于工作較繁忙，對大家提出的問題也是頭痛醫頭腳痛醫腳，沒有對 Web 的測試過程做一個整體的概述。希望通過本篇能夠讓大家了解大型 Web 應用是如何來進行測試的。
B/S 下的功能測試比較簡單，關鍵是如何做好性能測試。目前大多數的測試人員認為只要跑一些測試工具證明我的產品是可以達到性能的就 OK 了，為了證明而去測試是沒有任何價值的，關鍵是要發現產品性能上的缺陷，定位問題，解決問題，這才是測試要做的。
首先我們從兩個方面分析如何進行 Web 測試，從技術實現上來講一般的 B/S 結構，無論是 .NET 還是 J2EE，都是多層構架，有界面層、業務邏輯層、數據層。而從測試的流程上來說，首先是發現問題，分析問題，定位問題，再由開發人員解決問題。那么 B/S 的結構的測試如何來做呢？
如何發現問題是我首先要介紹的，在做 Web 測試之前你需要一些資料，比如產品功能說明書，性能需求說明書，不一定很完善，但一定要有，明確測試目標，這是基本的常識，可是我往往看到的是已經開始動手測了，但還不知自己的系統要達到的性能指標是什么。這里我簡單講一下測試的性能指標：
通用指標（指 Web 應用服務器、數據庫服務器必需測試項）：
Processor Time：指服務器 CPU 占用率，一般平均達到 70% 時，服務就接近飽和；
Memory Available Mbyte：可用內存數，如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重；
Physicsdisk Time：物理磁盤讀寫時間情況。
Web 服務器指標：
Avg Rps：平均每秒鐘響應次數=總請求時間/秒數；
Avg time to last byte per terstion（mstes）：平均每秒業務角本的迭代次數，有人會把這兩者混淆；
Successful Rounds：成功的請求；
Failed Rounds：失敗的請求；
Successful Hits：成功的點擊次數；
Failed Hits：失敗的點擊次數；
Hits Per Second：每秒點擊次數；
Successful Hits Per Second：每秒成功的點擊次數；
Failed Hits Per Second：每秒失敗的點擊次數；
Attempted Connections：嘗試鏈接數。
數據庫服務器指標：
User 0 Connections：用戶連接數，也就是數據庫的連接數量；
Number of deadlocks：數據庫死鎖；
Butter Cache hit：數據庫 Cache 的命中情況。
上面的指標只是一些通用的指標，起到拋磚引玉的作用，對于不同的應用你還必需作相應的調整，比如程序使用的是 .NET 技術的，則必需加入一些針對性的測試指標。對于這些指標的詳細了解，你可以參考 Windows 下面的 SystemMonitor 的幫助與 LoadRunner、ACT 的幫助。對于發現問題，指標的設置非常重要，它會幫你定性的發現一些錯誤。對于定性的壓力測試我就不做過多的分析，工具很多，流行的主要有 LoadRunner、ACT、WAS、WebLoad 各個工具有它的使用范圍；其中我各個認為：
LoadRunner 最全面，它提供了多種協議的支持，對復雜的壓力測試都可以勝任；
WAS 與 ACT 則對微軟的技術支持的比較好，其中 WAS 支持分布式機群測試；
ACT 則是與 .NET 集成比較好，支持 ViewState（.NET 下控件緩存的支持）的測試。
在這一階段測試你要不斷的跟據系數的測試目標進行變化，一開始由于系統過于龐大，所以我們要分成若干個子系統，各個子系統的性能目標必需明確，主要是并發指標定一個閾值，同時設定一些與系統相關的測試參數，應用服務器，數據庫服務器都要有，對達不到閾值的與一些通用參數有問題的子系統進行深入分析。比如它的并發達不到你的要求，證明子系統性能有問題，或是數據庫用戶連接過高，程序沒有釋放用戶連接等等。這個我們要對子系統進行詳細測試，由于 B/S 結構下，圖片的請求對性能的影響較大，所以我們對子系統測試時要分兩個部分進行：
非程序部分，即圖片等等；
應用程序本身。
通過事務或函數的分離，可以把這兩塊實現單獨的測試，具體做法參考各個工具的手冊，我這里就不做說明。對子系統的測試參數的設置要求則更高，它有助你后面精確的定位問題，比如對異常、死鎖、網絡流量等等前面沒有注意到的情況的增加；同時你要注意增加測試參數的收集對系統的性能影響比較大，所以一般不要超過 10 個。剛剛介紹的整體的性能測試指標也不要增加很多，這樣影響會小一點。最后在這一階段要說明的是數據庫的數據量會很大程度的影響性能，所以要根據前面的性能需求說明書向數據庫中模擬相應的數據量，來進行測試，這樣才有更高的可信度。
上面所說的是對問題的發現，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程序員配合完成，當然如果你有相當的開發經驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現問題的可能性可能有很多種，大致分以下幾種：
性能達不到目標；
性能達到目標，但有一些其它的問題，比如異常、死鎖。緩存命中過低，網絡流量較大；
服務器穩定性的問題，比如內存泄漏等。
發現這些問題起馬的要求要有一款使用的比較稱心的性能分析與優化工具，比如微軟的 .net 下就有自己開發的工具，對 Borland 的 Java 開發工具中也有類似的工具，但我個人認為更好的工具是 Rose 下的 Purify 與 Quantify，主要是他對.net 與 Java、C++ 都有支持，而且分析效果特別專業。我們先了解一下 Rational Purify。
Rational Purify 能自動找出 Visual C/C++ 和 Java 代碼中與內存有關的錯誤，確保整個應用程序的質量和可靠性。在查找典型的 Visual C/C++ 程序中的傳統內存訪問錯誤，以及 Java，C# 代碼中與垃圾內存收集相關的錯誤方面；Rational Quantity 則是一款針對函數級的性能分析利器，使用它你可以從圖形化的界面中得到函數調用的時間，百分比與次數，以及子函數所占時間，使你可以更快的定位性能瓶頸。
我們先說性能優化與異常的處理，性能優化有一個原則，即用時間比例最大的進行優化，效果才最明顯。比如有個函數它的執行時間為 30 秒，如果你優化了一百倍則執行時間為 0.3 秒，提升了 29.7 秒；而如果它的執行時間為 0.3 秒，優化后為 0.003 秒，實際提升了 0.297 秒，提升的效果并不明顯但寫過程序的人都知道，后者性能優化的代價更大。
在性能優化的過程中，一般是先數據庫，后程序。因為數據庫的優化不需要修改程序，修改的風險很小。但如何才能確定是數據庫的問題，這就需要技巧，在使用 Quantity 時，你一路分析下去，大多數最終會發現，是數據庫查詢函數占用時間比較大，比如什么 SqlCmd.ExecuteNoQuery 等等數據庫執行函數，這時你就需要分析數據庫。
數據庫的分析原則是先索引，后存儲過程，最后表結構視圖的優化。索引的優化是最簡單也是通常最有效的方法，如果合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛：SQLProfile、SQL 查詢分析器。
Precise SQLProfile 是一個 SQL 語句跟蹤器，可以跟蹤程序流程使用的 SQL 語句與存儲過程，結合查詢分析器對 SQL 的分析，可以對索引的優化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的性能下降，所以判斷還是需要一定的經驗。同時針對用戶使用頻度最高的 SQL 進行優化也是最行之有效的，這時我則需要 Precise，它可以觀測某一個較長時間內的 SQL 語句的執行情況。
數據庫優化的潛能挖光后，如果還是達不到性能要求或是還有問題，則要從程序來進行優化，這是程序員做的事。測試人員要做的，就是告訴他們，哪個函數執行過多引起了性能下降，比如異常過多，某個循環過多，或是 DCOM 調用過多等等，但說服程序員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經驗，并且要讓程序員感到聽你的性能會有提升，這是一件很不容易的事情哦。
內存的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰的準備，其次內存泄漏的分析最好是放在單元測試之中同步進行，而不是要等到最后再去發現問題，當然出了問題也只好面對，一般這類問題都是在服務器運行了很久才暴露出來，一旦發現問題后，則需要定位問題，分析的原則采用子系統相互獨立運行，找到最小問題的系統集，或是借助內存分析工具觀察內存對象情況，初步定位問題，再用 Purify 進行運行時分析，通常 C++ 內存問題比較多， Java 與 .NET 比較少，一般由 GC 不合理引起。C++ 的內存錯誤就比較多了，主要常見的有：
Array Bounds Read（ABR）：數組越界讀
Array Bounds Write（ABW）：數組越界寫
Beyond stack Read（BSR）：堆棧越界讀
Free Memory Read（FMR）：空閑內存讀
Invalid pointer Read（IPR）：非法指針閱讀
Null Pointer Read（NPR）： 空指針閱讀
Uninitialized Memory Read（UMR）：未初始化內存讀寫
Memory Leak：內存泄漏
注：如果需要更多的信息，可以參見 Purify 的幫助信息。
順便提一句，為什么我要說做單元測試時做內存分析比較好，由于單元測試針對的是單一功能，這時結合單元測試案例做內存分析會更快的定位問題，同時由于問題較早的發現，則后期的風險則會減少，當然如果結合代碼覆蓋工具 PureCoverage 來做就更完美了。
注：本篇只是對 B/S 應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹，你也可使用你比較熟悉的工具達到相同的目標。
]]>
01. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，并且頁面之間切換正確。
02. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。
03. 檢查按鈕的功能是否正確：如 update、cancel、delete、save 等功能是否正確。
04. 字符串長度檢查：輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯。
05. 字符類型檢查：在應該輸入指定類型的內容的地方輸入其他類型的內容（如在應該輸入整型的地方輸入其他字符類型），看系統是否檢查字符類型，會否報錯。
06. 標點符號檢查：輸入內容包括各種標點符號，特別是空格、各種引號、回車鍵。看系統處理是否正確。
07. 中文字符處理：在可以輸入中文的系統輸入中文，看會否出現亂碼或出錯。
08. 檢查帶出信息的完整性：在查看信息和 update 信息時，查看所填寫的信息是不是全部帶出，帶出信息和添加的是否一致。
09. 信息重復：在一些需要命名，且名字應該唯一的信息輸入重復的名字或 ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，系統是否作出正確處理。
10. 檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按“delete”，看系統如何處理，會否出錯；然后選擇一個和多個信息，進行刪除，看是否正確處理。
11. 檢查添加和修改是否一致：檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型。
12. 檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和自己重名的錯。
13. 重復提交表單：一條已經成功提交的紀錄，back 后再提交，看看系統是否做了處理。
14. 檢查多次使用 back 鍵的情況：在有 back 的地方，back，回到原來頁面，再 back，重復多次，看會否出錯。
15. Search 檢查：在有 Search 功能的地方輸入系統存在和不存在的內容，看 Search 結果是否正確。如果可以輸入多個 Search 條件，可以同時添加合理和不合理的條件，看系統處理是否正確。
16. 輸入信息位置：注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。
17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，并檢查系統是否能夠做到。
18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加“*”。
19. 快捷鍵檢查：是否支持常用快捷鍵，如 Ctrl+C、Ctrl+V、Backspace 等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。
20. 回車鍵檢查：在輸入結束后直接按回車鍵，看系統處理如何，會否報錯。
]]>
Web 壓力測試是目前比較流行的話題，利用 Web 壓力測試可以有效地測試一些 Web 服務器的運行狀態和響應時間等等，對于 Web 服務器的承受力測試是個非常好的手法。Web 壓力測試通常是利用一些工具，例如微軟的 Web Application Stress、Linux 下的 Siege、功能全面的 Web-CT 等等，這些都是非常優秀的 Web 壓力測試工具。
雖然這些工具給我們測試服務器承受能力帶來方便，但是它們的危害卻更是驚人，甚至于利用隨便一種比較全面的測試工具就可以對一臺小型的 Web 服務器發動災難性的拒絕式攻擊。下面我就帶大家利用微軟的 Web Application Stress 進行一次 Web 壓力測試，其目的是為了讓大家看到它的巨大危害。
一、工具簡單介紹
Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的客戶端計算機仿真大量用戶上線對網站服務所可能造成的影響，在網站實際上線之前先對您所設計的網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調整、設置工作。就是因為這些特性，才使它具備了 D.O.S 轟炸的功能。
小提示：D.O.S（拒絕服務攻擊）通過使你的服務計算機崩潰或把它壓跨來阻止你提供服務。簡單來說，就是讓你的計算機提供可能多的服務從而使你的計算機陷入崩潰的邊緣或崩潰。
二、工具簡單設置
打開 Web Application Stress Tool，很簡潔的一個頁面，上面是工具欄，左下方是功能選項，右下方是詳細設置選項。在對目標 Web 服務器進行壓力測試之前，先對它進行一些必要的設置。
1. 在“Settings”的功能設置中，一個是 Stress level （threads）這里是指定程序在后臺用多少線程進行請求，也就是相當于模擬多少個客戶機的連接，更加形象的就是說設置多少轟炸的線程數。一般填寫 500～1000，因為這個線程數是根據本機的承受力來設置的，如果你對自己的機器配置有足夠信心的話，那么設置的越高，轟炸的效果越好。
2. 在“Test Run Time”中來指定一次壓力測試需要持續的時間，分為天、小時、分、秒幾個單位級別，你根據實際情況來設置吧！
3. 其余的選項不太重要，這里就不再浪費筆墨，朋友們可以自己嘗試一下設置。
三、壓力測試
工具介紹完了，下面來準備條件：這里與一個朋友商量好進行測試，他是單機上網，機器配置是 CPU Athlon XP2500+、內存 512MB、硬盤 80GB 等，機器配置還不錯。他在機器上安裝了 IIS，架設了一臺對外的 Web 服務器，Web 服務中的程序是動網 7.0。我就利用壓力測試工具對這臺服務器進行測試。
步驟 1：在工具中點右鍵，選擇 Add 命令，增加了一個新的測試項目：New Script，對它進行設置，在主選項中的 Server 中填寫要測試的服務器的 IP 地址。在下方選擇測試的 Web 連接方式，這里的方式 Verb 選擇 Get，Path 選擇要測試的 Web 頁面路徑，這里填寫 /Index.asp，即動網的首頁文件。
步驟 2：在“Settings”的功能設置中將 Stress level （threads）線程數設置為 1000。完畢后，點工具中的灰色三角按鈕即可進行測試。測試完畢，等待朋友把任務管理器以及連接查看的截圖發過來！
攻擊開始后，朋友從任務管理器中可以看到 CPU 使用率已經達到 100%，損耗率達到最大。在 CMD 窗口中使用命令 netstat -an，可以看到我的 IP 地址在朋友服務器上的80端口進行了非常多的連接。而且它的 Web 網站已經打不開了，提示過多用戶連接，達到了跟 D.O.S 攻擊一樣的目的。
試想，如果利用多臺肉雞對一臺服務器進行 Web 壓力測試，那么對這臺服務器來說將是滅頂之災，所以朋友們在使用它之前一定要慎重考慮。
]]>
作者：于鵬 出處：中國 IT 實驗室 時間：2008-06-03 13:42
我始終認為，對一個初學者來說，IT 界的技術風潮是不可追趕。我時?？匆娮约旱?DDMM 們把課本扔了，去買些價格不菲的諸如 C#、VB.Net 這樣的大部頭，這讓我感到非常痛心。而許多搞不清指針是咋回事的 BBS 站友眉飛色舞的討論 C# 里面可以不用指針等等則讓我覺得好笑。C# 就象當年的 ASP 一樣，“忽如一夜春風來，千樹萬樹梨花開”，結果許多學校的信息學院成了“Web 學院”。96、97 級的不少大學生都去做 Web 了。當然我沒有任何歧視某一行業的意識。我只是覺得如果他們把追趕這些時髦技術的時間多花一點在基礎的課程上應該是可以走得更遠的。
一、高薪之路五大誤區
初學者對 C# 風潮的追趕其實也只是學習過程中經常遇到的幾個誤區之一。我將用一些實際的例子來說明這些現象，你可以按部就班的看看自己是不是屬于其中的一種或者幾種：
1. 認為計算機技術等于編程技術
有些人即使沒有這個想法，在潛意識中也有這樣的沖動。讓我奇怪的是，許多信息學院的學生也有這樣的念頭。認為計算機專業就是編程專業，與編程無關的，或者不太相關的課程他統統都不管，極端的學生只要書上沒帶“編程”兩個字他就不看。
其實編程只是計算機技術應用過程中一種復雜性最低的勞動，這就是為什么 IT 業最底層的人是程序員（Coder）。計算機技術包括了多媒體，計算機網絡，人工智能，模式識別，管理信息系統等等這些方面。編程工作只是在這些具體技術在理論研究或者工程實踐的過程中表達算法的過程。編程的人不一定對計算機技術的了解就一定很高。而一個有趣的現象是，不少大師級的計算機技術研究者是不懂編程的。網上的炒作和現實中良好的工作待遇把編程這種勞動神秘化了。其實每一個程序員心里都明白，自己這些東西，學的時候并不比其它專業難，所以自然也不會高檔到哪里去。
2. 咬文嚼字的孔已己作風
我見過一本女生的《計算機網絡原理》教材，這個女生像小學生一樣在書上劃滿了橫杠杠，筆記做得滿滿的，打印出來一定比教材還厚。我不明白的是，像計算機網絡原理這樣的課程有必要做筆記？我們的應試教育的確害了不少學生，在上《原理》這一類課程的時候許多學生像學《馬列原理》一樣逐字背誦記憶。這乃是我見過的最愚蠢的行為。所謂《原理》，即是需要掌握它為什么這樣做，學習 why，而不是 how（怎樣做）。極端認真的學生背下以太網的網線最大長度，數據幀的長度，每個字段的意義，IP 報頭的格式等等，但是忘了路由的原則，忘了 TCP/IP 協議設計的宗旨。總之許多人花了大量的時間把書背得滾瓜爛熟卻等于什么也沒學。
在學習編程的時候這些學生也是這樣，他們確切的記得 C++ 語法的各個細節?？赐炅?C++ 教程后看《Thinking in C++》（確實是好書），《Inside C++》，《C++ reference》，this C++，that C++ ……，然后是網上各種各樣的關于 C++ 語法的奇聞逸事，然后發現自己又忘了 C++ 的一些語法，最后回頭繼續惡補…。有個師弟就跟我說：“C++ 太難了，學了這里忘了那里，學了繼承忘了模板。”我的回答道：“你不去學就容易了。”我并沒有教壞他，只是告訴他，死摳 C++ 的語法就和孔已己炫耀茴香豆的茴字有幾種寫法一樣毫無意義。你根本不需要對的 C++ 語法太關心，動手編程就是了，有不記得的地方一查 MSDN 就立馬搞定。我有個結論就是，實際的開發過程中對程序語法的了解是最微不足道的知識。這是為什么我在為同學用 Basic（我以前從沒有學過它）寫一個小程序的時候，只花了半個小時看了看語法，然后再用半個小時完成了程序，而一個小時后我又完全忘記了 Basic 的所有關鍵字。
3. 不顧基礎，盲目追趕時髦技術
終于點到題目上來了。大多數的人都希望自己的東西能夠馬上跑起來，變成錢。這種想法對一個已經進入職業領域的程序員或者項目經理來說是合理的，而且 IT 技術進步是如此的快，不跟進就是失業。但是對于初學者來說（尤其是時間充裕的大中專在校生），這種想法是另人費解的。一個并未進入到行業競爭中來的初學者最大的資本便是他有足夠的時間沉下心來學習基礎性的東西，學習 why 而不是 how。時髦的技術往往容易掌握，而且越來越容易掌握，這是商業利益的驅使，為了最大化的降低軟件開發的成本。但在 IT 領域內的現實就是這樣，越容易掌握的東西，學習的人越多，而且淘汰得越快。每一次新的技術出來，都有許多初學者跟進，這些初學者由于缺乏必要的基礎而使得自己在跟進的過程中花費大量的時間，而等他學會了，這種技術也快淘汰了?；A的課程，比方數據結構，操作系統原理等等雖然不能讓你立馬就實現一個 Linux（這是許多人嘲笑理論課程無用的原因），但它們能夠顯著的減少你在學習新技術時學習曲線的坡度。而且對于許多關鍵的技術（比方 Win32 SDK 程序的設計、DDK 的編程）來說甚至是不可或缺的。
舉個一個不很恰當的比方：假設學習 VB 編程需要 4 個月，學習基礎課程和 VC 的程序設計需要 1 年。那么如果你先學 VB，再來學習后者，時間不會減少，還是 1 年，而反過來，如果先學習后者，再來學 VB，也許你只需要 1 個星期就能學得非常熟練。
4. 幾個重要的基礎課程
如果你是學生，或者如果你有充足的時間。我建議你仔細的掌握下面的知識。我的建議是針對那些希望在 IT 技術上有所成就的初學者。同時我還列出了一些書目，這些書應該都還可以在書店買到。說實在的，我在讀其他人的文章時最大的心愿就是希望作者列出一個書單。
《大學英語》：不要覺得好笑。我極力推薦這門課程是因為沒有專業文檔的閱讀能力是不可想象的。中文的翻譯往往在猴年馬月才會出來，而現在的許多出版社干脆就直接把 E 文印刷上去。學習的方法是強迫自己看原版的教材，開始會看不懂，用多了自然熟練。吃得苦下得狠心絕對是任何行業都需要的品質。
《計算機體系結構和匯編語言》：關于體系結構的書遍地都是，而且也大同小異，倒是匯編有一本非常好的書《80x86 匯編語言程序設計教程》（清華大學出版社，黑色封面，楊季文著）。你需要著重學習 386 后保護模式的程序設計。否則你在學習現代操作系統底層的一些東西的時候會覺得是在看天書。
《計算機操作系統原理》：我們的開發總是在特定的操作系統上進行，如果不是，只有一種可能：你在自己實現一個操作系統。無論如何，操作系統原理是必讀的。這就象我們為一個芯片制作外圍設備時，芯片基本的工作時序是必需了解的。這一類書也很多，我沒有發現哪一本書非常出眾。只是覺得在看完了這些書后如果有空就應該看看《Inside Windows 2000》（微軟出版社，我看的是 E 文版的，中文的書名想必是《Windows 2000 技術內幕》之類吧）。關于學習它的必要性，ZDNET 上的另一篇文章已經有過論述。
《數據結構和算法》：這門課程能夠決定一個人程序設計水平的高低，是一門核心課程。我首選的是清華版的（朱戰立，劉天時）。很多人喜歡買 C++ 版的，但我覺得沒有必要。C++ 的語法讓算法實現過程變得復雜多了，而且許多老師喜歡用模塊這一東西讓算法變得更復雜。倒是在學完了 C 版的書以后再來瀏覽一下 C++ 的版的書是最好的。
《軟件工程》：這門課程是越到后來就越發現它的重要，雖然剛開始看時就象看馬哲一樣不知所云。我的建議是看《實用軟件工程》（黃色，清華）。不要花太多的時間去記條條框框，看不懂就跳過去。在每次自己完成了一個軟件設計任務（不管是練習還是工作）以后再來回顧回顧，每次都會有收獲。
《Windows 程序設計》：（北京大學出版社，Petzold 著）我建議任何企圖設計 Windows 程序的人在學習 VC 以前仔細的學完它。而且前面的那本《Inside Windows 2000》也最好放到這本書的后面讀。在這本書中，沒有 C++，沒有 GUI，沒有控件。有的就是如何用原始的 C 語言來完成 Windows 程序設計。在學完了它以后，你才會發現 VC 其實是很容易學的。千萬不要在沒有看完這本書以前提前學習 VC，你最好碰都不要碰。我知道的許多名校甚至都已經用它作為教材進行授課?？梢娖渲匾?。
上面的幾門課程我認為是必學的重要課程（如果你想做 Windows 程序員）。
對于其它的課程有這樣簡單的選擇方法：如果你是計算機系的，請學好你所有的專業基礎課。如果不是，請參照計算機系的課程表。如果你發現自己看一本書時無法看下去了，請翻到書的最后，看看它的參考文獻，找到它們并學習它們，再回頭看這本書。如果一本書的書名中帶有“原理”兩個字，你一定不要去記憶它其中的細節，你應該以一天至少 50 頁的速度掌握其要領。盡可能多的在計算機上實踐一種理論或者算法。你還可以在 CSDN 上閱讀到許多書評。這些書評能夠幫助你決定讀什么樣的書。
5. 日三省乎己
每天讀的書太多，容易讓人迷失方向。一定要在每天晚上想想自己學了些什么，還有些什么相關的東西需要掌握，自己對什么最感興趣，在一本書上花的時間太長還是不夠等等。同時也應該多想想未來最有可能出現的應用，這樣能夠讓你不是追趕技術潮流而是引領技術潮流。同時，努力使用現在已經掌握的技術和理論去制作具有一定新意的東西。堅持這樣做能夠讓你真正成為一個軟件“研發者”而不僅僅是一個 Coder。
二、高薪之路三大關鍵
1. 名校畢業≠高薪，就業行業是關鍵
名校是一塊不錯的敲門磚，但并非萬能。選擇行業是重要因素。傳統行業經過了多年的發展，對人才的需求已趨于飽和狀態，并開始下跌；某些發展中的新興行業正在崛起，對人才的需求格外旺盛。被稱為朝陽行業的 IT 業，在過去 5 年經歷了每年 28% 的增長速度，是同期國家 GDP 增長速度的 3 倍。近兩年來互聯網、軟件、電子商務等各個分支行業的興起，為 IT 業打上了幾針強心劑，使其人才吸納速度加快。就業行業是影響個人職業生涯的重要因素，要獲取好的薪資待遇，不能忽視對行業的選擇。
2. 熱門專業≠高薪，是否具備經驗是關鍵
擔憂和抱怨社會就業狀況，不如深入了解自己找不到工作的癥結所在。研究一下各大企業的招聘啟事，我們不難發現，企業招納人才時所考慮的因素不外乎如下幾點：學歷、專業、技能、經驗、性別、形象、戶口。在這 7 大因素中，尤以“技能”和“經驗”所占比重最大，是起決定性作用的因素。在 IT 企業的招聘啟事中，“經驗”更是核心中的核心。
3. 高學歷≠高薪，是否掌握一技之長是關鍵
沒有掌握一技之長，僅憑學歷，寸步難行。現在社會競爭壓力很大，企業之間也在爭奪生存資源，相對于有學歷而沒有技術的人才，企業更青睞能直接創造效益的技能人才。因此，高學歷不代表能拿高薪，關鍵在于是否掌握一技之長；沒有高學歷，只要掌握一定的技術之后，也能成為名企青睞的對象。
三、編后語
程序員的人生不應該是枯燥無味整天跟機器打交道，希望所有的程序員或者希望成為程序員的朋友，能有豐富多彩地生活，能去除心浮氣躁踏踏實實地去學習不斷提高自己，能充滿熱情滿懷希望地去面對工作。“聞道有先后，術業有專攻，如是而已”，任何事情，只要把它做到及至，都會很成功。
]]>
基本原理
云計算（Cloud Computing）是分布式處理（Distributed Computing）、并行處理（Parallel Computing）和網格計算（Grid Computing）的發展，或者說是這些計算機科學概念的商業實現。
云計算的基本原理是，通過使計算分布在大量的分布式計算機上，而非本地計算機或遠程服務器中，企業數據中心的運行將更與互聯網相似。這使得企業能夠將資源切換到需要的應用上，根據需求訪問計算機和存儲系統。
這可是一種革命性的舉措，打個比方，這就好比是從古老的單臺發電機模式轉向了電廠集中供電的模式。它意味著計算能力也可以作為一種商品進行流通，就像煤氣、水電一樣，取用方便，費用低廉，最大的不同在于，它是通過互聯網進行傳輸的。
云計算的藍圖已經呼之欲出：在未來，只需要一臺筆記本或者一個手機，就可以通過網絡服務來實現我們需要的一切，甚至包括超級計算這樣的任務。從這個角度而言，最終用戶才是云計算的真正擁有者。
云計算的應用包含這樣的一種思想，把力量聯合起來，給其中的每一個成員使用。
“云計算”時代
目前，PC 依然是我們日常工作生活中的核心工具，我們用 PC 處理文檔、存儲資料，通過電子郵件或 U 盤與他人分享信息。但如果 PC 硬盤壞了，我們會因為資料丟失而束手無策。
而在“云計算”時代，“云”會替我們做存儲和計算的工作。“云”就是計算機群，每一群包括了幾十萬臺、甚至上百萬臺計算機。“云”的好處還在于，其中的計算機可以隨時更新，保證“云”長生不老。
屆時，我們只需要一臺能上網的電腦，不需關心存儲或計算發生在哪朵“云”上，但一旦有需要，我們可以在任何地點用任何設備，如電腦、手機等，快速地計算和找到這些資料。我們再也不用擔心資料丟失。
“云計算”就仿佛銀行的自動取款機（ATM），我們出門再也不用隨身攜帶大量現鈔，可以根據需要隨時取用。
PC 時代好比每個人要用電，都得自己購買發電機；而“云計算”時代，每個人不必擁有發電機，直接從大型發電廠買電就好。
“云計算”其實并不是一個新概念，“云計算”之前，還有“網格計算”（Grid Computing）等等，理念都是關于計算機如何協同發揮作用。
云計算是一種新興的共享基礎架構的方法，它可以將巨大的系統池連接在一起以提供各種 IT 服務。很多因素推動了對這類環境的需求，其中包括連接設備、實時數據流、 SOA 的采用以及搜索、開放協作、社會網絡和移動商務等這樣的 Web 2.0 應用的急劇增長。
另外，數字元器件性能的提升也使IT環境的規模大幅度提高，從而進一步加強了對一個由統一的云進行管理的需求。
“云計算+Always-On”設備被評為“25 年來最具影響力的十大 IT 技術組合”。
云計算正在成為一個大眾化的詞語。但是，問題是似乎每個人對于云計算的理解各不相同。作為一個對互聯網的比喻，“云”是很容易理解的。但是一旦同“計算”聯系起來，它的意義就擴展了，而且開始變得模糊起來。有些分析師和公司把云計算僅僅定義為計算的升級版，基本上就是互聯網上提供的眾多虛擬服務器。另外一些人把云計算定義的更加寬泛，他們認為用戶在防火墻保護之外消費的任何事物都處于“云”之中。
云計算被人們關注是在人們考慮 IT 業到底需要什么之后，人們需要找到一種辦法能夠在不增加新的投資，新的人力和新的軟件的情況下增加互聯網的能力和容量。而云計算正好提供了這種可能。
云計算形式
01. SaaS（軟件即服務）
這種類型的云計算通過瀏覽器把程序傳給成千上萬的用戶。在用戶眼中看來，這樣會省去在服務器和軟件授權上的開支；從供應商角度來看，這樣只需要維持一個程序就夠了，這樣能夠減少成本。SaaS 在人力資源管理程序和 ERP 中比較常用。
02. 實用計算（Utility Computing）
這個主意很早就有了，但是知道最近才在提供存儲服務和虛擬服務器的公司中新生。這種云計算是為 IT 行業創造虛擬的數據中心使得其能夠把內存、I/O 設備、存儲和計算能力集中起來成為一個虛擬的資源池來為整個網絡提供服務。
03. 網絡服務
同 SaaS 關系密切，網絡服務提供者們能夠提供 API 讓開發者能夠開發更多基于互聯網的應用，而不是提供單機程序。
04. 平臺即服務
另一種 SaaS，這種形式的云計算把開發環境作為一種服務來提供。你可以使用中間商的設備來開發自己的程序并通過互聯網和其服務器傳到用戶手中。
05. MSP（管理服務提供商）
最古老的云計算運用之一。這種應用更多的是面向 IT 行業而不是終端用戶，常用于郵件病毒掃描、程序監控等等。
06. 商業服務平臺
SaaS 和 MSP 的混合應用，該類云計算為用戶和提供商之間的互動提供了一個平臺。比如用戶個人開支管理系統，能夠根據用戶的設置來管理其開支并協調其訂購的各種服務。
07. 互聯網整合
將互聯網上提供類似服務的公司整合起來，以便用戶能夠更方便的比較和選擇自己的服務供應商。
云計算特點
首先，云計算提供了最可靠、最安全的數據存儲中心，用戶不用再擔心數據丟失、病毒入侵等麻煩。很多人覺得數據只有保存在自己看得見、摸得著的電腦里才最安全，其實不然。你的電腦可能會因為自己不小心而被損壞，或者被病毒攻擊，導致硬盤上的數據無法恢復，而有機會接觸你的電腦的不法之徒則可能利用各種機會竊取你的數據。此前轟動一時的“艷照門”事件據報道不也是因為電腦送修而造成個人數據外泄的嗎？
反之，當你的文檔保存在類似 Google Docs 的網絡服務上，當你把自己的照片上傳到類似 Google Picasa Web 的網絡相冊里，你就再也不用擔心數據的丟失或損壞。因為在“云”的另一端，有全世界最專業的團隊來幫你管理信息，有全世界最先進的數據中心來幫你保存數據。同時，嚴格的權限管理策略可以幫助你放心地與你指定的人共享數據。這樣，你不用花錢就可以享受到最好、最安全的服務，甚至比在銀行里存錢還方便。
其次，云計算對用戶端的設備要求最低，使用起來也最方便。大家都有過維護個人電腦上種類繁多的應用軟件的經歷。為了使用某個最新的操作系統，或使用某個軟件的最新版本，我們必須不斷升級自己的電腦硬件。為了打開朋友發來的某種格式的文檔，我們不得不瘋狂尋找并下載某個應用軟件。
為了防止在下載時引入病毒，我們不得不反復安裝殺毒和防火墻軟件。所有這些麻煩事加在一起，對于一個剛剛接觸計算機，剛剛接觸網絡的新手來說不啻一場噩夢！如果你再也無法忍受這樣的電腦使用體驗，云計算也許是你的最好選擇。你只要有一臺可以上網的電腦，有一個你喜歡的瀏覽器，你要做的就是在瀏覽器中鍵入 URL，然后盡情享受云計算帶給你的無限樂趣。
你可以在瀏覽器中直接編輯存儲在“云”的另一端的文檔，你可以隨時與朋友分享信息，再也不用擔心你的軟件是否是最新版本，再也不用為軟件或文檔染上病毒而發愁。因為在“云”的另一端，有專業的 IT 人員幫你維護硬件，幫你安裝和升級軟件，幫你防范病毒和各類網絡攻擊，幫你做你以前在個人電腦上所做的一切。
此外，云計算可以輕松實現不同設備間的數據與應用共享。大家不妨回想一下，你自己的聯系人信息是如何保存的。一個最常見的情形是，你的手機里存儲了幾百個聯系人的電話號碼，你的個人電腦或筆記本電腦里則存儲了幾百個電子郵件地址。為了方便在出差時發郵件，你不得不在個人電腦和筆記本電腦之間定期同步聯系人信息。買了新的手機后，你不得不在舊手機和新手機之間同步電話號碼。
對了，還有你的 PDA 以及你辦公室里的電腦。考慮到不同設備的數據同步方法種類繁多，操作復雜，要在這許多不同的設備之間保存和維護最新的一份聯系人信息，你必須為此付出難以計數的時間和精力。這時，你需要用云計算來讓一切都變得更簡單。在云計算的網絡應用模式中，數據只有一份，保存在“云”的另一端，你的所有電子設備只需要連接互聯網，就可以同時訪問和使用同一份數據。
仍然以聯系人信息的管理為例，當你使用網絡服務來管理所有聯系人的信息后，你可以在任何地方用任何一臺電腦找到某個朋友的電子郵件地址，可以在任何一部手機上直接撥通朋友的電話號碼，也可以把某個聯系人的電子名片快速分享給好幾個朋友。當然，這一切都是在嚴格的安全管理機制下進行的，只有對數據擁有訪問權限的人，才可以使用或與他人分享這份數據。
最后，云計算為我們使用網絡提供了幾乎無限多的可能，為存儲和管理數據提供了幾乎無限多的空間，也為我們完成各類應用提供了幾乎無限強大的計算能力。想像一下，當你駕車出游的時候，只要用手機連入網絡，就可以直接看到自己所在地區的衛星地圖和實時的交通狀況，可以快速查詢自己預設的行車路線，可以請網絡上的好友推薦附近最好的景區和餐館，可以快速預訂目的地的賓館，還可以把自己剛剛拍攝的照片或視頻剪輯分享給遠方的親友…
離開了云計算，單單使用個人電腦或手機上的客戶端應用，我們是無法享受這些便捷的。個人電腦或其他電子設備不可能提供無限量的存儲空間和計算能力，但在“云”的另一端，由數千臺、數萬臺甚至更多服務器組成的龐大的集群卻可以輕易地做到這一點。個人和單個設備的能力是有限的，但云計算的潛力卻幾乎是無限的。當你把最常用的數據和最重要的功能都放在“云”上時，我們相信，你對電腦、應用軟件乃至網絡的認識會有翻天覆地的變化，你的生活也會因此而改變。
展望未來
互聯網的精神實質是自由、平等和分享。作為一種最能體現互聯網精神的計算模型，云計算必將在不遠的將來展示出強大的生命力，并將從多個方面改變我們的工作和生活。無論是普通網絡用戶，還是企業員工，無論是 IT 管理者，還是軟件開發人員，他們都能親身體驗到這種改變。
另外，云計算編程技術將成為基準的下一代計算機編程結構。
]]>
軟件即服務（Software as a Service，SaaS）是隨著互聯網技術的發展和應用軟件的成熟，而在 21 世紀開始興起的一種完全創新的軟件應用模式。
它與 On-Demand Software（按需軟件)、The Application Service Provider(ASP，應用服務提供商)、Hosted Software（托管軟件）具有相似的含義。
它是一種通過 Internet 提供軟件的模式，廠商將應用軟件統一部署在自己的服務器上，客戶可以根據自己實際需求，通過互聯網向廠商定購所需的應用軟件服務，按定購的服務多少和時間長短向廠商支付費用，并通過互聯網獲得廠商提供的服務。
用戶不用再購買軟件，而改用向提供商租用基于 Web 的軟件，來管理企業經營活動，且無需對軟件進行維護，服務提供商會全權管理和維護軟件，軟件廠商在向客戶提供互聯網應用的同時，也提供軟件的離線操作和本地數據存儲，讓用戶隨時隨地都可以使用其定購的軟件和服務。
對于許多小型企業來說，SaaS 是采用先進技術的最好途徑，它消除了企業購買、構建和維護基礎設施和應用程序的需要。
在這種模式下，客戶不再象傳統模式那樣花費大量投資用于硬件、軟件、人員，而只需要支出一定的租賃服務費用，通過互聯網便可以享受到相應的硬件、軟件和維護服務，享有軟件使用權和不斷升級，這是網絡應用最具效益的營運模式。
SaaS 服務模式與傳統的銷售軟件永久許可證的方式有很大的不同，它是未來管理軟件的發展趨勢。
SaaS 不僅減少或取消了傳統的軟件授權費用，而且廠商將應用軟件部署在統一的服務器上，免除了最終用戶的服務器硬件、網絡安全設備和軟件升級維護的支出，客戶不需要除了個人電腦和互聯網連接之外的其它 IT 投資就可以通過互聯網獲得所需要軟件和服務。
此外，大量的新技術，如 Web Service，提供了更簡單、更靈活、更實用的 SaaS。
另外，SaaS 供應商通常是按照客戶所租用的軟件模塊來進行收費的，因此用戶可以根據需求按需訂購軟件應用服務，而且 SaaS 的供應商會負責系統的部署、升級和維護，而傳統管理軟件通常是買家需要一次支付一筆可觀的費用才能正式啟動。
SaaS 服務提供商為中小企業搭建信息化所需要的所有網絡基礎設施及軟件、硬件運作平臺，并負責所有前期的實施、后期的維護等一系列服務，企業無需購買軟硬件、建設機房、招聘 IT 人員，只需前期支付一次性的項目實施費和定期的軟件租賃服務費，即可通過互聯網享用信息系統。
服務提供商通過有效的技術措施，可以保證每家企業數據的安全性和保密性。
企業采用 SaaS 服務模式在效果上與企業自建信息系統基本沒有區別，但節省了大量用于購買 IT 產品、技術和維護運行的資金，且像打開自來水龍頭就能用水一樣，方便地利用信息化系統，從而大幅度降低了中小企業信息化的門檻與風險。
具體來說 SaaS 可以為客戶帶來如下的價值：
01. 服務的收費方式風險小，靈活選擇模塊，備份，維護，安全，升級
02. 讓客戶更專注核心業務
03. 靈活啟用和暫停，隨時隨地都可使用
04. 按需定購，選擇更加自由
05. 產品更新速度加快
06. 市場空間增大
07. 實現年息式的循環收入模式
08. 有效降低營銷成本
09. 準面對面使用指導
10. 在全球各地，7*24 全天候網絡服務
11. 不需要額外增加專業的 IT 人員
12. 大大降低客戶的總體擁有成本
]]>
微軟先后在 2001 年和 2006 年發布了兩個 Bug 報告，其中有一個報告說到如果獲取一個 checkbox list 的值，存入 dictionaray，再將 dictionary 放入 session，則有可能破壞掉 session 的值。
微軟在設計 dictionary 時，本身是為客戶端而設計，因此，如果在服務器端使用 dictionary，而又將其放入 session，則有可能損壞 session。
所以，官方不建議在服務器端使用 session。
不過讓人奇怪的是，微軟明明知道它的 VBScript 有這個 Bug，卻沒有推出新的版本來修復，而是發布用一種極變態的方法來規避。
]]>
中國共 產黨機關公文處理條例
（中辦發 [1996] 14 號 1996 年 5 月 3 日）
第一章 總 則第一章 總 則
第二章 公文種類
第三章 公文格式
第四章 行文規則
第五章 公文起草
第六章 公文校對
第七章 公文簽發
第八章 公文辦理和傳遞
第九章 公文管理
第十章 公文立卷歸檔
第十一章 公文保密
第十二章 附 則
第一條 為適應中國共 產黨機關（以下簡稱黨的機關）工作的需要，實現黨的機關公文處理工作的科學化、制度化、規范化、制定本條例。
第二條 黨的機關的公文，是黨的機關實施領導、處理公務的具有特定效力和規范格式的文書，是傳達貫徹黨的路線、方針、政策，指導、布置和商洽工作，請示和答復問題，報告和交流情況的工具。
第三條 公文處理是包抓公文擬制、辦理、管理、立卷歸檔在內的一系列銜接有序的工作。
第四條 公文處理應當堅持實事求是、按照行文機關要求和公文處理規定進行的原則，做到準確。及時、安全、保密。
第五條 黨的機關的辦公廳（室）主管本機關的公文處理工作，并對下級機關的公文處理工作進行業務指導。
第六條 黨的機關的辦公廳（室）應當設立秘書部門或者配備秘書人員具體負責公文處理工作，并逐步改善辦公手段，努力提高工作效率和質量。秘書人員應當具有較高的政治和業務素質，工作積極，作風嚴謹，遵守紀律，恪盡職守。
第二章 公文種類
第七條 黨的機關公文種類主要有：
?。ㄒ唬Q議：用于經會議討論通過的重要決策事項。
?。ǘQ定：用于對重要事項作出決策和安排。
?。ㄈ┲甘荆河糜趯ο录墮C關布置工作，提出開展工作的原則和要求。
?。ㄋ模┮庖姡河糜趯χ匾獑栴}提出見解和處理辦法。
（五）通知：用于發布黨內法規、任免干部、傳達上級機關的指示、轉發上級機關和不相隸屬機關的公文、批轉下級機關的公文、發布要求下級機關辦理和有關單位共同執行或者周知的事項。
?。┩▓螅河糜诒碚孟冗M、批評錯誤、傳達重要精神、交流重要情況。
（七）公報：用于公布發布重要決定或者重大事件。
?。ò耍﹫蟾妫河糜谙蛏霞墮C關匯報工作、反映情況、提出建議，答復上級機關的詢問。
?。ň牛┱埵荆河糜谙蛏霞墮C關請求指示、批準。
?。ㄊ┡鷱停河糜诖饛拖录墮C關的請示。
?。ㄊ唬l例：用于黨的中央組織制定規范黨組織的工作、活動和黨員行為的規章制度。
?。ㄊ┮幎ǎ河糜趯μ囟ǚ秶鷥鹊墓ぷ骱褪聞罩贫ň哂屑s束力的行為規范。
?。ㄊ┖河糜跈C關之間商洽工作、詢問和答復問題，向無隸屬關系的有關主管部門請求批準等。
?。ㄊ模h紀要：用于記載會議主要精神和議定事項。
第三章 公文格式
第八條 黨的機關公文由版頭、份號、密級、緊急程度、發文字號、簽發人、標題、主送機關、正文、附件、發文機關署名、成文日期、印章、印發傳達范圍。主題詞、抄送機關、印制版記組成。
?。ㄒ唬┌骖^由發文機關全稱或者規范化簡稱加"文件"二字或者加括號標明文種組成，用套紅大字居中印在公文首頁上部。聯合行文，版頭可以用主辦機關名稱，也可以并用聯署機關名稱。在民族自治地方，發文機關名稱可以并用自治民族的文字和漢字印制。
?。ǘ┓萏柟挠≈品輸档捻樞蛱枺瑯俗⒂诠氖醉撟笊辖恰Ｃ孛芄膽敇嗣鞣萏?。
?。ㄈ┟芗?，公文的秘密等級，標注于份號下方。
?。ㄋ模┚o急程度對公文送達和辦理的時間要求。緊急文件應當分別標明“特急”、“加急”，緊急電報應當分別標明“特提”、“特急”、“加急”、“平急”。
?。ㄎ澹┌l文字號由發文機關代字、發文年度和發文順序號組成，標注于版頭下方居中或者左下方。聯合行文，一般只標明主辦機關的發文字號。
?。┖灠l人上報公文應當在發文字號右側標注“簽發人”，“簽發人”后面標注簽發人姓名。
（七）標題由發文機關名稱、公文主題和文種組成，位于發文字號下方。
?。ò耍┲魉蜋C關主要受理公文的機關。主送機關名稱應當用全稱或者規范化簡稱或者同類型機關的統稱，位于正文上方，頂格排印。
?。ň牛┱墓牡闹黧w，用來表達公文的內容，位于標題或者主送機關下方。
?。ㄊ└郊母郊瑧斨糜谥骷螅c主件裝訂在一起，并在正文之后、發文機關署名之前注明附件的名稱。
（十一）發文機關署名應當用全稱或者規范化簡稱，位于正文的右下方。
?。ㄊ┏晌娜掌谝话闶饡h通過或者領導人簽發日期；聯合行文，署最后簽發機關領導人的簽發日期；特殊情況署印發日期。成文日期應當寫明年、月、日，位于發文機關署名右下方。決議、決定、條例、規定等不標明主送機關的公文，成文日期加括號標注于標題下方居中位置。
（十三）印章除會議紀要和印制的有特定版頭的普發性公文外，公文應當加蓋發文機關印章。
?。ㄊ模┯“l傳達范圍 加括號標注于成文日期左下角。
?。ㄊ澹┲黝}詞按上級機關的要求和《公文主題詞表》標注位于抄送機關上方。
?。ㄊ┏蜋C關指除主送機關以外的其他需要告知公文內容的上級、下級和不相隸屬機關。抄送機關名稱標注于印制版記上方。
?。ㄊ撸┯≈瓢嬗浻晒挠“l機關名稱、印發日期和份數組成，位于公文末頁下端。
第九條 公文的漢字從左至右橫排；少數民族文字按其書寫習慣排印。公文用紙幅面規格可采用 16 開型（長 260 毫米，寬 184 毫米），也可采用國際標準 A4 型（長 297 毫米，寬 210 毫米）。左側裝訂。
第十條 黨的機關公文版頭的主要形式及適用范圍：
?。ㄒ唬吨泄?XX 文件》用于各級黨委發布、傳達貫徹黨的方針、政策，作出重要工作部署，轉發上級機關的文件，批轉下級機關的重要報告、請示。
?。ǘ┲袊病‘a黨 XX 委員會（XX）》用于各級黨委通知重要事項、任免干部、批復下級機關的請示、向上級機關報告、請示工作。
（三）中共 XX 辦公廳（室）文件》、《中共 XX 辦公廳（室）（XX）》用于各級黨委辦公廳（室）根據授權，傳達黨委的指示，答復下級黨委的請示，轉發上級機關的文件，批轉下級機關的報告、請示、發布有關事項向上級機關報告請示工作。
?。ㄋ模吨泄?XX 部文件》、《中共 XX 部（XX）》用于除辦公廳（室）以外的黨委各部門發布本部門職權范圍內的事項，向上級機關報告、請示工作。
第四章 行文規則
第十一條 行文應當確有需要、注重實效、堅持少而精?？砂l可不發的公文不發，可長可短的公文要短。
第十二條 黨的機關的行文關系，根據各自的隸屬關系和職權范圍確定。
?。ㄒ唬┫蛏霞墮C關行文，應當主送一個上級機關如需其他相關的上級機關問知，可以抄送。不得越級向上級機關行文，尤其不得越級請示問題；因特殊情況必須越級行文時，應當同時抄送被越過的上級機關。
?。ǘ┫蛳录墮C關的重要行文，應當同時抄送發文機關的直接上級機關。
?。ㄈh委各部門在各自職權范圍內可以向下級黨委的相關部門行文。黨委辦公廳（室）根據黨委授權，可以向下級黨委行文；黨委的其他部門，不得對下級黨委發布指示性公文。部門之間對有關問題未經協商一致，不得各自向下行文。
?。ㄋ模┩夵h的機關、黨的機關與其他同級機關之間必要時可以聯合行文。
?。ㄎ澹┎幌嚯`屬機關之間一般用函行文。
第十三條 受雙重領導的機關向上級機關行文，應當寫明主送機關和抄送機關，由主送機關負責答復其請示事項。上級機關向受雙重領導的下級機關行文，應當抄送其另一上級機關。
第十四條 向上級機關請示問題，應當一文一事，不應當在非請示公文中夾帶請示事項。
請示事項涉及其他部門業務范圍時，應當經過協商并取得一致意見后上報；經過協商未能取得一致意見時，應當在請示中寫明。除特殊情況外，請示應當送上級機關的辦公廳（室）按規定程序處理，不應直接送領導者個人。
黨委各部門應當向本級黨委請示問題。未經本級黨委同意或授權，不得越過本級黨委向上級黨委主管部門請示重大問題。
第十五條 對不符合行文規則的上報公文，上級機關的秘書部門可退回下級呈報機關。
第五章 公文起草
第十六條 起草公文應當做到：
?。ㄒ唬┓宵h的路線、方針、政策和國家的法律、法規及上級機關的指示，完整、準確地體現發文機關的意圖，并同現行有關公文相銜接。
?。ǘ┤?、準確地反映客觀實際情況，提出的政策、措施切實可行。
?。ㄈ┯^點明確，條理清晰，內容充實，結構嚴謹，表述準確。
?。ㄋ模╅_門見山，文字精練，用語準確，篇幅簡短，文風端正。
?。ㄎ濉橙嗣?、地名、時間、數字、引文準確。公文中漢字和標點符號的用法符合國家發布的標準方案，計量單位和數字用法符合國家主管部門的規定。
?。┪姆N、格式使用正確。
（七）杜絕形式主義和繁瑣哲學。
第十七條 起草重要公文應當由領導人親自動手或親自主持、指導，進行調查研究和充分論證，征求有關部門意見。
第六章 公文校對
第十八條 公文文稿送領導人審批之前，應當由辦公廳（室）進行校核。公文校校的基本任務是協助機關領導人保證公文的質量。公文校核的內容是：
?。ㄒ唬﹫笈绦蚴欠穹弦幎?；
?。ǘ┦欠翊_需行文；
（三）內容是否符合黨的路線、方針、政策和國家的法律、法規及上級機關的批示精神，是否完整、準確地體現發文機關的意圖，并同現行有關公文相銜接；
?。ㄋ模┥婕坝嘘P部門業務的事項是否經過協調并取得一致意見；
?。ㄎ澹┧岽胧┖娃k法是否切實可行；
?。┤嗣⒌孛r間、數字、引文和文字表述、密級、印發傳達范圍、主題詞是否準確、恰當，漢字、標點符號、計量單位、數字的用法及文種使用、公文格式是否符合本條例的規定。
第十九條 文稿如需作較大修改，應當與原起草部門協商或請其修改。
第二十條 已經領導人審批過的文稿，在印發之前應再作校核。校核的內容同第十條（六）款。經校核如需作涉及內容的實質性修改，須報原審批領導人復審。
第七章 公文簽發
第二十一條 公文須經本機關領導人審批簽發。重要公文應當由機關主要領導人簽發。聯合發文，須經所有聯署機關的領導人會簽。黨委辦公廳（室）根據黨委授權發布的公文，由被授權者簽發或者按照有關規定簽發。領導人簽發公文，應當明確簽署意見，并寫上姓名和時間。若圈閱，則視為同意。
第八章 公文辦理和傳遞
第二十二條 公文辦理分為收文和發文辦理。收文辦理包括公文的簽收、登記、擬辦、請辦、分發、傳閱、承辦和催辦等程序。公文經起草、校核和領導審批簽發后轉入發文辦理，發文辦理包括公文的核發、登記、印制和分發等程序。
?。ㄒ唬┖炇帐盏接嘘P公文并以簽字或蓋章的方式給發文方以憑據。簽收公文應當逐件清點，如發現問題，應當及時向發文機關查詢，并采取相應的處理措施。急件應當注明簽收的具體時間。
?。ǘ┑怯浌霓k理過程中就公文的特征和辦理情況進行記載。登記應當將公文標題、密級、發文字號、發文機關、成文日期、主送機關、份數、收發文日期及辦理情況逐項填寫清楚。
?。ㄋ模M辦秘書部門對需要辦理的公文提出辦理意見，并提供必要的背景材料，送領導人批示。
?。ㄎ澹┓职l秘書部門根據有關規定或者領導人批示將公文分送有關領導人和部門。
（六）傳閱秘書部門根據領導人批示或者授權，按照一定的程序將公文送有關領導人閱知或者批示。辦理公文傳閱應當隨時掌握公文去向，避免漏傳、誤傳和延誤。
（七）承辦主管部門對需要辦理的公文進行辦理。凡屬承辦部門職權范圍內可以答復的事項，承辦部門應當直接答復呈文機關；凡涉及其他部門業務范圍的事項，承辦部門應當主動與有關部門協商辦理；凡須報請上級機關審批的事項，承辦部門應當提出處理意見并代文稿，一并送請上級機關審批。
（八）催辦秘書部門對公文的承辦情況進行督促檢查。催辦貫穿于公文處理的各個五一節。對緊急或者重要公文應當及時催辦，對一般公文應當定期催辦，并隨時或者定期反饋辦理情況。
?。ň牛┖税l秘書部門在公文正式印發前，對公文的審批手續、文種、格式等進行復核，確定發文字號、分送單位和印制份數。
?。ㄊ┯≈茟斪龅綔蚀_、及時、規范、安全、保密。秘密公文應當由機要印刷廠（或一般印刷廠的保密車間）印制。
第二十三條 公文處理過程中，應當使用符合存檔要求的書寫材料。需要送請領導人閱批的傳真件，應當復制后辦理。
第二十四條 秘密公文應當通過機要交通（或機要通信）傳遞、密電傳輸或者計算機網絡加密傳輸，不得密電明傳、明電密電混用。
第九章 公文管理
第二十五條 黨的機關公文應當發給組織，由秘書部門統一管理，一般不發給予個人。秘書部門應當切實做好公文的管理工作，既發揮公文效用，又有利于公文保密。
第二十六條 黨的機關秘密公文的印發傳達范圍應當按照發文機關的要求執行，下級機關、不相隸屬機關如需變更，須經發文機關批準。
第二十七條 公開發布黨的機關公文，須經發文機關批準。經批準公開發布的公文，同發文機關正式印發的公文具有同等效力。
第二十八條 復制上級黨的機關的秘密公文，須經發文機關批準或者授權。翻印件應當注明翻印機關名稱、翻印日期和份數；復印件應當加蓋復印機關印記。復制的公文應當與正式印發的公文同樣管理。
第二十九條 匯編上級黨的機關的秘密公文，須經發文機關批準或者授權。公文匯編本的密級按照編入公文的最高密級標注并進行管理。
第三十條 絕密級公文應當由秘書部門指定專人管理，并采取嚴格的保密措施。
第三十一條 秘書部門應當按照規定對秘密公文進行清理、清退和銷毀，并向主管機關報告公文管理情況。
銷毀秘密公文，必須嚴格履行登記手續，經主管領導人批準后，由二人監銷，保證不丟失、不漏銷。個人不得擅自銷毀公文。
第三十二條 機關合并時，全部公文應當隨之合并管理。機關撤銷時，需要歸檔的公文立卷后按照有關規定移交檔案部門，其他公文按照有關規定登記銷毀。工作人員調離工作崗位時，應當將本人保管、借用的公文按照有關規定移交、清退。
第十章 公文立卷歸檔
第三十三條 公文辦理完畢后，秘書部門應當按照有關規定將公文的定稿、正本和有關材料收集齊全，進行立卷歸檔。個人不得保存應當歸檔的公文。
第三十四條 兩個以上機關聯合辦理的公文，原件由主辦機關立卷歸檔，相關機關保存復制件。機關領導人兼任其他機關職務的，在履行其所兼職務過程中形成的公文，由其兼職的機關立卷歸檔。
第十一章 公文保密
第三十五條 公文處理必須嚴格遵守《中華人民共和國保守國家秘密法》及有關保安法規，遵守黨的保密紀律，確保黨和國家秘密的安全。
第三十六條 黨內秘密公文的密級按其內容及如泄露可能對黨和國家利益造成危害的程度劃分為“絕密”、“機密”、“秘密”。不公開發表又未標準密級的公文，按內部公文管理。
第三十七條 發文機關在擬制公文明，應當根據公文的內容和工作需要，嚴格劃分密與非密的界限；對于需要保密的公文，要準確標注其密級。公文密級的變更和解除由發文機關或其上級機關決定。
第十二章 附 則
第三十八條 本條例適用于中國共 產黨各級機關。
第三十九條 本條例由中共中央辦公廳負責解釋。
第四十條 本條例自發布之日起施行。
]]>
中華人民共和國檔案法
（1987 年 9 月 5 日第六屆全國人民代表大會常務委員會第二十二次會議通過） （根據 1996 年 7 月 5 日第八屆全國人民代表大會常務委員會第二十次會議《關于修改〈中華人民共和國檔案法〉的決定》修正）
第一章 總 則第一章 總 則
第二章 檔案機構及其職責
第三章 檔案的管理
第四章 檔案的利用和公布
第五章 法律責任
第六章 附 則
附 件
第一條 為了加強對檔案的管理和收集、整理工作，有效地保護和利用檔案，為社會主義現代化建設服務，制定本法。
第二條 本法所稱的檔案，是指過去和現在的國家機構、社會組織以及個人從事政治、軍事、經濟、科學、技術、文化、宗教等活動直接形成的對國家和社會有保存價值的各種文字、圖表、聲像等不同形式的歷史記錄。
第三條 一切國家機關、武裝力量、政黨、社會團體、企業事業單位和公民都有保護檔案的義務。
第四條 各級人民政府應當加強對檔案工作的領導，把檔案事業的建設列入國民經濟和社會發展計劃。
第五條 檔案工作實行統一領導、分級管理的原則，維護檔案完整與安全，便于社會各方面的利用。
第二章 檔案機構及其職責
第六條 國家檔案行政管理部門主管全國檔案事業，對全國的檔案事業實行統籌規劃，組織協調，統一制度，監督和指導。
縣級以上地方各級人民政府的檔案行政管理部門主管本行政區域內的檔案事業，并對本行政區域內機關、團體、企業事業單位和其他組織的檔案工作實行監督和指導。
鄉、民族鄉、鎮人民政府應當指定人員負責保管本機關的檔案，并對所屬單位的檔案工作實行監督和指導。
第七條 機關、團體、企業事業單位和其他組織的檔案機構或者檔案工作人員，負責保管本單位的檔案，并對所屬機構的檔案工作實行監督和指導。
第八條 中央和縣級以上地方各級各類檔案館，是集中管理檔案的文化事業機構，負責接收、收集、整理、保管和提供利用各分管范圍內的檔案。
第九條 檔案工作人員應當忠于職守，遵守紀律，具備專業知識。
在檔案的收集、整理、保護和提供利用等方面成績顯著的單位或者個人，由各級人民政府給予獎勵。
第三章 檔案的管理
第十條 對國家規定的應當立卷歸檔的材料，必須按照規定，定期向本單位檔案機構或者檔案工作人員移交，集中管理，任何個人不得據為己有。
國家規定不得歸檔的材料，禁止擅自歸檔。
第十一條 機關、團體、企業事業單位和其他組織必須按照國家規定，定期向檔案館移交檔案。
第十二條 博物館、圖書館、紀念館等單位保存的文物、圖書資料同時是檔案的，可以按照法律和行政法規的規定，由上述單位自行管理。
檔案館與上述單位應當在檔案的利用方面互相協作。
第十三條 各級各類檔案館，機關、團體、企業事業單位和其他組織的檔案機構，應當建立科學的管理制度，便于對檔案的利用；配置必要的設施，確保檔案的安全；采用先進技術，實現檔案管理的現代化。
第十四條 保密檔案的管理和利用，密級的變更和解密，必須按照國家有關保密的法律和行政法規的規定辦理。
第十五條 鑒定檔案保存價值的原則、保管期限的標準以及銷毀檔案的程序和辦法，由國家檔案行政管理部門制定。禁止擅自銷毀檔案。
第十六條 集體所有的和個人所有的對國家和社會具有保存價值的或者應當保密的檔案，檔案所有者應當妥善保管。對于保管條件惡劣或者其他原因被認為可能導致檔案嚴重損毀和不安全的，國家檔案行政管理部門有權采取代為保管等確保檔案完整和安全的措施；必要時，可以收購或者征購。
前款所列檔案，檔案所有者可以向國家檔案館寄存或者出賣；向國家檔案館以外的任何單位或者個人出賣的，應當按照有關規定由縣級以上人民政府檔案行政管理部門批準。嚴禁倒賣牟利，嚴禁賣給或者贈送給外國人。
向國家捐贈檔案的，檔案館應當予以獎勵。
第十七條 禁止出賣屬于國家所有的檔案。
國有企業事業單位資產轉讓時，轉讓有關檔案的具體辦法由國家檔案行政管理部門制定。
檔案復制件的交換、轉讓和出賣，按照國家規定辦理。
第十八條 屬于國家所有的檔案和本法第十六條規定的檔案以及這些檔案的復制件，禁止私自攜運出境。
第四章 檔案的利用和公布
第十九條 國家檔案館保管的檔案，一般應當自形成之日起滿三十年向社會開放。經濟、科學、技術、文化等類檔案向社會開放的期限，可以少于三十年，涉及國家安全或者重大利益以及其他到期不宜開放的檔案向社會開放的期限，可以多于三十年，具體期限由國家檔案行政管理部門制訂，報國務院批準施行。
檔案館應當定期公布開放檔案的目錄，并為檔案的利用創造條件，簡化手續，提供方便。
中華人民共和國公民和組織持有合法證明，可以利用已經開放的檔案。
第二十條 機關、團體、企業事業單位和其他組織以及公民根據經濟建設、國防建設、教學科研和其他各項工作的需要，可以按照有關規定，利用檔案館未開放的檔案以及有關機關、團體、企業事業單位和其他組織保存的檔案。
利用未開放檔案的辦法，由國家檔案行政管理部門和有關主管部門規定。
第二十一條 向檔案館移交、捐贈、寄存檔案的單位和個人，對其檔案享有優先利用權，并可對其檔案中不宜向社會開放的部分提出限制利用的意見，檔案館應當維護他們的合法權益。
第二十二條 屬于國家所有的檔案，由國家授權的檔案館或者有關機關公布；未經檔案館或者有關機關同意，任何組織和個人無權公布。
集體所有的和個人所有的檔案，檔案的所有者有權公布，但必須遵守國家有關規定，不得損害國家安全和利益，不得侵犯他人的合法權益。
第二十三條 各級各類檔案館應當配備研究人員，加強對檔案的研究整理，有計劃地組織編輯出版檔案材料，在不同范圍內發行。
第五章 法律責任
第二十四條 有下列行為之一的，由縣級以上人民政府檔案行政管理部門、有關主管部門對直接負責的主管人員或者其他直接責任人員依法給予行政處分；構成犯罪的，依法追究刑事責任：
?。ㄒ唬p毀、丟失屬于國家所有的檔案的；
?。ǘ┥米蕴峁?、抄錄、公布、銷毀屬于國家所有的檔案的；
?。ㄈ┩扛摹卧鞕n案的；
?。ㄋ模┻`反本法第十六條、第十七條規定，擅自出賣或者轉讓檔案的；
（五）倒賣檔案牟利或者將檔案賣給、贈送給外國人的；
（六）違反本法第十條、第十一條規定，不按規定歸檔或者不按期移交檔案的；
?。ㄆ撸┟髦４娴臋n案面臨危險而不采取措施，造成檔案損失的；
?。ò耍n案工作人員玩忽職守，造成檔案損失的。
在利用檔案館的檔案中，有前款第一項、第二項、第三項違法行為的，由縣級以上人民政府檔案行政管理部門給予警告，可以并處罰款；造成損失的，責令賠償損失。
企業事業組織或者個人有第一款第四項、第五項違法行為的，由縣級以上人民政府檔案行政管理部門給予警告，可以并處罰款；有違法所得的，沒收違法所得；并可以依照本法第十六條的規定征購所出賣或者贈送的檔案。
第二十五條 攜運禁止出境的檔案或者其復制件出境的，由海關予以沒收，可以并處罰款；并將沒收的檔案或者其復制件移交檔案行政管理部門；構成犯罪的，依法追究刑事責任。
第六章 附 則
第二十六條 本法實施辦法，由國家檔案行政管理部門制定，報國務院批準后施行。
第二十七條 本法自 1988 年 1 月 1 日起施行。
附 件
全國人民代表大會常務委員會關于修改《中華人民共和國檔案法》的決定
（1996 年 7 月 5 日第八屆全國人民代表大會常務委員會第二十次會議通過） （1996 年 7 月 5 日中華人民共和國主席令第 71 號公布，自公布之日起施行）
第八屆全國人民代表大會常務委員會第二十次會議決定對《中華人民共和國檔案法》作如下修改：
一、第十六條第二款修改為：“前款所列檔案，檔案所有者可以向國家檔案館寄存或者出賣；向國家檔案館以外的任何單位或者個人出賣的，應當按照有關規定由縣級以上人民政府檔案行政管理部門批準。嚴禁倒賣牟利，嚴禁賣給或者贈送給外國人。”
二、第十七條增加一款作為第二款：“國有企業事業單位資產轉讓時，轉讓有關檔案的具體辦法由國家檔案行政管理部門制定。”
三、第十九條第二款修改為：“檔案館應當定期公布開放檔案的目錄，并為檔案的利用創造條件，簡化手續，提供方便。”
四、第二十四條修改為：“有下列行為之一的，由縣級以上人民政府檔案行政管理部門、有關主管部門對直接負責的主管人員或者其他直接責任人員依法給予行政處分；構成犯罪的，依法追究刑事責任：
?。ㄒ唬p毀、丟失屬于國家所有的檔案的；
（二）擅自提供、抄錄、公布、銷毀屬于國家所有的檔案的；
?。ㄈ┩扛?、偽造檔案的；
?。ㄋ模┻`反本法第十六條、第十七條規定，擅自出賣或者轉讓檔案的；
?。ㄎ澹┑官u檔案牟利或者將檔案賣給、贈送給外國人的；
（六）違反本法第十條、第十一條規定，不按規定歸檔或者不按期移交檔案的；
（七）明知所保存的檔案面臨危險而不采取措施，造成檔案損失的；
?。ò耍n案工作人員玩忽職守，造成檔案損失的。
在利用檔案館的檔案中，有前款第一項、第二項、第三項違法行為的，由縣級以上人民政府檔案行政管理部門給予警告，可以并處罰款；造成損失的，責令賠償損失。
企業事業組織或者個人有第一款第四項、第五項違法行為的，由縣級以上人民政府檔案行政管理部門給予警告，可以并處罰款；有違法所得的，沒收違法所得；并可以依照本法第十六條的規定征購所出賣或者贈送的檔案。”
五、增加一條作為第二十五條：“攜運禁止出境的檔案或者其復制件出境的，由海關予以沒收，可以并處罰款；并將沒收的檔案或者其復制件移交檔案行政管理部門；構成犯罪的，依法追究刑事責任。”
本決定自公布之日起施行。
《中華人民共和國檔案法》根據本決定作相應的修正，重新公布。
]]>
公文知識點
1 公文的概念1 公文的概念
2 公文的分類
3 通用公文的類型
4 公文文種
5 公文的作用
6 公文的文面格式
7 公文的撰寫
公文，公務文書，機關應用文。
黨政機關、團體、企事業單位在管理過程中形成，按照規定程序辦理并在法定范圍內使用，具有法律效力，是規范體式的文書。
是實施領導和管理，進行公務活動的重要工具。
2 公文的分類
2.1 按形成和使用的公務活動領域劃分
通用公文：各級各類機關、團體、企事業單位在公務活動中普遍使用的公文。
專用公文：專門業務機關、部門、組織在業務工作范圍內，因特殊需要專門使用的行業、專業、部門公文（外交文件、司法文件、軍事公文、審計文件等）。
2.2 按公文的來源劃分
對外文件：發文，指本單位向外單位發出的文件。
收來文件：收文，指由外單位發送來本單位的文件。
內部文件：限于單位內部制發、運行和使用的文件。
2.3 按公文的行文關系和行文方向劃分
上行文：下級機關、單位向隸屬的上級領導機關和單位報送的公文。
平行文：同級或不相隸屬的機關單位之間的行文。
下行文：上級領導機關單位對所屬的下級機關單位的行文。
2.4 按公文的秘密程度和閱讀范圍劃分
絕密文件：內容涉及國家核心秘密，一旦泄漏會使國家的安全和利益遭受重大損害的公文。
機密文件：內容涉及國家重要秘密，一旦泄漏會使國家的安全和利益遭受嚴重損害的公文。
秘密文件：內容涉及國家一般秘密，一旦泄漏會使國家的安全和利益遭受一定損害的公文。
內部文件：內容不涉及秘密，但不宜或不必對社會公開，只限在國內某系統、某部門內部使用的公文。
限國內公開的文件：內容不涉及秘密，但不宜或不必對國外公布，而只在國內公開發布的公文。
對外公開的文件：內容不涉及任何秘密，可直接對國內外公布的公文。
2.5 按公文處理時限的要求劃分
特急件：內容至關重要并特殊緊急，已臨近規定的辦結時限，需隨時隨地優先迅速傳遞處理的公文。
急件（黨的機關公文作加急件）：內容重要并緊急，需打破工作常規優先迅速傳遞處理的公文。
平件：無特殊時間要求，按工作常規依次傳遞處理的公文（電報：特提件、特急件、加急件、平急件等）。
2.6 按收文機關對收到公文的處理方式劃分
閱件：閱知性公文，按規定交有關部門、有關人員閱知的公文。
辦件：承辦性公文，交有關部門、有關人員及時辦理、答復、貫徹執行的收文。
2.7 從物質載體的角度劃分
紙質文件：用紙張印制、書寫的文件。
感光介質文件：以感光膠片、像紙等感光材料為物質載體的文件（照片文件、影片文件、縮微膠片文件、顯微膠片文件等）。
磁介質文件：以磁帶、磁盤、磁鼓等磁性材料為物質載體的文件（錄音文件、錄像文件、計算機磁帶文件和磁盤文件以及磁光盤文件等）。
電子文件：借助電子計算機生成、傳輸和處理的文件，它們的制作方式、處理方法和保管要求均各部相同。
2.8 按公文性質和作用劃分
在通用公文和專用公文的不同范疇內，都可有不同的類型。
3 通用公文的類型
從管理工作的性質和公務活動的內容相結合的角度劃分通用公文的類型。
3.1 黨政機關主要公文
機關公文、法定公文、正式公文。
《中國共 產黨機關公文處理條例》和《國家行政機關公文處理辦法》規定的黨的各級機關、國家行政機關正式文件常用的主要文種。
企事業單位、人民團體也常酌情比照適用。
黨的各級領導機關常用主要公文有 14 種，國家行政機關常用主要公文有 13 種。
3.1.1 領導指導性公文
命令（令）：用于依照有關法律發布行政法規和規章，宣布施行重大強制性行政措施，嘉獎有關單位及人員。法定的國家機關，才有權在規定的權限和范圍內，依法發布命令（黨的各級機關通用公文無此文種）。
指示：用于對下級機關布置工作，提出開展工作的原則和要求（國家行政機關常用主要公文無此文種）。
決定：用于對重要事項或者重大行動作出安排及決策，獎懲有關單位及人員，變更或者撤銷下級機關不適當的決定事項。
決議：用于發布經會議討論通過并要求貫徹執行的重要決策事項（國家行政機關不用此文種）。
通知：用于批轉下級機關的公文，轉發上級機關、平行機關和不相隸屬機關的公文，傳達要求下級機關辦理和需要有關單位周知或者執行的事項，任免人員。
通報：用于表彰先進，批評錯誤，傳達重要精神或者情況。
批復：用于答復下級機關請示事項。
會議紀要：用于記載和傳達會議情況、主要精神和議定事項。
?。l例、規定，系黨的各級機關通用公文，當屬此類。但從國家行政機關的行文規范和從寫作規律看，將其列入法規和規章文體為宜）
3.1.2 呈報性公文
議案：用于各級人民政府（或者法定人數的人民代表）按照法律程序向同級人民代表大會或人民代表大會常務委員會提請審議事項（黨的各級領導機關不用此文種）。
請示：用于向上級機關請求指示、批準。
報告：用于向上級機關匯報工作，反映情況，答復上級機關的詢問。
3.1.3 公布性公文
公告：用于向國內外宣布重要事項或者法定事項（黨的各級領導機關主要通用公文無此文種）。
通告：用于公布社會各有關方面應當遵守或者周知的事項（黨的各級領導機關主要通用公文無此文種）。
公報：用于公開發布重要決定或者重大事件。
3.1.4 商洽性公文
函：用于不相隸屬機關之間商洽工作，詢問和答復問題，向有關主管部門請求批準和答復審批事項。
3.1.5 兼容性公文
意見：行政機關用于對重要問題提出見解和處理方法（黨的機關使用意見就是下行文了）。
3.2 行政法規、規章和管理規章
條例：用于對某一方面的行政工作作出比較全面、系統的規定的法規。國務院各部門和地方人民政府制定的規章不得用條例（但黨的中央組織制定規范黨組織的工作、活動和黨員行為的黨規，用條例），也不能用于管理規章。
規定：用于對某一方面的行政工作和事務制定出帶有約束性的措施和部分的規定，既可用于法規、規章，又可用于管理規章。
辦法：用于對某一項行政工作作出比較具體的、可操作性的規定。既可用于法規、規章，又可用于管理規章。
章程：管理規章的一種，用以規定以個組織或團體的性質、宗旨、任務、組織結構、組織成員及其權利義務、活動規則等事項。
守則：管理規章的一種，用于在一定范圍內對有關人員作出行為準則、道德規范。
規則：管理規章的一種，用于在一定范圍內某項工作或活動作出行為規范。
準則：管理規章的一種，用于在一定范圍內對組織的成員，或者限定的有關人員作出的行為規范。
細則：規章、管理規章的一種，用于具體執行實施有關法律、法規和行政規章而制定的一種解釋性、操作性的規章。
規范：管理規章的一種，用于對某項工作質量標準、質量要求作出的規定。
規程：管理規章的一種，用于對某項工作、某項活動的操作過程、實施辦法作出的有序的規定。
制度：管理規章的一種，用于對某項具體工作、具體事項制定出一些切實可行而又必須遵守和執行的紀律、規定。
公約：管理規章的一種，某一組織、群體為了做好某一工作，正常開展某項活動或維護正常的工作、生產、學習、生活秩序，經過商量確定的、必須共同遵守的行為規則。
3.3 會議文書
開幕詞與閉幕詞：有關領導人在莊重、嚴肅的大型會議開幕時和閉幕時的短篇講話稿。
會議工作報告：主要領導人在代表會議、工作會議上代表領導機構所作的，說明成績和經驗、問題和教訓，介紹形勢與工作情況，提出任務與措施的全面性報告。
專題講話：有關領導人在會議上圍繞形勢與任務，就某方面工作、某一專門問題所作的指導性講話。
提案：與會代表按規定向某些重要會議提出并提請大會討論或處理的書面意見和建議。多用于各級政協會議。
會議記錄：當場記錄會議的基本情況，即會議組織情況、會上的報告、講話、發言以及會上討論的問題、議定的事項等內容的書面材料。
3.4 計劃、決策與反饋文書
可行性分析（研究）報告：領導機關、部門、單位對某項工作作出重大決策前，對決策方案進行比較、分析等可行性論證，根據論證結果寫出的報告。
計劃：機關、單位、團體預先對一定時期內的工作提出目標、要求、措施和安排的公文。通常說的安排、方案、設想、打算、要點、綱要、規劃等，都屬計劃。
總結：是對前一階段的工作回顧、檢查和分析研究，找出成績與問題、經驗與教訓，用以指導今后工作的一種公文。
答復：是各級政府辦公廳（室）及有關部門，對人大代表建議（批評和意見）、政協提案辦理之后，將辦理意見或處理結果直復提出建議、提案的有關人員和組織的公文。
3.5 公務信息文書
調查報告：對客觀事物調查研究后寫成的反映調查結果的公文。
簡報：機關、單位、團體用來反映情況、傳遞信息、交流經驗的一種公文。
信息快報：及時反映公務活動運轉情況和社情民情，供領導和有關部門決策和指揮工作參考的一種短篇公文。
信訪摘報：信訪部門對群眾來信來訪內容摘要整理而成的報告。
信訪分析報告：信訪部門對一段時間內群眾來信來訪反映的問題，作出綜合分析研究而寫出的分析報告。
3.6 日常事務文書
黨政機關、單位、團體在處理機關日常具體事務時所使用的、格式很固定的公文。
3.6.1 公務書信
介紹信：用于證實單位有關工作人員的身份，介紹其工作使命，憑此與其他單位接洽工作的一種證明性函件。
證明信：用于證明有關人員身份或有關事情真相的一種證明性函件。
公開信：機關、單位、團體就某項重要工作或某個重大問題，向一定范圍的有關人員公開發布的書信。
倡議書：機關、單位、團體或會議、或某一群體就人們所共同關心的事情，向社會或有關方面首先提出的帶有號召性建議的一種專用書信。
慰問信：機關、單位、團體或群體向有關方面、有關人員表示安慰和問候的一種專用書信。
感謝信：機關、單位、團體或群體向有關方面、有關人員表示感謝的一種專用書信。
賀信：向取得成績或遇上喜事的有關方面、有關人員表示慶賀的一種專用書信。
邀請書（請柬）：在舉行某項活動、開展某項工作、召開某個重要會議時，向有關單位、有關人員發出邀請而使用的一種專用書信。
聘請書：機關、單位、團體招聘、聘任某些專門人員所使用的一種專用書信。
3.6.2 告啟文書
啟事：機關、單位、團體需要公開向大家說明某項事情或者希望公眾協助辦理某件事情而使用的文書。
海報：機關、單位、團體向公眾公布有關文藝、體育、科技、學術、展覽等方面活動消息的文書。
聲明：國家、政府、政黨、團體、機關或有關人員對重大事件和問題表明立場、態度、主張而發表的一種文書。
廣告：有關單位通過一定的輿論媒介，進行有關商品或勞務智力服務的公開宣傳、傳遞市場信息的文書。也屬經濟文書的一種。
公示：機關、單位、團體領導機構，需作出涉及某項決策、人事任免、組織處理或安排等重要事項的決定，在事前征求一定范圍公眾意見的一種周知性公文。
3.6.3 條據
單位之間、單位與個人之間，在收、領、借錢財物品時所寫的憑據（收條、領條、借條、欠條等）。
3.6.4 大事記
按時間順序連續記載某個機關、單位在一定時期的重要工作、重大事件、重要活動的書面材料。
3.6.5 喪事禮儀文書
訃告：機關、單位、團體把某人不幸去世的消息告知親屬好友和有關方面的一種文書。
唁函（電）：機關、單位、團體向死者家屬或死者所在單位發出的、向死者表示哀悼、向其家屬或所在單位表示慰問的專用書信（電報）。
悼詞：領導人代表機關、單位、團體在追悼會上對死者表示悼念與哀思的致詞。
?。ㄗ⒁猓喝粘Ｊ聞瘴臅牟簧傥姆N（啟事、條據、訃告等），具有兼容性，當用于私人時則不屬公文而是私人文書了。）
4 公文文種
4.1 文種的含義
把性質和用途相同的公文歸為一種，并規定一個固定名稱，即公文種類，簡稱文種。
文種是公文必不可少的組成部分，所有公文都必須在標題中標明文種。
4.2 正確標明文種的作用
有利于維護公文的嚴肅性、規范性。
為公文撰寫提供方便。
為公文處理提供方便。
撰寫公文時，務必正確選用文種。不用、錯用或生造文種，都會損害公文的效用。
4.3 選擇文種的依據
要依據國家的有關法律、法規以及黨和國家有關領導機關關于公文處理的有關規定，選擇恰當的、規范的文種。絕不能違反有關法規、規定和標準，隨意另選文種。
要看作者與主要受文者（即主送機關單位）的工作關系（上行文種、下行文種、平行文種）。
要看作者權限。
要看行文目的、行文要求的需要。
4.4 正確區分一些易混淆的文種
能否正確選用文種，直接關系到公文質量的高低、表達效果的好壞和公文處理的方便與否。
4.4.1 決定與決議
都是帶有制約、規范、指揮或指導作用的指揮性公文，在性質、寫法上都有許多相似之處。寫法上，一般都不在正文前些主送機關，而是在文尾抄送欄標明主送或者分送單位。正文都由行文依據、行文事項和結語三部分構成，都可視內容多少寫為篇段合一式、多段式、總分條文式和分部式結構。
顯著區別：成文過程不同；發文機關（組織）不同；涉及內容不同；作用不同；寫作格式上簽注和落款不同。
4.4.2 公告與通告
都是周知性公文，內容都不涉及秘密，都要公開發布，登報、張貼、通過電視播出或廣播，寫法也相似。
顯著區別：內容適用范圍不同；制發單位不同；發送對象不同；作用不同。
特別注意不能濫用公告。
4.4.3 請示與報告
都是上行文。
顯著區別：行文目的、作用不同；呈報時間不同；主送機關不同；受文機關處理方式不同；涉及內容不同；寫作側重點不同。
4.4.4 請示與函（請求批準函）
這里的函專指用于向有關主管部門請求批準的函。
都可用于請求批準。
顯著區別：類型不同；主送機關不同；內容范圍不同；受文機關復文方式不同。
4.4.5 批復與函（審批函）
這里的函專指有關主管部門發出的審批函。
都可用于審批有關事項。
顯著區別：類型不同；主送機關不同；內容范圍不同。
4.4.6 規劃與計劃
都屬計劃類文種。
顯著區別：規劃是時間較長、范圍較廣、內容比較概括的長遠計劃，常常是對工作方向、目標提出提綱式、原則性的計劃；計劃則可用于各種情況、各種場合，時間角度上區分，年度內常用計劃，機關單位層級區分，基層單位常用計劃，計劃的內容更具體，通常包括目標任務、工作措施、步驟時間、督促檢查。
4.4.7 法規、規章與管理規章（規章制度）
盡管在寫作上有一些共同特點，但它們畢竟是外部結構相似而性質極不相同的兩類公文。
顯著區別：效用不同；作者的限定范圍不同；制發程序不同；文種不同。
5 公文的作用
明法傳令，指揮工作；
聯系公務，溝通信息；
宣傳教育，引導輿論；
記錄記載，以為憑據。
6 公文的文面格式
指公文正式文本的印制規格樣式。
極強的程式性、規范性，有利于公文的寫作和處理。
6.1 公文文面格式的類型
公文式文面格式。
專業規范文本式文面格式。
一般文章文面格式。
6.2 規范的公文文面格式的作用
保證公文的完整、正確、莊重，是公文權威性、有效性的具體表現形式。
可以為公文的撰寫、處理、運用、立卷歸案提供方便，有利于提高辦文效率，進而提高工作效率和質量。
可為辦公自動化奠定基礎。
6.3 公文文面格式的特點
具有規范性和確定性。
7 公文的撰寫
7.1 公文撰寫的基本要求
符合黨的路線、方針、政策和國家法律、法規及上級有關規定；準確、完整地體現發文單位的意圖；全面、真實地反映本地區、本部門的實際情況；提出問題準確，分析問題實事求是；解決問題的政策、措施切實可行。
主旨突出，觀點鮮明，內容充實，條理清晰，結構嚴謹，表達準確，語言精煉，篇幅簡短，文風端正。
得體合規，符合公文特定的體式要求：行文關系、文種、格式符合規范；表述宜用直筆，忌用曲筆，應露而不藏，直言不諱；行文語氣得體；堅持一文一事。
公文的語言需要做到：明晰，準確，簡樸，莊重。
7.2 公文撰寫的具體要求
7.2.1 突出主旨
正確使用標題：公文式標題、四項式標題、新聞式標題。
顯示主旨句：題目明旨，開門見山，篇末點題，片言居要，一線貫通。
7.2.2 強化觀點
明白顯示、準確表達觀點。
用好小標題：層首句、段首句、條首句。
注意強調觀點：層前總提語；層后總括語；文中強調語。
7.2.3 充實材料
事實材料：人物、事件、工作情況、現象、細節、數據圖表等。
理論材料：經典著作、領導講話文稿、文件、報刊重要社論及重要理論文章。
材料處理（不違背事實真相、不改變事情原意、不損害事物本來面目）：概括材料，以少勝多；濃縮材料，去粗取精；截取材料，去繁就簡。
材料表現力、說服力：點面材料、對比材料、正反材料、現實材料和歷史材料、定性材料和定量材料。
材料安排：先亮觀點，后舉材料；先列材料，后擺觀點；邊列材料邊擺觀點。
7.2.4 安排結構
7.2.4.1 公文安排結構的要求
圍繞主旨安排結構。
層次清楚、思路清晰。
完整、嚴謹、合理。
7.2.4.2 公文結構的基本內容
標題。
開頭：概述情況；說明根據；介紹目的；交代原因；闡明觀點；表明態度；提出問題；慰問祝賀；引述來文；列序號。
結尾：收篇點題；提出希望、號召、意見、建議；強調說明；表示祝賀、慰問；自然作結。
層次：序號、小標題、層首句等。
段落：最小單位、自然段、小于層次、明顯換行標志。
過渡：詞語過渡、句子過渡、段落過渡、自然過渡。
照應：題文照應、首尾照應、前后照應。
7.2.4.3 結構的基本形式
橫向組合結構：簡單列舉式；總分條文式。
縱向組合結構：直敘式；遞進式。
縱橫交叉結構。
]]>
中華人民共和國國家標準
國家行政機關公文格式
GB/T 9704-1999 代替 GB/ 9704-1988 Layout key for official document of administration
前 言前 言
1 范圍
2 引用標準
3 定義
4 公文用紙主要技術指標
5 公文用紙幅面及版面尺寸
6 公文中圖文的顏色
7 排版規格與印制裝訂要求
8 公文中各要素標識規則
9 頁碼
10 公文中表格
11 公文的特定格式
12 式樣
本標準根據國務院辦公廳發布的《國家行政機關公文處理辦法》的有關規定對 GB/T 9704－1988 進行修訂。本標準相對 GB/T 9704－1988 作如下修訂：
?。?）將原標準名稱《國家機關公文格式》改為《國家行政機關公文格式》；
?。?）刪去原標準中的引言部分；
?。?）刪去原標準中與公文格式規定無關的一些敘述性解釋；
（4）對公文用紙的幅面尺寸作了較大調整，將國際標準 A4 型紙作為用紙紙型；刪去國內 16 開型紙張的相應說明；
（5）對公文用紙的頁邊尺寸作了較大的調整；
?。?）不設各標識域，而按公文眉首、主體和版記三部分各要素的順序依次進行說明；
?。?）增加了公文用紙的主要技術指標；
（8）增加了印刷和裝訂要求；
?。?）增加了每頁正文行數和每行字數以及各種要素標識的字體和字號；
（10）增加了主要公文式樣。
本標準中所用公文用語與《國家行政機關公文處理辦法》中的用語一致。
本標準為第一次修訂。
本標準由國務院辦公廳提出。
本標準起草單位：中國標準研究中心、國務院辦公廳秘書局。
本標準主要起草人：孟辛卯、房慶、李志祥、劉碧松、范一喬、張榮靜、李穎。
1 范圍
本標準規定了國家行政機關公文通用的紙張要求、印刷要求、公文中各要素排列順序和標識規則。
本標準適用于國家各級行政機關制發的公文。其他機關公文可參照執行。
使用少數民族文字印制的公文，其格式可參照本標準按有關規定執行。
2 引用標準
下列標準所包含的條文，通過在本標準中引用而構成為本標準的條文。本標準出版時，所示版本均為有效。所有標準都會被修訂，使用本標準的各方應探討使用下列標準最新版本的可能性。
（GB 148－1977 印刷、書寫和繪圖紙幅面尺寸）
3 定義
本標準采用下列定義。
3.1 字 Word
標識公文中橫向距離的長度單位。一個字指一個漢字所占空間。
3.2 行 line
標識公文中縱向距離的長度單位。本標準以 3 號字高度加 3 號字高度 7/8 倍的距離為一基準行。
4 公文用紙主要技術指標
公文用紙一般使用紙張定量為 60g/m2~80g/m2 的膠版印刷紙或復印紙。紙張白度為 85％~90％，橫向耐折度≥ 15 次，不透明度≥ 85％，pH 值為 7.5~9.5。
5 公文用紙幅面及版面尺寸
5.1 公文用紙幅面尺寸
公文用紙采用 GB/T 148 中規定的 A4 型紙，其成品幅面尺寸為：210mm×297mm，尺寸的允許偏差見 GB/T 148。
5.2 公文頁邊與版心尺寸
公文用紙天頭（上白邊）為：37mm±1mm
公文用紙訂口（左白邊）為：28mm±1mm
版心尺寸為：156mm×225mm（不含頁碼）
6 公文中圖文的顏色
未作特殊說明公文中圖文的顏色均為黑色。
7 排版規格與印制裝訂要求
7.1 排版規格
正文用 3 號仿宋字，一般每面排 22 行，每行排 28 個字。
7.2 制版要求
版面干凈無底灰，字跡清楚無斷劃，尺寸標準，版心不斜，誤差不超過 1mm。
7.3 印刷要求
雙面印刷；頁碼套正，兩面誤差不得超過 2mm。黑色油墨應達到色譜所標 BL100%，紅色沒墨應達到色譜所標 Y80％，M80％。印品著墨實、均勻；字面不花、不白、無斷劃。
7.4 裝訂要求
公文應左側裝訂，不掉頁。包本公文的封面與書芯不脫落，后背平整、不空。兩頁頁碼之間誤差不超過 4mm。騎馬訂或平訂的訂位為兩釘釘鋸外訂眼距書芯上下各 1/4 處，允許誤差 ±4mm。平訂釘鋸與書脊間的距離為 3mm~5mm；無壞釘、漏釘、重釘，釘腳平伏牢固；后背不可散頁明訂。裁切成品尺寸誤差 ±1mm，四角成 90°，無毛茬或缺損。
8 公文中各要素標識規則
本標準將組成公文的各要素劃分為眉首、主體、版記三部分。置于公文首頁紅色反線（寬度同版心，即 156mm）以上的各要素統稱眉首；置于紅色反線（不含）以下至主題詞（不含）之間的各要素統稱主體；置于主題詞以下的各要素統稱版記。
8.1 眉首
8.1.1 公文份數序號
公文份數序號是將同一文稿印制若干份時每份公文的順序編號。如需標識公文份數序號，用阿拉伯數碼頂格標識在版心左上角第 1 行。
8.1.2 秘密等級和保密期限
如需標識秘密等級，用 3 號黑體字，頂格標識在版心右上角第 1 行，兩字之間空 1 字；如需同時標識秘密等級和保密期限，用 3 號黑體字，頂格標識在版心右上角第 1 行，秘密等級和保密期限之間用“★”隔開。
8.1.3 緊急程度
如需標識緊急程度，用 3 號黑體字，頂格標識在版心右上角第 1 行，兩字之間空 1 行；如需同時標識秘密等級與緊急程度，秘密等級頂格標識在版心右上角第 1 行，緊急程度頂格標識在版心右上角第 2 行。
8.1.4 發文機關標識
由發文機關全稱或規范化簡稱后面加“文件”組成；對一些特定的公文可只標識發文機關全稱或規范化簡稱。發文機關標識上邊緣至版心上邊緣為 25mm。對于上報的公文，發文機關標識上邊緣至版心上邊緣為 80mm。
發文機關標識推薦使用小標宋體字，用紅色標識。字號由發文機關以醒目美觀為原則酌定，但最大不能等于或大于 22mm×15mm。
聯合行文時應使主辦機關名稱在前，“文件”二字置于發文機關名稱右側，上下居中排布；如聯合行文機關過多，必須保證公文著頁顯示正文。
8.1.5 發文字號
發文字號由發文機關代字、年份和序號組成。發文機關標識下空2行，用3號仿宋體字，居中排布；年份、序號用阿拉伯數碼標識；年份應標全稱，用六角括號“〔 〕”括入；序號不編虛位（即 1 不編為 001），不加“第”字。
發文字號之下 4mm 處印一條與版心等寬的紅色反線。
8.1.6 簽發人
上報的公文需標識簽發人姓名，平行排列于發文字號右側。發文字號居左空 1 字，簽發人姓名居右空 1 字；簽發人用 3 號仿宋體字，簽發人后標全角冒號，冒號后用 3 號楷體字標識簽發人姓名。
如有多個簽發人，主辦單位簽發人姓名置于第 1 行，其他簽發人姓名從第 2 行起在主辦單位簽發人姓名之下按發文機關順序依次順排，下移紅色反線，應使發文字號與最后一個簽發人姓名處在同一行并使紅色反線與之的距離為 4mm。
8.2 主體
8.2.1 公文標題
紅色反線下空 2 行，用 2 號小標宋體字，可分一行或多行居中排布；回行時，要做到詞意完整，排列對稱，間距恰當。
8.2.2 主送機關
標題下空 1 行，左側頂格用 3 號仿宋體字標識，回行時仍頂格；最后一個主送機關名稱后標全角冒號。如主送機關名稱過多而使公文首頁不能顯示正文時，應將主送機關名稱移至版記中的主題詞之下、抄送之上，標識方法同抄送。
8.2.3 公文正文
主送機關名稱下一行，每自然段左空 2 字，回行頂格。數字、年份不能回行。
8.2.4 附件
公文如有附件，在正文下一行左空 2 字用 3 號仿宋體字標識“附件”，后標全角冒號和名稱。附件如有序號使用阿拉伯數碼（如“附件：1.×××××”）；附件名稱后不加標點符號。附件應與公文正文一起裝訂，并在附件左上角第 1 行頂格標識“附件”，有序號時標識序號；附件的序號和名稱前后標識應一致。如附件與公文正文不能一起裝訂，應在附件左上角第 1 行頂格標識公文的發文序號并在其后標識附件（或帶序號）。
8.2.5 成文時間
用漢字將年、月、日標全；“零”寫為“○”；成文時間的標識位置見 8.2.6。
8.2.6 公文生效標識
8.2.6.1 單一發文印章
單一機關制發的公文在落款處不署發文機關名稱，只標識成文時間。成文時間右空 4 字；加蓋印章應上距正文 2mm~4mm，端正、居中下壓成文時間，印章用紅色。
當印章下弧無文字時，采用下套方式，即僅以下弧壓在成文時間上；
當印章下弧有文字時，采用中套方式，即印章中心線壓在成文時間上。
8.2.6.2 聯合行文印章
當聯合行文需加蓋兩個印章時，應將成文時間拉開，左右各空 7 字；主辦機關印章在前；兩個印章均壓成文時間，印章用紅色。只能采用同種加蓋印章方式，以保證印章排列整齊。兩印章之間不相交或相切，相距不超過 3mm。
當聯合行文需加蓋 3 個以上印章時，為防止出現空白印章，應將各發文機關名稱（可用簡稱）排在發文時間和正文之間。主辦機關印章在前，每排最多排 3 個印章，兩端不得超出版心；最后一排如余一個或兩個印章，均居中排布；印章之間互不相交或相切，在最后一排印章之下右空 2 字標識成文時間。
8.2.6.3 特殊情況說明
當公文排版后所剩空白處不能容下印章位置時，應采取調整行距、字距的措施加以解決，務使印章與正文同處一面，不得采取標識“此頁無正文”的方法解決。
8.2.7 附注
公文如有附注，用 3 號仿宋體字，居左空 2 號字加圓括號標識在成文時間下一行。
8.3 版記
8.3.1 主題詞
“主題詞”用 3 號黑體字，居左頂格標識，后標全角冒號詞目用 3 號小標宋體字；詞目之間空 1 字。
8.3.2 抄送
公文如有抄送，在主題詞下一行；左空 1 字用 3 號仿宋體字標識“抄送”，后標全角冒號；回行時與冒號后的抄送機關對齊；在最后一個抄送機關后標句號。如主送機關移至主題詞之下，標識方法同抄送機關。
8.3.3 印發機關和印發時間
位于抄送機關之下（無抄送機關在主題詞之下）占 1 行位置；用 3 號仿宋體字。印發機關左空 1 字，印發時間右空 1 字。印發時間以公文付印的日期為準，用阿拉伯數碼標識。
8.3.4 版記中的反線
版記中各要素之下均加一條反線，寬度同版心。
8.3.5 版記的位置
版記應置于公文最的一頁，版記的最后一個要素置于最后一行。
9 頁碼
用 4 號半角白體阿拉伯數碼標識，置于版心下邊緣之下一行，數碼左右各放一條 4 號一字線，一字線距離版心下邊緣 7mm。單頁碼居右空 1 字，雙頁碼居左空 1 字?？瞻醉摵涂瞻醉撘院蟮捻摬粯俗R頁碼。
10 公文中表格
公文如需附表，對橫排 A4 紙型表格，應將頁碼放在橫表的左側，單頁碼置于表的左下角，雙頁碼置于表的左上角，單頁碼表頭在訂口一邊，雙頁碼表頭在切口一邊。
公文如需附 A3 紙型表格，且當最后一頁為 A3 紙型表格時，封三、封四（可放分送，不放頁碼）就為空白，將 A3 紙型表格貼在封三前，不應貼在文件最后一頁（封四）上。
11 公文的特定格式
11.1 信函式格式
發文機關名稱上邊緣距上頁邊的距離為 30mm，推薦用小標宋體字，字號由發文機關酌定；發文機關全稱下 4mm 處為一條武文線（上粗下細），距下頁邊 20mm 處為一條文武線（上細下粗），兩條線長均為 170mm。每行居中排 28 個字。發文機關名稱及雙線均印紅色。兩線之間各要素的標識方法從本標準相應要素說明。
11.2 命令格式
命令標識由發文機關名稱加“命令”或“令”組成，用紅色小標宋體字，字號由發文機關酌定。命令標識上邊緣距版心上邊緣 20mm，下邊緣空 2 行居中標識標識令號；令號下空 2 行標識正文；正文下一行右空 4 字標識簽發人簽名章，簽名章左空 2 字標識簽發人職務；聯合發布的命令或令的簽發人職務應標識全稱。在簽發人簽名章下一行右空 2 字標識成文時間。分送機關標識方法同抄送機關。其他要素從本標準相關要素說明。
11.3 會議紀要格式
會議紀要標識由“×××××會議紀要”組成。其標識位置同 8.1.4，用紅色小標宋體字，字號由發文機關酌定。會議紀要不加蓋印章。其他要素從本標準相關要素說明。
12 式樣
?。ˋ4 型公文紙頁邊及版心尺寸見圖 1）
?。ü氖醉摪媸揭妶D 2）
?。ㄉ蠄蠊氖醉摪媸揭妶D 3）
?。ü哪╉摪媸揭妶D 4）
?。摵闲形墓哪╉摪媸?1 見圖 5）
（聯合行文公文末頁版式 2 見圖 6）
注：版心實線框僅為示意，在印制公文時并不印出。
國家質量技術監督局 1999－12－27 批準發布，2000－01－01 實施。
]]>
擁有帳號和密碼，我們通常使用 FTP 客戶端軟件（FlashFXP、CuteFTP 等）登錄 FTP 服務器，以取得相關的資源。
或者直接在 Web 瀏覽器上輸入 FTP 服務器地址，再輸入帳號和密碼登錄。
當然，為了更簡單，我們嘗試使用 FTP 協議的 URL 直接登錄服務器，格式如下：
ftp://用戶名:密碼@服務器:端口例如：ftp://testuser:testpwd@127.0.0.1:21
]]>
微軟 MSDN 版本，安裝時不用輸入序列號。
裝好三天后自動激活，如果沒有激活會進入 60 天的正版試用期。
過了 60 天后還可以繼續延期試用期 3 次，加起來 240 天正版試用期。
240 天以后，想必序列號都大把大把了。
文件大小 1955MB，比之前的 1.79G 試用版大。
MD5：D366B7F8EC69C646A8B1E512BA01BEE3
SHA-1 Hash：4C1BC3739C13D3CE122C9B4BBED4BB2BB2DC708C1
快到期時，在管理員模式下，運行 slmgr.vbs -rearm 命令重置激活期限，可重置三次。
網上檢索的下載地址（HTTP）：
http://58.218.154.35/zh-Hans_windows_server_2008_datacenter_enterprise_standard_x86_dvd_x14-26742.iso
http://fcv.cn/tmp/zh-Hans_windows_server_2008_datacenter_enterprise_standard_x86_dvd_x14-26742.iso
]]>
默認情況下，<pre /> 標簽中的內容若超出范圍不會自動換行，這樣無論在顯示或打印都會出現麻煩。
下面提供符合 W3C 標準并支持多瀏覽器的 CSS 樣式代碼：
pre{
white-space:pre-wrap; /* css-3 */
white-space:-moz-pre-wrap; /* Mozilla, since 1999 */
white-space:-pre-wrap; /* Opera 4-6 */
white-space:-o-pre-wrap; /* Opera 7 */
word-wrap:break-word; /* Internet Explorer 5.5+ */
}
white-space:pre-wrap; /* css-3 */
white-space:-moz-pre-wrap; /* Mozilla, since 1999 */
white-space:-pre-wrap; /* Opera 4-6 */
white-space:-o-pre-wrap; /* Opera 7 */
word-wrap:break-word; /* Internet Explorer 5.5+ */
}
更多內容請參見：http://www.w3.org/TR/css3-text/#white-space。
]]>
國家行政機關公文處理辦法
（2000 年 8 月 24 日國務院國發 [2000] 23 號發布）
第一章 總 則第一章 總 則
第二章 公文種類
第三章 公文格式
第四章 行文規則
第五章 發文辦理
第六章 收文辦理
第七章 公文歸檔
第八章 公文管理
第九章 附 則
第一條 為使國家行政機關（以下簡稱行政機關）的公文處理工作規范化、制度化、科學化，制定本辦法。
第二條 行政機關的公文（包括電報，下同），是行政機關在行政管理過程中形成的具有法定效力和規范體式的文書，是依法行政和進行公務活動的重要工具。
第三條 公文處理指公文的辦理、管理、整理（立卷）、歸檔等一系列相互關聯、銜接有序的工作。
第四條 公文處理應當堅持實事求是、精簡、高效的原則，做到及時、準確、安全。
第五條 公文處理必須嚴格執行國家保密法律、法規和其他有關規定，確保國家秘密的安全。
第六條 各級行政機關的負責人應當高度重視公文處理工作，模范遵守本辦法并加強對本機關公文處理工作的領導和檢查。
第七條 各級行政機關的辦公廳（室）是公文處理的管理機構，主管本機關的公文處理工作并指導下級機關的公文處理工作。
第八條 各級行政機關的辦公廳（室）應當設立文秘部門或者配備專職人員負責公文處理工作。
第二章 公文種類
第九條 行政機關的公文種類主要有：
?。ㄒ唬┟睿睿哼m用于依照有關法律公布行政法規和規章；宣布施行重大強制性行政措施；嘉獎有關單位及人員。
?。ǘQ定：適用于對重要事項或者重大行動做出安排，獎懲有關單位及人員，變更或者撤銷下級機關不適當的決定事項。
?。ㄈ┕妫哼m用于向國內外宣布重要事項或者法定事項。
（四）通告：適用于公布社會各有關方面應當遵守或者周知的事項。
（五）通知：適用于批轉下級機關的公文，轉發上級機關和不相隸屬機關的公文，傳達要求下級機關辦理和需要有關單位周知或者執行的事項，任免人員。
?。┩▓螅哼m用于表彰先進，批評錯誤，傳達重要精神或者情況。
?。ㄆ撸┳h案：適用于各級人民政府按照法律程序向同級人民代表大會或人民代表大會常務委員會提請審議事項。
?。ò耍﹫蟾妫哼m用于向上級機關匯報工作，反映情況，答復上級機關的詢問。
?。ň牛┱埵荆哼m用于向上級機關請求指示、批準。
?。ㄊ┡鷱停哼m用于答復下級機關的請示事項。
（十一）意見：適用于對重要問題提出見解和處理辦法。
（十二）函：適用于不相隸屬機關之間商洽工作，詢問和答復問題，請求批準和答復審批事項。
（十三）會議紀要：適用于記載、傳達會議情況和議定事項。
第三章 公文格式
第十條 公文一般由秘密等級和保密期限、緊急程度、發文機關標識、發文字號、簽發人、標題、主送機關、正文、附件說明、成文日期、印章、附注、附件、主題詞、抄送機關、印發機關和印發日期等部分組成。
?。ㄒ唬┥婕皣颐孛艿墓膽敇嗣髅芗壓捅Ｃ芷谙?，其中，“絕密”、“機密”級公文還應當標明份數序號。
?。ǘ┚o急公文應當根據緊急程度分別標明“特急”、“急件”。其中電報應當分別標明“特提”、“特急”、“加急”、“平急”。
（三）發文機關標識應當使用發文機關全稱或者規范化簡稱；聯合行文，主辦機關排列在前。
?。ㄋ模┌l文字號應當包括機關代字、年份、序號。聯合行文，只標明主辦機關發文字號。
（五）上行文應當注明簽發人、會簽人姓名。其中，“請示”應當在附注處注明聯系人的姓名和電話。
（六）公文標題應當準確簡要地概括公文的主要內容并標明公文種類，一般應當標明發文機關。公文標題中除法規、規章名稱加書名號外，一般不用標點符號。
（七）主送機關指公文的主要受理機關，應當使用全稱或者規范化簡稱、統稱。
（八）公文如有附件，應當注明附件順序和名稱。
?。ň牛┕某?#8220;會議紀要”和以電報形式發出的以外，應當加蓋印章。聯合上報的公文，由主辦機關加蓋印章；聯合下發的公文，發文機關都應當加蓋印章。
（十）成文日期以負責人簽發的日期為準，聯合行文以最后簽發機關負責人的簽發日期為準。電報以發出日期為準。
（十一）公文如有附注（需要說明的其他事項），應當加括號標注。
?。ㄊ┕膽敇俗⒅黝}詞。上行文按照上級機關的要求標注主題詞。
?。ㄊ┏蜋C關指除主送機關外需要執行或知曉公文的其他機關，應當使用全稱或者規范化簡稱、統稱。
?。ㄊ模┪淖謴淖笾劣覚M寫、橫排。在民族自治地方，可以并用漢字和通用的少數民族文字（按其習慣書寫、排版）。
第十一條 公文中各組成部分的標識規則，參照《國家行政機關公文格式》國家標準執行。
第十二條 公文用紙一般采用國際標準 A4 型（210mm×297mm），左側裝訂。張貼的公文用紙大小，根據實際需要確定。
第四章 行文規則
第十三條 行文應當確有必要，注重效用。
第十四條 行文關系根據隸屬關系和職權范圍確定，一般不得越級請示和報告。
第十五條 政府各部門依據部門職權可以相互行文和向下一級政府的相關業務部門行文；除以函的形式商洽工作、詢問和答復問題、審批事項外，一般不得向下一級政府正式行文。部門內設機構除辦公廳（室）外不得對外正式行文。
第十六條 同級政府、同級政府各部門、上級政府部門與下一級政府可以聯合行文；政府與同級黨委和軍隊機關可以聯合行文；政府部門與相應的黨組織和軍隊機關可以聯合行文；政府部門與同級人民團體和具有行政職能的事業單位也可以聯合行文。
第十七條 屬于部門職權范圍內的事務，應當由部門自行行文或聯合行文。聯合行文應當明確主辦部門。須經政府審批的事項，經政府同意也可以由部門行文，文中應當注明經政府同意。
第十八條 屬于主管部門職權范圍內的具體問題，應當直接報送主管部門處理。
第十九條 部門之間對有關問題未經協商一致，不得各自向下行文。如擅自行文，上級機關應當責令糾正或撤銷。
第二十條 向下級機關或者本系統的重要行文，應當同時抄送直接上級機關。
第二十一條 “請示”應當一文一事；一般只寫一個主送機關，需要同時送其他機關的，應當用抄送形式，但不得抄送其下級機關。“報告”不得夾帶請示事項。
第二十二條 除上級機關負責人直接交辦的事項外，不得以機關名義向上級機關負責人報送“請示”、“意見”和“報告”。
第二十三條 受雙重領導的機關向上級機關行文，應當寫明主送機關和抄送機關。上級機關向受雙重領導的下級機關行文，必要時應當抄送其另一上級機關。
第五章 發文辦理
第二十四條 發文辦理指以本機關名義制發公文的過程，包括草擬、審核、簽發、復核、繕印、用印、登記、分發等程序。
第二十五條 草擬公文應當做到：
?。ㄒ唬┓蠂业姆?、法規及其他有關規定。如提出新的政策、規定等，要切實可行并加以說明。
（二）情況確實，觀點明確，表述準確，結構嚴謹，條理清楚，直述不曲，字詞規范，標點正確，篇幅力求簡短。
?。ㄈ┕牡奈姆N應當根據行文目的、發文機關的職權和與主送機關的行文關系確定。
?。ㄋ模M制緊急公文，應當體現緊急的原因，并根據實際需要確定緊急程度。
（五）人名、地名、數字、引文準確。引用公文應當先引標題，后引發文字號。引用外文應當注明中文含義。日期應當寫明具體的年、月、日。
?。┙Y構層次序數，第一層為“一、”，第二層為“（一）”，第三層為“1．”，第四層為“（1）”。
?。ㄆ撸斒褂脟曳ǘㄓ嬃繂挝?。
?。ò耍┪膬仁褂梅且幏痘喎Q，應當先用全稱并注明簡稱。使用國際組織外文名稱或其縮寫形式，應當在第一次出現時注明準確的中文譯名。
（九）公文中的數字，除成文日期、部分結構層次序數和在詞、詞組、慣用語、縮略語、具有修辭色彩語句中作為詞素的數字必須使用漢字外，應當使用阿拉伯數字。
第二十六條 擬制公文，對涉及其他部門職權范圍內的事項，主辦部門應當主動與有關部門協商，取得一致意見后方可行文；如有分歧，主辦部門的主要負責人應當出面協調，仍不能取得一致時，主辦部門可以列明各方理據，提出建設性意見，并與有關部門會簽后報請上級機關協調或裁定。
第二十七條 公文送負責人簽發前，應當由辦公廳（室）進行審核。審核的重點是：是否確需行文，行文方式是否妥當，是否符合行文規則和擬制公文的有關要求，公文格式是否符合本辦法的規定等。
第二十八條 以本機關名義制發的上行文，由主要負責人或者主持工作的負責人簽發；以本機關名義制發的下行文或平行文，由主要負責人或者由主要負責人授權的其他負責人簽發。
第二十九條 公文正式印制前，文秘部門應當進行復核，重點是：審批、簽發手續是否完備，附件材料是否齊全，格式是否統一、規范等。經復核需要對文稿進行實質性修改的，應按程序復審。
第六章 收文辦理
第三十條 收文辦理指對收到公文的辦理過程，包括簽收、登記、審核、擬辦、批辦、承辦、催辦等程序。
第三十一條 收到下級機關上報的需要辦理的公文，文秘部門應當進行審核。審核的重點是：是否應由本機關辦理；是否符合行文規則；內容是否符合國家法律、法規及其他有關規定；涉及其他部門或地區職權的事項是否已協商、會簽；文種使用、公文格式是否規范。
第三十二條 經審核，對符合本辦法規定的公文，文秘部門應當及時提出擬辦意見送負責人批示或者交有關部門辦理，需要兩個以上部門辦理的應當明確主辦部門。緊急公文，應當明確辦理時限。對不符合本辦法規定的公文，經辦公廳（室）負責人批準后，可以退回呈報單位并說明理由。
第三十三條 承辦部門收到交辦的公文后應當及時辦理，不得延誤、推諉。緊急公文應當按時限要求辦理，確有困難的，應當及時予以說明。對不屬于本單位職權范圍或者不宜由本單位辦理的，應當及時退回交辦的文秘部門并說明理由。
第三十四條 收到上級機關下發或交辦的公文，由文秘部門提出擬辦意見，送負責人批示后辦理。
第三十五條 公文辦理中遇有涉及其他部門職權的事項，主辦部門應當主動與有關部門協商；如有分歧，主辦部門主要負責人要出面協調，如仍不能取得一致，可以報請上級機關協調或裁定。
第三十六條 審批公文時，對有具體請示事項的，主批人應當明確簽署意見、姓名和審批日期，其他審批人圈閱視為同意；沒有請示事項的，圈閱表示已閱知。
第三十七條 送負責人批示或者交有關部門辦理的公文，文秘部門要負責催辦，做到緊急公文跟蹤催辦，重要公文重點催辦，一般公文定期催辦。
第七章 公文歸檔
第三十八條 公文辦理完畢后，應當根據《中華人民共和國檔案法》和其他有關規定，及時整理（立卷）、歸檔。個人不得保存應當歸檔的公文。
第三十九條 歸檔范圍內的公文，應當根據其相互聯系、特征和保存價值等整理（立卷），要保證歸檔公文的齊全、完整，能正確反映本機關的主要工作情況，便于保管和利用。
第四十條 聯合辦理的公文，原件由主辦機關整理（立卷）、歸檔，其他機關保存復制件或其他形式的公文副本。
第四十一條 本機關負責人兼任其他機關職務，在履行所兼職務職責過程中形成的公文，由其兼職機關整理（立卷）、歸檔。
第四十二條 歸檔范圍內的公文應當確定保管期限，按照有關規定定期向檔案部門移交。
第四十三條 擬制、修改和簽批公文，書寫及所用紙張和字跡材料必須符合存檔要求。
第八章 公文管理
第四十四條 公文由文秘部門或專職人員統一收發、審核、用印、歸檔和銷毀。
第四十五條 文秘部門應當建立健全本機關公文處理的有關制度。
第四十六條 上級機關的公文，除絕密級和注明不準翻印的以外，下一級機關經負責人或者辦公廳（室）主任批準，可以翻印。翻印時，應當注明翻印的機關、日期、份數和印發范圍。
第四十七條 公開發布行政機關公文，必須經發文機關批準。經批準公開發布的公文，同發文機關正式印發的公文具有同等效力。
第四十八條 公文復印件作為正式公文使用時，應當加蓋復印機關證明章。
第四十九條 公文被撤銷，視作自始不產生效力；公文被廢止，視作自廢止之日起不產生效力。
第五十條 不具備歸檔和存查價值的公文，經過鑒別并經辦公廳（室）負責人批準，可以銷毀。
第五十一條 銷毀秘密公文應當到指定場所由二人以上監銷，保證不丟失、不漏銷。其中，銷毀絕密公文（含密碼電報）應當進行登記。
第五十二條 機關合并時，全部公文應當隨之合并管理。機關撤銷時，需要歸檔的公文整理（立卷）后按有關規定移交檔案部門。工作人員調離工作崗位時，應當將本人暫存、借用的公文按照有關規定移交、清退。
第五十三條 密碼電報的使用和管理，按照有關規定執行。
第九章 附 則
第五十四條 行政法規、規章方面的公文，依照有關規定處理。外事方面的公文，按照外交部的有關規定處理。
第五十五條 公文處理中涉及電子文件的有關規定另行制定。統一規定發布之前，各級行政機關可以制定本機關或者本地區、本系統的試行規定。
第五十六條 各級行政機關的辦公廳（室）對上級機關和本機關下發公文的貫徹落實情況應當進行督促檢查并建立督查制度。有關規定另行制定。
第五十七條 本辦法自 2001 年 1 月 1 日起施行。1993 年 11 月 21 日國務院辦公廳發布，1994 年 1 月 1 日起施行的《國家行政機關公文處理辦法》同時廢止。
]]>
]]>
通常情況下，我們要打開一個外部鏈接（新開窗口），往往使用如下代碼：
<a href="" target="_blank"></a>
然而把它放在 W3C XHTML 1.0 Strict 標準下卻發現無法通過驗證。
原來，在嚴格的 W3C DTD 下，<a /> 標簽的 target 屬性是不被官方所推薦的，使用 Strict 模式將視 target 屬性無效，我們只有利用 JavaScript 來變通實現。
真不知道 W3C 專家們是怎么想的，或許“易用性、友好性”成為他們主張的關鍵，因為老外覺得不經過用戶同意，沒有明確提示就打開一個新窗口是不禮貌的。
我們姑且不管這樣的概念是否真正合理，先看看解決辦法：
rel 屬性：規定當前文檔與目標 URL 之間的關系，即用來說明鏈接和包含此鏈接頁面的關系，以及鏈接打開的目標。
我們將使用 rel="external" 作為 <a /> 標簽的特性，那么可以得到如下代碼：
<a href="" rel="external"></a>
這是符合 W3C XHTML 1.0 Strict 標準的方法，當然還需要以個 JavaScript 方法作配合：
function external(){
var anchors=document.getElementsByTagName("a");
for(var i=0;i<anchors.length;i++){
if(anchors[i].getAttribute("rel")=="external"){anchors[i].target="_blank";}
}
}
var anchors=document.getElementsByTagName("a");
for(var i=0;i<anchors.length;i++){
if(anchors[i].getAttribute("rel")=="external"){anchors[i].target="_blank";}
}
}
在頁面下載完成時自動加載：
window.onload=function(){
external();
};
external();
};
可以把以上兩段 JavaScript 代碼存儲在 external.js 文件里，然后通過外部鏈接方法調用：
<script type="text/javascript" src="external.js"></script>
]]>
在計算機群管理的實際應用中，我們通常會下載所有的升級補丁，然后在計算機上逐個安裝，這樣免去了無法上網或在線升級耗時的問題。
但是計算機數量一旦很多，逐個升級將是十分繁瑣和可怕的事情。
Windows 的批處理功能將使得任務更加簡單，操作步驟如下：
1. 找一個大容量的 U 盤（如 2GB），格式化后建立 WinXP\、Win2K\、Win2003\ 三個目錄。
2. 將不同類型的升級補丁程序分別存放在這三個目錄下。
3. 下載批處理程序 update.rar，解壓出批處理命令程序文件 update.cmd。
4. 分別在這三個目錄下建立批處理程序的拷貝。
5. 升級時，只需要插上 U 盤，根據不同系統運行相關目錄下的 update.cmd 程序即可。
6. 批處理會自動逐個安裝升級程序，直至全部完成。
當然，也可以按需要刻成光盤，同時升級多個計算機。
需要注意的是，該批處理程序只會自動安裝與它在同一目錄下的升級補丁程序。
]]>
Public Function fnSize(vSize,iDot)
Dim sSize:sSize="0"
If vSize>1073741824 Then
sSize=FormatNumber(vSize/1073741824,iDot,-1,0,0)&" GB"
ElseIf vSize>1048576 Then
sSize=FormatNumber(vSize/1048576,iDot,-1,0,0)&" MB"
ElseIf vSize>1024 Then
sSize=FormatNumber(vSize/1024,iDot,-1,0,0)&" KB"
Else
sSize=vSize&" Byte"
End If
fnSize=sSize
End Function
Dim sSize:sSize="0"
If vSize>1073741824 Then
sSize=FormatNumber(vSize/1073741824,iDot,-1,0,0)&" GB"
ElseIf vSize>1048576 Then
sSize=FormatNumber(vSize/1048576,iDot,-1,0,0)&" MB"
ElseIf vSize>1024 Then
sSize=FormatNumber(vSize/1024,iDot,-1,0,0)&" KB"
Else
sSize=vSize&" Byte"
End If
fnSize=sSize
End Function
]]>
當頁面加載完畢后會觸發一個 onload 事件，假設此時想執行一個函數 aFunction，只需要將其綁定到這個事件上就可以了：
window.onload=aFunction;
但當要觸發兩個函數 aFunction 和 bFunction 時：
window.onload=aFunction;
window.onload=bFunction;
window.onload=bFunction;
以上代碼只能觸發后者，前者會被后者取代。
解決這個問題時可以通過編寫一個匿名函數來解決：
window.onload=function(){
aFunction();
bFunction();
}
aFunction();
bFunction();
}
這樣，無論在頁面加載時需要觸發多少函數，都可以在其匿名函數里指定，并且可以安排觸發順序。
]]>
召回率（Recall Rate）（查全率）：是檢索出的相關文檔數和文檔庫中所有的相關文檔數的比率，衡量的是檢索系統的查全率。
精度（Precision）（查準率）：是檢索出的相關文檔數與檢索出的文檔總數的比率，衡量的是檢索系統的查準率。
對于一個檢索系統來講，召回率和精度不可能兩全其美：召回率高時，精度低，精度高時，召回率低。
所以常常用 11 種召回率下 11 種精度的平均值來衡量一個檢索系統的精度。
對于搜索引擎系統來講，因為沒有一個搜索引擎系統能夠搜集到所有的 Web 網頁，所以召回率很難計算。
目前的搜索引擎系統都非常關心精度。
影響一個搜索引擎系統的性能有很多因素，最主要的是信息檢索模型，包括文檔和查詢的表示方法、評價文檔和用戶查詢相關性的匹配策略、查詢結果的排序方法和用戶進行相關度反饋的機制。
從一個大規模數據集合中檢索文檔的時，可把文檔分成四組：
※ 系統檢索到的相關文檔（A）
※ 系統檢索到的不相關文檔（B）
※ 相關但是系統沒有檢索到的文檔（C）
※ 相關但是被系統檢索到的文檔（D）
| 相關 | 不相關 | |
| 檢索到 | A | B |
| 未檢索到 | C | D |
直觀的說，一個好的檢索系統檢索到的相關文檔越多越好，不相關文檔越少越好。
召回率 R：用檢索到相關文檔數作為分子，所有相關文檔總數作為分母，即 R=A/(A+C)。
精度 P：用檢索到相關文檔數作為分子，所有檢索到的文檔總數作為分母，即 P=A/(A+B)。
舉例：一個數據庫有 500 個文檔，其中有 50 個文檔符合定義的問題；系統檢索到 75 個文檔，但其中只有 45 個文檔符合定義。
召回率：R=45/50=90%。
精度：P=45/75=60%。
上例中：系統檢索是比較有效的，召回率為 90%；但是結果有很大的噪音，有近一半的檢索結果是不相關。
研究表明：在不犧牲精度的情況下，獲得一個高召回率是很困難的；召回率越高，精度下降的很快，而且這種趨勢不是線性的。
]]>
對含有表單的網頁進行 XHTML 1.0 校驗時，發現無論如何也無法通過驗證，網上檢索了一下相關資料，發現有如下規則：
XHTML 1.0 Strict 中表單元素要放在<div></div>、<p></p>… 里面。
看下面的代碼：
<form method="post" action="">
<p>
<label>帳號 <input name="account" type="text" /></label>
<label>密碼 <input name="password" type="password" /></label>
<input type="submit" value="登錄" />
</p>
</form>
<p>
<label>帳號 <input name="account" type="text" /></label>
<label>密碼 <input name="password" type="password" /></label>
<input type="submit" value="登錄" />
</p>
</form>
另外，如果 form 中包含 fieldset 元素，它可不必包含在 div、p 等元素中，但未包含在 fieldset 元素中的表單元素，必須包含在 div、p 中。
<form method="post" action="">
<fieldset>
<legend>帳戶</legend>
<label>帳號 <input name="account" type="text" /></label>
<label>密碼 <input name="password" type="password" /></label>
</fieldset>
<p><input type="submit" value="登錄" /></p>
</form>
<fieldset>
<legend>帳戶</legend>
<label>帳號 <input name="account" type="text" /></label>
<label>密碼 <input name="password" type="password" /></label>
</fieldset>
<p><input type="submit" value="登錄" /></p>
</form>
]]>
<param name="wmode" value="transparent" />
]]>
給 <div /> 加上滾動條時，最好指定其高度和寬度，當內容超過其范圍時，滾動條會自己出現。
<div style="weight:200px;height:200px;overflow:scroll"></div>
]]>
隨著 W3C 標準的流行，表格標簽對于我們來說已經不太常用，但 W3C 標準并沒有拋棄它，這必然有它存在的合理性。
依我看來，表格最大的用途就在于數據內容的表現，確實省去了不少麻煩。
下面是表格標記的 XHTML 代碼：
<table width="236">
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</table>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</table>
常用的修飾上述表格為細線表格的 CSS2 樣式代碼如下：
table{border:1px solid #000;border-width:1px 0 0 1px;margin:2px 0 2px 0;text-align:center;border-collapse:collapse}
td,th{border:1px solid #000;border-width:0 1px 1px 0;margin:2px 0 2px 0;text-align:left}
th{text-align:center;font-weight:600;font-size:12px;background-color:#F4F4F4}
td,th{border:1px solid #000;border-width:0 1px 1px 0;margin:2px 0 2px 0;text-align:left}
th{text-align:center;font-weight:600;font-size:12px;background-color:#F4F4F4}
后來發現有更簡單的：
table,td,th{border:1px #000 solid;border-collapse:collapse}
注意：以上代碼均通過了 W3C 驗證（strict），符合標準。
]]>
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title></title>
<style type="text/css">
body{margin:0;padding:0}
div{margin:-200px auto auto -275px;position:absolute;top:50%;left:50%;width:550px;height:400px;background:#ff6600;text-align:center;line-height:400px}
</style>
</head><body>
<div>盒模型 div 布局的垂直居中（W3C 推薦方法）</div>
</body></html>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title></title>
<style type="text/css">
body{margin:0;padding:0}
div{margin:-200px auto auto -275px;position:absolute;top:50%;left:50%;width:550px;height:400px;background:#ff6600;text-align:center;line-height:400px}
</style>
</head><body>
<div>盒模型 div 布局的垂直居中（W3C 推薦方法）</div>
</body></html>
]]>
唐寅（唐伯虎）
桃花塢里桃花庵，桃花庵下桃花仙；
桃花仙人種桃樹，又摘桃花換酒錢。
酒醒只在花前坐，酒醉還來花下眠；
半醒半醉日復日，花落花開年復年。
但愿老死花酒間，不愿鞠躬車馬前；
車塵馬足富者趣，酒盞花枝貧者緣。
若將富貴比貧者，一在平地一在天；
若將貧賤比車馬，你得驅馳我得閑。
別（他）人笑我忒（太）瘋癲，我笑他人看不穿；
不見五陵豪杰墓，無花無酒鋤作田。
突然想起星爺的《唐伯虎點秋香》，蠻佩服其生活態度。
]]>