Ceeji 篤志者 - 宁心勉学，慎思笃行

紹興之旅（4）：陽明故里、沈園與書聖故里

Thu, 02 May 2024 16:08:56 +0800

這次旅程的第四天，我主要去了紹興的陽明故里、沈園和書聖故里。

此心光明——陽明故里

陽明故里是王守仁（即「王陽明」）的故居所在地，其建築已經只剩地基上一些樁石之類，現在看到的大多數內容是近幾年新建的。但是，它在考古挖掘的重點區域透過透明玻璃的方式保留了現場，因此你可以看到一些「真傢伙」。我去的時候剛好碰到政府的觀光團，有導遊隨行講解，也因此大致瞭解了王陽明相關的一些故事。整體而言，這個地方能看到的東西不多。

王陽明故居21mm f/6.3 E 17-28mm F2.8-2.8

王陽明故居玻璃下的考古現場17mm f/2.8 E 17-28mm F2.8-2.8

王陽明對死生非常豁達。據說其臨死前留下的遺言為：「此心光明，亦復何言？」

此心光明20mm f/2.8 E 17-28mm F2.8-2.8

除了建築，這個景點還有一個王陽明的紀念館。但是裡面的東西不是很多。看完陽明故里，我就抓緊趕往沈園，因為此刻已經是下午三四點鐘。

去沈園步行路上27mm f/2.8 E 17-28mm F2.8-2.8

沈園門口的小河27mm f/2.8 E 17-28mm F2.8-2.8

沈園

昨天我去看了沈園之夜，今天繼續來看白天的沈園。沈園也是建國後重修的，在門口有重修之記。

重建沈園碑記24mm f/2.8 E 17-28mm F2.8-2.8

沈園的名氣幾乎全依賴於陸游在此的故事。簡單來說，陸游在父母的安排下，迎娶表妹唐婉為妻。兩人的婚姻雖然是父母之命媒妁之言的老式婚姻，可是卻超乎尋常的幸福。陸游的母親唐氏本是這場婚姻的主導者，可是，在唐婉過門之後不到三年，唐氏就對自己的侄女唐婉厭惡不已，強逼著兒子把唐婉趕走。主要原因一是覺得陸游沉湎女色，不務正業，讓父母焦慮不安。另一個原因，可能是唐婉不孕。古人多希望「早生貴子」，像陸游續娶王氏，次年就生了一個大胖小子。可唐婉婚後兩年多，肚皮竟然一點訊息也沒有。這在古代可是「七出」之首的嚴重罪過。

於是，唐婉就有了兩大罪名：讓陸游倦於科舉，影響仕途；婚後三年不孕，不能傳宗接代。最終，陸母下令，將唐婉驅逐出陸家家門。

在31歲時，陸游偶然在春末遊覽沈園，巧遇唐婉，回想起過往種種，在沈園的牆壁上寫下流傳千古的《釵頭鳳》，表達自己的愁緒。據說後續唐婉也回詩一首，詞牌也是「釵頭鳳」。

但這個故事的真實性我覺得很難說，很多細節在史料中沒有證據。甚至有人認為唐婉這個名字是明清時編出來的，而且唐嫁也沒嫁趙士程，趙士程是有老婆陳氏的，還有六個孩子，沒了一個，剩下五個。

沈園中的兩首釵頭鳳17mm f/2.8 E 17-28mm F2.8-2.8

沈園的風景是典型的江南園林。在入口有一塊斷了的石頭，據說象徵情緣斷裂，我好奇這石頭是不是重建沈園的時候專門找人砸開的？

斷石27mm f/2.8 E 17-28mm F2.8-2.8

沈園的面積不小，重修經歷了好幾期，現在如果要全部轉完需要點時間。裡面有一個陸游的紀念館，僅僅這一個紀念館面積就不小。

陸游紀念館最深處24mm f/2.8 E 17-28mm F2.8-2.8

書聖故里

我以為書聖故里是王羲之的某個故居之類，沒想到又是一個歷史街區，主要是古橋和古建築。其中比較有名的是題扇橋。

書聖故里24mm f/2.8 E 17-28mm F2.8-2.8

題扇橋20mm f/2.8 E 17-28mm F2.8-2.8

紹興之旅（3）：蘭亭景區、印山越國王陵、八字橋周邊與沈園之夜

Tue, 30 Apr 2024 22:54:44 +0800

蘭亭景區

因為公司有事，我在4月10日回到杭州處理事情。第二天，我重新出發踏上了旅途。這一次，我先來到了紹興蘭亭景區，這裡主要是一些與王羲之有關的人文景觀，其中最多的就是各種書法作品的石刻和亭臺樓閣。據說「蘭亭集序」就是王羲之在這裡所寫就。

蘭亭入口24mm f/4.0 FE 24-105mm F4 G OSS

進入景區不久就是「鳶（yuān）池」，裡面似乎養了幾隻鳶，但我並不知道「鳶」到底是什麼，查了一下資料依然是雲裡霧裡。

鳶池書法24mm f/4.0 FE 24-105mm F4 G OSS

鳶池的「鳶」56mm f/4.0 FE 24-105mm F4 G OSS

這裡有一塊康熙寫的「蘭亭」的碑，但在文化大革命中被損壞，成為殘字。

「蘭亭」碑亭24mm f/4.0 FE 24-105mm F4 G OSS

與之前一樣，我並沒有提前做什麼功課，但我剛好碰到了它的「書聖節」，就是每年一度紀念王羲之以及舉行一些書法活動的節日。因此，景區里人比較多，而且到處都是活動相關的內容。下面這張圖的橫幅就是活動所懸掛的，這裡在我來之前不久剛舉辦過晉聖儀式。

晉聖儀式24mm f/4.0 FE 24-105mm F4 G OSS

在這個地方不遠處就是傳說中「九曲流觴」之地。一千年前，古人喜歡圍坐在這樣的小溪流邊，放入酒杯，讓酒杯順水而流，流到誰那裡就要作詩作文。而此刻，這個地方有幾個外國留學生說著流利的中文在討論問題。

流觴亭24mm f/4.0 FE 24-105mm F4 G OSS

九曲流觴之地24mm f/4.0 FE 24-105mm F4 G OSS

整個蘭亭景區最多的就是「蘭亭集序」，比如這裡有一個非常高大的蘭亭集序的書法碑文：

蘭亭集序24mm f/4.0 FE 24-105mm F4 G OSS

由於書聖節，這裡還在舉辦全國書法篆刻的展覽。我進去簡單看了一下，名家所寫確實好看！我最喜歡的是下圖中間的這一張：

書法篆刻展覽24mm f/4.0 FE 24-105mm F4 G OSS

印山越國王陵

看完了蘭亭景區，我馬不停蹄地趕往旁邊不遠處地「印山越國王陵」。到了門口正好是下午4點整，停好車進去是4點2分的樣子，保安不讓進，說4點開始禁止進入，4點半停止營業。我執意要進，最後允許我進去了。這裡是一個考古發現，發現的時間距今也不過二三十年。這個景區名氣不太大，我是因為看地圖發現的。這個陵墓缺乏直接的證據證明墓主人的身份，但據推測極有可能是越王勾踐之父允常。這個王陵曾經在抖音上火過。

景區十分精簡，在國內這種景區其實是不多見的。停車場就是一片土地，真的就只有土。而景區的入口旁邊就是大片的農田。

印山越國王陵24mm f/4.0 FE 24-105mm F4 G OSS

在現場我看到了「木客大冢」四個大字，當時完全不明白是什麼意思，看到上面有一隻鳥的形狀，更是非常神秘。後來查維基百科才知道這個地方在當地最初被稱為「木客大冢」，因其所在地原為木客的聚居地而得名，是一座人工堆築的大型古代墓葬。而這個山「印山」以前也叫「木客山」。

「木客大冢」24mm f/4.0 FE 24-105mm F4 G OSS

隨著階梯進入王陵內部後，又有一個保安看到了我，不耐煩地說快要下班了，讓我不要進去。明明還有半個小時時間，王陵也很小，我就執意要進去。說真的，親眼見到王陵還是挺壯觀的，不虛此行。

王陵內部24mm f/4.0 FE 24-105mm F4 G OSS

有時候，不做規劃的旅行最容易出現驚喜。在印山越國王陵，我沒有見到一個遊人，且天色已晚，又是強行進入，保安一直催，我本來並不覺得能看到什麼東西。但我不但完整地看到了王陵內部，而且在往出口的時候偶然在地圖上發現徐渭的墓地也在這個園區之中，於是躲過保安從山上小路直奔徐渭之墓。我基本不瞭解徐渭，一邊走一邊在網上簡單瞭解了一下，知道他是明代中期的文學家和軍事家。

路上經過一個私人的魚塘，讓人一度懷疑自己是不是還在景區之中。名字也十分有意思，叫「塘狗弄山塘」。

塘狗弄山塘24mm f/4.0 FE 24-105mm F4 G OSS

整個景區道路都人跡罕至，但標牌還比較清楚，而且路上竟然遇到了兩三個剛從徐渭墓地出來的人。我加快了腳步，因為馬上就四點半了，我想我估計進不去了。路上我路過一個指路牌，感覺字寫得很有設計感，尤其是「渭」和「園」字格外好看，整體看也很莊重，於是拍了下來。

「徐渭墓園」路牌24mm f/4.0 FE 24-105mm F4 G OSS

快到的時候，路邊種滿了很小的松樹，雖然不大但依然給人蒼勁嚴肅之感，再加上四處寧靜無人，氣氛渲染的非常空靈。可惜的是，我還是沒能進去，只能從墓園的門口遙望。可以感知的是，墓園內樹木極多，花草繁茂。

去墓園的路上24mm f/4.0 FE 24-105mm F4 G OSS

徐渭墓園24mm f/4.0 FE 24-105mm F4 G OSS

八字橋周邊

看完徐渭墓，我開車直奔八字橋，此時天色開始漸漸下雨。因為擔心停車難，我把車停到了大概 1 公里外的一個停車場充電，然後步行前往八字橋周邊。在來這裡之前，我完全不清楚這裡是什麼。快到終點的時候，看到了一個天主教堂。再走幾步路，八字橋映入眼簾，我才發現這裡比我想象的要值得來看很多。幾個詞總結——純天然、很乾淨、大面積、江南煙雨。

天主教堂35mm f/1.4 FE 35mm F1.4 GM

八字橋之牌35mm f/1.4 FE 35mm F1.4 GM

具體來說，這是一大片保留非常好的傳統街區，有橋有水、建築優美，商業化程度剛剛好，且原住民非常多。隨便走走就能走到別人家裡。因為剛好下雨，從橋上遠眺，一片江南煙雨。

江南煙雨35mm f/1.4 FE 35mm F1.4 GM

八字橋周邊35mm f/2.0 FE 35mm F1.4 GM

八字橋與水上烏篷船35mm f/2.0 FE 35mm F1.4 GM

走在其中，商業氣息不是很濃，且移步換景。

從一個小巷中出來還有一個漂亮的寺廟。

沈園之夜

沈園即「沈氏園」，是紹興的一個園林。裡面流傳著陸游的一個感情故事。這個景區做了一個晚上看的劇目「沈園之夜」，我趁著夜色把它給看了。我本來一度認為今天看不成了，因為當時雨下的挺大，但到了演出快開始的時候，雨差不多停了。我也剛好在演出開始前兩三分鐘才趕到了沈園。

但我認為這個劇寫的不好，演的也一般。其實這個劇目確實也不好演，因為沈園之夜顯然主要是說沈園，但陸游的這個感情故事，應該只有幾個片段發生在沈園，大多數時候和沈園關係不大。在劇目中，硬生生被描繪成發生在沈園的故事，這在邏輯上有點怪。

沈園之夜35mm f/1.4 FE 35mm F1.4 GM

結合 TextRank 與 TF-IDF 更精準的提取文章關鍵詞

Tue, 30 Apr 2024 18:50:40 +0800

我們往往需要從大量的文字中迅速提取出核心關鍵詞，以便快速把握文章主旨。如果要做資訊流分發、基於內容的推薦演算法，這也是其中很重要的步驟，一般用於文章特徵。

傳統的 TF-IDF 方法雖然廣泛使用，但有時候它並不能完全準確地反映出文章的關鍵內容。實際上，TextRank、PositionRank 等任意演算法都很難保證不遺漏重要的關鍵詞。為了提高關鍵詞提取的準確性，我們可以採用結合多種演算法的方式來提取關鍵詞。我在產品中使用了 TextRank 演算法和 TF-IDF 的方法來結合，實測效果不錯。

不同的庫實現的關鍵詞提取，結果往往不同，因為其實現細節有優劣之分。這裡我使用的是 pke_zh 和 textrank4zh 庫，透過 Python 程式碼實現這一過程。

在介紹程式碼實現之前，我們先簡單回顧一下 TF-IDF 和 TextRank 的基本概念。

TF-IDF

TF-IDF（詞頻-逆文件頻率）是一種用於資訊檢索與文字挖掘的常用加權技術。它透過計算詞語的頻率（TF）和其在文件集中的分佈（IDF）來評估一個詞語對於一個檔案集或一個語料庫中的其中一份檔案的重要程度。TF-IDF 值越大，這個詞在文字中的重要性越高。

你可以在這篇文章檢視具體的計算方法和公式。

TextRank

TextRank 是一種基於圖的排序演算法，透過將文字分割成多個單詞，並將這些單詞作為圖中的節點，透過節點之間的相互影響，計算每個節點的重要性。在關鍵詞提取的場景中，TextRank 可以幫助我們找出文字中的高權重關鍵詞。

接下來，我們將詳細講解如何使用程式碼實現更精準的關鍵詞提取。

文字預處理：首先，我們將文字轉換為小寫，並使用正則表示式移除所有的數字，這是為了確保後續處理的文字是純粹的文字資料。
關鍵詞提取：我們使用 TfIdf_m.extract 方法和 tr4w.analyze 方法分別提取 TF-IDF 和 TextRank 的結果。
關鍵詞合併與向量生成：將兩種方法提取的關鍵詞合併，併為每個關鍵詞生成相應的 TF-IDF 和 TextRank 向量。
資料歸一化：為了使不同的指標具有可比性，我們使用 MinMaxScaler 對資料進行歸一化處理。
混合向量計算：將歸一化後的 TF-IDF 向量和 TextRank 向量按照一定的比例混合，從而得到一個綜合考慮兩者的混合向量。
關鍵詞排序：根據混合向量的值對關鍵詞進行排序，並選出排名前20的關鍵詞作為最終的關鍵詞。

完整程式碼如下：

from pke_zh import TextRank, TfIdf, PositionRank, Yake, KeyBert
import codecs
from timeit import default_timer as timer
from sklearn.preprocessing import MinMaxScaler
from textrank4zh import TextRank4Keyword
import numpy as np
import re

TfIdf_m = TfIdf()
tr4w = TextRank4Keyword()

