Go中字符串的遍历

首先说一下go中的字符串类型：

创新互联主要从事成都做网站、成都网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务兴县,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18980820575

字符串就是一串固定长度的字符连接起来的字符序列。Go的字符串是由单个字节连接起来的。Go语言的字符串的字节使用UTF-8编码标识Unicode文本。

下面介绍字符串的三种遍历方式，根据实际情况选择即可。

该遍历方式==缺点==：遍历是按照字节遍历，因此如果有中文等非英文字符，就会出现乱码,比如要遍历"abc北京"这个字符串，效果如下:

可见这不是我们想要的效果，根据utf-8中文编码规则，我们要str[3]str[4]str[5]三个字节合起来组成“北”字及 str[6]str[7]str[8]合起来组成“京”字。由此引出下面第二种遍历方法。

该方式是按照字符遍历的，所以不会出现乱码，如下：

运行结果：

从图中可以看到第二个汉子“京”的开始下标是6，直接跳过了4和5，可见确实依照utf8编码方式将三个字节组合成了一个汉字，str[3]-str[5]组合成“北”字，str[6]-str[8]组合成了“京”字。

由于下标的不确定性，所以引出了下面的遍历方式。

1 可以先将字符串转成 []rune 切片

2 再用常规方法进行遍历

运行效果：

由此可见下标是按1递增的，没有产生跳跃现象。

go语言string之Buffer与Builder

操作字符串离不开字符串的拼接，但是Go中string是只读类型，大量字符串的拼接会造成性能问题。

拼接字符串，无外乎四种方式，采用“+”，“fmt.Sprintf()”,"bytes.Buffer","strings.Builder"

上面我们创建10万字符串拼接的测试，可以发现"bytes.Buffer","strings.Builder"的性能最好，约是“+”的1000倍级别。

这是由于string是不可修改的，所以在使用“+”进行拼接字符串，每次都会产生申请空间，拼接，复制等操作，数据量大的情况下非常消耗资源和性能。而采用Buffer等方式，都是预先计算拼接字符串数组的总长度（如果可以知道长度），申请空间，底层是slice数组，可以以append的形式向后进行追加。最后在转换为字符串。这申请了不断申请空间的操作，也减少了空间的使用和拷贝的次数，自然性能也高不少。

bytes.buffer是一个缓冲byte类型的缓冲器存放着都是byte

是一个变长的 buffer，具有 Read 和Write 方法。 Buffer 的 零值 是一个 空的 buffer，但是可以使用，底层就是一个 []byte， 字节切片。

向Buffer中写数据，可以看出Buffer中有个Grow函数用于对切片进行扩容。

从Buffer中读取数据

strings.Builder的方法和bytes.Buffer的方法的命名几乎一致。

但实现并不一致，Builder的Write方法直接将字符拼接slice数组后。

其没有提供read方法，但提供了strings.Reader方式

Reader 结构:

Buffer:

Builder:

可以看出Buffer和Builder底层都是采用[]byte数组进行装载数据。

先来说说Buffer:

创建好Buffer是一个empty的，off 用于指向读写的尾部。

在写的时候，先判断当前写入字符串长度是否大于Buffer的容量，如果大于就调用grow进行扩容，扩容申请的长度为当前写入字符串的长度。如果当前写入字符串长度小于最小字节长度64，直接创建64长度的[]byte数组。如果申请的长度小于二分之一总容量减去当前字符总长度，说明存在很大一部分被使用但已读，可以将未读的数据滑动到数组头。如果容量不足，扩展2*c + n 。

其String()方法就是将字节数组强转为string

Builder是如何实现的。

Builder采用append的方式向字节数组后添加字符串。

从上面可以看出，[]byte的内存大小也是以倍数进行申请的，初始大小为 0，第一次为大于当前申请的最大 2 的指数，不够进行翻倍.

可以看出如果旧容量小于1024进行翻倍，否则扩展四分之一。（2048 byte 后，申请策略的调整）。

