112 年 國立中央大學資訊管理學系碩士班甲組《計算機概論》

此題主要考驗對 Linux crontab 檔案格式的理解與應用。Crontab 是 Linux 系統中用來排程執行特定指令的工具。其檔案格式為：分鐘、小時、日期、月份、星期、指令。

(1) 每周六凌晨2時執行備份指令：

• 分鐘: 0 (凌晨 2 點的 0 分)
• 小時: 2 (凌晨 2 點)
• 日期: * (每天)
• 月份: * (每月)
• 星期: 6 (星期六，0 或 7 代表星期日，1 代表星期一，以此類推)
• 指令: /backup.sh

因此，對應到 crontab 檔案的格式，該行指令應為：
0 2 * * 6 /backup.sh

此題考驗二進位轉換、IEEE 754 浮點數表示法以及機器 epsilon 的概念。

核心觀念：

• 二進位轉換： 整數部分除以 2 取餘數，小數部分乘以 2 取整數。
• IEEE 754 單精準度： 由符號位元 (1 bit)、指數位元 (8 bits) 和尾數 (mantissa) 位元 (23 bits) 組成。指數部分採用 excess-127 表示法，即實際指數為儲存值減去 127。對於正規化 (normalized) 數字，尾數的最高位元 (implicit leading 1) 不儲存。
• 機器 epsilon (Machine Epsilon)： 指的是 1 加上機器 epsilon 後，在浮點數表示下與 1 相等的最小正數。對於單精準度浮點數，機器 epsilon 約為 $2^{-23}$。

解題過程：

(1) 二進位定點表示法 (237.8125)

• 整數部分 237：

  • $237 \div 2 = 118$ 餘 1
  • $118 \div 2 = 59$ 餘 0
  • $59 \div 2 = 29$ 餘 1
  • $29 \div 2 = 14$ 餘 1
  • $14 \div 2 = 7$ 餘 0
  • $7 \div 2 = 3$ 餘 1
  • $3 \div 2 = 1$ 餘 1
  • $1 \div 2 = 0$ 餘 1
    將餘數由下往上讀，得到 $237_{10} = 11101101_2$。

• 小數部分 0.8125：

  • $0.8125 \times 2 = 1.625$ 取 1
  • $0.625 \times 2 = 1.25$ 取 1
  • $0.25 \times 2 = 0.5$ 取 0
  • $0.5 \times 2 = 1.0$ 取 1
    將取出的整數由上往下讀，得到 $0.8125_{10} = 0.1101_2$。

• 合併： $237.8125_{10} = 11101101.1101_2$。

此題考驗對虛擬記憶體分頁系統的理解，特別是分頁表的大小計算。

核心觀念：

• 分頁系統 (Paging System)： 將邏輯位址空間劃分為固定大小的頁 (page)，實體記憶體劃分為固定大小的頁框 (page frame)。
• 邏輯位址 (Logical Address)： 程式使用的位址，由頁號 (page number) 和頁內位移 (offset) 組成。
• 分頁表 (Page Table)： 儲存邏輯頁號與對應的實體頁框號的結構。每個行程都有一個分頁表。
• 位元寬度： 決定了可定址的空間大小。
• 頁大小 (Page Size)： 決定了位移部分的位元數，以及邏輯位址中頁號的位元數。

解題過程：

1. 確定邏輯位址空間大小：
   題目指出邏輯位址空間是 32-bits。
   所以，邏輯位址空間總共有 $2^{32}$ 個位元組 (byte)。

2. 確定頁大小 (Page Size)：
   題目給定每個頁大小為 4 MB。
   $1 \text{ MB} = 2^{20} \text{ bytes}$
   所以，頁大小 $= 4 \times 2^{20} \text{ bytes} = 2^2 \times 2^{20} \text{ bytes} = 2^{22} \text{ bytes}$。

