You may have a list of subtitle files having different naming schemes than those video files to be matched. We can use Regex to rename these subtitle files.

Unix Shell

With Perl File::Rename utility:

rename 's/^.*?\[(\d+)\].*(\.\w+)$/$1$2/' *.ass  

Powershell

Get-ChildItem .\* -Include *.ass | Rename-Item -NewName { $_.Name -replace '^.*?(\d+).*(\.\w+)$','$1$2' }  

Encoding Conversion

Unix Shell

With enconv:

#!/bin/bash

find "$0" -type f -name "*.ass" -o -name "*.srt" -o -name "*.ssa" -o -name "*.sub" -o -name "*.sbv" -exec enconv -L chinese -x UTF8 "{}" \;  

With iconv:

#!/bin/bash

if [ -z "$1" ]; then  
    SRC="."
else  
    SRC="$1"
fi

if [ -z "$2" ]; then  
    ENCODING="gb18030"
else  
    ENCODING="$2"
fi

if [ -z "$3" ]; then  
    DESTI="UTF-8"
else  
    DESTI="$3"
fi

mkdir -p "${SRC}/out"

find "${SRC}/"* -maxdepth 0 -type f -name "*.ass" -exec sh -c "iconv -f \"${ENCODING}\" -t \"${DESTI}\" \"{}\" > \"${SRC}/out/{}\" " \;  

Powershell

ForEach ($f in Get-ChildItem .\* -Include *.ass) {[System.IO.File]::WriteAllText($f, [System.IO.File]::ReadAllText($f, [System.Text.Encoding]::GetEncoding('gb2312')), [System.Text.Encoding]::GetEncoding('utf-8'))}  

List of encoding names:

[System.Text.Encoding]::GetEncodings()

下載地址： https://github.com/YouDanMu/YouDanMu/releases/tag/v0.1.0

提交 Issues：https://github.com/YouDanMu/YouDanMu/issues

所以特地針對這種情況折騰了一個解決方案：在本地用 Squid 搭建一個 HTTP 緩存代理服務器，編寫緩存規則自動將常用網站的靜態文件長期緩存，第一次經過該代理加載成功後，Squid 會把資源緩存在硬盤，之後每次的相同請求都會直接將硬盤中的緩存返回給瀏覽器，不需要再向源地址請求資源。說白了就是本地搭建了一個 CDN 緩存服務器罷了。

Squid 在 Linux/Unix 下的安裝過程我就不講了。Windows 下的安裝過程有些坑要提一提。

首先下載 Squid for Windows，安裝完後運行 Squid Server Tray，會在系統托盤出現 Squid 圖標。右鍵 Stop Squid Service，但後 Open Squid Configuration，按照下面的配置模板寫好 Squid 配置。

# Squid 監聽的 HTTP Proxy 端口
http_port 3128

# 緩存目錄。參數：
# cache_dir Type Directory Mbytes L1 L2 [options]
#   - Type: 緩存數據格式，建議使用 aufs
#   - Directory: 目錄地址，因爲 Squid for Windows 是運行
#     在 Cygwin 虛擬 POSIX 環境中，如果你想要設置的目錄是
#     D:\Squid\cache，則寫成 /cygdrive/d/Squid/cache
#   - Mbytes: 緩存大小限制（MB）
#   - L1, L2: 緩存目錄一級二級文件夾數目，建議保持默認值
cache_dir aufs /cygdrive/d/Squid/cache 20480 16 256

# 在這部分添加常用網站的緩存規則。參數：
# refresh_pattern [-i] regex min percent max [options]
#   - -i: 正則匹配忽略大小寫
#   - regex: 緩存規則對應的正則表達式，用來匹配請求 URL，
#     如果匹配成功則使用該規則處理請求
#   - min: 該規則對資源緩存至少多少分鐘，對動態內容建議
#     設爲 0，靜態內容則越大越好
#   - percent: 該資源至少緩存上次生命週期的百分比
#   - max: 該規則對資源緩存最大多少分鐘
# 對於 options，推薦使用 override-expire ignore-no-store
# ignore-private ignore-reload 的組合強制進行靜態資源緩存
# - 參考 http://www.luocheng.cn/article-view-209.html

refresh_pattern ^https?://...\.bdstatic\.com/ 43200 90% 432000 override-expire ignore-no-store ignore-private ignore-reload  
refresh_pattern ^https?://assets\.xxxxx\.com 43200 90% 432000 override-expire ignore-no-store ignore-private ignore-reload  
refresh_pattern . 0 20% 4320

# 定義一個叫 localnet 的 IP 組，包含所有內網地址
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network  
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network  
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network  
acl localnet src fc00::/7       # RFC 4193 local private network range  
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

# 允許本地連接通過代理
http_access allow localhost manager localnet  
http_access allow localnet  
http_access allow localhost

# 防止 Squid 在 HTTP Request Header 中亂添加東西
# 導致某些網站檢測到 Proxy 特徵而禁止訪問
via off  
forwarded_for delete  
log_mime_hdrs on  
header_access User-Agent allow all

# 崩潰時 coredumps 目錄，建議保留默認
coredump_dir /var/cache/squid

# 設置 DNS 服務器
dns_nameservers 8.8.8.8 208.67.222.222

# 限制 Squid 的文件句柄數，Windows 有一定限制，不要改動
max_filedescriptors 3200  

