.NET 非對稱式加密與數位簽章程式設計入門

11/11/2007
這篇文章介紹了 .NET 非對稱式加密與數位簽章的一些基本概念,並提供了範例程式。

書摘:《知識的騙局》

9/20/2007

中文書名:知識的騙局
英文書名:Fashionable Nonsense
作者:Alan Sokal, Jean Bicmont
翻譯:蔡佩君


翻譯這本書想必極為不易,其難度一部份來自於內容本身所涉及的專業知識領域,一部分則來自引用其他學者在其論述中使用的晦澀詞句。即使翻譯成中文,許多詞句對於像我這種未接觸過相關領域(精神分析、科學哲學、知識論、後現代主義、相對主義等等)的人來說,閱讀起來還是有些吃力,目光老是在同一個段落的文字間反覆遊走,試圖捕捉看似毫無關聯的詞彙之間組合起來的意義。在沒有原文對照的情況下,有時也不易分辨究竟是原文就這麼難懂,還是因為翻譯成另一種語言的緣故(除了那些帶有特定科學術語的敘述,這些肯定是我自己的專業素養不足)。不過,還是有極少數明顯是中文語句不通的情形,例如第五章開頭的第一句:「路希‧伊莉嘉萊的著作處理的很廣泛主題,從精神分析、語言學到科學哲學。」

這本書我只認真看了前面兩章,到後面我的腦袋已經被各種科學術語和理論搞得頭昏腦脹,無法保持閱讀的興趣了。因此,以下的書摘僅包含前面兩章的部分。

========================================
ch01: 導言

我們必須強調,不懂微積分或量子力學並不是可恥的事。我們所要批判的是某些著名知識分子的虛矯,假裝能未他們所瞭解的複雜主題提供深刻的思考,但他們的瞭解頂多只是在通俗的層面。 (p.13)

不論是物理學、生物學、或社會科學,以象徵符號或公式來包裝半調子的理論(half-firnykated theory),於事無補。

注:以上點出了作者撰寫本書的動機,以及對學術道德的看法。

任何一種介入的(intervention)的知識價值,是由其內容所決定,而不是由發言者的身分,更不是他的文憑。 (p.18)

注:「介入的(intervention)的知識價值」?


......一般說來,一個領域的實質知識愈豐富的話,對文憑的關心就愈低,而對內容的關心也愈高,這樣說似乎是公平的。 (p.19, 註11)

注:當我們看到一篇立論精妙的文章,對作者大感佩服時,如果有人告訴你,作者在該領域並沒有碩士、博士的文憑或顯赫的頭銜時,是否會立刻減損你對他的評價?甚至開始質疑,作者有什麼資格談論些主題?


ch02: 雅克‧拉岡

拉岡對數學的偏好,在他的作品中絕非無足輕重。1950 年代時,他的書寫中就滿是圖表、公式、和「算式」。為了加以說明,讓我們摘錄 1959 年講座中的一段:

『我在寫註解的時候腦中出現一些公式,如果你們允許我使用其中之一--人的生命可以定義為一個微積分,其中零是無理數(irrational number)。......』

在這段引文中,拉岡將無理數和虛數混淆,還宣稱是「確實的」。 (p.31)

