在今年夏天我们对Kubernetes的评估成功之后，我们收到了大量Go项目的安全评估需求。为此，我们将在其他编译语言中使用过的安全评估技术和策略调整适配到多个Go项目中。

我们从了解语言的设计开始，识别出开发人员可能无法完全理解语言语义特性的地方。多数这些被误解的语义来自我们向客户报告的调查结果以及对语言本身的独立研究。尽管不是详尽无遗，但其中一些问题领域包括作用域、协程、错误处理和依赖管理。值得注意的是，其中许多与运行时没有直接关系。默认情况下，Go运行时本身的设计是安全的，避免了很多类似C语言的漏洞。

对根本原因有了更好地理解后，我们搜索了现有的能帮助我们快速有效检测客户端代码库的工具。结果我们找到一些静态和动态开源工具，其中包括了一些与Go无关的工具。为了配合这些工具使用，我们还确定了几种有助于检测的编译器配置。

一. 静态分析

由于Go是一种编译型语言，因此编译器在生成二进制可执行文件之前就检测并杜绝了许多潜在的错误模式。虽然对于新的Go开发人员来说，这些编译器的输出比较烦，但是这些警告对于防止意外行为以及保持代码的清洁和可读性非常重要。

静态分析趋向于捕获很多未包括在编译器错误和警告中的悬而未决的问题。在Go语言生态系统中，有许多不同的工具，例如go-vet、staticcheck和analysis包中的工具。这些工具通常会识别出诸如变量遮蔽、不安全的指针使用以及未使用的函数返回值之类的问题。调查这些工具显示警告的项目区域通常会发现可被利用(进行安全攻击)的功能特性。

这些工具绝不是完美的。例如，go-vet可能会错过非常常见的问题，例如下面例子中这种。

package main

import "fmt"

func A() (bool, error) { return false, fmt.Errorf("I get overridden!") }

func B() (bool, error) { return true, nil }

func main() {
    aSuccess, err := A()
    bSuccess, err := B()
    if err != nil {
        fmt.Println(err)
    }
    fmt.Println(aSuccess, ":", bSuccess)
}

这个例子未使用A函数的err返回值，并在表达式左侧为bSuccess赋值期间立即重新对err做了赋值。编译器针对这种情况不会提供警告，而go-vet也不会检测到该问题；errcheck也不会。实际上，能成功识别这种情况的工具是前面提到的staticcheck和ineffassign，它们将A的错误返回值标识为未使用或无效。

示例程序的输出以及errcheck，go-vet，staticcheck和ineffassign的检查结果如下：

$ go run .
false : true
$ errcheck .
$ go vet .
$ staticcheck .
main.go:5:50: error strings should not be capitalized (ST1005)
main.go:5:50: error strings should not end with punctuation or a newline (ST1005)
main.go:10:12: this value of err is never used (SA4006)
$ ineffassign .
main.go:10:12: ineffectual assignment to err

当您深入研究此示例时，您可能会想知道为什么编译器没有针对此问题发出警告。当程序中有未使用的变量时，Go编译器将出错，但此示例成功通过编译。这是由“短变量声明”的语义引起的。下面是短变量声明的语法规范：

ShortVarDecl = IdentifierList ":=" ExpressionList .

根据规范，短变量声明具有重新声明变量的特殊功能，只要：

• 重新声明在多变量短声明中。
• 重新声明的变量在同一代码块或函数的参数列表中声明较早。
• 重新声明的变量与先前的声明具有相同的类型。
• 声明中至少有一个非空白变量(“_”)是新变量。

所有这些约束在上一个示例中均得到满足，从而防止了编译器针对此问题产生编译错误。

许多工具都具有类似这样的极端情况，即它们在识别相关问题或识别问题但以不同的方式描述时均未成功。使问题复杂化的是，这些工具通常需要先构建Go源代码，然后才能执行分析。如果分析人员无法轻松构建代码库或其依赖项，这将使第三方安全评估变得复杂。

