stanford-oval/wikipedia huggingface dataset:
水力壓裂對環境的影響
地震 > 水力壓裂誘發地震

截至2016年8月，已知至少有9起因水力壓裂而導致斷層重新激活的案例，而地震強度足以讓住在地表的人感受到：在加拿大，阿爾伯塔省發生3起（M4.8M4.4和M4.4）和英屬哥倫比亞省發生3起（M4.6，M4.4和M3.8）、在美國，俄克拉荷馬州發生1起（M2.8）和俄亥俄州發生1起（M3.0），和在英國，蘭開夏郡發生2起（M2.3和M1.5）。
地震 > 污水處理井誘發地震

根據美國地質調查局（USGS），在美國大約30,000口用於棄置石油和天然氣作業廢液的井中，只有一小部分曾誘發足以引起公眾關注的地震。 雖然這些地震的震級很小，但USGS表示無法保證不會發生更大的地震。此外，地震的頻率一直在增加。 2009年，橫跨阿拉巴馬州和蒙大拿州的地區發生50次M3.0級以上的地震，2010年發生87次。同一地區在2011年發生134次，比在20世紀發生的地震次數增加6倍。也有人擔心地震可能會把原先未足以耐震的地下油氣和輸水管線，以及油氣井損壞。
USGS在2012年發佈的一項研究報告稱，美國中部的M3級及以上地震發生率“正顯著”增加中，從2001年開始到2011年，其頻率達到20世紀水準的6倍。總體增長與一些特定地區的地震增加有關聯：科羅拉多州南部的{{le|拉頓盆地|Raton Basin｝｝（當地有開採煤層氣活動），以及俄克拉荷馬州中部和南部以及阿肯色州中部的產氣區。雖然分析顯示這種增加“幾乎能肯定是人為所導致”，但USGS指出：“我們的研究顯示實際的水力壓裂過程少有是導致有感地震的直接因素。”據說增加廢水注入處理井的次數是最有可能造成地震增加的原因。將石油和天然氣作業產生的廢水（包括水力壓裂產生的廢水）注入處理井中可能會導致更大的低震級震顫，最高震度可達3.3Mw。
噪音

每個鑽井平台（平均包含10口鑽孔）在準備和進行水力壓裂過程時會持續有大約800至2,500天的活動，其產生的噪音會影響到附近的居民。此外，與水力壓裂相關的運輸活動也會產生噪音。 水力壓裂作業（例如交通運輸、燃燒多餘氣體的火焰）造成的噪聲污染通常被當作是造成心理困擾以及兒童學習成績不佳的原因。由井泵產生的低頻噪音會導致煩躁、不安和疲勞。
英國陸上石油和天然氣 (UKOOG) 是個英國當地的產業協會，UKOOG制定一份章程，其中含有降低鑽井場地噪音問題的建議。
安全問題

2013年7月，美國聯邦鐵路總署把水力壓裂化學品列為導致油罐車發生腐蝕的“可能原因”，由於油罐車鏽蝕，會有造成油污染的可能性。
社區影響

受到影響的社區通常已是脆弱者，居民通常為窮人、農村人口或是原住民，這些人可能會連續幾代都受到水力壓裂的影響。石油公司與農民爭奪資源，加劇這些人及其家庭的壓力。原住民與農業社區尤其會受到水力壓裂的影響，因為他們對所居住的土地有長期的感情，並賴以為生，而水力壓裂將此種聯繫破壞。美洲原住民，特別是那些生活在保留地的，會特別容易受到壓裂活動的影響；當地部落一方面很想與石油公司合作以獲得收入，但在另一方面又需經常進行法律鬥爭以保護他們的主權和土地上的自然資源。
政策與科學

目前對於制定水力壓裂監管政策，先有關於如何做風險管理的辯論，而對應的，又有如何做風險評估的辯論。
這兩個主要流派是根據科學的風險評估並採取措施，通過危害分析而規避這些有害風險，或採用預防原則，在風險被明確識別之前就採取行動。在已有水力壓裂的社區中，風險評估的相關性和可靠性也在環保團體、衛生醫學科學家和行業領導者之間引發辯論。有人覺得風險被誇大，認為目前的研究不足以表明水力壓裂與不利健康影響之間的聯繫，而對另一些人來說，風險顯而易見，但因經費不足而無法進行評估。
從不同角度出發而會產生不同的監管方法。例如，法國和美國佛蒙特州基於預防原則而禁止水力壓裂。但美國有些州採用的是風險評估（危害分析）方法，而引起何者屬於水力壓裂風險的辯論。
而在英國，監管框架主要是根據政府於2012年委託皇家協會和皇家工程學院所作的研究報告而制定，這份研究報告目的是確定水力壓裂的問題，並為監管機構提供建議。報告由教授羅伯特·梅爾（英语：）領銜撰寫，提出10項建議，涵蓋如地下水污染、油氣井完整性、地震風險、氣體洩漏、水資源管理、環境風險、風險管理最佳實踐等領域，還包括對監管機構和研究委員會的建議。值得注意的是，該報告指出如果依據有效法規，同時採用最佳實踐運作，相關的風險足以控制。
一份在2013年發表的評論，其結論是在美國，由於法律調查有保密條款，在環境影響研究中，經由同儕評審的研究工作會因而受到妨礙。
水力壓裂對環境影響的研究有許多科學上的限制。主要的是難以制定有效的監測程序和協議，有以下幾個原因：
不同壓裂場地在生態系統、作業規模、鑽井平台密度和品管措施方面具有差異性，而難以制定出標準化的檢測協議。
隨著日益增多的壓裂場地開發，不同場地間相互作用的機會增加，而讓影響大幅增加，其複雜性讓單獨針對一個場地的監測難以控制。這些累積出的影響不易衡量，因為許多發展是以非常緩慢的速率進行。
由於水力壓裂使用到大量化學品，因此在設定基線數據時會有挑戰性。此外，目前對於水力壓裂液中化學物質的相互作用以及個別成分的去向尚無充分的研究。
參見

波康比抗議水力壓裂事件（英语：）
誇德里拉資源公司（英语：）
定向鑽孔
發電對環境的影響
石油產業對環境的影響
油頁岩產業對環境的影響
2012-2014年羅馬尼亞的頁岩氣抗議活動（英语：）
參考書目

Broomfield, Mark.  (PDF) (报告). European Commission: vi–xvi. 2012-08-10  [2014-09-29]. ED57281. （原始内容存档于2020-12-24）.  |issue=被忽略 (帮助)
Brown, Valerie J. . Environmental Health Perspectives. February 2007, 115 (2): A76. PMC 1817691 . PMID 17384744. doi:10.1289/ehp.115-a76.
Ground Water Protection Council; ALL Consulting.  (PDF) (报告). DOE Office of Fossil Energy and National Energy Technology Laboratory: 56–66. April 2009  [2012-02-24]. DE-FG26-04NT15455. （原始内容存档 (PDF)于2020-10-17）.
Healy, Dave.  (PDF) (报告). Environmental Protection Agency. July 2012  [2013-07-28]. （原始内容存档 (PDF)于2020-11-28）.
Jenner, Steffen; Lamadrid, Alberto J.  (PDF). Energy Policy. 2013, 53 (53): 442–453  [2014-09-28]. doi:10.1016/j.enpol.2012.11.010. （原始内容 (PDF)存档于2014-10-19）.
Mair (Chair), Robert.  (PDF) (报告). The Royal Society and the Royal Academy of Engineering. June 2012  [2014-10-10]. （原始内容存档 (PDF)于2013-12-10）.
Moniz (chair), Ernest J.; Jacoby (Co-Chair), Henry D.; Meggs (Co-Chair), Anthony J. M.  (PDF). Massachusetts Institute of Technology. June 2011  [2014-10-08]. （原始内容 (PDF)存档于2013-03-12）.
Zoback, Mark; Kitasei, Saya; Copithorne, Brad.  (PDF) (报告). Worldwatch Institute: 9. July 2010  [2012-05-24]. （原始内容存档 (PDF)于2018-05-21）.
|  论 编人類對環境的影響 |
| --- | --- |
一般:  人類世  环境问题 問題列表  人類影響（英语：） 海洋生物（英语：）  全球公眾關注問題列表（英语：）  影響評估  地球限度理論 
產生原因:  農業 大麻種植（英语：）  灌溉（英语：）  肉類生產（英语：）  可可生產（英语：）  棕櫚油（英语：）  能源產業 生物燃料（英语：）  生質柴油  煤炭（英语：）  核能發電  油頁岩（英语：）  石油  水庫  風力發電（英语：）  基因污染  破壞環境罪（英语：）  工业化  土地利用  制造业 清潔劑（英语：）  混凝土  塑膠  奈米科技（英语：）  油漆（英语：）  造紙  農藥（英语：）  藥物與個人護理用品  海洋生物 捕魚（英语：）  沿著海洋食物網捕魚（英语：）  海洋污染  过度捕捞  採礦（英语：）  過度消耗  過度抽取地下水（英语：）  过度开发  过度放牧  颗粒物  污染  採沙與採石  旅遊（英语：）  交通運輸 航空業  道路（英语：）  道路生態學（英语：）  航運業（英语：）  城市化 都市蔓延  戰爭（英语：） 
影響:  對生物多樣性的威脅 生物多樣性喪失（英语：）  兩棲動物數量喪失（英语：）  昆蟲數量喪失（英语：）  气候变化 失控的氣候變化  珊瑚礁（英语：）  森林砍伐  土地退化  沙漠化  生態滅絕行為（英语：）  侵蚀  环境退化  水循環  棲息地破壞  全新世滅絕事件  氮循環（英语：）  水土流失  土地消耗（英语：）  地表變化對氣候的影響（英语：）  绿化带的丧失  磷循環  海洋酸化  臭氧層空洞  資源枯竭  水污染  水资源匮乏 
緩解措施（英语：）:  新能源車（英语：）  生育控制  清洁生产  氣候變化減緩措施（英语：）  气候工程  社區恢復力（英语：）  脫鉤（英语：）  生态工程  环境工程  環境影響緩解措施（英语：）  工业生态学  生態系統緩解庫（英语：）  有機農業  資源回收  林地復育 城市（英语：）  復原生態學（英语：）  可持續消費（英语：）  廢棄物減量（英语：） 
   维基共享    分类  評估
2019年至2020年澳洲職業足球聯賽

| --- | --- |

賽季資料
: 2019–20
賽事日期: 2019年10月11日 – 2020年8月30日
賽季成績總結
冠軍: 悉尼 FC (第5個冠軍)
冠軍: 悉尼 FC (第4個冠軍)
亞足聯冠軍聯賽: 悉尼 FC 墨爾本城 布里斯班獅吼
賽季統計
比賽場數: 148場
入球總數: 431球（每場2.91球）
觀眾人數: 1,055,913人（每場7,135人） 
賽季紀錄
: 占美·麥卡倫(23球)
最大主場勝仗: 珀斯光荣 6–2 纽卡斯尔喷气机 (2019年12月21日) 西部聯 6–2 中岸水手 (2020年3月1日)
最大客場勝仗: 纽卡斯尔喷气机 0–4 墨爾本城 (2019年12月6日)
最多入球: 珀斯光荣 6–2 纽卡斯尔喷气机 (2019年12月21日) 西部聯 6–2 中岸水手 (2020年3月1日)
最長連勝: 悉尼 FC (6場)
最長不敗: 悉尼 FC (12場)
最長連敗: 中岸水手 (10場)
最長不勝: 中岸水手 (10場)
最多觀眾: 33,523 墨尔本胜利 0–0 墨爾本城 (2019年10月12日)
最少觀眾: 1,035 中岸水手 1–1 西悉尼流浪者 (2020年7月27日)
← 2018–19 2020–21 → 
2019–20年澳洲職業足球聯賽（英語：），是澳大利亞職業足球聯賽成立以來的第15個球季。原訂常規賽賽事由2019年10月11日開始，至2020年4月26日完結，但後來受到2019新型冠状病毒病疫情影响，推遲至2020年8月19日完結。疫情影响下澳大利亞足球協會宣佈由3月至7月期間賽事暫停。 最後賽事於7月17日重新開始，並且順利於8月舉行季後賽及決賽賽事。
球隊

本賽季將由11支球隊角逐，西部聯是新加入球隊。
阿德莱德联
布里斯班獅吼
中岸水手
墨爾本城
墨尔本胜利
纽卡斯尔喷气机
珀斯光荣
悉尼 FC
威靈頓鳳凰
西部聯
西悉尼流浪者
| 球隊 | 城市 | 球場 | 容納觀眾數 |
| --- | --- | --- | --- |
| 阿德莱德联 | 阿德莱德 | 海馬許體育場 | 16,500 |
| 布里斯班獅吼 | 布里斯班 | 布里斯本體育場 羅賓那體育場（英语：） 海豚體育場（英语：） | 52,500 27,000 10,000 |
| 中岸水手 | 戈斯福德 | 中岸球場 | 20,059 |
| 墨爾本城 | 墨尔本 | AAMI公園球場 | 30,050 |
| 墨尔本胜利 | 墨尔本 | 漫威體育館 AAMI公園球場 | 56,347 30,050 |
| 纽卡斯尔喷气机 | 纽卡斯尔 | 紐卡索國際體育中心 | 33,000 |
| 珀斯光荣 | 珀斯 | HPF公園球場（英语：） | 20,500 |
| 悉尼 FC | 悉尼 | 禧年體育場（英语：） 萊卡特體育場（英语：） | 20,500 20,000 |
| 威靈頓鳳凰 | 惠灵顿 | 伊甸公園 西太平洋銀行體育場 | 50,000 34,500 |
| 西悉尼流浪者 | 悉尼 | 西澳銀行體育場 | 30,000 |
| 西部聯 | 墨尔本 | 卡迪尼亞公園（英语：） 惠騰橢圓球場（英语：） 尤里卡體育場（英语：） | 36,000 12,000 11,000 |
球隊 > 球隊人員及球衣贊助

| 球隊 | 領隊 | 隊長 | 球衣供應商 | 主贊助商 |
| --- | --- | --- | --- | --- |

| 阿德莱德联 |  卡爾·福爾特（英语：） (代理) |  邁克爾·雅庫布森（英语：） | 马克龙 | 弗林德斯大學 #BookThemOut（英语：） |
| 布里斯班獅吼 |  華倫·穆（英语：） |  湯姆·阿爾德雷德 | 茵寶 | Actron Air |
| 中岸水手 |  艾倫·斯塔西奇（英语：） |  麥·西蒙 | 茵寶 | 瑪氏食品 MATE |
| 墨爾本城 |  埃里克·蒙巴埃爾（英语：） |  史葛·占美遜 | PUMA | 阿提哈德航空 |
| 墨尔本胜利 |  格蘭特·佈雷伯納（英语：） (代理) |  空缺 | 愛迪達 | Metricon（英语：） |
| 纽卡斯尔喷气机 |  卡尔·罗宾森 |  尼格尔·布格阿德 | Viva Sports | #FootballForFires  Inspirations Paint |
| 珀斯光荣 |  托尼·波波维奇 |  迭戈·卡斯特羅（英语：） | 马克龙 | 必和必拓 |
| 悉尼 FC |  史提夫·哥里卡 |  阿歷斯·韋堅遜 | Under Armour | 星億賭場 |
| 威靈頓鳳凰 |  烏夫·塔萊（英语：） |  斯蒂芬·泰勒 | Paladin Sports | 华为 |
| 西悉尼流浪者 |  讓·保羅·德馬里尼（英语：） |  米歇爾·杜基 | 耐克 | Centuria JD Sports（英语：） |
| 西部聯 |  馬可·魯丹（英语：） |  亚历山德罗·迪亚曼蒂 | 卡帕 | Probuild |
常規賽 > 積分榜

| 排名 | 隊伍 论 编 | 賽 | 勝 | 和 | 負 | 得 | 失 | 差 | 分 | 獲得資格 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 悉尼FC (C) | 26 | 16 | 5 | 5 | 49 | 25 | +24 | 53 | 晉級至季後賽及亚足联冠军联赛分組賽 |
| 2 | 墨爾本城 | 26 | 14 | 5 | 7 | 49 | 37 | +12 | 47 | 晉級至季後賽及亚足联冠军联赛附加賽 |
| 3 | 威靈頓鳳凰 | 26 | 12 | 5 | 9 | 38 | 33 | +5 | 41 | 晉級至季後賽 |
| 4 | 布里斯班獅吼 | 26 | 11 | 7 | 8 | 29 | 28 | +1 | 40 | 晉級至季後賽及亚足联冠军联赛附加賽 |
| 5 | 西部聯 | 26 | 12 | 3 | 11 | 46 | 37 | +9 | 39 | 晉級至季後賽 |
| 6 | 珀斯光荣 | 26 | 10 | 7 | 9 | 43 | 36 | +7 | 37 | 晉級至季後賽 |
| 7 | 阿德莱德联 | 26 | 11 | 3 | 12 | 44 | 49 | −5 | 36 |  |
| 8 | 纽卡斯尔喷气机 | 26 | 9 | 7 | 10 | 32 | 40 | −8 | 34 |  |
| 9 | 西悉尼流浪者 | 26 | 9 | 6 | 11 | 35 | 40 | −5 | 33 |  |
| 10 | 墨尔本胜利 | 26 | 6 | 5 | 15 | 33 | 44 | −11 | 23 |  |
| 11 | 中岸水手 | 26 | 5 | 3 | 18 | 26 | 55 | −29 | 18 |  |
資料來源：A-League
排名規則：1) 積分； 2) 得失球差；3) 進球數
 冠軍
備註：
1 2 3 4 5  前兩名的球隊將直隊進入季後賽的半決賽階段，而排名第三至第六的球隊則進行淘汰賽。
↑  因為威靈頓鳳凰不是亚洲足球联合会成員國家的球隊，所以不能出席亚洲足球联合会舉辦的洲際賽事。
常規賽 > 對賽成績

|  论 编 主隊 ＼ 客隊 | ADE | BRI | CCM | MCY | MVC | NEW | PER | SYD | WEL | WSW | WUN | ADE | BRI | CCM | MCY | MVC | NEW | PER | SYD | WEL | WSW | WUN |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 阿德莱德联 |  | 1–0 | 2–0 | 3–1 | 3–1 | 2–1 | 5–3 | 2–3 | 1–2 | 2–3 | 1–5 |  |  |  |  | 1–0 | 0–3 |  | 1–1 |  |  |  |
| 布里斯班獅吼 | 2–1 |  | 2–0 | 4–3 | 0–1 | 1–0 | 1–1 | 1–1 | 1–0 | 3–1 | 0–2 | 0–1 |  | 1–0 | 2–2 |  |  |  |  |  |  |  |
| 中岸水手 | 1–3 | 0–1 |  | 2–4 | 3–2 | 1–1 | 0–3 | 0–3 | 1–3 | 1–3 | 1–0 | 2–1 |  |  |  |  | 0–0 |  |  |  | 1–1 |  |
| 墨爾本城 | 2–1 | 1–0 | 3–1 |  | 1–2 | 2–0 | 0–3 | 2–0 | 3–2 | 1–1 | 3–2 | 2–2 |  |  |  | 2–1 |  | 0–0 |  |  |  |  |
| 墨尔本胜利 | 2–1 | 1–2 | 2–3 | 0–0 |  | 4–0 | 1–0 | 0–3 | 1–1 | 1–2 | 2–3 |  |  |  |  |  |  |  | 1–4 | 0–0 |  | 1–2 |
| 纽卡斯尔喷气机 | 1–2 | 1–1 | 4–3 | 0–4 | 1–1 |  | 1–1 | 1–2 | 3–0 | 2–0 | 0–0 |  |  |  | 2–1 |  |  | 2–1 |  |  |  | 1–0 |
| 珀斯光荣 | 3–0 | 1–1 | 1–2 | 2–3 | 2–2 | 6–2 |  | 1–3 | 4–2 | 2–0 | 0–2 |  |  | 1–0 |  | 0–4 |  |  |  | 1–2 |  |  |
| 悉尼 FC | 2–1 | 5–1 | 1–0 | 2–1 | 2–1 | 4–1 | 0–0 |  | 2–1 | 0–1 | 1–2 |  | 1–0 |  |  |  | 1–2 |  |  | 3–1 |  |  |
| 威靈頓鳳凰 | 1–1 | 2–1 | 2–1 | 1–0 | 3–0 | 2–1 | 1–2 | 2–2 |  | 2–1 | 0–1 |  | 1–1 |  |  |  |  |  |  |  | 2–0 | 2–0 |
| 西悉尼流浪者 | 5–2 | 0–0 | 2–1 | 2–3 | 2–1 | 1–1 | 0–1 | 1–0 | 1–0 |  | 1–1 |  | 1–2 |  |  |  |  | 1–3 | 1–1 |  |  |  |
| 西部聯 | 3–4 | 0–1 | 3–0 | 1–2 | 3–1 | 0–1 | 1–1 | 0–2 | 1–3 | 2–1 |  |  |  | 6–2 | 1–3 |  |  |  |  |  | 5–3 |  |
資料來源：A-League
藍色：主隊取勝；黃色：；紅色：客隊取勝。
- 尚未進行的賽事欄位中若顯示「a」，表示有相關條目講述雙方的對賽組合。
季後賽 > 初賽

| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| 2020年8月22日  |  威靈頓鳳凰  | 0–1 |  珀斯光荣  | 悉尼 |
| 17:00 AEST |  | 報告 |  喬爾·切斯（英语：）  18' | 場館： 西澳銀行體育場 入場人數： 0 ： Alex King |
| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| 2020年8月23日  |  布里斯班獅吼  | 0–1 |  西部聯  | 悉尼 |
| 18:00 AEST |  | 報告 |  亚历山德罗·迪亚曼蒂  21' | 場館： 西澳銀行體育場 入場人數： 0 ： 克里斯·比思 |
季後賽 > 準決賽

| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| 2020年8月26日  |  墨爾本城  | 2–0 |  西部聯  | 悉尼 |
| 17:00 AEST |  占美·麥卡倫  68'（）  今井智基  84'（乌龙球） | 報告 |  | 場館： 西澳銀行體育場 入場人數： 1,897 ： 阿里-礼萨·法加尼 |
| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| 2020年8月26日  |  悉尼 FC  | 2–0 |  珀斯光荣  | 悉尼 |
| 20:10 AEST |  米洛什·宁科维奇  24'  亚当·勒·冯德尔  28' | 報告 |  | 場館： 西澳銀行體育場 入場人數： 3,477 ： Alex King |
季後賽 > 決賽