def extract_keywords_mixed(text):
 # 轉換為小寫
 text = text.lower()
 # 使用正則移除所有純數字，包括整數和小數
 text = re.sub(r'\b\d+(\.\d+)?\b', '', text)

 # 獲取初始 tf-idf 和 textrank 資料
 tfidf = TfIdf_m.extract(text, n_best=30)
 tr4w.analyze(text=text, lower=True, window=2)

 textrank = []
 for item in tr4w.get_keywords(30, word_min_len=1):
 textrank.append((item.word, item.weight))

 # 合併關鍵詞清單
 allKeywords = []
 for word, weight in tfidf:
 allKeywords.append(word)
 for word, weight in textrank:
 if word not in allKeywords:
 allKeywords.append(word)

 # 根據合併的關鍵詞清單重新生成 tfidf 和 textrank 向量，對原始不存在的資料使用 0 填充
 tfidf_vector = []
 textrank_vector = []
 for word in allKeywords:
 tfidf_vector.append([weight for w, weight in tfidf if w == word][0] if word in [w for w, weight in tfidf] else 0)
 textrank_vector.append([weight for w, weight in textrank if w == word][0] if word in [w for w, weight in textrank] else 0)

 # 資料歸一化
 scaler = MinMaxScaler()
 tfidf_vector = np.array(tfidf_vector).reshape(-1, 1)
 tfidf_vector = scaler.fit_transform(tfidf_vector)
 textrank_vector = np.array(textrank_vector).reshape(-1, 1)
 textrank_vector = scaler.fit_transform(textrank_vector)

 # 混合向量
 mixed_vector = (tfidf_vector * 3 + textrank_vector * 2) / 5

 # 加入關鍵詞名稱
 mixed_keywords = []
 for i, word in enumerate(allKeywords):
 mixed_keywords.append((word, mixed_vector[i][0]))

 # 獲取前 top 個關鍵詞
 top = 20
 mixed_keywords = sorted(mixed_keywords, key=lambda x: x[1], reverse=True)
 mixed_keywords = mixed_keywords[:top]
 print(mixed_keywords)

 return mixed_keywords

透過結合 TF-IDF 和 TextRank 演算法，我們可以更全面地考慮詞語的重要性和文字結構，從而提高關鍵詞提取的準確性。以上程式碼實現了一個基於這兩種技術的混合關鍵詞提取方法，有助於我們在實際應用中抽取出更加精準的關鍵資訊。

紹興之旅（2）：會稽山兜率天、倉橋直街與魯迅故居

Mon, 29 Apr 2024 23:29:33 +0800

會稽山兜率天

會稽山是紹興名山，在中國歷史上也有重要地位，後面我們還會多次提到這座山。雖然如此，但我此次來到會稽山並沒有什麼準備。當時我在前一天晚上看過柯橋古鎮之後，就在地圖上尋找附近可去的地方，發現了「會稽山兜率天景區」的字樣，然後在網上簡單搜了幾句就決定第二天過去看看。我感覺，「會稽山」是一大片山脈，因為還有其他地方也屬於會稽山。

這個地方的第一印象並不好，因為我不喜歡被強迫要求坐景區大巴上山，但也沒有辦法。上山之後我發現這個景區有個特別之處——景區大巴直接把我拉到了靠近山頂的地方，而且下車後先進入了一個建築之內，裡面全是紀念品商店。一般景區的紀念品商店都在出口，它卻在入口。另外，走過紀念品商店後，需要坐好幾層的電梯，然後會到達一個十分寬闊恢弘的平臺，平臺盡頭就是景區的第一個主要景點——龍華寺。

龍華寺17mm f/8.0 E 17-28mm F2.8-2.8

龍華寺的牌坊十分大氣和恢弘，我使用騰龍 17-28mm 鏡頭超廣角拍攝下來效果十分震撼（上圖），驚訝到我了，在這之前我除了拍攝星空，很少使用這顆鏡頭的 17mm 端。

接下來是同樣震撼的大殿和其屋簷：

大雄寶殿28mm f/8.0 E 17-28mm F2.8-2.8

超廣角下的屋簷

龍華寺建築精美，但除此之外乏善可陳。走過龍華寺的幾個大殿之後，我遠遠看到了景區主打的標誌性景觀「兜率天宮」。

遠眺兜率天宮20mm f/9.0 E 17-28mm F2.8-2.8

「兜率天」是梵文 Tusita 的音譯，也譯成「兜率陀」。六慾天之一。此天有內、外兩院，內院是彌勒居住的淨土，普通訊眾若信仰彌勒，稱誦其名號，死後便可往生（即上生）此天。

這也是一個人工建築，完工於 2015 年。兜率天作為佛教極樂淨土的所在，之前只存在於宗教典籍之中。提出修建該建築的是潘建國先生（國學大師南懷瑾先生的弟子），用於教化與文化傳播，吸引大量遊客前往，利於佛教文化傳播。按照《彌勒上生經》中善財童子參彌勒的描述，他提取出兜率天宮的主要元素——寶宮形態像須彌山，山下有香水海、七重寶垣，蓮花也是兜率天宮必不可少的重要特徵。

在去往兜率天宮的路上，需要先下山，然後再爬山，最後到達刻有名字的石頭。

兜率天宮石刻20mm f/9.0 E 17-28mm F2.8-2.8

近觀兜率天宮，發現其中分很多層，建築外側是非常恢弘的階梯，在中間一層正在進行陶瓷藝術品展覽，標價不菲。

兜率天宮28mm f/9.0 E 17-28mm F2.8-2.8

兜率天宮內部17mm f/4.0 E 17-28mm F2.8-2.8

兜率天宮頂部18mm f/6.3 E 17-28mm F2.8-2.8

從兜率天宮下來，我想再去它的另一個景點「大香林」看看，但時間已經十分緊張。我沿著山路抄小道一路走過去，大概用了半個多小時，一路上全是筍，十分壯觀。到了大香林後發現這裡並沒有什麼太多東西，只有一些古樹。因為景區即將關門，我匆匆看了幾眼就直接走了。

大香林景區的繡球花50mm f/6.3 E 50-400mm F4.5-6.3 A067

離開會稽山兜率天后，在路上看到好幾個「黃酒小鎮」的牌子，網上查了一下似乎是一個值得去的地方，於是跟著標誌停車，停好車後才發現被騙了——這個「黃酒小鎮」實則為酒廠。裡面還煞有介事地搞了個黃酒博物館。搞笑的是，在地圖上，黃酒小鎮和黃酒博物館都存在，但位置是距離這裡十幾公里的越城區；而這裡所謂的的「黃酒小鎮」和「黃酒博物館」，地圖上完全沒有標誌。不過，這裡的風景還不錯，裡面有一整牆的李白將進酒的詩句，還做了一些愛喝酒的古人的塑像。

所謂「黃酒小鎮」35mm f/8.0 FE 35mm F1.4 GM

所謂「黃酒博物館」35mm f/8.0 FE 35mm F1.4 GM

愛酒之人塑像35mm f/4.0 FE 35mm F1.4 GM

魯迅故里附近

離開「黃酒小鎮」附近後，我一路直奔魯迅故里附近。這附近我已經來過幾次，但因為是紹興最經典的一片區域，我還是決定在附近轉轉，倒不是一定要進入核心景點，更多的是要在附近的步行街轉轉，感受一下。把車停好充電後，我來到了魯迅故里步行街的核心位置，這裡有一家王奶奶臭豆腐，我吃了感覺還挺不錯。

魯迅故里步行街牌坊35mm f/4.0 FE 35mm F1.4 GM

王奶奶臭豆腐35mm f/3.2 FE 35mm F1.4 GM

附近的餐飲店及烏篷船專用河35mm f/3.2 FE 35mm F1.4 GM

不禁感慨一下，魯迅養活了多少紹興人。直到現在，多少店鋪都是靠著它留下的「營養」而吸引客戶，例如「孔乙己茴香豆」等等，不一而足。

不知不覺天黑了，我突然發現魯迅故里晚上竟然也開門，就故地重遊了一下，其實我更主要的是想看魯迅紀念館，上次疫情期間它晚上不開門，錯過了。

在魯迅故居中，給我留下主要印象的是紹興的「祝福」儀式：

祝福35mm f/1.8 FE 35mm F1.4 GM

而在魯迅紀念館中，主要感慨於魯迅原配朱安和在一起生活的許廣平的故事，以及魯迅晚期病中的狀態。當然，魯迅為治中國人心病的一路歷程每看一次都令人動容。

俯首甘為孺子牛35mm f/1.8 FE 35mm F1.4 GM

非常幸運，魯迅刻「早」字的課桌原件展出在紀念館中，而這件文物在過去數十年間一直沒有對外展出，都是複製件。你能在課桌上找到「早」字在哪裡嗎？我當時硬是沒有找到，後來在網上查資料後重新找，才找到了它的位置。你可以放大下面圖片仔細找找。

魯迅在三味書屋的課桌35mm f/1.8 FE 35mm F1.4 GM

倉橋直街

離開魯迅故里附近，我直奔不遠處的倉橋直街。

倉橋直街路牌35mm f/1.6 FE 35mm F1.4 GM

如前所述，我這次旅行沒有做過多攻略，因此對倉橋直街也沒什麼太大概念。但到了之後我發現，這個街的小巷子很長，且老房子還是挺多的，走走及拍拍照，很不錯。當然，老房子裡經營的肯定都是中國古街清一色的內容——特色小吃。

古街小巷35mm f/1.4 FE 35mm F1.4 GM

古街對聯35mm f/1.4 FE 35mm F1.4 GM

可以看出紹興政府為了提振旅遊做了不少努力。比如在倉橋直街的十字路口，發現其交叉的街道掛滿了燈籠，估計是想營造打卡點，但其實在這裡拍照有點危險，車不少：

樹上燈籠35mm f/1.4 FE 35mm F1.4 GM

徹底離開倉橋直街，回去取我車的路上，突然無意間看到了秋瑾的紀念塑像。在夜光下這樣的場景具有獨特的視覺效果，配合孫中山的題詞「巾幗英雄」，顯得格外聖潔和印象深刻，大量敬贈的鮮花擺放在路邊，這種不期而遇的震撼讓我有點懵。

秋瑾紀念塑像及鮮花35mm f/2.8 FE 35mm F1.4 GM

國內 AI 應用創業為何舉步維艱？國內 AI 創業者的出路何在？

Thu, 25 Apr 2024 19:05:40 +0800

不知道大家有沒有發現，在當前 AI 技術蓬勃發展的浪潮中，海外湧現出眾多獨立開發者憑藉創新應用斬獲成功，而反觀國內，AI 創業之路卻步履蹣跚。

即使拋開AI，這個現象其實已經持續了幾年了，而且愈演愈烈。做網際網路產品，國內網際網路的這一現象背後，凸顯出國內網際網路生態中流量分配的失衡，以及平臺政策對獨立開發者的壁壘。

首先，國內網際網路流量高度集中於移動端的頭部應用。據統計，微信和抖音兩大平臺佔據了絕大部分的使用者使用時長。這意味著，對於初創團隊而言，要在短時間內獲取可觀的使用者規模，只能依附於既有平臺，而平臺往往對第三方應用抱有排他性。微信對小程式訪問連結的限制，以及抖音對外鏈跳轉的封禁，無不凸顯出平臺對流量的壟斷和控制。

因此，創業者們無法引導使用者走出平臺，獨立 App 的生存空間被極度壓縮。

其次，頭部平臺基於自身的商業邏輯，更青睞變現效率高、有助於延長使用者時長的內容形態。這導致短影片和直播成為平臺重點扶持的方向，而創新型應用則難覓機會。不少創業者被迫轉型，從事內容生產，在擅長的技術之外耗費大量精力。平臺主導的商業生態，並未給創新軟體應用預留髮展的空間。

相比之下，海外市場則呈現出不同的圖景。得益於開放而中立的社交網路，使用者可以自由地在平臺間跳轉。加之海量的 Web 端流量，使得初創團隊能夠透過搜尋引擎最佳化等手段，持續獲得忠實使用者。再者，推特、臉書等社交媒體允許外鏈的存在，使用者可以在平臺內發現新鮮應用，繼而走出圍牆花園，與開發者直接互動。這些因素共同構築起良性迴圈，催生出更多新穎獨特的 AI 應用，引領創新浪潮。

那麼，國內 AI 創業者的出路何在？

挺難的。

從長遠來看，只有打破頭部平臺對流量的壟斷格局，創新的土壤才能培育而生。倘若 App 端主導地位動搖， Web 端的復興將為創業者帶來新的想象空間。

綜上所述，國內 AI 創業之困，根源在於頭部平臺對流量的壟斷割裂。

短期內，出海或許是最理想的選擇，藉助海外開放而活躍的網際網路生態，讓創意落地生根。

而從國內市場來看，要麼順應平臺“遊戲規則”發力內容領域，要麼立足細分賽道開拓創新路徑。無論何種選擇，創業者們都需要保持敏銳洞察，隨時調整策略。在 AI 革命的浪潮中，唯有直面挑戰、把握機遇，才能成就非凡。

為了造車，拋妻棄子？還有多少老婆孩子要被犧牲？

Tue, 23 Apr 2024 19:18:04 +0800

希望以後我們國產汽車的發佈會，不要一個個像內捲到內傷的孩子在訴苦。

1

我無意間看到了智己L6發佈會上聯席CEO劉濤的這麼一段話：

我們的同學甚至連自己小孩子的出生都會錯過

我們有同學一狠心

把自己年幼的孩子送去了寄宿制學校……

我們國人什麼時候才能不被這種話語所感動？

令人欣慰的是，這話一出，網上並非一片感動，而是炸了鍋。有人調侃道：「少買一輛智己，就少一個寄宿的孩子。」

有的甚至給L6貼上了「拋妻棄子車」的標籤。

這位高管的苦衷，或許只有他自己心裡清楚。但是，這不禁讓人思考：在汽車行業裡，這樣的家庭犧牲是不是成了常態？

其實，智己並非個例。有些車企不僅將週六定為正常工作日，還讓員工「悄悄」規避法律風險。這種情況在業內已經不是秘密。

犧牲了個人和家庭生活，真的能造出好車，銷量就能飆升嗎？

2

汽車行業的高速發展，似乎讓一些企業忘了，造車不僅僅是生產線上的機械運轉，更是人的智慧和生活體驗的結晶。

在汽車行業的無情競賽中，有一課似乎被遺忘了：亨利·福特的智慧。

1914年，福特汽車公司推出T型車後，福特宣佈了一個震驚世界的決策：工人的日薪將達到5美元。這一創舉不僅僅是對社會公平的貢獻，更是一條精明的商業法則。福特深知，只有當工資高且穩定時，工人才能成為消費者，市場才會穩定增長，他們才買得起T型車。

福特的這一理念開啟了一個良性迴圈：待遇優厚的工人帶來了消費需求，進而促進了業務擴張和就業增加。他是最早明確提出這個概念的商業領袖之一。

福特的智慧並非孤例，其他高管和強大的工會組織也採納了這一理念，通用汽車和全美汽車工人聯合會簽訂的《底特律條約》便是最好的證明。這種「利益共享資本主義」的理念，曾帶領美國經歷了二戰後的經濟黃金時期，創造了前所未有的中產階級繁榮景象。那時的商界領袖們深信，企業的成功與工人福利成正比。

像標準石油公司的弗蘭克·W·艾布拉姆和通用電氣的厄爾·S·威利斯等人，都提倡平衡各方利益，認為員工的經濟安全是企業最寶貴的資產。

然而，自20世紀70年代晚期以來，這一理念似乎逐漸被邊緣化。生產力雖然大幅提升，但工人的實際工資和福利卻幾乎停滯不前。公司利潤飆升，而中產階級的收入卻停滯，我們正在為這種轉變付出代價。福特曾預言，如果普通民眾沒有穩定的收入增長，經濟將會停滯不前。

現在，我們似乎正遭受著這一預言的驗證。就像福特說的那樣，如果普通民眾沒有收入穩步增長的穩定工作，經濟就會停滯不前。自20世紀90年代初以來，世界已經多次陷入「失業型復甦」的泥沼。

