指定了 HTML 文檔遵循的文檔類型定義(DTD)。
Microsoft? Internet Explorer 6 的新增內容
你可使用此聲明將 Internet Explorer 6 及以后版本切換到標準兼容模式下。
語法
HTML 頂級元素 可用性 "注冊//組織//類型 標簽//定義 語言""URL"
可能值
頂級元素 指定 DTD 中聲明的頂級元素類型。這與聲明的 SGML 文檔類型相對應。 HTML 默認。HTML。
可用性 指定正式公開標識符(FPI)是可公開訪問的對象還是系統資源。 PUBLIC 默認。可公開訪問的對象。
SYSTEM 系統資源,如本地文件或 URL。
注冊 指定組織是否由國際標準化組織(ISO)注冊。 + 默認。組織名稱已注冊。
- 組織名稱未注冊。Internet 工程任務組(IETF)和萬維網協會(W3C)并非注冊的 ISO 組織。
組織 指定表明負責由 !DOCTYPE 聲明引用的 DTD 的創建和維護的團體或組織的名稱,即 OwnderID。 IETF IETF。
W3C W3C。
類型 指定公開文本類,即所引用的對象類型。 DTD 默認。DTD。
標簽 指定公開文本描述,即對所引用的公開文本的唯一描述性名稱。后面可附帶版本號。 HTML 默認。HTML。
定義 指定文檔類型定義。 Frameset 框架集文檔。
Strict 排除所有 W3C 專家希望逐步淘汰的代表性屬性和元素,因為樣式表已經很完善了。
Transitional 包含除 frameSet 元素的全部內容。
語言 指定公開文本語言,即用于創建所引用對象的自然語言編碼系統。該語言定義已編寫為 ISO 639 語言代碼(大寫兩個字母)。 EN 默認。英語。
URL 指定所引用對象的位置。
注釋
此聲明必須出現在文檔的起始處,出現在 html 標簽之前。
!DOCTYPE 元素不需要關閉標簽。
此元素在 Microsoft? Internet Explorer 3.0 的 HTML 中可用。
你可使用此聲明在 Internet Explorer 6 及以后版本中切換為嚴格的標準兼容模式。若想打開此開關,請在你的文檔頂部包含 !DOCTYPE 聲明,在聲明中指定合法的標簽,在某些情況下,還需要指定定義和/或 URL。下面的表格列出了標準兼容模式的開關情況。 DOCTYPE 出現 URL 未出現 URL
未出現 DOCTYPE 關 關
HTML (無版本) 關 關
HTML 2.0 關 關
HTML 3.0 關 關
HTML 4.0 開 開
HTML 4.0 Frameset 開 關
HTML 4.0 Transitional 開 關
HTML 4.0 Strict 開 開
XHTML 開 開
XML 開 開
無法識別的 DOCTYPE 開 開
注意 在標準兼容模式下,不能保證與其它版本的 Internet Explorer 保持兼容。當打開標準兼容模式時,文檔的渲染行為也許與將來版本的 Internet Explorer 不同。若內容本來就是固定的(如刻錄在 CD 上),則不應該使用此模式。
示例
下面的例子演示了如何使用 !DOCTYPE 聲明指定文檔遵從的 DTD,并將 Internet Explorer 6 及更高版本切換到標準兼容模式。
下面例子中的聲明都指定了遵從 HTML 4.0 DTD。第二種聲明指定了“Strict”。第一種聲明沒有指定。這兩種聲明都將會把 Internet Explorer 6 及以后版本切換到標準兼容模式。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
下面例子中的聲明都指定了遵從“Transitional”HTML 4.0 DTD。第二種聲明指定了 DTD 的 URL。第一種聲明沒有指定。第二種聲明將會把 Internet Explorer 6 及以后版本切換到標準兼容模式。第一種聲明不會。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"
======================================================
使用正確的doctype聲明
雖然大多數Web文檔的頂部都有doctype聲明,但很多人都沒有注意它。它是在你新建一個文檔時,由Web創作軟件草率處理的眾多細節之一。
雖然doctype被許多人忽視,但在遵循標準的任何Web文檔中,它都是一項必需的元素。doctype會影響代碼驗證,并決定了瀏覽器最終如何顯示你的Web文檔。
doctype的作用
doctype聲明指出閱讀程序應該用什么規則集來解釋文檔中的標記。在Web文檔的情況下,“閱讀程序”通常是瀏覽器或者校驗器這樣的一個程序,“規則”則是W3C所發布的一個文檔類型定義(DTD)中包含的規則。
每個DTD都包括一系列標記、attributes和properties,它們用于標記Web文檔的內容;此外還包括一些規則,它們規定了哪些標記能出現在其他哪些標記中。每個Web建議標準(比如HTML 4 Frameset和XHTML 1.0 Transitional)都有自己的DTD。
假如文檔中的標記不遵循doctype聲明所指定的DTD,這個文檔除了不能通過代碼校驗之外,還有可能無法在瀏覽器中正確顯示。對于標記不一致的問題,瀏覽器相較于校驗器來說更寬容。但是,不正確的doctype聲明經常導致網頁不正確顯示,或者導致它們根本不能顯示。
選擇正確的doctype
為了獲得正確的doctype聲明,關鍵就是讓DTD與文檔所遵循的標準對應。例如,假定文檔遵循的是XHTML 1.0 Strict標準,文檔的doctype聲明就應該引用相應的DTD。另一方面,如果doctype聲明指定的是XHTML DTD,但文檔包含的是舊式風格的HTML標記,就是不恰當的;類似地,如果doctype聲明指定的是HTML DTD,但文檔包含的是XHTML 1.0 Strict標記,同樣是不恰當的。
有的時候,也可以根本不使用一個doctype聲明。如果沒有指定有效的doctype聲明,大多數瀏覽器都會使用一個內建的默認DTD。在這種情況下,瀏覽器會用內建的DTD來試著顯示你所指定的標記。對于一些臨時性的、匆忙拼湊的文檔(這種文檔有許多),你確實可以考慮省略doctype聲明,并接受瀏覽器的默認顯示。
完全可以從頭編寫一個doctype聲明,并讓它指向自己選擇的一個DTD。然而,由于大多數Web文檔都需要遵循由W3C發布的某個國際公認的Web標準,所以那些文檔通常都要包含以下標準doctype聲明之一:
HTML 2:
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
HTML 3.2:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
HTML 4.01 Strict:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
HTML 4.01 Transitional:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Frameset:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 Strict:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Frameset:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
XHTML 1.1 plus MathML plus SVG:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
除了上面列出的doctype聲明,具有特殊要求的一些文檔還使用了其他幾種聲明。
doctype聲明通常是文檔的第一行,要在<html>標記以及其他文檔內容之前。注意,在XHTML文檔中,doctype的前面偶爾會出現一條XML處理指令(也稱為XML prolog):
<?xml version="1.0" encoding="utf-8"?>
為了確保網頁正確顯示和順利通過驗證,使用正確的doctype是關鍵。與內容相反的、不正確的或者形式錯誤的doctype是大量問題的罪魁禍首。在未來的專欄文章中,我還會具體解釋如何診斷及糾正這些問題。
==============================================
其他關于這個問題的帖子:
http://search.teein.com/results.aspx?q=DTD&st=PST&SiteID=29&hl=zh-cn&lu=http%3A%2F%2Fwww.blueidea.com%2Fimg%2Fcommon%2Flogo.gif&rt=%BE%AD%B5%E4%C2%DB%CC%B3%CB%D1%CB%F7%BD%E1%B9%FB&ku=http%3A%2F%2Fwww.blueidea.com%2F
曾經也是網頁大師,現在也要好好學學細節問題了,呵呵
http://www.w3cn.org/article/step/2004/26.html
由于篇幅較長,請查看對于IoC的概要介紹。
OFFICE里,電腦是我們最重要的一件辦公用品,很難想像,如果沒有了電腦,我們將如何工作。但遺憾的是,當我們享受著電腦帶給我們的一切方便的同時,也不得不接受它在身心兩方面對我們健康的威脅。所以,了解電腦“病”,防治電腦“病”,已經成為我們刻 不容緩的事情。為了全面了解電腦對OL身心的負面影響,我們特地組織這次策劃,全面介紹緩解OL們最難逃脫的八大電腦“病”的竅門和方法。How To Ask Questions The Smart Way Copyright (C) 2001 by Eric S. Raymond 中文版Copyleft 2001 by D.H.Grand(nOBODY/Ginux) 英文版:http://www.tuxedo.org/~esr/faqs/smart-questions.html 感謝Eric的耐心指點和同意,本文才得以完成并發布,本指南英文版版權為Eric Steven Raymond所有,中文版版權由D.H.Grand[nOBODY/Ginux]所有。 ==== 簡介 ==== 在黑客世界里,當提出一個技術問題時,你能得到怎樣的回答?這取決于挖出答案 的難度,同樣取決于你提問的方法。本指南旨在幫助你提高發問技巧,以獲取你最 想要的答案。 首先你必須明白,黑客們只偏愛艱巨的任務,或者能激發他們思維的好問題。如若 不然,我們還來干嗎?如果你有值得我們反復咀嚼玩味的好問題,我們自會對你感 激不盡。好問題是激勵,是厚禮,可以提高我們的理解力,而且通常會暴露我們以 前從沒意識到或者思考過的問題。對黑客而言,"問得好!"是發自內心的大力稱 贊。 盡管黑客們有蔑視簡單問題和不友善的壞名聲,有時看起來似乎我們對新手,對知 識貧乏者懷有敵意,但其實不是那樣的。 我們不想掩飾對這樣一些人的蔑視--他們不愿思考,或者在發問前不去完成他們應 該做的事。這種人只會謀殺時間--他們只愿索取,從不付出,無端消耗我們的時間 ,而我們本可以把時間用在更有趣的問題或者更值得回答的人身上。我們稱這樣的 人為"失敗者"(由于歷史原因,我們有時把它拼作"lusers")。 我們也知道,很多人只想使用我們編寫的軟件,對技術細節沒什么興趣。對多數人 們而言,計算機不過是一個工具,一種達到目的的手段;他們有更重要的事情要做 ,有更重要的生活要過。我們明白這點,也并不奢望每個人都對另我們癡狂的技術 問題有興致。然而,我們回答問題的風格是針對這樣一群人--他們有興趣,并且愿 意積極參與問題的解決。這點不會改變,也不應該改變;如果變了,我們將失去我 們引以為傲的效率。 我們在很大程度上屬于志愿者,從繁忙的生活中抽出時間來解惑答疑,而且時常被 提問淹沒。所以我們無情的濾掉一些話題,特別是拋棄那些看起來象失敗者的家伙 ,以便更高效的利用時間來回答勝利者的問題。 如果你覺得我們過于傲慢的態度讓你不爽,讓你委屈,不妨設身處地想想。我們并 沒有要求你向我們屈服--事實上,我們中的大多數人最喜歡公平交易不過了,只要 你付出小小努力來滿足最起碼的要求,我們就會歡迎你加入到我們的文化中來。但 讓我們幫助那些不愿意幫助自己的人是沒有意義的。如果你不能接受這種"歧視" ,我們建議你花點錢找家商業公司簽個技術支持協議得了,別向黑客乞求幫助。 如果你決定向我們求助,當然不希望被視為失敗者,更不愿成為失敗者中的一員。 立刻得到有效答案的最好方法,就是象勝利者那樣提問--聰明、自信、有解決問題 的思路,只是偶爾在特定的問題上需要獲得一點幫助。 (歡迎對本指南提出改進意見。任何建議請E-mail至esr@thyrsus.com,然而請注 意,本文并非網絡禮節的通用指南,我通常會拒絕無助于在技術論壇得到有用答案 的建議。) (當然,如果你寫中文,最好還是寄到DHGrand@hotmail.com;-) ======== 提問之前 ======== 在通過電郵、新聞組或者聊天室提出技術問題前,檢查你有沒有做到: 1. 通讀手冊,試著自己找答案。 2. 在FAQ里找答案(一份維護得好的FAQ可以包羅萬象:)。 3. 在網上搜索(個人推薦google~~~)。 4. 向你身邊精于此道的朋友打聽。 當你提出問題的時候,首先要說明在此之前你干了些什么;這將有助于樹立你的形 象:你不是一個妄圖不勞而獲的乞討者,不愿浪費別人的時間。能說明你從這些操 作中學到了什么就更好了。如果提問者能從答案中學到東西,我們更樂于回答他的 問題。 周全的思考,準備好你的問題,草率的發問只能得到草率的回答,或者根本得不到 任何答案。越表現出在尋求幫助前為解決問題付出的努力,你越能得到實質性的幫 助。 小心別問錯了問題。如果你的問題基于錯誤的假設,普通黑客(J. Random Hacker)通常會用無意義的字面解釋來答復你,心里想著"蠢問題...",希望著 你會從問題的回答(而非你想得到的答案)中汲取教訓。 決不要自以為夠資格得到答案,你沒這種資格。畢竟你沒有為這種服務支付任何報 酬。你要自己去"掙"回一個答案,靠提出一個有內涵的,有趣的,有思維激勵作 用的問題--一個對社區的經驗有潛在貢獻的問題,而不僅僅是被動的從他人處索要 知識--去掙到這個答案。 另一方面,表明你愿意在找答案的過程中做點什么,是一個非常好的開端。"誰能 給點提示?"、"我這個例子里缺了什么?"以及"我應該檢查什么地方?"比" 請把確切的過程貼出來"更容易得到答復。因為你顯得只要有人指點正確的方向, 你就有完成它的能力和決心。 ======== 怎樣提問 ======== ------------ 謹慎選擇論壇 ------------ 小心選擇提問的場合。如果象下面描述的那樣,你很可能被忽略掉或者被看作失敗 者: 1. 在風馬牛不相及的論壇貼出你的問題 2. 在探討高級技巧的論壇張貼非常初級的問題;反之亦然 3. 在太多的不同新聞組交叉張貼 黑客們通常砍掉問錯地方的問題,以保護自己的社區不被大量無關帖子淹沒。你不 會希望自己的帖子被這樣砍掉吧。 總的說來,問題發到精心挑選的公眾論壇,比發到封閉的小圈子更容易得到有用的 答案。這一現象有多種原因,其中之一是公眾論壇有更多潛在的問題回答者;另一 個原因是公眾論壇有更多的聽眾。黑客們更愿意讓盡量多的人--而非有限的一兩個 --從回答中受益。 ---------------- 盡量使用郵件列表 ---------------- 如果某項目有自己的開發郵件列表,要把問題發到這個郵件列表而不是某個開發者 ,即使你很清楚誰最能回答你的問題。仔細查看項目文檔和項目主頁,找到這個項 目的郵件列表地址,這樣做的理由有四: 1. 任何值得問某位開發者的好問題,都值得向整個開發團體提出。反之,若你認 為這個問題不值得在郵件列表中提起,就沒有理由用它來騷擾任何一位開發者。 2. 在郵件列表提問可以分擔開發者的工作量。某位開發者(尤其當他是項目負責 人的情況下),可能忙得沒時間回答你的問題。 3. 大多數郵件列表都有歷史存檔,而且都能在搜索引擎中檢索到。人們可以從中 找到你的問題和答案,不用一遍又一遍在列表中發問。 4. 如果某個問題經常被提出,開發者可以據此改進文檔或改進軟件,以減少用戶 的困惑。而如果問題總在私下提出,就不會有人對此有整體上的把握了。 如果你找不到項目的郵件列表地址,只能看到項目維護者的,那就寫給維護者吧。 在這種情況下,也別以為郵件列表并不存在。在你的信中寫明你已盡力尋找,仍無 法找到郵件列表。另外表明你不介意將此消息轉給他人。(大多數人認為私信就應 該是私下的,即使并沒有什么可保密的內容。允許你的消息被轉寄給他人,給了收 信者一種處理你郵件的選擇。) ---------------------------- 用辭貼切,語法正確,拼寫無誤 ---------------------------- 我們從經驗中發現,粗心的寫作者通常也是馬虎的思考者(我敢打包票)。回答粗 心大意者的問題很不值得,我們寧愿把時間耗在別處。 因此,明確充分表述你的問題非常重要。如果你嫌這樣做麻煩,我們也會懶得搭理 你。注意推敲你的用辭,不一定要用呆板正式的語言--事實上,黑客文化的價值觀 是不拘小節。準確的運用俚語和富有幽默感的語言,但別亂用;一定要能表明你在 思考,在關注。 正確的拼寫,標點符號和大小寫很重要。別把"its"和"it's"或者"loose"和 "lose"搞混淆了。別用全部大寫的形式,這被視為粗魯的大聲叫嚷(全都用小寫 也好不到哪兒去,因為這會給閱讀帶來困難。Alan Cox可以用全部小寫,但你不行 )。 更一般的說,如果你的提問寫得象個半文盲,你很有可能被忽視。如果寫得象一個 窺客(破解愛好者)或者灰客(只會用現成工具的搗亂者)絕對是自己找死,保證 你除了無情的抵制什么也得不到(或者,最好的結局是得到一大堆挖苦嘲笑的"幫 助")。 如果你在使用非母語的論壇提問,你可以犯點拼寫和語法上的小錯--但決不能在思 考上馬虎(沒錯,我們能弄清兩者的分別)。另外,除非你確切知道你的回答者會 使用什么語言,否則請用英文。匆匆忙忙的黑客往往簡單的跳過他們看不懂的問題 ,而英文是網絡上的工作語言。用英文可以降低你的問題未被閱讀即遭拋棄的風險 。 ------------------ 用易讀格式發送問題 ------------------ 如果人為造成你的提問難以閱讀和理解,將會更容易被人忽略。因此你要: 1. 使用純文本郵件,不要使用HTML(關掉HTML并不難)。 2. 通常可以附加MIME附件,但一定要有真正的內容(例如附加的源文件或者補丁 ),而不僅僅是你的郵件客戶端產生的文件模板(例如你郵件的一份拷貝)。 3. 不要把所有問題放在不停換行的一整段中。(這將讓答復的人難于回答其中一 部分問題,即使能回答所有問題,我也更希望條理清楚的一個一個來:)。很可能 收件人只能在80個字符寬度的文本顯示器上讀信,因此要相應的把行環繞模式設在 80字符以內。 4. 不要在英文論壇使用MIME Quoted-Printable編碼發送;這種編碼格式對ASCII 碼不能表達的語言來說是非常必要的,但很多郵件代理不支持它,這時,滿篇的" =20"符號把文字分割開,既難看,又分散注意力。 5. 永遠不要指望黑客會樂于閱讀封閉所有權的文件格式,例如萎軟的Word格式。 多數黑客對此的反應就象你在門口的階梯上堆滿熱烘烘的豬糞(意即誰也不會踏進 你的門--譯者注)。 6. 如果你通過一臺安裝Windows的電腦發送郵件,關閉萎軟愚蠢的"智能引用"功 能。這能使你免于在郵件中夾帶垃圾字符。 ---------------------------- 使用含義豐富,描述準確的標題 ---------------------------- 在郵件列表或者新聞組中,大約50字以內的主題標題是抓住資深專家注意力的黃金 時機。別用喋喋不休的"幫幫忙"(更別說"救命啊!!!!!"這樣讓人反感的 話)來浪費這個機會。不要妄想用你的痛苦程度來打動我們,別用空格代替問題的 描述,哪怕是極其簡短的描述。 蠢問題: 救命啊!我的膝上機不能正常顯示了! 聰明問題: XFree86 4.1下鼠標光標變形,Fooware MV1005的顯示芯片。 如果你在回復中提出問題,記得要修改內容標題,表明里面有一個問題。一個看起 來象"Re:測試"或者"Re:新bug"的問題很難引起足夠重視。另外,引用并刪 減前文的內容,給新來的讀者留下線索。 ------------------ 精確描述,信息量大 ------------------ 1. 謹慎明確的描述癥狀。 2. 提供問題發生的環境(機器配置、操作系統、應用程序以及別的什么)。 3. 說明你在提問前是怎樣去研究和理解這個問題的。 4. 說明你在提問前采取了什么步驟去解決它。 5. 羅列最近做過什么可能有影響的硬件、軟件變更。 盡量想象一個黑客會怎樣反問你,在提問的時候預先給他答案。 Simon Tatham寫過一篇名為《如何有效的報告Bug》的出色短文。強力推薦你也讀 一讀。 -------- 話不在多 -------- 你需要提供精確有效的信息。這并不是要求你簡單的把成噸的出錯代碼或者數據完 全轉儲摘錄到你的提問中。如果你有龐大而復雜的測試條件,盡量把它剪裁得越小 越好。 這樣做的用處至少有三點。第一,表現出你為簡化問題付出了努力,這可以使你得 到回答的機會增加;第二,簡化問題使你得到有用答案的機會增加;第三,在提煉 你的bug報告的過程中,也許你自己就能找出問題所在或作出更正。 ------------------ 只說癥狀,不說猜想 ------------------ 告訴黑客們你認為問題是怎樣引起的沒什么幫助。(如果你的推斷如此有效,還用 向別人求助嗎?),因此要確信你原原本本告訴了他們問題的癥狀,不要加進你自 己的理解和推論。讓黑客們來診斷吧。 蠢問題: 我在內核編譯中一次又一次遇到SIG11錯誤,我懷疑某條飛線搭在主板的走線上了 ,這種情況應該怎樣檢查最好? 聰明問題: 我自制的一套K6/233系統,主板是FIC-PA2007 (VIA Apollo VP2芯片組),256MB Corsair PC133 SDRAM,在內核編譯中頻頻產生SIG11錯誤,從開機20分鐘以后就 有這種情況,開機前20分鐘內從沒發生過。重啟也沒有用,但是關機一晚上就又能 工作20分鐘。所有內存都換過了,沒有效果。相關部分的典型編譯記錄如下...。 ------------------ 按時間順序列出癥狀 ------------------ 對找出問題最有幫助的線索,往往就是問題發生前的一系列操作,因此,你的說明 應該包含操作步驟,以及電腦的反應,直到問題產生。在命令行操作的情況下,保 存一個操作記錄(例如使用腳本工具),并且引用相關的大約20條命令會大有幫助 。 如果崩潰的程序有診斷選項(例如用-v轉到詳盡模式),試著仔細考慮選擇選項以 在操作記錄中增加有用的調試信息。 如果你的說明很長(超過四個段落),在開頭簡述問題會有所幫助,接下來按時間 順序詳述。這樣黑客們就知道該在你的說明中找什么。 -------------- 別要求私下答復 -------------- 黑客們認為解決問題應該有公開、透明的流程。只要任何更有見地的人注意到答案 的不完善或者不正確,這個最初的答案就可以和應該得到糾正。同時,通過能力和 知識被大家注意,被大家接受,回答問題者得到了應有的獎勵。 如果你要求對方私下回答你,這既破壞了整個流程,也破壞了獎勵制度。別提這要 求,這是回答者的權利,由他來選擇是否私下答復--如果他選擇這樣做,通常是因 為他認為這個答案過于顯而易見或者有不良的公開影響,別人不會感興趣。 只有一種有限的例外:如果你預計將收到大量雷同的答復,你可以說:"把答案寄 給我,由我來匯總吧。"將郵件列表或者新聞組從大量重復的帖子中打救出來是很 有君子之風的--但請記住,履行自己關于匯總的承諾。 -------------- 明白你想問什么 -------------- 漫無邊際的提問近乎無休無止的時間黑洞。最能給你有用答案的人也正是最忙的人 (他們忙是因為要親自完成大部分工作)。這樣的人對無節制的時間黑洞不太感冒 ,因此也可以說他們對漫無邊際的提問不大感冒。 如果你明確表述需要回答者做什么(提供建議,發送一段代碼,檢查你的補丁或是 別的),就最有可能得到有用的答案。這會定出一個時間和精力的上限,便于回答 者集中精力來幫你,這很湊效。 要理解專家們生活的世界,要把專業技能想象為充裕的資源,而回復的時間則是貧 乏的資源。解決你的問題需要的時間越少,越能從忙碌的專家口中掏出答案。 因此,優化問題的結構,盡量減少專家們解決它所需要的時間,會有很大的幫助 --這通常和簡化問題有所區別。因此,問"我想更好的理解X,能給點提示嗎?" 通常比問"你能解釋一下X嗎?"更好。如果你的代碼不能工作,問問它有什么地 方不對,比要求別人替你修改要明智得多。 ------------------------ 別問應該自己解決的問題 ------------------------ 黑客們總是善于分辨哪些問題應該由你自己解決;因為我們中的大多數都曾自己解 決這類問題。同樣,這些問題得由你來搞定,你會從中學到東西。你可以要求給點 提示,但別要求得到完整的解決方案。 ---------------- 去除無意義的疑問 ---------------- 別用無意義的話結束提問,例如"有人能幫我嗎?"或者"有答案嗎?"。首先: 如果你對問題的描述不很合適,這樣問更是畫蛇添足。其次:由于這樣問是畫蛇添 足,黑客們會很厭煩你--而且通常會用邏輯上正確的回答來表示他們的蔑視,例如 :"沒錯,有人能幫你"或者"不,沒答案"。 ---------------------------- 謙遜絕沒有害處,而且常幫大忙 ---------------------------- 彬彬有禮,多用"請"和"先道個謝了"。讓大家都知道你對他們花費時間義務提 供幫助心存感激。 實話實說,雖然這不象合乎語法、清楚準確的描述,避免私有格式等等那么重要( 也不能用來替代它們);黑客一般更喜歡直接了當然而技術上敏銳的bug報告,而 不是彬彬有禮的廢話(如果這讓你迷惑不解,請記住,我們衡量一個問題價值的標 準是:它能讓我們學會多少)。 然而,如果你有很多問題無法解決,禮貌將會增加你得到有用答案的機會。 (我們注意到,自從本指南發布后,從資深黑客處得到的唯一嚴重缺陷反饋,就是 對預先道謝這一條。一些黑客覺得"先謝了"的言外之意是過后就不會再感謝任何 人了。我們的建議是:都道謝。) ------------------------ 問題解決后,加個簡短說明 ------------------------ 問題解決后,向所有幫助過你的人發個說明,讓他們知道問題是怎樣解決的,并再 一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注,應該在 那里貼一個補充說明。 補充說明不必很長或是很深入;簡單的一句"你好,原來是網線出了問題!謝謝大 家--Bill"比什么也不說要強。事實上,除非結論真的很有技術含量,否則簡短可 愛的小結比長篇學術論文更好。說明問題是怎樣解決的,但大可不必將解決問題的 過程復述一遍。 除了表示禮貌和反饋信息以外,這種補充有助于他人在郵件列表/新聞組/論壇中搜 索對你有過幫助的完整解決方案,這可能對他們也很有用。 最后(至少?),這種補充有助于所有提供過幫助的人從中得到滿足感。如果你自 己不是老手或者黑客,那就相信我們,這種感覺對于那些你向他們求助的導師或者 專家而言,是非常重要的。問題久拖未決會讓人灰心;黑客們渴望看到問題被解決 。好人有好報,滿足他們的渴望,你會在下次貼出新問題時嘗到甜頭。 ============ 如何理解答案 ============ -------------------- RTFM和STFW:別煩我啦 -------------------- 有一個古老而神圣的傳統:如果你收到"RTFM (Read The Fucking Manual)"的 回復,回答者認為你應該去讀TMD手冊。當然,基本上他是對的,你應該讀一讀。 RTFM有一個年輕的親戚。如果答案是"STFW (Search The Fucking Web)",回 答者認為你應該到TMD的網上去搜索。基本上,他也是對的,你就去找吧。 通常,用這兩句之一回答你的人會給你一份包含你需要內容的手冊或者一個網址, 而且他們打這些字的時候正在閱讀著。這些答復意味著回答者認為(1). 你需要的 信息非常容易獲得;(2). 你自己去搜索這些信息比灌給你能讓你學到更多。 別為這個而不爽;依照黑客的標準,他沒有對你的要求視而不見,已經能大致能表 示對你的關注。你應該對他祖母般的慈祥表示感謝。 ---------- 還是不懂 ---------- 如果你不是很理解答案,別立刻要求對方解釋。象你以前試著自己解決問題時那樣 (利用手冊,FAQ,網絡,身邊的高手),去理解它。如果你真的需要對方解釋, 記得表現出你已經學到了點什么。 比方說,如果我回答你:"看來似乎是zEntry被阻塞了;你應該先清除它。",然 后: 一個很糟的后續問題:"zEntry是什么?" 聰明的問法應該是這樣:"哦~~~我看過幫助了但是只有-z和-p兩個參數中提到了 zEntry而且還都沒有清楚的解釋:<你是指這兩個中的哪一個嗎?還是我看漏了什么 ?" -------- 面對無禮 -------- 黑客圈子里很多貌似粗魯的言行并非有意冒犯。更恰當的說,這是直率、不說廢話 的溝通方式的產物,這種溝通方式源于人們關注問題的解決--多過讓人感受溫暖親 情然而卻依舊糊里糊涂--的天性。 如果你覺得受到粗魯的對待,請保持冷靜。如果真有人表現粗野,通常會有列表/ 新聞組/論壇的長輩找他談心,如果沒有這樣,而你又大發脾氣,則很可能對方的 言行是黑客社區行為規范許可內,而你被認為是有過錯的。這會不利于你得到信息 或者幫助。 另一方面,你偶爾也會無緣無故有粗野的言行和心態。上述現象的另一面是,人們 允許狠狠打擊真正的冒犯者,用尖刻的言語剖析他們的不當言行。如果你真決定這 樣做,先仔細又仔細的掂量一下你自己的分量。合理的粗魯與發動一場無意義的論 戰之間只隔了一條細細的線,冒冒失失撞上去的黑客不在少數;如果你是新手或者 門外漢,不犯這種錯的機會是很渺茫的。如果你想得到信息而不是來胡鬧,別冒險 回復,最好把手從鍵盤上拿開。 (有些人聲稱多數黑客有孤僻癥或者社交障礙綜合征的輕度癥狀,而且確實缺少部 分有助"常人"進行社交行為的腦組織結構。這也許是真的,也許不是。如果你自 己不是黑客,那么,把我們想象成腦部有缺陷的人有助你面對我們的古怪。有話直 說,我們無所謂;我們樂于按自己的想法生活,而且總是對醫學概念持相當懷疑的 態度。) 在下一節里,我們將談論另一個話題;當你行差踏錯時可能遇到的"無禮"。 ================ 決不要象個失敗者 ================ 很有可能,你在黑客社區的論壇會受到很多公開的攻擊--用本文提到的各種方式或 類似的方法,而且很可能會有各式各樣的旁敲側擊來告訴你你有多討厭。 如果噩夢成真,你能做的最糟的事就是為此發牢騷,抱怨受到人身攻擊,要求對方 道歉,尖叫,屏住呼吸,威脅要控訴對方,向他老板告狀,不掀起馬桶座圈,等等 等等。然而,你應該這樣: 由它去吧,這沒什么大不了的。實際上這么做是恰當的和有益的(主要是有利身心 健康:)。 社區的規范不靠社區,而是靠積極推行它們的人們來維護,這種維護是公開的,顯 而易見的。別抱怨說一切批評都應該通過私信傳送,它本來就不該那樣。當別人指 出你的話有錯誤,或者他有不同觀點的時候,堅持認為他在羞辱你是沒有用的。這 些都是失敗者的態度。 有那么一些黑客論壇,出于對高度自謙的誤解,禁止參與者張貼專給人找茬的帖子 ,而且被告知"如果不愿幫助用戶,那就閉嘴。",他們認為,引開參與者的話題 ,只會使得他們陶醉在毫無意義的喋喋不休中,從而失去了技術論壇的意義。 夸張的"友善"(以那種方式)還是有用的幫助:你自己選擇吧。 記住:當黑客說你很煩人,(無論用多么粗暴的語言)警告你別再那樣做了,他的 本意并非是針對(1)你,以及(2)他的社區。他本來可以輕易的忽略你,把你從他的 視線中抹去。如果你無法接受要向他表示感激,至少應該表現出你的氣度,別抱怨 ,別期望只因為你是新人,你有戲劇般的敏感脆弱的神經和自封的權利,而受到易 碎玩偶般的特別對待。 ========== 三思而后問 ========== 以下是幾個經典蠢問題,以及黑客在拒絕回答時的心中所想: 問題:我能在哪找到X程序? 問題:我的程序/配置/SQL申明沒有用 問題:我的Windows有問題,你能幫我嗎? 問題:我在安裝Linux(或者X)時有問題,你能幫我嗎? 問題:我怎么才能破解root帳號/竊取OP特權/讀別人的郵件呢? 提問:我能在哪找到X程序? 回答:就在我找到它的地方啊蠢貨--搜索引擎的那一頭。天吶!還有人不會用 Google嗎? 提問:我的程序(配置、SQL申明)沒有用 回答:這不算是問題吧,我對找出你的真正問題沒興趣--如果要我問你二十個問題 才找得出來的話--我有更有意思的事要做呢。在看到這類問題的時候,我的反應通 常不外如下三種: 1. 你還有什么要補充的嗎? 2. 真糟糕,希望你能搞定。 3. 這跟我有什么鳥相關? 提問:我的Windows有問題,你能幫我嗎? 回答:能啊,扔掉萎軟的垃圾,換Linux吧。 提問:我在安裝Linux(或者X)時有問題,你能幫我嗎? 回答:不能,我只有親自在你的電腦上動手才能找到毛病。還是去找你當地的 Linux用戶組尋求手把手的指導吧(你能在這兒找到用戶組的清單)。 提問:我怎么才能破解root帳號/竊取OP特權/讀別人的郵件呢? 回答:想要這樣做,說明你是個卑鄙小人;想找個黑客幫你,說明你是個白癡! ============== 好問題,壞問題 ============== 最后,我舉一些例子來說明,怎樣聰明的提問;同一個問題的兩種問法被放在一起 ,一種是愚蠢的,另一種才是明智的。 蠢問題:我可以在哪兒找到關于Foonly Flurbamatic的資料? 這種問法無非想得到"STFW"這樣的回答。 聰明問題:我用Google搜索過"Foonly Flurbamatic 2600",但是沒找到有用的 結果。誰知道上哪兒去找對這種設備編程的資料? 這個問題已經STFW過了,看起來他真的遇到了麻煩。 蠢問題:我從FOO項目找來的源碼沒法編譯。它怎么這么爛? 他覺得都是別人的錯,這個傲慢自大的家伙 聰明問題:FOO項目代碼在Nulix 6.2版下無法編譯通過。我讀過了FAQ,但里面沒 有提到跟Nulix有關的問題。這是我編譯過程的記錄,我有什么做得不對的地方嗎 ? 他講明了環境,也讀過了FAQ,還指明了錯誤,并且他沒有把問題的責任推到別人 頭上,這個家伙值得留意。 蠢問題:我的主板有問題了,誰來幫我? 普通黑客對這類問題的回答通常是:"好的,還要幫你拍拍背和換尿布嗎?" , 然后按下刪除鍵。 聰明問題:我在S2464主板上試過了X、Y和Z,但沒什么作用,我又試了A、B和C。 請注意當我嘗試C時的奇怪現象。顯然邊帶傳輸中出現了收縮,但結果出人意料。 在多處理器主板上引起邊帶泄漏的通常原因是什么?誰有好主意接下來我該做些什 么測試才能找出問題? 這個家伙,從另一個角度來看,值得去回答他。他表現出了解決問題的能力,而不 是坐等天上掉答案。 在最后一個問題中,注意"告訴我答案"和"給我啟示,指出我還應該做什么診斷 工作"之間微妙而又重要的區別。 事實上,后一個問題源自于2001年8月在Linux內核郵件列表上的一個真實的提問。 我(Eric)就是那個提出問題的人。我在Tyan S2464主板上觀察到了這種無法解釋 的鎖定現象,列表成員們提供了解決那一問題的重要信息。 通過我的提問方法,我給了大家值得玩味的東西;我讓人們很容易參與并且被吸引 進來。我顯示了自己具備和他們同等的能力,邀請他們與我共同探討。我告訴他們 我所走過的彎路,以避免他們再浪費時間,這是一種對他人時間價值的尊重。 后來,當我向每個人表示感謝,并且贊賞這套程序(指郵件列表中的討論--譯者注 )運作得非常出色的時候,一個Linux內核郵件列表(lkml)成員表示,問題得到 解決并非由于我是這個列表中的"名人",而是因為我用了正確的方式來提問。 我們黑客從某種角度來說是擁有豐富知識但缺乏人情味的家伙;我相信他是對的, 如果我象個乞討者那樣提問,不論我是誰,一定會惹惱某些人或者被他們忽視。他 建議我記下這件事,給編寫這個指南的人一些指導。 ================ 找不到答案怎么辦 ================ 如果仍得不到答案,請不要以為我們覺得無法幫助你。有時只是看到你問題的人不 知道答案罷了。沒有回應不代表你被忽視,雖然不可否認這種差別很難區分。 總的說來,簡單的重復張貼問題是個很糟的想法。這將被視為無意義的喧鬧。 你可以通過其它渠道獲得幫助,這些渠道通常更適合初學者的需要。 有許多網上的以及本地的用戶組,由狂熱的軟件愛好者(即使他們可能從沒親自寫 過任何軟件)組成。通常人們組建這樣的團體來互相幫助并幫助新手。 另外,你可以向很多商業公司尋求幫助,不論公司大還是小(Red Hat和 LinuxCare就是兩個最常見的例子)。別為要付費才能獲得幫助而感到沮喪!畢竟 ,假使你的汽車發動機汽缸密封圈爆掉了--完全可能如此--你還得把它送到修車鋪 ,并且為維修付費。就算軟件沒花費你一分錢,你也不能強求技術支持總是免費的 。 對大眾化的軟件,就象Linux之類而言,每個開發者至少會有上萬名用戶。根本不 可能由一個人來處理來自上萬名用戶的求助電話。要知道,即使你要為幫助付費, 同你必須購買同類軟件相比,你所付出的也是微不足道的(通常封閉源代碼軟件的 技術支持費用比開放源代碼軟件要高得多,而且內容也不那么豐富)。 |
據醫學報告指出每天使用計算機4-6小時,
三年后得到癌癥的機率比正常人多26﹪。
中午睡覺時要記得關計算機!
你是否常覺得頭重重的或記憶力帥退呢?
趴著睡覺的時候要記的把計算機關機,不只是把屏幕關掉而已,因為只把屏幕關掉是無法杜絕輻射線的,而且我們都是趴著睡,頭直接對著計算機,哪天得了老人癡呆癥或腦瘤就來不及了!輻射線真的很可怕的!!小心啊~健康重于一切!
計算機族的殺手——胸廓出口癥
常坐在計算機桌前的你,是否一坐就是好幾個小時而且坐姿不正確,總感到莫名肩頸疼痛,甚至于無心工作?現在請你作個小測驗,請你將你的頭向左側方向望去,然后將你的頭45度朝下慢慢彎下去,動作做到這里,你的脖子頸肩是否感到不正常的酸痛?對假使你有上述癥狀,你可要小心了,因為你很可能得到現代計算機文明病“胸廓出口癥候群”的受害者。
殺手原來是“計算機”
計算機一族的您或許常納悶為何常常感到腰酸背痛,身體抵抗力越來越弱,精神常常無法集中,您絕無法想象原因出在“計算機”,電腦所散發出的輻射電波往往為人們所忽視,依國際MPRⅡ防輻射安全規定,在50cm距離內必需≦25V/m的輻射曝露量,但您知道計算機的輻射量是多少嗎?
告訴您
Ⅰ、鍵盤1000V/m,
Ⅱ、鼠標450V/m,
Ⅲ、屏幕218V/m,
Ⅳ、主機170V/m,
Ⅴ、Notebook 2500V/m,
輻射電磁波對人體的八大傷害
1.細胞癌化促進作用,
2.荷爾蒙不正常,
3.鈣離子激烈流失,
4.癡呆癥的引發,
5.異常妊娠異常生產,
6.高血壓心臟病,
7.電磁波過敏癥,
8.自殺者的增加。