KANOU Hiroki
kanou****@khdd*****
2005年 5月 3日 (火) 18:58:37 JST
狩野です。 岩井さんのご指摘のとおり、* 4 では足りない場合がありますね。 仕様を勘違いしていました。 > > KANOU Hiroki <kanou****@khdd*****> wrote: > > Message-ID: <20050****@lists*****> > > > RFC2152 をざっと確認してみました。、エンコードする場合は 3 バイト と > > > 先頭の '+' で最大4 バイト (サロゲートペアは個別にエンコード)、 '-' が これが間違いですね。16 ビットを base64 エンコードすれば 3 バイトで 済むと早とちりしていたのですが、UTF-7 は 21 ビットの Unicode の フルレンジをサポートしているわけですから 1 文字につき 4 バイトの 固定エンコーディングなのでしたね。そこにさらにデリミタが入ると。 > Hidetaka Iwai <tyuyu****@debia*****> wrote: > これなんですが、現在の utf7_u_strcpy の実装だと、 > > if ( ubuf!=NULL ) while ( (ch = *ubuf++)!='\0' ) { > > を抜けた後の残りの文字の処理で、 残りが 8 ビットまたは 16 ビット分しか > なくても、シフトして 24 ビットにしてから 6 ビットずつ 4 バイト書き込む > ので、utf7_u_strcpy に渡された ubuf が 1文字の非アスキー文字であれば、 > 最初の'+' と合わせてやはり 5 バイト必要になってしまうようです。 おっしゃるとおりです。さらに、ヌルバイトで終端する必要があるので、 さらに 1 バイト確保しなければなりませんね。 > utf7_enc を残りのビット数に応じて処理を変えるよう変更するか、富豪的に > u2utf7_copy で 5倍確保する必要があると思います。 uchar_t の文字数の 4 倍 + 2 バイト確保することにしました。 (1) 文字列先頭に出て来る可能性のある '+' 用の 1 バイト、 (2) 1 文字につき、エンコーディング文字列 4 バイト、または、 "--" や "+-" に、次の要エンコーディング文字用の "+" がつけ加わることも ある最大 3 バイトが文字数分 (3) 文字列を終端する '\0' 用の 1 バイト という内訳です。 >また、別の不具合になりますが、fontforge/charview.c について、 >stroketypelist[] の userdata が hira_long から実際の配列の index とず >れているために、アウトラインビューで[点]->[ストローク情報]でストローク >タイプに kamae 以降の項目を選ぶとSIGSEGV になります。 こちらのご指摘もありがとうございました。修正しました。 今日実装したその他の新機能ですが、リンク点 (Joint。丸で囲まれている部分) を選択すると、重なっている他の点も同時に選択されるようにしました。 別々に移動したい時は、点を選択して、Point メニューでいったんリンクを 解除してから点を別々の場所に移動して、最後にリンクを再設定してください。 (http://bozu.sytes.net/~tyuyu/diary/?200505a&to=200505021#200505021 で 岩井さんの作成された「英」の字を見て、右払いが横画から離れているのに 気づき、この機能を追加してみました)。 狩野 宏樹 <kanou****@khdd*****>
