Motorola iDEN J2ME 開發實戰（四）：除錯、中文支援與開發工具鏈

MIDlet 除錯策略

模擬器端：System.out.println()

• 輸出導向模擬器啟動終端機/Console 視窗
• 即時追蹤變數、流程分支、例外堆疊
• 限制：真機無 Console，輸出去向不明（依賴廠商實作）

真機端：On-Device Debugging (KDWP)

需滿足三條件：

1. 裝置支援 KDWP (KVM Debug Wire Protocol)
2. 廠商提供 MIDlet 側載除錯機制（序列埠/USB/藍牙/UDP）
3. IDE/工具支援 KDWP 客戶端（如 CodeWarrior、JBuilder OpenTools）

Motorola 承諾後續 SDK/裝置將完善此鏈路。

中文支援深度解析：編碼陷阱與破解

現象複現

根因追溯：Bytecode 中的字串編碼流程

1. 原始碼中文採 Big5 編碼儲存 (如「激活」= B1 D2 B0 CA)
2. javac 預設以平台編碼 (Big5) 讀取 → 轉 Unicode (555F 5272) → 以 UTF-8 寫入 class 常數池 (E5 95 9F E5 89 B5)
3. KVM 執行時：讀取 UTF-8 → 轉 Unicode → 直接輸出 Unicode 碼值，缺少「依當前 Locale 轉回 Big5」步驟
4. Console/終端機以 Big5 解讀 Unicode 碼值 → 亂碼

破解方案：-encoding ISO8859_1

強制 javac 將原始碼視為單位元組 ISO-8859-1 (Latin-1) ：

• Big5 雙位元組 B1 D2 被視為兩個獨立字元 B1、D2
• 各自對應 Unicode 00B1、00D2
• UTF-8 編碼為 C2 B1 C3 92
• KVM 讀取 → 轉 Unicode 00B1 00D2 → 直接輸出 → 終端機以 Big5 解讀 → 正確顯示「激」

結論：真機大概率需加 -encoding ISO8859_1 才能正確顯示中文。模擬器行為可能與真機不同，以真機為準。

實務建議

• Ant/Eclipse 建構腳本統一加入 -encoding ISO8859_1 (或 UTF-8 配合 KVM 修補)
• 資源檔 (.txt, .properties) 同樣需注意編碼一致性
• 可考慮將中文字串外部化至資源檔，建構時統一轉碼

Motorola J2ME SDK 內建輔助工具

IDE 整合現狀

• CodeWarrior (Metrowerks)：官方支援 IDE，整合編譯/預驗證/模擬器/除錯，SDK 文件附有教學
• JBuilder (Borland)：OpenTools API 潛力大，Spotlet 方案已有，MIDlet 支援預期中
• Eclipse + EclipseME：社群驅動，靈活免費，需手動配置 WTK 路徑

範例程式碼庫速覽

SDK 安裝目錄 demo/midlets/ 包含：

• 遊戲類：Bounce, PaddleBall, Scribble
• 教學類：FontDemo, GraphicsDemo, RecordStoreDemo, UDPReceive
• 測試類：AlertTest, ChoiceGroupTest, DateFieldTest, FormTest, GaugeTest, KeyEventsTest, TextBoxTest, TextFieldTest, TickerTest

建議逐一編譯運行，閱讀原始碼，掌握 Motorola 平台慣用模式。

結語

Motorola iDEN 系列作為早期 Java 手機先鋒，其 SDK 暴露了 J2ME 早期生態的典型痛點：除錯鏈路不完善、中文編碼無標準化、IDE 整合碎片化。開發者以 -encoding ISO8859_1 破解中文、以 System.out.println 湊合除錯、以批次檔驅動模擬器，這些「土法煉鋼」的經驗，倒逼出後來 WTK 2.x 統一建構、EclipseME 整合 IDE、MIDP 2.0 強制 HTTPS/簽名/安全域的標準化路徑。回望這段歷史，能更深刻理解現代 Android Studio/Gradle/ADB 工具鏈設計的每一個細節初衷。