尽管存在这些困难，但只要付出一点点努力，这些工具就可以很好地提示我们在项目中从何处查找问题。我们建议至少使用gosec、go-vet和staticcheck。对大多数代码库而言，这些工具具有良好的文档和人机工效。他们还提供了针对常见问题的多种检查（例如ineffassign或errcheck）。但是，要对特定类型的问题进行更深入的分析，可能必须使用更具体的分析器，直接针对SSA开发定制的工具或使用semmle。

二. 动态分析

一旦执行了静态分析并检查了结果，动态分析技术通常是获得更深层结果的下一步。由于Go的内存安全性，动态分析通常发现的问题是导致硬崩溃(hard crash)或程序状态无效的问题。Go社区已经建立了各种工具和方法来帮助识别Go生态系统中这些类型的问题。此外，可以改造现有的与语言无关的工具以满足Go动态分析的需求，我们将在下面展示。

1. 模糊测试

Go语言领域中最著名的动态测试工具可能是Dimitry Vyukov的go-fuzz了。该工具使您可以快速有效地实施模糊测试，并且它已经有了不错的战利品。更高级的用户在猎错过程中可能还会发现分布式的模糊测试和libFuzzer的支持非常有用。

Google还发布了一个更原生的模糊器(fuzzer)，它拥有一个与上面的go-fuzz相似的名字：gofuzz。它通过初始化具有随机值的结构来帮助用户。与Dimitry的go-fuzz不同，Google的gofuzz不会生成夹具(harness)或协助提供存储崩溃时的输出信息、模糊输入或任何其他类型的信息。尽管这对于测试某些目标可能是不利的，但它使轻量级且可扩展的框架成为可能。

为了简洁起见，我们请您参考各自自述文件中这两个工具的示例。

• google/gofuzz#gofuzz
• dvyukov/go-fuzz#usage

2. 属性测试(property test)

译注：属性测试指编写对你的代码来说为真的逻辑语句（即“属性”），然后使用自动化工具来生成测试输入（一般来说，是指某种特定类型的随机生成输入数据），并观察程序接受该输入时属性是否保持不变。如果某个输入违反了某一条属性，则证明用户程序存在错误 – 摘自网络。

与传统的模糊测试方法不同，Go的testing包（通常用于单元测试和集成测试）为Go函数的“黑盒测试” 提供了testing/quick子包。换句话说，它提供了属性测试的基本原语。给定一个函数和生成器，该包可用于构建夹具，以测试在给定输入生成器范围的情况下潜在的属性违规。以下示例是直接摘自官方文档。

func TestOddMultipleOfThree(t *testing.T) {
    f := func(x int) bool {
        y := OddMultipleOfThree(x)
        return y%2 == 1 && y%3 == 0
    }
    if err := quick.Check(f, nil); err != nil {
        t.Error(err)
    }
}

上面示例正在测试OddMultipleOfThree函数，其返回值应始终为3的奇数倍。如果不是，则f函数将返回false并将违反该属性。这是由quick.Check功能检测到的。

虽然此包提供的功能对于属性测试的简单应用是可以接受的，但重要的属性通常不能很好地适合这种基本界面。为了解决这些缺点，诞生了leanovate/gopter框架。Gopter为常见的Go类型提供了各种各样的生成器，并且支持您创建与Gopter兼容的自定义生成器。通过gopter/commands子包还支持状态测试，这对于测试跨操作序列的属性是否有用很有有帮助。除此之外，当违反属性时，Gopter会缩小生成的输入。请参阅下面的输出中输入收缩的属性测试的简要示例。

Compute结构的测试夹具：

package main_test
import (
  "github.com/leanovate/gopter"
  "github.com/leanovate/gopter/gen"
  "github.com/leanovate/gopter/prop"
  "math"
  "testing"
)

type Compute struct {
  A uint32
  B uint32
}

func (c *Compute) CoerceInt () { c.A = c.A % 10; c.B = c.B % 10; }
func (c Compute) Add () uint32 { return c.A + c.B }
func (c Compute) Subtract () uint32 { return c.A - c.B }
func (c Compute) Divide () uint32 { return c.A / c.B }
func (c Compute) Multiply () uint32 { return c.A * c.B }

