01(Sun)

○[i18n] AIX multi-locale implementation

いえいえ、OSF/1由来のPOSIX locale実装をベースにしたやつなんですが
かといって Distributed I18N Frameworkでもないし、ってやつですね。
機能的には Thread Aware Locale Extensionよりもしょぼいです。

locale objectの定義とconstructor/destructorはこんなの。

typedef void* __xlocale_ptr;

__xlocale_ptr __xopen_locale(const char *);
void __xclose_locale(__xlocale_ptr);

__xopen_localeにLC_*なカテゴリ指定がないのはまぁ正しい実装やね。
せっかくmulti-localeなんだからカテゴリはもはや意味ないよ＞＞TALE
Javaのjava.util.Localeもそういう実装ですな。
ただ、printf系なんかだと数値フォーマットはen_USで、照合順序はja_JPでとか
必要になるので、java.text.Formatみたいに分離する必要あるけど。
＃なぜかjava5でSystem.out.printf入って退化したけどな、Java。

以下の関数は、第一引数に__xlocale_ptrをとる以外は非multi-locale版と同じプロトタイプ。

マルチバイト・ワイド文字(列)変換

[locale.h]		[_LC_core_charmap_t]	[SUSv3]
__xmbtowc		__mbtowc		mbtowc
__xmbstowcs		__mbstowcs		mbstowcs
__xwctomb		__wctomb		wctomb
__xwcstombs		__mbstowcs		mbstowcs
__xmblen		__mblen			mblen
__xwcswidth		__wcswidth		wcswidth
__xwcwidth		__wcwidth		wcwidth

/* http://publib.boulder.ibm.com/infocenter/systems/topic/com.ibm.aix.files/doc/aixfiles/Locale_Method.htm */
__x__mbtopc		__mbtopc		(__mbtopc)
__x__mbstopcs		__mbstopcs		(__mbtopcs)
__x__pctomb		__pctomb		(__pctomb)
__x__pcstombs		__pcstombs		(__pcstombs)
__xcsid			__csid
__xwcsid		__wcsid

__x__getmbcurmax	N/A			MB_CUR_MAX
__xmbrtowc		N/A			mbrtowc
__xwcrtomb		N/A			wcrtomb

wcs?widthは文字の属性情報なので、ここより_LC_core_ctype_tの方が
相応しいのだけども、SUSv3もwctype.hじゃなしにwchar.hなのよな。

文字クラス分類

[locale.h]		[_LC_core_ctype_t]	[SUSv3]
__xtowupper		__towupper		towupper
__xtowlower		__towlower		towlower
__xget_wctype		__get_wctype		(get_wctype)
__xis_wctype		__is_wctype		(is_wctype)
__xtoupper		N/A			toupper
__xtolower		N/A			tolower
__xisalnum		N/A			isalnum
__xisalpha		N/A			isalpha
__xisblank		N/A			(isblank)
__xiscntrl		N/A			iscntrl
__xisdigit		N/A			isdigit
__xisgraph		N/A			isgraph
__xislower		N/A			islower
__xisprint		N/A			isprint
__xispunct		N/A			ispunct
__xisspace		N/A			isspace
__xisupper		N/A			isupper
__xisxdigit		N/A			isxdigit
__xiswalnum		N/A			isalnum
__xiswalpha		N/A			iswalpha
__xiswblank		N/A			iswblank
__xiswcntrl		N/A			iswcntrl
__xiswdigit		N/A			iswdigit
__xiswgraph		N/A			iswgraph
__xiswlower		N/A			iswlower
__xiswprint		N/A			iswprint
__xiswpunct		N/A			iswpunct
__xiswspace		N/A			iswspace
__xiswupper		N/A			iswupper
__xiswxdigit		N/A			iswxdigit

is*とかisw*が_LC_core_ctype_tにないのは全部これ直接テーブルを参照してるかis_wctype呼んでるからぽ。

文字照合順序

[locale.h]		[_LC_core_collate_t]	[SUSv3]
__xstrcoll		__strcoll		strcoll
__xstrxfrm		__strxfrm		strxfrm
__xwcscoll		__strcoll		strcoll
__xwcsxfrm		__strxfrm		strxfrm
__xfnmatch		__fnmatch		fnmatch
N/A			__regcomp		regcomp
N/A			__regerror		regerror
N/A			__regexec		regexec
N/A			__regfree		regfree

