HSPTV!掲示板

UTF16について質問です。

UTF8では1文字について符号単位の数がバラバラなため、文字数を数える時などは先頭から1文字ずつ
数えていく必要があります。

UTF16ではそもそも1符号単位で1文字を表すことを目的として作られたので、ほとんどの文字
は1符号単位（2バイト）で表されます。
つまり、文字数 = NULLまでのバイト数 / 2　というありがたいことに《なるはず》だったのです。
ところが、あとからやっぱり足りないということになって、サロゲートペアが導入されて面倒なことに
なりました。
U+10000..U+10FFFFの範囲の文字は1文字が2符号単位（4バイト）で表されることになったのです。
つまり、文字数を数えるときに先ほどの式が成り立たなくなり、一文字ずつサロゲートペアかを確かめて数えないと
いけなくなったのです。

とまあ、ここまでを調べました。間違っているところがあれば教えていただきたいです。
ここまでの書いたことが正しいとして、聞きたいことがあります。

「サロゲートペアはちゃんと考慮してやるべきなのでしょうか」
サロゲートペアさえ考えなければ、文字数も簡単に求まりますし、文字列操作も簡単にできます。
でも、サロゲートペアを考えると、1文字ごとにCharNextWでイテレートして文字列を数える、という
UTF8と同じようなことをしないといけません。これは格段に遅いですし、文字数カウントが遅くなれば
自然と文字列操作も遅くなります。

ほかの言語ではどうかというと、
C#(.NET)では、LengthメソッドはChar配列の大きさを返しますし、C++のwstringにおいてはただの文字
のコレクションなので、同じくサロゲートペアは考慮しません。
サロゲートペアを考慮するとなると、C#では、Globalization.StringInfo、C++では外部ライブラリを
使わない限りろくに文字列操作もできません。
一方、UTF8を使う言語も多く、そのような言語ではUTF8に対する文字列操作は標準で提供されています。

こう言った状況を鑑みるに、UTF16をデフォルトのエンコーディングとして採用する環境では、
（サロゲートペアを考慮するのはUTF8と同じくらいのコストなのに、）「正確な文字数」を
数える手段を提供していないように見受けられます。

非常に長々と書いてしまいましたが、結局
「UTF16を使う場合、速度が格段に遅くなる（といってもUTF8と同じくらい）としても、サロゲートペアは
ちゃんと考えてやるべきなのか」という質問です。

あまりHSPとは関係なく、ここで質問するのは不適切かもしれません。
それでも、教えてくれる方がいらっしゃるとありがたいです。

私的な意見でいいのなら

UTF16を使い、サロゲートペアを扱う（扱う可能性がある）

という条件下ならば、当然それに対応するコードを組むでしょう。



速度に関してはどうしても犠牲になってしまいますが、
大量の文字を扱う場合でなければそれほど問題にはならないでしょうし、
仮に大量に扱う場合でも、必要に応じて分割して読み込むというなどの形で実装すれば
たいして問題にはならないでしょう。

HSPに限って言えば、そもそもHSPがメインで扱っているのはSJISですし、
本気で速度面を考慮するなら始めから（プラグインやマシン語も考慮するという意味で）
他言語を使う。と考えています。

確かに、サロゲートペアを考慮するに越したことはないのかもしれませんね。
サロゲートペアなど普通は考慮しないものなのかもしれないと思っていたので、そう言っていただける
と安心です。

ただ、サロゲートペアに含まれる文字はそもそもあまり使われないものですし、おっしゃる通り大量の
文字を扱うと、それに比例して速度が遅くなるというのは少しキツイですね。

分割して少しずつ読み込む、というのはいいかもしれません。
それが難しかったらそこだけCで書く方向で行こうと思います。