請務必將所有中文註釋刪掉，然後將該配置文件保存爲 ANSI 文本文件，Squid 不支持 Unicode 配置文件。然後運行桌面上的 Squid Terminal 程序，執行 squid -z 初始化緩存目錄。如果出現類似

FATAL: Ipc::Mem::Segment::create failed to shm_open(/squid-cf__metadata.shm): (17) File exists  

這樣的錯誤，請到 Squid 安裝目錄，刪除 dev/shm/ 目錄下的所有文件再重新執行上述命令。

然後再 Start Squid Service，緩存代理服務器就應該架好了。

接下來在你的瀏覽器配置 HTTP 代理，感受一下緩存加速的效果吧。

And more to come soon...

These problems haunted me for very long time. Recently I finally found the way to solve all of them, so I decided to share these solutions.

Disable Tool Panels

In Adobe Reader, go to menu "Edit -> Preferences". Under "Documents", uncheck "Open tools panel for each document."

I also prefer to check "Restore last view setting when reopening documents." It remembers the page I left when reopening a file, which is very handy.

Default "Fit Width"

In Adobe Reader, go to menu "Edit -> Preferences". Under "Accessibility", check "Always use Page Layout Style," and choose "Single Page Continuous." Also Check "Always use Zoom Setting," and choose "Fit Width."

Fix Bookmarks

It's impossible to prevent the bookmark reset zoom operation in Adobe Reader, which is a TOTAL FAIL. However, I still found a workaround, which requires you to modify your PDF file with Adobe Acrobat Pro, with a plugin called PubHelper.

Download the PubHelper plugin. Unzip the PubHelper 0.991.api file to <Adobe Acrobat Pro>/Acrobat/plug_ins.

Then open your targeting PDF in Adobe Acrobat Pro. Click on any bookmark item, then press Ctrl-A to select all of them. Go to menu "PubHelper -> Bookmarks -> To Inherit Zoom". Now clicking any bookmark won't reset your zoom level.

I also prefer to run "PubHelper -> Bookmarks -> Expand all" to make all levels of bookmarks expanded by default.

Now save the modified PDF file. You can now switch back to Adobe Reader to view the file.

PS: I wish there's a GhostScript or pdfmark script that can substitue the use of Adobe Acrobat Pro and the PubHelper plugin to modify PDF files. If you know how please tell me in the comment section.

1. 便攜且實用，70% Layout
2. 無線+有線，支持多設備藍牙快速切換
3. 內置 USB 充電電池，有效續航
4. 有線供電下運載 16M 色域 RGB LED
5. PBT 雙色注塑定製透光鍵帽，採用 HHKB 曲面 Profile
6. 支援全新 Cherry MX RGB 系列軸體（要等 Corsair 獨占解禁）
7. 全鍵盤無衝（N-Key Rollover + USB 6-Key Workaround）

70% Layout

Axiom Keyboard Layout 基於 60% 的 HHKB，增加了一些常用功能鍵，包括方向鍵、Home、End、Page Up、Page Down，一共有 68 鍵，所以大概是一個 70% 的 Layout。

可以跟 HHKB Layout 對比一下：

可以看到 Axiom Keyboard 對最底部一行的空間利用得更加充分，並且對不習慣 Caps-Ctrl Exchange 的人保留了傳統的左下角 Ctrl 鍵位。增加的方向鍵同樣能提升用戶友好度。最右邊增設的一列功能鍵可以由用戶設定成自定義功能鍵，能給經常使用 IDE 環境工作的開發者帶來很多便利。

藍牙連接

我之前成功將 HHKB 改裝成了藍牙鍵盤，用的都是一些比較零散的模塊，而且對底層的控制也不是很深。經過一段時間的探索，我已經找到了一個大致的方向，這次我將選用 Texas Instruments 的 CC2564 藍牙芯片，它能提供完全符合 Bluetooth 4.0 標準的 HCI 控制接口，對底層的控制將更加靈活，希望在近期內能用它做出多藍牙設備快速切換的原型。

RGB LED

受最近 Corsair RGB 系列鍵盤的啓發，我打算給我的鍵盤也加上 16M 色域的 RGB LED 支持。對於電子電路來說，LED 的電壓控制是通過 PWM 實現的，一般的 MCU 只會配備很少的甚至完全沒有硬件支持的 PWM 模塊，如果要靠軟件模擬 PWM 將會消耗巨大的計算資源，幾乎無法實現。所以我們只能選擇外部的 LED Matrix PWM Driver IC 來完成這項工作。事實證明，Corsair 在它們的新產品中也選用了這種芯片：

可以看到 Corsair 使用了三塊 Panasonic AN32181B 芯片來控制多達 122 個 RGB LED。通過查看這塊芯片的 Data Sheet 我們可以看到，一塊這樣的芯片能輸出 144 個 PWM 信號，而一個 RGB LED 需要紅、黃、藍三個 PWM 信號，所以一塊芯片能控制 48 個 RGB LED。因此 Corsair 必須貼三塊這樣的芯片才能滿足控制 122 個 RGB LED，也就是 366 個 PWM Channels 的需求。

如果把 AN32181B 應用到 Axiom Keyboard 上，我們需要貼兩片才能控制 68 個 RGB LED。然而在我進一步的調查中發現，儘管在電子市場上沒有出售，但是 Panasonic 在它的一篇廣告文案中提到：