3. 計算邏輯位址中的頁號位元數和頁內位移位元數：
   邏輯位址總長度為 32 bits。
   頁內位移 (offset) 的位元數由頁大小決定，即 $\log_2(\text{Page Size})$。
   頁內位移位元數 $= \log_2(2^{22}) = 22$ bits。
   頁號 (page number) 的位元數 = 總邏輯位址位元數 - 頁內位移位元數
   頁號位元數 $= 32 - 22 = 10$ bits。

4. 計算一個行程總共有多少個頁：
   行程的邏輯位址空間大小為 $2^{32}$ bytes。
   每個頁的大小為 $2^{22}$ bytes。
   總頁數 = (邏輯位址空間大小) / (頁大小)
   總頁數 $= 2^{32} \text{ bytes} / 2^{22} \text{ bytes} = 2^{10}$ 個頁。
   這也等於頁號的位元數所能表示的頁數。

5. 計算分頁表 (Page Table) 的大小：
   分頁表的主要功能是將邏輯頁號映射到實體頁框號。每個邏輯頁號都需要在分頁表中有一項對應的記錄 (entry)。
   由於行程有 $2^{10}$ 個邏輯頁，因此分頁表將有 $2^{10}$ 個項目。

   題目提到電腦是 64-bits 的定址匯流排。這通常意味著一個實體位址是 64 bits。在分頁系統中，分頁表項目 (Page Table Entry, PTE) 需要儲存實體頁框號，可能還包含其他標誌位 (如有效位、權限位、髒位等)。
   一個常見的分頁表項目大小會與 CPU 的位元寬度有關，或者至少足夠儲存實體位址。假設一個分頁表項目至少需要儲存實體頁框號。
   一個實體頁框號的位址空間是由 64 bits 的定址匯流排決定的。然而，頁大小是 4MB ($2^{22}$ bytes)，所以實體位址的位移部分是 22 bits。
   實體位址總長度為 64 bits。
   實體位址 = 實體頁框號 (Physical Page Frame Number) + 頁內位移 (Offset)

此題考驗對 HTTP Cookies 的理解，包括其功用、工作原理以及 First-party 和 Third-party Cookies 的區別。

核心觀念：

• HTTP Cookies： 伺服器透過 HTTP 回應標頭 (Set-Cookie) 傳送給瀏覽器，瀏覽器將其儲存，並在後續的 HTTP 要求中透過要求標頭 (Cookie) 傳送回伺服器。
• 無狀態協定 (Stateless Protocol)： HTTP 本身是無狀態的，伺服器無法記住之前的請求。Cookies 解決了這個問題，使得伺服器可以追蹤使用者狀態。
• 功用： 紀錄使用者偏好、追蹤登入狀態 (session management)、追蹤瀏覽行為 (e.g., 購物車內容)。
• 工作原理： 伺服器發送 Set-Cookie 標頭，瀏覽器儲存 Cookie。下次請求相同網域時，瀏覽器自動附加 Cookie 標頭。
• First-party vs. Third-party Cookies： 根據 Cookie 的來源網域與使用者正在瀏覽的網域的關係來區分。

詳細說明：

HTTP Cookies 的功用：

HTTP 協定本身是無狀態的，這意味著伺服器不會自動記住來自同一客戶端的連續請求之間的任何資訊。為了彌補這一點，Cookies 被引入，用於在客戶端（通常是瀏覽器）儲存少量資訊，並在每次與同一伺服器通信時將這些資訊傳送回去。Cookies 的主要功用包括：

1. Session Management (會話管理)： 這是 Cookies 最常見的用途之一。當使用者登入網站時，伺服器可以產生一個唯一的 session ID，並將其儲存在一個 Cookie 中傳送給瀏覽器。之後，瀏覽器每次發送請求時都會帶上這個 session ID，伺服器據此識別使用者，從而保持登入狀態，無需使用者每次都重新輸入帳號密碼。
2. Personalization (個人化設定)： 網站可以利用 Cookies 記住使用者的偏好設定，例如語言選擇、佈景主題、字體大小等。下次使用者訪問該網站時，網站會自動載入這些偏好設定，提供更個人化的體驗。
3. Tracking (追蹤)： Cookies 可以用來追蹤使用者的瀏覽行為。例如，電子商務網站可以使用 Cookies 來記錄使用者在購物車中添加的商品、瀏覽過的頁面等。這有助於網站分析使用者行為，改進網站設計，或進行更精準的廣告投放。

