STOP USING WINDOWS NOTEPAD!



贊助商連結


琥珀
2010-08-06, 06:06 PM
Why are UTF-8 encoded Unix shell scripts *ever* written or edited in Notepad? (http://blogs.msdn.com/b/michkap/archive/2008/03/11/8152232.aspx)
The game is over, people! (http://blogs.msdn.com/b/michkap/archive/2010/02/23/9967789.aspx)

雖然是老問題,不過值得回味。


看完之後,請一起說:

STOP USING WINDOWS NOTEPAD!
STOP USING WINDOWS NOTEPAD!
STOP USING WINDOWS NOTEPAD!

遊戲結束。


說不定自己是被虐狂,因為十多年來,常會用到記事本。看完文章和評論,覺得很好笑 (可笑しいね)。

贊助商連結


tvirus
2010-08-06, 07:55 PM
notepad對我而言的最大問題:BOM
所以,我在unix上用mc,Windows下用Madedit

lenbo
2010-08-06, 09:42 PM
notepad對我而言的最大問題:BOM
所以,我在unix上用mc,Windows下用Madedit

很久沒用過 Notepad 了…
因為開啟時沒辦法 reload 正確的編碼。

Unix-like 下我都用 vim
Windows 下目前是用 EmEditor

ellery
2010-08-06, 10:29 PM
Windows 下目前是用 EmEditor

emeditor不錯用, 可是個人覺得有兩個缺點:

1. 分頁視窗沒辦法打散或是兩個併排(類似一些可比較兩檔案的軟體), 檔案要對照看要切來切去的.
2. 文字加色功能無法對應VB .Net, 只有VBscript

noeleon930
2010-08-08, 05:37 PM
但由於方便性,這個習慣很難改掉呢~~

門神
2010-08-09, 09:01 AM
可以使用Notepad ++
台灣之光

http://notepad-plus-plus.org/tw/node/8

algolee
2010-08-09, 12:19 PM
我還是用的很高興

完全不知道現在發生啥事 ........

noeleon930
2010-08-09, 06:10 PM
我還是用的很高興

完全不知道現在發生啥事 ........

是呀~
我都不曾遇過這樣的問題,因為沒有這樣用過?

dmwc
2010-08-21, 03:28 PM
他們的問題只是 UTF-8 BOM 問題,在 UTF-8 時 BOM 是不需要的,但在 Windows 絕大多數軟體,他會把 UTF-8 加 BOM

在Windows 上,絕大多數軟體有沒有 BOM 都無所謂(但存檔會自動加料),但在 Unix 上加 BOM 是不行的

所以無論你用啥編輯器,沒有此觀念也沒用,這問題根本就不是 Notepad 的問題

琥珀
2010-08-28, 03:06 PM
相關連結的其中一段敘述,覺得應該要提出來解釋。


As for whether plain text files can have a BOM, that is one of the few unending debates that arise with certain (fortunately not too frequent) regularity, each time with vociferous expressions of deeply-held beliefs but never any resolution. I'll just observe that the formal grammar for XML does not make reference to a BOM, yet the XML spec certainly assumes that a well-formed XML document may begin with a UTF-8 BOM (or a BOM in any Unicode encoding form/scheme). Rather than have a philosophical debate about the definition of "plain text file", I suggest a more pragmatic approach: for better or worse, plain text processes that support UTF-8 are going to encounter UTF-8 data beginning with a BOM: learn to live with it!

Linux 系統不喜歡那 3 個位元組,難道是錯誤?當然沒有錯,因為知道 UTF-8 沒有字節序 (byte order) 的問題,認為必定比 UTF-16 更具有優勢,同時也方便進行 ANSI / ASCII 補完計畫,變成 UTF-8 架構。

Windows 系統需要那 3 個位元組,難道是錯誤?當然也沒有錯,因為微軟打從一開始就不採用 UTF-8 當底層,而且要兼顧 UTF-16 LE/BE、UTF-8、ANSI 這些編碼。

使用文字編輯器開啟一個文字文件,想要知道其使用的編碼,都是要靠「特徵」決定,基本上沒有「智慧」這種事情。作業系統或文字處理程式,以嚴格的標準來說,沒有義務具備自動偵測語系編碼的功能,反正就只看 BOM 標記來決定,沒有標記就一律當作 ANSI (非統一碼) 文件來處理和顯示,如此而已。

無論是基於個人喜好、工作需要、「它就是那樣」的理由,琥珀認為有件事情比起這個更為重要,也就是上面提到的,學會共生共存。有了這個基礎,遇到什麼樣的難題都不怕,只怕不願意去做,或是想沿用幾十年的成見或傳統,認為「這樣做就是不對」、「這樣是違反標準」。



Change! / チェンジ! / 改變唄!

應該是要改變的時候了。如果汝有 BOM 的困擾,能力所及之下,就努力向該作業系統的社群/論壇表達訴求,希望未來可以支援那 3 個位元組,儘管這種問題的回應,通常都是「非咱們的問題」或類似的批評語句,不過還是感謝付出這一份心力。

如果汝是賢狼,應該可以理解咱之前所說的話。與之共生共存,聽起來好像很容易,想要真正做到,還有一段艱辛的路要走。如果汝無法認同,只能說汝跟咱是兩個不同世界的人唄?