編碼輸入參數

我用一個方法創建了一個簡單的測試合約：

pragma solidity ^0.4.24;

contract SimpleTest {

   function testFunc(string name, bool isFirst) public {
       //do stuff
   }

}

我用值呼叫函式，"test name", true一旦事務執行，我會看到以下編碼輸入：

0x1a387720
0000000000000000000000000000000000000000000000000000000000000040
0000000000000000000000000000000000000000000000000000000000000001
0000000000000000000000000000000000000000000000000000000000000009
74657374206e616d650000000000000000000000000000000000000000000000

根據文件，其中應該包括函式選擇器和每個輸入參數的 32 字節字元串。為什麼我得到 4 個 32 字節的字元串而不是 2 個？我不清楚如何解碼此輸入以獲取輸入參數的實際值。

我使用 Remix 來測試這個案例。

交易根據合約 ABI 規范進行編碼。很難通過，但這些文件有你問題的所有答案。

---

有問題的交易傳入兩個參數：一個動態字元串 ( name) 和一個靜態布爾值 ( isFirst)。在對參數進行編碼時，EVM 會查看參數是靜態的還是動態的。

靜態參數以相當簡單的方式編碼——它們被轉換為十六進製表示，然後連接到輸入數據十六進製字元串中。

動態值更有趣。使用文件的這一部分來完全理解，但想法是編碼數據是數據的位置。在所有動態類型之後，編碼數據本身然後連接到輸入數據十六進製字元串的末尾。對於動態類型，然後包含參數的長度，然後是數據本身。

分解您發布的交易：

0x1a387720000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000974657374206e616d65000000000000000000000000000000000000000000

0x1a38772

這是被呼叫函式的方法 ID（在本例中為testFunc(string, bool)）

0000000000000000000000000000000000000000000000000000000000000040

這是第一個（動態）參數的位置。這是name生活的地方，但不是數據本身。

0000000000000000000000000000000000000000000000000000000000000001

這是isFirst與交易一起發送的參數。1相當於true。

0000000000000000000000000000000000000000000000000000000000000009

這是動態的長度name。在這種情況下，字元串有 9 個字元。

74657374206e616d650000000000000000000000000000000000000000000000

“測試名稱”的 ASCII 十六進製表示。

引用自：https://ethereum.stackexchange.com/questions/68558