我們不能忘記，在造車的過程中，不僅需要技術和創新，還需要人的智慧和生活體驗。沒有時間去享受生活的人，如何能夠理解使用者的需求，造出能觸動人心的產品？

汽車行業的領袖們應該回顧歷史，重新領悟福特的智慧：只有當中產階級能從國家經濟收入中分到更多的份額，經濟才能更快增長，我們的產品也才能更加卓越。

畢竟，只有幸福的員工，才能造出讓人幸福的車。

正確實現根據使用者偏好自動切換網頁中文簡繁版本

Tue, 23 Apr 2024 03:50:36 +0000

很多人都沒有正確地實現中文簡繁體語言的自動切換，其實現有瑕疵，造成使用者體驗和 SEO 的問題。這篇文章直接給你一個終極答案，照抄就可以了。

在給出具體的程式碼之前，先普及幾個知識點：

根據規範，中文的語言編碼有兩種形式，一種是根據簡繁來標識，如 zh-hans 代表簡體中文，zh-hant 代表繁體中文；另一種是根據地區來標識，如 zh-cn 代表中國大陸地區的中文，zh-tw 代表臺灣地區的中文。我們的程式碼要相容兩種形式。
大多數中文網站沒必要針對臺灣、香港、新加坡等不同地域實現不同的語言切換，例如臺灣和香港我們一般共用繁體中文。因此，網站的繁體中文語言 url 字首應該使用 zh-hant 而不是 zh-TW 或 zh-HK。
為了 SEO，我們需要注意兩件事：
- 應該在網站的 <html> 標籤上新增 lang 屬性，以便搜尋引擎正確識別網站的語言；
- 對於搜尋引擎的爬蟲（蜘蛛），不要自動跳轉到其他語言版本，否則可能會導致其無法索引到各種語言的版本；
一些使用者不知道如何在瀏覽器或作業系統中設定自己偏好的語言，因此使用者會在網頁上手工切換到自己偏好的語言。我們需要記住使用者選擇的語言，避免重複跳轉到作業系統或瀏覽器設定的語言。

下面是我們的終極程式碼。

在你網頁的 JavaScript 指令碼中，新增如下程式碼：

const beforeSwitchLanguage = (lang) => {
 localStorage.setItem("preferred_lang", lang);
 return true;
}

window.beforeSwitchLanguage = beforeSwitchLanguage;