HTTP Cookies 的工作原理：

Cookies 的工作流程如下：

1. 伺服器發送 Set-Cookie：
   當瀏覽器首次訪問一個網站時，伺服器可能會在其 HTTP 回應的標頭中包含一個 Set-Cookie 指令。這個指令包含一個鍵值對 (name=value)，以及一些可選的屬性，例如：

   • Expires：指定 Cookie 的過期日期。
   • Max-Age：指定 Cookie 在多少秒後過期。
   • Domain：指定 Cookie 適用於哪個網域。
   • Path：指定 Cookie 適用於該網域下的哪個路徑。
   • Secure：如果設置，則 Cookie 只會在 HTTPS 連接時被傳送。
   • HttpOnly：如果設置，則 Cookie 無法透過 JavaScript 訪問，增加了安全性。

   範例：

   HTTP/1.1 200 OK
   Set-Cookie: sessionID=a1b2c3d4e5f6; Expires=Wed, 21 Oct 2023 07:28:00 GMT; HttpOnly
   Content-Type: text/html
   ...
   

2. 瀏覽器儲存 Cookie：
   瀏覽器接收到 Set-Cookie 指令後，會將其儲存起來，通常是與該 Cookie 的網域、路徑等屬性關聯。

3. 瀏覽器發送 Cookie：
   當瀏覽器在有效期內再次訪問與該 Cookie 相關聯的網域時，它會在 HTTP 要求標頭中自動包含之前儲存的 Cookie。

   範例：

   GET /index.html HTTP/1.1
   Host: www.example.com
   Cookie: sessionID=a1b2c3d4e5f6
   ...
   

4. 伺服器讀取 Cookie：
   伺服器接收到帶有 Cookie 標頭的請求後，就可以讀取其中的資訊，並根據這些資訊來識別使用者或執行相應的操作。

First-party Cookie 與 Third-party Cookie：

這兩者的區別在於 Cookie 的來源網域與使用者當前瀏覽的網域的關係。

• First-party Cookie (第一方 Cookie)：
  當使用者正在瀏覽的網站網域與 Cookie 的來源網域相同時，該 Cookie 就是第一方 Cookie。
  例如，當你瀏覽 www.example.com 時，如果 www.example.com 伺服器設定的 Cookie，那就是第一方 Cookie。
  功用： 主要用於網站本身的運營，如使用者登入狀態、個人化設定、購物車等。
  瀏覽器策略： 大部分瀏覽器預設允許第一方 Cookie。

• Third-party Cookie (第三方 Cookie)：
  當使用者正在瀏覽的網站網域與 Cookie 的來源網域不同時，該 Cookie 就是第三方 Cookie。
  這通常發生在網頁中嵌入了來自其他網域的內容（例如廣告、分析腳本、社交媒體按鈕等）。

此題考驗對網路安全「Kill Chain」模型的理解，包括其構成階段以及在網路安全防禦中的實用意義。

核心觀念：

• Kill Chain： 一種將網路攻擊分解為一系列離散階段的模型，幫助安全專業人員理解、偵測和應對攻擊。
• Lockheed Martin Cyber Kill Chain： 最常見的 Kill Chain 模型，包含七個階段。
• 防禦意義： 透過識別攻擊的每個階段，可以在攻擊者尚未達成最終目標前進行干預，中斷攻擊鏈，從而提高防禦效率。

詳細說明：

網路安全 Kill Chain 的內容 (以 Lockheed Martin 的模型為例)：

Lockheed Martin 的 Cyber Kill Chain 模型將網路攻擊過程分解為七個階段。攻擊者必須成功完成每一個階段，才能達成其最終的惡意目標。這七個階段是：

