RFC1738,1808,3986 小整理

最近在看直播的問題, 必須看一些 RFC 的文件. 在此把相關的部分都整理出來.

最基礎的一本是 RFC 1738 Uniform Resource Locators (URL), 一個 URL 可以分成兩個部分:

        <scheme>:<scheme-specific-part>

Scheme 可以翻譯成 "系統" 或 "範型", 它包括以下幾種內容, 相當於是大分類. http 或是 ftp 都是常用的 scheme.

scheme 說明
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service

至於 scheme-specific-part 的部份, 會依據不同的 scheme 而有不同的格式變化.下面就進入 RFC1808 Relative Uniform Resource Locators 的 URL 格式, 和前面 RFC1738 最大的差異在於:Relative – "相對性".

它基本的長相是這樣. 

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

scheme ":"   ::= scheme name.

"//" net_loc ::= network location and login information.

"/" path     ::= URL path.

";" params   ::= object parameters.

"?" query    ::= query information.

"#" fragment ::= fragment identifier.

為了簡化描述, 我們直接看簡化版的例子, scheme, net_loc, params, query (component), fragment 改用 http://, a, p, q, f 代替. Path 的部份因為要多給幾層才能看出端倪, 所以給三個符號 b, c, d. d 可以視為檔名. 此後 URL 變成 <URL:http://a/b/c/d;p?q#f&gt;

於是我們有下列的表達方式:

      g:h        = <URL:g:h>
      g          = <URL:http://a/b/c/g>
      ./g        = <URL:http://a/b/c/g>
      g/         = <URL:http://a/b/c/g/>
      /g         = <URL:http://a/g>
      //g        = <URL:http://g>
      ?y         = <URL:http://a/b/c/d;p?y>
      g?y        = <URL:http://a/b/c/g?y>
      g?y/./x    = <URL:http://a/b/c/g?y/./x>
      #s         = <URL:http://a/b/c/d;p?q#s>
      g#s        = <URL:http://a/b/c/g#s>
      g#s/./x    = <URL:http://a/b/c/g#s/./x>
      g?y#s      = <URL:http://a/b/c/g?y#s>
      ;x         = <URL:http://a/b/c/d;x>
      g;x        = <URL:http://a/b/c/g;x>
      g;x?y#s    = <URL:http://a/b/c/g;x?y#s>
      .          = <URL:http://a/b/c/>
      ./         = <URL:http://a/b/c/>
      ..         = <URL:http://a/b/>
      ../        = <URL:http://a/b/>
      ../g       = <URL:http://a/b/g>
      ../..      = <URL:http://a/>
      ../../     = <URL:http://a/>
      ../../g    = <URL:http://a/g>

由於 a 是 network location, 無論往上幾層, 都不能高過於 http://a/, 其他的都可以直觀地了解. 大致瞭解了比較常聽見的 URL, 接著看看比較陌生的 RFC3896 Uniform Resource Identifier (URI): Generic Syntax.

其實 RFC3896 的內容和 RFC1808 有些重複, 原因是 URI 包含了 URL 和 URN (Uniform Resource Name), 所以 RFC1808 只是 RFC3896 的一部份. 一個 URI 可能是一個 locator (URL), 一個 name (URN), 或是 locator + name. 舉例子來說, 它們會像這樣:

         foo://example.com:8042/over/there?name=ferret#nose
         _/   ______________/_________/ _________/ __/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         /  /                        
         urn:example:animal:ferret:nose

大家應該很容易就發現, URI 的說明, 簡直就和 URL 一樣嘛! 只不過 URL 用 network location 代替了 URI 的 authority, URL 有 parameters, 而 URI 把它併入了 path. 基本上, URI 著重在 "標識" – identifier, URL 著重在位置 – location, 即使兩者的長相完全一樣.

參考 [ref 4] 的說法, 若是 PPS 把一部 "大話西遊 – 月光寶盒" 的電影, 同時放在伺服器 1, 2, … 和伺服器 100, 以便給不同地區的使用者觀看.  這些片子可以理解為同一個 URI, 但它們的 URL 各自不同. 另外一部同時放在伺服器 1 的電影: "大話西遊 – 仙履奇緣", 就要理解為另外一個 URI 了.

