\u???? による指定で矛盾No.02407
Iranoan さん 09/04/11 02:38
 
 秀丸担当さん今日は、Iranoan です。
 末尾にサンプル・マクロを書きますが、\u???? による文字表現を使った場
合、値が変化します。
 こちらの環境は、WindowsXP+IE7.0+秀丸 Ver.7.11b02 です。
//------------------------------------------------------------
setencode 1, 0;
call Message;
setencode 8, 0;
call Message;
config "xFont(Times New Roman)";
call Message;
setencode 1, 0;
endmacro;

Message:
  message unichar( 0xC0 );//欧文で半角「タ」になる
  //↓等幅/プロポーショナル・フォントで変化 (欧文範囲外だから仕方が無い?)
  message str( strlen( "\u05D0-\u05EA" ) );
  return;

[ ]
RE:02407 \u???? による指定で矛盾No.02408
秀丸担当 さん 09/04/13 14:44
 

マクロを実行してみたところ、Times New Romanのときだけ、5になりました。

strlenは、半角は1文字ぶん、全角は2文字ぶんとして数えていますが、
Unicode独自の文字は、文字の幅から半角か全角かを判断しています。
欧文文字は半角固定、漢字は全角固定なのですが、一概に判断できない文字は、
文字の幅から判断していました。

なぜかというと、固定ピッチフォントの場合、全角か半角かで升目上に収まるよ
うに判断しないといけないためで、x,y,movetoなどの計算とstrlenが合うように
なっているためです。

プロポーショナルフォントの場合は、その計算は関係無いのですが、全角の判断
は、固定ピッチフォントと同じようにしていました。
Times New Roman の該当の文字は一見半角の幅のように見えますが、半角の基準
となる幅はルーラーの1文字分で、Times New Roman の場合は半角の幅が短いた
め、それを超える幅の文字時は全角と判断されているようです。

[ ]
RE:02408 \u???? による指定で矛盾No.02409
Iranoan さん 09/04/13 20:07
 
 秀丸担当さん今日は、Iranoan です。
> マクロを実行してみたところ、Times New Romanのときだけ、5になりました。
 ご確認有難うございます。
 おそらく単なる Times でも 5 になると思いますが、結局これは
・仕様
・バグ
どちらという認識なのでしょう? もし仕様だとすると、
・leftstr(), rightstr(), midstr() による文字の取り出しが上手くいかない
  ケースが出てくる
  //------------------------------------------------------------
  $top = leftstr( $s, #m );
  $end = rightstr( $s, strlen( $s ) - #m - 1 );
  //------------------------------------------------------------
  等、欧文文字なら 1 文字として処理する事は良くあると思うのですが....。
・movetolino #i + strlen( $s ), #y;
・if( strlen( $s ) > 257 )message "検索文字列としては長すぎる";
等で、異なる結果になると困ります。また世には非常に多くのフォントがある
ので、フォントによって処理を変えるというのも現実的では有りません。

 また
>   message unichar( 0xC0 );//欧文で半角「タ」になる
について、コメントを頂いていません。Unicode で指定しているのにのに、字
が変わるというのは、不味くないですか?

[ ]
RE:02409 \u???? による指定で矛盾No.02410
秀丸担当 さん 09/04/14 11:03
 

> おそらく単なる Times でも 5 になると思いますが、結局これは
>・仕様
>・バグ
>どちらという認識なのでしょう? もし仕様だとすると、

現時点では仕様ということになってしまうのですが、言われている通り、不都合
があることは理解でき、その通りだと思います。
もともとUnicode文字の想定が無いマクロの互換性を維持させようということが、
いろいろ無理なことを発生させてしまっていると思います。

根本的に解決するには、例えば Unicode版 strlen の wcslen を作るなど、
Unicode解釈の関数を全面的に用意するしか無いかもしれないです。


>>   message unichar( 0xC0 );//欧文で半角「タ」になる
>について、コメントを頂いていません。Unicode で指定しているのにのに、字
>が変わるというのは、不味くないですか?

調べてみたところ、欧文のとき、
 message "\xC0";
 insert "\xC0";
が違うという問題と同じことのようです。
互換性を考慮すると、いろいろ難しい問題がありそうです。
文字列型変数の格納方法を、内部的にも全面的にUnicodeにしないと解決できな
いかもしれないです。
将来的に strlen の件も含め、何らかの方法を考えなくてはいけないと思います。
そうしたとすると、互換性をどこまで維持できるかという問題もまたでてきそう
で、厄介なのではありますが…

現時点では、エンコードがShift-JISのときでないと、「タ」になってしまう問
題は避けられそうにないようです。
申し訳ありません。

[ ]
RE:02410 \u???? による指定で矛盾No.02411
Iranoan さん 09/04/14 14:17
 
 秀丸担当さん今日は、Iranoan です。
> 互換性を考慮すると、いろいろ難しい問題がありそうです。
> 文字列型変数の格納方法を、内部的にも全面的にUnicodeにしないと解決できな
> いかもしれないです。
> 将来的に strlen の件も含め、何らかの方法を考えなくてはいけないと思います。
> そうしたとすると、互換性をどこまで維持できるかという問題もまたでてきそう
> で、厄介なのではありますが…
 現時点では、どちらも仕様ということですか。上位互換を考慮すると、難し
いという事も理解できました。
 ##しかし現状で対処法も無いので、さてどうしたものか。確実にやるには、
一時的に書き込んで、そこで処理するしかないか。
 
 現状、秀丸担当さんのほうで、どのようなフォントで
strlen( "\u05D0" ) == 2
となるのか、規則性は解りますか? 日本語環境なら、
( fontmode&1 ) &&
  ( dllfunc( "FindRegular","[(I!(B-(I_ぁ-んァ-ヶ亜-K]", fontname, 0 ) == -1 )
で多くの場合は対処できそうですが....。

[ ]
RE:02411 \u???? による指定で矛盾No.02412
秀丸担当 さん 09/04/14 15:15
 

いろいろご迷惑をおかけして申し訳ありません。

> 現状、秀丸担当さんのほうで、どのようなフォントで
>strlen( "\u05D0" ) == 2
>となるのか、規則性は解りますか? 日本語環境なら、

本末転倒かもしれないですが、
if( strlen( "\u05D0" ) == 2 ) {
 :
}
と判定される場合、strlen( "\u05D0" ) == 2 となる、という判断ではどうでし
ょうか。当たり前といえば当たり前ではありますが。

[ ]
RE:02412 \u???? による指定で矛盾No.02413
Iranoan さん 09/04/14 16:16
 
 秀丸担当さん今日は、Iranoan です。
> strlen( "\u05D0" ) == 2 となる、という判断ではどうでし
> ょうか。当たり前といえば当たり前ではありますが。
 確かに本末転倒かもしれませんが、これが一番確実かもしれませんね。

 P.S どうやら、結果が異なる文字は、日中韓以外の文字で 0x100 以上の
コードのようです。

[ ]