其次String()方法与Buffer的string方法也有明显区别。Buffer的string是一种强转，我们知道在强转的时候是需要进行申请空间，并拷贝的。而Builder只是指针的转换。

这里我们解析一下 *(*string)(unsafe.Pointer(b.buf)) 这个语句的意思。

先来了解下unsafe.Pointer 的用法。

也就是说，unsafe.Pointer 可以转换为任意类型，那么意味着，通过unsafe.Pointer媒介，程序绕过类型系统，进行地址转换而不是拷贝。

即*A = Pointer = *B

就像上面例子一样，将字节数组转为unsafe.Pointer类型，再转为string类型，s和b中内容一样，修改b,s也变了，说明b和s是同一个地址。但是对s重新赋值后，意味着s的地址指向了“WORLD”,它们所使用的内存空间不同了，所以s改变后，b并不会改变。

所以他们的区别就在于 bytes.Buffer 是重新申请了一块空间，存放生成的string变量， 而strings.Builder直接将底层的[]byte转换成了string类型返回了回来，去掉了申请空间的操作。

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") } }

现代编程釆用什么方法?

现代化编程应该是：不强制用相同的 IDE，统一的代码风格，方便的依赖管理，持续集成，版本控制等。

在我的青少年时期，我涉猎了编程基础和一些汇编。当我学习了 Turbo Pascal 之后这事更进了一步，它提供了一种最早期的集成开发环境（IDE）。我觉得这下合我心意了。实际上，IDE 是一种让你在一个友好的环境内，方便地编写、编译、调试和运行代码的程序。Turbo Pascal 没有太多的图形界面（它基于文本），但它有菜单和窗口。你可以进入调试模式，跟踪变量的值等等。

然后我转到了 Delphi （一种图形化的 Turbo Pascal），它拥有到今天看来仍然不错的出色 IDE。我用 Visual Basic 设计了一个“会报时的钟”，当时发表在 Bulletin Board Systems（使用 Windows 3.1 的一个系统）。那之后我发现了 Visual Studio。有好几年我的 C++ 编程都是借用的 Visual Studio。以上就是我一直使用的所有 IDE。

早在八十年代初，Smalltalk 就有了著名的强大图形化 IDE（Youtube 视频）。

我认为，使用 IDE 并不代表着“现代化”。现在的 IDE 和过去的 IDE 非常相像。虽然我们编程的内容改变了，但在很多情况下，我们如何编程却没有改变。在我的 Dell 笔记本电脑里装着最新版 Visual Studio。换做 20 年前的我，也能完美地轻松上手它。调试、代码补全、远程代码执行，它和以前很像。事实上，Visual Studio 从未与 Turbo Pascal 相差很大过。而我发现这非常令人沮丧。我以为我们应该取得比这更快的进步。

我提出了现代化编程在桌面外观上难有作为的观点。图形化用户界面（GUI）只是表层。现代化编程技术都是关于流程和实际工具的，而不是它们之上的表层。我不在乎你是否使用 Eclipse 或 Emacs，这和你如何现代化毫不相关。

那么，什么是“现代化”？

编码是社会化的

在 20 年前，要求你公司里的每个人都使用相同的 IDE，并且要唯一依赖于这种 IDE 来构建、测试和部署代码，这是很明智的。但在你公司外有很多聪明的人，他们往往不使用你这种 IDE。如今，你可以触及他们了。这意味着对于所采用的工具和流程你必须明智。

如果你嘲弄使用 Atom 文本编辑器、Visual Studio 或者 Emacs 编程的人，那你就不是社会化的。你需要尽可能的包容，否则就会付出代价。

Go 语言有自己的格式化工具

我不在乎在你保存的时候，是不是自动重新格式化代码，或者有没有点击重新格式化按钮，或者是不是输入 go fmt，这些都一样。但它无疑是一个卓越的现代化的想法。这就是进步。所有的编程语言都应该为用户强加一个唯一的代码格式。别再 bikeshedding（过于关心旁枝末节，而忽视主要问题）。

