「ユニコード文字列」のようなものは実際にはありません。文字列は、何でも含むことができる一連のバイトです。ただし、文字列内のデータのエンコーディングを知ることは重要です。
私は Lua をUTF-8 文字列で使用しています。これは、気になるすべての操作で機能します。Unicode 文字列ライブラリは使用しませんが、Lua ( ICU4Lua、slnunicodeなど) で使用できます。
Lua で UTF-8 文字列を使用する場合の注意事項:
- 文字列の長さ (# 演算子) は、文字やコードポイントではなく、文字列の長さをバイト単位で返します (非 ASCII 文字は、複数バイトのシーケンスである場合があります)。
- 文字列分割 (string.sub など) は、UTF-8 シーケンスを分割してはなりません。
- 文字列の一致 (string.find、string.match) は、ASCII パターンで問題なく機能します。
- 部分文字列検索 ('plain' モードの string.find など) は、UTF-8 を針または干し草の山として使用します。
UTF-8 でのコードポイントのカウントは、他のエンコーディングよりもわずかに効率的ではありませんが、非常に簡単です。たとえば、Lua では次のようになります。
function utf8_length(str)
return select(2, string.gsub(str, "[^\128-\193]", ""));
end
これ以上のことが必要な場合は、前述の Unicode ライブラリが、エンコーディング間の変換を含むすべての API を提供します。
個人的には、特定のフレーバーの Unicode を強制する言語 (Javascript など) や、言語に複数のエンコーディングを組み込むことによって賢くしようとする言語 (Python など) に対して、この単純なアプローチを好みます。私の経験では、それらは頭痛とパフォーマンスのボトルネックを引き起こすだけです。
いずれにせよ、すべての開発者は、Unicode がどのように機能するかについての基本的な理解と、アプリケーションでの Unicode の処理方法について最良の選択を行うことができるように、さまざまなエンコーディング間の原則の違いを理解する必要があると思います。
たとえば、アプリケーション内のすべての既存の文字列がワイド文字エンコーディングである場合、Lua を使用するのはあまり便利ではありません。Lua に出入りするすべての文字列に変換を追加する必要があるからです。これは完全に可能ですが、アプリが (ゲームのように) CPU バウンドである可能性がある場合は、パフォーマンスの点でマイナスになります。