當然肯定還有滑稽
讓Coreseek支持索引日語假名
coreseek是一個修改版的sphinx，用mmseg來做中文分詞。但是發現一個問題，日語搜索總是效果很差，全部是假名的關鍵詞會返回一個空結果。
開始猜想是不是詞庫沒有包含日語的關係，後來仔細想了一想，mmseg對於沒有在詞典里的詞應該是直接一元分詞的，按理說也不應該出現無法索引日語的關係。我們可以通過mmseg命令行工具來證明這一點：
|
1 2 |
$ /usr/local/mmseg/bin/mmseg -d /usr/local/mmseg/etc/ 1.txt ヨ/x ス/x ガ/x ノ/x ソ/x ラ/x |
證明mmseg進行了一元分詞。
那麼為什麼coreseek搜不到假名呢？我找啊找啊終於發現在coreseek使用mmseg進行分詞的過程中，對輸入字符做了一個過濾，並且有一個注釋：
|
1 2 3 4 5 |
// BEGIN CJK There is no case folding, should do this in remote tokenizer. // Here just make CJK Charactor will remain. --coreseek dRemaps.Add ( CSphRemapRange ( 0x4e00, 0x9FFF, 0x4e00 ) ); dRemaps.Add ( CSphRemapRange ( 0xFF00, 0xFFFF, 0xFF00 ) ); dRemaps.Add ( CSphRemapRange ( 0x3040, 0x303F, 0x3040 ) ); |
可見coreseek雖然將CJK (Chinese, Japanese, Korean) 中所有漢字、全角字符和標點加入了範圍，但是卻漏掉了平假名和片假名。因此我們將第三個range改成0x3000, 0x30FF, 0x3000就可以修正這個問題。
其中：
|
1 2 3 4 |
// 4e00 - 9fff CJK unified ideographs // 3000 - 303f CJK symbols and punctuation // 3040 - 30ff Hiragana/Katagana // ff00 - ffff half/fullwidth forms |
我把修改後的版本放到了github
另外，這裡可以查詢到Unicode編碼範圍對應的字符內容；unicode.org有一個database，但是是一個列出了全部字符的大pdf，我似乎沒有找到類似的分類。
對於Ubuntu/Debian，這裡有編譯好的coreseek的deb包：i386 amd64；依賴於mmseg：i386 amd64；mmseg自帶的詞典
對於>2.2.10的版本，我在這篇博客里提供了完整的補丁，可以應用在sphinx的源碼上編譯。
Python中熱補丁(Hot Patching)的實現和一些問題
Let’s Encrypt！
試一下Let’s Encrypt
順便前幾天剁了Alpharacks的辣雞vps，拿來做前端好了，聽說國內效果ping不錯（？
因為還有一堆微博圖床上的圖沒法https，所以就不強行301了，你們看心情就好
搭建一個不被審查的串流站點
原標題：被害妄想症該如何生存
先看配置：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
server { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl default_server; root /usr/share/nginx/html; ssl_certificate certs/default.pem; ssl_certificate_key certs/default-nopass.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; } server { listen 443 ssl spdy; ssl_certificate certs/real-cert.pem; ssl_certificate_key certs/real-cert-nopass.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; root /usr/share/nginx/html; server_name example.com; location / { root /path/to/your/files; if (-d $request_filename) { return 404; } try_files $uri $uri/ =404; charset utf-8; } location ~ .*/$ { root /path/to/your/files; access_by_lua ' local coo = ngx.var.cookie_coo if coo ~= "coo" then ngx.exit(404) end '; autoindex on; autoindex_exact_size off; } } |
假設：
審查機關擁有運營商級別的入侵檢測設備（比如GFW）
說明：
- 全站使用https，關閉SSLv3，關閉弱加密組件
- default_server開啟80端口，使用自簽名證書；真實需要訪問的域名(example.com)必須使用有效的證書，或者在本地信任根證書。注意example.com不能開啟80端口，且與default_server使用的證書不能相同。不要使用泛域名證書。這是為了防止審查機關通過直連IP查看返回的證書中的Common Name來得到真實域名。這樣配置之後，直連IP https://xxx.xxx.xxx.xxx默認是返回自簽名證書，無法得到真實example.com。
- 選擇性開啟autoindex，通過cookie鑒別。注意也可以通過HTTP Basic Authenication認證。對匹配文件夾的uri（”/”結尾）做認證，示例中只有帶cookie coo=coo的請求才會返回autoindex，否則返回404。
- 在location /中禁用目錄末尾自動加斜杠，因為如果自動加斜杠，審查機關可以通過暴力猜測出服務器上有哪些目錄確實存在（返回了301到末尾加/的url）。方法是if (-d $request_filename)返回404。