[ref]

1. http://www.ietf.org/rfc/rfc1738.txt

2. http://www.ietf.org/rfc/rfc1808.txt

3. http://www.ietf.org/rfc/rfc3986.txt

4. URI, URL, 和 URN 的區別

USB 充電小註解

目前 USB 的充電規範以 USB應用者論壇(USB-IF) 所制定 BC (Battery Charge Spec.) 1.2 為主, 它定義了每個類型充電器的可用電流上限, 以及充電器的類型.

原先大家的認知, 都是 USB 要支援 500mA 的電流. 但是實際上, 這種電流可能連外接硬碟都推不動. 於是大家可能都 "偷偷" 可以供到 1A. 從 BC 1.1 開始, 規範中就直接讓 USB 可以輸出 1.5 A 了.

在充電類型方面, 一共有三種定義:標準下行埠(Standard Downstream Port, SDP)、充電下行埠(Charging Downstream Port, CDP)及專用充電埠(Dedicated Charging Port, DCP). 

所謂的 SDP 就是標準的 USB HUB 輸出, 像是電腦或是螢幕基座上的 USB 輸出大抵都支援 SDP. 它的充電電流是 500 mA, 所以不致於充得太快! 甚至在被充電裝置完全沒電時, 可以先用 100m A 的小電流輸出, 等到充至 0.5~0.7 V 時才改回 500 mA.

這有什麼好處呢?如果沒有人在管電流限額, 而沒電的手機電壓已經趨近於 0 了, 當輸入阻抗很小, 那麼電流將會很大, 使得溫度過高, 說不定會燒壞什麼電路. 阻抗給很大, 那麼電流就會太小, 導致充得很慢. 因此, 聰明的控制電流是有必要的.

至於 CDP 可以提供 500mA 和 1.5A 兩種電流, 算是有 "兩下子" 的 USB 接口. 一般會先用 500mA, 若是符合 1.5A 的快充, 就會切換過去 [3, 4].

最後的 DCP 只能充電, 不能傳 data.

上面提到的都是 USB 2.0, 而一般 USB 3.0 都是用 USB 2.0 的規範充電.

USB 可持裝置 (portable device, 簡稱 PD) 要怎麼知道連上的是哪一種 USB Port, 並從而決定要抽多少電呢?判斷方式可以參考 ref  3 或 4. 簡單地說:

PD 先把 D+ 設為 0.6V:

1. D- 還在低電位, 表示 USB HOST 沒反應, 那麼這 HOST 是 SDP.

2. 若 D- 變成 0.6V, HOST 可能是 DCP 或 CDP.

PD 再把 D+ 或 D- (只有慢速設備會拉 D-) 拉高到高電位, 然後去看另外一根 D- 或 D+:

1. D- (D+) 還在低電位, 表示這是 CDP.

2. D-  (D+) 也變成高電位, 表示 D+ 和 D- 短路, 一定是 DCP.

因此 PD 有辦法知道它所連接的 port 是哪一種, 再進一步決定抽 0.5A 還是 1.5A.

最後, 一個裝置可能有時支援 CDP, DCP, 或 SDP , 這叫做 multi-role port. 若是不只是能支援充電, 還可以當 OTG 用, 這個叫做 ACA (Accessary Charge Adapter).

PD 只要有一個 micro-ACA, 它的 3 個 port 就同時扮演 device 當別人的 USB Storage (OTG Port), 當 host 外接鍵盤滑鼠 (Accessary Port) , 又被充電 (Charger Port). 一孔多用是未來的趨勢, 因此 ACA 早在 BC 1.1 的時候就被列入規範了.

[REF]

1. USB 快速充電知多少?使用跳線達成 AC 模式充電.

2. 滿足可攜式裝置電源需求 USB電池充電規範角色關鍵

3. USB Battery Charge Spec. 1.2

4.  解读USB-IF电池充电规范

Gerrit 帳號小註解

