The Man Who Fell From The Wrong Side Of The Sky:2009年3月9日分

2009/3/9(Mon)

[i18n][モグタン] EUCはじめてものがたり

すばらしー、JAE(Japanese Application Environment)ははつみみです。

AT&TのUNIX System V Release 3 以降の標準リリースや日本語処理パッケージのJAE/JIOという形でUNIXの8ビット
化、16ビットコードのサポート、日本語入力機能など、日本語処理には不可欠な問題も、UNIXの国際化の観点から議論
され、統一的にサポートされるようになった。

なるほど、この16bitコードがwchar_tの先祖ですやね。

実は調べてたのはEUCの由来がメインではなく、wchar_tという名前がどの時点で使われるようになったか
を確認する途中で出てきた疑問だったので参考リンク非常に興味深いです、ありがとうございます。

http://ci.nii.ac.jp/naid/110002717870/ より引用

4.1 long character 型

 実際のビット幅は, 将来の都合および計算機に合
わせることになるだろうが, とにかく, 今までの
char 型よりもビット幅が倍以上の新しい文字型をC
に導入する必要があることは明らかであろう.
 プログラミング言語の拡張を避けるために, 上述の
処理単位を新しいデータ型として導入するのではな
く, 整数型の別名 (typedef) にするという方針 (JAE
リリース 2.0 で供給される日本語化Cはその予定で
ある) はこの場合可能であろうか.

【中略】

 拡大した文字型を long char 型と名付けることは,
Bell 研究所より示唆をうけたものであるが, キーワー
ドを増やさずにすむという利点があるうえに, 型の拡
張という観点からもまさに的を射た語感の名前といえ
よう.

ちゅうことでこのドキュメント(1986)の時点ではwchar_tではないみたいなんだけど
これもSolarisの/usr/include/widec.hのcopyrightを見る限り

Copyright (c) 1986 AT&T

となってて、すでにwchar_tという名前が存在しててもおかしくないのですよね。

それとも1986の時点ではwidec.hはlong charだったけど、XOJIG(X/Open Joint Internationalization Group)
がMSE(Multibyte Support Environment、後にC90およびC90AMD1で標準化)策定し、SVR4 MNLSで
これをマージした事で、両者の整合性を取るためにs/long char/wchar_t/したとかなんだろうか。

あとなんでwidec.hの関数群はまるっと捨てられたのかも良く判らんのですよ。
まぁ大半の関数は、MSEと名前が違うだけで機能が被ってたり、 安全でなかったりするのだけど
wscasecmp/wsncasecmpとかwsdupは今更GNUがwcs*として再発明してるくらいだから
この時点でMSEに同等品があってもよさそうなのだけど。

JAE 2.0(でたのかな、これそのまんなSVR4 MNLSだったり?)とかSVR4のヘッダでいいから見たいわ。
さぁGoogle、ブック検索で絶版本を勝手公開してる暇があったら
コード検索で絶版OSのソースを勝手公開するんだ(ぉい

まぁ避けられないとはいえ、Σ[お察しください]の名前がでてきてふいた。
やっぱり1984以下略

あと4.4BSDはMSEに何の不満があってPlan9のRuneなんぞインスパイヤしたのだろ。

[追記]
なるほど、C++なんて言語があったことすら忘れてましたwww(ぉい
ウィキペの C++の項読んでたら「1984」のニュースピークの話が出てきてコーヒー噴いた。
やっぱりBIG BROTHER IS WATCHING YOU!

ソースとしてはかなり微妙[要出典]ですが、 これ

C++では、これが予約語として採用された。
_tが付いているが、C++においてはこれは組み込み型の予約語であり、typedefではない。
このような奇妙な名になったのは、Cの遺物といえる。

Cが先? うーむわからん。

[i18n] 続^2 New I18N API

引き続き なるせさんとこ。

ついでにGCまでしてくれれば完璧ですね。それなんてRubyのC API?

そうなんすよねー、高度な文字列処理したけりゃLL使って以下略

それだと用意されているオプション「何か」しか使えないような

SUSv3の時点ではiconvの変換テーブルってのはlocale dataと違って、生成用のツールや
ソースの書式についてのの規定がまるっと欠けとりますやね。
NetBSDならmkcsmapper/mkesdbという独自ツールでユーザも自由に生成できますが
(まぁさすがにやらんけど)、GNU libiconvはありゃCのtableなので再コンパイル必須
よって用意されたものだけ、ということになります。

しかし ISO/IEC TR14652だともうちょい仕様が煮詰めてあって、localedef(1)を使って
iconvの変換テーブルを作成することもOKというようなニュアンスになっとります。
localedef/charmapに加えてrepartoiremapという新しいファイルに異なる文字集合間の
変換ルール(まぁ変換先はUnicodeしか書けない雰囲気ですが)記述できるようになっとります。
ですので、localedef(1)でいくらでもオレオレルールは作れる余地が残されています。

他にもSUSv3の時点でlocaledef(1)でwctype/wctransのuser defined classが作れたりしますので
これつかってisxmlspace()的な関数の代わりをiswctpe(3)で代用することもできますやね。

そもそも「変換できない文字を見つけたらiconv(3)はエラーを投げる」とSUSv3の仕様を曲げたとしても
そのエラーを元に文字参照に置き換えるなんて処理をユーザは書くのはとっても難しいはずなんですよね。

前者はまぁどうせ変換後はUTF-8とか決めうちなら問題にならんのですけど
後者はね…

まぁCSIかつPOSIX localeでXML Parser作るくらいならIBM ICU以下略

そいやjoerg氏って某所でNFSv4の実装どーこーちょっと前いってなかったっけ?
もしかしてその辺もあってNew I18N APIゆうとるのだろか。

俺があと120ヶ月くらい若くて24hour Hacking PeopleならNew I18N API話でもいいんだけどねw

今日

static linkedの場合、翻訳単位の問題で__link_set_decl()が空になってしまう問題のpatchは
commitしてreleng-5にpullup requestかけといた。

lib/40983、include path問題はそのうちCAVENATにでも書いとく。

ふいた、お祈りしますAAそのまんまだ。

ケータイ絵文字が JTC1/SC2/WG2へだと。
ねぇISO/IEC 2022のescape sequenceは? (ぉい

Unicode Nameは初期から結構見直し入ってるくさい、以前にちょっと ネタにした
MAN WITH LONG MOUSTACHE は MAN WITH GUA PI MAO(U+1F359)になってたりとか。
ところで BUCK‐TOOTHED MAN WITH THICK GRASSESって無いの?

あれバナナ(U+1F338)剥けとる、んんんん…ケロタン(U+1F38C)…やんらしい…
それとSPIRAL SHELL(U+1F37B)どうみても 横山まさみち画です、本当にありがとうございました。

そいとナマハゲがOGRE(U+1F360)、天狗がGOBLIN(U+1F361)は納得いかないな。
それともこれCJK統合漢字みたいに日欧統合妖怪なのだろうか…水木先生出番です。
ならIVS使って ゴブリン天狗を切替んと、よしAdobeが後は勝手にやってくれるだろう。