/* undocumented, obsoleted interface derrived from OSF/1 */
__xNCcollate		N/A			(NCcollate)
__xNCcoluniq		N/A			(NCcoluniq)
__xNCcolval		N/A			(NCcolval)
__x_NLxcol		N/A
__x_NCxcol		N/A
__x_NLxcolu		N/A
__x_NCxcolu		N/A

時刻フォーマット

[locale.h]		[_LC_core_time_t]	[SUSv3]
__xstrftime		__strftime		strftime
__xstrptime		__strptime		strftime
__xwcsftime		__wcsftime		wcsftime
__x__isowcsftime	N/A

通貨フォーマット

[locale.h]		[_LC_core_monetary_t]	[SUSv3]
__xstrfmon		__strfmon		strfmon

数値フォーマット

[locale.h]		[_LC_core_numeric_t]	[SUSv3]
なし

メッセージフォーマット

[locale.h]		[_LC_core_resp_t]	[SUSv3]
__xrpnmatch		__rpnmatch		rpnmatch

locale共通

[locale.h]		[_LC_core_locale_t]	[SUSv3]
__xnl_langinfo		__nl_langinfo		nl_langinfo
__xlocaleconv		__localeconv		localeconv

(追記)

#define _MULTILOCALE_API
#include <locale.h>

すると使えまふ。

2009/11/02(Mon)

○[OpenBSD] また SourceForge.JP Magazine か

この記事、なんでこれでuim動いてるのかさっぱりワカメ。

そもそもOpenBSD 4.6はja_JP.UTF-8どころかen_US.UTF-8だってサポートしてないんですが。

$ ls /usr/share/locale | grep ja_JP.UTF-8

$ ls /usr/share/locale/locale.alias

$ ls /usr/share/locale/en_US.UTF-8/*

ぜーんぶからっぽでござい、詳しくはこのスレ読んで頂戴。

実際にsetlocale(3)呼ぶコード書いて実行してみても

cat >test.c
#include <locale.h>
#include <stdio.h>
int
mai(void)
{
	char *s;
	s = setlocale(LC_CTYPE, "ja_JP.UTF-8");
	printf("%s\n", s == NULL ? "(null)" : s);
}
^D

$ make test
$ ./test
(null)

ほら失敗しとる、成功してれば"ja_JP.UTF-8"が返るはず。

これは懐かしの-D_XLOCALEかと思ったけど、Xorgになってから
configureからは-D_XLOCALE指定できないし、xenocaraでhackしてる様子もないし
そもそもXlibにもシンボルないしね。

$ nm /usr/X11R6/lib/libX11.so.11.2 | grep _Xsetlocale

$ nm /usr/X11R6/lib/libX11.so.11.2 | grep setlocale
               U setlocale

ちゃんとlibcのsetlocale使ってるし。

リンク先の通りに.xinitrcを設定してX起動すると

Warning: locale not supported by C library, locale unchanged

動くわきゃない。

どーも見覚えあると思ったらこれDragonFlyBSDの時もアレな記事書いてた人か。

残念ながらDragonFly BSD 2.2はデフォルトのままでは日本語の扱いに難がある。
そこで次回は、DragonFly BSDで日本語環境を構築する方法を紹介する予定だ。

前も書いたけど、LC_CTYPEとiconv(3)はjoerg氏の手でCitrusが移植されとるし(現在のメンテはhasso氏)
その他のLC_*もFreeBSD由来の実装があるし、LC_COLLATEも不完全だけど実装されとるので
ある意味*BSDの中で一番まともな「国際化」機能を持つのがDragonFlyBSDですわ。

マルチバイトもOKなDragonFlyBSD捕まえて「難がある」という記事を書きつつ
シングルバイトしか扱えないOpenBSDをデフォルトインストールしただけで日本語環境整えられるって凄いね。

うちで配布してる Citrus patchを当ててる風でもないので
(ちうか4.6用はまだ作ってない、なんせsvn repository壊したからな！)
多分これ、 kuratiさんとこの暫定patchと同様の処理か

$ cd /usr/share/locale
$ ln -s en_US.ISO8859-1 ja_JP.UTF-8

とか素敵なことやってるような気がする。

ちなみにkuratiさんの暫定patchを解説すると


        rl->rl_citrus_ctype = NULL;

+       /*
        if (strcmp(rl->rl_encoding, _CITRUS_DEFAULT_CTYPE_NAME) != 0) {
                _NukeRune(rl);
                return EINVAL;
        }
+       */
        /* register it */
        lt = malloc(sizeof(struct localetable));
        if (lt == NULL) {

rl->rl_encodingには、このlocaleで必要になるマルチバイト処理のためのplugin名が入っていて
これが現在OpenBSDで用意されている_CITRUS_DEFAULT_CTYPE_NAME(=NONE、シングルバイトのみ)
に一致しない場合はsetlocale(3)を失敗させるという処理をスキップさせてるのよね。
なのでこれ当ててもまともに動くわけないです。

ただ、setlocale(3)さえ成功すれば、マルチバイト処理は自前でやっちゃうようなアプリも多いので
(Xutf8*とか)一見動いているように見えるのかもしれんけど:D

libcにpatchを当てるぐらいなら、前述の通りen_US.ISO-8859-1をja_JP.UTF-8にリンク張ったほうがましですな。

ま、うちで配布してるCitrus patch使えばちゃんとマルチバイトも扱えるようになるんですが
MB_LEN_MAXが変わることによるバイナリ互換性問題のためにいろいろいやらしい事してるのと
現状全く本家へのmergeの道筋が立ってないので、正直止めとけって感じですけど。

いちおTheo氏は作業できる人を探してて候補者も以下略という話もあります、うまくいけばいいんですがね。

2009/11/03(Tue)

○[OpenBSD] Q: is the OpenBSD supports UTF-8 locale? A: No!

@

昨日のネタの続き、mutt開発者でOpenBSDユーザの tamoさんと
uimコミッタでOpenBSDユーザのいわたさんからの情報で事情掴めました。
いつもいつもありがとうございます。

結論、gtk+なアプリならGTK_IM_MODULE経由だとOSのlocaleサポートなしでも動いちゃったりするみたい。
そういやあれGNU libiconvリンクしてるからなぁ、それにしても

(process:16313): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.

とか警告出すのにぜんぜんCにfallbackしてないじゃねーか、おい。

つまり、件の記事はさも

ja_JP.UTF-8 localeが有効
ximも動く

ような事が書いてあったのだけどそれはジャン＝ルイ・ガセーネタで
GTK_IM_MODULEだけしか動かないちゅーことです、であるならば.xinitrcのサンプルは
余計な警告を出すだけのLANG環境変数とどうせ動かないuim-ximの行は削っちまって

GTK_IM_MODULE=uim; export GTK_IM_MODULE
uim-toolbar-gtk &
exec twm

でおｋっちゅうこと、一部のアプリが動いとるだけで「日本語入力システムが利用可能」とは言わんがな。
なんで、ここまで読んだ人はmisc@あたりに「xtermに入力できません」とか突撃するなよ！(ダチョウ倶楽部的な意味で)

一部のアプリが動けばいいのなら、私が常々自虐ジョークネタとして使ってる
「*BSDにはlinux emulationがあるので国際化されてるアプリが使いたければlinux binary使え」
でOKということなんだよな(半分本気)。

それにしてもGTK_IM_MODULEってアレだよな、libcannaとかlibwnnを直接リンクしてた時代に逆戻りとしか思えん。
まぁXIMがあくまでX環境のものであってdirectfbみたいにframebuffer環境だと必要ってのはわかるけど。

あとfallbackしてないの話に戻るけど、正直GTK+が内部UTF-8で動こうがどうでもいいんだけど
ちゃんと外側についてはcurrent localeの文字エンコーディングを尊重してんだろうかね。
複数の文字エンコーディングを同時に扱うって、セキュリティの原則としてあんまり宜しくないんですが。

@

(追記)
pkg_add firefox35したらuimで入力できてワロタ。
ただしlocaleはCなので、jaのデフォルト変換エンジンであるAnthyは有効になってないので
ツールボックスから選択してやる必要があるけど。

んで、繰り返しますがlocaleはCなので、あのお馬鹿なfontconfigにも悩まされず、きれいな欧文フォントで表示されるので
むしろNetBSDでもLANG=Cで起動した方が(ぉ

○ 今日

@

このチラシの裏でも何度かネタ( 1

)にしたレヴィ＝ストロース先生死去、R.I.P

個人的にはやぱし野生の思考がおぬぬめ。

バブル時代は構造主義を知ってる俺クールというナンパの道具だったらしいぞ。

2009/11/04(Wed)

○ 今日

@

kbkさんとこ

そいや、strlcpy/strlcat 的なものの追加はないんだろうか?

TR24731-1のstrcpy_s/strcat_sですね。

2009/11/09(Mon)

○[i18n] iconv -f UTF-8 -t ct

@

AIXのiconv(3)がグレイトなことにCOMPOUND_TEXTをサポートしてたんで前言撤回。
それとこの記事でも触れてる iconv -f UTF-8 -t ct 問題なんだけど
AIXの実装はきっちりDOCS(Designation of Other Coding System)を実装してんのね、ヴォースゲー。

$ od -x test.txt
0000000  e380 8000
0000003
$ iconv -f UTF-8 -t ct test.txt | od -x
0000000  1b25 2f30 8089 5554 462d 3802 e380 801b
0000020  2842
0000022

本日はPOWERな箱なのでBig Endianでお届けしておりま、つまりこれ

<ESC> % / 0 \x80 \x89 U T F - 8 <STX> \xe3 \x80 \x80

「<ESC> % /」までがDOCSの指示、「0」は可変長であることの指示、「\x80\x89」は
後続バイト数にMSB立てたもの、「UTF-8<STX>」は以下略、続けて生UTF-8という構造。

これならUTF-8 → ct → eucJPの変換がUTF-8 → eucJPと完全に等価になるから
どの国語を優先するかおのずと決まりますな。

よってTODO追加、citrus_iso2022.cでのDOCSサポートなんだが
さすがにlibISO2022.soが他のプラグイン例えばlibUTF8.soなんかを呼ぶのはアレな希ガス。

それに現状DOCSやDRCS(Dynamically Redefinable Character Setを実装するには
wchar_tに空きが無いんだよな、Unicodeだけならitojunさんが上手いこと
MSB(いわゆるＭＯＨＴＡ　ＢＩＴ)をリザーブしてくれてたんだけども。

さぁどうすんべか、完璧な実装が欲しければ一度wchar_tにするという
iconv_stdモジュールだと限界があるので、内部ISO2022でコード変換する
iconv_iso2022モジュールちうものが欲しいかんじか。

あーそれにDOCSの後続バイト数の計算はmb/wc変換がiconv(3)の中で動く実装には厳しいすな。
同様のものに UTF-6の圧縮率決定問題など。

まぁそのためのプラグインなので以下略

2009/11/10(Tue)

○ 今日

@

どうやらAIXのlibX11はiconv化されてるみたいね、ソースはnmの結果。
iconv -lするとISO8859-1-GLとかJISX0208とかfontsetで使用されてるげなコード名が表示されよる。
なのでiconvでのCOMPOUND_TEXTサポートは必須だったちゅうことっぽい。

2009/11/13(Fri)

○ 今日

@

モンスターの生まれる11月ちゅうことで、いきなり本業炎上してまいりました。

ちうことで土曜日は体制を立て直すために休出、はぁ。
日曜日は心に茨城を持つ少年という電波を突然傍受したので、水戸の偕楽園に遊びに行く予定。

2009/11/28(Sat)

○ 近況

@

ご無沙汰しておりま、ここんとこ「 ~~ガイア~~会社が俺にもっと輝け働けと囁いてる」
メンズナックル状態で、こっちに書くネタ書く暇ないという。

ほんとはAIXのincludeの下にイパーイあるobsoleteと思わしき
数々のi18n APIの話とか書きたいんですが。

ちなみに年明けると通勤時間が往復6時間になるかもらしいぞ☆(←死兆星的な意味で)