The AN3x Series is a single chip solution which can drive from 3 to 288 single color LEDs or from 1 to 96 RGB LEDs.

說明 Panasonic 有可能有未公開銷售的芯片模組擁有控制 96 個 RGB LED 的能力。對此我也在向松下的銷售人員求證，如果能夠搞到這樣的芯片，我們可能只需要一塊貼片就足以。

Oct 20 更新：松下的 Rep 回覆

Our product group advised:

It looks like this is misprint. Maximum number of LEDs with this series driver is 144.

所以這個系列芯片最多只支持 144 通道。不過也是，如果有更多通道的芯片的話 Corsair 沒理由不用呀。於是我們目前看來需要兩塊 AN32181B 芯片驅動我們的鍵盤 LED 矩陣。好在這款芯片支持 400kHz I²C 通訊協議，而且能選擇 4 個物理地址，也就是說我的 MCU 只需要用一個 I²C 接口就能同時控制最多 4 塊並聯在一起的 AN32181B 芯片，以及更多不同物理地址的其他 I²C 設備。

鍵帽

鍵帽的質量直接決定了鍵盤的使用舒適程度。我覺得做得最好的鍵帽當屬 HHKB。如果你仔細對比過 Cherry 原廠的鍵帽和 HHKB 的鍵帽你會發現，原廠鍵帽的每個側面都是平面，而 HHKB 的左右兩面其實是曲面。仔細觀察下面這個 HHKB R2 鍵帽模型的右側面：

你可以看到後面的一角是突出來的，說明這一面並不是平面。HHKB 這樣設計的目的是爲了讓頂部的觸摸面在不同的行高和斜度下都能保持同樣的規格，所以 HHKB 鍵帽整體看起來十分美觀，而且高度和斜度的變化也十分適合打字的手指運動。因此我打算以 HHKB Profile 爲基礎重新設計一套適用於 Cherry MX 的鍵帽。

鍵帽的製作工藝我打算使用 PBT 雙色注塑（Two-Shot Injection Molding），透光的圖案部分採用 ABS 材質，這兩種材質的粘合性非常好，國內有很多雙色注塑鍵帽用的也是這種工藝：

因爲是定製的模型，所以需要製作模具，中國東莞有很多注塑和模具的生產廠家，預計製作這樣一套模具將花費一萬到三萬人民幣不等。所以能否做出來還要看這套鍵盤能不能衆籌到相應的價錢。

鍵盤矩陣掃描芯片

熟悉鍵盤固件的人應該都知道矩陣掃描的工作原理。目前市面上絕大多數的鍵盤都是採用運載於 MCU 的軟件驅動的掃描程序來檢測按鍵事件的。然而 MCU 輪詢矩陣的過程中還要處理別的事情，比如 USB 通訊等等，所以需要分配計算資源，所以軟件驅動的矩陣掃描的頻率非常低，是跟着處理器頻率走的，MCU 的資源緊張的時候響應速度往往都在 5-10ms 級別。一般人難以察覺，但是像我這種對延遲異常敏感的人還是能察覺得到的。

爲了加快按鍵響應速度，我打算採用 Texas Instruments 的 TCA8418E 鍵盤矩陣掃描芯片。這款芯片能夠在 25μs 內掃描一個 8x10 的矩陣並做出響應。通過 I²C 端口通信，MCU 只需要在有按鍵事件的時候處理 Interrupt 就行了，並不需要分配資源進行矩陣掃描，效率將大大提高。這樣一來 MCU 甚至能夠進入完全休眠的節能狀態，只留下這塊芯片不停地掃描 Matrix，直到產出一個按鍵事件的 Interrupt 才進行 Wake Up，能大大節省休眠時期的能耗。

主控 MCU

大部分的 DIY 鍵盤爲了方便，都是用的 Hasu 的 AVR 固件，然而 AVR 在各方面來說都比較弱，當鍵盤的功能變多的時候，我們希望能有速度更快、內存更多、功耗不大的選擇。現在很多商業鍵盤裏面都是用的 NXP 的 ARM Cortex-M 系列 MCU。然而就個人而言，我覺得 ARM 架構對於一個 USB 設備而言太過複雜了，開發環境不容易搭建，代碼也比較複雜，很多功能都用不到，而且功耗也比較大。因此這次我想嘗試使用 Texas Instruments 專門爲 USB 產品設計的 MSP430 系列 MCU。

MSP430 雖然沒有 ARM 那麼強大，但是作爲鍵盤的主控芯片是綽綽有餘了，而且價格便宜功耗小。再加上 TI 豐富的開發資源跟開源的軟硬件工具鏈，開發過程相當容易。

總結

Axiom Keyboard 將是一款從頭到尾重新設計過的鍵盤，所有的部件都是以商業產品爲目標進行設計的。它的價格也同樣不會便宜，我預計它將會成爲高端玩家的新寵。讓我們拭目以待。

__attribute__ ( ( interrupt( TIMER1_A0_VECTOR ) ) )  
void TIMER1_A0_ISR( void )  
{
    //Toggle P1.0
    GPIO_toggleOutputOnPin(
        GPIO_PORT_P1,
        GPIO_PIN0
    );
}

But how exactly does this interrupt magical attribute works? How does the compiler know where exactly to place the interrupt handler's entry address inside the memory, defined by the interrupt vector table? Let's dig it up.

Interrupt Vector Addresses