func TestCompute(t *testing.T) {
  parameters := gopter.DefaultTestParameters()
  parameters.Rng.Seed(1234) // Just for this example to generate reproducible results

  properties := gopter.NewProperties(parameters)

  properties.Property("Add should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Add()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Subtract should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Subtract()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Multiply should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Multiply()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Divide should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Divide()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.TestingRun(t)
}

执行测试夹具并观察属性测试的输出（除法失败）：

user@host:~/Desktop/gopter_math$ go test
+ Add should never fail.: OK, passed 100 tests.
Elapsed time: 253.291µs
+ Subtract should never fail.: OK, passed 100 tests.
Elapsed time: 203.55µs
+ Multiply should never fail.: OK, passed 100 tests.
Elapsed time: 203.464µs
! Divide should never fail.: Error on property evaluation after 1 passed
   tests: Check paniced: runtime error: integer divide by zero
goroutine 5 [running]:
runtime/debug.Stack(0x5583a0, 0xc0000ccd80, 0xc00009d580)
    /usr/lib/go-1.12/src/runtime/debug/stack.go:24 +0x9d
github.com/leanovate/gopter/prop.checkConditionFunc.func2.1(0xc00009d9c0)
    /home/user/go/src/github.com/leanovate/gopter/prop/check_condition_func.g
  o:43 +0xeb
panic(0x554480, 0x6aa440)
    /usr/lib/go-1.12/src/runtime/panic.go:522 +0x1b5
_/home/user/Desktop/gopter_math_test.Compute.Divide(...)
    /home/user/Desktop/gopter_math/main_test.go:18
_/home/user/Desktop/gopter_math_test.TestCompute.func4(0x0, 0x0)
    /home/user/Desktop/gopter_math/main_test.go:63 +0x3d
# snip for brevity;

ARG_0: 0
ARG_0_ORIGINAL (1 shrinks): 117380812
ARG_1: 0
ARG_1_ORIGINAL (1 shrinks): 3287875120
Elapsed time: 183.113µs
--- FAIL: TestCompute (0.00s)
    properties.go:57: failed with initial seed: 1568637945819043624
FAIL
exit status 1
FAIL    _/home/user/Desktop/gopter_math 0.004s

3. 故障注入

在攻击Go系统时，故障注入令人惊讶地有效。我们使用此方法发现的最常见错误包括对error类型的处理。因为error在Go中只是一种类型，所以当它返回时，它不会像panic语句那样自行改变程序的执行流程。我们通过强制生成来自最低级别(内核)的错误来识别此类错误。由于Go会生成静态二进制文件，因此必须在不使用LD_PRELOAD的情况下注入故障。我们的工具之一KRF使我们能够做到这一点。

在我们最近的Kubernetes代码库评估中，我们使用KRF找到了一个vendored依赖深处的问题，只需通过随机为进程和其子进程发起的read和write系统调用制造故障。该技术对通常与底层系统交互的Kubelet十分有效。该错误是在ionice命令出现错误时触发的，未向STDOUT输出信息并向STDERR发送错误。记录错误后，将继续执行而不是将STDERR的错误返回给调用方。这导致STDOUT后续被索引，从而导致索引超出范围导致运行时panic。

下面是导致kubelet panic的调用栈信息：

E0320 19:31:54.493854    6450 fs.go:591] Failed to read from stdout for cmd [ionice -c3 nice -n 19 du -s /var/lib/docker/overlay2/bbfc9596c0b12fb31c70db5ffdb78f47af303247bea7b93eee2cbf9062e307d8/diff] - read |0: bad file descriptor
panic: runtime error: index out of range

goroutine 289 [running]:
k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs.GetDirDiskUsage(0xc001192c60, 0x5e, 0x1bf08eb000, 0x1, 0x0, 0xc0011a7188)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs/fs.go:600 +0xa86
k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs.(*RealFsInfo).GetDirDiskUsage(0xc000bdbb60, 0xc001192c60, 0x5e, 0x1bf08eb000, 0x0, 0x0, 0x0)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs/fs.go:565 +0x89
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).update(0xc000ee7560, 0x0, 0x0)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:82 +0x36a
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).trackUsage(0xc000ee7560)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:120 +0x13b
created by
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).Start
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:142 +0x3f

