http://freebsd.netlab.cse.yzu.edu.tw/~statue/mt/archives/2003_10.html 目前是圖書館書目資料輸出入的格式標準(ISO-2709)， 由文建會國字整理小組負責 整理及編碼維護的中文字集。 圖書館作為書目交換時的中文交換碼傳輸標準。排序方 法是先按康熙字典部首，次按部首外筆劃數， 再按筆順排序，每字以3 bytes 編碼。 目前市面上商品化而廣被各圖書館系統使用的中文內碼， 則為4 bytes，較不適稱之CCCII碼，而應稱如永麒中文碼或昌泰中文碼。 永麒中文碼或昌泰中文碼.....我投降了 找不到轉換方法 有人有辦法解決嗎?

http://ethesys.lib.nsysu.edu.tw/congress_20011228-31/faq.html 北區說明會問題集 Q1: 各校論文轉給國圖之後，對一般使用者開放的範圍為何？ A: 各校論文書目及電子檔皆需轉給國圖，國圖會依據作者授權範圍開放在網路上使用的權限。比如若作者授權為校內立即開放，校外一年後開放，則國圖論文系統會在一年後才開放該論文供下載。 Q2: eThesys透過電子郵件帳號來登入系統，是否需與計中取得技術上的合作？ A: 技術上沒有問題，不需額外的技術支援，惟對於不常使用學校e-mail的學生，常需麻煩計中查詢帳號/密號，仍舊會造成相關人員工作上的負擔，故宜事先溝通為宜。 Q3: 對於各校已建置但不是使用eThesys之數位論文系統，如何達到共建共享的目的？ A: 有兩種做法，第一種是仿eThesys系統轉出同樣XML格式的論文資料給國圖, 第二種方式則是要學生除了上貴校論文系統外，也同時上國圖全國博碩士論文系統登錄資料，當然，學生上兩套系統可能會有怨言，需要溝通。 Q4: 目前eThesys僅提供big5及cccii的2709格式轉出，有沒有計劃作unicode的轉檔？因本校的圖書館自動化系統是用unicode。 A: 短期內並無這樣的計劃。但國家圖書館宋玉顧問專研字碼的轉換，目前已發展出將cccii透過字碼處理程式轉換為unicode，若各校有此需求，可託國圖向宋顧問取得此程式，就可先由eThesys轉成cccii的2709格式，再透過該程式轉成unicode的2709格式檔。惟現在僅止於單方面的轉換，仍舊無法將unicode轉為cccii。 Q5: 有關授權契約書，有無終止日期？ A: 自簽約日起就表示要開始，直到一方提出中止合約。 Q6: 有關授權契約書，第五條第一項如果甲方違約如何處置？同時在合約中並未見到乙方有中止合約的權利。 A: 據合約第七條第四項：甲乙任一方如未遵守任皆屬違約情事，不見得僅保障甲方，同意第八條第三項改為：甲乙雙方皆有權終止合約 Q7: 提供博碩士論文電子檔是否與開放列印功能bundle在一起，可否僅提供電子檔而不允許列印？ A: 全國博碩士論文系統提供電子檔下載、列印的功能，但不允許對pdf檔剪貼編輯；同一系統若是有些文章允許列印，有些不允許列印，很容易讓使用者產生混淆的麻煩，所以希望盡量電子檔一律要開放列印。若實在無法提供列印，可以請其選擇校內公開但校外不公開，且在備註欄裡﹝在eThesys的論文管理功能裡﹞註明該論文不允許列印，如此該論文在國圖系統裡就不會開放，也不會給國圖帶來困擾。 Q8: 如果本校未能在三月及十月提供電子檔轉給全國博碩士論文系統，國圖會如何處理？ A: 訂定三月及十月主要是為了劃分上、下學期之用，並非為了箝制各校，大家不必過份擔心。 Q9: 目前採用ethesys系統的學校可否作跨校論文的查詢？ A: 透過OAI標準應可達成跨校查詢的目的，惟目前尚未決定是否做，因目前透過全國博碩士論文系統集中式查詢亦可達到跨校查詢的效果。 Q10: 在圖書館自動化系統及論文系統若同時收錄博碩士論文，有沒有考慮到重覆存放的問題？ A: 中山大學在webpac及ethesys皆有收錄論文資料，但前者存放的是簡單的書目資料，後者登載的資料較為詳盡，所以可說是以論文系統為主，自動化系統只是方便作館藏的集中式查詢，查到後再透過超連結連到論文系統看更詳細的資料和全文。 Q11: 本校目前尚未有研究生，可否先簽約取得軟體，待日後有畢業生再提供電子檔？ A: 可以。 中區說明會問題集 Q1: 中山是否針對電子博碩士論文編目？ A: 以ethesys ISO2709轉出的編目資料是以紙本館藏需求而設定的書目格式，對電子檔的館藏並未再另行編目。 Q2: 對於電子論文的迅速在網路上傳播的效應，教授若有專利申請的需求，如何顧及智慧財產權的保護？ A: 原作者可以針對時間、地點的限制設定電子檔公開使用的範圍(如: 校內外均一年後公開)，PDF檔亦經過加密設定不允許使用者任意剪貼複製，以保護作者心血的結晶。此外，考量教授對授權範圍的顧慮，系統在核准論文後，也會以email通知指導教授。 Q3: 在過去畢業生簽署授權書需經指導教授的簽名同意以確認其品質，目前以電子檔案的方式如何確認該檔是完整的論文？ A: 系統有一些基本的檢查，如：繳交日期在口試日期之前是不被接受的，當然作者亦可能提供錯誤的資訊，圖書館進行的審核為格式上的檢查，而非內容的審核，我們也教育學生以了解在網路上公開的論文若有任何錯誤，原作者要負完全的責任。 Q4: ethesys論文透過ISO 2709轉入功能進入自動化系統，是直接進入系統或僅提供檔案再由館員轉入？ A: 目前是提供檔案，再由人工用自動化系統的功能轉入。如需直接轉入書目資料庫，自動化系統必須提供開放的程式介面才可達成，本館的INNOPAC系統沒有提供此介面。 Q5: ethesys計劃自88年5月分起實施計劃，但查詢系統收錄年代是從84年開始顯示，中山大學如何處理回溯性的資料？ A: 回溯性資料極少，是因為有早期畢業的校友看了有ethesys系統而願意主動提供電子檔，本館尚未針對過去資料再加建檔。將來也希望國圖能提供該館所收集的本校往年論文資料，使資料完整。 Q6: 中山大學所收之論文如何與國家圖書館的全國博碩士論文作結合？ A: 資料每年會轉給國圖。 Q7: 系統少數功能是以asp撰寫，是否考慮完全採用perl來寫，以使系統建置的環境更為單純？ A: 1.2版前的ASP程式較現在還多，目前僅餘的三支程式都是附屬程式，非核心功能，即使不裝，系統都可正常運作。而且據我們所知，大部分學校圖書館的網頁都以ASP撰寫，所以也就有了裝該三支程式的環境，應該不會造成太大困擾才是。 Q8: pdf檔目前是由館員來做保全，是否考慮由eThesys的介面顯示給學生自行選擇設定？ A: 目前中山仍是由館員逐筆做保全設定加密，市面上亦有付費軟體以程式介面來處理，但該軟體是要付費的，如果我們使用該eThesys採用該程式介面，則移轉給貴校的eThesys，貴校亦需付費，這與我們提供免費軟體的精神不合，而且以本校每年八百餘篇的數量，以人工處理並不會太麻煩。 Q9: 對於一些特殊檔案如何來處理？(例如：建築圖檔) A: 現在論文撰寫平台一般為windows，macintosh，unix，前者轉為pdf檔並無問題，後二者我們要求先將原始檔案轉為postscript檔再轉為pdf檔。若是真為特殊檔案格式，也真想收集，可由館員透過管理介面上載該檔﹝無法透過繳交介面上再因系統會檢查是否為PDF檔﹞。 Q10: 目前系統是採用pop3來與e-mail server作身分認證，本校亦使用innopac系統，可否以innopac帳號密碼來認證身分？ A: 可以去問innopac有沒有API的介面，提供連線系統查證身分資料的功能，若有，則可依此改認證程式，不過據我們現在的了解，INNOPAC似乎不提供該介面。 Q11: ethesys是進到e-mail server進行身分的認證，會不會影響e-mail服務的效能？ A: 應該是不會，每年論文數量僅有800篇，且只有論文作者才會用此功能，不致有影響電子郵件伺服的效能。 Q12: 學生繳交論文需填的欄位都是必備欄嗎？或是可以作選擇？ A: 目前系統所顯示的畫面都需填入資料。 Q13: 論文系統是以pop3協定來認證，如果用imap會不會有問題？ A: 要改API，應該是沒有問題。 Q14: 會議結束後是否可以立即簽置授權書，即可取得軟體？ A: 下週我們會壓製軟體，交由國家圖書館。 南區說明會問題集 Q1: 有關將來ethesys系統改版，修改功能，各單位該如何加入新功能？ A: 本系統功能多已完備，若發現有bug，我們會視bug的狀況決定處理的方式。若為嚴重的bug，我們會修正，並提供修正程式給各校；但若各校取得原始碼後，功能上已作了大幅的修改，則該修正程式可能無法直接使用，此時我們會告知錯誤所在，請移轉學校自行修正有問題的地方。 Q2: ethesys目前都建置在UNIX作業系統，可不可以安裝在MS Windows系統上？ A: 基本上Perl和Apache都可在視窗平台上執行，所以應無問題。不過我們並沒有做這樣的測試。以往中山大學也只將eThesys安裝在Solaris及FreeBSD上，Linux上的安裝測試則靠中原大學及成功大學的幫忙。目前我們無充裕人力在各種作業環境進行安裝測試，因此鼓勵各位可嘗試將系統安裝於不同的作業平台，各校可視個別環境作適度的調整，屆時再分享系統安裝的心得，以達到真正共建共享的目標。 Q3: 以中山大學的經驗，有多少館員支援論文審核的工作？ A: 中山大學每年產生超過800篇電子論文，博碩文上傳的高峰是在每年七、八月，暑假期間有二名館員進行審核的工作。附帶一提，仍有部分畢業生會到圖書館現場轉檔，故提醒大家預先配置適當的人力協助學生轉檔；今年我們申請圖書館系的學生到館實習並配合義工的幫忙，有效紓解人力不足的情況，在此提供實際經驗供作參考。 Q4: 本校並無技術人員可以支援系統安裝等作業，該如何推展計畫？ A: 許多圖書館都面臨缺乏技術人員的窘境，此時可以考慮將建置系統及修改程式的工作外包給廠商，但提醒大家遵照合約的規定，務必與委外公司言明在先，不可在取得免費軟體之後，而產生銷售的行為，以免違反合約。 Q5: 本校須經校內會議討論通過始能正式實施計劃，我們可以事先取得軟體作系統測試嗎？ A: 國家圖書館的答覆是可以的，但請先與之聯絡再洽中山大學取得測試版。 有任何問題，請 E-Mail 至 etd@mail.nsysu.edu.tw

