Wie erhalte ich byte32-ähnliche Daten und gebe denselben Index wie die Ethereum-Brieftasche in web3.js zurück?

Solidity byte32 gibt in web3, Remix-Browser-Compiler und Ethereum-Wallet einen anderen Wert zurück

Im Vertrag habe ich gerade byte32-Werte hinzugefügt und es zurückgegeben, aber in der Web3-API, dem Remix-Browser-Compiler und der Ethereum-Brieftasche, die zum Zeitpunkt der Rückgabe einen anderen Wert und Index zeigen.

Ethereum Wallet zeigt genaue Daten mit 0x

Remix-Browser-Compiler zeigt einen anderen Wert an

Web3-API mit unterschiedlichen Daten und Index

Vertrag :

pragma solidity ^0.4.11;

contract ABC{

    struct Data{
        bytes32 data;
        bytes32 data2;
        bytes32 data3;
        bytes32 data4;
        bytes32 data5;
    }
    mapping(uint => Data) public metaData;

    function ABC(){

    }

    function addData(bytes32 data,
        bytes32 data2,
        bytes32 data3,
        bytes32 data4,
        bytes32 data5){
        metaData[0]=Data(data,data2,data3,data4,data5);
    }

    function getData() returns(bytes32,bytes32,bytes32,bytes32,bytes32){
        return (metaData[0].data,metaData[0].data2,metaData[0].data3,metaData[0].data4,metaData[0].data5);
    }
}

Eingabedaten :"d4967590eb024589dfb6b9e48a576eb49ebc19d764b0d1d67dc21975e7258e97","1","1","1","065e0be95fb43db528a20ba65c0e575e33cd4a9e1ca089dba4efff24596e8553"

Im Remix Solidity BrowserGeben Sie hier die Bildbeschreibung ein

Im Ethereum-WalletGeben Sie hier die Bildbeschreibung ein

In Web3.jsGeben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

Antworten (1)

Dieses Problem wird verursacht, weil Javascript keinen nativen bytes32-Typ hat. Und die Mehrdeutigkeit beim Interpretieren von Zeichenfolgen als bytes32-Werte.

Wenn Sie Probleme vermeiden möchten, müssen Sie hexadezimalen Zeichenfolgen "0x" voranstellen und auf 64 Zeichen auffüllen, wo nötig mit Nullen auffüllen.

So zum Beispiel:

["0xd4967590eb024589dfb6b9e48a576eb49ebc19d764b0d1d67dc21975e7258e97",
"0x0000000000000000000000000000000000000000000000000000000000000001",
"0x0000000000000000000000000000000000000000000000000000000000000001",
"0x0000000000000000000000000000000000000000000000000000000000000001",
"0x065e0be95fb43db528a20ba65c0e575e33cd4a9e1ca089dba4efff24596e8553"]

Erklärung der Probleme:

  • Wenn Sie die Zeichenfolge "d4967590eb024589dfb6b9e48a576eb49ebc19d764b0d1d67dc21975e7258e97"ohne "0x"davor übergeben, wird sie als rohe 64 Byte interpretiert. Führend zur exadezimalen Zeichenfolge "64343936373539306562303234353839646662366239653438613537366562343965626331396437363462306431643637646332313937356537323538653937". Welches ist das Ergebnis, das in Ihrem web3.js-Beispiel gezeigt wird. Ein weiteres ernsteres Problem hier ist, dass der erste Parameter nicht auf 32 Bytes gekürzt wird, sondern stattdessen auf den zweiten Parameter rutscht, der die anderen Parameter drückt. Dies geschieht, wenn Sie Daten nicht validieren.

  • Wenn Sie den Wert 1 übergeben und der Parameterformatierer einen String erwartet, wird Javascript Ihre Zahl gerne als String interpretieren und wir haben zwei Fälle:

    • Es wird als Rohzeichenfolge interpretiert. 0x31 ist der ASCII-Wert des Zeichens „1“. Es wird mit '0' gefüllt, um die 32 Bytes oder 64 Hexadezimalziffern zu erhalten, was '0x31000000000000000000000000000000000000000000000000000000000000' ergibt, was die Fehlershow im Remix-Beispiel ist.
    • Es wird als hexadezimaler String interpretiert und mit '0' gefüllt, um 32 Bytes oder 64 hexadezimale Ziffern zu erhalten. Das ergibt '0x1000000000000000000000000000000000000000000000000000000000000' als Ergebnis in Ihrem Ethereum-Wallet-Beispiel.

Wenn Sie Probleme vermeiden möchten, stellen Sie einfach "0x" voran und geben Sie die vollen 64 Hexadezimalziffern an.

Perfekte Antwort. es funktioniert gut.