Go x/text/unicode/bidi 片段顺序为什么不能直接反转字节

处理阿拉伯文、希伯来文和英文混排时，不能把“显示顺序”理解成把字符串或 UTF-8 字节倒过来。字节反转可能直接破坏编码；即使按 rune 倒序，也没有处理段落方向、数字、标点、括号和嵌入层级。golang.org/x/text/unicode/bidi 的正确入口是先把文本交给 Paragraph，再从 Ordering 读取视觉排列的方向片段。

官方地址：https://pkg.go.dev/golang.org/x/text/unicode/bidi

先保留输入的逻辑顺序，再用 Paragraph.Order() 计算视觉顺序；Run.String() 和 Run.Bytes() 返回每个片段自身的原始顺序。只有确实需要做字符级逆序时，才使用 ReverseString 或 AppendReverse。

字节倒序为什么从第一步就错了

Go 的 string 保存的是 UTF-8 编码后的字节序列。一个非 ASCII 字符通常由多个字节组成，按字节逆序后，原来的首字节和后续字节关系就被打散，结果不是另一个“反向文字”，而是非法或错误的 UTF-8。即使先转换成 []rune 再倒序，也只完成了字符序列变换，没有完成双向排版。

Unicode 双向算法把文本的逻辑顺序作为输入，依据字符的方向属性计算视觉顺序；混排中的数字和标点可能与周围文字形成独立片段。因此“把所有字符反过来”与“按照视觉方式排列片段”不是同一个操作。程序中的存储、搜索和比较仍应使用逻辑顺序，布局层才消费视觉顺序。

用 Paragraph.Order 取得混排文本的视觉片段

SetString 将一个段落交给 Paragraph，返回消费的字节数和错误。随后调用 Order，得到包含视觉排列的 Ordering。遍历时使用 NumRuns 和 Run(i)，再读取每个 Run 的方向、原始位置和文本。

package main

import (
	"fmt"

	"golang.org/x/text/unicode/bidi"
)

// VisualRuns 只负责计算段落的方向片段，不改写原始字符串。
func VisualRuns(text string) error {
	var paragraph bidi.Paragraph

	// SetString 按一个段落处理输入；返回值可用于确认消费到哪里。
	used, err := paragraph.SetString(text)
	if err != nil {
		// 输入或选项错误应在布局前返回，避免使用不完整结果。
		return fmt.Errorf("set bidi paragraph: %w", err)
	}
	if used != len(text) {
		// 遇到段落分隔符时，库可能只消费第一个段落。
		return fmt.Errorf("only one paragraph consumed: %d/%d bytes", used, len(text))
	}

	ordering, err := paragraph.Order()
	if err != nil {
		// Order 失败时不能假设已有的片段顺序可用于绘制。
		return fmt.Errorf("order bidi runs: %w", err)
	}

	for i := 0; i 

这里的关键是两层顺序：Ordering 决定片段在视觉布局中的先后，Run.String() 仍返回该片段在输入中的原始顺序。绘制器可以按 run 的方向安排字形，但业务层不要把打印出来的视觉片段重新写回数据库。

Run、Line 和 Direction 分别解决什么问题

Run 是连续的同方向字符片段，Run.Direction() 告诉布局层它属于左到右还是右到左，Run.Pos() 给出它在输入文本中的位置。段落整体方向可以通过 Paragraph.Direction() 或 IsLeftToRight() 判断，但整体方向不能替代每个 run 的方向。

如果界面已经完成换行，不要总是对整段调用 Order 后再硬拆。Paragraph.Line(start, end) 可以针对原文中的一个行区间计算视觉排列；行边界应由上层排版根据字形宽度决定，而不是靠倒序字符串猜测。RunAt 还可以帮助根据逻辑位置定位片段。

ReverseString 什么时候才是合适工具

ReverseString 和 AppendReverse 适合明确的字符级逆序需求，例如某个独立片段需要按字符反向展示。官方文档说明它们会处理 rune 顺序，修饰符仍跟随所修饰的 rune，括号会替换为对应的另一侧括号。这仍然是一个“逆序变换”，不是对混合方向段落执行完整布局。

package main

import (
	"fmt"

	"golang.org/x/text/unicode/bidi"
)

func main() {
	part := "abc"
	// 只有业务明确要求字符级逆序时才使用 ReverseString。
	reversed := bidi.ReverseString(part)
	fmt.Println(reversed)

	// 逆序结果仅是新字符串，不能替代 Paragraph.Order 的视觉布局。
}

反过来，如果需求是“让阿拉伯文与英文同处一行时显示正确”，应走 Paragraph；如果需求是“生成一个反向标签或测试字符串”，才考虑 ReverseString。两者都不负责字体 shaping、字形宽度计算或换行，这些仍属于更高层的排版链路。

换行、复用和并发的边界

双向算法按段落工作。SetString 或 SetBytes 遇到段落分隔符时可能只处理第一个段落，并返回实际消费的字节数；多段输入应由上层先拆分或逐段处理。调用 SetString 更新原段落后，之前得到的 Ordering 会失效，不要缓存它跨越下一次设置。

此外，官方文档明确限制同一个 Ordering 的方法只由一个 goroutine 同时调用。可以并行处理不同段落，但不要把同一结果对象交给多个渲染协程后再同时读取。排查“偶尔顺序错乱”时，先检查对象生命周期和共享方式，再检查字体或浏览器层。

相关问题

把 UTF-8 转成 rune 后反转可以吗？

它不会破坏 UTF-8，但仍然只是字符级逆序，不能处理混合方向文本的视觉排列、数字和标点关系。需要排版时应调用 Paragraph.Order 或 Line。

Run.String() 返回的是屏幕上看到的顺序吗？

不是。它返回该 run 的原始顺序文本；屏幕上的片段先后由 Ordering 决定，具体字形方向还要由渲染层完成。

修改 Paragraph 后为什么旧 Ordering 不能继续用？

因为 SetString 或 SetBytes 会替换段落输入并使原来的计算结果失效。更新文本后应重新调用 Order 或 Line。

把逻辑文本当作数据源、把 Ordering 当作布局中间结果，再把字体与换行交给渲染层，才能避免“看起来只是倒序”的误判。字节反转不是双向排版；它只会把本来不同层次的问题混在一起。