http://www.iis.sinica.edu.tw/EVENT/Activity/iis20/i05.html 謝清俊先生之簡介與訪談簡要 ---------------- 謝清俊先生於2001年8月自本所退休，但仍為兼任研究員，續主持本所文獻處理實驗室的工作，並協助本院規劃與執行國科會自2002年1月起為期五年的「數位典藏國家型科技計畫」，為計畫辦公室主任。謝先生於1983年至中央研究院，擔任資訊科學研究所研究員。於同年受前院長吳大猷先生囑託籌備計算中心，並於1983至1990年兼計算中心籌備處主任至主任一職。謝先生的研究工作涵蓋中文資訊處理、中文圖書館自動化、古籍資料庫、數位典藏、以及資訊技術對社會影響。於謝先生退休前夕（2001年7月26日），我們與他進行了一次訪談。茲摘錄部份訪談內容如下，以饗讀者。 ---------------- 問：你在中文資訊處理的基礎工作，從早期的中文輸入與輸出系統，字與詞的頻率統計，到近期的中文缺字處理系統。請你就「字形」（glyph）處理方面，說明目前的進展以及未來的展望？ 中文輸入與輸出涉及的是中文的構字問題。我是花了一些時間來瞭解文字學，把文字學中用古文所寫的東西，用科學、數學的方式表達出來，也就是等於說把文字學中的科學結構用現在的數學、邏輯語言表達出來，一旦轉換成現在的數學語言，計算機就可以處理這些文字。 這也涉及了中文字形交換碼的問題。中文字形交換碼的問題在於中文與外國語文的結構並不相同。外國語文的結構是詞（word），詞之下就是字母（alphabet）。字母是符號，本身沒有意義，經過一個次序組織出詞之後，才有意義。詞的意義多半是由音延伸而來。在這個情形下，外國語文的好處是很簡潔，字母是一個封閉集合（closed set），數量有限，所以數學結構表達起來非常容易。中文則有豐富的語意成分，是以知識來表達所構成的對象，而不是以表音為主。中文文字就是將古代的日常生活用圖像表達出來，裡頭也同時包含了語音與語意兩個部分。在這個基礎上，中文的文字並非是一個封閉集合，而是一個開放集合（open set）。 外國人並不懂中文的這套結構，因此當他們開始處理中文編碼時，直接就把中文字跟字母對應起來。將中文字跟字母對等是有問題的，因為中文字是開放集合，把開放集合納入封閉集合的結構中，有些字一定處理不了。有些字處理不了好像不是什麼大問題，但卻是非常嚴重的文化歧視。一直到今日，中文交換碼的最大問題都還是想把開放集合當作封閉集合來處理，所以不管那套系統都會有中文缺字的問題。 其實中文字是有封閉集合的，就是當初造字時的元件（components），古代曾經將這些元件分為聲母與形母兩類，加起來約有幾千個。這個統計與分類的工作在漢朝許慎做說文解字時就統計過，說文解字歸納出五百四十個部首，但其中仍然有問題。一方面是資料量太大；許慎處理了一萬一千多個字，分析這麼大量的資料難免有錯誤之處。另一方面則受到秦始皇焚書的影響，也就是說資料收集不易。 我開始做這個工作時，就是想承續這些文字學的努力，把中國構字的法則找出來，希望將中文構字用現代科學、數學的語言表達出來。最初我是在交大任職時處理這項工作，不過那時候受到電腦處理容量的限制，例如說記憶體只有八千位元（8k bytes）。分析字根時得盡量節省計算資源，因此必須忽略一些細節。到了院裡的時候，我就把這個工作再重新整理一遍，將過去忽略的細節重新補足，以忠實中國文字學的結構。最近我們發展出來的系統裡，大概包含了1200個字根，這些字根就是中國字形的最基本結構，字根與字根間則透過一些規則來結合成文字。另外，現在的系統也考慮到使用者的方便運用，因此我們將字根擴展到約4000個元件，讓任何人使用時只須做一個層次的分析，只要考慮一個組合運算，就能直觀的知道一個字是如何組成。 我們用這個系統來處理缺字，這個系統最終將是中文交換碼的下一代，因為所有現在的交換碼都是封閉集合，而我們的系統是一套產生系統（production system）。透過這個系統我們已經可以處理六萬多個字，而現行的任何系統都無法處理六萬多字。這當中，文字是用構字式來表達，而構字式是唯一的。只要是構字式不同，就是不同的字（雖然一個字可能有不同的構字式，但都可以經過計算機的化約歸納到一個標準式），字和字就可以比對了。 透過這套系統，可以做中文字的交換。它和傳統編碼的方式完全是兩套不同的思路，但可以附加在目前任何編碼系統上，都沒有問題。現行的系統只要加上一個後處理（post process）運算來識別沒有碼的那些缺字，無須更改原來的編碼。譬如大五碼（big 5），可以加上構字式的系統，其中所有的字根都用大五碼的編碼，但缺字就用構字式來表達。目前何建明的實驗室做了一個網站，根據這些構字式就可以到網站上去下載那些字形。不只如此，這套系統也可以延伸到處理日文、韓國、越南的漢字，甚至於中國各個朝代的文字，在時、空上都沒有問題。 問：你曾經參與「中文資訊交換碼」（Chinese Character Code for Information Interchange, CCCII）的制訂與推廣，並規劃與建立中央研究院圖書館自動化系統。請你就這方面，作一些回顧？「中文資訊交換碼」的前景為何？ 中文資訊交換碼最初是由我領導的小組所制訂的。1979年11月時，美國為了處理東亞文字，想要訂定一套標準碼，就由美國國會圖書館委託史丹佛大學，由John Haeger所負責的研究圖書館組織（Research Library Group, RLG）召集一個會議。那時國科會的處長王紀五要我去參加這個會。在那個會議中，我發現由於當時全世界只有一套日本的JIS交換碼可處理漢字。如果我們沒有一套中文資訊交換碼的話，可能日本的交換碼就會變成全部漢字的標準，我覺得這是個非常嚴肅的事。 那時我原本就在收集資料，1979年教育部也剛好發表了一份4808個常用字的字集，使我們可以開始做中文資訊交換碼的工作，不過在召開RLG會議的時候，我們還沒有開始進行。而美國其實是非常急於要訂立一套標準的。因為在軍事以及其他的用途上，美國必須用計算機處理中、日、韓文等東方語文資料，其中最大的問題即在中文字的處理。他們打算在第二年（1980）三月在華盛頓召開亞洲研究學會年會時，決定採取哪套編碼系統。 為了避免中文系統採用日本漢字的編碼方式，在RLG會議時，我就說我們正在做中文編碼的工作。一回國，我就跟當時電機工程學會會長李國鼎先生報告，我對他說，這是很嚴重的問題，牽涉到我們的文化的問題。舉例來看，清朝末年編了一本電報號碼本，到那時還是中文字唯一的編碼標準，這個電報號碼本編得很糟糕，所以用起來很不方便。外國人在設計ISO 646（ISO 7-bit coded character set for information interchange，字元集資訊交換碼）時，中國人沒有參與，所以計算機根本沒有辦法處理中文。這個標準如果不制訂的話。我們會對不起以後我們的子孫。 李國鼎聽了很贊同，就找了一些基金會，募了三百萬台幣，要我組織一個小組。因此我找了一些文字學家，如金祥恆、趙友培、潘重規以及當初的中央圖書館館長王振鵠等，以及一些圖書館方面的教授等。1979年12月25日正式成立了「國字整理小組」，花了三個月的時間，將4808個字的字集編碼作出來。當時張仲陶教授和我一起做這個事，他那年沒有回家過年，就在台灣技術學院的計算中心幫我跑這些資料。我上飛機時，帶了幾本上去，裝訂的膠都還沒有乾，拿在手上還是軟的。 就是在這個情形下，我在1980年3月，到美國報告。我在上面報告說明時，底下有美國圖書館界的編碼專家、ANSI（美國國家標準局）的編碼專家、語言方面的專家等，考了我一個早上。這四個小時比我考博士論文還辛苦。之後，中午吃飯時，他們恭喜我說，決定採用我們這套系統，不用日本的系統。日本派了七、八個代表去，但最後日本的系統沒被採用，非常失望的回去了。 問：中文資訊交換碼為什麼沒有成為國家標準？ 這是很辛酸的事情，大部分的事情已經都收錄在1989年出版的《國字整理小組十年》一書中。其中一個問題是，在做中文資訊交換碼時，我把簡體字也都收錄進來，很多人就罵我「與匪認同」。李國鼎把我找去，我很簡單的說：「我們要不要處理匪情資料？」他說要。我說：「我們不是說反攻大陸以後要把簡體字跟正體字做一個對照，要做很多文宣，這些工作需不需要計算機幫忙？」他說要。「所以我把簡體字放進去。」聽了之後，李國鼎就幫我把這些事都檔掉。 但後來有一些人，認為中文編碼不過是把中文排列起來給個編號而已，為什麼要給你做？他們批評說，CCCII用三個bytes來做編碼是不對的，三個bytes太浪費空間，我們用兩個bytes就有65536個組合，使用其中一部份編一萬多字就夠了。實際上是他們並沒有搞清楚什麼是資料碼（data code），什麼是控制碼（control code），結果編出來的碼裡頭沒有控制碼。最後的結果是完全不能使用，後來修改時，還是把CCCII一步一步學過去。當時的一些科技大老要求我就這兩套編碼做妥協，說新編一個系統，一部份採取我的結構，另一部份採取他的結構。我直接拒絕，因為兩套系統有很多不相容之處。在我拒絕之後，他們就弄出了一套CNS（國家標準交換碼），但是CNS至今並沒有人使用。今日用的是big5，而非CNS。至於big5，是民間發展出來的，業界要發展中文系統，但CNS不能用，又不能用謝清俊的，因為使用謝清俊的就會得罪那些大老。只好弄一個big5出來。 CCCII一直維護到三、四年前張仲陶教授過世以前，之後我也不再做維護了。我認為，CCCII從1979年發展出來，經過20多年後，階段性的任務已經完成，沒有必要再維持下去。而且現在這個缺字系統出來，就可以取代CCCII了。 問：中研院在古籍資料庫的工作，很早就開始了。請問你在古籍資料庫方面的工作經驗與心得？是哪些因素驅使你進行這些工作？ 我離開台灣技術學院（編注：現台灣科技大學）到中研院的主要目的，就是想做古籍資料庫。當時外國可以看到很多文史方面的工作已經開始進行，中國卻沒有。1983年我到院裡來，就跟史語所毛漢光先生講好到這裡來做古籍的事。但是來不到半年就被吳大猷先生抓去做計算中心的籌備工作。當時中研院的計算環境很差，除了資訊所有一些電腦外，大概就只有植物所有一台迷你電腦（mini computer），大概是HP 2100 系列的，其他沒有一個所有電腦。吳大猷先生跟我說得語重心長。他說他雖然不懂電腦，但知道以後研究不用電腦的話，研究院的學術地位在世界上會受到非常大的挑戰。這句話說的很沈重的，因為他一直說他不需要用電腦做研究，他只需要一枝鉛筆一張紙就夠了。吳大猷先生做研究確實是如此，但是對年輕人就不一樣，他也瞭解電腦對研究院的發展很重要。 這件事我到今天仍然不瞭解是誰推薦我去的，因為之前我根本不認識吳大猷先生。我跟吳大猷先生說，我的想法是要盡全力幫忙文史的人。我說，自然科學和生命科學我們不用照顧他們，機器給他們用就好了，但是文史方面必須要有人照顧他們。接了計算機中心主任之後，我就利用這個機會，把我想做的二十五史的資料做出來。從那時一直到我卸任之前，計算機中心的資源幾乎百分之七十在支持文史，一直到現在我也覺得這個策略沒有錯，因為電腦買了，對自然科學、生命科學的人來說，他們很容易的就可以使用，但是文史的非有人帶不可。 在計算機中心時，我就開始做古籍電子化的工作，研究院開始做電子文獻時，外國剛起步不到兩年。我們從1985開始做二十五史全文資料庫，國外是1984年年底開始有一些全文資料庫出現，所以事實上我們做全文資料庫是滿早的，確實相當有前瞻性。比起我們的計算機科學，技術跟國外至少五到十年的差距來說，是少得多了。 從文史的角度來思考，其實和從計算機科學的角度來思考是不一樣的。舉個例來說，訂二十五史全文資料庫的規格時，我手下有一些人，拿了一些國外的論文來跟我說，國外的全文資料庫的檔案結構都是一頁文稿一個檔案，你為什麼要堅持一個段落做一個單位？為什麼一定要堅持要保留二十五史原書的段落、行數跟字數？我跟他們講道理講不通，他們從計算機的技術來看認為我是在找麻煩，但是我認為那是錯的。這是因為我認為結構分成好多種，版面結構是一種，文章內容結構是另外一種，我們必須要知道哪些資訊是做全文資料庫時必須保留下來的。這到今天都是一個好問題。 這個制訂出來規格其實是非常領先的，當時SGML（Standard Generalized Markup Language，通用標示語言語法）正在發展，SGML是1986正式發展出來的，我們在1985已經訂出了一個自己的標示語言，一直到今天計算機中心還在使用。後來上網路時，才將這套系統對應到HTML（HyperText Markup Language，超文件標示語言）格式。我們那套標示語言和SGML不一樣。雖然SGML功能較強，但也比較複雜。我們的系統用拿來做二十五史也就夠了。