1. 偵察 (Reconnaissance)：

   • 攻擊者行為： 攻擊者在發動攻擊前，會積極收集目標的資訊。這可能包括偵察目標的網路架構、使用的技術、員工資訊、漏洞等。
   • 方法： 掃描網站、查詢公開資訊 (DNS 記錄、WHOIS)、社交工程、惡意軟體樣本分析等。

2. 武器化 (Weaponization)：

   • 攻擊者行為： 攻擊者將惡意軟體（如病毒、蠕蟲、勒索軟體、後門程式）與一個滲透載體（如惡意文件、可執行檔）結合成一個「武器」。
   • 目標： 創建一個能夠在目標系統上執行並達成下一個階段目標的載體。
   • 範例： 將勒索軟體打包成一個 PDF 文件，並附加一個惡意巨集。

3. 傳送 (Delivery)：

   • 攻擊者行為： 攻擊者將武器化後的載體傳送給目標。
   • 方法： 透過電子郵件附件、惡意連結、USB 隨身碟、網頁植入廣告 (malvertising) 等方式。

4. 攻擊 (Exploitation)：

   • 攻擊者行為： 當武器化的載體到達目標系統後，它會觸發一個或多個漏洞來執行攻擊者預設的代碼。
   • 範例： 使用者打開惡意 PDF 文件，PDF 閱讀器中的一個漏洞被觸發，進而執行了惡意程式碼。

5. 安裝 (Installation)：

   • 攻擊者行為： 攻擊者會在目標系統上建立一個持久性的後門，以便在系統重新啟動後仍然能夠訪問。
   • 目的： 確保即使初始的滲透點被發現或修復，攻擊者仍然能保持對目標系統的控制。
   • 方法： 安裝後門程式、修改系統註冊表、建立新的使用者帳戶等。

核心觀念

本題考查「物件持久化（object persistence）」與「物件—關聯式資料庫對映（Object-Relational Mapping, ORM）」。

物件存在於程式記憶體中時，程式結束後通常會消失；若要在程式結束後仍保留物件狀態，就必須將其資料寫入永久性儲存媒體，例如關聯式資料庫。之後再透過查詢將資料還原成程式物件。

關聯式資料庫以資料表、資料列、欄位與外部鍵表示資料；物件則包含：

• 屬性（attributes）
• 物件識別（object identity）
• 方法（methods）
• 封裝（encapsulation）
• 繼承（inheritance）
• 物件之間的關聯

因此，物件持久化的核心問題是：如何將物件狀態轉換成關聯式資料，以及如何從資料庫資料重建物件。這個差異稱為「物件—關聯阻抗不匹配（object-relational impedance mismatch）」。

解題方法

回答此題時，應從「資料如何寫入資料庫」與「資料如何重新組合成物件」兩個方向，列出常見的實作方式，並說明各方式的特色與適用情境。

1. 手寫 SQL 搭配資料庫連線 API

程式直接使用 JDBC、ODBC、ADO.NET 等資料庫存取 API，撰寫 SQL 指令完成新增、查詢、修改與刪除。

例如，將 Student 物件寫入資料表：

INSERT INTO Student (id, name, department)
VALUES (?, ?, ?);

查詢後，再由程式逐一讀取欄位並建立物件：

Student student = new Student(
    resultSet.getInt("id"),
    resultSet.getString("name"),
    resultSet.getString("department")
);

此方法的流程為：

1. 從物件取得屬性值。
2. 組成 INSERT 或 UPDATE SQL。
3. 將物件識別值存入主鍵欄位。
4. 查詢時執行 SELECT。
5. 將查詢結果逐欄轉換回物件。
6. 依外部鍵重新建立物件之間的關聯。

優點是控制力高、SQL 效能容易調校，也能充分運用資料庫功能。缺點是程式碼量大，資料表結構與物件類別高度耦合，容易出現重複的 CRUD 程式碼。

2. 資料存取物件或資料存取層

將資料庫操作集中在 DAO（Data Access Object）、Repository 或 Data Mapper 等類別中，讓領域物件不直接處理 SQL。

例如：

StudentRepository.save(student)
StudentRepository.findById(id)

資料存取層負責：

• 將物件屬性對映到資料表欄位。
• 執行 SQL。
• 將查詢結果轉換成物件。
• 處理交易與資料庫連線。

此方法本身仍可能使用手寫 SQL，但透過分層設計隔離資料庫細節，使商業邏輯不必直接依賴資料庫操作。它特別適合需要清楚分離商業邏輯與基礎設施的系統。

3. 使用 ORM 框架自動進行物件—關聯對映

ORM 框架將類別對映到資料表，將物件屬性對映到欄位，並自動處理部分 SQL 與物件重建工作。常見工具包括 Hibernate、JPA、Entity Framework 等。

例如：

Student 類別       → Student 資料表
student.id         → id 欄位
student.name       → name 欄位
student.department → department 欄位

ORM 通常會提供：

• 類別與資料表對映。
• 屬性與欄位對映。
• 主鍵與物件識別管理。
• 一對一、一對多、多對多關聯。
• 延遲載入（lazy loading）。
• 快取。
• 交易管理。
• 物件生命週期管理。
• 將繼承階層對映到資料表。

程式可直接操作物件：

核心觀念

本題評量**物件關聯對應（Object-Relational Mapping, ORM）與物件永續性（Object Persistence）**之系統架構與實作策略。

在現代軟體工程中，應用程式端常以「物件導向（Object-Oriented, OO）」典範建構（強調封裝、繼承、多型、物件參照與狀態）；後端儲存則以「關聯式資料庫（Relational Database Management System, RDBMS）」為主（強調資料表、關聯（Relation）、主鍵／外鍵約束與正規化）。兩者之間存在的理論與架構落差稱為物件-關聯阻抗不匹配（Object-Relational Impedance Mismatch）。

所謂「將物件透過關聯式資料庫永續化（Provide persistence to objects using relational databases）」，即探討如何跨越阻抗不匹配，將記憶體中的物件狀態（In-memory state）可靠地轉換並儲存於關聯式表格中。

---

解題方法

本題為問答題（配分 7%），作答切入點應分為「應用層架構取向（Architecture Approaches）」與「物件導向結構對應至關聯表的技術策略（Structural Mapping Strategies）」，層次分明地列舉常見實作方式：

一、 實作物件永續性的主要架構方式（Architectural Ways）

1. 手動資料存取（Direct SQL / Data Access Objects, DAO）

   • 作法：程式開發人員直接使用資料庫連線介面（如 JDBC、ODBC、ADO.NET），透過原生 SQL 語法手動撰寫 INSERT、UPDATE、DELETE、SELECT。
   • 特性：藉由手寫映射程式碼將資料庫的 Cursor / ResultSet 與物件的屬性進行雙向轉換。控制力最強、效能透明，但程式碼冗長且維護成本極高。

2. 半自動／資料映射框架（Data Mapper / SQL Mapper）

   • 作法：如 MyBatis（前身為 iBATIS）。開發者自行撰寫 SQL 語句，框架負責將輸入物件的欄位參數綁定到 SQL，並自動將查詢結果映射為物件結構。
   • 特性：保留對 SQL 最佳化與複雜查詢的完全掌控，同時消除大部分繁瑣的手動賦值工作。

3. 全自動物件關聯映射框架（Full Object-Relational Mapping, ORM）

   • 作法：使用 ORM 框架（如 Hibernate、JPA、Entity Framework、SQLAlchemy、Django ORM）。開發者透過 Metadata（宣告性註解 Annotation 或 XML 檔案）宣告「類別－表格（Class-to-Table）」及「屬性－欄位（Attribute-to-Column）」的對應規則。
   • 特性：框架動態產生 SQL、管理物件生命週期（Dirty Checking、Unit of Work、Identity Map）與關聯載入（Lazy/Eager Loading），將資料庫操作完全抽象化為物件導向操作。

