Go TurkishCase 怎样转换带点和不带点的字母I

Go 中处理土耳其语的字母 I，应使用 unicode.TurkishCase.ToLower 和 ToUpper：不带点的大写 I 对应不带点的小写 ı，带点的大写 İ 对应小写 i。整段字符串则用 strings.ToLowerSpecial(unicode.TurkishCase, s) 或 strings.ToUpperSpecial，显式传入这套规则。

官方地址：https://pkg.go.dev/unicode

迁移范围：改变语言规则，不是升级 Go 版本

把默认大小写转换用于土耳其语人名、地名或展示标签时，容易忽略 I 上方的点。我的选择是先明确字段的语言约定，再决定是否替换转换函数。本文的迁移指从默认 Unicode 映射切换到明确的土耳其语映射，并不对应一次新版本发布，也不声称旧接口被弃用。

适用范围是业务已确认的土耳其语文本。TurkishCase 不会读取用户所在地、操作系统区域或浏览器语言来自动识别文本。混合语言数据应在业务层保留语言属性；协议字段、已有标识符的大小写约定也不能因为展示语言变化而一起替换。

变更表：四个字符对应两组关系

下面是本文讨论的四个码点。在土耳其语规则中，它们组成带点与不带点的两组大小写对应。大小写转换只在需要改变的方向改变字符；已经处于目标大小写的字符保持自身。

最容易影响现有逻辑的是 I 的小写和 i 的大写：默认映射中 I 变成 i、i 变成 I，而这里分别变成 ı 与 İ。SpecialCase 的用途是优先应用指定的特殊映射，其余字符继续按标准映射处理。不要把这理解为只处理四个字符、把其他字母原样跳过。

旧代码风险：结果字符和字节长度都可能改变

只覆盖英语样本的旧代码，即使没有报错，也不能说明符合土耳其语的要求。I 与 ı 是不同码点，i 与 İ 也是不同码点，不能把它们当作字体渲染差异。若旧业务曾把全部文本转为默认小写作为检索键，换规则后就需要重新考虑存量键与新键如何同时解释。

我会把展示转换和键生成拆成两个明确的业务决定。展示标签可以按已知语言转换；持久化键是否重建则要另有数据方案，不能直接覆盖原文后再尝试恢复。大小写转换会丢失原始大小写信息，保存原文本是更稳妥的做法。

另外，Go 的字符串长度 len 统计字节。ASCII 的 I 与 i 各占一个 UTF-8 字节，而 İ、ı 各占两个；因此转换前后的字节数可能不同。不要在原来的字节偏移上直接替换一个 byte，也不要依赖“大小写变化不影响长度”来复用原字符串索引。

新写法：按 rune 与整串选择接口

已有单字符值时，调用 TurkishCase 的方法即可。整串文本直接调用 strings 的 Special 接口，可避免自己拼接字符的细节。下面用四个字符作码点对照，再使用原创标签 IŞIK İzmir 演示字符串接口，输入已约定为有效 UTF-8。

package main

import (
    "fmt"
    "strings"
    "unicode"
)

func main() {
    // 用码点打印，避免字体让四个字符看起来相似。
    for _, r := range []rune{'I', 'i', '\u0130', '\u0131'} {
        fmt.Printf("%U lower=%U upper=%U\n", r,
            unicode.TurkishCase.ToLower(r),
            unicode.TurkishCase.ToUpper(r))
    }

    // 业务已经明确为土耳其语；整串转换显式传入同一规则。
    label := "IŞIK İzmir"
    lower := strings.ToLowerSpecial(unicode.TurkishCase, label)
    upper := strings.ToUpperSpecial(unicode.TurkishCase, label)
    fmt.Printf("lower=%q upper=%q\n", lower, upper)
}

按规则推导，标签的小写应是 ışık izmir，大写应是 IŞIK İZMİR。这里给的是接口语义对应的预期字符串，没有把它描述成实际运行日志。单字符循环以 %U 显示码点，适合在自己的程序中区分看起来相似的字形。

若上层收到的是 UTF-8 字符串，不能把 s[0] 直接当成第一个 Unicode 字符，因为索引取得的是 byte。遍历字符可使用 range 得到 rune；整串转换则优先保留上面的 strings 写法。无需自己复制或修改 unicode.TurkishCase 的公共映射表。

回归样本：把语言差异写进预期值

接入自己的代码时，建议覆盖四个码点以及混合单词，明确每个方向的预期，而不是只检查“函数调用成功”。可将表格作为回归用例的输入依据；本文不为了制作插图执行本地程序或测试。

若输入包含分解形式的字母与组合点，不能只凭外观套用本文的预组合字符表。本文没有制定 Unicode 规范化策略，也不把大小写接口当作规范化、排序或语言检测工具。此类输入应另行定义数据规则后处理。

迁移清单：让变化停在有语言约定的字段

• 为目标字段明确土耳其语语义，保留原文本。
• 单字符改用 TurkishCase 方法，整串改用 strings 的 Special 接口。
• 把带点与不带点字符分别写入预期样本，记录 byte 长度可能变化。
• 盘点存量检索键与新键的解释方式；展示转换不自动授权覆盖存量数据。
• 对没有语言约定的字段继续遵守其自身协议，避免全局替换。

只把字符 I 替换成 ı 可以吗？

不适合作为完整大小写规则。它没有同时处理大写方向和带点的 İ，也可能改动本来不应按土耳其语处理的字段。

ToTitleSpecial 会只把单词首字母变大写吗？

不会按“每个词只改首字母”的需求工作，它把字母映射为 Unicode title case。单词标题格式需要单独的分词和展示约定。

用了 TurkishCase 就完成土耳其语文本处理了吗？

本文只完成大小写映射。字符排序、查询匹配策略和语言识别仍是独立需求，不能从转换接口推导它们的结果。

技术依据：SpecialCase 接口说明、Go 土耳其语映射表源码、strings 特殊大小写转换说明。