ISO/IEC 2022実装

改良など


今日は、幾つかの処理の改良や、新造をした。

第二中間文字として2/1だけでなく、2/2、2/3にも対応するようにした。
この後に、更に2/0~2/15が1つだけ追加される拡張にも何れ対応できるように、CCS-IDの仕様に明記しておいた。


DOCS


DOCS(DESIGNATE OTHER CODING SYSTEM)の処理を改良した。
従来は、エスケープシーケンスを受けたらそのままCES-ID/CCS-IDをUTF-8などに変えていましたが、これをやめた。
CES-IDはISO/IEC 2022のままで、CCS-IDでUTF-8/16、UCS2/4の区別をするようにした。
関連して、Unicode処理DLLで対応処理を追加。

なぜなら、本当にUTF-8の処理に切り替えてしまうと、ESC 2/5 4/0で戻るかどうかの処理が怪しくなるからです。


通常のUTF-8では、エスケープシーケンスは無視してバイトをそのままで扱う。


間に2/15を挟まない場合は、C0がISO/IEC 2022のまま生きているので、ESC 2/5 4/0で戻ることができる。
実際には、C0が生きているので、更にエスケープシーケンスを使って別の文字集合に変更したりも可能なんですが、これはどうなんだろうか。


間に2/15を挟んだ場合は、エスケープシーケンスは無視するようにC0を指示し直し、エスケープシーケンスは無視してバイトをそのままで扱うので、決して戻ることはない。


恐らく、仕様が想定しているような動作となっているだろう。

ここで発生した疑問は、ESC 2/5 4/7 などとしてUTF-8に切り替えた場合、どのバージョンの文字集合を使えばよいのだろうか、という点。
一応、最新版を選ぶようにした。他に方法がないので。


あと、Unicodeまわりで実装水準1~3まで選択可能だけれど、特に今のところ区別はしていない。
どう処理するかの検討もまだしていないけれど、需要あるんだろうか。



DRCS


動的再指定可能文字セットへの対応準備。
処理はまだ書いていないが、標準のCCS-IDの範囲について規定した。

実際には標準のCCS-IDの場合は内部で処理を定義しないので、そのまま1文字ごとにU+FFFDを吐き出す関数行きになる。
何の文字だか規定されていない謎の集合を指示しているのだから、仕方がないのである。


ARIB STD-B24の文字集合に対応する処理を書くときには、エスケープシーケンスを受信した時点でCES-IDを確認し、必要に応じて別の、ちゃんと使うCCS-IDで指示することになる。



ARIB STD-B24の文字集合


ARIB STD-B24の複雑なエスケープシーケンスは、受信はするが、それを解読したあとは捨てられる。
つまり、ARIB STD-B24を入力し、ARIB STD-B24を出力しても、出力は全く違ったものになるだろう。この辺りは仕方がないところである。

特に、マクロに対応するとしても、マクロの入力は受けても、これを出力することは無さそうな気がする。まだ作っていないから何とも言えないが、そんな気がする。


あと、ARIB STD-B24には色々な文字集合がありますが、内部ではそれぞれに個別の文字集合番号を附番して元の文字集合を維持する努力をしたい。
平仮名や片仮名の文字集合の1バイトかな文字も、内部ではそれを維持する。
ただUnicodeとして吐き出す場合、普通のひらがな・カタカナの番号に割り振ってしまって良いのだろうか。他に方法がないけれど、一方向変換になるのかな。

ところで、DRCSの文字は、Unicodeのどこに割り当てればよいのだろう。
常識的に考えればU+E000~の外字領域になるのだろうが、仕様書を見ていると、独自拡張文字がこの領域に割り当てられているようだ。
ARIB STD-B24は、UTF-8やUTF-16BE WITH BOMにも対応しており、Unicodeから拡張文字を使う場合は、この符号位置を指定するようです。



MSX文字集合


1バイトかな文字で思い出しましたが、そういえば、MSXにもANKモードには「半角ひらがな」があった。
SCREEN 0での表示性を高めるため、MSX2以降はフォントが若干変わったりもした。

MSX1とMSX2+は実機が押し入れの中に大切に保存されているが、この漢字集合もなかなか特徴的で興味深いものだった。
妙な拡張記号類が大量に含まれていた。
Unicodeに無いような摩訶不思議な記号もいっぱいあったはず。
あと、JIS C 6226の拡張で、空いていた6区からいきなり拡張記号類を追加したため、JIS X 0208相当の罫線の符号位置が違ったりもした。98なんてメではなかったな。

対応するのは、やぶさかでは無いのだが、はたして需要あるだろうか。

MSXを骨の髄まで愛した私ですら、MSX独自の文字を使ったような文書は手元に残っていないわけであります。

2009/01/15(木)22:01 |Comments(2) |Trackback(0)

製造開発 | プログラミング | コンピュータ | [編集]

▲ページトップ

コメント

DRCSでは、終端バイトにFtを使った場合でも、すべて私用になります(JIS X 0202:1998 13.3.3)。U+FFFDにするより、他の私用終端バイトと同じ扱い(Unicodeに出力するならPUAのどこかに割り当て)のほうがいいと思います。

ARIB STD-B24の拡張文字は、一部がISO/IEC 10646:2003 Amd.5:2008 (Unicode 5.2)で追加されました。
Japanese TV Symbols Update
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3469.pdf
Proposal to encode six CJK Ideographs in UCS
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3318.pdf
最終的な符号位置は提案文書のものとは異なる可能性があるので、必ずAmd.5の実物で確認してください。
http://standards.iso.org/ittf/PubliclyAvailableStandards/c046577_ISO_IEC_10646_2003_Amd_5_2008(E).zip
HKSCSやKPS 9566でも問題になると思いますが、一部の符号はUnicodeに変換する場合、変換先のバージョンに応じてPUAにマップするか追加文字にマップするか変えなければならないかもしれません。
2009/01/16(金)12:34 |えむけい | URL |編集
▲ページトップ

入力時点では、出力の符号を一切考慮しない設計になっています。

Unicodeのバージョンによって出すべき符号を変えなければならないこともあるようなので、入力時点でUnicodeでの第一候補と第二候補が選択可能なように、処理の対応準備をしてみました。

実際にどう処理するかは、作りながら考えていきたいと思います。
2009/01/20(火)16:34 |miraicorp | URL |編集
▲ページトップ

コメントの投稿

DRCSまわりのシーケンス ホーム JIS X 0202:1998
トラックバック

この記事にトラックバックする(FC2ブログユーザー)
▲ページトップ

カレンダー

09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterツイッター

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR