UTF-8の文字列操作関数について
山西 守
とあるアプリケーションのインターナショナル化をしようと奮闘中なのですが、
メッセージ等の文字列をUTF-8にするようにオリジナルの作者にいわれて、ちょっ
と
困っております。
ダイナミックにUTF-8からEUC-JPなりに変換するのはiconvが使えそう（MacOSなら
TextEncodingConverter）なのは判ったのですが、文字列に関する各種の情報を
操作する（得る）関数をどう作ったらよいのか、よくわかりません。作りたいのは
マルチバイト文字も１文字と数えるようにして、ある文字がUTF-8文字列の
何バイト目から始まるか
UTF-8文字列のある文字が変換後の文字列で何バイト目になるか
です。はじめの方は、（それなりに機能するものが）比較的簡単に作成できた
のですが、（後者の方も含めて）標準的なものがあったらそちらを使いたいと思い
ます。
日本語環境だけを考えれば、EUCやShift-JISに決め打ちでも良さそう（マルチバイ
ト
文字はローカルな環境でASCII２文字に相当するとか）なのですが、non-ASCIIな
西欧語圏の場合を含めるとなると、よくわかりません。
ネットワーク上でUTF-8とかで引っかかる情報で日本語のものは一通り目を通した
つもりではありますが、希望するような情報に当たりませんでした。
そもそも、そのあたりの標準的な関数は存在するのでしょうか？
もしご存じの方がいらっしゃいましたら、お教えいただけませんでしょうか。
--
山西 守 <ya...@biotech.okayama-u.ac.jp>
tel: 086-251-8196, fax: 086-251-8264
岡山大学工学部生物機能工学科
Go Watanabe
ya...@biotech.okayama-u.ac.jpさんは書きました。
>山西＠岡山大学ともうします。
>
>とあるアプリケーションのインターナショナル化をしようと奮闘中なのですが、
>メッセージ等の文字列をUTF-8にするようにオリジナルの作者にいわれて、ちょっ
>と
>困っております。
>
>ダイナミックにUTF-8からEUC-JPなりに変換するのはiconvが使えそう（MacOSなら
>TextEncodingConverter）なのは判ったのですが、文字列に関する各種の情報を
>操作する（得る）関数をどう作ったらよいのか、よくわかりません。作りたいのは
>
>
> マルチバイト文字も１文字と数えるようにして、ある文字がUTF-8文字列の
> 何バイト目から始まるか
>
> UTF-8文字列のある文字が変換後の文字列で何バイト目になるか
>
>です。はじめの方は、（それなりに機能するものが）比較的簡単に作成できた
>のですが、（後者の方も含めて）標準的なものがあったらそちらを使いたいと思い
いずれも、頭から目的の位置までの文字列を切り出して、それをコード変換
してしまえばしてみれば判明しますよね。両方マルチバイトだから iconv で
良いでしょう。ただ、文字を数えるには、マルチバイトでは無理があるので
普通一回ワイドキャラにして処理することになるかと思いますが、それを
してるとかなりパフォーマンスは落ちると思います。
MB→WC→MB→UTF-8
って処理しないと確実にはできないですから…
>そもそも、そのあたりの標準的な関数は存在するのでしょうか？
ということで、標準的な関数で一応全部できますが、おもいっきり
効率が悪いものになります。
設計の見直しをされることをお勧めしておきます。
元のアプリケーションが UTF-8 BASE なのなら、変なラッパをかますのではなく、
全部 UTF-8 で通すのが普通です。ダイナミックな変換には無理がありすぎます。
--
渡邊剛 (Watanabe,Go) g...@dsl.gr.jp / g...@denpa.org
山西 守
> いずれも、頭から目的の位置までの文字列を切り出して、それをコード変換
> してしまえばしてみれば判明しますよね。両方マルチバイトだから iconv で
> 良いでしょう。ただ、文字を数えるには、マルチバイトでは無理があるので
> 普通一回ワイドキャラにして処理することになるかと思いますが、それを
> してるとかなりパフォーマンスは落ちると思います。
>
> MB→WC→MB→UTF-8
>
> って処理しないと確実にはできないですから…
>
> >そもそも、そのあたりの標準的な関数は存在するのでしょうか？
>
> ということで、標準的な関数で一応全部できますが、おもいっきり
> 効率が悪いものになります。
なるほど、そうですか。
> 設計の見直しをされることをお勧めしておきます。
確かにそうですね。１バイトで文字が表示できる圏内の人はUTF-8でも
それほど困らないのかも知れないですが、マルチバイトの場合は多くの
問題があることを痛感しました。オリジナルの作者にも、対応を要望
してみます。
> 元のアプリケーションが UTF-8 BASE なのなら、変なラッパをかますのではなく
、
> 全部 UTF-8 で通すのが普通です。ダイナミックな変換には無理がありすぎます
。
MacOSとWindowsでは、コンパイルに先立ち適切なコード変換を行っておけば
良さそうなのですが、オリジナルの作者はそれが気に入らないようなのです。
また、X-Windowsシステム用のものは、locale対応にして、メッセージを
リソースに押し込めてしまえば後々便利そうなのですが、そうなっていないし、
ソースコードがマルチバイトに対応にもなっていないのです。さらに、実行中に
メニューやメッセージの言語を変更するような機能を独自に組み込んでいて、
ダイナミックな変換が不可欠な感じなのです。
私が作成した日本語対応パッチを見てか、インターナショナル化をスタート
させようと（オリジナルの作者は）考えているようなのですが、UTF-8なら
簡単と思っている節があるのです。
頓珍漢なことを申すかも知れないのですが、もう少し教えて下さい。
最近のプログラム環境（及び実行環境）では、アプリケーションでUTF-8でコード
された文字列をそのまま出力すると、ローカルに表示可能なコード大系に
自動的に変換されて表示されるものなのでしょうか？
Narita Takaoki
<yama-07080...@dhcps2m.biotech.okayama-u.ac.jp>の記事において
ya...@biotech.okayama-u.ac.jpさんは書きました。
> また、X-Windowsシステム用のものは、locale対応にして、メッセージを
> リソースに押し込めてしまえば後々便利そうなのですが、そうなっていないし、
man setlocale -> man catopen -> man catget ...
> ソースコードがマルチバイトに対応にもなっていないのです。さらに、実行中に
こっちはしかたないなぁ。やっぱり、圧倒的に wchar_t にしておいた方
が楽なんですけれど。バグも入りづらいし。
> 最近のプログラム環境（及び実行環境）では、アプリケーションでUTF-8でコード
> された文字列をそのまま出力すると、ローカルに表示可能なコード大系に
> 自動的に変換されて表示されるものなのでしょうか？
プログラム環境ってのが何かってのがありますが、Linux 上で考えれば、
Java とかでもない限り、例えば単純に printf とかで出力しただけなら
変換はされないでしょう。(man wcstombs)
--
成田 隆興 ＠ エー・アイ・ソフト株式会社 NB 推進部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ』
Narita Takaoki
<9kogor$i76$1...@epsongw6.epson.co.jp>の記事において
tak...@aisoft.co.jpさんは書きました。
> <yama-07080...@dhcps2m.biotech.okayama-u.ac.jp>の記事において
> ya...@biotech.okayama-u.ac.jpさんは書きました。
>
> > また、X-Windowsシステム用のものは、locale対応にして、メッセージを
> > リソースに押し込めてしまえば後々便利そうなのですが、そうなっていないし、
あ、これってそのもともとのプログラムがそういう風に作っていないっ
てことでしょうか？でしたら、
> man setlocale -> man catopen -> man catget ...
は大きにお世話でしたね。失礼、失礼。(^^;;;
Takanori Uchiyama
> 最近のプログラム環境（及び実行環境）では、アプリケーションでUTF-8でコード
> された文字列をそのまま出力すると、ローカルに表示可能なコード大系に
> 自動的に変換されて表示されるものなのでしょうか？
Mac OS X の Objective C を触っている感じだと, UTF-8 で文字列を使うこと
は, 結構あります. ただ, API を上手に使わないと, 速度に難があります. ま
た, UTF-8 にない文字(dotlessj はありません)の扱いに困りました(グリフの
内部配列でアクセスするのこと). UTF-8 だと簡単といったことは, ないよう
に思います.
--
内山 孝憲
Go Watanabe
ya...@biotech.okayama-u.ac.jpさんは書きました。
>山西＠岡山大学です。
>
>MacOSとWindowsでは、コンパイルに先立ち適切なコード変換を行っておけば
>良さそうなのですが、オリジナルの作者はそれが気に入らないようなのです。
>また、X-Windowsシステム用のものは、locale対応にして、メッセージを
>リソースに押し込めてしまえば後々便利そうなのですが、そうなっていないし、
>ソースコードがマルチバイトに対応にもなっていないのです。さらに、実行中に
>メニューやメッセージの言語を変更するような機能を独自に組み込んでいて、
>ダイナミックな変換が不可欠な感じなのです。
そもそもマルチバイトは通信と記録以外の用途には向いていない体系なので、
「マルチバイト対応」はあまりお勧めできません。メニューやメッセージだけ
ならマルチバイトで特に支障がでることはあまり無いと思いますが、
なんか話の流れからすると編集的な操作もあるような気配ですし。
「動的な変更」自体は、いわゆる「Cのロケール」の仕様ではカバーしきれ
ませんけど機構と概念は普通にロケールです。
比較的簡単にできて効果的なのは、ワイドキャラクタのような、(ある程度)
ロケール非依存かつ簡単に操作できるような内部コードを採用して
アプリケーション全体を記述し、必要な段階で外部コードとの変更を
行うようにするようなシステムです。
入力: 外部コード(通常マルチバイト文字列) → 内部コード
処理: 全て内部コードで行う
出力: 内部コード → 外部コード
こうすれば、変換は処理の最初と最後だけですみます。マルチバイトは個々の
もので極端に仕様が異なりますから、アプリケーションの内部でマルチバイト
を保持したままでいようとするのはとても大変です。メニューやメッセージなら、
言語を切り替えた時にこの処理を行うことになります。
>私が作成した日本語対応パッチを見てか、インターナショナル化をスタート
>させようと（オリジナルの作者は）考えているようなのですが、UTF-8なら
>簡単と思っている節があるのです。
UTF-8 というか、Unicode で処理できる範囲でなら簡単でしょう。
UTF-8 はマルチバイト文字列の一種なのですが、容易に前後のコードの境界が
わかるようなデータ構造なので、char で書かれたデータ構造を破壊せずに
ワイドキャラ的な操作を行うのなら、有効な選択肢の一つです。
原理的には、
マルチバイト←→ワイドキャラ
が
マルチバイト←→UTF-8
となるだけのことです。
# きちんと設計されている locale では、ワイドキャラはそのマルチバイトの体系に
# 最適化されたデータ構造をもってるはずなので、UTF-8 化よりはパフォーマンスが
# 良い可能性がありますが、それはアプリケーション作成上の本質ではありません。
このアプローチ、UTF-8 (というか Unicode で扱えない範囲)とか、Unicode での
マルチバイトとか考えはじめると、対処しきれなくなるんですけど、
そこまで考えるなら、たぶんアプリケーション本体側でかなり本格的な
「多言語」対応しないといけなくなりますので、そこまで求めるような
ものでないのならOKだと思います
>頓珍漢なことを申すかも知れないのですが、もう少し教えて下さい。
>
>最近のプログラム環境（及び実行環境）では、アプリケーションでUTF-8でコード
>された文字列をそのまま出力すると、ローカルに表示可能なコード大系に
>自動的に変換されて表示されるものなのでしょうか？
場合によります。まず端末では、UTF-8 対応の端末が必要でしょう。
最近の XFree86 の XTerm は UTF-8 化しているとは思いますが、
出来のほどは不明です。X としての表示系では、UTF-8 系の Locale にした
上でマルチバイトで出力すれば可能ですが、多くのPC-UNIX 環境ではこれを
望むのはちょっとまだ無理です。
まあ、そもそもマルチバイトですら怪しい環境は多いので、どんな環境でも
動くようにしたければ「UTF-8でだせば適宜表示してくれるライブラリ」
とかつくらんと無理でしょうね。探せばいろいろあるとは思います。
なお、Windows とか Java とかは、ワイドキャラクタ的アプローチを取ってる
んで、画面とかへのインターフェースは UTF-8 じゃないです。