符号「C99とJAVA」

折角APIをiconv風にしてしまったので、「iconvで扱える符号は原則全てを実装」という自然な流れで作業を始めました。

いま使っているFreeBSDに入っているiconvは
iconv (GNU libiconv 1.13)
とのことなので、とりあえずここにある符号は対応させることにします。
但しソースを見るわけには行かないので、別途資料を集めて独自に実装します。どのみち機構が全く違うので、ソースの流用も難しいでしょうし。


そんな中で今日は、C99とJAVAという、対応符号中で最も意味の良く分からないものの入出力に対応させました。
文字番号と実際の文字を変換する処理のようです。

次のような動作をするようです。

① ASCII文字はそのまま。原文中に含まれる \ もそのままスルーする
② C99は、U+100からU+FFFDまでは \u**** 形式
③ C99は、U+10000以上は \U******** 形式
④ JAVAは、全てを \u**** 形式する。サロゲートペアは \ud8**\udc** のような形式
⑤ BOMは出力しない

この符号の入出力双方に対応させました。
これがどのような需要のある符号なのか良く分かりませんが、わざわざ実装されているということは、何らかの需要があったのでしょうか。

現時点では、正常系は同じ動作をするものと推定されますが、異常系については違う動作をします。
iconvでC99やJAVAで入力させるとき、ASCII文字以外ではエラーになって変換処理を停止しますが、gTefでは今のところ「途中で止める」という処理がないので(そのうち作る予定ですが)、現時点では不明文字(?など)として扱うことにしました。

また、長さが違う場合などの動作(\u*** など)も違っています。\u***\u**** の場合、4文字目の\が前の処理で吸われるので、u****がそのまま文字として扱われてしまいます。
これで困るようなら改良の余地はありますが、どうでしょう。


\U******** については、JAVAで読み込ませる時には無視して通常の文字列として扱っています(つまり\U を認識させない)。iconvもどうやら同じ動作をするようです(いま確認した)。


あとは、一覧を見る限りでは普通の符号ばかりで、また対応済みのものも多いようなので、遠からず網羅できるものと思われます。

2009/09/16(水)13:47 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

コメント

コメントの投稿

MSXの機種依存文字 ホーム gTef 0.08 beta 公開のお知らせ
トラックバック

この記事にトラックバックする(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