有些人應該也遇到過這個問題: 編 Android 的主機與 Gerrit 主機的帳號不一樣, 導致認證失敗. 前年我在 Gerrit 叫做 cashc, 但是我在編 code 的 Linux server 有時叫 cash, 有時叫 cashchou, 於是上述的冏事就發生了. 當時查了一些資料才搞定, 但這個痛過一年後就忘了, 連要用哪幾招都變生疏了. 最近公司也有人遇到, 我想我還是詳細地記錄下來比較好, 如此才能舉一反三 – 別人問一步, 我可以直接回答三步.

第一步就是在編 code 的 server 製作符合 Gerrit server 的 RSA 公鑰. 因為 gerrit 通常都是公司架設的, 就算是自己部門架設的, 也會引用公司 domain 的帳號密碼. 因此我們的 RSA key 要設成公司 email address. 假設您在公司的帳號是 username@companyname.com, Gerrit server 是 gerrit.companyname.com, port 是 29418.

ssh-keygen -C"username@companyname.com" -t rsa

此時把 ~/ssh/id_rsa.pub 貼到 Gerrit 接收的 key 的公鑰的欄位, Gerrit 就可以接受這把 key 的私鑰. 若設定都沒有錯誤, ~/ssh/id_rsa.pub 的最後一行就是 username@companyname.com.

第二步是對 Gerrit server 做 repo init. 舉例來說:

export MANIFEST_REPO=ssh://username@gerrir.companyname.com:29418/github/manifests

export MANIFEST_BRANCH=jb-dev

export MANIFEST_FILENAME=jb-20130405.xml

repo init -u ${MANIFEST_REPO} -b ${MANIFEST_BRANCH} -m ${MANIFEST_FILENAME}

第三步是 repo sync. 第一次做 repo sync 相當於 git clone. 由於 sync 的時候是用 .repo/manifest.xml. 所以要去手動修改這個檔案的內容, 把所有

<remote fetch="ssh://gerrit.companyname.com:29418" …

都改成  

<remote fetch="ssh://username@gerrit.companyname.com:29418" …

改完這三步就可以正確做完 repo sync.

不過, 故事還沒完. 因為您已經改過 manifest.xml 了, 下次再 repo sync, 系統就會提醒您有一個修改沒有 check in. 比較笨的方法就是每次都把原始的 manifest.xml 存起來 (rename 即可), 等到手動改的 manifest.xnl 做完 repo sync, 再回存舊版. 

一般來說, 如果 sync repo 失敗, 可以到有衝突的目錄做 git stash 保存現場. 等 repo sync 通過之後, 再 git stash pop 把自己的版本叫出來, 以便手動 merge code.

比較先進的 hack 方法是忽略掉我們對 manifest.xml 這個檔案的修改. 把永遠忽略的檔案加入 .gitignore, 以後 commit 就不會包含這個檔案, 但這不是這個狀況下所需要的. 我們現在只求忽略當前本地的 repository 就好, 因此可以把這個檔案加入 .get/info/exclude. 如此一來, 就不會失手把只適用自己的 manifest.xml 上傳到 git sever.

像我本身只編 code 來測試, 不改 code, 甚至可以忽略掉全部在本地端的修改. 此時可以用 git reset –hard HEAD 恢復到前一版.

[ref]

1. Repo 和 git 版本管理常用命令

2. 如何正确的repo sync?

青青子衿的聯想

高中的時候讀了陳曉林學長的 <青青子衿> 後相當受到感動, 所以去圖書館借了他推崇的史書來看. 轉眼過了快三十年, 只能依稀記得湯恩比和 <歷史研究>, 史賓格勒和 <西方的沒落>. 不但細節全部忘光光, 就連 "粗節" 也不復記憶. 總之, <歷史研究> 這兩冊書我看了很久 (據說英文版是 12 大本). 不過讀書花得時間再多, 也比不上陳曉林學長翻譯它花的工夫就是了.

湯恩比說, 每個文明都會經歷成長, 茁壯, 茂盛, 枯萎的階段, 而根據史賓格勒的觀察, 每個文明都會盛極而衰, 正如四季的變化. "西方即將沒落, 中國還很有搞頭!" 這個說法, 對當年的我們相當地有激勵作用. 果然今天中國很有地位, 雖然台灣還沒有…  "盛極必衰" 的概念在中華文化也是個基本常識, 不用治史也能理解. 倒是把春夏秋冬四個階段考慮進來的這個說法, 讓我有了個靈感. 它不但能套在文化上, 也能套在股票上~~~

