1.原文上链。

这种主要适用于只上链一个字段的情况，比如我们做了一个许愿的DAPP，就是用户将自己的心愿写到区块链上，而这个心愿可能就是几个字，也可能是长篇大论，但不管怎么样，他可以认为就是一个文本字符串，而我们的上链操作就是将整个字符串直接上链存储。

2.格式化后上链。

这种主要适用于业务数据上链的场景，比如企业要将自己生成的所有产品上链，而产品本身具有很多属性，比如：材质、总量、类型等等。企业可以将产品的所有要上链的属性构建成XML对象或者JSON对象（个人更推荐使用JSON对象），然后将格式化（序列化）后的产品对象上链。不推荐使用protobuf、rlp等数据库不支持的序列化方法，一般很多NoSQL数据库是支持JSON对象的索引的，所以如果我们存入的是JSON对象，那么还可以直接对存入的对象进行各种条件的检索。

3.哈希摘要上链。

这种主要用于文件上链的场景。前面说到，区块链不适合将大文件直接上链，而哈希算法可以将大文件计算出一个固定长度的摘要。（比如SHA256算法，算出来32字节的摘要）使用哈希摘要可以保证原始数据不会被篡改，因为文件一旦被篡改，那么算出来的哈希值和链上的哈希值不匹配。而为了预防文件存储在某个服务器硬盘上，万一服务器硬盘坏了，那么数据就永远丢失了这种情况，我们可以采用IPFS这种分布式存储技术。IPFS负责将大文件切割成很多个小块，然后将小块分散存储在多台服务器中，从而避免了单机故障造成文件丢失的可能。同时IPFS在文件分割和存储的同时，也会计算出一个哈希摘要，我们可以将该哈希摘要上链（可能还需要对哈希进行加密），在获得文件准确的哈希值，就可以通过IPFS获得原始文件。

4.加密后上链。

这种上链方式好主要适用于不希望其他方看到的机密敏感数据。加密一般采用对称加密，而加密的密钥每个文件都不一样，我们可以将密钥用上链方的公钥进行加密，这样只有私钥持有方才能解密出对称密钥，然后再用对称密钥解密链上数据。为什么不直接用数据持有者的公钥加密呢？因为一方面对称加密的性能远远高于非对称加密，另一方面，如果我们希望将某个链上数据共享给另一方，那么他只需要解密对称密钥，然后将该密钥用对方的公钥加密上链，这样对方就可以使用自己的私钥解密出对称密钥，然后用对称密钥解密出文件。