Not only is the Internet dead, it's starting to smell really bad.:2009年11月分

2009/11/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版と同じプロトタイプ。

(追記)

#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

でおkっちゅうこと、一部のアプリが動いとるだけで「日本語入力システムが利用可能」とは言わんがな。
なんで、ここまで読んだ人は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

2

3

)にしたレヴィ=ストロース先生死去、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(いわゆるMOHTA BIT)をリザーブしてくれてたんだけども。

さぁどうすんべか、完璧な実装が欲しければ一度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時間になるかもらしいぞ☆(←死兆星的な意味で)