const autoSwitchLanguage = () => {
 // 是否為搜尋引擎蜘蛛
 let isBot = /(Googlebot\/|Googlebot-Mobile|Googlebot-Image|Googlebot-News|Googlebot-Video|AdsBot-Google([^-]|$)|AdsBot-Google-Mobile|Feedfetcher-Google|Mediapartners-Google|Mediapartners \(Googlebot\)|APIs-Google|Google-InspectionTool|Storebot-Google|GoogleOther|bingbot|Slurp|[wW]get|LinkedInBot|Python-urllib|python-requests|aiohttp|httpx|libwww-perl|httpunit|Nutch|Go-http-client|phpcrawl|msnbot|jyxobot|FAST-WebCrawler|FAST Enterprise Crawler|BIGLOTRON|Teoma|convera|seekbot|Gigabot|Gigablast|exabot|ia_archiver|GingerCrawler|webmon |HTTrack|grub\.org|UsineNouvelleCrawler|antibot|netresearchserver|speedy|fluffy|findlink|msrbot|panscient|yacybot|AISearchBot|ips-agent|tagoobot|MJ12bot|woriobot|yanga|buzzbot|mlbot|yandex\.com\/bots|purebot|Linguee Bot|CyberPatrol|voilabot|Baiduspider|citeseerxbot|spbot|twengabot|postrank|Turnitin|scribdbot|page2rss|sitebot|linkdex|Adidxbot|ezooms|dotbot|Mail\.RU_Bot|discobot|heritrix|findthatfile|europarchive\.org|NerdByNature\.Bot|sistrix crawler|Ahrefs(Bot|SiteAudit)|fuelbot|CrunchBot|IndeedBot|mappydata|woobot|ZoominfoBot|PrivacyAwareBot|Multiviewbot|SWIMGBot|Grobbot|eright|Apercite|semanticbot|Aboundex|domaincrawler|wbsearchbot|summify|CCBot|edisterbot|SeznamBot|ec2linkfinder|gslfbot|aiHitBot|intelium_bot|facebookexternalhit|Yeti|RetrevoPageAnalyzer|lb-spider|Sogou|lssbot|careerbot|wotbox|wocbot|ichiro|DuckDuckBot|lssrocketcrawler|drupact|webcompanycrawler|acoonbot|openindexspider|gnam gnam spider|web-archive-net\.com\.bot|backlinkcrawler|coccoc|integromedb|content crawler spider|toplistbot|it2media-domain-crawler|ip-web-crawler\.com|siteexplorer\.info|elisabot|proximic|changedetection|arabot|WeSEE:Search|niki-bot|CrystalSemanticsBot|rogerbot|360Spider|psbot|InterfaxScanBot|CC Metadata Scaper|g00g1e\.net|GrapeshotCrawler|urlappendbot|brainobot|fr-crawler|binlar|SimpleCrawler|Twitterbot|cXensebot|smtbot|bnf\.fr_bot|A6-Indexer|ADmantX|Facebot|OrangeBot\/|memorybot|AdvBot|MegaIndex|SemanticScholarBot|ltx71|nerdybot|xovibot|BUbiNG|Qwantify|archive\.org_bot|Applebot|TweetmemeBot|crawler4j|findxbot|S[eE][mM]rushBot|yoozBot|lipperhey|Y!J|Domain Re-Animator Bot|AddThis|Screaming Frog SEO Spider|MetaURI|Scrapy|Livelap[bB]ot|OpenHoseBot|CapsuleChecker|collection@infegy\.com|IstellaBot|DeuSu\/|betaBot|Cliqzbot\/|MojeekBot\/|netEstate NE Crawler|SafeSearch microdata crawler|Gluten Free Crawler\/|Sonic|Sysomos|Trove|deadlinkchecker|Slack-ImgProxy|Embedly|RankActiveLinkBot|iskanie|SafeDNSBot|SkypeUriPreview|Veoozbot|Slackbot|redditbot|datagnionbot|Google-Adwords-Instant|adbeat_bot|WhatsApp|contxbot|pinterest\.com\/bot|electricmonk|GarlikCrawler|BingPreview\/|vebidoobot|FemtosearchBot|Yahoo Link Preview|MetaJobBot|DomainStatsBot|mindUpBot|Daum\/|Jugendschutzprogramm-Crawler|Xenu Link Sleuth|Pcore-HTTP|moatbot|KosmioBot|[pP]ingdom|AppInsights|PhantomJS|Gowikibot|PiplBot|Discordbot|TelegramBot|Jetslide|newsharecounts|James BOT|Bark[rR]owler|TinEye|SocialRankIOBot|trendictionbot|Ocarinabot|epicbot|Primalbot|DuckDuckGo-Favicons-Bot|GnowitNewsbot|Leikibot|LinkArchiver|YaK\/|PaperLiBot|Digg Deeper|dcrawl|Snacktory|AndersPinkBot|Fyrebot|EveryoneSocialBot|Mediatoolkitbot|Luminator-robots|ExtLinksBot|SurveyBot|NING\/|okhttp|Nuzzel|omgili|PocketParser|YisouSpider|um-LN|ToutiaoSpider|MuckRack|Jamie's Spider|AHC\/|NetcraftSurveyAgent|Laserlikebot|^Apache-HttpClient|AppEngine-Google|Jetty|Upflow|Thinklab|Traackr\.com|Twurly|Mastodon|http_get|DnyzBot|botify|007ac9 Crawler|BehloolBot|BrandVerity|check_http|BDCbot|ZumBot|EZID|ICC-Crawler|ArchiveBot|^LCC |filterdb\.iss\.net\/crawler|BLP_bbot|BomboraBot|Buck\/|Companybook-Crawler|Genieo|magpie-crawler|MeltwaterNews|Moreover|newspaper\/|ScoutJet|(^| )sentry\/|StorygizeBot|UptimeRobot|OutclicksBot|seoscanners|Hatena|Google Web Preview|MauiBot|AlphaBot|SBL-BOT|IAS crawler|adscanner|Netvibes|acapbot|Baidu-YunGuanCe|bitlybot|blogmuraBot|Bot\.AraTurka\.com|bot-pge\.chlooe\.com|BoxcarBot|BTWebClient|ContextAd Bot|Digincore bot|Disqus|Feedly|Fetch\/|Fever|Flamingo_SearchEngine|FlipboardProxy|g2reader-bot|G2 Web Services|imrbot|K7MLWCBot|Kemvibot|Landau-Media-Spider|linkapediabot|vkShare|Siteimprove\.com|BLEXBot\/|DareBoost|ZuperlistBot\/|Miniflux\/|Feedspot|Diffbot\/|SEOkicks|tracemyfile|Nimbostratus-Bot|zgrab|PR-CY\.RU|AdsTxtCrawler|Datafeedwatch|Zabbix|TangibleeBot|google-xrawler|axios|Amazon CloudFront|Pulsepoint|CloudFlare-AlwaysOnline|Google-Structured-Data-Testing-Tool|WordupInfoSearch|WebDataStats|HttpUrlConnection|Seekport Crawler|ZoomBot|VelenPublicWebCrawler|MoodleBot|jpg-newsbot|outbrain|W3C_Validator|Validator\.nu|W3C-checklink|W3C-mobileOK|W3C_I18n-Checker|FeedValidator|W3C_CSS_Validator|W3C_Unicorn|Google-PhysicalWeb|Blackboard|ICBot\/|BazQux|Twingly|Rivva|Experibot|awesomecrawler|Dataprovider\.com|GroupHigh\/|theoldreader\.com|AnyEvent|Uptimebot\.org|Nmap Scripting Engine|2ip\.ru|Clickagy|Caliperbot|MBCrawler|online-webceo-bot|B2B Bot|AddSearchBot|Google Favicon|HubSpot|Chrome-Lighthouse|HeadlessChrome|CheckMarkNetwork\/|www\.uptime\.com|Streamline3Bot\/|serpstatbot\/|MixnodeCache\/|^curl|SimpleScraper|RSSingBot|Jooblebot|fedoraplanet|Friendica|NextCloud|Tiny Tiny RSS|RegionStuttgartBot|Bytespider|Datanyze|Google-Site-Verification|TrendsmapResolver|tweetedtimes|NTENTbot|Gwene|SimplePie|SearchAtlas|Superfeedr|feedbot|UT-Dorkbot|Amazonbot|SerendeputyBot|Eyeotabot|officestorebot|Neticle Crawler|SurdotlyBot|LinkisBot|AwarioSmartBot|AwarioRssBot|RyteBot|FreeWebMonitoring SiteChecker|AspiegelBot|NAVER Blog Rssbot|zenback bot|SentiBot|Domains Project\/|Pandalytics|VKRobot|bidswitchbot|tigerbot|NIXStatsbot|Atom Feed Robot|[Cc]urebot|PagePeeker\/|Vigil\/|rssbot\/|startmebot\/|JobboerseBot|seewithkids|NINJA bot|Cutbot|BublupBot|BrandONbot|RidderBot|Taboolabot|Dubbotbot|FindITAnswersbot|infoobot|Refindbot|BlogTraffic\/\d\.\d+ Feed-Fetcher|SeobilityBot|Cincraw|Dragonbot|VoluumDSP-content-bot|FreshRSS|BitBot|^PHP-Curl-Class|Google-Certificates-Bridge|centurybot|Viber|e\.ventures Investment Crawler|evc-batch|PetalBot|virustotal|(^| )PTST\/|minicrawler|Cookiebot|trovitBot|seostar\.co|IonCrawl|Uptime-Kuma|SeekportBot|FreshpingBot|Feedbin|CriteoBot|Snap URL Preview Service|Better Uptime Bot|RuxitSynthetic|Google-Read-Aloud|Valve\/Steam|OdklBot\/|GPTBot|ChatGPT-User|YandexRenderResourcesBot\/|LightspeedSystemsCrawler|ev-crawler\/|BitSightBot\/|woorankreview\/|Google-Safety|AwarioBot|DataForSeoBot|Linespider|WellKnownBot|A Patent Crawler|StractBot|search\.marginalia\.nu|YouBot|Nicecrawler|Neevabot|BrightEdge Crawler|SiteCheckerBotCrawler|TombaPublicWebCrawler|CrawlyProjectCrawler|KomodiaBot|KStandBot|CISPA Webcrawler|MTRobot|hyscore\.io|AlexandriaOrgBot|2ip bot|Yellowbrandprotectionbot|SEOlizer|vuhuvBot|INETDEX-BOT|Synapse|t3versionsBot|deepnoc|Cocolyzebot|hypestat|ReverseEngineeringBot|sempi\.tech|Iframely|MetaInspector|node-fetch|lkxscan|python-opengraph|OpenGraphCheck|developers\.google\.com\/\+\/web\/snippet|SenutoBot|MaCoCu|NewsBlur|inoreader|NetSystemsResearch|PageThing|WordPress\/|PhxBot|ImagesiftBot|Expanse|InternetMeasurement|^BW\/|GeedoBot|Audisto Crawler|PerplexityBot\/|[cC]laude[bB]ot)/g.test(navigator.userAgent);

 if (isBot) {
 return;
 }

 // 如果使用者手工切換過語言，則記住
 let preferredLang = localStorage.getItem("preferred_lang");

 if (!preferredLang) {
 // 查詢瀏覽器第一偏好的 'zh' 類語言
 let lang = navigator.languages.find((l) => l.startsWith("zh"));
 if (lang) {
 let isPreferSC = lang == "zh-CN" || lang == "zh-SG" || lang == "zh-hans";
 preferredLang = isPreferSC ? "zh-hans" : "zh-hant";
 }
 }

 if (preferredLang) {
 // 注意：此處需要根據你自己網站的情況進行改寫，以獲取到正確的跳轉 url。
 // 查詢 id 為 link-lang-[preferredLang] 的 a 標籤指向的連結
 let link = document.getElementById("link-lang-" + preferredLang);

 // 如果找到，自動跳轉
 if (link) {
 window.location.href = link.href;
 }
 }
}

這裡的主要邏輯如下：

我們在 beforeSwitchLanguage 函式中使用 localStorage 來儲存使用者偏好的語言。
在 autoSwitchLanguage 函式中，我們首先判斷使用者是否是搜尋引擎蜘蛛，如果是，則不進行自動切換。
然後我們查詢使用者瀏覽器的第一偏好的中文語言，如果找到，則自動切換到簡體或繁體中文。
如果使用者手工切換過語言，則記住使用者的選擇，下次訪問時自動切換到使用者偏好的語言。

要注意的是，自動跳轉到相應語言的部分，需要你根據自己網站的情況判斷正確的跳轉 url。

我自己網站實現中，網頁會有一個指向另一種中文的連結，因此我這裡使用的是查詢連結對應的 url 的方法來實現。這種實現比較適合於 Hugo 等靜態網站，一般主題中會自帶語言切換連結，因此在 JavaScript 指令碼中不需要再手工生成連結，而是引用網頁上的連結，這樣也增加了可維護性。

最後還要做一件事，在使用者手工切換語言的連結上呼叫 beforeSwitchLanguage 方法並傳入要跳轉的語言編碼，這樣我們就記住了使用者的偏好。例如，如果你透過 a 標籤進行跳轉，可以這麼寫：

<a onclick="beforeSwitchLanguage('zh-hant')" id="link-lang-zh-hant" class="menu-link" href="xxxxxx">繁體中文</a>

也就是新增一個 onclick 事件。

紹興之旅（1）：羊山石境與柯橋古鎮

Sat, 20 Apr 2024 01:25:01 +0800

2024年4月，我決定趁著春光來一段浙東的旅行，從杭州出發，穿過紹興，沿著浙東唐詩之路前往嵊州、新昌、天台方向。

為了方便看沿路的風景，同時也為了節約成本，我決定透過自駕的方式旅行，晚上儘量睡在車上，一路上不走高速，儘量用電而不是油。整個旅行持續了一週左右的時間，中間公司有事就回杭州，沒事就睡車裡以便第二天繼續旅行。

我這次旅行的目的有兩個，一是多看看浙江的人文景色；二是遊山玩水，鍛鍊身體。在路線選擇上，我曾經在一個偶然的機會去新昌開過會，另外還去過一次十九峰，感覺那邊的景色十分不錯。

這次旅行整體比較匆忙，沒有怎麼做攻略，但實際效果比我預期的要好不少。另外，這次旅行過程中頻繁下雨，也算是煙雨江南了。

羊山石境

我是在知乎一篇討論浙東唐詩之路的文章上看到羊山石境的。但在去之前，我並不太瞭解羊山石境的實際情況。到達現場的時候正在下雨，下車之後映入眼簾的卻是杭州亞運會的攀巖運動館（紹興柯橋羊山攀巖中心），仔細看的話會發現這個運動館旁邊還有一個山頭。

紹興柯橋羊山攀巖中心（亞運會攀巖場地）

而真正的羊山石鏡在停車場邊上一個很小的小路盡頭。在景區入口，我瞭解了今日羊山的來歷：

紹興古代屬於越國。史載，隋開皇九年，豪強高智慧在越州自稱天子，皇帝命晉王楊廣、水師總督楊素興兵討伐。為防後患，楊素採羊山石築羅城。

羊山本來是一個完整的大山，但在千百年的採石過程後，只剩下斷崖殘壁，但反而形成了自己獨有的特色：佛在石中，石在水中，水在山中。

蕭山與紹興這一帶的平原，屬於錢塘江沖積平原。水多山少，山少，石頭就少。然而築城，錢塘江攔壩，處處要用石頭，而且是大石頭。

楊素在杭州築城，在紹興擴城，需要石頭，就到羊山開採。錢鏐呢，創業當年，攻克山陰郡，首先攻佔的就是羊山，並在此駐紮。還有林則徐，當年在錢塘江加固江堤時，需要大量石頭，採自羊山。所以，羊山活在很多大人物的奏摺中。

羊山石境介紹

進入羊山石鏡後，看到的是一大片水，是一個面積不太大的湖，中間修有遊步道。沿著湖走，綠樹成蔭，水波盪漾，但沒有看到其他東西。

因為在門口我已經知道了「佛在石中」的景觀，所以我一直沿著路走，一直走到了湖的盡頭。這裡果然別有洞天，有一個小寺廟「石佛禪寺」。此時雨越下越大。

石佛禪寺內部

這個寺在外面看著其貌不揚，進入之後也只看到了一個普通寺廟的樣子。但是在它的一個殿的左側，有一個很小的門，裡面黑黑的，沒有什麼特別的標識。

從這裡走進去，發現了羊山石鏡真正的核心景點——這裡有一個階梯，可以通往羊山被開採後留下的孤巖。在階梯上，我看到了文人墨客的崖刻。

石佛禪寺崖刻墨寶

從題字來看，大多數石刻可能來自於清代和民國時期。回家後搜尋得知，其中的「飛躍」二字傳為南宋名將韓世忠書。

繼續往前走可到一個修建於孤石中的佛殿，當時我以為已經走到頭了，但是仔細一看，在殿裡的右側有一入口，沿著這個口往外走，就到了石佛峰石窟造像，為江南四大石佛之一。我沒有拍照，但這個石佛是真的很壯觀，尤其是他的手，非常的令人震撼！

從寺中出來回到羊山湖，發現在寺外湖邊還有一個佛像，好像是觀音像？

寺外佛像

柯橋古鎮

柯橋古鎮並非我此次規劃中的路線，但好在距離羊山很近，地圖上一搜我就過去了。到了之後發現這個地方景色還挺不錯，雖然很商業化、且大多數為現代重修的仿古建築，但整體規劃設計在國內古鎮中我認為是上乘的。由於正在下雨，頗有江南煙雨的感覺。

下面這張圖拍攝於藍調時分雨中的柯橋古鎮，是我這次旅行中拍攝的最滿意的照片之一：

藍調時分雨中的柯橋古鎮

在古鎮中走了一會兒，穿過一個小橋後，遠遠看到了一個仿古橋，在煙雨中很是漂亮，算是這次的一個小驚喜。

柯橋古鎮

在古鎮中雨越來越大，我走的時間不太長就出來了。我發現附近全是新疆餐廳，於是我就隨便找了一家新疆菜來吃，畢竟新疆面是真的好吃。意外的是，對方還送了個小菜。

新疆菜館的小菜

新疆面

Grub Filter Not Found 修復：系統升級後的引導修復

Wed, 03 Apr 2024 17:11:07 +0800

症狀

如果你在伺服器啟動時遇到了提示 Grub Filter Not Found 並自動進入 Grub Rescue（救援模式）的問題，本文給出了完整的解決方案。

昨天晚上我對時隔三五年沒有更新過的伺服器進行了升級，把 Debian 10 經過兩次更新升級到了 Debian 12。隨著系統更新，PHP 也從 7.4 升級到了 8.2； Nginx 從 1.15 升級到了 1.22.1。

升級之後，系統執行一切正常，所有網站也都能正常訪問。為了保證長期執行的穩定性（我的伺服器常年不重啟），我打算在伺服器升級後順道重啟一次。結果這下可好，重啟後直接無法使用了。

首先是 SSH 無法連線，然後透過雲伺服器的 Web 終端登入後，發現螢幕顯示內容如下：

error: symbol 'grub_file_filters' not found.
Entering rescue mode...
grub rescue>

原因分析

迅速分析和查閱了相關的資料，發現這個問題應該是在系統更新過程中破壞了引導的 grub 配置造成的。網上大部分的資料都需要掛載系統恢復光碟映象來執行 grub-install，來完成引導的修復。但對於雲伺服器，這是不可行的，因為你無法插入修復光碟映象。

如果你和我一樣無法掛載系統恢復光碟映象，我提供兩個解決思路。

方法一：雲盤掛載在救援主機

阿里雲、AWS 等伺服器支援掛載雲盤到其他主機。而有些雲伺服器，例如青雲，提供了救援主機功能。你可以利用這些功能把受損的系統盤掛載在一個可以正常啟動的伺服器上，然後在這個伺服器上修復你的引導。

具體步驟如下：

# 切換到 root 許可權
sudo su

# 查詢被掛載的損壞的系統盤的盼復
fdisk -l

# 把損壞的系統盤的一些內容掛載到可以正常啟動的伺服器
# 這裡假設你在 fdisk 中查詢到的系統碟符為 sdc，
# 且系統掛載在其中的 sdc1：
mount /dev/sdc1 /mnt
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

chroot /mnt

# 執行引導修復
grub-install /dev/sda

假如一切順利，系統會提示：

Installation finished. No error reported.

此時別忘了取消掛載：

# 退出 chroot
exit

# 取消掛載
umount /mnt/dev/pts
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt

然後把雲盤重新掛載回損壞的主機，重啟該主機，應該可以進入系統。

方法二：手工引導系統

如果你和我一樣倒黴，在執行 grub-install 時不成功，或者你沒法掛載系統盤到其他可用的主機，還有一個辦法，那就是手工透過 grub 引導進入系統，然後在系統內修復 grub 安裝。

首先執行你的主機，在出現下面的提示時:

error: symbol 'grub_file_filters' not found.
Entering rescue mode...
grub rescue>

又或者你進入的是 grub 命令列，而不是 grub rescue，也是可以的：

grub>

小心地按照下列步驟執行命令。

首先執行一個可以讓長輸出進行分頁的指令：

grub> set pager=1

不要有多餘的空格。

然後列出自己的磁碟：

grub> ls
(hd0) (hd0,msdos2) (hd0,msdos1)

怎麼出來了一個 msdos？這說明你的磁碟使用的是以前的 MS-DOS 分割槽模式，而不是 GPT 模式。這不重要。

我們的重點是找到你的啟動盤。比如我們嘗試 (hd0,1) 這個盤：

grub> ls (hd0,1)/
lost+found/ bin/ boot/ cdrom/ dev/ etc/ home/ lib/
lib64/ media/ mnt/ opt/ proc/ root/ run/ sbin/
srv/ sys/ tmp/ usr/ var/ vmlinuz vmlinuz.old
initrd.img initrd.img.old

透過 ls 指令，你可以確認這個盤的內容以分析它是不是我們的啟動盤。你也可以透過 cat 指令進一步確認系統的版本號：

grub> cat (hd0,1)/etc/issue
Ubuntu 14.04 LTS n l

假如你有多個系統或者多個碟符，一定不要搞錯。

接下來手工引導系統（先別急著複製執行，看解釋）：

# 看完解釋後再執行哦
grub> set root=(hd0,1)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot

注意：

這裡的 (hd0,1) 是你要修復引導的實際磁碟，要反覆核實清楚；
這裡的 /boot/vmlinuz-3.13.0-29-generic 只是一個例項，你執行的時候，打出 /root/vmlinuz，然後按 Tab 鍵選出你實際的 linux 核心版本號，不要照抄。如果有多個核心版本，一般選最新的。
這裡 /boot/initrd.img-3.13.0-29-generic 同上。

現在你應該可以進入系統了。

注意，這時候別急著高興，趕緊修復 grub 引導，不然下次重啟還是無法正常進入：

# 更新 grub
> update-grub
# 系統可能輸出類似內容：
# Generating grub configuration file ...
# Found background: /usr/share/images/grub/Apollo_17_The_Last_Moon_Shot_Edit1.tga
# Found background image: /usr/share/images/grub/Apollo_17_The_Last_Moon_Shot_Edit1.tga
# Found linux image: /boot/vmlinuz-3.13.0-29-generic
# Found initrd image: /boot/initrd.img-3.13.0-29-generic
# Found linux image: /boot/vmlinuz-3.13.0-27-generic
# Found initrd image: /boot/initrd.img-3.13.0-27-generic
# Found linux image: /boot/vmlinuz-3.13.0-24-generic
# Found initrd image: /boot/initrd.img-3.13.0-24-generic
# Found memtest86+ image: /boot/memtest86+.elf
# Found memtest86+ image: /boot/memtest86+.bin
# done

# 重新安裝 grub
> grub-install /dev/sda
# 可能的輸出：
# Installing for i386-pc platform.
# Installation finished. No error reported.

這時候你的系統應該完全恢復了。

參考資料： Classic SysAdmin: How to Rescue a Non-booting GRUB 2 on Linux

自動更新阿里雲的 CDN HTTPS 證書

Mon, 01 Apr 2024 12:30:07 +0000

開源地址

Github

使用說明

這是一個可以自動更新你的阿里雲 CDN 證書的命令行工具。基於 Golang 開發。無需安裝繁重的 Python。可以結合 acme.sh、let's encrypt 等工具，免費使用證書。

通過這個方法，你不需要每隔幾個月就去手工更新你的 CDN 證書了。

Clone 這個項目。
在項目所在文件夾中安裝依賴：

go mod init ceeji.net/aliyun-cdn-cert-bot
go get "github.com/denverdino/aliyungo/cdn"

編譯 main.go 即可使用：

go build main.go

運行之前請設置下列環境變量：

ACCESS_KEY_ID、ACCESS_KEY_SECRET 為阿里雲有權限的 RAM 子賬號信息；
ALI_DOMAIN 為阿里雲 CDN 域名（非源站域名）；
ALI_CERT_PATH 為 CDN 證書文件名（注意要用 fullchain 的證書，否則可能有些客戶端會報錯）；
ALI_KEY_PATH 為 CDN 證書密鑰文件名。

建議結合 crontab 設置定時任務，每天執行一次。

對於 acme.sh 用戶，你可以直接設置相關路徑到 ~/.acme.sh/證書名稱/文件這樣的路徑。

本站從 Wordpress 遷移到 Hugo

Mon, 01 Apr 2024 16:38:34 +0800

時隔多年，本站終於進行了一次較大的更新，從 Wordpress 遷移到了 Hugo。這篇文章記錄了遷移的原因和過程。

緣由

想從 Wordpress 遷移到 Hugo 已經有五六年了，但一直沒有進行。想遷移的原因非常簡單：

Wordpress 越來越臃腫。尤其是最近幾年，我幾乎都不想登錄到 Wordpress 後臺，太多的插件年久失修，也不敢亂動，甚至 Wordpress 自身升級後連新建頁面都打不開了；
Wordpress 對 Markdown 的支持是非原生的；雖然使用插件後看似效果不錯，但從數據源的角度來說，本質上它還是存儲為 HTML 格式，這導致文章的結構化和批量處理效果一般。
網站的訪問中有相當比例來源於繁體中文使用者，因此想更好的支持繁體中文的閱讀和使用。

關鍵步驟

從 Wordpress 備份提取 Markdown

這是看似很簡單的步驟，因為有好幾個插件都支持相關的功能，也有一些命令行的腳本。但是，最要命的是轉換並不完美。

我使用的是基於 NodeJS 的 blog2md 腳本。這個腳本的使用很簡單，只需要在 Wordpress 後臺導出備份的 .xml 文件，然後執行腳本就行了。你的計算機需要有 Node 環境。要注意的是，一定按照其 README 中的說明，添加 paragraph-fix 參數，否則很多換行和段落會出現問題。例如：

node index.js w your-wordpress-backup-export.xml out m paragraph-fix

但是即使你採用了上面的參數，轉換出的文章很多依然是有問題的。主要表現在：

部分段落丟失，即缺少換行；
很多之前的代碼高亮的內容出現了多餘的轉義，例如 * 變成了 \*、] 變成了 \]。我的理解是當初為了在 Wordpress 中存儲代碼高亮，相關插件本身做了轉義，但在導出數據時就很痛苦了。
（更要命的）以 < 開頭的內容丟失。可能因為和導出格式為 XML 有關，出現了語義上的衝突。這部分可能只能自己修了。

例如一個 C++ 程序：

template<typename T>
class ...

可能會變成

template typename T\>
class ...

所以，我需要寫腳本來解決這個問題。

使用腳本處理多餘的轉義