First of all, let's connect the dots. We know from the MSP430 specification SLAU208O, 1.3.6 Interrupt Vectors that the interrupt vectors are located in the address range 0xFFFF to 0xFF80, each takes 2 bytes, or 16 bits. Each interrupt vector's value is actually a 16-bit memory address that points to somewhere stores the code to be executed when the corresponding interrupt was raised.

For example, for the previous TIMER1_A0_VECTOR interrupt, it actually corresponds to the TA1CCR0 interrupt flag if you understands the timer module. Thus we can look up the actual interrupt vector address from SLAS590M, 6.3 Interrupt Vector Addresses, Table 6-1 (assuming we are using MSP430F552X or MSP430F551X family MCUs). It shows us the interrupt vector address of TIMER1_A0_VECTOR is indeed 0xFFE2.

Specifically, it means at the memory address of 0xFFE2 on our MCU's flash, stores the 16-bit value of the memory address of the TIMER1_A0_ISR function, which will be calculated in the linking process by the linker tool. When the timer module raised an interrupt, the MCU will always read in the 16-bit value from 0xFFE2, stop and save the current job, and resume the CPU from the address just read in, which transfer the execution to the TIMER1_A0_ISR function.

Therefore, there have to be some sort of means to tell the linker to store the specific function's (future-calculated) address into a (pre-defined) memory address space. Thus a Linker Script can be used to assist the job.

Linker Script

A linker script is actually a memory and sections definition file to tell the linker how to map the input sections from the input object files to the output sections of the single output object file. It can also export symbols (with only addresses but no values) to the C programs sources.

When compiling with MSP430 GCC, a linker script is passed to the linker with -T command line option defined in your Makefile. For example in my case I'm including a linker script with

msp430-elf-gcc -L $(MSP430_GCC_DIR)/include -T msp430f5529.ld ...  

So the linker script is called msp430f5529.ld resides in the path $(MSP430_GCC_DIR)/include. Actually, all these MCU specific linker scripts were shipped with the full version of the MSP430 GCC (msp430-gcc-full-*), or you can download them separately with msp430-gcc-support-files-*.zip also listed in the download page.

If you open the linker script file, you can see the full layout of the device memory including all the interrupt vectors inside a code block called MEMORY. So let's find out where it defines 0xFFEA:

MEMORY {  
  ...
  VECT50 : ORIGIN = 0xFFE2, LENGTH = 0x0002
  ...
}

This line of code simply defines a memory space called VECT50. The number "50" here is just part of a name, like "a", "b", "c" etc. nothing special. What makes it meaningful is the next part. ORIGIN = 0xFFE2 specifies the start of the memory space at 0xFFE2 as we expected, and LENGTH = 0x0002 tells the linker this memory space only takes 2 bytes, so that if we put more than that into the space, some errors may occur during linking.

But VECT50 is only a memory space reference, like a C pointer. We have to "assign" something to the memory value to make it meaningful. This is done in the next code block SECTIONS.

SECTIONS {  
  ...
  __interrupt_vector_50 : {
    KEEP (*(__interrupt_vector_50))
    KEEP (*(__interrupt_vector_timer1_a0))
  } > VECT50
  ...
}

WOW, it looks terrifyingly complex. Let's break it down. So the SECTIONS block defines and assigns values to a set of named sections of the output object file. Practically you can use msp430-elf-objdump to dump the section table of the compiled ELF object file:

$ msp430-elf-objdump -h output.elf

Sections:  
Idx Name                  Size      VMA       LMA       File off  Algn  
  0 __interrupt_vector_50 00000002  0000ffe2  0000ffe2  00000572  2**0
                          CONTENTS, ALLOC,    LOAD,     READONLY, CODE
  1 __reset_vector        00000002  0000fffe  0000fffe  00000576  2**0
                          CONTENTS, ALLOC,    LOAD,     READONLY, DATA
...

You can see after linking, a section named __interrupt_vector_50 is exported to the output object file. Its Virtual Memory Address (VMA) and Logical Memory Address (LMA) are both 0xFFE2. It explained part of what the above linker script code did. The code __interrupt_vector_50 : {} > VECT50 simply declares an output section __interrupt_vector_50 to be stored inside memory space defined by VECT50, which starts at 0xFFE2 and has 2 bytes in size.

What makes it confusing is the inner part. We only defined a section called __interrupt_vector_50, but it's yet empty. To put something inside, we have to map some input sections into this output section.

The term "input section" may be confusing. So let me explain it a little bit. When we compile a C project, the compiler can generate object files for every C source file, such as "a.o" for "a.c", and "b.o" for "b.c" etc. In each object file, code and data are separated into a common set of sections, such as .data, .bss, .heap, text etc. There may also be some compiler defined and even user defined sections in some object files. When we link the intermediate object files, their sections were passed onto the linker as "input sections". The linker uses a set of rules defined by default or through a linker script to map the input sections from their original files to a set of newly defined sections. And the new sections, called "output sections", will be written to the output object file.

So basically, the inner statement *(__interrupt_vector_50) is a wildcard expression that includes input sections named __interrupt_vector_50 in all the input object files to the enclosing __interrupt_vector_50 output section. Please don't be confused by the naming. The outer __interrupt_vector_50 is the name of the output section, and the inner one is for the input section. The function KEEP() informs the compiler's optimizer to keep the mapped section data since it's not referenced by any C code and may be otherwise considered redundant and optimized out.