悉尼 FC v 墨爾本城
| 悉尼 FC | 1–0  （加時賽） | 墨爾本城 |
| --- | --- | --- |
| 瑞恩·格蘭特  100' | 報告 |  |
洛韋 (堪薩斯州)

| 洛韋 Lowe |
| --- | --- |
非建制地區
洛韋洛韋在堪薩斯州的位置
坐标： 38°01′59″N 100°59′34″W﻿ / ﻿38.03306°N 100.99278°W﻿ / 38.03306; -100.99278
國家: 美国
州份: 堪薩斯州
縣: 芬尼縣
海拔: 890 公尺（2,920 英尺）
时区: 北美中部时区（UTC-6）
 • 夏时制: CDT（UTC-5）
電話區號: 620
GNIS ID: 484571
洛韋（英語：）是位於美國堪薩斯州芬尼縣的一個非建制地區。該地的面積和人口皆未知。
地理

洛韋所處的海拔為高於海平面890米（即2920英呎），而該地所採用的時區為UTC-6，即北美中部時區（CST）。同時該地設有夏令時間，為UTC-6調快一小時，即UTC-5（CDT）。
參考文獻

↑  . . United States Geological Survey.
|  论 编芬尼縣行政區劃 |
| --- | --- | --- |
：加登城
| 城市 |  加登城  霍爾科姆  | Map of Kansas highlighting Finney County |
| 非建制地區 |  埃米嫩斯  弗倫德  加諾  卡爾維斯塔  洛韋  曼斯菲爾德  彼得森  皮爾斯維爾  普萊梅爾  昆比  拉瓦納  里查  羅德基  坦尼斯  沃爾夫  | Map of Kansas highlighting Finney County |
| 鎮區 |  加登城鎮區  加菲爾德鎮區  艾文霍鎮區  皮爾斯維爾鎮區  普萊森特瓦利鎮區  舍洛克鎮區  特里鎮區  | Map of Kansas highlighting Finney County |
季索韋茨

季索韋茨是斯洛伐克的城鎮，位於該國中部，由班斯卡-比斯特里察州負責管轄，面積123.43平方公里，海拔高度411米，該地區自青銅時代有人類居住，2005年人口4,092。
友好城市

匈牙利普特諾克
捷克卢德盖若维采（英语：）
波蘭新日米格鲁德（英语：）
美国仙納度
外部連結

Official website（页面存档备份，存于）
建國南路

建國南路是部份城市的重要道路：
建國南北路 (臺北市)，為臺北市的重要道路。
建國南路 (台中市)，為臺中市南區內的道路，與建國北路為獨立的兩條道路，兩者隔台鐵台中線相望。
建國南路 (嘉兴市)，
建国南路 (杭州)，杭州的一条南北走向的道路，北接建国北路。
组件对象模型

| 「」的各地常用名稱 |
| --- | --- |
中国大陸: 
臺灣: 
组件对象模型（英語：，縮寫）是微軟的一套软件组件的二进制接口标准。这使得跨编程语言的进程间通信、动态对象创建成为可能。COM是多项微软技术与框架的基础，包括OLE、OLE自动化（英语：）、ActiveX、COM+、DCOM、Windows shell、DirectX、Windows Runtime。COM與實作語言種類無關，如此使用它實作的物件可用在不同於開發它的環境，甚至跨越機器邊界。對製作良好的物件，COM使物件得以重複使用，而無須知道其內部實作，因為它強制實作者提供與實作分離、確切定義的介面。各語言不同的儲存配置語意使组件对象模型用物件參照計數()管理其自身的產生與銷毀。不同介面間型別轉換的鑄型用 QueryInterface 方法。
概要

COM的核心是一组组件对象间交互的规范，定义了组件对象如何与其使用者通过二进制接口标准进行交互，COM的接口是组件的类型纽带。
除了规范之外，COM还是一个称为“COM库”的实现，包括若干API函数，用于COM程序的创建与使用。
COM还提供定位服务的实现，可以根据Windows系统注册表，从一个类标识（CLSID）来确定组件的位置。
COM采用自己的IDL来描述组件的接口（interface），支持多接口，解决版本兼容问题。COM为所有组件定义了一个共同的父接口IUnknown。GUID 是一个 128 位整数（16 字节），COM将其用于计算机和网络的唯一标识符。
除了基本规范和系统实现之外，COM的构成还包括永久存储、绰号（moniker智能命名/标记）和统一数据转移（UDT = Uniform Data Transfer）三个核心的操作系统部件。
COM实质上是一种语言无关的对象实现方式，这使其可以在创建环境不同的场合、甚至跨计算机的分布环境下被复用。COM允许复用这些对象，而不必知道对象内部是如何实现，因为组件实现者必须提供良好定义的接口从而屏蔽实现细节。通过引用计数，组件对象自己负责动态创建与销毁，从而屏蔽了不同编程语言之间的内存分配语义差异。在COM接口之间的类型转换通过QueryInterface方法。
对于某些应用程序来说，COM已经部分被.NET框架取代。COM通过Windows Communication Foundation（WCF）支持Web Service。COM对象通过.NET COM Interop可以被所有.NET语言使用。网络化的DCOM使用二进制私有格式，而WCF鼓励使用基于XML的SOAP消息机制。COM非常类似其他软件组件接口技术，如CORBA与JavaBeans，它们各自有其优点与弱点。
与C++不同，COM提供了一个稳定的应用二进制接口（ABI），不随编译器版本而改变 。
歷史

早在1988年，微软的Anthony Williams的论文“Object Architecture: Dealing with the Unknown or Type Safety in a Dynamically Extensible Class”以及1990年的“On Inheritance: What It Means and How To Use it”论文奠定了COM的理论基础。
Windows作業系統提供了三種进程間的通訊機制：剪貼簿、DDE（動態資料交換）與OLE。OLE原名是物件連結與嵌入（Object Linking and Embedding），OLE可以說是DDE的改良版。1992年，OLE 1.0版随Windows 3.1操作系统发布，提供复合文档（compound document）处理，但它過於複雜，Brockschmidt, Kraig的「Inside OLE」一书中提到，必须经过六个月的心灵混沌期，才能了解OLE是什么。1993年，COM架构随OLE 2.0第一次公开发布。在微软Office套件中，COM取代了OLE。这成为COM技术战胜Windows 95团队开发的其他对象技术的关键因素。
1996年，为应对CORBA，DCOM随Windows NT 4 Option Pack发布。
1999年，Windows 2000发布了COM+，关注MTS（微软事务服务器），并放弃了DCOM这个名称。
COM元件類型

COM是基於元件物件方式概念來設計的，在基礎中，至少要讓每個元件都可以支援二個功能：
查詢元件中有哪些接口
讓元件做自我生命管理，此概念的實踐即為引用計數（Reference Counting）
這二個功能即為COM的根：IUnknown介面所提供的IUnknown::QueryInterface()，IUnknown::AddRef()及IUnknown::Release()三個方法的由來。所有的COM元件都要實作IUnknown，表示每個COM元件都有相同的能力。
只由COM衍生實作出來的元件，稱為純COM元件。
但在Windows持續發展時，Visual Basic 4.0開始支援OCX，也就是OLE Custom Control，這讓微軟開始思考要如何讓COM元件可以跨語言支援，在這樣的要求下，必須要提供一個一致的介面，以及提供一組可以呼叫介面內方法的能力，由於純COM元件只能夠支援C/C++的直接存取，為了要達到跨語言的能力，在COM中必須要支援在外部呼叫內部方法的機能，這個機能造就了Invoke()方法，另外為了跨語言的支援，COM應該要提供簡單的元件存取識別方式，這也就是會有GetIDsOfNames()的原因，將這些方法組合起來，定義出的必要介面，稱為IDispatch介面，所有實作此介面的，都可以支援跨語言的支援。
微軟將實作此介面的元件都稱為自動化（Automation）元件。
相關技術

COM曾是Windows平台下主要的軟體開發平台，並且影響至其他許多相關軟體技術。
相關技術 > COM+

条目：微軟元件服務
COM+是微軟Windows 2000中，Microsoft Transaction Server的強化實作版本，除了提供基本的元件交易支援外，還提供了鬆散藕合式事件（loosely-coupled events）與物件共用池（object pooling）等應用程式伺服器的能力，成為Windows 2000開始在微軟平台上主要的應用程式伺服器平台，目前.NET Framework也提供了System.EnterpriseServices命名空間以支援COM+。
相關技術 > Distributed COM

条目：Distributed COM
Distributed COM是依據遠程過程調用（RPC，Remote Procedure Call）的規範發展的可以在網路上通訊的COM元件，它將COM元件的能力擴及到網路上，但因為網路安全以及防火牆因素，DCOM無法廣泛的流行。
相關技術 > .NET

条目：.NET Framework
.NET Framework是新一代的Microsoft Windows應用程式開發平台。使用C#开发COM組件，首先創建类型为Class Library的项目，然后在项目的Property中进入Build页，对“Register for COM interop”选项打勾。打开AssemblyInfo.cs文件，设置[assembly: ComVisible(true)]，这样就可以生成.tlb文件。源程序示例如下：
using System.Runtime.InteropServices;
 
namespace MyNameSpace
{
    //可以通过//菜单“工具/guid 生成”。
    [Guid("298D881C-E2A3-4638-B872-73EADE25511C")]
    public interface AddComInterface
    {
         [DispId(1)]  
         int iadd(int a, int b);
         [DispId(2)]
         string stradd(string strA, string strB);
     }
     [Guid("2C5B7580-4038-4d90-BABD-8B83FCE5A467")]
     [ClassInterface(ClassInterfaceType.None)]
     public class AddComService : AddComInterface
     {
         public AddComService()
         {
          }
          public int iadd(int a, int b)
          {
                int c = a + b;
                return c;
          }
          public string stradd(string strA, string strB)
          {
                 return strA+strB ;
           }
       }
}
相關技術 > ATL

条目：活动模板库
相關技術 > WTL

条目：Windows Template Library
技术细节

不同的COM组件类型用类ID（CLSID）标示，这是一种全局唯一标识符（GUID）。每个COM组件用一个或多个接口来暴露其功能。这些接口也采用GUID唯一标识，称为接口ID（IID）。
COM接口与几种编程语言有语言绑定，如C语言、C++、Visual Basic、Delphi语言、Python以及Windows平台上的几种脚本语言。它们都是通过接口的方法来访问组件。
技术细节 > 接口

所有COM组件都实现了IUnknown接口，该接口暴露了引用计数实现的对象生命期管理与类型转换，以访问不同的预定义接口。
IUnknown接口以及基于IUnknown的定制接口包括一个指向虚函数表（英语：）的指针，虚函数表中包含若干函数指针，分别指向接口所声明的函数实现。对于进程内的COM组件调用，其效率等同于C++的虚函数调用。
除了基于IUnknown的定制接口，COM也支持继承自IDispatch的dispatch接口，从而支持了用于OLE自动化（英语：）的晚绑定（英语：）。不能访问定制接口的编程语言（例如VBS）可以通过dispatch接口访问COM组件。
Windows API提供了C语言定义COM接口的方法：
#include <objbase.h>
#undef  INTERFACE
#define INTERFACE   IClassFactory

DECLARE_INTERFACE_(IClassFactory, IUnknown)
{
                // *** IUnknown methods ***
                STDMETHOD(QueryInterface) (THIS_
                                           REFIID riid,
                                           LPVOID FAR* ppvObj) PURE;
                STDMETHOD_(ULONG,AddRef) (THIS) PURE;
                STDMETHOD_(ULONG,Release) (THIS) PURE;
  
                // *** IClassFactory methods ***
                STDMETHOD(CreateInstance) (THIS_
                                          LPUNKNOWN pUnkOuter,
                                          REFIID riid,
                                          LPVOID FAR* ppvObject) PURE;
};
  
 //      等效的C++例子:
  
            struct FAR IClassFactory : public IUnknown
            {
                virtual HRESULT STDMETHODCALLTYPE QueryInterface(
                                                    IID FAR& riid,
                                                    LPVOID FAR* ppvObj) = 0;
                virtual HRESULT STDMETHODCALLTYPE AddRef(void) = 0;
                virtual HRESULT STDMETHODCALLTYPE Release(void) = 0;
                virtual HRESULT STDMETHODCALLTYPE CreateInstance(
                                                LPUNKNOWN pUnkOuter,
                                                IID FAR& riid,
                                                LPVOID FAR* ppvObject) = 0;
            };
 
 //      C语言宏扩展后是这样的:
  
            typedef struct IClassFactory
            {
                const struct IClassFactoryVtbl FAR* lpVtbl;
            } IClassFactory;
  
            typedef struct IClassFactoryVtbl IClassFactoryVtbl;
  
            struct IClassFactoryVtbl
            {
                HRESULT (STDMETHODCALLTYPE * QueryInterface) (
                                                    IClassFactory FAR* This,
                                                    IID FAR* riid,
                                                    LPVOID FAR* ppvObj) ;
                HRESULT (STDMETHODCALLTYPE * AddRef) (IClassFactory FAR* This) ;
                HRESULT (STDMETHODCALLTYPE * Release) (IClassFactory FAR* This) ;
                HRESULT (STDMETHODCALLTYPE * CreateInstance) (
                                                    IClassFactory FAR* This,
                                                    LPUNKNOWN pUnkOuter,
                                                    IID FAR* riid,
                                                    LPVOID FAR* ppvObject);
                HRESULT (STDMETHODCALLTYPE * LockServer) (
                                                    IClassFactory FAR* This,
                                                    BOOL fLock);
            };
技术细节 > 类

COM类（coclass）是一个或多个接口的具体实现，它很类似面向对象程序设计语言中的类。类的GUID标识被称作类ID（CLSID）；或者programmatic identifier字符串（progid），因为VBS等脚本语言不能使用GUID，只能用字符串查找、使用COM组件。
COM对象不能被直接访问，只能通过COM接口来访问对象。COM也支持同一个接口的多个实现，因此客户程序运行时可以选择实例化接口的哪个实现。
技术细节 > 接口定义语言与类型库

类型库（type library）包含着COM类型的元数据。这些类型采用微软接口定义语言（MIDL）描述。
IDL文件定义了类、接口、结构、枚举与其他用户定义类型。IDL类似于C++的声明，使用了一些额外的关键字如interface、library等。IDL还支持在声明前给出方括號属性（bracketed attribute）以提供额外信息，如接口的GUID、指针参数与长度域之间的关系等。
MIDL编译器用来编译IDL文件，产生编译器独立的头文件。头文件包含了IDL文件中声明的接口对应的结构定义。结构只包含一项成员，即指向在接口中声明函数的地址表的指针（vtbl），以模仿C++对虚函数的实现。头文件还包含了类与接口等的GUID的常量的定义。MIDL编译器也可以产生C++源文件，包含代理模块（proxy module），用以把COM调用转为远程过程调用，以支持跨进程的DCOM通信。
IDL文件也可以被MIDL编译器生成类型库（TLB）文件.TLB，以供其他语言编译器与运行时环境使用，如VB、Delphi、.NET等生成语言相关表示COM类型的结构。C++把TLB转回到IDL表示。
技术细节 > 接口定义语言与类型库 > #import 类型信息

使用C++的预编译directive#import ，可以装入如下格式的类型信息：
包含类型库的文件，如.olb、.tlb、.dll等；
progid
libid
exe文件
dll文件包含着类库资源（如.ocx）
复合文档包含了类库
其他可以被LoadTypeLib函数理解的文件
#import创建两个头文件以用C++源码形式恢复类型库信息：
类型库主头文件（.TLH）：类似于MIDL编译器产生的头文件，还有一些额外的代码与数据；
类型库次头文件（.TLI）：编译器产生的成员函数。该文件被包含在主头文件中。
两个文件被放在输出目录中。编译器在现场就地#include主头文件。
类型库主头文件（.TLH）包含七部分：
头部常规代码
将要用到的结构的前向引用与typedef
智能指针声明：使用宏语句_COM_SMARTPTR_TYPEDEF建立了COM接口的typedef，实际上是_com_ptr_t的模板特化。
Typeinfo声明：类定义、ITypeLib:GetTypeInfo返回的其他Typeinfo项
可选的旧格式的GUID常量定义，形如CLSID_CoClass、IID_Interface
#include类型库次头文件
尾部常规代码：#pragma pack(pop)
从第2至第6部分都包含在命名空间中，其名字在最初的IDL文件的library语句中给出。改名字在#import语句中可用属性no_namespace抑制掉；也可用rename_namespace属性更名。
技术细节 > COM作为对象框架

COM是一个运行时框架，类型必须在运行时单独地标识并可指定。为此，使用GUID，每个COM类型被指定了它自己的GUID用于运行时标识。这也解决了C/C++语言的名字修饰导致的链接兼容性问题。
为了使COM类型信息在编译时与运行时都可以访问，COM使用类型库。这使得COM成为对象交互的动态框架。
考虑下述用IDL定义coclass的例子：
coclass SomeClass {
  [default] interface ISomeInterface;
};
上述代码框架声明了一个COM类，称为SomeClass，实现了接口ISomeInterface。
这在概念是等价于下述C++类：
class SomeClass : public ISomeInterface {
  ...
  ...
};
其中ISomeInterface是一个C++虚基类。
包含COM接口与类的IDL文件被编译为类型库（TLB）文件。客户程序可以在运行时分析类型库文件，以确定对象支持哪些接口，然后调用对象的接口方法。
C/C++程序以类ID（CLSID）与接口ID（IID）作为参数，用CoCreateInstance函数实例化COM对象。SomeClass的实例化代码如下：
ISomeInterface* interface_ptr = NULL
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);
在这个例子中，使用COM子系统获取指向ISomeInterface接口的实现对象的指针，用CLSID_SomeClass指示用这个特定的coclass。
技术细节 > 引用计数

所有COM对象采用引用计数管理对象的生命期。客户程序通过所有COM对象都要强制实现的IUnknown接口的AddRef与Release方法来控制引用计数。当引用计数降到0时，COM对象自己负责释放内存。即对动态分配内存创建的COM对象，其Release函数内部引用计数降为0时，就释放自身所占的动态分配内存。有的COM对象（如IClassFactory）往往是静态对象，Release函数内部引用计数降为0时不需做额外的操作。
特定语言（例如Visual Basic）提供了自动引用计数，所以COM对象开发者在源代码中不需要显式维护任何内部的引用计数。C/C++编程者或者执行显式的引用计数，或者使用智能指针（如MFC提供的CComPtr）自动管理引用计数[需要解释]。
下述是如何调用COM对象的AddRef与Release的指引：
函数、方法返回接口的引用（通过返回值或者"out"参数），应当在返回前增加被返回的对象的引用计数。
接口指针被覆盖或超出作用域之前，必须调用接口指针的Release方法。
如果一个接口引用指针被复制，必须调用该指针的AddRef方法。
AddRef与Release必须在被引用的相关接口上调用。因为一个COM对象可能实现了逐个接口上的引用计数，使得仅在相关接口上内部分配资源。
不向远程对象发出引用计数的调用。代理模块保持着远程对象的一个引用，并维持着它自己的本地引用计数。
为简化COM开发，引入了活动模板库（Active Template Library，ATL）用于C++开发。ATL提供了更高层次的COM开发范式。ATL也有益于COM客户应用程序开发摆脱直接维护引用计数，而是用智能指针对象。
其他能直接支持COM的库与语言还包括MFC Visual C++编译器的COM支持、VBScript、Visual Basic、ECMAScript（JavaScript）和Borland Delphi等。
技术细节 > 程序设计