注:論文是否一定要有密密麻麻的數學公式和眼花撩亂的圖表,才稱得上好論文?不過,拉岡把人生定義(應該只能說類比吧)為一個微積分的創舉,就個人膚淺的觀點來看,卻再合理不過--我恐怕永遠都搞不懂人生,就像我永遠都搞不懂微積分。(彷彿又聽見吾友 Twgif 對我說:「這就是人參。」Ick!


......但在兩頁之後,拉岡回到同樣的主題:

『......這就是為什麼我冒著招來輕蔑眼光的風險,指出我在使用數學算式時將之扭曲到什麼程度:根號負1 的符號--在複數理論中仍被寫成「i」--顯然只是因為它在後來的用法中沒有主張自動性,因而擁有正當性。
......
因此,豎立起來的器官變成象徵快感的地方,不是在它自身,或甚至在一個意向的形式上,而是作為在欲求意象中匱缺的一部分:那就是為什麼它等同於上面所產生的表意過程的根號負1,快感的根號負1,是它藉由它的陳述對於意符(-1)匱缺之函數的係數而回復的。』(拉岡 1977b,317-320 頁)

坦白說,看到我們豎立起來的器官等於根號負1,實在令人苦惱。 (p.33)

注:雖然我看不懂拉岡這段話在講什麼,但是「快感的根號負1」,還真是一整個歡樂啊!無厘頭的程度恐怕連周星馳也自嘆不如。作者對拉岡這段話的評論,也頗令人莞爾。


長久以來,拉岡的書寫愈趨神秘--這是許多宗教聖典的共同特色--結合了文字遊戲和破碎的文法,好讓他的門徒虔誠地做註經的工作,恰好適合作為基礎。人們或許會想知道,究竟我們面對的,是不是一種新的宗教。 (p.47)

注:為了塑造自己擁有博大精深學問的形象,論文變成造神的工具,而許多信徒也努力試圖解釋那些看似謎團、夢囈般的論述。此時,科學竟成了另一種形式的宗教信仰,甚至迷信。

==========================================

有些人真正發現了一些東西,並將他的發現寫成論文;有些人以為他發現了一些東西。而其他人,或許只是企圖說服別人他真的發現了一些東西?

專業術語一定要翻譯成中文嗎?

8/06/2007
上回寫了一篇關於 property 和 attribute 如何翻譯的問題,這次要記錄的則是自己在翻譯時碰到的另一個問題:專業術語是否一定要翻譯成中文?

一般來說,翻譯專業術語有個通則,即第一次碰到時採用中英並陳的方式呈現,例如:設計模式(design patterns)。往後再碰到就一律直接以中文表達,不再列出原文。

但有些術語用中文表達時會覺得很生硬(個人主觀上認定),例如:session、callback、code-behind....等。對這些術語,我在翻譯時則傾向採用不同的處理方式,也就是第一次碰到時採中英或英中並陳,例如:「callback(回呼)」,往後再碰到時則一律只寫英文。因此,剛才舉的幾個例子,實際上第一次碰到時可能會這麼寫:

session(工作階段)
callback(回呼)
code-behind(程式碼後置)

記得之前曾與幾位朋友討論過類似的問題,彼此各有不同的看法。有的認為,既然是中文版,當然要負起翻譯的責任,盡量讓讀者看中文,否則難免有不用功、偷懶的嫌疑(喂!我花錢買中文版就是要看中文哪...)。

而我個人是比較在意大家平時是怎麼溝通的,閱讀時是否順暢,以及會不會造成誤解。至於是否要 100% 譯成中文,個人倒覺得其次,尤其是 IT 類的書籍。也就是說,哪一種方式讀起來順,就用哪一種--當然啦,這仍脫離不了個人的主觀想法及先入為主的習慣

IT 類的書籍中,很多術語在實際溝通時仍然是以英文為主,例如:瀏覽器的 "cookie",在溝通時很少聽人說:「小餅乾」(除了帶點開玩笑的、非正式場合的討論)。雖然翻譯書籍的本意就是要讓讀者更快吸收原文書的內容,可是有些術語用中文講就硬是覺得怪怪的,甚至可能造成誤解,或令讀者在閱讀時再翻譯回原文(有時還得用猜的),這樣反而失去了翻譯的本意。

要採用哪一種表達方式,恐怕還是見仁見智的問題,每個作者/譯者心中自有定見吧。因此,在翻譯時只好依照自己平日接觸的、以及個人習慣的方式來做主觀上的考量了(當然也還得看編輯大人是否同意)。


後記(2008-5-16):

朱子兄也對此議題發表了更深入的看法,文章的網址是 http://thoughspace.blogspot.com/2008/04/blog-post_10.html


如何翻譯 Property、Attribute 才適當?

7/27/2007
手邊正在翻譯的書籍裡面,property 和 attribute 的出現頻率很高,對翻譯的人來說實在是一項困擾,因為這兩個術語一般都是譯為「屬性」。

舉例來說,提到類別的屬性,這裡用的英文是 property;提到 HTML/XML 的元素屬性,用的則是 attribute。在討論不同主題時,讀者可能很容易辨認中文的屬性指的是 property 還是 attribute,可是如果碰到兩個字同時出現的段落,就有點麻煩了,例如:

「簡言之,ScriptPath 屬性讓你可以從指定的路徑載入外部指令碼檔案,而 Path 屬性則能夠蓋過全域的 ScriptPath 設定,以指定個別的指令碼參考路徑。」

其中的 ScriptPath 和 Path,一個是類別的 property,一個是 ASP.NET 標記的 attribute,如果不明白標示原文,恐怕很難避免讀者誤解。這樣好多了:

「簡言之,ScriptPath 屬性(property)讓你可以從指定的路徑載入外部指令碼檔案,而 Path 屬性(attribute)則能夠蓋過全域的 ScriptPath 設定,以指定個別的指令碼參考路徑。」

但問題不只如此,另一個更讓人頭疼的,是 .NET 的 attribute 語法(微軟線上文件也將它翻譯為「屬性」),以下是個 C# 語言的範例:

namespace Huanlin.WebServices
{
[ScriptService]
public class BookService : System.Web.Services.WebService, IBookService
{
...
}
}

其中的 ScriptService 就是 attribute,如果同一個段落中同時提到 HTML/XML 標記的 attribute 和 .NET attribute,翻譯時就更頭大了,若不適時加注,放眼望去全是一堆屬性,讀者不頭暈也難。

一種方式是碰到 .NET attribute 語法時就維持原文,這是我個人比較喜歡的方式。另一種方式是將 attribute 語法也翻譯成屬性,再以括弧加注,如:屬性(attribute),個人覺得這樣不僅囉唆,對讀者也沒有太大的幫助。也曾經看過有人把它翻譯成「特徵項」,個人也覺得是不錯的辦法。在翻譯時,我可能會採用「特徵項」吧!

技術提供:Blogger.