http://163.17.18.70:8080/modules/xoopsfaq/index.php?cat_id=8 館藏查詢系統中常看到錯字，例如：「歷」會變成「曆」、「當」會變成「噹」、「家族治療」變成「{213a79}族治療」等，或是查詢不到某特定書籍。這些問題產生的原因是因為字碼轉換的關係。目前我們建檔用的是UNICODE碼，系統儲存用的是CCCII碼，而IE瀏覽器顯示用的是BIG5碼，所以會有字碼轉換與比對的問題。 當您發現時，請告訴我們，我們將持續收集，並積極與國外廠商聯絡。由於字碼問題的解決是需要時間的累積，恐怕不是一時可解決，還請讀者多多包涵。 建議您，若有特定的中文書要找，但以書名查詢不到時，改以作者查詢看看。 CCCII碼 不過是一個 台灣自己 騙逍ㄟ 的規格產物 台灣的字型發展 仍停留20年前 令人髮指 令人嘖嘖稱奇 哈哈 哈哈哈

程式以上傳程式到發表區 "Z39.50 圖書館搜索 Client 端 使用元件 VB ZOOM" 有興趣的可以去看看, 目前只支援英文搜索 >< 中文我在想想辦法吧.... 目前想到最好的方法是用 loop 來 try 字型找出編碼規則...

連接 INNOPAC 圖書館的CCCII編碼方式已經解決了, 他們是用 "{}" 來把每一個字括起來 eg. 字1,字2 = { 字1 } { 字2 } = {212321}{212324}

昌泰中文碼 有沒辦法轉成 big5 或 unicode?