下面例子：记录了STDERR日志但未将error返回调用方。

stdoutb, souterr := ioutil.ReadAll(stdoutp)
if souterr != nil {
    klog.Errorf("Failed to read from stdout for cmd %v - %v", cmd.Args, souterr)
}

当stdout为空，也尝试使用索引，这是运行时出现panic的原因：

usageInKb, err := strconv.ParseUint(strings.Fields(stdout)[0], 10, 64)

更完整的包含重现上述问题的步骤，可参见我们的Kubernetes最终报告附录G（第109页），那里详细介绍了针对Kubelet使用KRF的方法。

Go的编译器还允许将测量工具包含在二进制文件中，从而可以在运行时检测race状况，这对于将潜在的race识别为攻击者非常有用，但也可以用来识别对defer、panic和recover的不正确处理。我们构建了Trailofbits/on-edge来做到这一点：识别函数入口点和函数panic点之间的全局状态变化，并通过Go race检测器”泄露”此信息。有关OnEdge的更多详细信息，请参见我们以前的博客文章“在Go中选择正确panic的方式”。

实践中，我们建议使用：

• dvyukov/go-fuzz为组件解析输入建立夹具
• google/gofuzz用于测试结构验证
• leanovate/gopter用于增强现有的单元和集成测试以及测试规范的正确性
• Trailofbits/krf和Trailofbits/on-edge用于测试错误处理。

除KRF外，所有这些工具在实践中都需要付出一些努力。

三. 利用编译器的优势

Go编译器具有许多内置功能和指令(directive)，可帮助我们查找错误。这些功能隐藏在各种开关中中，并且需要一些配置才能达到我们的目的。

1. 颠覆类型系统

有时在尝试测试系统功能时，导出函数不是我们要测试的。要获得对所需的函数的测试访问权，可能需要重命名许多函数，以便可以将其导出，这可能会很麻烦。要解决此问题，可以使用编译器的build指令(directive)进行名称链接(name linking)以及导出系统的访问控制。作为此功能的示例，下面的程序（从Stack Overflow答案中提取）访问未导出的reflect.typelinks函数，并随后迭代类型链接表以识别已编译程序中存在的类型。

下面是使用linkname build directive的Stack Overflow答案的通用版本:

package main

import (
    "fmt"
    "reflect"
    "unsafe"
)

func Typelinks() (sections []unsafe.Pointer, offset [][]int32) {
    return typelinks()
}

//go:linkname typelinks reflect.typelinks
func typelinks() (sections []unsafe.Pointer, offset [][]int32)

func Add(p unsafe.Pointer, x uintptr, whySafe string) unsafe.Pointer {
    return add(p, x, whySafe)
}

//go:linkname add reflect.add
func add(p unsafe.Pointer, x uintptr, whySafe string) unsafe.Pointer

func main() {
    sections, offsets := Typelinks()
    for i, base := range sections {
        for _, offset := range offsets[i] {
            typeAddr := Add(base, uintptr(offset), "")
            typ := reflect.TypeOf(*(*interface{})(unsafe.Pointer(&typeAddr)))
            fmt.Println(typ)
        }
    }
}

下面是typelinks表的输出：

$ go run main.go
**reflect.rtype
**runtime._defer
**runtime._type
**runtime.funcval
**runtime.g
**runtime.hchan
**runtime.heapArena
**runtime.itab
**runtime.mcache
**runtime.moduledata
**runtime.mspan
**runtime.notInHeap
**runtime.p
**runtime.special
**runtime.sudog
**runtime.treapNode
**sync.entry
**sync.poolChainElt
**syscall.Dirent
**uint8

如果需要在运行时进行更精细的控制（即，不仅仅是linkname指令），则可以编写Go的中间汇编码，并在编译过程中包括它。尽管在某些地方它可能不完整且有些过时，但是teh-cmc/go-internals提供了有关Go如何组装函数的很好的介绍。

2. 编译器生成的覆盖图

