[A Moment in L'Arc-en-Ciel History] If you're a French fan of L'Arc-en-Ciel, you've probably seen "LIVE IN PARIS," a live concert video originally released in May 2009. The video is a full recording of the band's historic show at Le Zénith in Paris on May 9th, 2008, the first Paris solo performance by any Japanese artist. The members were thrilled to be performing there, which can be seen between songs when they speak to the audience in French!
[A Moment in L'Arc-en-Ciel History] 在法國的L'Arc-en-Ciel歌迷有可能知道『LIVE IN PARIS』這張於2009年5月發行的演唱會DVD。該作品完整收錄了樂團2008年5月9日在巴黎的天頂劇院所進行的歷史性演出,而他們也是成為了史上第一個在法國進行個人演唱會的日本藝人。成員們對於能在這樣的場地演出表現得十分興奮,從他們在演出間隙和觀眾們積極用法語互動就可以看出來這一點了!
同時也有10000部Youtube影片,追蹤數超過62萬的網紅Bryan Wee,也在其Youtube影片中提到,...
「originally用法」的推薦目錄:
- 關於originally用法 在 L'Arc-en-Ciel Facebook
- 關於originally用法 在 Taipei Ethereum Meetup Facebook
- 關於originally用法 在 Taipei Ethereum Meetup Facebook
- 關於originally用法 在 Bryan Wee Youtube
- 關於originally用法 在 Travel Thirsty Youtube
- 關於originally用法 在 スキマスイッチ - 「全力少年」Music Video : SUKIMASWITCH / ZENRYOKU SHOUNEN Music Video Youtube
- 關於originally用法 在 [請益] 原本打算做,但後來沒有的用法(want) - 看板Eng-Class 的評價
- 關於originally用法 在 YouTube 嵌入式播放器及播放器参数 的評價
- 關於originally用法 在 解析德文irgend 意思和用法 - YouTube 的評價
originally用法 在 Taipei Ethereum Meetup Facebook 八卦
📜 [專欄新文章] Solidity Weekly #8
✍️ mingderwang
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Events 和 Logs 的用法
從 #8 開始, 我想增加短連結方式(links 分享), 介紹大家更多有關 Solidity 的好文章. 若有想共筆的人, 也可以將連結與短文介紹, 寄到 twitter @mingderwang 給我, 我會放在下一期的 Solidity Weekly 刊登.
TL;DR
事實上 solidity 本身只有 event 指令, 沒有 log 指令(註: log0, log1 …它們屬於 assembly 用的 low-level function). Events 是用來實現 logs 的方法, 把它想成是比記載在 storage 裡更便宜的資料儲存方法. 但 logs 只能從區塊鏈的外部, 比如說用 web3.js 來讀取, 正確的說法應該是 trigger 的方式, 透由 web3.js 的 watch 指令來看到 ”事件” 的發生, 所以也可以用來更新 Dapp 的畫面.
這裡提到比記載在 storage 裡更便宜, 指的是相同的資料量, 放在記憶體裡當然貴了. 在區塊鏈的世界裡, 用到 miner 電腦的資源越多, 所要花費的 gas 就越高. LOG 運算碼(opcode)本身需花 375 gas, 再加上每個 byte 只要花 8 gas, 相較於 contract storage 每 32 bytes 就要 20,000 gas 實在差很大.
最後, 要提到的是 event 定義裡的參數(如下範例的 _market 和 _sender), 可以加 indexed 保留字讓該參數可以當參數被查詢, 又稱為 topics. 但最多只能用 3 個 (其實原本有四個 topics, 但第一個已經被 event 的識別值給用掉了). 如此一來 web3.js 就可以針對某個 _market 或 _sender 的值來查詢. 沒有用 indexed 的只能當 data 讀取. (若要 indexed 更詳細用法, 可參考 這裡)
contract CryptoExchange {
event Deposit(uint256 indexed _market, address indexed _sender, uint256 _amount, uint256 _time);
function deposit(uint256 _amount, uint256 _market) returns (int256) { // perform deposit, update user’s balance, etc Deposit(_market, msg.sender, _amount, now);}
links 分享;
Solidity撰寫智能合約與注意事項(二) — (NIC Lin)
Technical Introduction to Events and Logs in Ethereum — (ConsenSys)
[無用] 如何在 token 發行量裡埋彩蛋? — (Roger Wu)
後記;
Events 在文法上, 要在 event 的呼叫前面增加 emit 字眼, 否則 solidity compiler 會有 “Invoking events without “emit” prefix is deprecated.” 的警告出現.
*emit 適用於 solidity ^0.4.21;
Solidity Weekly #8 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
originally用法 在 Taipei Ethereum Meetup Facebook 八卦
📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Trust Token API 是一個正在標準化的瀏覽器 API,主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能,以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制,而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。
會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私,這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。
問題
大家應該都有點了一個產品的網頁後,很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面,他怎麼會知道我看了這個產品的頁面?
通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。
當使用者登入 Facebook 之後,Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面,當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時,瀏覽器在載入 SDK 時會再度夾帶這個識別碼,此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式,Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡,從你的瀏覽紀錄推敲喜好,餵給你 Facebook 最想給你看的廣告了。
不過跨站追蹤也不是只能用在廣告這樣的應用上,像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。
雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務,但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢?
這就是今天要講的新 API: Trust Token。
Trust Token API - The Chromium Projects
Trust Token / Privacy Pass 簡介
Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制,可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass,所以兩個運作機制類似,但是實作方式稍有不同。
先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春,不過大致上還是可以了解整個概念。
以 hCaptcha 跟 Cloudflare 的應用為例,使用者第一次進到由 Cloudflare 提供服務的網站時,網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。
當使用者答對問題後,Cloudflare 會回傳若干組 blind token,這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token,這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token,在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token,這個步驟稱為 redeem token。
但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起,也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token,但是在後續瀏覽不同網站時把 token 兌換掉時,Clouldflare 並無法區分哪個 token 是來自 Bob,哪個 token 是來自 Alice,但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。
但這樣的機制要怎麼完成呢?以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。
零知識證明 (Zero-knowledge proof)
零知識證明是一種方法在不揭露某個祕密的狀態下,證明他自己知道那個秘密。
Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的,下面簡單的翻譯一下:
假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉,如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力?我們可以設計一個流程來證明這件事情。
Alice 先把眼睛閉起來,請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候,告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到,但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。
而零知識證明的原理大致上就是這樣,你可以用一個流程來證明你知道某個秘密,即使你不真的揭露這個秘密到底是什麼,以上面的例子來說,這個秘密就是超能力運作的方式。
以上就是零知識證明的概念,不過要完成零知識證明有很多各式各樣的方式,今天我們要介紹的是 Trust Token 所使用的零知識證明:DLEQ。
DLEQ (Discrete Logarithm Equivalence Proof)
說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar),如果是大寫如 G, H則是橢圓曲線上面的點 (Point),如果是 vG 則一樣是點,計算方式則是 G 連續相加 v 次,這跟一般的乘法不同,有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。
DLEQ 有一個前提,在系統中的所有人都知道公開的 G 跟 H 兩個點,此時以下等式會成立:
假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何,並且在這個過程中不揭露 s 真正的數值,此時 Victor 可以產生一個隨機數 c 傳送給 Peggy,而 Peggy 則會再產生一個隨機數 v 並且產生 r,並且附上 vG, vH, sG, sH:
r = v - cs
所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值:
vG = rG + c(sG)vH = rH + c(sH)
我們舉第二個等式作為例子化簡:
vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH
這樣只有 Peggy 知道 s 的狀況下才能給出 r,所以這樣就可以證明 Peggy 確實知道 s。
從簡易到實際的情境
Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境,不過前面的例子就會相對比較天真一點,就請大家一步步的往下看。
基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的,以下參與的角色分為 Client 與 Server,並且都會有兩個階段 issue 與 redeem token。
Scenario 1
如果我們要設計一個這樣可以兌換 token 來確認身分的系統,其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server,Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client,這個產生 sT 的過程稱為 Sign Point,不過實際上運作的原理就是橢圓曲線上的連續加法運算。
SignPoint(T, s) => sT
等到 Client 需要兌換時只要把 T 跟 sT 給 Server,Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。
Issue
以下的範例,左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server,反之亦然。
// Client 發送 T 給 Server, 然後得到 sT
T -> <- sT
Redeem
// Client 要 redeem token 時,傳出 T 與 sT
T, sT ->
問題:Linkability
因為 Server 在 issue 的時候已經知道了 T,所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。
Scenario 2
要解決上面的問題,其中一個方法是透過 Blind Signature 達成。Client 不送出 T,而是先透過 BlindPoint 的方式產生 bT 跟 b,接下來再送給 Server bT。Server 收到 bT 之後,同樣的透過 Sign Point 的方式產生結果,不一樣的地方是情境 1 是用 T,而這邊則用 bT 來作 Sign Point,所以得出來的結果是 s(bT)。
Client:BlindPoint(T) => (bT, b)
Server:SignPoint(bT, s) => sbT
而 Blind Signature 跟 Sign Point 具備了交換律的特性,所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind:
UnblindPoint(sbT, b) => sT
這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了,而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點,同時因為 T 從來都沒有送到 Server 過,所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。
Issue
bT -> <- s(bT)
Redeem
T, sT ->
問題:Malleability
以上的流程其實也有另外一個大問題,因為有交換律的關係,當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT):
BlindPoint(sT) => a(sT), a// a(sT) === s(aT)
此時如果將 aT 跟 s(aT) 送給 Server Redeem,此時因為
SignPoint(aT, s) => s(aT)
所以就可以兌換了,這樣造成 Client 可以無限地用任意數值兌換 token。
Scenario 3
這次我們讓 Client 先選擇一個純數 t,並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T,並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。
因為 redeem 要送出的是 t,上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了,因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到,所以就沒辦法無限兌換了。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, sT ->
問題:Redemption hijacking
在這個例子裏面,Client 其實是沒有必要傳送 sT 的,因為 Server 僅需要 t 就可以計算出 sT,額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題,如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。
不過在網站上沒講出實際上要怎麼利用這個問題,但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好,而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。
Scenario 4
步驟跟前面都一樣,唯一不一樣的地方是 redeem 的時候原本是傳 t, sT,現在則改傳 t, M, HMAC(sT, M),如果再介紹 HMAC 篇幅會太大,這邊就不解釋了,但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。
這樣的特性在這個情境用很適合,因為 Server 透過 t 就可以計算出 sT,透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, M, HMAC(sT, M) ->
問題:Tagging
這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’,這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。
要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。
Scenario 5
前面的 DLEQ 講解有提到,如果有 Peggy 有一個 s 秘密純量,我們可以透過 DLEQ 來證明 Peggy 知道 s,但是又不透漏 s 真正的數值,而在 Privacy Pass 的機制裡面,Server 需要證明自己每次都用 s,但是卻又不用揭露真正的數值。
在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端,但 Server 端的回應就不一樣了,這次 Server 會回傳 sbT 與一個 DLEQ 證明,證明自己正在用同一個 s。
首先根據 DLEQ 的假設,Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client,而 H 則改用 bT 代替。
回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token,所以附上了一個 DLEQ 的證明 r = v - cs,Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替,此時 client 也有 sbT 也就是 sH):
vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT
這樣就可以證明 Server 依然用同一個 s。
Issue
T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)
Redeem
t, M, HMAC(sT, M) ->
問題:only one redemption per issuance
到這邊基本上 Privacy Pass 的原理已經解釋得差不多了,不過這邊有個問題是一次只發一個 token 太少,應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。
Scenario 7
由於一次僅產生一個 redeem token 太沒效率了,如果同時發很多次,每次都產生一個 proof 也不是非常有效率,而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法,這樣就可以大大的降低頻寬需求。
不過這邊我們就不贅述 Batch DLEQ 的原理了,文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。
Issue
T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)
Redeem
t1, M, HMAC(sT1, M) ->
結論
Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式,期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。
不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去,而協議制定的過程中其實廣告龍頭 Google 也參與其中,希望這份協議還是可以保持中立,盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。
參考資料
IETF Privacy Pass docs
Privacy Pass: The Protocol
Privacy Pass: Architectural Framework
Privacy Pass: HTTP API
Cloudflare
Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)
Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化
Other
Privacy Pass official website
Getting started with Trust Tokens (web.dev)
WICG Trust Token API Explainer
Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用,列了很多零知識證明的源碼參考,但可惜的是 DLEQ 這個演算法講解有錯,讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心,源碼應該是可以參考的,解釋的話需要斟酌一下。
關鍵源碼
這邊我貼幾段覺得很有用的源碼。
privacy pass 提供的伺服器端產生 Proof 的源碼
privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼
github dedis/kyber 產生 Proof 的源碼
[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
originally用法 在 Bryan Wee Youtube 的評價
originally用法 在 Travel Thirsty Youtube 的評價
originally用法 在 スキマスイッチ - 「全力少年」Music Video : SUKIMASWITCH / ZENRYOKU SHOUNEN Music Video Youtube 的評價
originally用法 在 YouTube 嵌入式播放器及播放器参数 的八卦
概览
本文档介绍如何在应用中嵌入 YouTube 播放器,并定义了 YouTube 嵌入式播放器可以使用的参数。
通过将参数附加到 iframe 网址末尾,您可以自定义应用中的播放体验。例如,您可以使用 autoplay
参数自动播放多个视频,也可以使用 loop
参数重复播放一个视频。您还可以使用 enablejsapi
参数,允许通过 iframe Player API 控制播放器。
目前,本页面定义了任意 YouTube 嵌入式播放器支持的全部参数。每个参数定义均会确定支持相应参数的播放器。
注意:嵌入式播放器必须具有一个尺寸至少为 200x200 像素的视口。如果播放器显示控件,那么它必须足够大,可以在无需将视口缩小到最小尺寸以下的情况下完整显示控件。我们建议 16:9 播放器的宽至少为 480 像素、高至少为 270 像素。
嵌入 YouTube 播放器您可以使用以下任意一种方法在应用中嵌入 YouTube 播放器并指定播放器参数。请注意,以下说明将介绍如何嵌入会加载单个视频的播放器。接下来的部分将说明如何配置您的播放器,以便加载其他类型的内容(例如播放列表和搜索结果)。
使用<iframe>
标记嵌入播放器在您的应用中定义一个 <iframe>
标记,其中 src
网址用于指定播放器将要加载的内容以及您想设置的其他任何播放器参数。<iframe>
标记的 height
和 width
参数指定了播放器的尺寸。
如果您自行创建 <iframe>
元素(而不是使用 iframe Player API 创建),则可以直接将播放器参数附加到网址末尾。网址格式如下:
https://www.youtube.com/embed/VIDEO_ID
以下 <iframe>
标记将会加载一个可用来播放 YouTube 视频 M7lc1UVf-VE
的 640x360 像素的播放器。由于网址中 autoplay
参数设置为 1
,因此视频会在播放器加载完后自动播放。
使用 iframe Player API 嵌入播放器
<iframe id="ytplayer" type="text/html" width="640" height="360"
src="https://www.youtube.com/embed/M7lc1UVf-VE?autoplay=1&origin=http://example.com"
frameborder="0"></iframe>
请按照 iframe Player API 说明,在 iframe Player API 的 JavaScript 代码加载之后,在网页或应用中插入视频播放器。视频播放器构造函数中的第二个参数是指定播放器选项的对象。在此对象中,playerVars
属性会确定播放器参数。
以下 HTML 和 JavaScript 代码展示了一个简单示例,即将 YouTube 播放器插入 id
值为 ytplayer
的页面元素。系统会在 iframe Player API 代码加载完成后自动调用此处指定的 onYouTubePlayerAPIReady()
函数。此代码不会定义任何播放器参数,也不会定义其他事件处理脚本。
选择要播放的内容
<div id="ytplayer"></div><script>
// Load the IFrame Player API code asynchronously.
var tag = document.createElement('script');
tag.src = "https://www.youtube.com/player_api";
var firstScriptTag = document.getElementsByTagName('script')[0];
firstScriptTag.parentNode.insertBefore(tag, firstScriptTag); // Replace the 'ytplayer' element with an <iframe> and
// YouTube player after the API code downloads.
var player;
function onYouTubePlayerAPIReady() {
player = new YT.Player('ytplayer', {
height: '360',
width: '640',
videoId: 'M7lc1UVf-VE'
});
}
</script>
您可以配置已嵌入的播放器,以加载视频、播放列表、用户上传的视频或针对特定查询的搜索结果。
以下列表介绍了这些选项:
加载视频
对于使用 iframe 嵌入的播放器,您要加载的视频的 YouTube 视频 ID 是在 iframe 的 src
网址中指定的。
https://www.youtube.com/embed/VIDEO_ID
如果您使用了 YouTube Data API (v3),则可以从搜索结果、播放列表项资源、视频资源或其他资源中检索视频 ID,以编程方式构建这些网址。获取视频 ID 之后,请使用该值替换上述网址中的 VIDEO_ID
文字以创建播放器网址。
加载播放列表
将 listType
播放器参数设为 playlist
。此外,将 list
播放器参数设为您想加载的 YouTube 播放列表 ID。
https://www.youtube.com/embed?listType=playlist&list=PLAYLIST_ID
请注意,播放列表 ID 需要以字母 PL
作为前缀,如下例所示:
https://www.youtube.com/embed?listType=playlist&list=PLC77007E23FF423C6
如果您使用的是 YouTube Data API (v3),则可以从搜索结果、频道资源或活动资源中检索播放列表 ID,以编程方式构建这些网址。获得播放列表 ID 之后,请使用该值替换上述网址中的 PLAYLIST_ID
文字。
加载用户上传的视频
将 listType
播放器参数设为 user_uploads
,然后将 list
播放器参数设为 YouTube 用户名,加载自己喜欢的对象所上传的视频。
https://www.youtube.com/embed?listType=user_uploads&list=USERNAME
加载指定查询的搜索结果
将 listType
播放器参数设为 search
,然后将 list
播放器参数设置为您希望的查询字词,让播放器加载相应的搜索结果。
https://www.youtube.com/embed?listType=search&list=QUERY
支持的参数
下面所有的参数都是可选的。
参数
autoplay
此参数用于指定是否在播放器加载时自动开始播放初始视频。支持的值为
0
或 1
。默认值为 0
。cc_lang_pref
此参数用于指定播放器将用于显示字幕的默认语言。请将参数值设置为两个字母组成的 ISO 639-1 语言代码。
如果您使用此参数且将
cc_load_policy
参数设为 1
,则在播放器加载时,播放器将会以指定的语言显示字幕。如果您还未设置 cc_load_policy
参数,则默认情况下字幕将不会显示,但如果用户选择打开字幕,则字幕将会以指定的语言显示。cc_load_policy
将参数值设置为
1
会使系统在默认情况下显示字幕,即使在用户此前关闭了字幕的情况下也是如此。默认行为基于用户偏好设置。color
此参数用于指定在播放器的视频进度条中用来突出显示观看者已经看过的视频长度的颜色。有效的参数值包括
red
和 white
,而且在默认情况下,播放器将在视频进度条中使用红色。如需详细了解颜色选项,请参阅 YouTube API 博客。注意:将
color
参数设置为 white
会停用 modestbranding
选项。controls
此参数用于指明视频播放器控件是否会显示:
controls=0
- 播放器控件不会在播放器中显示。controls=1
(默认值)- 播放器控件会在播放器中显示。disablekb
将参数值设置为
1
会导致播放器无法响应键盘控制键。默认值为 0
,表示支持键盘控制键。目前支持的键盘控制键如下:空格键或 [k] 键:播放/暂停
向左箭头键:在当前视频中向后跳 5 秒
向右箭头键:在当前视频中向前跳 5 秒
向上箭头键:调高音量
向下箭头键:调低音量
[f] 键:切换全屏显示
[j] 键:在当前视频中向后跳 10 秒
[l] 键:在当前视频中向前跳 10 秒
[m] 键:将视频静音或取消静音
[0-9] 键:跳转到视频中的某一位置。
0
键用于跳转到视频的开头、1
键用于跳转到视频的 10% 这一位置、2
键用于跳转到视频的 20% 这一位置,依此类推。enablejsapi
将参数值设置为
1
则可允许通过 iframe 或 JavaScript Player API 调用来控制播放器。默认值为 0
,表示无法使用这些 API 控制播放器。如需详细了解 iframe API 及其用法,请参阅 iframe API 文档(JavaScript Player API 已被弃用)。
end
此参数用于指定时间,以秒为单位,自视频开头开始计算,直到播放器应该停止播放视频时为止。此参数值是正整数。
请注意,时间是从视频开头而不是从
start
播放器参数值或 startSeconds
参数值开始计算的;此时间在 YouTube Player API 函数中用于加载视频或将视频加入队列。fs
将此参数设置为
0
可以阻止全屏按钮显示在播放器中。默认值为 1
,该值会使全屏按钮显示。hl
设置播放器的界面语言。此参数值是两个字母组成的 ISO 639-1 语言代码或完整表示的语言区域。例如,
fr
和 fr-ca
都是有效值。系统或许也能正确处理 IETF 语言标记 (BCP 47) 之类的语言输入代码。界面语言用于播放器中的工具提示,而且还会影响默认的字幕轨道。请注意,YouTube 可能会根据特定用户的个人语言偏好设置和提供的字幕轨道,为该用户选择其他字幕轨道语言。
iv_load_policy
将参数值设置为
1
会在默认情况下显示视频注释,而将其设置为 3
则默认不显示。默认值为 1
。list
list
参数与 listType
参数搭配使用时可确定播放器中将要加载的内容。如果
listType
参数的值为 search
,则 list
参数值会指定搜索查询。如果
listType
参数的值为 user_uploads
,则 list
参数值会确定将要加载的已上传视频所在的 YouTube 频道。如果
listType
参数的值为 playlist
,则 list
参数值会指定 YouTube 播放列表 ID。在参数值中,您需要使用字母 PL
为播放列表 ID 添加前缀,如下例所示。https://www.youtube.com/embed?
listType=playlist
&list=PLC77007E23FF423C6
注意:如果您指定
list
和 listType
参数的值,则 iframe 嵌入网址就无需指定视频 ID。listType
listType
参数与 list
参数搭配使用时可确定播放器中将要加载的内容。有效的参数值包括 playlist
、search
和 user_uploads
。如果您指定
list
和 listType
参数的值,则 iframe 嵌入网址就无需指定视频 ID。loop
如果播放器是单视频播放器,则将此值设置为
1
会使播放器反复播放初始视频。如果播放器是播放列表播放器(或自定义播放器),则会播放整个播放列表中的视频,然后再从第一个视频开始播放。支持的值为
0
和 1
,默认值为 0
。注意:此参数在 AS3 播放器和 iframe 嵌入式播放器(可能会加载 AS3 或 HTML5 播放器)中得到的支持会受到限制。目前,仅在与
playlist
参数结合使用时,loop
参数才能在 AS3 播放器中起作用。要循环播放单个视频,请将 loop
参数值设置为 1
,并将 playlist
参数值设置为与 Player API 网址中已指定的视频 ID 相同的值:https://www.youtube.com/v/VIDEO_ID?
version=3
&loop=1
&playlist=VIDEO_ID
modestbranding
此参数可让您使用不显示 YouTube 徽标的 YouTube 播放器。将参数值设置为
1
可以阻止 YouTube 徽标显示在控制栏中。请注意,当用户的鼠标指针悬停在播放器上方时,一个小 YouTube
文字标签仍将显示在暂停的视频的右上角。origin
此参数为 iframe API 提供额外的安全措施,而且仅支持 iframe 嵌入式播放器。如果您使用了 iframe API,这意味着您会将
enablejsapi
参数值设置为 1
,那么您应始终将网域指定为 origin
参数值。playlist
此参数用于指定要播放的视频 ID 列表(以英文逗号分隔)。如果您指定一个值,则播放的第一个视频将是网址路径中指定的
VIDEO_ID
对应的视频,而在 playlist
参数中指定的视频将在随后播放。playsinline
此参数用于控制视频在 iOS 设备上的 HTML5 播放器中播放时,是以内嵌方式还是全屏模式播放。有效值如下:
0
:如果使用该值,视频将以全屏模式播放。目前默认使用此值,但以后可能会变。1
:如果使用该值,则在 allowsInlineMediaPlayback
属性值设置为 TRUE
的情况下创建的 UIWebViews
会以内嵌方式播放。rel
注意:此参数在 2018 年 9 月 25 日当天或之后有调整。
在更改前,此参数用于指示初始视频播放结束时,播放器是否应显示相关视频。
如果参数值设置为
1
(默认值),则播放器会显示相关视频。如果参数值设置为
0
,则播放器不会显示相关视频。在更改后,您将无法停用相关视频。相反,如果
rel
参数设置为 0
,则相关视频将来自与刚播放的视频相同的频道。showinfo
注意:2018 年 9 月 25 日后,此参数已被弃用,并会被忽略。
支持的值包括:
0
和 1
。如果将参数值设置为
0
,则在视频开始播放之前,播放器不会显示视频标题和上传者等信息。如果播放器正在加载播放列表,而且您已明确将该参数值设置为
1
,那么播放列表加载时,播放器还将显示播放列表中视频的缩略图。start
此参数可让播放器从视频中的指定位置开始播放视频,具体位置以距视频开头的秒数表示。此参数值是正整数。请注意,与
seekTo
函数类似,播放器会查找与指定时间最接近的关键帧。这就意味着,播放指针有时可能会停在请求时间之前几秒的位置,通常与请求时间相差不超过 2 秒。widget_referrer
此参数用于标识在其中嵌入了播放器的网址。如果 YouTube 播放器嵌入到了微件中,而该微件随后嵌入到网页或应用中,则 YouTube 数据分析报告中会使用此值。在这种情况下,
origin
参数用于标识微件提供商的网域,但 YouTube 数据分析不会将微件提供商标识为实际的流量来源。相反,YouTube 数据分析会改用 widget_referrer
参数值以标识与流量来源关联的网域。修订历史记录
August 23, 2018
Note: This is a deprecation announcement for the showinfo
parameter. In addition, the behavior for the rel
parameter is changing. Titles, channel information, and related videos are an important part of YouTube’s core user experience, and these changes help to make the YouTube viewing experience consistent across different platforms.
The behavior for the
rel
parameter is changing on or after September 25, 2018. The effect of the change is that you will not be able to disable related videos. However, you will have the option of specifying that the related videos shown in the player should be from the same channel as the video that was just played.To be more specific:
Prior to the change, if the parameter's value is set to
0
, then the player does not show related videos.After the change, if the
rel
parameter is set to 0
, the player will show related videos that are from the same channel as the video that was just played.The
showinfo
parameter, which indicates whether the player should display information like the video title and uploader before the video starts playing, is also being deprecated. Following the change, the channel avatar and video title will always display before playback begins, when playback is paused, and when playback ends. The avatar being displayed is new behavior that will be consistent across all embedded players.These changes will become effective on or after September 25, 2018. After that time, the showinfo
parameter will be ignored. The behavior following the changes is consistent with the current default behavior for embedded players with the exception of the channel avatar changes mentioned above.
August 16, 2018
The cc_lang_pref
parameter can be used to specify the default language that the player will use to display captions. This parameter can be used in conjunction with the cc_load_policy
parameter to automatically show captions in the specified language during playback.
September 15, 2017
The controls
parameter's definition has been updated to remove references to the deprecated Flash (AS3) player. The value 2
has been deprecated as it was originally designed to provide a performance improvement for embeds that loaded a Flash player.
June 12, 2017
The new widget_referrer
parameter helps to enable more accurate YouTube Analytics reporting when the YouTube player is embedded in a widget, and that widget is then embedded in a web page or application.
November 1, 2016
This document has been updated to remove references to the deprecated Flash (AS3) player as well as to parameters only supported by that player. The YouTube Flash player was deprecated in January 2015.
October 20, 2016
This update contains the following changes:
The disablekb
parameter definition has been corrected to note that the default value is 0
, which means that keyboard controls are enabled. A value of 1
indicates that keyboard controls should be disabled.
The list of keyboard controls that the player supports has also been updated to include the following:
[f]: Toggle full-screen display
[j]: Jump back 10 seconds in the current video
[k]: Play / Pause
[l]: Jump ahead 10 seconds in the current video
[m]: Mute or unmute the video
[0-9]: Jump to a point in the video.
0
jumps to the beginning of the video, 1
jumps to the time 10% into the video, 2
jumps to the point 20% into the video, and so forth.In addition, the effect of pressing the [arrow left] or [arrow right] keys has changed. These keys now jump 5 seconds back (arrow left) or ahead (arrow right) in the current video.
August 11, 2016
This update contains the following changes:
The newly published YouTube API Services Terms of Service ("the Updated Terms"), discussed in detail on the YouTube Engineering and Developers Blog, provides a rich set of updates to the current Terms of Service. In addition to the Updated Terms, which will go into effect as of February 10, 2017, this update includes several supporting documents to help explain the policies that developers must follow.
The full set of new documents is described in the revision history for the Updated Terms. In addition, future changes to the Updated Terms or to those supporting documents will also be explained in that revision history. You can subscribe to an RSS feed listing changes in that revision history from a link in that document.
December 18, 2015
European Union (EU) laws require that certain disclosures must be given to and consents obtained from end users in the EU. Therefore, for end users in the European Union, you must comply with the EU User Consent Policy. We have added a notice of this requirement in our YouTube API Terms of Service.
August 19, 2015
The autohide
parameter has been deprecated for the HTML5 player. In HTML5 players, the video progress bar and player controls display or hide automatically. That behavior corresponds to an autohide
setting of 1
.
The theme
parameter has been deprecated for the HTML5 player. HTML5 players now always use the dark theme.
March 9, 2015
The document has been updated to reflect the fact that YouTube <object>
embeds, the YouTube Flash Player API and the YouTube JavaScript Player API have all been deprecated as of January 27, 2015. A deprecation warning appears in several sections of this document to help point readers to the IFrame Player API as an alternative.
The definition of the autohide
parameter has been updated to clarify the meaning of the parameter's values. The default behavior (autohide=2
) is that if the player has a 16:9 or 4:3 aspect ratio, the player's video progress bar and player controls display or hide automatically. Otherwise, those controls are visible throughout the video.
The definition of the hl
parameter has been updated to note that the parameter value could be an ISO 639-1 two-letter language code or a fully specified locale. For example, fr
and fr-ca
are both valid parameter values.
The definition of the enablejsapi
parameter has been reworded to clarify that the parameter enables a player to be controlled via API calls. The API could be either the IFrame Player API or the JavaScript Player API.
October 14, 2014
The HTML5 player now supports the cc_load_policy
, disablekb
, end
, fs
, list
, and listType
parameters. The parameter descriptions have been updated accordingly.
July 18, 2014
The new hl
parameter can be used to set the player's interface language. The interface language is used for tooltips in the player and also affects the default caption track. The selected caption track may also depend on the availability of caption tracks and user's individual language preferences.
The parameter's value is an ISO 639-1 two-letter language code, though other language input codes, such as IETF language tags (BCP 47) may also be handled properly.
The definition of the playsinline
parameter, which only affects HTML5 players on iOS, has been modified slightly. The definition now notes that setting the parameter value to 1
causes inline playback only for UIWebViews
created with the allowsInlineMediaPlayback
property set to TRUE
.
January 28, 2014
The playsinline
parameter controls whether videos play inline or fullscreen in an HTML5 player on iOS. Setting the value to 1
causes inline playback.
The Selecting content to play section has been updated to explain how to find YouTube video IDs and playlist IDs using the YouTube Data API (v3) rather than the older API version.
The controls
parameter's definition has been updated to reflect the fact that the parameter value only affects the time that the Flash player actually loads in IFrame embeds. In addition, for IFrame embeds, the parameter value also determines when the controls display in the player. If you set the parameter's value to 2
, then the controls display and the Flash player loads after the user initiates the video playback.
May 10, 2013
This update contains the following changes:
YouTube no longer identifies experimental API features and services. Instead, we now provide a list of YouTube APIs that are subject to the deprecation policy.
July 20, 2012
This update contains the following changes:
The definition of the controls
parameter has been updated to reflect support for a parameter value of 2
and to explain that, for AS3 players, the parameter value determines the time when the Flash player actually loads. If the controls
parameter is set to 0
or 1
, the Flash player loads immediately. If the parameter value is 2
, the Flash player does not load until the video playback is initiated.
June 5, 2012
This update contains the following changes:
The HTML5 player now supports the color
, modestbranding
, and rel
parameters, and the definitions for these parameters have been updated accordingly.
The definition of the showinfo
parameter has been updated to explain how that if the player is loading a playlist, and you explicitly set the parameter value to 1
, then, upon loading, the player will also display thumbnail images for the videos in the playlist. Note that this functionality is only supported for the AS3 player since that is the only player that can load a playlist.
May 4, 2012
This update contains the following changes:
The showinfo
parameter's definition has been updated to reflect the fact that the HTML5 player supports this parameter.
May 3, 2012
This update contains the following changes:
The new end
parameter specifies the time, measured in seconds from the start of the video, when the player should stop playing a video. Note that the time when playback is stopped is measured from the beginning of the video and not from the value of either the start
player parameter or the startSeconds
parameter, which is used in YouTube Player API functions for loading or queueing a video.
March 29, 2012
This update contains the following changes:
The new Embedding a YouTube player section explains different ways to embed a YouTube player in your application. This section covers manual IFrame embeds, IFrame embeds that use the IFrame Player API, and AS3 and AS2 object embeds. This section incorporates information from the old Example usage section, which has been removed.
The new Selecting content to play section explains how to configure the player to load a video, a playlist, search results for a specified query, or uploaded videos for a specified user.
The new list
and listType
parameters let you specify the content that the player should load. You can specify a playlist, a search query, or a particular user's uploaded videos.
The definitions of the fs
and rel
parameters have been updated to more clearly explain the default parameter values for the AS3 player.
The border
, color1
, egm
, hd
, and showsearch
parameters, which are all only supported for the deprecated AS2 Player API, have been moved to a new section named deprecated parameters only used in the AS2 Player API.
The document no longer provides a way to filter the parameter list to only display parameters supported in either the AS3, AS2, or HTML5 player. Instead, each parameter definition has been updated to identify the players that support that parameter.
August 11, 2011
This update contains the following changes:
The new theme
and color
parameters let you customize the appearance of the embedded player's player controls. See the YouTube API blog for more information.
June 8, 2011
This update contains the following changes:
The new modestbranding
parameter lets you use a YouTube player that does not show a YouTube logo. As of this release, the parameter was only supported for the AS3 embedded player and for IFrame embeds that loaded the AS3 player. As of June 5, 2012, the HTML5 player also supported this parameter.
February 14, 2011
This update contains the following changes:
The documentation has been updated to note that the AS2 Player API has been deprecated. The deprecation of the AS2 Player API was actually announced on October 14, 2009.
February 3, 2011
This update contains the following changes:
The documentation has been updated to identify parameters supported in the HTML5 (IFrame) embedded player.
The document now displays all of the parameters supported in any of YouTube's embedded players (HTML5, AS3, AS2).
The following parameters are supported in the AS2 player but have been deprecated for the newer AS3 and HTML5 players: border
, color1
, color2
, egm
, hd
, and showsearch
.
In addition, the loop
parameter has limited support in the AS3 player and in IFrame embeds, which could load either an AS3 or HTML player. Currently, the loop
parameter only works in the AS3 player when used in conjunction with the playlist
parameter. To loop a single video, set the loop
parameter to 1
and set the playlist
parameter value to the same video ID already specified in the Player API URL:
https://www.youtube.com/v/VIDEO_ID?version=3&loop=1&playlist=VIDEO_ID
Similarly, the controls
and playlist
parameters are supported in the AS3 and HTML5 players but are not and will not be supported in the AS2 player.
As noted above, IFrame embeds can load either an AS3 or HTML5 player. Though some parameters are not supported in both players, an IFrame embed that loads the AS3 player will support all parameters that work with that player and ignore all other parameters. Similarly, an IFrame embed that loads the HTML5 player will support all parameters that work with that player while ignoring all other parameters.
The parameter list has been updated to include the autohide
parameter, which indicates whether the player's video controls will automatically hide after a video begins playing.
The parameter list has been updated to include the controls
parameter, which indicates whether the player's video controls will display at all. (Player controls do display by default.)
The parameter list has been updated to include the playlist
parameter, which specifies a comma-separated list of video IDs to play.
The definition of the fs
has been updated to note that the fullscreen option will not work if you load the YouTube player into another SWF.
The example at the end of the document has been updated to use the embedded AS3 player instead of the embedded AS2 player. The parameters used in the example have also been updated to only include parameters that the AS3 player supports.
In addition, the instructions for constructing the URLs that contain player parameters have been updated to reflect the URL formats used by the AS3 and AS2 embedded and chromeless players as well as by the HTML5 player.
... <看更多>
originally用法 在 [請益] 原本打算做,但後來沒有的用法(want) - 看板Eng-Class 的八卦
原句:
I actually wanted to do that originally
but it seem that I ..... .
---------------------------------------------------------
主要想詢問第一個句子的 wanted,
我個人會寫成
I actually want to do something in some way, but ...it seems that...
或者
Actually, I want/ try /prefer to do something in some way,
but...it seems that....
覺得原句使用wanted有點怪怪的,
該怎麼說呢...有點饒口?
想要詢問哪一種才是正確的(或者兩個都不是?Q__Q)
以及這樣使用的原因,
因為我現在只覺得怪怪的,但沒有任何原因,
而且想不起來這種句型叫什麼,有點難google
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.39.41.143
※ 文章網址: https://www.ptt.cc/bbs/Eng-Class/M.1469686564.A.397.html
※ 編輯: Tevety (114.39.41.143), 07/28/2016 14:20:18
感謝d大,超級詳細!!
其實語感真的不準 Q Q
我只是衝著自己平常都有在聽和閱讀英文,所以常仗著語感...
有時會出現幻覺,明明沒有看過這種用法,卻出現某種直覺的壞習慣 >_<
再次感謝D大,與回文的大家!
※ 編輯: Tevety (114.39.41.143), 07/29/2016 00:04:34
... <看更多>