go语言大端小端 go语言前后端分离

golang之大端序、小端序当分别处于大小端模式下go语言大端小端的内容存放如下
(1)大端模式存储(存储地址为16位)
地址数据
0x0004(高地址)0x44
0x00030x33
0x00020x22
0x0001(低地址)0x11
(2)小端模式存储(存储地址为16位)
地址数据
0x0004(高地址)0x11
0x00030x22
0x00020x33
0x0001(低地址)0x44
在前面也简单阐述go语言大端小端了大小端序go语言大端小端的定义并结合简单实例来说明,接下来会给出详细实例来说明go语言大端小端:
1、大端序(Big-Endian):或称大尾序
一个类型: int32 的数 0X0A0B0C0D的内存存放情况
数据是以8bits为单位
2、小端序(little-endian):或称小尾序
比如0x00000001
大端序:内存低比特位 00000000 00000000 00000000 00000001 内存高比特位
小端序:内存低比特位 10000000 00000000 00000000 00000000 内存高比特位
其实在前面罗列出那么东西,最终是为了接下来讲述的在golang中涉及到网络传输、文件存储时的选择 。一般来说网络传输的字节序,可能是大端序或者小端序 , 取决于软件开始时通讯双方的协议规定 。TCP/IP协议RFC1700规定使用“大端”字节序为网络字节序 , 开发的时候需要遵守这一规则 。默认golang是使用大端序 。详情见golang中包encoding/binary已提供了大、小端序的使用
输出结果:
16909060 use big endian:
int32 to bytes: [1 2 3 4]### [0001 0002 0003 0004]
bytes to int32: 16909060
16909060 use little endian:
int32 to bytes: [4 3 2 1]### [0004 0003 0002 0001]
bytes to int32: 16909060
在RPCX框架中关于RPC调用过程涉及的传递消息进行编码的,采用的就是大端序模式
Go语言中的字节序Go中的binary包实现了简单的数字与字节序列的转换以及变长值的编解码
package main
import ( "fmt" "bytes" "encoding/binary" ) func main(){ n := 0x12345678 bytesBuffer := bytes.NewBuffer([]byte{}) //BigEndian 大端顺序存储 LittleEndian小端顺序存储 binary.Write(bytesBuffer, binary.BigEndian, int32(n)) data:=bytesBuffer.Bytes() fmt.Printf("[0]: %#x addr:%#x\n",data[0],data[0]) fmt.Printf("[0]: %#x addr:%#x\n",data[1],data[1]) fmt.Printf("[0]: %#x addr:%#x\n",data[2],data[2]) fmt.Printf("[0]: %#x addr:%#x\n",data[3],data[3]) }
输出
[0]: 0x12 addr:0xc042010248 [1]: 0x34 addr:0xc042010249 [2]: 0x56 addr:0xc04201024a [3]: 0x78 addr:0xc04201024b
也可以使用下面的方式
n := 0x12345678 var data []byte = make([]byte,4) //操作的都是无符号整型 binary.BigEndian.PutUint32(data,uint32(n))
可以使用下面的方式判断当前系统的字节序类型
const INT_SIZE int = int(unsafe.Sizeof(0))
//判断我们系统中的字节序类型 func systemEdian() { var i int = 0x1 bs := (*[INT_SIZE]byte)(unsafe.Pointer(i)) if bs[0] == 0 { fmt.Println("system edian is little endian") } else { fmt.Println("system edian is big endian") } }
驳狗屎文 "我为什么放弃Go语言此篇文章流传甚广, 其实里面没啥干货, 而且里面很多观点是有问题的. 这个文章在 golang-china 很早就讨论过了.
最近因为 Rust 1.0 和 1.1 的发布, 导致这个文章又出来毒害读者.
所以写了这篇反驳文章, 指出其中的问题.
有好几次,当我想起来的时候,总是会问自己:我为什么要放弃Go语言?这个决定是正确的吗?是明智和理性的吗?其实我一直在认真思考这个问题 。
开门见山地说,我当初放弃Go语言(golang),就是因为两个“不爽”:第一,对Go语言本身不爽;第二,对Go语言社区里的某些人不爽 。毫无疑问,这是非常主观的结论 。但是我有足够详实的客观的论据,用以支撑这个看似主观的结论 。

推荐阅读