記錄節後一周系統性復習與新技術探索心得，涵盖 Web MVC 框架、ORM 映射、前端異步交互及移動端開發入門四大板塊。 一、Struts 1.x 核心架構與

J2ME 提供 HttpConnection（應用層 HTTP 協議支持）與 SocketConnection（傳輸層原始 Socket 流）兩種網絡 API。

J2ME 應用常需查詢設備能力（如支持的 API 版本、硬件特性、本地化信息）以實現動態適配。平台通過 System.getProperty(String ke

XML 以其良好的可讀性和結構化特性成為數據交換首選，但在早期 MIDP 1.0 時代，受限於設備內存與處理器性能，平台未內置 XML 解析器。隨著硬件升級，J

自中國移動啟動上網資費頁面提醒機制後，許多 J2ME 應用在聯網時遭遇「連不上服務器」的問題。具體表現為：程序發起網絡請求後，移動網關在特定地區或時段會攔截請求

本文與 ID 78170 關係 本文內容與 ID 78170 高度相似，均出自同一來源。此處提供補充視角：更完善的異常處理、執行緒模式、連線釋放順序，並修正原文

MMAPI 攝像頭核心類 Manager.createPlayer(capture://video) 建立 Player。 player.getCon

問題現象 J2ME DataInputStream.read() 逐字元讀取回應，若伺服器回傳 UTF-8 中文，直接 new String(byte[]) 依

Cookie 工作原理回顧 伺服器回應含 Set-Cookie Header。 客戶端儲存，下次請求同域同路徑自動帶上 Cookie: name=va

前言 手機程式開發最常見需求即 SMS、MMS、Email。Sun 透過 JSR 102 (WMA 1.1) 與 JSR 205 (WMA 2.0) 完善支援。

背景 J2ME 無 java.net.URLEncoder，需自行實作 application/x-www-form-urlencoded 編碼，以便向伺服器傳

必要引用 import javax.wireless.messaging.MessageConnection; import javax.wireless.me

WMA 2.0 概覽 JSR 205 定義 Wireless Messaging API 2.0，基於 Generic Connection Framework

無線 Web 服務安全挑戰 無線通訊易遭攔截，設備算力弱難支撐強加密；Web 服務跑在防火牆外用開放協議。傳統點對點加密 (SSL/TLS) 不適合多中繼拓撲，

問題：並非所有設備支援多連線 部分手機限制同時開啟的網路連線數。應用若依賴多連線，在不支援的設備上會崩潰。解決之道：在 JAD 中聲明設備最大連線數，執行期動態

問題背景 HTTP 1.1 允許伺服器以 302 狀態碼指示資源暫時移動，新位置在 Location Header。桌面瀏覽器自動追蹤，但移動設備實作差異極大：

專案背景 開發一套 J2ME 查詢公網資料庫的客戶端/伺服端介面。客戶端透過 CMNET 或 CMWAP 代理閘道，向伺服端 HTTP 介面發送查詢請求，伺服端

HttpConnection 介面速覽 MIDP 建立在 CLDC 的 Generic Connection Framework 之上，強制支援 HTTP。所有

遠端服務調用完整範例 生成、編譯、部署 Stubs 後，調用遠端服務極為簡單：實例化 Stub → 設定端點 URL 與 Session 維持屬性 → 在獨立執

消費 Web 服務流程 取得描述服務的 WSDL 文件。 使用工具（如 J2ME Wireless Toolkit 2.1 Stub Generato