下面是一個 NodeJS 腳本，用來批量將指定目錄下的 md 文件的正文部分包裹的代碼塊中的多餘轉義進行修復。例如，它將 \[ 修復成 [，\_ 修復成 _。

const fs = require('fs');
const path = require('path');

// 指定目錄路徑
const DIRECTORY_PATH = 'path/to/content';

// 遞歸地查找.md文件
function findMarkdownFiles(dirPath) {
 let filesToProcess = [];

 const files = fs.readdirSync(dirPath);

 for (const file of files) {
 const filePath = path.join(dirPath, file);
 const stat = fs.statSync(filePath);

 if (stat.isDirectory()) {
 filesToProcess = filesToProcess.concat(findMarkdownFiles(filePath));
 } else if (path.extname(filePath) === '.md') {
 filesToProcess.push(filePath);
 }
 }

 return filesToProcess;
}

// 處理.md文件中的代碼塊
function processMarkdownFile(filePath) {
 const content = fs.readFileSync(filePath, 'utf8');

 // 使用正則表達式匹配所有代碼塊
 const newContent = content.replace(/```[\s\S]*?```/g, (match) => {
 // 替換代碼塊中的反轉義字符
 return match.replace(/\\\[/g, '[')
 .replace(/\\\]/g, ']')
 .replace(/\\\*/g, '*')
 .replace(/\\_/g, '_')
 .replace(/\\\\/g, '\\')
 });

 // 覆蓋原文件
 fs.writeFileSync(filePath, newContent, 'utf8');
}

// 主函數
function main() {
 const markdownFiles = findMarkdownFiles(DIRECTORY_PATH);

 for (const filePath of markdownFiles) {
 processMarkdownFile(filePath);
 }

 console.log('所有.md文件中的代碼塊已處理完畢。');
}

// 運行主函數
main();

警告

請修改 DIRECTORY_PATH 的值，並注意轉義。
這個腳本會覆蓋原文件，請提前備份。而且，由於其做了批量替換，可能會影響代碼正常運行。需要手工檢查。

移除不必要的 TOC（文章目錄）

很多 Hugo 主題使用 toc 這個 Front Matter 來標記是否展開文章目錄。對於老文章，我寫了一個腳本，可以根據這個文章是否有實際的二級標題來判斷是否啟用 toc。也就是說，如果一個文章的 Markdown 裡沒有兩個以上的二級標題，它會把：

+++
title = '本站從 Wordpress 遷移到 Hugo'
date = 2024-04-01T16:38:34+08:00
draft = false
+++

修改為

+++
title = '本站從 Wordpress 遷移到 Hugo'
date = 2024-04-01T16:38:34+08:00
draft = false
toc = false
+++

這樣渲染出的文件就不會有目錄了，並且不需要前端使用 Javascript 動態實現。

自動翻譯簡體中文到繁體中文（或相反）

因為這次升級的一個目的是更好地支持簡繁兩種漢字的使用者，因此我使用了一個腳本，它可以將所有 Markdown 自動進行簡繁轉換。

Hugo 支持兩種多語言模式，我使用的是文件模式，也就是簡體、繁體的文章放在一起，繁體文章增加 .zh-hant 後綴名。

簡繁轉換不能簡單的字字對應，因為存在很多「一對多」的問題和各地習慣用語的問題。 Opencc 是一個不錯的開源工具，可以幫我們實現以詞彙為單位的簡繁轉換，提高轉換的準確率。根據統計，本站大部分繁體用戶來自臺灣，因此我在簡體轉換繁體時，使用了臺灣的慣用詞。

下面的腳本使用 opencc 的 NodeJS 版本進行簡繁轉換。

這個腳本會把轉換後的結果放在 DIRECTORY_OUTPATH 目錄下，文件名增加 .zh-hant 後綴。它只轉換文章的標題和正文，不會轉換文章的元數據，例如 tag 和 url，因此比較安全。

使用前，你需要根據自己的情況對腳本進行適當的修改，並且需要安裝 opencc：

npm i opencc

你需要提前修改腳本中的 DIRECTORY_PATH 和 DIRECTORY_OUTPATH。如果你使用 posts/xxx/index.md、posts/xxx/index.zh-hant.md 這種形式，你可以將兩個目錄設置相同。

腳本內容如下：

const fs = require("fs");
const path = require("path");
const OpenCC = require("opencc");
const converter = new OpenCC("s2twp.json");
const matter = require('gray-matter');

// 指定目錄路徑
const DIRECTORY_PATH = "path/to/blog/content";
const DIRECTORY_OUTPATH = "path/to/blog/content-hant";

// 遞歸地查找.md文件
function findMarkdownFiles(dirPath) {
 let filesToProcess = [];

 const files = fs.readdirSync(dirPath);

 for (const file of files) {
 const filePath = path.join(dirPath, file);
 const stat = fs.statSync(filePath);

 if (stat.isDirectory()) {
 filesToProcess = filesToProcess.concat(findMarkdownFiles(filePath));
 } else if (path.extname(filePath) === ".md") {
 filesToProcess.push(filePath);
 }
 }

 return filesToProcess;
}

// 處理.md文件中的代碼塊
async function processMarkdownFile(filePath) {
 if (filePath.indexOf("zh-tw") >= 0) {
 return;
 }

// 解析Markdown文件的front matter
 const content = matter(fs.readFileSync(filePath, "utf8"));

 // 翻譯正文
 content.content = await converter.convertPromise(content.content)
 // 翻譯標題
 if (content.data.title && content.data.title.length > 0) {
 content.data.title = await converter.convertPromise(content.data.title)
 }

 // 構造輸出文件路徑
 const outFilePath = path.join(DIRECTORY_OUTPATH, path.basename(filePath, ".md") + ".zh-hant.md");

 console.log(outFilePath)
 console.log(content.content)

 // 如果文件存在則不覆蓋
 if (fs.existsSync(outFilePath)) {
 return;
 }
 const newMarkdownContent = matter.stringify(content);
 fs.writeFileSync(outFilePath, newMarkdownContent)
}

// 主函數
function main() {
 const markdownFiles = findMarkdownFiles(DIRECTORY_PATH);

 for (const filePath of markdownFiles) {
 processMarkdownFile(filePath);
 }

 console.log("所有.md文件已處理完畢。");
}

// 運行主函數
main();

警告

不要使用 zh-tw、zh-hk、zh-cn 等作為語言標識。因為他們代表的是地區。作為一個小站點，你估計不太可能會為香港、臺灣、新加坡各做一個不同的站點。
使用 zh-hant 代表傳統漢字，zh-hans 代表簡體中文是明顯更加通用的選擇。這也方便瀏覽器、搜索引擎判斷你的目標用戶。比如，你使用了 zh-hant，香港訪問者不會被排除在外。
你可以訪問 opencc 的 gihhub 頁面，查找不同的配置文件。不同的配置文件會使用不同的慣用詞，請根據你實際的需求進行修改。我使用的是 s2tw.json 文件，代表使用臺灣慣用詞進行簡體到繁體的轉換。

你也可以通過修改 s2twp.json 配置文件的名字實現繁體->簡體的轉換。

手工檢查所有文章

雖然做了自動化處理，但很多文章依然有問題，需要手工檢查一遍。

選擇合適的評論系統

我選擇的是 Waline，但你可以選擇任何你喜歡的評論系統。唯一的建議是，評論數據需要掌握在自己手裡，因此必須選擇可以備份評論數據的評論系統。否則，一旦你的託管方式發生變化，你可能會追悔莫及。

Waline 支持多種數據源，我選擇的是 sqlite，因為我有自己的服務器，並且我希望一個節約內存的輕量化解決方案。

從 Wordpress 評論遷移到 Waline

目前網絡上似乎還沒有從 Wordpress 評論遷移到 Waline 的現成方案。本文提供了一種方案，可以將 Wordpress 所有評論無損地遷移到 Waline。

首先從 Wordpress 後臺，導出所有內容的 xml 文件。

然後執行我寫的腳本（你需要有 NodeJS），對 xml 文件進行分析，生成可以導入到 Waline 的導入格式（注意修改 WORDPRESS_XML_FILE 變量）：

const fs = require('fs');
const xml2js = require('xml2js');
const parser = new xml2js.Parser();

// WordPress備份文件的路徑
const WORDPRESS_XML_FILE = 'WordPress.2024-03-28.xml';

// 讀取XML文件
fs.readFile(WORDPRESS_XML_FILE, (err, data) => {
 if (err) {
 console.error('Error reading XML file:', err);
 return;
 }

 // 解析XML數據
 parser.parseString(data, (err, result) => {
 if (err) {
 console.error('Error parsing XML data:', err);
 return;
 }

 // 初始化評論數組
 let commentsArray = [];

 // 遍歷每個item（文章或頁面）
 result.rss.channel[0].item.forEach((post) => {
 // 判斷是否有評論
 if (post['wp:comment']) {
 // 遍歷每條評論
 post['wp:comment'].forEach((comment) => {
 if (comment['wp:comment_approved'] + '' == "1" && comment['wp:comment_type'] != 'pingback') {
 let commentObj = {
 user_id: null,
 comment: comment['wp:comment_content'] ? comment['wp:comment_content'][0] : '',
 insertedAt: comment['wp:comment_date'] ? comment['wp:comment_date'][0] : '',
 ip: comment['wp:comment_author_IP'] ? comment['wp:comment_author_IP'][0] : '',
 link: comment['wp:comment_author_url'] ? comment['wp:comment_author_url'][0] : '',
 mail: comment['wp:comment_author_email'] ? comment['wp:comment_author_email'][0] : '',
 nick: comment['wp:comment_author'] ? comment['wp:comment_author'][0] : '',
 rid: comment['wp:comment_parent'] && comment['wp:comment_parent'][0] !== '0' ? parseInt(comment['wp:comment_parent'][0]) : null,
 pid: null,
 sticky: null,
 status: 'approved',
 like: null,
 ua: comment['wp:comment_agent'] ? comment['wp:comment_agent'][0] : '',
 url: (post['link'] ? post['link'][0] : '').replace("https://ceeji.net", ""),
 createdAt: comment['wp:comment_date'] ? comment['wp:comment_date'][0] : '',
 updatedAt: comment['wp:comment_date'] ? comment['wp:comment_date'][0] : '',
 objectId: parseInt(comment['wp:comment_id'][0])
 };
 commentsArray.push(commentObj);
 } else {
 console.log("跳過沒批准的評論")
 }
 });
 }
 });

 // 將評論數組轉換為JSON並保存到文件
 const jsonContent = JSON.stringify(commentsArray, null, 2);
 fs.writeFile('comments.json', jsonContent, 'utf8', (err) => {
 if (err) {
 console.error('Error writing JSON file:', err);
 } else {
 console.log('Comments have been exported to comments.json');
 }
 });
 });
});

最後，在 Waline 的管理後臺，選擇導入導出功能：

先選擇導出，打開導出後的 JSON 文件，格式類似如下：

{
 "__version": "1.31.13",
 "type": "waline",
 "version": 1,
 "time": 1711963109933,
 "tables": [
 "Comment",
 "Counter",
 "Users"
 ],
 "data": {
 "Comment": [] // 替換此處的數據
 }
}

把 Comment 處的內容替換為腳本生成的內容，即可進行導入。注意，導入會丟失所有現有數據，如原來有數據的，需要手工合併或提前備份。

實現代碼高亮的黑暗模式自適應

Hugo 自帶的代碼高亮功能，一般只能設置一個樣式。如果你的主題支持自適應黑暗模式，可能會導致在切換黑暗模式開關的時候，代碼高亮不能跟著切換。

最新版本的 Hugo 使用 chroma 進行語法高亮。首先，確定你想要使用的樣式。比如我們在亮色模式下使用 monokailight 樣式，在暗色模式下使用 onedark 樣式。

接下來，創建對應的 .css 文件供 Hugo 使用：

hugo gen chromastyles --style=monokailight > syntax_light.css
hugo gen chromastyles --style=onedark > syntax_dark.css

將這兩個文件移動到你的主題 assets 文件夾中（例如 ./themes/paper/assets/）。

接下來，確保我們的 Hugo 主題加載這些樣式。為此，編輯 ./themes/paper/layout/partials/head.html（或者負責在你的主題中添加頭部部分的文件），添加以下內容：

{{ $syntax_dark_css := resources.Get "syntax_dark.css" | minify }}
{{ $syntax_light_css := resources.Get "syntax_light.css" | minify }}

<link rel="preload stylesheet" as="style" href="{{ $syntax_dark_css.Permalink }}" />
<link rel="preload stylesheet" as="style" href="{{ $syntax_light_css.Permalink }}" />

這將在使用 Hugo 構建站點時使 .css 文件可用，並允許頁面加載它們。

順序很重要：默認情況下，應用最後引用的文件中的樣式，因為它會覆蓋之前的樣式！為了讓 Hugo 使用我們的 .css 文件作為 chroma 樣式，我們需要在 Hugo 的 hugo.toml 文件中明確指定以下內容：

[markup.highlight]
 noClasses = false

確保一切正常後，檢查你的代碼是否已使用設置的樣式進行高亮顯示。當你切換到暗色模式時，目前應該還不會有任何變化。

然後你需要寫動態切換應用於代碼片段的 .css 文件的腳本。

在 ./themes/papers/partials/header.html（或者負責在你的 Hugo 主題中切換模式的文件）中，找到切換模式的代碼。每個主題都不一樣，你需要自己去找。

例如它可能類似這樣：

const setDark = (isDark) => {
 metaTheme.setAttribute('content', isDark ? '#000' : lightBg);
 htmlClass[isDark ? 'add' : 'remove']('dark');
 localStorage.setItem('dark', isDark);
};

我們在這個函數調用中添加一個方法：

const setDark = (isDark) => {
 metaTheme.setAttribute('content', isDark ? '#000' : lightBg);
 htmlClass[isDark ? 'add' : 'remove']('dark');
 localStorage.setItem('dark', isDark);
 setSyntaxDark(isDark); // 添加的方法
};

定義 setSyntaxDark 函數和一個額外的輔助函數：

function getStyleSheet(file_name) {
 for (var i = 0; i < document.styleSheets.length; i++) {
 var sheet = document.styleSheets[i];
 if (sheet.href.includes(file_name)) {
 return sheet;
 }
 }
}

function setSyntaxDark(isDark) {
 let sheet_light = getStyleSheet("syntax_light")
 let sheet_dark = getStyleSheet("syntax_dark")

 sheet_light.disabled = isDark ? true : false
 sheet_dark.disabled = isDark ? false : true
}

隨後，使用 Hugo 重新構建你的網站，確保一切正常。

簡繁中文使用相同的評論數據，並自動翻譯

簡繁語言本就沒什麼大差距，不需要分開不同的評論。在 Waline 中，你可以通過移除 url 中的語言部分使得不同語言版本共享同一個評論。

修改你的 waline 初始化代碼：

init({
 el: "#xxx",
 serverURL: "xxx",
 locale: locale['{{ .Page.Lang }}'], // 注意這一行
 dark: 'html.dark', // 可實現黑暗模式自適應
 // path 中使用正則移除簡繁部分的網址
 path: window.location.pathname.replace(/zh-(hans|hant)\//, '')
});

同時我們需要定義一個 locale 變量實現 waline 的本地化，例如：

const locale = {
 "zh-hans": {
 nick: '暱称',
 nickError: '暱称不能少于3个字符',
 mail: '邮箱',
 mailError: '请填写正确的邮件地址',
 link: '网址',
 optional: '可选',
 placeholder: '欢迎评论',
 sofa: '来发评论吧~',
 submit: '提交',
 like: '喜欢',
 cancelLike: '取消喜欢',
 reply: '回复',
 cancelReply: '取消回复',
 comment: '评论',
 refresh: '刷新',
 more: '加载更多...',
 preview: '预览',
 emoji: '表情',
 uploadImage: '上传图片',
 seconds: '秒前',
 minutes: '分钟前',
 hours: '小时前',
 days: '天前',
 now: '刚刚',
 uploading: '正在上传',
 login: '登录',
 logout: '退出',
 admin: '博主',
 sticky: '置顶',
 word: '字',
 wordHint: '评论字数应在 $0 到 $1 字之间！\n当前字数：$2',
 anonymous: '匿名',
 level0: '潜水',
 level1: '冒泡',
 level2: '吐槽',
 level3: '活跃',
 level4: '话痨',
 level5: '传说',
 gif: '表情包',
 gifSearchPlaceholder: '搜索表情包',
 profile: '个人资料',
 approved: '通过',
 waiting: '待审核',
 spam: '垃圾',
 unsticky: '取消置顶',
 oldest: '按倒序',
 latest: '按正序',
 hottest: '按热度',
 reactionTitle: '你认为这篇文章怎幺样？'
 },
 "zh-hant": {
 nick: '暱稱',
 nickError: '暱稱不能少於3個字元',
 mail: '郵箱',
 mailError: '請填寫正確的郵件地址',
 link: '網址',
 optional: '可選',
 placeholder: '歡迎評論',
 sofa: '來發評論吧~',
 submit: '提交',
 like: '喜歡',
 cancelLike: '取消喜歡',
 reply: '回覆',
 cancelReply: '取消回覆',
 comment: '評論',
 refresh: '重新整理',
 more: '載入更多...',
 preview: '預覽',
 emoji: '表情',
 uploadImage: '上傳圖片',
 seconds: '秒前',
 minutes: '分鐘前',
 hours: '小時前',
 days: '天前',
 now: '剛剛',
 uploading: '正在上傳',
 login: '登入',
 logout: '退出',
 admin: '博主',
 sticky: '置頂',
 word: '字',
 wordHint: '評論字數應在 $0 到 $1 字之間！\n當前字數：$2',
 anonymous: '匿名',
 level0: '潛水',
 level1: '冒泡',
 level2: '吐槽',
 level3: '活躍',
 level4: '話癆',
 level5: '傳說',
 gif: '表情包',
 gifSearchPlaceholder: '搜尋表情包',
 profile: '個人資料',
 approved: '透過',
 waiting: '待稽核',
 spam: '垃圾',
 unsticky: '取消置頂',
 oldest: '按倒序',
 latest: '按正序',
 hottest: '按熱度',
 reactionTitle: '你認為這篇文章怎麼樣？'
 }
}

重定向 Feed（Rss/Atom）訂閱地址

我的網站雖然是個小站，但依然有些人在訂閱。為了避免他們走丟，我需要能夠保持原有的 Feed 訂閱地址。如果你使用的 OSS 或其他無服務器（Serverless）的方式進行託管，你可能需要在你的 CDN 頁面使用 rewrite 來實現。

因為我是有服務器的，我使用 nginx 來實現了這一點。

Hugo 默認將 RSS/Atom 發佈在根目錄下的 index.xml 或類似的文件中。找到這個文件的地址，然後你可以進行重定向：

location ~ ^/blog/feed/?$ {
 rewrite ^ /index.xml last;
}

上面的這段 nginx 配置可以把 /blog/feed 和 /blog/feed/ 指向 index.xml，同時保持對外訪問地址不變。

提示

一個小技巧：在你的 nginx 訪問日誌中搜索 feed，你可能可以看到有多少人訂閱了你的網站。

除了解決 Feed 網址問題外，如果你和我一樣通過 nginx 部署，建議你還要做兩件事：

遷移早期定期訪問 access log，查看是否有舊網址出現了 404 錯誤，這不利於 SEO；
在 nginx 配置文件裡，設置正確的 404 頁面。

圖片管理

強力建議你採用下列的文件結構來存放圖片：

posts /
 article /
 index.md
 1.jpg

這種方式管理方便，而且在 Markdown 編輯器中不會出現圖片看不到的問題。

然後，你可以通過 render-image hook 實現圖片的 CDN 化，提升全球訪問速度。具體可進行相關搜索。

智繪童話

Sun, 24 Mar 2024 18:03:50 +0000

親愛的大朋友們和小朋友們，
就在今天，《智繪童話》小程序正式開始公測了！這是我們對於未來教育和家庭親子活動的一次大膽想象和實踐。

《智繪童話》是一款微信小程序，它巧妙地將AI技術融入到兒童教育和家庭親子活動中，通過先進的AI算法，根據孩子的興趣和喜好推薦個性化故事內容，配以動人的聲音和精美的圖像，為孩子們創造出獨一無二的故事體驗。每一個環節都力求完美，真正實現了「故事自由」的理念。

我們知道，家長們在選擇教育內容時，總希望能夠提供既富有想象力又具有教育意義的素材。《智繪童話》正是基於這一需求而生。它不僅能夠根據不同年齡段的孩子身心特點定製故事，還能通過精準的AI標籤，讓您用最簡單的詞彙就能找到所需的資源。更加令人興奮的是，這些故事都是中英雙語的，不僅能夠豐富孩子的語言環境，還能在輕鬆愉快的氛圍中提高英語聽力水平。而AI語音技術的加持，更是讓故事的講述變得生動有趣，吸引孩子們的注意力，同時也讓忙碌的家長們能夠在繁重的育兒任務中稍作喘息。

《智繪童話》不僅僅是一款產品，它是一個家庭親子互動的新平臺，是AI技術與日常生活完美結合的實例。在這裡，每一個家庭都能找到共同的樂趣。

目前，《智繪童話》正處於公測階段，我們誠邀您與孩子一起探索這個充滿想象力的童話世界。目前我們只上線了基礎功能，在未來，我們將不斷更新迭代，引入更多智能化功能，以期為您和孩子帶來更加豐富、便捷的親子互動體驗。AI時代，讓我們一起走進這個智慧的童話世界，探索知識的海洋，共繪美好的記憶。《智繪童話》期待與您和孩子一同成長，一起創造無限可能！

這是網頁版，其中點擊故事可以跳轉到小程序：

zhihuitonghua.baiyan.tech

假如杭州保留了南宋古建築…

Sun, 28 Jan 2024 14:43:07 +0000

今天我使用人工智慧繪圖還原了南宋古建築和現代城市交相輝映下的杭州，一起來看：

杭州夜景

西湖邊的燈籠

武林廣場與輕軌

杭州城站

西湖與飛鳥

高鐵穿過群山

在街巷遊玩的孩子

使用ChineseGenie學習中文

Fri, 16 Jun 2023 09:04:12 +0000

革命性地學習中文，由先進的AI技術、自然語言處理和語音識別能力驅動！隨時隨地與您的AI中文口語夥伴Viva聊天，談論您最喜歡的書籍、法式餐廳等等。Viva具有與母語人士相同的地道普通話發音，但無需像真正的中文老師一樣預約時間。始終在線且可用，無需擔心按小時收費。被一句你無法閱讀或理解的句子難倒了嗎？Viva將立即將其準確翻譯成您的母語。自信地說話，因為Viva在那裡糾正語法錯誤；需要寫一篇中文報告嗎？Viva將幫助您潤色句子，不僅修復語法問題，還解決任何不當的用詞。 Viva，您的中文精靈，是您學習語言過程中忠實的AI助手。通過ChineseGenie應用程序，發現一種全新、有趣且有效的方法來掌握中文！

訪問 ChineseGenie 官網：https://chinese-language-learning-chinesegenie.baiyan.tech/

無法在阿里雲控制檯被使用的 CSI 插件特性：動態 NAS 存儲池

Tue, 15 Dec 2020 16:56:37 +0000

在 Kubernetes 環境中，阿里雲早已開發並支持基於 CSI 存儲插件的動態 NAS PV 創建，其基於阿里開發的 CSI Plugin。但是，你會發現，在阿里雲的控制檯中，如果你創建 PVC，你會發現只有雲盤才支持基於 StorageClass 自動生成 PV。其實你是可以通過命令行的方式來開啟該功能的。網上有些阿里官方的文檔比較老，一些步驟裡引用的鏈接不正確。目前創建的阿里 Kubernetes 集群都已經開啟了 CSI Plugin 並且包含 NAS 支持，你並不需要手工安裝。

首先要求用戶使用NAS控制檯或 SDK/API 創建好NAS文件系統和掛載點。

然後，唯一需要的是創建一個 StorageClass, 詳細參數說明見：https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/master/docs/nas-dynamic.md

HTML disabled 屬性的一個坑

Sat, 26 Nov 2016 02:36:18 +0000

一天我在一個頁面裡寫下如下的代碼：

<div disabled></div>

並在 CSS 中設置：#xx:disabled { background-color: red; }。

可是，此 CSS 並沒有生效。

後來考慮到，disabled 這個屬性是不是對 div 無效？經過查詢，果然 disabled 屬性是針對表單的，於是果斷把 div 改為 button，發現依然無效。

果斷在 W3School 查找，發現 disabled 屬性只對 input 元素有效。

C# 與 Java 語言機制與語法的異同

Mon, 14 Nov 2016 19:06:28 +0000

本文是從 C# 到 Java 系列的文章。此係列文章是為了方便從 C# 轉到 Java 平臺的工程師快速學習新的語言和平臺。整個系列的目錄請點擊此處瀏覽。

這篇文章從基礎的語言機制、語法層面來分析 C# 和 Java 的不同。部分與虛擬機（CLR | JVM）有關的不同會放在相關的另一篇裡，詳見總目錄。

命名規範

Java 中的方法和變量，無論是否為public，都要以小寫字母開頭，其餘與 C# 大體相當。

那些簡單的同義詞或近義詞

下面的詞彙，在 Java 和 C# 中是 同義 或 近義 的：

C# 中獲取一個對象的類型使用 typeof 關鍵詞，Java 中使用 .class，如 String.class；C# 也可以使用對象實例的 GetType 方法，Java 中對應的是 getClass 方法。參考鏈接；
代表一個對象的類型的類型，C# 為 Type 類型，Java 則為 Class 類型。參考鏈接。
C# 中的 const （編譯時常量）和 readonly（運行時常量）在 Java 中都是 final，同時還代表了一個類不能被繼承（等同於 C# 的 sealed）。
Java 中的 native 關鍵字（聲明使用 native 實現的代碼）類似於 C# 中的 extern（當聲明非託管的外部方法，如動態鏈接庫時使用）。
string 與 String：在 Java 只有後者，在 C# 中前後兩者是同義詞。
Java 中的 synchronized 等同於 C# 語句塊中的 lock，以及方法體上的特性MethodImplOptions.Synchronized。
Java 中的 transient （短暫）等同於 C# 的 NonSerializableAttribute，代表在序列化中跳過。
Java 的 ... 操作符等同於 C# 的 params。例如：String... args，則 args 為一個所有參數組成的數組。

值類型與裝箱

Java 的值類型（Value Types）僅限於原生類型，如 int、boolen 等。Java 不允許自定義值類型，即 Java 不存在 C# 中的 struct。

值類型 的作用可以從以下幾個方面來考慮：

性能：C# 中的 struct 類型有助於減少 GC、減少內存使用、提高性能，但 Java 強大的虛擬機 JVM 通過優化部分緩解了這個問題。
語義：原生類型無法為 null，且通過傳值方式賦值。

但是，由於 C# 中的值類型通過傳值類型賦值造成了意外錯誤的可能（例如用類似類的方式在杯傳遞後的值類型中修改成員，試圖影響到原有的值），使用值類型要警惕。

值類型在 Java 中不繼承於 Object，但 C# 中卻繼承，這是通過自動裝箱實現的。Java 的值類型可以通過裝箱變為類實例，比如：

int => Integer
float => Float
byte => Byte

Java 具體的數據類型方面的內容，可以參考本系列文章中的另一篇：數據結構（文章末尾有目錄導航）。

泛型

Java 支持泛型，但其支持的方式和 .NET 差別比較大。Java 的泛型使用 類型擦除 實現。所以，你雖然可以設置某個方法或類有一個類型參數 T，但是你在其實現內部卻無法獲知與該類型的任何信息，解決方法就是使用一個補償的 class 類型（類似於 C# 中的 Type 類型）參數手工傳遞數據類型。

有關 Java 泛型的類型擦除，請參考鏈接

委託，事件

C# 中的委託（delegate）用於指向固定某個方法原型（一系列參數、某種返回值）的指針（姑且這麼叫吧）。Java 中沒有 delegate 的概念。

Java 中一般通過接口來實現類似委託的效果。

例如，C# 中假如有下面的定義：

 // 定義委託
public delegate void onClickListener(View v);

// 定義委託的實現
public void listener(View v) {
 // foo
}

// 使用委託
onClickListener = listener;
onClickListener(this);

在 Java 中可以這樣實現。先定義一個接口：

public interface OnClickListener {
 void onClick(View v);
}

然後，使用這個接口來存儲一個匿名類，其中帶有具體的實現，例如：

OnClickListener listener = new OnClickListener() {
 @Override
 void onClick(View v) {
 // 在此書寫代碼
 }
};

// 調用接口
listener.onClick(someView);

除了使用匿名類，也可以讓某個命名類繼承此接口：

public class TestClass implements OnClickListener {
 void OnClick(View v) {
 // 在此書寫代碼
 }

 void init() {
 OnClickListener listener = this;

 // 調用接口
 listener.onClick(someView);
 }
}

C# 支持事件（event），其內部是通過委託來實現的。Java 中沒有事件的概念。

一般來說，用於事件或委託的情況，Java 會使用接口來實現。

例如，C# 中的事件：

public event EventHandler SomeEvent; // 事件的發出者

// 事件監聽
someInstance.SomeEvent += (sender, args) => { /* xxx */ };

大約等價於 Java 中的方法：

// 先定義接口
public interface SomeEventListener {
 void onEvent(int arg);
}

// 搞一個東西用來存儲接口的具體實現對象
private ArrayList<SomeEventListener> someEventListeners = new ArrayList<>();

// 在要產生事件的類中，添加一對方法用於監聽或取消監聽
public void addSomeEventListener(SomeEventListener listener) {
 someEventListeners.add(listener);
}

public void removeSomeEventListener(SomeEventListener listener) {
 someEventListeners.remove(listener);
}

// 觸發事件
for (int i = 0; i < someEventListeners,size(); ++i) {
 someEventListeners.get(i).onEvent(5);
}

// 事件監聽者，使用 Java8 中才支持的 Lambd 表達式
someInstance.addSomeEventListener(() -> { /* xxx */ });

// 事件監聽者，使用 Java7 以前版本的 匿名類
someInstance.addSomeEventListener(new SomeEventListener() {
 @Override
 void onEvent(int arg) {
 // 代碼邏輯
 }
});

也可以參考這篇文章。

本文是從 C# 到 Java 系列的文章。此係列文章是為了方便從 C# 轉到 Java 平臺的工程師快速學習新的語言和平臺。整個系列的目錄請點擊此處瀏覽。

為什麼要從 C# 轉為 Java：淺談 .NET 與 Java 生態

Mon, 14 Nov 2016 17:46:28 +0000

本文是從 C# 到 Java 系列的第一篇文章。整個系列的目錄請點擊此處瀏覽。

C# 是 .NET 平臺上最重要的一門語言，Java 是世界上使用最廣的語言之一。這兩門語言有著太多的恩怨情仇，也有很多相似之處。C# 在最初創立的時候，或多或少借鑑了 Java 語言的優秀特性，但後期發展又和 Java 走上了不同的道路。

那麼，為什麼你要從一門語言，轉換為另一門很相似的語言呢？本文主要談談，為什麼在某些情況下，你可能需要，或者願意從基於 .NET 的 C# 轉移到基於 JVM 的 Java 語言平臺。

統一開發平臺，重用現有資產

某些類型的開發不得不用 Java 開發，或者大多數人都在用 Java 開發。如 Android 開發，Android 的開發技術棧全部構建於 JVM 之上；所以整個團隊的開發語言只能遷就於上述原因來選用 Java；
很多團隊或公司中，有大量現存的基於 Java 的資產（代碼、模塊、應用），統一開發語言和平臺可以降低團隊磨合、學習成本，重用現有代碼資產。而統一語言時顯然無法選擇 C#，因為 Java 適用面更廣（即很少有 Java 可做而 C# 無法做的領域或平臺）。

減少技術風險，方便技術學習

Java 的歷史更長，開發人員更多，社區也更大，如果在開發上遇到問題，有很多成熟的解決方案可以參考（俗稱的Google之）；
開發特定領域的程序時，Java 可借鑑的代碼和框架更多，避免遇到技術死角；大多數領域的開發已經在 Java 中有成功的案例，避免技術上潛在的風險。
某些第三方產品或接口，官方優先支持 Java 或只支持 Java，使用其他平臺需要額外開發或進行封裝，導致開發效率和性能的問題。

減少開支

靠譜的 Java 程序員更好招聘，可以減少用於招聘的人力資源成本；原因有二。一是 C# 確實比 Java 對開發者更貼心，所以導致了學習成本更低，造成了 C# 小白喪失了繼續學習的進取心，客觀上降低了 C# 開發者的平均水平；二是從絕對數量上來說，C# 開發者也少於 Java 開發者（如下圖）。
基於 .NET 平臺的開發工具和相關產品普遍需要付費；基於 Java 的開發工具和相關產品免費的更多。

下圖為 2016年11月，在全球範圍內 C# 與 Java 語言的流行度對比，Java 排名第一，C# 排第四。

C# 與 Java 流行度對比

基於 Java 開發將擁抱更廣泛的生態

如上圖所示，Java 長期在開發語言排行榜中流行程度排名第一，所以擁有更好的生態，即有成千上萬的成熟類庫、大量的技術資料、很多的現成代碼；
Java 更偏向於基於 Linux/Unix 平臺的開發，而 .NET 在早期太多地依賴於 Windows，後期 .NET 雖然開源且跨平臺，但已為時略晚。在互聯網相關行業，Linux 及其生態圈比 Windows 繁榮得多。
Java 早已不是一個開發語言，而是一整個生態圈。
Java 在語法、平臺技術上、開發效率上並非最好的，但卻是夠用的，且有出色的平衡性。雖然 Java 在哪個方面幾乎都不是最強的，但卻都說得過去。

說實話，我個人更偏愛 .NET 技術，其炫酷、性能優異、免費且跨平臺、開發效率高，但是，基於以上原因，有時 Java 是更務實的選擇。

如果你準備好了基於 Java，而不是 C# 開啟你的下一段代碼，就讓我們一起來學習吧！

本文是從 C# 到 Java 系列的第一篇文章。整個系列的目錄請點擊此處瀏覽。

從 C# 到 Java：總目錄

Mon, 14 Nov 2016 17:03:02 +0000

引言

為了方便以前使用 C#（.NET），由於某些原因，需要學習 Java （JVM），或開發基於其的應用的人（比如開發 Android 應用），我打算寫一篇系列文章，詳細地描述中間可能遇到地問題、學習路徑等。方便 .NET 開發人員快速轉為 Java 開發人員。

具體來說，主要會通過對比和舉例來行文。在過程中，不但會講 Java，也會把 C#（.NET）的一些內容講一講，算是起到兩種語言甚至是平臺的對比與深入。

下面是總目錄，沒寫好的部分不可點擊，有鏈接的部分才可以閱讀。

總目錄

為什麼要從 C# 轉為 Java：淺談 .NET 與 Java 生態

C# 與 Java 語言機制與語法的異同

.NET 與 Java 數據結構異同 .NET 與 Java 核心類庫的主要區別 CLR 與 JVM 對比

從 C# 到 Java：Java 包管理、主要框架與測試從 C# 到 Java：開發範式與哲學

近期遇到的幾個佈局兼容性彙總

Thu, 10 Nov 2016 17:59:42 +0000

（實時更新）

flex 可伸縮元素比例不正確（Android 4.0 - 4.3，iOS 低版本）

使用 flex 佈局，在現階段已經是非常靠譜的方案了，因為 flex 佈局已經在大多數主流瀏覽器中兼容。但是，flex 佈局還是有不少需要注意的兼容問題。

在 Android 4.0 - 4.3 和部分低版本 iOS 中，可伸縮元素（大小按比例縮放的元素）如果要確保比例正確，必須設置：

xxx {
 width: 0px;
}

其中，width，一般設置為 width: 0 或 1px、0.001% 等。

如果不設置，那麼一旦 flex 的子元素的實際內容超過了按照伸縮比例應該擁有的寬度，在這些有 bug 的系統中就會出問題，具體表現是**子元素的寬度將根據實際寬度進行延伸，最多可以佔據整個屏幕的寬度（即使它的 flex 佈局的父元素設置了寬度，它自身仍然可以撐開以達到整個屏幕的寬度）。

Javascript 中的 undefined 與未定義（not defined）

Mon, 01 Sep 2014 08:19:26 +0000

在 Javascript 中，有一種致命錯誤非常常見，即 ReferenceError：xxx is not defined. 但是，有時候當一個值從未被賦值的時候，並不會出錯，而是返回 undefined，有必要對這兩者進行梳理。

undefined

undefined 表達的含義有三種情況：

這個變量存在，但是並沒有給予任何值。
一種普通的數據類型和一種值。你可以手工將任何變量賦值為 undefined，此時其沒有特別含義。
一個存在的對象中的一個不存在（沒有聲明）的值，會被認為是 undefined。

對這三種情況進行歸納，undefined 可以如下總結：

它是一種數據類型，也是一種值。
有這種值的時候，要麼它本身被賦值，要麼本身存在，要麼其所在對象存在。完全不存在的變量不會是 undefined（注意，此處還有坑，往後看）。下面舉幾個例子。

一個聲明但沒有賦值的變量為 undefined

var p;
alert(p); // undefined

一個不存在的對象成員為 undefined

var p = { };
alert(p.a); // undefined

如果 p 還有一個成員 b，其值被手工賦值為 undefined，如何區分不存在的成員 a 和存在的成員 b？可以使用 Object.prototype.HasOwnProperty() 方法。

一個手工賦值的 undefined

var p = 5;
p = undefined;
alert(p); // undefined

從上面的三個例子可以清楚看出 undefined 的一些情況。undefined 的優點在於正常使用有此值的變量不會拋出異常。

未定義（not defined）

一個 未定義 (not defined) 的變量是完全沒有任何聲明的變量。這樣的變量在使用時會直接拋出致命錯誤。但是，如果使用 typeof 來判斷這樣的變量，不但不會出錯，而且竟然會返回 undefined，這使得無法使用 typeof 來區分這兩種情況。

iPhone 手機QQ 4.7.2 版本網絡狀態洩露用戶隱私

Tue, 01 Jul 2014 15:44:42 +0000

iPhone 手機QQ 4.7.2 版本會在用戶的在線狀態旁邊增加一行小字，「2G」，「3G」，「4G」，或「WiFi」。我目前沒有找到關閉這項功能的方法。而這項內容其實是嚴重洩漏了用戶的隱私信息的。

對於很多生活就是三點一線甚至兩點一線的人來說，其所在區域的網絡狀態（2G、3G、WiFi）可以輕易讓人確定其方位。尤其是，如果再加上電腦在線的狀態，這四種狀態很可能可以大體推斷用戶所在位置。

例如對於學生黨而言：

2G：可能在旅遊或火車上。 3G、4G：可能在課堂或市區。 WiFi：很可能在寢室或圖書館。

騰訊沒有給出取消狀態顯示的方式，對於用戶隱私考慮絕對是不周全的。

宋卿體育館與六一慘案

Sat, 19 Apr 2014 06:44:46 +0000

在武漢大學文理學部第四教學樓前樹立著一個六一亭，紀念著當年六一慘案中的遇難者。一九四七年六月一日黎明，國民黨軍警幾千人武裝包圍了武漢大學校園。肆意搜捕進步師生陳如豐、王志德、黃鳴嵐三人，並當場慘遭槍殺，造成震驚全國的「六一」慘案。

機槍掃射，軍警包圍，珞珈山竟成屠場，請看遍地鮮血，四項諾言何去？四海同胞，人神共憤，清華園遙祭英魂，謹獻一瓣心血，億萬青年繼後來。（摘自清華學生自治會的輓聯）

同年8月，武漢大學進步師生在校內修建「六·一」慘案紀念亭。亭坐北朝南，邊高6.5米，六角地尖頂，翠瓦飛簷，有6根朱漆圓柱支柱。在六一亭上寫有紀念的碑文。

其不遠處的桂園有一個著名的宋卿體育館。宋卿體育館用了「民國大總統」黎元洪的字「宋卿」作為名稱，是因為其資金來源於黎元洪之子的捐贈。

然而之前我不知道的是，六一慘案的紀念儀式就是在距離其不遠的宋卿體育館舉行的。

我也不知道的是，在黎元洪當年籌備十萬大洋捐建武漢大學體育館的時候，其是為了滿足自己的一個心願：能夠讓自己死後葬在風景如畫的珞珈山南麓。黎元洪希望自己的捐贈能讓武大置換給自己一塊陵墓的位置。為了得葬於此地，黎元洪曾表示願意向武大捐獻一筆資金，不過被當時的武漢大學拒絕了，老武大前輩們當年的風骨可見一斑。

黎元洪早年曾想在武昌創辦江漢大學，並籌款銀洋10萬元購買了當時的中興煤礦股票1000股，以備日後作辦學基金。黎元洪病逝後其子將股票折換成10萬現大洋，並在1934年去信給武大稱:

繫於先君遺志，不敢輒忘，……擬將此項基金轉移貴校，用以培植人才，藉了先君心願。

武大派人到天津過戶並同黎子約定這筆資金用來建設宋卿體育館。

Nginx 無法處理軟鏈接作為網站主目錄的情況

Wed, 16 Apr 2014 04:28:52 +0000

近日我將本站點的服務器從北京遷移到了廣州。在遷移的過程中，我發現 Nginx 無法處理軟鏈接作為網站主目錄的情況。

例如，我在 Dropbox 備份了服務器的網站主目錄，位置在 /root/Dropbox/var/www.

我使用這條命令為其創建一個軟鏈接：

ln -s /root/Dropbox/var/www /var/www

修改目錄和軟鏈接的所有者以便 nginx 可以讀取和執行：

chown -h www-data:www-data /var/www

chown -R www-data:www-data /root/Dropbox/var/www

然後，修改 nginx 配置文件中 sites-enabled 的網站，把其配置中的主目錄設定為 /var/www；

隨後運行，發現 nginx 報告 500 錯誤，查看 nginx 日誌 /var/log/nginx/error.log，發現其中有這樣的話：

13: Permision Denied

經過仔細檢查，我認定無論如何設置權限， nginx 都無法處理軟鏈作為主目錄的情況。

甲午年，至關重要的使命

Thu, 30 Jan 2014 18:04:11 +0000

接下來的一年於我而言的重要，直接可以用人生選擇來形容。我已經將創業作為了自己的發展方向和主業。接下來的半年，算是正式創業的開端。從此，作為一個職業創業者，今年的使命可以說「亞歷山大」。更核心的時期，應該是前半年，也就是我畢業之前的時間節點。在這段時間，我的業績能做到如何，企業能否起步，將是相當重要的一個轉折點。加油。

蔡元培不肯再任北大校長的宣言

Fri, 03 Jan 2014 10:58:49 +0000

（1919年6月15日）

（一）我絕對不能再作那政府任命的校長：為了北京大學校長是簡任職，是半官僚性質，便生出那許多官僚的關係，那裡用呈，那裡用諮，天天有一大堆無聊的照例的公牘。要是稍微破點例，就要呈請教育部，候他批准。什麼大學文、理科叫做本科的問題，文、理合辦的問題，選科制的問題，甚至小到法科暫省學長的問題，附設中學的問題，都要經那拘文牽義的部員來斟酌。甚而部裡還常常派了什麼一知半解的部員來視察，他報告了，還要發幾個訓令來訓飭幾句。我是個痛惡官僚的人，能甘心仰這些官僚的鼻息麼？我將進北京大學的時候，沒有想到這一層，所以兩年有半，天天受這個苦痛。現在苦痛受足了，好容易脫離了，難道還肯投入去麼？

（二）我絕對不能再做不自由的大學校長：思想自由，是世界大學的通例。得意志帝政時代，是世界著名開明專制的國，他的大學何等自由。那美、法等國，更不必說了。北京大學，向來受舊思想的拘束，是很不自由的。我進去了，想稍稍開點風氣，請了幾個比較的有點新思想的人，提倡點新的學理，發佈點新的印刷品，用世界的新思想來比較，用我的理想來批評，還算是半新的。在新的一方面偶有點兒沾沾自喜的，我還覺得好笑。哪知道舊的一方面，看了這點半新的，就算"洪水猛獸"一樣了。又不能用正當的辯論法來干涉了，國務院來干涉了，甚而什麼參議院也來干涉了，世界哪有這種不自由的大學麼？還要我去充這種大學的校長麼？

（三）我絕對不能再到北京的學校任校長：北京是個臭蟲窠。無論何等高尚的人物，無論何等高尚的事業，一到北京，便都染了點臭蟲的氣味。我已經染了兩年有半了，好容易逃到故鄉的西湖、鑑湖，把那個臭氣味淘洗乾淨了。難道還要我再作逐臭之夫，再去嚐嚐這氣味麼？

我想有人見了我這一段的話，一定要把’我不入地獄，誰入地獄’的話來勸勉我。但是我現在實在沒有到佛說這句話的時候的程度，所以只好謹謝不敏了。

附：愛蔡孑民者啟

右宣言聞尚是蔡君初出京時所草，到上海後，本擬即行宣佈，後因北京挽留之電，有友人勸其婉復，免致以個人去留問題與學生所爭政治問題，永結不解之緣，故有以條件的允任維持之電，後來又有臥病不行之電，均未將真意說出。聞其意，無論如何，決不回校也。鄙人抄得此宣言書，覺與北京各報所載啟事，及津浦車站告友之言，均相符合，必是祭君本意。個人意志自由，本不可以多數壓制之，且為社會上留此一個乾淨人，使不與政治問題發生關係，亦是好事。故特為宣佈，以備挽留蔡君者之參考焉。愛蔡孑民者啟

據蔡元培手稿

選自《蔡元培全集》第3卷，中華書局1984年版

另附《蔡元培先生任北京大學校長之就職演說》

五年前，嚴幾道先生為本校校長時，餘方服務教育部，開學日曾有所貢獻於學校。諸君多自預科畢業而來，想必聞知。士別三日，刮目相見，況時閱數載，諸君較昔當為長足之進步矣。予今長斯校，請以三事為諸君告：

一曰抱定宗旨。諸君來此求學，必有一定宗旨，欲求宗旨之正大與否，必先知大學之性質。今人肄業專門學校，學成任事，此固勢所必然。而在大學則不然，大學者，研究高深學問者也。外人每指摘本校之腐敗，以求學於此者，皆有做官發財思想，故畢業預科者，多入法科，入文科者甚少，入理科者尤少，蓋以法科為幹祿之終南捷徑也。因做官心熱，對於教員，則不問其學問之淺深，惟問其官階之大小。官階大者，特別歡迎，蓋為將來畢業有人提攜也。現在我國精於政法者，多入政界，專任教授者甚少，故聘請教員，不得不聘請兼職之人，亦屬不得已之舉。究之外人指摘之當否，姑不具論，然弭謗莫如自修，人譏我腐敗，問心無愧，於我何懼？果欲達其做官發財之目的，則北京不少專門學校，入法科者儘可肄業於法律學堂，入商科者亦可投考商業學校，又何必來此大學？所以諸君須抱定宗旨，為求學而來，入法科者，非為做官；入商科者，非為致富。宗旨既定，自趨正軌，諸君肄業於此，或三年，或四年，時間不為不多，苟能愛惜分陰，孜孜求學，則求造詣，容有底止。若徒志在做官發財，宗旨既乖，趨向自異。平時則放蕩冶遊，考試則熟讀講義，不問學問之有無，惟爭分數之多寡；試驗既終，書籍束之高閣，毫不過問，敷衍三、四年，潦草塞責，文憑到手，即可藉此活動於社會，豈非與求學初衷大相背馳乎？光陰虛度，學問毫無，是自誤也。且辛亥之役，吾人之所以革命，因清廷官吏之腐敗。即在今日，吾人對於當軸多不滿意，亦以其道德淪喪。今諸君苟不於此時植其基，勤其學，則將來萬一因生計所迫，出而仕事，但任講席，則必貽誤學生；置身政界，則必貽誤國家。是誤人也。誤已誤人，又豈本心所願乎？故宗旨不可以不正大。此餘所希望於諸君者一也。

二曰砥礪德行。方今風俗日偷，道德淪喪，北京社會，尤為惡劣，敗德毀行之事，觸目皆是，非根基深固，鮮不為流俗所染。諸君肄業大學，當能束身自愛。然國家之興替，視風俗之厚薄。流俗如此，前途何堪設想。故必有卓絕之士，以?身作則，力矯頹俗，諸君為大學學生，地位甚高，肩此重任，責無旁貸，故諸君不惟思所以感已，更必有以勵人。苟德之不修，學之不講，同乎流俗，合乎汙世，已且為人輕侮，更何足以感人。然諸君終日伏首案前，芸芸攻苦，毫無娛樂之事，必感身體上之苦痛。為諸君計，莫如以正當之娛樂，易不正當之娛樂，庶幾道德無虧，而於身體有益。諸君入分科時，曾填寫願書，遵守本校規則，苟中道而違之，豈非與原始之意相反乎？故品行不可以不謹嚴。此餘所希望於諸君者二也。

三曰敬愛師友。教員之教授，職員之任務，皆以圖諸君求學便利，諸君能無動於衷乎？自應以誠相待，敬禮有加。至於同學共處一室，尤應互相親愛，庶可收切磋之效。不惟開誠佈公，更宜道義相勗，蓋同處此校，譭譽共之。同學中苟道德有虧，行有不正，為社會所訾詈，已雖規行矩步，亦莫能辨，此所以必互相勸勉也。餘在德國，每至店肆購買物品，店主殷勤款待，付價接物，互相稱謝，此雖小節，然亦交際所必需，常人如此，況堂堂大學生乎？對於師友之敬愛，此餘所希望於諸君者三也。

餘到校視事僅數日，校事多未詳悉，茲所計劃者二事：一曰改良講義。諸君既研究高深學問，自與中學、高等不同，不惟恃教員講授，尤賴一已潛修。以後所印講義，只列綱要，細微末節，以及精旨奧義，或講師口授，或自行參考，以期學有心得，能裨實用。二曰添購書籍。本校圖書館書籍雖多，新出者甚少，苟不廣為購辦，必不足供學生之參考。刻擬籌集款項，多購新書，將來典籍滿架，自可旁稽博採，無虞缺乏矣。今日所與諸君陳說者只此，以後會晤日長，隨時再為商榷可也。

蔡元培 1917年4月

Mono 環境下跟蹤和優化 .NET 程序內存分配

Mon, 09 Dec 2013 16:40:59 +0000

.NET 程序在 Mono 環境之下的內存分配和在 Microsoft .NET Framework 環境是不太相同的，雖然它們的兼容性很高，但仍有區別。尤其是在 GC 方面，Mono 的 GC 實現似乎仍有不足（在 3.0.6 版本下），據我觀察，有一些大對象（估計是二代對象，譬如很大的 byte[] 數組）的釋放仍然有些問題。下面就以 TCP 服務器端程序為例。

場景

假設在服務器端有這樣的語句，用來備份 SQLite 數據庫文件：

private void BackupDB(string dest)
{
 byte[] content = getAllContent(this.DBFile);
 File.WriteAllBytes(dest, Zip.Compress(content));
 content = null;
}

private byte[] getAllContent(string path)
{
 try
 {
 byte[] b;
 using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
 {
 b = new byte[fs.Length];
 fs.Read(b, 0, b.Length);
 }
 return b;
 }
 catch
 {
 throw new Exception("數據庫正在讀寫，請稍後再備份。");
 }
}

備份數據庫需要讀取整個數據庫。這段代碼直接將整個數據庫的本地文件鏡像讀出，並放在了一個 Byte[] 數組之中，作為 getAllContent 函數的返回值。在讀取之後， getAllContent 方法的 b 中存儲了大量的字節。另外，在 BackupDB 函數中，使用 Zip.Compress 函數壓縮數據庫後，也會返回一個較大的 byte[] 數組。

經過測試，這段代碼在 Windows 的 .NET Framework 平臺下工作沒有問題。因為這些大對象可以幾乎在使用後即刻被銷燬。但是，在 Mono 下，即使在代碼的最後顯式調用 GC.Collect() 方法進行全代垃圾回收，也無法減少內存。

使用 Profiler 跟蹤內存分配和垃圾回收

雖然我們可能不知道原因出在哪裡，但是我們可以通過 Mono 自帶的工具來跟蹤內存分配。這裡用到的工具是 Profiler，這個工具只支持 Mono 2.9+，如果你使用的發行版過於穩定，可能需要安裝測試版本的 Mono 或手工編譯安裝 Mono 才可以使用這個工具。

Profiler 特別像在 Visual Studio 中的「性能分析」工具。它們的原理也大同小異。它們都是通過運行時採樣和日誌，來跟蹤程序運行的狀態。

具體來說，Profiler 會在託管程序運行時記錄這些內容：

方法進入和退出
對象分配
垃圾回收
JIT 編譯
元數據加載
鎖上下文
異常

另外，它還提供了堆快照的功能，可以在你的程序進行過一次垃圾回收之後，記錄下目前託管堆的情況。

使用 Profile 日誌

要使用 Profiler 進行分析，首先要以附加參數啟動 Mono 代碼：

mono –profile=log program.exe

在程序運行結束後，在當前目錄下會生成一個 output.mlpd 文件。這個文件稍後可以被用來做性能分析。在程序運行結束之後，輸入命令

mprof-report output.mlpd

會生成分析報告。

你也可以使用一些參數，常用參數有

mono –profile=log:report program.exe

這樣可以不保留日誌，而是直接產生分析報告，有時候這可能很有用，因為日誌文件實在是太大了。

mono –profile=log:noalloc program.exe

noalloc 會導致日誌中不記錄分配情況。

mono –profile=log:nocalls program.exe

nocalls 不記錄調用方法。如果不使用 nocalls，要預留足夠大的硬盤空間。在我的實驗中，幾分鐘產生了 500MB 甚至 2GB 的數據（即使取消一些日誌，文件仍然很大）。

mono –gc=sgen –profile=log:heapshot program.exe

這可以記錄託管堆的快照。

mono –profile=log:sample program.exe

CPU 採樣，和 .NET 自帶的特別像，通過一般不超過 10% 的性能損耗，在運行時動態採樣，以便獲取關於 CPU 時間消耗在什麼運算中的第一手資料。

分析日誌

現在我們開始分析日誌，輸入命令

mprof-report output.mlpd

即可看到結果。

詳細的 Mono Profiler 使用方法請參考它的官方文檔。

兩處優化

使用 Stream 代替 byte[]

如果可能，在操作大量 byte[] 數據的地方，考慮使用 Stream 對象。比如，如果你使用 FileStream 操作大文件，你將不需要將文件性一次讀入內存。進行此項優化成功節約了 20% 的內存。但是要注意：

確保 Stream 的回收，儘可能使用 using 關鍵字來管理 Stream 的釋放
如果你使用的是 MemoryStream，其內部實現其實是一個動態變長的 byte[] 數組，當它增長到最大的時候，文件仍然是完全放在了內存之中。
最重要的是，你對數據的處理必須是流式的，如果你只是把 FileStream 分塊讀入到一個 byte[]，DataTable，MemoryStream 等中並作為參數進行某種操作（比如壓縮，如上述代碼中的 Zip.Compress(byte[] 對象)），那麼你仍然無法節約內存。你必須確保你對流的操作是分塊流式進行的。

壓縮是典型的非流式操作，因為壓縮算法幾乎都是基於上下文的，而不只是當前位置。

使用外部命令代替大內存操作

編寫另外一個可執行文件，這個文件不能是 dll，so 等模塊，保證其內存空間的獨立，然後將耗費內存的操作放在這個程序中，將數據的位置作為參數。好處是這個程序處完數據會退出，所有資源得到了充分的釋放。

為什麼不使用 GC.Collect()

GC.Collect() 進行全代垃圾回收，暫停所有線程的運行，而且資源消耗大，對於對速度要求高的程序（比如服務器端程序）不太合適
GC 未必可以正確的回收所有垃圾（如本文代碼在 Mono 環境下就無法正常回收）
外置程序可以在多核計算機中和原服務器中並行執行，因為數據處理很多時候是高 IO 操作，不會卡住服務器程序，邏輯簡單性能又高

通過弱引用（WeekReference）管理緩存

這並不是標準庫推薦的做法，但是如果你想簡單的防止程序緩存佔用過多的資源，可以使用它。詳細介紹可以移步 MSDN。

VirtualBox Code CO_E_SERVER_EXEC_FAILURE Server execution failed 解決辦法

Wed, 04 Dec 2013 22:45:39 +0000

問題描述

如果你在使用 VirtualBox 的命令行 VBoxManage 創建虛擬磁盤指向物理磁盤，那麼你可能會使用類似這樣的語法：

VBoxManage internalcommands createrawvmdk -filename "C:\Users\my\usb30.vmdk" -rawdisk "\\.\PhysicalDrive1"

其中，filename 代表的是虛擬磁盤名稱，rawdisk 代表的是對應的物理磁盤，PhysicalDrive1 代表的是第二塊物理磁盤（通常是移動硬盤），請不要搞錯了，直接複製來用。

此時（在 Windows 平臺下），你可能會得到這樣的錯誤輸出。

VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server execution failed (extended info not available)

解決方法

解決方法只是把每個參數加上引號，很無語，因為其實並沒有空格等字符，但仍然需要加上引號，而且錯誤信號驢頭不對馬嘴。

例如：

VBoxManage internalcommands createrawvmdk -filename “C:\Users\my\usb30.vmdk” -rawdisk “\.\PhysicalDrive1”

輸出：

RAW host disk access VMDK file C:\Users\my\usb30.vmdk created successfully.

另，如果你執行 VBoxManage 遇到 Access Denied 等錯誤，請用管理員權限打開 cmd。

參考資料

http://wishuwell.blog.163.com/blog/static/182950146201332892928812/ VirtualBox中引導usb啟動盤
http://blog.sina.com.cn/s/blog_7d0164e301011d10.html VirtualBox直接使用物理硬盤作虛擬機磁盤

在 Debian Wheely (6.0) 下安裝 testing mono 軟件包

Tue, 03 Dec 2013 08:09:26 +0000

在 /etc/apt/sources.list.d/下建立一個 testing.list 文件，內容為

deb http://ftp.cn.debian.org/debian testing main

然後執行

apt-get update

apt-get -t testing install 包名

即可。

PHP 獲取 EXIF 信息時中文編碼問題

Sun, 01 Dec 2013 20:47:05 +0000

在 Windows 中編輯的 EXIF 信息（指的是資源管理器之中編輯的）默認存儲為 Unicode，但是

Unicode 編碼並不等於 UTF-8 編碼。

所以，在 PHP 中進行如下轉換：

iconv(“unicode”, “utf8”, xxxxx);

Ceeji 篤志者 - 宁心勉学，慎思笃行

紹興之旅（4）：陽明故里、沈園與書聖故里

此心光明——陽明故里

沈園

書聖故里

紹興之旅（3）：蘭亭景區、印山越國王陵、八字橋周邊與沈園之夜

蘭亭景區

印山越國王陵

八字橋周邊

沈園之夜

結合 TextRank 與 TF-IDF 更精準的提取文章關鍵詞

紹興之旅（2）：會稽山兜率天、倉橋直街與魯迅故居

會稽山兜率天

魯迅故里附近

倉橋直街

國內 AI 應用創業為何舉步維艱？國內 AI 創業者的出路何在？

為了造車，拋妻棄子？還有多少老婆孩子要被犧牲？

1

2

正確實現根據使用者偏好自動切換網頁中文簡繁版本

紹興之旅（1）：羊山石境與柯橋古鎮

羊山石境

柯橋古鎮

Grub Filter Not Found 修復：系統升級後的引導修復

症狀

原因分析

方法一：雲盤掛載在救援主機

方法二：手工引導系統

自動更新阿里雲的 CDN HTTPS 證書

開源地址

使用說明

本站從 Wordpress 遷移到 Hugo

緣由

關鍵步驟

從 Wordpress 備份提取 Markdown

使用腳本處理多餘的轉義

移除不必要的 TOC（文章目錄）

自動翻譯簡體中文到繁體中文（或相反）

手工檢查所有文章

選擇合適的評論系統

從 Wordpress 評論遷移到 Waline

實現代碼高亮的黑暗模式自適應

簡繁中文使用相同的評論數據，並自動翻譯

重定向 Feed（Rss/Atom）訂閱地址

圖片管理

智繪童話

假如杭州保留了南宋古建築…

使用ChineseGenie學習中文

無法在阿里雲控制檯被使用的 CSI 插件特性：動態 NAS 存儲池

HTML disabled 屬性的一個坑

C# 與 Java 語言機制與語法的異同

命名規範

那些簡單的同義詞或近義詞

值類型與裝箱

泛型

委託，事件

為什麼要從 C# 轉為 Java：淺談 .NET 與 Java 生態

統一開發平臺，重用現有資產

減少技術風險，方便技術學習

減少開支

基於 Java 開發將擁抱更廣泛的生態

從 C# 到 Java：總目錄

引言

總目錄

近期遇到的幾個佈局兼容性彙總

flex 可伸縮元素比例不正確（Android 4.0 - 4.3，iOS 低版本）

Javascript 中的 undefined 與 未定義（not defined）

undefined

一個聲明但沒有賦值的變量為 undefined

一個不存在的對象成員為 undefined

一個手工賦值的 undefined

未定義（not defined）

iPhone 手機QQ 4.7.2 版本網絡狀態洩露用戶隱私

宋卿體育館與六一慘案

Nginx 無法處理軟鏈接作為網站主目錄的情況

甲午年，至關重要的使命

蔡元培不肯再任北大校長的宣言

（1919年6月15日）

附：愛蔡孑民者啟

另附《蔡元培先生任北京大學校長之就職演說》

Javascript 中的 undefined 與未定義（not defined）