COM是一个语言独立的二进制标准，任何能够理解与实现COM的二进制定义的数据类型与接口的语言都可以开发COM组件。
COM实现负责进入、离开COM环境，实例化与引用计数COM对象，查询对象支持的接口，以及错误处理。
Microsoft Visual C++编译器支持对C++语言的扩展：称作C++ Attributes。这些扩展被设计用于简化COM开发，去除实现COM服务器时大量臃肿的代码。
技术细节 > 使用注册表

参见：regsvr32
在Windows操作系统中，COM类、接口、类型库都会根据其GUID登记到Windows注册表。HKEY_CLASSES_ROOT\CLSID下是COM类；HKEY_CLASSES_ROOT\Interface下是接口。COM类型库注册在每个COM对象的本地库条目下或者远程服务的网络位置处。
技术细节 > 不使用注册表的COM

不使用注册表的COM（RegFree COM）是Windows XP引入的技术，允许COM组件不在注册表中存期激活的元数据与类ID（CLSID），而是在实现类的程序集清单或者存储在可执行文件的资源中或组件安装时的单独文件中。这使得同一组件的不同版本可以安装在不同目录下，用其各自的manifest描述，直接复制安装（英语：）。这种技术有限支持EXE COM服务器且不能用于系统范围组件如MDAC、MSXML、DirectX或Internet Explorer。
应用程序装入时，Windows装入器搜索manifest。如果存在，装入器从它增加信息到激活上下文。COM类工厂试图实例化一个类时，激活上下文首先检查这个CLSID的实现是否可以找到。仅当查找失败时，才扫描Windows注册表。
技术细节 > 进程与网络透明

COM对象可以透明地实例化与引用在同一进程、跨进程边界、甚至在网上远程（DCOM）。进程外或远程对象用marshalling序列化方法调用与返回值。这种marshalling对用户是不可见的，就如同访问进程内的COM对象。
批评 > 消息泵

STA初始化时，创建一个隐藏窗口，用于apartment之间、进程间的消息路由。该窗口必须有正常的消息队列泵。这种结构称为消息泵。早期版本的Windows，消息泵的失败会导致系统范围的死锁。这个问题被初始化COM的Windows API复杂化了，并会导致实现细节的泄露。
批评 > 引用计数

如果多个对象是循環參照（英语：）（Circular reference），则可能会导致问题。
Objects may also be left with active reference counts if the 
使用COM事件池（event sink）模型，则对象可能一直保持活动的引用计数而不能被销毁。因为发送事件的对象必须有处理事件的对象的引用，因而对象引用计数永远不为0.
引用循环可以采取下述技术来克服：
带外终止（out-of-band termination），对象暴露一个方法，该方法调用时迫使该对象放弃对其他对象的全部引用。
身份分离（split identity）技术，一个实现暴露两个单独的COM对象（也称作identity），之间保持weak reference。
批评 > DLL地狱

进程内的COM组件是用DLL文件实现，每个版本的DLL用CLSID登记到Windows注册表，因而某些情况下会发生DLL Hell效应。无需注册的COM克服了这一问题。
批评 > 组件间的约定的表示

COM组件间的约定，纯粹是通过用户与组件之间的语义保证和假设的形式来表示的。COM用类型的形式表示组件约定。但是该约定存在如下两个关键问题，使得其对语义的表示并不是最优的。
约定的描述：COM没有定义约定的交换格式，即COM规范所约定的类型定义，必须通过完全是COM之外的某种技术来进行交互。微软定义和支持的COM交换格式有两个——IDL（Interface Definition Language接口语言定义）和TLB（Type LiBrary类型库），但是这两种格式并不是同构的，其中也没有哪种格式是权威的或标准的。
COM缺乏对组件依赖性的描述。因此，没有办法来解析COM组件（或者其约定的定义），也不能确定它所需要（依赖）的其他组件与版本。
COM约定的描述格式缺乏扩展性。IDL是基于文本的，极少随组件部署，通常只有C++程序员才会使用。TLB在扩展性方面存在缺陷，VB不使用TLB。
约定的工作方式是基于类型描述的，所采用的类型系统是C++的可移植子集。而且COM对组件的约定是物理的二进制约定，要求每个方法都具有精确的虚函数表偏移量、每个被传递的参数在堆栈规则中都有明确的偏移量、对象引用采用接口指针的明确格式、使用规定的分配器进行被调用这内存分配。COM组件的约定的精确性，产生了高效的代码；但不可靠性、开发使用及扩展升级的困难与复杂性高昂。
代特瓦

代特瓦是斯洛伐克的城鎮，位於該國中部，由班斯卡-比斯特里察州負責管轄，面積68.09平方公里，海拔高度400米，2005年人口15,020，其中八成居民信奉羅馬天主教。
外部連結

Official municipal website（页面存档备份，存于） （斯洛伐克文）
Detva flag & coat of arms（页面存档备份，存于）
中国人民解放军陕西省军区

| 中国人民解放军陕西省军区 |
| --- | --- |
中国人民解放军军旗
存在時期: 1949年至今
國家或地區:  中华人民共和国
效忠於:  中国共产党
種類: 省级军区
直屬: 中央军事委员会国防动员部
駐軍/總部: 西安市雁塔区长安中路
指挥官
現任指揮官: 趙天翔 少将
政治委员: 唐书海 少将
中国人民解放军陕西省军区，是中国人民解放军现属中央军事委员会国防动员部的一个省级军区，管辖范围为陕西省。