春夏秋冬意味著每個階段都有不同的動作 – 春耕、夏耘、秋收、冬藏. 有些股票就像一年生草本植物, 今年的大利多發酵之後, 以後就要打回原形. 有些是多年生草本植物, 它能夠讓我們賺個好幾年, 然後才完蛋大吉. 更厲害一些的是木本植物, 它們可以活幾十年、幾百年, 包括股價低的灌木, 以及股價高的喬木. 喬木又分為: 穩定獲利的長綠喬木, 如台積電; 和大起大落的落葉喬木. 後者每次葉子掉光光時, 都讓人覺得它大概快死了. 至於是不是真的是最後一個冬天, 也沒有人能知道. 比方說: HTC.

年少時候讓人正面思考的能量, 中年時候卻變成了賺錢的點子, 這好像有點怪怪的. 不過, 呃…, 現在的正面能量都要靠自己從資源回收場提煉. 如果還要靠從前的養分, 應該是沒辦法撐這麼久. 哈! 

 

收購價格分攤小註解

收購價格分攤 (purchase price allocation) 牽涉到收購價金的細節, 一般來說分為三個部分. 

1. 決定價金是由現金、股權、或是兩者綜合所組成. 

2. 公允價格的評定. 其中有形資產的部分會牽涉到資產的耐用年限等等. 而無形資產是其中比較難評估的部分.

3. 評估財務報表衝擊. 因為在第二點僅僅是評定了價金, 並未考慮未來的折舊或是商譽減損的影響.

收購價金有一個很有趣的地方, 那就是有時價金可以被認列為併購期間的費用. 假如被併購對象的 B 公司員工持有大量的員工分紅或是認股. 而收購價金最後也會流入他們的口袋. 那麼在談判期間, 這些員工的薪水要列為費用? 還是價金呢? 收購公司 A 一共就付出這麼多錢, 如果這些薪資列為價金, 那麼 B 公司員工是以股東的身分獲得這些錢, 不需繳納所得稅.

不過對於 A 公司來說就比較吃虧了, 因為它所付出的 B 公司員工薪資等於是購買 "無形資產", 也就是溢價購買了 "商譽". A 公司併進 B 公司之後, 這些多花的 "商譽" 溢價就不存在了. 必須在隔年列為商譽的減損, 資產也就自動縮水了!

那麼列為 "期間費用" 會影響商譽嗎? 答案是不會! 因為根據美國 GAAP (Generally accepted accounting principles) 規定, 費用不得資本化. 比方說, 我們公司花 100 萬美金買了一個八角形輪子專利, 這個專利可以列為無形資產, 並且依專利有效期限攤提減損. 結果忽然有個圓形輪子的專利被提出來了, 這個八角形輪子的剩餘價值就要立刻改列為費用. 也就是彰顯公司花掉這個錢, 並且造成資產價值的下降 [1]. 

無形資產的定義有三個,認列條件有兩個, 符合這五項的東西才可以被承認為無形資產.

定義: (1) 具可辨識性, (2) 可被企業控制, (3) 具未來經濟效益.

條件: (1) 未來經濟效益可能流入企業, (2) 成本可以合理衡量.

何謂可辨識性呢?

1. 可與企業分離, 比方說要能賣、能授權給別人.

或者

2. 受到合約或法律保障. 像是租約.

一般無形資產包括專利權、競業禁止合約、未出貨訂單、優於行情的權利金合約、商標、網域名稱、電腦軟體.

我們出來上班, 大概都免不了簽一紙競業禁止合約, 它保障公司可以留住員工, 至少不會跑到競爭對手那裡去. 合約簽得是否合情合理, 或者合法是另外一回事. 比方說明明領最低法定工資, 競業禁止合約卻載明 "員工薪資已包括競業禁止補償金" 之類的. 話雖如此, 員工只在負面表列的競業禁止合約中被列為無形資產, 員工本身並不屬於公司的無形資產. 因為員工績效不能為企業控制, 也不具備 "可辨識性".

[Ref]

1. 南台科技大學 e-learning 會計課第十二章無形資產 (doc 檔)

2. 企業併購策略與最佳實務