いつ誰がEUCを作ったか
のざきさんの 「AT&TがEUC(Extended UNIX Code)をUNIXの文字符号化手法として使うようになったのって正確にはいつからなんですかね」 について。FreeBSD 4.6.2 からのわたしが解説しますよ。
結論からいえば 1985 年で、この年に System V Release 2*1 に対する拡張として、Japanese Application Environment がリリースされたようです (要公式リリース資料)。ただし、それが「EUC」という名前だったかについては今のところ不明。
その前段階として件の日本語UNIX システム諮問委員会では当然議論があったわけですが、その一員にAT&T UNIX Pacificがいる。ゆえに、1984年以前から実装は開始されていて、委員会へ開示されたタイミングである1984年がそのコードに残っているのではないか、と推測してみるわけです。
EUC がいつ生まれたかについては、調べている途中で塩崎さんと熊谷さんのやりとりもひっかかってきたので、塩崎さんの方でも載せていただけるともうちょっと情報が集まるんじゃないかなぁとか思ってみたりも。
*1:2009-03-12訂正 System V Release 3 は1987年
日本語EUCの歴史
EUC-JP の歴史ではないことに注意していただきたい、EUC-JP には (おそらく) JIS X 0212、つまり補助漢字を含んだもの (UI-OSF 日本語環境実装規約 Version 1.1 の AJEC。とは言ってもこれは追認規格だったらしい) のことだろうが、「日本語 EUC」といった場合、その前も含んでいる。というわけで、以下メモ。
1985年に日本語UNIXシステム諮問委員会が設置。メンバーは大学、NTT、富士通、日立、三菱、NEC、沖、東芝、AT&T UNIX Pacific。委員長は石田晴久東大教授。
1985年4月、UNIXシステム日本語機能提案書を、AT&T インターナショナル・ジャパンに答申。
「日本語用UNIX 内部コード体系」を定義
1985年にJAE (Japanese Application Environment) 第1版リリース (リリース主体は AT&T UNIX Pacific?)
http://ci.nii.ac.jp/naid/110002717870/
AT&TのUNIX System V Release 3 以降の標準リリースや日本語処理パッケージのJAE/JIOという形でUNIXの8ビット化、16ビットコードのサポート、日本語入力機能など、日本語処理には不可欠な問題も、UNIXの国際化の観点から議論され、統一的にサポートされるようになった。
http://ci.nii.ac.jp/naid/110002894948/
1988年5月、AT&T UNIX Pacific が MNLSをリリース。
http://www.cbronline.com/news/att_unix_pacific_offers_supplement_for_multinational_languages
「歴史的には、まず「日本語EUC」の元 (ujis) があって、その工夫を I18N 的枠組に拡張したものが EUC」
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-tech-jp/2269
ujis はシグマプロジェクト用の名前 (=ujis/Unixized JIS?)
http://www.ie.u-ryukyu.ac.jp/~kono/fj/fj.kanji/567.html
「日本の Linux の黎明期には真鍋氏の手による JE がほぼ唯一の日本語環境であり、それが採用していた "ja_JP.ujis" が事実上の標準のロケール名称であったという歴史的経緯がある」
http://www.linux.or.jp/JF/JFdocs/Japanese-Locale-Policy.txt
業界としても日本語 EUC における補助漢字への対応を公式に示す必要に迫られ，1991年12月に公開したのが「UI-OSF 共通日本語 EUC」である
http://blog.livedoor.jp/numa2666/archives/50236450.html
UI-OSF 日本語環境実装規約 Version 1.1 1993 年5 月21 日 等で eucJP が用いられる
IANA に登録されている「EUC-JP」はこれ。
http://home.m05.itscom.net/numa/cde/ucs-conv/ucs-conv.html
Unicode との間のコード変換規則として eucJP-ms, eucJP-0201, eucJP-ascii が定義される。
http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html
http://www.w3.org/TR/japanese-xml/
MicrosoftのCP51932。
補助漢字対応以前の日本語EUCからG3外字をばっさり切り落とした
http://legacy-encoding.sourceforge.jp/wiki/index.php?cp51932
つまり、わたしが言いたいのは、UNIXシステム日本語機能提案書と、日経エレクトロニクスの記事が読みたいということなのです。
日本語UNIX諮問委員会:UNIX日本語機能提案書, Press Release, 解説“NEレポート, 日本語版Unix の標準案を提案,” 日経エレクトロニクス，No.370，pp.111-113(1985)
New I18N API?
iconv_open("WCHAR_T")的なもので行きたい模様
とりあえず、iconv はバイト列同士での変換だと思うから、それを widechar にしちゃうのは気に入らないなぁとか。
あとエラーハンドリングは、そもそも文字コード変換に失敗した場合アプリは処理継続しちゃダメ、絶対なのよな。
処理継続しようとがっつくと、つまらない セキュリティホールを生むわけでして。
新規に受け付けるというか、すぐそこにそのデータを作ったユーザがいるなら変なデータは即突っぱねた方がユーザのためだと思います。けれども、旧システムからの移行等で、そのデータを作ったユーザが今生きてるかどうかすら分からないような場合、悩ましいですよねぇ。
fopen(3)のccs=
flag拡張
Ruby 1.9 にも open("hoge.txt", "r:utf-8") みたいな記法はありますな、これはこれであるといいのでしょうが。おそらくのざきさんは、プログラム内は基本的にすでに wchar_t になっているから変換は必要ない。変換が必要なバイト列は基本的に外部のファイルであり、ゆえに fopen に変換を仕込めば解決、ってロジックだと予想。で、これがjoerg氏には伝わっていないとみた。
mbrtowc_enc
木を隠すなら森の中、ゴミを隠すならゴミの山と申しまして。。。
fmemopen(3)とopen_memstream(3)
こっちは上記を前提とした上で、万が一プログラム内にバイト列が紛れ込んだ時も、同じ方法で扱えるというメリットがあると。しかし、前提が共有できていないとメリットは伝わらないし、ファイル以外からもバイト列が飛び込んでくる場合は煩雑なだけとか。それでもiconvが隠蔽できるのはメリットなのでしょうけれど。
本気でやるなら CERT managed Stringのstring_mのように 文字コード情報埋め込みの文字列型を用意するべき
ついでにGCまでしてくれれば完璧ですね。それなんてRubyのC API?
iconv(3)に指定すべき文字コードはISO-8859-1ではなくてISO-8859-1@XML1.0といった別の何かを指定してしまえばいいんでね？
それだと用意されているオプション「何か」しか使えないような。libcの外の人には置換文字の選択肢が増える程度ですよね。(まぁ、XML文字参照を増やすだけでもだいぶ変わるとは思いますけれど)
