han3_ji7_tsoo1_kian3
han3_ji7_tsoo1_kian3 copied to clipboard
sih4sing5hong5
維基主機無法顯示漢字
Debian
uname -a
3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
locale: LANG=en_US.UTF-8
locale全部都是 en_US.UTF-8 沒有別的
那邊不管什麼漢字檔名都變成???????
我有和 @MGdesigner 研究過維基的主機 主要是佈署的時候，他們是python 2，無支援漢字檔名 所以現在檔名和內容不相符
要求他們改程式可能沒辦法？ 所以就檔名英文，程式維持華語
他們是python 2，無支援漢字檔名
from __future__ import unicode_literals
能解決大部分問題，雖然這種時候我基本只用 python3 xxxx.py（用 py2 也直接全都指明 b'位元組串' 和 u'字串'）了。
回覆兩位，現在組字的測試server在tools.wmflabs.org 上。啟動關閉各種server服務的，是主機上的網路服務管理script webservice。他就是一個script 開頭是#!/usr/bin/python 例如說，這樣可以啟動tomcat: webservice tomcat start
狀況是那個script的擁有者是root，我有執行權限但沒有修改權限，tools.wmflabs.org 是很多人共用這個server去跑各種測試服務與實驗，我不是山老大。test wiki的server則是另外一個server上的dock（還是虛擬機？），我才在那裡可以當山老大，可以改一點點系統等等
說回來，我認為，在主機部署上，也是要考慮這種問題-不是每一種佈署你都可以當山老大，可以自由sudo，自己擁有主機裡面的一切。尤其是一些組織擁有的伺服器甚至是大型的雲端，可能是更常見的佈署標的，而系統服務可能是比較舊的，如果要讓一個服務在上面可以正式地營運，這樣的話維持英文檔名還是比較通用而保險的。
@MGdesigner 我們不是要root去改設定 是他的佈署程式有unicode的bug
我們要做的不是跟他要sudo，而是要修這個bug 修bug跟老大不老大沒什麼太大的關係
你那邊可以問問他們佈署的程式可以從哪邊pull request過去嗎？ 對這個專案長期來說是有幫助的
1.這個專案最後會離開 tools.wmflabs.org（實驗室），會到另外正式的主機上，而兩邊的管理就我目前所知不太一樣（實驗主機上面很多ugly的東西） 2. 如果只是希望改善 tools.wmflabs.org 佈署程式的這個bug，我目前判斷成本不太划算。比方說本來我在上面一開始也是想要jetty獨立模式執行，他要跑起來得用另外一個script體系來啟動（更ugly），當時遇到其他的問題（而且還很難描述問題），所以改用tomcat
簡單說，那個實驗server很多東西很ugly，我認為要在進入Official的主機時，才來作這樣的事情比較適當。
PS.所謂的「成本」包含溝通的成本， 包含找到可以處理的人。其實今年上半年維基基金會的工程師們士氣很低落，人力吃緊，還有大退潮（跟這事件有關 ），一開始甚至tomcat也有「洞」，不能跑，爬了一個小時認真看了大文件結果還不能動....那時我是去irc找人，對方花了幾天，去翻離職員工的資料才把文件裡面提到的script幫我hack回來（或者是重新實作改另外一個作法，我有點忘記，而且還是托我們理事長去壓一下....）...此外他們不是很喜歡java，要溝通java的容器就蠻辛苦的了。
問題是這樣子/_\
我整理一下可能的做法
- 修
tools.wmflabs.org的bug - class名用英文
- class名用漢字，gradle裡再用程式refactor
謝謝 @MGdesigner 的解釋，1成本沒有想像的低
接下來可能要評估2和3哪個成本比較低
我幫你補充一下，"1."應該是未來的 正式tools server 。行政程序快的話，這服務可能12月就會搬家出去。
我同意 2.或者3都是比較好的，只要在本地端用gradle做好 war檔，佈署到的遠端主機就算不是最理想的，甚至系統層編碼不是unicode編碼（現代不見得就沒有這種主機），只要上面有合乎標準的java應用伺服器，都還是可以運作漢字組建server。
系統層編碼不是unicode編碼（現代不見得就沒有這種主機）
至少沒有這種 Linux 主機……有的話也會被當做是臭蟲的存在啊。
當然事情少點有好處。
java程式跑的主機，未必就是Linux主機，如果一個軟體service可以擴散的廣，應該還是比較好的，撇開我遇到維基基金會主機這個特定狀況，我認為，針對他特定解決問題，只是解決了一個單一case。比較重要的，還是要考量通用的狀況，所以 2跟3都是好方法。
而即使是Linux，現在還是可以因為某種理由（相容性之類）「續用」某種傳統編碼。這不是沒有，尤其會應用缺字處理領域的單位，比較會容易遇到這種case（通常比較守舊，有長年的包袱，甚至IT技術有點..過時，但依然可靠），依然使用大型主機例如Solaris之類的，也不是沒有（我就不清處Solaris系統用什麼編碼了）。
所以我認為在JAVA內程式原碼內，我們用unicode沒問題。JAVA外的檔案系統層，最終編好的binary還有其他檔案的檔名最好還是英文命名，最保險。可以保證這個軟體service在不修改的狀況，build 1 time, run everywhere。
而即使是Linux，現在還是可以因為某種理由（相容性之類）「續用」某種傳統編碼。……Solaris
UTF-8 就是 Linux 的傳統編碼呀。當時（1992）Ken Thompson 搞出來這樣一個和 ASCII 相容但又有位元組範圍隔離的東西，就是為了各種舊程式能繼續運作。
真正有問題的是 C 這個 locale，POSIX 只要求支援到 ASCII 字元，而 glibc 對此實作也是特別做了個縮減到只有 ASCII 的 locale。好在大家都用 .UTF-8 的。
JAVA外的檔案系統層
其實要有問題的話可能反而是 macOS 這種 Unicode 正規化和別人不一樣的東西，好在漢字也沒什麼 combining character。還有就是原始碼的檔名到時候也是被 jar 進去算作 Java 的事情了，如果 Java 還不支援就是 Java 的問題了……
UTF-8 就是 Linux 的傳統編碼呀。當時（1992）Ken Thompson 搞出來這樣一個和 ASCII 相容但又有位元組範圍隔離的東西，就是為了各種舊程式能繼續運作。
不是，Linux 處理UTF-8是中期以後，2000年左右我第一個使用的Linux系統是Redhat6.2+CLE 那時的中文Linux 的系統內碼在台灣就是設BIG-5，其他國家就是各自設各自的，不是後來更方便的utf-8。
jar 進去算作 Java 的事情了，如果 Java 還不支援就是 Java 的問題了……
Java應用伺服器不是用 jar，是用war。war的使用跟jar不一樣，jar使用時不會被解開，但是war在佈署到Java應用伺服器時，例如tomcat，這個war會被解壓縮開來用（不同的Java應用伺服器行為可能不同）。這裡就有一個額外的"but" ，解壓縮是用unzip，只是不知道是用那一種"unzip"機制，會不會有這個問題
解壓縮是用unzip，只是不知道是用那一種"unzip"機制
war 是一種 .jar 檔，用的 unzip 是 jar -xvf 那種：
War: What's it Good for?
Web application archive files have the extension .war, which stands for Web application archive. War files are actually jar files (created using the jar utility) saved with an alternate extension.
至於 jar 的檔名編碼定義得是很清楚了。（本來想想也覺得 Oracle 不會順手多造一個 bug）
解包後在 FS 層我相信對於 Windows 會中規中矩地使用 "Unicode" API 直接用 Kernel UTF-16 交流；對於 Linux 應該是 UTF-8 等本地編碼。要壞掉就是臭蟲。
2000年左右我第一個使用的Linux系統是Redhat6.2+CLE 那時的中文Linux 的系統內碼在台灣就是設BIG-5
Big5、GBK 等第二位元組與 ASCII 重疊的多位元組編碼下的 Linux 環境即使是今天也是 Bug 多多，屬於「誰用誰倒楣」。（嗯這個是程式臭蟲——UTF-8 不重合的特性慣壞了開發者，做出了「先剖析再解碼」這種事情。或者說這個程式這部分本身就是按照 ASCII 設計的。）
updated, @MGdesigner 增加了對於 war 使用 jar 檔案格式的引用，以及舊中文 Linux 使用的編碼遇到的一些問題。
原回應：jar -xvf 也是一种 unzip ( （覺得「應該如此」但懶得考證）