字符串值和字符串文字之间的区别

Question

根据这篇关于字符串的 golang 博客文章（ https://blog.golang.org/strings ），有一行说明“...字符串值可以包含任意字节；正如我们在这篇文章中展示的，字符串文字总是包含UTF-8 文本，只要它们没有字节级转义。”

有什么不同？

Answer 1

这种区别取决于Go 语言规范中字符串文字和字符串值的定义：

字符串文字：字符串文字表示通过连接字符序列获得的字符串常量。

字符串值：字符串值是一个（可能是空的）字节序列。

以及源代码在编码为 UTF-8 文本的源文件中表示的要求：

源代码表示：源代码是 UTF-8 编码的 Unicode 文本。

最重要的是，请注意字符串文字被定义为常量，因此其值完全在编译时定义。

---

将一组有效的 Go 源文件视为符合语言规范的文件。 根据定义，此类源文件必须使用有效的 UTF-8 编码。 由于在编译时从源文件的内容中知道字符串文字的值，我们通过构造看到任何字符串文字都必须包含有效的 UTF-8 文本。

如果我们忽略字节级转义序列，我们可以进一步看到结果二进制文件中字符串文字的编译输出也必须包含有效的 UTF-8，因为它是从源文件中的 UTF-8 值编译的。

---

字节序列？ 一个概括

但是，字符串值被定义为字节序列^1，因此不要求它们本身包含有效的 UTF-8。 此类非 UTF-8 文本可能来自程序从编译时定义的字符串文字以外的输入接收的值，例如通过套接字或本地管道接收的数据、从文件中读取的数据或包含字节级转义的字符串文字序列。

¹_{正如博客文章所述，对于大多数用途，此字节序列可被视为字节切片 ( []byte )。 然而，这并不严格正确，因为底层实现不使用切片； 字符串是不可变的，不需要单独跟踪它们的容量。 调用cap(str)其中str的类型为string是错误的。}

字节级转义序列

字节级转义序列提供了一种使用 UTF-8 表示对非 UTF-8 值进行编码的机制。 此类序列允许以 UTF-8 格式表示任意字节，以生成有效的 Go 源文件并满足语言规范。

例如，字节序列b2 bd （这里的字节表示为空格分隔的两位十六进制数）不是有效的 UTF-8 。 尝试使用 UTF-8 解码器解码此字节序列将产生错误：

var seq = "\xb2\xbd"
fmt.Println("Is 'seq' valid UTF-8 text?", utf8.Valid([]byte(seq)))

$ go run ./main.go
Is 'seq' valid UTF-8 text? false

因此，虽然这样的字节序列可以存储在 Go 中的字符串中，但无法直接在 Go 源文件中表达。 任何这样做的源文件都是无效的 Go，词法分析器将拒绝它（见下文）。

反斜杠转义序列提供了一种机制，用于将此字节字符串分解为满足工具链的有效 UTF-8 表示。 解释后的 Go 字符串文字"\\xb2\\xbd"表示使用 ASCII 字符序列的字符串，可以用 UTF-8 表示。 编译时，此序列被解析以在编译输出中生成一个包含字节序列b2 bd的字符串。

---

例子

我将提供一个工作示例来更具体地演示这一点。 由于我们将生成无效的源文件，因此我不能轻易使用 Go 游乐场； 我在我的机器上使用了 go 工具链。 工具链是go version go1.11 darwin/amd64 。

考虑以下简单的 Go 程序，其中可以为字符串myStr指定值。 为方便起见，我们将空格（字符串my value:之后的字节序列20 20 20 ）替换为所需的字节。 这使我们可以在稍后反汇编二进制文件时轻松找到编译后的输出。

package main

import "fmt"

func main() {
    myStr := "my value:   "
    fmt.Println(myStr)
}

我使用十六进制编辑器将无效的 UTF-8 字节序列b2 bd插入到myStr空白的最后一个字节中。 以下代表； 为简洁起见省略了其他行：

00000030: 203a 3d20 22b2 bd20 220a 0966 6d74 2e50   := ".. "..fmt.P

尝试构建此文件会导致错误：

$ go build ./test.go
# command-line-arguments
./test.go:6:12: invalid UTF-8 encoding

如果我们在编辑器中打开文件，它会以自己的方式（可能是特定于平台的）解释字节，并在保存时发出有效的 UTF-8。 在这个基于 OS X 的系统上，使用vim ，序列被解释为 Unicode U+00B2 U+00BD，或²½ 。 这满足了编译器的要求，但源文件和因此编译的二进制文件现在包含与最初预期的字节序列不同的字节序列。 下面的代码转储展示了序列c2 b2 c2 bd ，源文件的十六进制转储也是如此。 （参见第 1 行的最后两个字节和第 2 行的前两个字节。）

$ gobjdump -s -j __TEXT.__rodata test | grep -A1 "my value"                                                                                         
 10c4c50 63746f72 796d7920 76616c75 653ac2b2  ctorymy value:..
 10c4c60 c2bd206e 696c2065 6c656d20 74797065  .. nil elem type

为了恢复原始字节序列，我们可以这样更改字符串定义：

myStr := "my value: \xb2\xbd"

转储编辑器生成的源文件会产生一个有效的 UTF-8 序列5c 78 62 32 5c 78 62 64 ，即 ASCII 字符\\xb2\\xbd的 UTF-8 编码：

00000030: 203a 3d20 226d 7920 7661 6c75 653a 205c   := "my value: \
00000040: 7862 325c 7862 6422 0a09 666d 742e 5072  xb2\xbd"..fmt.Pr

然而，通过构建此源文件生成的二进制文件表明编译器已将此字符串文字转换为包含所需的b2 bd序列（第四列的最后两个字节）：

10c48b0 6d792076 616c7565 3a20b2bd 6e6f7420  my value: ..not

Answer 2

一般来说，字符串值和文字没有区别。 字符串文字只是初始化新字符串变量（字符串原样）的方法之一。