为了帮助进行测试，Go编译器可以执行预处理以生成coverage信息。这旨在标识单元测试和集成测试的测试覆盖范围信息，但是我们也可以使用它来标识由模糊测试和属性测试生成的测试覆盖范围。Filippo Valsorda在博客文章中提供了一个简单的示例。

3. 类型宽度安全

Go支持根据目标平台自动确定整数和浮点数的大小。但是，它也允许使用固定宽度的定义，例如int32和int64。当混合使用自动宽度和固定宽度大小时，对于跨多个目标平台的行为，可能会出现错误的假设。

针对目标的32位和64位平台构建进行测试将有助于识别特定于平台的问题。这些问题通常在执行验证、解码或类型转换的时候发现，原因在于对源和目标类型属性做出了不正确的假设。在Kubernetes安全评估中就有一些这样的示例，特别是TOB-K8S-015：使用strconv.Atoi并将结果向下转换时的溢出（Kubernetes最终报告中的第42页），下面是这个示例。

// updatePodContainers updates PodSpec.Containers.Ports with passed parameters.
func updatePodPorts(params map[string]string, podSpec *v1.PodSpec) (err error) {
    port := -1
    hostPort := -1
    if len(params["port"]) > 0 {
        port, err = strconv.Atoi(params["port"]) // <-- this should parse port as strconv.ParseUint(params["port"], 10, 16)
        if err != nil {
            return err
        }
    }
       // (...)
    // Don't include the port if it was not specified.
    if len(params["port"]) > 0 {
        podSpec.Containers[0].Ports = []v1.ContainerPort{
            {
                ContainerPort: int32(port), // <-- this should later just be uint16(port)
            },
        }

错误的类型宽度假设导致的溢出：

root@k8s-1:/home/vagrant# kubectl expose deployment nginx-deployment --port 4294967377 --target-port 4294967376
E0402 09:25:31.888983    3625 intstr.go:61] value: 4294967376 overflows int32
goroutine 1 [running]:
runtime/debug.Stack(0xc000e54eb8, 0xc4f1e9b8, 0xa3ce32e2a3d43b34)
    /usr/local/go/src/runtime/debug/stack.go:24 +0xa7
k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/intstr.FromInt(0x100000050, 0xa, 0x100000050, 0x0, 0x0)
...
service/nginx-deployment exposed

实际上，很少需要颠覆类型系统。最需要的测试目标已经是导出了的，可以通过import获得。我们建议仅在需要助手和测试类似的未导出函数时才使用此功能。至于测试类型宽度安全性，我们建议您尽可能对所有目标进行编译，即使没有直接支持也是如此，因为不同目标上的问题可能更明显。最后，我们建议至少生成包含单元测试和集成测试的项目的覆盖率报告。它有助于确定未经直接测试的区域，这些区域可以优先进行审查。

四. 有关依赖的说明

在诸如JavaScript和Rust的语言中，依赖项管理器内置了对依赖项审核的支持-扫描项目依赖项以查找已知存在漏洞的版本。在Go中，不存在这样的工具，至少没有处于公开可用且非实验状态的。

这种缺乏可能是由于存在多种不同的依赖关系管理方法：go-mod，go-get，vendored等。这些不同的方法使用根本不同的实现方案，导致无法直接识别依赖关系及其版本。此外，在某些情况下，开发人员通常会随后修改其vendor的依赖的源代码。

在Go的开发过程中，依赖管理问题的解决已经取得了进展，大多数开发人员都在朝使用go mod的方向发展。这样就可以通过项目中的go.mod跟踪和依赖项并进行版本控制，从而为以后的依赖项扫描工作打开了大门。我们可以在OWASP DependencyCheck工具中看到此类工作的示例，该工具是具有实验性质的go mod插件。

五. 结论

最终，Go生态系统中有许多可以使用的工具。尽管大多数情况是完全不同的，但是各种静态分析工具可帮助识别给定项目中的“悬而未决的问题”。当寻求更深层次的关注时，可以使用模糊测试，属性测试和故障注入工具。编译器配置随后增强了动态技术，使构建测试夹具和评估其有效性变得更加容易。

本文翻译自“Security assessment techniques for Go projects”。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

今天几个同事在处理一个有关中文字符编码的问题，感觉他们对字符编码这件事依然理解不够透彻。这里用图文方式对中文字符编码做一个简要的解释，例子使用Go语言。

我们知道每个英文字母和数字在计算机中都会对应一个字节，或者说用一个字节来表示，这就是最初的ASCII码。但是随着计算机在全球范围内的广泛使用，非英语国家也要在计算机使用自己的字符，于是出现了字符集“百花齐放”的情况，我国在早期也颁布了自己的中文字符集标准。字符集一多，难免出现字符集编码不兼容的情况，比如：A字符集中某字符X的编码值是Y，但是在B字符集中Y这个值所表示的字符却是Z，这种不兼容的情况在一段时间内长期存在，导致因字符集导致的传输、处理、呈现、存储等问题常常发生，非常恼人。直到Unicode(万国码/统一码)在1994年发布，人类终于有了以统一人类所有字符为目的的统一字符集。Unicode的普及也是花费了不少的时间。但在2019年的今天，世界上绝大多数系统都支持了Unicode。

Unicode究竟是啥？Unicode就是一个表，如下图：

图：unicode是什么

我们看到这个表中有两列：序号和字符。其中序号就是为全世界所有国家的所有语言文字的符号做的编码，每个字符分配一个序号，序号的范围从0×000000到0x10FFFF，一共110多万个字符，这个序号也被称为Unicode码点(code point)。第二列的字符就称为“Unicode字符”。注意：同样一个“中”字，在Unicode表中的”中”称为Unicode字符“中”；在GB18030码表中的“中”称为GB18030字符“中”。计算机中的字符是有字符集属性的，因此虽然字符外形相同（都是“中”），但在计算机内部的存储表示是不同的。

图：拉丁字符对应的unicode表段

试想一下如果全世界的计算机系统都将Unicode序号作为Unicode字符的编码方案进行编解码，那么字符集问题便会从地球上彻底消失。但这个“理想的情况”并未发生。原因是什么呢？原因就是如果按照”理想方案”编码，那么无论是世界上最常用的26个字母a-z还是亚马逊森林中某个尚处于原始社会形态的某个部落的一个符号都要用一个”三字节”的存储单元表示，这意味着现实世界中所有数字资料的存储空间要变为原先的三倍（注：世界上大部分资料是用英语的26个字母编写的，原先每个字母仅需一个字节存储）、在传输相同信息的情况下，传输压力增加为原来的三倍，这是世界所无法接受的。Unicode组织其实也没有要求大家使用这种“理想的编码方案”对Unicode字符进行编码。于是就出现了UTF-8、UTF-16等变长的Unicode字符的编码方案，专门用于在存储和传输Unicode字符时使用。其中UTF-8经过实践，已经成为如今世界的Unicode字符的编码方案事实标准。

图：凤凰网默认采用utf-8编码方案

UTF-8这种Unicode字符的编码方案有几个特点：

• 使用变长字节对Unicode字符进行编码。采用什么编码与Unicode字符的序号有关，序号小的使用的字节就少，序号大的使用的字节就多。使用的字节个数从 1 到 4 个不等。

• 兼容ASCII字符集编码。这点非常重要，这意味着采用Unicode字符集时，已有的ASCII字符存储和传输方式无需改变，依然兼容可用。

• UTF-8 的编码单元为一个字节（也就是一次编解码一个字节），所以在处理UTF8字符的时候就不需要考虑这一个字节的存储是在高位还是在低位。

下面我们结合图、代码示例来更清晰地了解一下Unicode字符、UTF-8编码、GB18030编码的区别。

图: “中国人”三个字对应Unicode字符、字符对应的码点（序号）、UTF-8编码与GB18030编码

从上图中，我们看到三个Unicode字符：中、国、人对应的在Unicode表中的序号(码点）分别是：U+4E2D、U+56FD和U+4EBA。我们可以通过一段Go代码来输出Unicode字符的码点。

package main

import "fmt"

func main() {
        var s = "中国人"
        for _, v := range s {
                fmt.Printf("%s => 码点：%X\n", string(v), v)
        }
}

运行该程序的输出结果：

中 => 码点：4E2D
国 => 码点：56FD
人 => 码点：4EBA

我们知道在Go语言中，rune这种builtin类型被用来表示一个“Unicode字符”，因此一个rune的值就是其对应Unicode字符的序号，即码点。通过for range语句对字符串进行迭代访问是，range会依次返回Unicode字符对应的rune，即码点。这里可以看到Unicode字符“中”对应的rune（码点）为0x4E2D。

前面我们说过，Unicode字符在存储和传输时采用的并非“理想编码方案”，而多维UTF-8编码，也就是说在上面的例子中“中国人”这三个Unicode字符在内存中并不是以码点值存储的，而是以UTF-8编码后的值存储的。还以Unicode字符“中”为例，在上图中，我们看到其对应的UTF-8编码为0xE4B8AD这三个字节，我们用Go代码来验证一下：

package main

import "fmt"

func main() {
        var s = "中"
        fmt.Printf("%s => UTF8编码: ", s)
        for _, v := range []byte(s) {
                fmt.Printf("%X", v)
        }
        fmt.Printf("\n")
}

运行该程序得到如下结果：

中 => UTF8编码: E4B8AD

我们将字符串转换为对应的切片元素，然后按字节逐一输出便得到了Unicode字符“中”所对应的UTF-8编码，即存储“中”这个字符时，内存所使用的字节(三个)和对应的值。

“中”这个字符也存在于我们的国标GB18030编码表中，那么GB18030表中是如何对GB18030字符“中”进行编码的呢？我们来看一个全面些的例子：

// github.com/bigwhite/experiments/non-ascii-char-encoding/demo1.go

package main

import (
        "fmt"

        utils "github.com/bigwhite/gocmpp/utils"
)

func main() {
        var stringLiteral = "中国人"
        var stringUsingRuneLiteral = "\u4E2D\u56FD\u4EBA"

        if stringLiteral != stringUsingRuneLiteral {
                fmt.Println("stringLiteral is not equal to stringUsingRuneLiteral")
                return
        }
        fmt.Println("stringLiteral is equal to stringUsingRuneLiteral")

        for i, v := range stringLiteral {
                fmt.Printf("中文字符: %s <=> Unicode码点(rune): %X <=> UTF8编码(内存值): ", string(v), v)
                s := stringLiteral[i : i+3]
                for _, v := range []byte(s) {
                        fmt.Printf("0x%X ", v)
                }

                s1, _ := utils.Utf8ToGB18030(s)
                fmt.Printf("<=> GB18030编码(内存值): ")
                for _, v := range []byte(s1) {
                        fmt.Printf("0x%X ", v)
                }
                fmt.Printf("\n")
        }
}

运行该程序，得到如下结果：

$go run demo1.go
stringLiteral is equal to stringUsingRuneLiteral
中文字符: 中 <=> Unicode码点(rune): 4E2D <=> UTF8编码(内存值): 0xE4 0xB8 0xAD <=> GB18030编码(内存值): 0xD6 0xD0
中文字符: 国 <=> Unicode码点(rune): 56FD <=> UTF8编码(内存值): 0xE5 0x9B 0xBD <=> GB18030编码(内存值): 0xB9 0xFA
中文字符: 人 <=> Unicode码点(rune): 4EBA <=> UTF8编码(内存值): 0xE4 0xBA 0xBA <=> GB18030编码(内存值): 0xC8 0xCB

我们看到，如果使用GB18030编码，中文字符“中”字仅需要在内存中使用两个字节0xD6和0xD0表示。

综上，关于中文字符编码，需记住以下要点：

• Unicode是目前被支持最为广泛的字符集；

• Utf-8是目前被支持最为广泛的Unicode字符的编码方式(还有其他方式，比如UTF-16、UTF-32等)；

• 针对同一个字符，比如：“中”，如果该字符存在于两个字符集编码方案A（比如：utf8)和B(比如gb18030)中，那么我们可以通过转换，将该字符在A中的编码(如：”中”的E4B8AD)转换为在B中的编码(如“中”的D6D0)。

>本文涉及的例子源码可以在这里下载。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。