We can see there's one more statement that includes input sections __interrupt_vector_timer1_a0 from all input object files. So basically it works like an alias for input sections __interrupt_vector_50 in application level.

Now we know the linker puts the contents in the __interrupt_vector_50 or __interrupt_vector_timer1_a0 input sections into the output section called __interrupt_vector_50 which resides at the interrupt vector at address 0xFFE2 and takes 2 bytes in space. So the next step is to find out what's actually inside the input sections __interrupt_vector_50 or __interrupt_vector_timer1_a0.

Exploring with objdump

Before we dive deeper into the compiler implementation, let's pause and see what we can get using the msp430-elf-objdump utility. First let's see what's actually inside the interrupt vector address 0xFFE2.

$ msp430-elf-objdump -s --start-address=0xFFE2 --stop-address=0xFFE4 output.elf

Contents of section __interrupt_vector_50:  
 ffe2 fe46                                 .F

We can see that at 0xFFE2 there stores a 16-bit value 0xFE46. As we already know, it's the memory address of the TIMER1_A0_ISR interrupt handler function. Since MSP430 processors are little-endian, the actual address should be 0x46FE. Now let's see what's inside that address.

$ msp430-elf-objdump -S --start-address=0x46FE --stop-address=0x4700 output.elf

Disassembly of section .text:

000046fe <TIMER1_A0_ISR>:  
__attribute__( ( interrupt( TIMER1_A0_VECTOR ) ) )  
void TIMER1_A0_ISR( void )  
{
    46fe:          bf 15           pushm   #12,    r15     ;16-bit words
    ...

As we expected, it leads us to the interrupt handler function. But if you can recall, the value stored in 0xFFE2 is actually the contents of input sections __interrupt_vector_50 or __interrupt_vector_timer1_a0. In this case, it means the value of this input section is indeed 0x46FE, and is the memory address of the TIMER1_A0_ISR interrupt handler function.

As I mentioned before, the address of a specific function can only be calculated in the linking process, so it's impossible to hard-code it inside C code, nor in linker scripts. So the only way to put the function address into the memory section's content is through the magical interrupt function attribute implemented in the MSP430 GCC. To understand it, we have to look inside the MSP430 GCC source code. After some quick digging, I found the implementation in gcc/gcc/config/msp430/msp430.c:

void  
msp430_start_function ( FILE *file, const char *name, tree decl )  
{
  tree int_attr;

  int_attr = lookup_attribute ( "interrupt", DECL_ATTRIBUTES ( decl ) );
  if ( int_attr != NULL_TREE )
  {
    tree intr_vector = TREE_VALUE ( int_attr );

    if ( intr_vector != NULL_TREE )
    {
      char buf[101];

      intr_vector = TREE_VALUE ( intr_vector );

      /* The interrupt attribute has a vector value.  Turn this into a
         section name, switch to that section and put the address of
         the current function into that vector slot.  Note msp430_attr()
         has already verified the vector name for us.  */
      if ( TREE_CODE ( intr_vector ) == STRING_CST )
        sprintf ( buf, "__interrupt_vector_%.80s",
                  TREE_STRING_POINTER ( intr_vector ) );
      else /* TREE_CODE (intr_vector) == INTEGER_CST */
        sprintf ( buf, "__interrupt_vector_%u",
                  ( unsigned int ) TREE_INT_CST_LOW ( intr_vector ) );

      switch_to_section ( get_section ( buf, SECTION_CODE, decl ) );
      fputs ( "\t.word\t", file );
      assemble_name ( file, name );
      fputc ( '\n', file );
      fputc ( '\t', file );
    }
  }

  switch_to_section ( function_section ( decl ) );
  ASM_OUTPUT_TYPE_DIRECTIVE( file, name, "function" );
  ASM_OUTPUT_FUNCTION_LABEL ( file, name, decl );
}

As the comment above suggests, the interrupt attribute takes the interrupt name as its argument. In our example, __attribute__ ( ( interrupt( TIMER1_A0_VECTOR ) ) ) takes TIMER1_A0_VECTOR as the interrupt name. It's actually a macro defined in the MSP430 driver library:

#define TIMER1_A0_VECTOR   (50)   /* 0xFFE2 Timer1_A3 CC0 */

Then the interrupt attribute will create a section with the name prefixing __interrupt_vector_ to the interrupt name. So in our example, the created section is called __interrupt_vector_50. As you may recall, this is indeed the input section name we were expecting to pass onto the linker. Finally the interrupt attribute puts the address of the current annotating function, i.e. 0x64FE for TIMER1_A0_ISR in our case, into the newly created section.

Summary

Now we've connected all the dots. Let's wrap it up. Firstly we use __attribute__(interrupt(INTERRUPT_NAME_MACRO)) to tell the compile generate a new section named __interrupt_vector_INTERRUPT_NAME_MACRO, storing the memory address of the annotating interrupt handler function. Then during the linking process, we use the TI provided linker script to map all the interrupt generated sections into correct memory spaces in the interrupt vector table defined by the MSP430 specifications.

後來想了想，我并不希望讓這個插件僅局限于 YouTube，考慮到現在很多 ACG 内容也會推到臉書上，我希望 YouDanMu 能實現一種通用的彈幕插件接口，把大部分視頻網站的播放器抽象到我們内部的通用播放器接口上，還能接入 Bilibili、AcFun 等主流彈幕網站的彈幕數據，甚至跟這些網站的用戶系統進行對接等等。再考慮到現在 Web Extension 規範的流行，我們甚至能同時提供 Chrome、FireFox、Opera 等等的跨瀏覽器支持。

這麽一想，這坑還確實不小，但是深入瞭解一下還是能發現不少前人已經填好的坑，我們衹需要踩著別人填好的坑繼續往前跳就好了。

項目地址：GitHub/YouDanMu
（現有的代碼寫在 experiment/Chrome 這個 branch 上）

因此我對未來可能成為 Anti-Censorship 核心的技術進行了一些簡單的預測。

Tor

能夠隱藏用戶 IP 地址的 P2P 加密網絡。以後很有可能所有的 Anti-Censorship 技術都需要基於 Tor Service 來隱藏用戶的 IP 地址，這將成為新的網絡協議層。

但光靠 Tor 是無法對抗 Censorship 的，要知道最嚴厲的 Censorship 是打擊犯罪。連 Silk Road、Silk Road 2 的管理員都陸續落網，證明 Tor 網絡是有缺陷的。^[1] 雖然 Tor 能隱藏用戶的身份，但是 Tor 提供的 Onion Net 網站協議卻是一種傳統的中心化網站模式，所有 Onion 網站都必須有一台中央服務器提供服務，而且有一批運維團隊要對這台服務器進行維護，也就是說存在所謂的「頭號人物」。FBI 就是從這些「頭號人物」入手，派遣特工滲透到這批管理層內部，從人員方面攻破了這些犯罪組織，然後在法庭上再用 Parallel Reconstruction 重現證據鏈。雖然有傳言說 CMU 研究出了某種方法能追蹤到 Tor 網絡中用戶的身份，甚至在法庭上用這種技術提供了取證。^[2] 但是這還是基於 Tor 服務存在中央服務器的事實才能做到的。

新一代的 Anti-Censorship 技術會繼續使用 Tor 的網絡層，但不會沿用 Onion Net 層。基於 Tor 之上建立的服務將是完全去中心化的 P2P 應用，將不存在中央服務器，也不再會有「頭號人物」一說，就算把所有開發者都抓起來，這種分佈式的網絡仍然能自主運轉，只是沒有了技術支持停止更新了，而不像 Silk Road 那樣人一抓服務器一查就渣都不剩了。

現在已經有這種 Decentralized P2P Anonymous E﹣Commerce 平台出現了，比如 OpenBazaar。^[3] 目前這個平台還處於 Beta 版本，所以內容還是很和諧的，但是考慮到現在非法交易在 Onion Net 網絡中沒有一個安穩的棲息之地，這片淨土估計很快就會被污染掉。到時候 FBI 要打擊這種完全沒有中央服務器、沒有領導班子的平台估計會相當頭疼。

ZeroNet

具有動態內容接口的 P2P 分佈式網站框架。沒錯這就是我預測的今後將代替 Onion Net 層的去中心化 P2P Web 服務協議。這個協議本身不考慮對用戶的身份信息進行保護，但是它的設計就是為了能和 Tor 一起搭配使用的匿名分佈式網絡系統，所以用戶想要隱藏身份是可以很輕鬆地進行配置的。

在 ZeroNet 中每個用戶都有一個公鑰加密身份，可以作為用戶的賬戶進行動態內容發佈。ZeroNet 提供了一套動態內容接口，以前的 FreeNet 也是一套去中心化的 Web 層，但是只支持靜態頁面，ZeroNet 的動態網頁支持完美彌補了 Onion Net 和 FreeNet 的兩大缺陷。配合 Tor 網絡層進行匿名處理后就已經能挑戰非常嚴峻的 Censorship 了。

IPFS

提高 P2P 分佈式網絡數據分發效率的 CDN 協議。這套協議的初衷跟 Censorship 沒有什麼關係，它解決的是目前網絡數據分發中存在的現實問題：比如一棟樓裡面有5個人同時觀看一個 YouTube 視頻，但是 YouTube 卻必須把同樣的視頻數據發送5次給這5個人。IPFS 能大大減少這種網絡開銷，它利用 P2P 網絡的原理實現了一個分佈式文件系統，在數據結構上跟 UNIX 的 INODE 文件存儲方式非常類似，每一個 Block 的 Hash 值是固定的，於是就能依靠 P2P 網絡進行分發，這樣同一份視頻數據理論上只要發送一次就能提供同一棟樓的5個用戶觀看，乃至更多。

這種 P2P CDN 協議能為新一代 Anti-Censorship 網絡解決速度和容量的問題。對於 ZeroNet 來說並不適合直接把大文件像多媒體文件存在分佈式節點上，這樣會增加很多不必要的網絡開銷。IPFS 能夠將這些大文件進行按需分配、並且能保證良好的速度。我覺得將來的 P2P Streaming 會使用這種技術。

NameCoin

以比特幣核心技術為基礎的區塊鏈 DNS 系統。我朝最喜歡搞的就是 DNS 污染了，再加上最近出台的域名政策名正言順地給 DNS 污染安上了法律的擋箭牌。這樣一套分佈式的 DNS 系統很好地解決了這個問題。ZeroNet 直接支持 NameCoin 的 .bit 域名解析，整合起來十分方便。再加上 .bit 的設計非常簡單，價格公道，我覺得將來能成為 Anti-Censorship 網絡流行的域名解決辦法。

Conclusion

還有很多 Anti-Censorship 的技術正在如火如荼地開發當中，這其中還有很多更理論的東西，比如更加完善的密碼學套件支持等等。DuckDuckGo 今年捐了 225,000 USD 給這些優秀的 Anti-Censorship 項目。^[4] 如果你不希望活在一個沒有信息自由的世界中，也請偶爾為這些項目捐獻一杯咖啡吧。

爲了簡化問題，請考慮下面這段代碼：

(function(global){
    function GUID(secret) {
        this.secret = secret;
    }
    GUID.prototype.generate = function() {
        return Math.floor((1 + this.secret) * 0x10000000000000).toString(16).toUpperCase();
    };
    GUID.history = [];
    GUID.guid = function() {
        var id;
        do {
            id = (new GUID(Math.random())).generate();
        } while (GUID.history.indexOf(id) >= 0);
        GUID.history.push(id);
        return id;
    };
    global.guid = GUID.guid;
})(window);

這是一個簡單的 GUID 生成器（爲了簡單并沒有按照 RFC 4122 規範來寫，請不要使用）。他會向外部暴露一個 window.guid() 函數，每次調用時它會生成一個隨機數作爲種子， new 一個 GUID 對象，產生一段 GUID 碼，如果這段 GUID 碼存在于 GUID.history 中則重新生成，以保證生成 GUID 碼的唯一性（爲了簡單這個唯一性衹在這段程序的生命周期中有效）。

我們現在要寫一個瀏覽器插件，在不改動上面這段代碼的情況下，我們可以在這段代碼執行前後的全局作用域中添加我們的代碼，我們最終的目的是拿到閉包中 GUID 私有對象（Function）的讀寫權限。即我們能操縱 GUID.history，比如能夠刪掉之前生成過的 GUID 碼記錄讓唯一性失效等等。

這個簡化版的問題正是我在對 YouTube 内部 API 進行劫持時遇到的等同問題，如果我們能解決這個簡化版的問題，那麽也就能成功劫持到 YouTube 的内部 API 對象了。

「偷天換日術」

我們先來看看這個「偷天換日術」的實現代碼：

/* 「偷天換日術」的實現部分 */
Object.defineProperty(Function.prototype, 'guid', {  
    __proto__: null,
    enumerable: true,
    configurable: false,
    get: function _getter() {
        return this._guid;
    },
    set: function _setter(value) {
        value._this = this;
        this._guid = value;
    }
});
/* 這是原來的代碼 */
(function(global){
    function GUID(secret) {
        this.secret = secret;
    }
    GUID.prototype.generate = function() {
        return Math.floor((1 + this.secret) * 0x10000000000000).toString(16).toUpperCase();
    };
    GUID.history = [];
    GUID.guid = function() {
        var id;
        do {
            id = (new GUID(Math.random())).generate();
        } while (GUID.history.indexOf(id) >= 0);
        GUID.history.push(id);
        return id;
    };
    global.guid = GUID.guid;
})(window);
/* 結果演示 */
window.guid();  
console.log(window.guid._this.history);  

可以先在瀏覽器裏面跑一跑體驗一下，然後可以跟蹤調試一下并嘗試理解。在 _getter 和 _setter 的函數裏面設置斷點，在中斷的時候追溯一下 Call Stack 嘗試理解一下工作原理。

通過跟蹤我們能發現，這個「偷天換日術」最關鍵的一步發生在 GUID.guid = function() ... 這裏。我們知道，GUID 是一個 Function，不，準確來説是 Function 類的一個實例，相當於 new Function() 的結果，所以 GUID 應該繼承了 Function 這個類的 prototype，也就是說 GUID.__proto__ === Function.prototype。如果這裏不理解，請溫習一下 JavaScript 的面嚮對象編程以及封裝方法（by 阮一峰）。

其次我們知道，在 JavaScript 中對一個對象 x 的屬性 y 進行賦值的流程是這樣的：

1. 如果在當前對象的直屬屬性中存在名爲 y 的屬性，則調用 y 相應的 setter 將新的值傳進去，同時設置這個 setter 的 this 爲 x；如果該屬性存在但是沒有定義 setter 則直接賦值在它的 Property Descriptor 的 value 屬性上。
2. 如果在當前對象的直屬屬性中找不到名爲 y 的屬性，則訪問當前對象的 __proto__ 屬性，如果 __proto__ != undefined 則把當前對象替換爲該 __proto__ 屬性，然後重複步驟 1。
3. 如果 __proto__ 訪問發生循環，或最後訪問到的 __proto__ == undefined，則終止 __proto__ 鏈訪問。這種情況下，JavaScript 才會重新回到最開始的對象 x 上面，在它的直屬屬性中定義一個新的名爲 y 的屬性，并賦值在它的 Property Descriptor 的 value 屬性上面。

我們把這種遞歸式的屬性查詢訪問稱爲 Prototype Chain。我們可以把整個流程用 JavaScript 重現一遍：

function assignProperty(object, property, value) {  
    var current = object;
    var protoChain = [current];
    while (true) {
        if (current.hasOwnProperty(property)) {
            var descriptor = Object.getOwnPropertyDescriptor(current, property);
            if (typeof descriptor.set === 'function') {
                descriptor.set.call(object, value);
            } else {
                descriptor.value = value;
                Object.defineProperty(current, property, descriptor);
            }
            break;
        } else {
            if (current.__proto__ != undefined
                && protoChain.indexOf(current.__proto__) < 0) {
                current = current.__proto__;
                protoChain.push(current);
            } else {
                Object.defineProperty(object, property, {
                    configurable: true,
                    enumerable: true,
                    value: value,
                    writable: true
                });
                break;
            }
        }
    }
}

這段代碼將讓 x.y = 'value' 等價于 assignProperty(x, 'y', 'value')，可以試試。

看到這裏，我想很多人都已經明白了這個「偷天換日術」的秘密了。最關鍵的一點，在於 Prototype Chain 賦值操作中，一個屬性擁有 setter 的時候，調用 setter 的同時會將 this 設置爲最上級的對象。也就是説，如果我們能在一個對象 x 的某一級 __proto__ 中定義一個帶有我們自己設置的 setter 的屬性 y，所有對 x.y 進行的賦值操作，除了會把新的值傳給我們的 setter 之外，還會把 setter 調用的 this 設成 x，所以我們在 setter 中訪問 this 就是在訪問 x。明白了這點，這個「偷天換日術」就不是什麽秘密了。

最後的問題就是如何在 GUID 的某層 __proto__ 中插入一個我們提前制定好了 setter 的 guid 屬性。之前我們講到了，GUID 繼承了 Function.prototype，用 JavaScript 重現一遍 function GUID() {...} 的内部實現就是：

var GUID = Function('/* function body ... */');  
GUID.__proto__ = Function.prototype;  
// 真正的内部實現還有很多別的内容，此處簡化省略

所以你看，我們衹要修改一下 Function.prototype 這個全局變量，就能在 GUID 的 Prototype Chain 上面隨意地添加「陷阱」了。好了我們再回頭看看我們的「偷天換日術」的實現：

/* 「偷天換日術」的實現部分 */
Object.defineProperty(Function.prototype, 'guid', {  
    __proto__: null,
    enumerable: true,
    configurable: false,
    get: function _getter() {
        return this._guid;
    },
    set: function _setter(value) {
        value._this = this;
        this._guid = value;
    }
});

可以看到，我在 Function.prototype 上面定義了一個同時帶有 setter 和 getter 的屬性 'guid'。於是在原來代碼執行到 GUID.guid = function() ... 這裏的時候，就會執行我們定義的 setter，把新的值（一個 Function）作爲參數傳進來，同時把 setter 的 this 設置成 GUID。於是在這個 setter 中我們就能進行「偷天」：把 this，也就是 GUID 放在 value 的 _this 屬性上，注意這個 value 最後會被暴露到全局作用域上，我們就能通過它把 GUID 一起帶出去。其實我這麽寫衹是爲了好看，我們完全可以在這個 setter 裏面直接把 this 賦值給一個全局變量，比如 window.GUID = this，就直接偷到 GUID 了。爲了優雅，我還加上了「換日」：setter 會把傳進來的值存在一個別的屬性 _guid 上，然後我寫了一個 getter，會把 _guid 返回回去。所以在原來的代碼 global.guid = GUID.guid 這裏我們得到的 guid 實際上來自於 GUID._guid，而且上面還帶著我們「偷天」回來的 _this 屬性，一起被傳出了全局作用域。

那麽一式 JavaScript 之「偷天換日術」就是這樣了。

1. Disconnect J10 and J13

From the FRDM-K22F Freedom board for Kinetis K22 Hardware document Section 13, it points out that

The debug interface on the MK22FN512VDC12 MCU is a serial wire debug (SWD) port with trace output capability. There are two debug interfaces on the FRDM-K22F: an onboard OpenSDAv2 circuit (J5) and a K22F direct SWD connection via a 10-pin header (J11).To use an external debugger, such as J-Link on J11, you may need to disconnect the OpenSDAv2 SWD circuit from the K22F by removing jumpers J10 and J13.

Therefore, to use with external J-Link debugger, we need to disconnect the J10 and J13 jumpers to disable the on-board OpenSDA debugging functionality, but instead allowing external connections.

On the board we can find the two jumpers J10 and J13 connected by two jumper shunts.

We can simply unplug the jumper shunts to disconnect J10 and J13.

2. Connect J-Link to K22F SWD Debug Interface

From the FRDM-K22F Quick Start Guide pg.2, we can find out the SWD interfaced located on the board.

And then, on the bottom side of the board, we can find out the pin numbering of the SWD interface.

From the FRDM-K22F Freedom board for Kinetis K22 Hardware document Section 3.2.1 we can find out the pin assignment schematic of the SWD interface.

So here is the pin assignment for J-Link SWD connection port, numbers in orange are the pin numbers of the SWD interface on the FRDM-K22F board.

You can connect these pins manually to your J-Link debugger, but the simplest way is to buy this J-Link adapter to connect them directly.

Just be careful at the direction of the connector plugging on the board as there's no indication slot for you.

3. Debugging with J-Link Debugger

Now plugin your J-Link device to your computer, and launch the J-Link Debugger program.

In the new project wizard window, click the "..." button under "Device" option.

In the popped up window, search and select Freescale MK22FN512xxx12 then click "OK". Then click "Next".

In the Connection Setting window, select Target Interface as SWD. Type your J-Link device's Serial No which you can find on the bottom of the device. Then click "Next".

Click "Finish".

Now you have successfully connected your FRDM-K22F board with an external Segger J-Link debugger. Try load a program and start debugging.