我们很清楚 Java 拥有规范，但规范是不够的。我们需要一个工具，能把代码作为输入，并生成一个唯一定义了的输出，它能处理从行长度到空格的所有问题。

这个工具的目标是对于应该如何格式化代码，不再有任何可能有的争议，而且产生正确的格式不费吹灰之力。我简直无法告诉你这是多么的重要。

像 Rust、Go、Swift 这样的编程语言有自己的程序包管理系统

因此，例如在 Swift 中，我可以创建一个名为 Package.swift 的小文本文件，并把它放入我项目的根文件，在那里声明我的依赖。

importPackageDescription

letpackage = Package(

name: "SwiftBitsetBenchmark",

dependencies: [

.Package(url: "",

majorVersion: 0),

.Package(url: "",

majorVersion: 0)

]

)

然后我可以输入 swift build，软件会自动抓取依赖代码，并构建我的程序。这在 Swift 运行的所有地方通用。你使用哪种文本编辑器和 IDE 都没关系。

你不想使用文本编辑器，而更喜欢图形界面？可以。都没有区别。

为什么那样显得现代化？因为自动地解决依赖关系而不费吹灰之力，对于 20 年前的我来说就像魔术。并且自动地、系统地解决依赖关系是极其重要的。我不想永远都不得不手动安装和部署一个依赖项。我希望其他人能够在几秒内把我的库添加到他们项目中，而不是几分钟或是几小时。

是的,你可以将它添加到现有的语言(如：Java 的 Maven 或是 IED)但需要有一个唯一的方法让它起效。

像 Rust、Go、Swift 这样的编程语言，在一开始就支持单元测试。

比如在 Go 里，创建一个 filemyproject_test.go，然后添加 func TestMyStuff（t * testing.T）这样的函数，然后输入 go test 既可。

在 20 年前，几乎没有人测试他们的代码，而今天已经是一个必要要求，您和它需要以一种唯一的方式来做，这样你就可以在项目之间移动，还总是知道如何测试了。

如果不能在你的代码中立刻认出健全的单元测试，我会设想你的代码严重损坏了。

持续集成

代码更改时，你想要一个远程工具来获取新代码，并测试它，以便可以提前停止回归。人们可以在你的代码上运行测试还不够，他们还需要看到自动化测试的结果，自行检查最终的故障。

持续集成是较大规模计划的一部分：你必须在你编程的时候疯狂地自动化程序。体力劳动应该最小化。有时候这意味着你真的应该只是点击一个按钮，无论是通过一个图形化用户界面，还是命令窗口，但它不意味着需要反复地遵循一系列复杂的命令。

版本控制

20 年前，你在桌面上编写代码，并通过电子邮件发送新代码（作为补丁）是讲得通的。但这只在缓慢的合作节奏中有意义。如今，这么做是愚蠢的。任何差于 Git 的都是落后的。注意，如今甚至微软构建 Windows 也使用 Git。

那么，当你共事于从来没有听过现代编程的聪明学生会发生什么呢？他们看一个类似 go get 的命令，只看得到表层（一个命令行）。他们认为这是落后的。漂亮的图形在哪？

他们使用一个好看的 IDE 工作，像是 Visual Studio 或 Eclipse，并确信自己是现代化的，完全无视 IDE 可以追溯到几十年前的事实。然后并没有使用 IDE 的优势，比如更好的功能可见性和更快的操作，而是在其他地方使用现代化编程技术。他们坚持守旧派编程：

没有测试。至少，没有自动化和系统化的测试。

在一个具体的设置上难以处理依赖关系。

没有自动化。没有持续集成，没有自动化部署。

他们编程就像我几十年前使用 Turbo Pascal 入门的时候。尽管 Turbo Pascal 有图形化用户界面（GUI），但它是非常古老的学校。

当前标题：go语言bitset go语言和python哪个好
链接URL：http://lswzjz.com/article/dogodic.html