Crystal语言中UTF-16字符串字面量的实现探讨

在Crystal语言的标准库开发过程中，处理Windows API时经常需要将UTF-8字符串转换为UTF-16编码。虽然标准库提供了String#to_utf16方法进行转换，但这种方法存在运行时开销，特别是当处理字符串字面量时，这种转换实际上可以在编译期完成。

当前实现的问题

目前标准库中许多使用String#to_utf16的场景都是针对字符串字面量的转换，例如"Content Type".to_utf16。这种实现方式存在两个主要问题：

1. 运行时转换带来不必要的计算和内存分配开销
2. 在某些特殊场景下（如#14659），完全不能有任何内存分配

开发者们不得不使用复杂的宏技巧来实现编译期转换，例如：

UInt16.static_array({% for chr in "CRYSTAL_TRACE".chars %}{{chr.ord}}, {% end %} 0)

但这种方案存在局限性，无法正确处理基本多语言平面(BMP)之外的Unicode字符。

解决方案探讨

社区提出了几种可能的解决方案：

1. 宏方法实现：将String#to_utf16的转换算法实现为宏方法。虽然宏语言不能直接操作16位整数，但可以通过其他方式实现。

2. 编译器内置支持：暴露编译器原语来支持UTF-16转换。

3. StringLiteral扩展：为StringLiteral类型添加to_utf16方法，使其在宏环境中可用。

宏方法实现方案

BlobCodes提出了一个完整的宏实现方案：

class String
  macro utf16_literal(data)
    {% 
      arr = [] of NumberLiteral
      data.chars.each do |c|
        c = c.ord
        if c < 0x1_0000
          arr << c
        else
          c -= 0x1_0000
          arr << 0xd800 + ((c >> 10) & 0x3ff)
          arr << 0xdc00 + (c & 0x3ff)
        end
      end
      arr << 0
    %}
    Slice(UInt16).literal({{arr.splat}})[0, {{arr.size - 1}}]
  end
end

这个实现能够正确处理所有Unicode字符，包括BMP之外的字符。性能测试表明，转换10000个字符大约需要300ms，对于大多数使用场景已经足够。

StringLiteral扩展方案

ysbaddaden提出了更优雅的方案：为StringLiteral类型添加to_utf16方法。这种方法有几个优势：

1. 语法与运行时版本完全一致，保持一致性
2. 明确表示转换发生在编译期
3. 更容易被编译器优化

不过，这个方案需要解决SliceLiteral的支持问题，目前Crystal还没有原生的切片字面量语法。

Windows UTF-8支持讨论

stakach和ysbaddaden指出，现代Windows系统已经支持UTF-8编码，并鼓励开发者使用UTF-8 API。从Windows 10 v1903(2019)开始，可以通过设置活动代码页(ACP)为UTF-8来使用ANSI API处理UTF-8字符串。

然而，考虑到Windows生态系统的庞大和遗留代码的广泛存在，UTF-16字符串处理在可预见的未来仍将是必要的。

结论

经过讨论，社区倾向于采用StringLiteral#to_utf16方案，因为它提供了最优雅和一致的API设计。虽然需要解决一些技术实现问题，但这个方案最能满足开发者的需求，同时为未来的编译器优化留下了空间。

对于性能敏感的场景，可以通过优化宏解析器来提升转换速度。测试表明，简单的语法调整就能将10000字符的转换时间从300ms降低到20ms，说明宏语言的性能瓶颈主要在解析阶段而非执行阶段。

这一改进将为Crystal语言的Windows平台开发带来更好的体验，特别是在与原生API交互时减少不必要的运行时开销。