4. 主動記錄模式（Active Record Pattern）

   • 作法：一個物件代表資料庫中的一筆記錄（Tuple），該物件封裝了資料與資料庫存取方法（如 Ruby on Rails ActiveRecord）。
   • 特性：適合業務邏輯相對單純的 CRUD 系統。

---

二、 處理物件特殊結構的對應策略（Structural Mapping Strategies）

物件導向核心特性（如繼承、關聯）在 RDBMS 中沒有直接對應的語法，實務上常見的對應持久化策略如下：

1. 繼承關係的映射策略（Inheritance Mapping Strategies）
   • 單一表格策略（Single Table per Class Hierarchy）：整個繼承體系共用一張資料表，以「辨別欄（Discriminator Column）」標記具體子類別。非通用屬性欄位在未使用的子類別中留為 NULL（查詢快、但違反正規化且有空間浪費）。

核心觀念

本題考查資料庫 ER 模型中的「特殊化」（specialization）。特殊化是將一個較一般的超類別（supertype）依照特徵或業務規則，細分成一個以上的子類別（subtype）。

例如：

• Employee：員工
• Manager：經理
• Engineer：工程師

Manager 與 Engineer 都繼承 Employee 的共同屬性，例如員工編號、姓名與到職日；各子類別再擁有自己的專屬屬性或關聯。

特殊化主要有兩種參與限制：

1. Total specialization（完全特殊化）

完全特殊化表示超類別中的每一個實體，都必須屬於至少一個子類別。

形式化表示為：

$$\forall e \in E,\quad e \in S_1 \cup S_2 \cup \cdots \cup S_n$$

其中：

• $E$ 是超類別的實體集合；
• $S_1, S_2, \ldots, S_n$ 是各個子類別；
• 每個超類別實體至少出現在一個子類別中。

在 ER 圖中，通常以超類別與子類別之間的雙線表示。

2. Partial specialization（部分特殊化）

部分特殊化表示超類別中的實體，不一定要屬於任何子類別；只有符合特定條件的實體才會被分類到子類別。

形式化表示為：

$$\exists e \in E,\quad e \notin S_1 \cup S_2 \cup \cdots \cup S_n$$

也就是說，允許存在某些超類別實體不屬於任何子類別。

在 ER 圖中，通常以超類別與子類別之間的單線表示。

---

解題方法

判斷應使用 total specialization 或 partial specialization，關鍵在於檢查業務規則：

超類別中的每一個實體，是否都必須被歸入至少一個子類別？

使用 total specialization 的情況

當題目中的業務規則要求「所有超類別實體一定屬於某個子類別」時，使用完全特殊化。

例如，資料庫中定義：

• Account：帳戶
• SavingsAccount：儲蓄帳戶
• CheckingAccount：支票帳戶

若系統規定每一個帳戶必定是儲蓄帳戶或支票帳戶，則：

$$Account = SavingsAccount \cup CheckingAccount$$

此時每個 Account 實體都必須出現在至少一個子類別中，因此使用 total specialization。

其他例子包括：

• 每一位公司員工必定是正式員工或約聘員工；
• 每一份訂單必定是一般訂單或急件訂單；
• 每一輛登記車輛必定是汽車、機車或貨車。

這些情況的共同特徵是：子類別已經完整涵蓋超類別的所有合法實體。

使用 partial specialization 的情況

當只有部分超類別實體具有特殊身分，且仍允許其他實體只存在於超類別中時，使用部分特殊化。

例如：

• Employee：員工
• Manager：經理
• Engineer：工程師

若公司員工中有些人是經理、有些人是工程師，但仍有行政人員、助理或其他職務不屬於這兩個子類別，則不是每個 Employee 都必須屬於 Manager 或 Engineer。

核心觀念

• 遞迴 (recursion)：方法 A、C 皆以遞迴呼叫自身或其他方法，必須先把遞迴到底部（基礎情況）才能返回結果。
• 呼叫順序 (call order)：System.out.print 會立即輸出而不換行，System.out.println 會先輸出參數再換行。
• 回傳值累計：A 於遞迴時將 A(x+5) 與 B(x) 的回傳值相加；B 回傳 4*x；C 回傳 3*A(x-4)。

---

解題方法

1. 分析 A(x)

   public static int A(int x) {
       if (x < 30) x = A(x+5) + B(x);
       return x;
   }
   

   • 基礎情況：x >= 30 時直接回傳 x，不會有 * 輸出。
   • 遞迴情況：每次把 x 增加 5，直到達到或超過 30，期間會呼叫 B(x)，B 會輸出 * 並回傳 4x。

2. 計算 A(4)

   • 呼叫序列：A(4) → A(9) → A(14) → A(19) → A(24) → A(29) → A(34)

   • A(34) 為基礎情況，回傳 34。

   • 由內而外累加 B 的回傳值（同時輸出 *）：

     呼叫	B(x) 回傳	累計 A 值
     B(29)	$4·29 = 116$	$34 + 116 = 150$
     B(24)	$4·24 = 96$	$150 + 96 = 246$
     B(19)	$4·19 = 76$	$246 + 76 = 322$
     B(14)	$4·14 = 56$	$322 + 56 = 378$
     B(9)	$4·9 = 36$	$378 + 36 = 414$
     B(4)	$4·4 = 16$	$414 + 16 = 430$

   • 因此 A(4) = 430，且在遞迴過程中共輸出 6 個 *。

3. 計算 B(4)

   • B(4) 直接輸出 *，回傳 $4·4 = 16$。

4. 分析 C(x)

   public static int C(int x) {
       System.out.print("*");
       return 3 * A(x-4);
   }
   

   • 先輸出一個 *，再呼叫 A(x-4)。

核心觀念

本題的核心考點在於 Java 的變數作用域（Variable Scope）與例外處理機制（Exception Handling: try-catch-finally）：

1. 區塊作用域（Block Scope）：
   在 Java 中，任何在 {} 程式碼區塊內宣告的區域變數（Local Variable），其有效範圍僅限於該區塊內部。離開宣告它的區塊後，該變數即無法被辨識與存取。
2. try-catch-finally 的變數可見性：
   try、catch 與 finally 分屬三個獨立的程式碼區塊。若變數僅宣告於 try 區塊內部，則 catch 區塊與 finally 區塊均無法存取該變數，否則在編譯階段即會產生「找不到符號（cannot find symbol）」之編譯錯誤（Compile-Time Error）。
3. 例外拋出與流程控制：
   Float.parseFloat(str) 在解析非數字格式字串（如 "invalid"）時，會拋出 NumberFormatException。程式若能正常編譯，執行時將跳過 try 區塊後續指令，直接進入對應的 catch 區塊處理，最後無論是否發生例外，都一定會執行 finally 區塊。

---

解題方法與錯誤分析

1. 能否執行之判定

無法執行（無法通過編譯）。

2. 錯誤處指正

• 錯誤位置 1：第 6 行 catch (NumberFormatException nfe) { f = 0; } 中的 f = 0;。
• 錯誤位置 2：第 8 行 finally { System.out.println(f); } 中的 System.out.println(f);。
• 原因說明：
  變數 f 宣告於 try { ... } 區塊之內：

  try {
      float f = Float.parseFloat(str);
  }
  

  依 Java 作用域規則，f 的存取範圍僅限於該 try 區塊。緊隨其後的 catch 區塊與 finally 區塊並不在 f 的有效作用域內，因此編譯器在編譯 f = 0; 與 System.out.println(f); 時，皆會回報 cannot find symbol 錯誤，程式根本無法編譯產生 .class 檔，遑論執行。

3. 改正方式

將區域變數 f 的宣告提升至 try-catch-finally 結構之外（即 parse 方法的層級），並給予適當的初始值（例如 0.0f 或 0），使 try、catch 與 finally 區塊均能合法存取該變數。

改正後的完整程式碼：