「文字コード表示」に要望(grepの話題にNo.09281
でるもんたいいじま さん 17/01/20 19:56
 
でるもんた・いいじまです。
下記の件に便乗ですが、新しいスレッドを立てます。

> From: "でるもんたいいじま"
> Date: Fri, 20 Jan 2017 16:19:39 +0900
> Subject: turukame.3:09279| RE 09275 【要望】Grepの初期フォルダについて
...
> 幸いにしてサロゲートペアの結合処理は unichar() が自動的にやってくれますし、

☆ ☆ ☆

上記の unichar() の仕様を確認するために使った「文字コードの表示」
コマンドについてです。
(コマンド一覧→その他。メニュー編集をして[表示(V)]に出すこともできる。)

このコマンド、色々な文字コードを表示してくれて重宝しているのですが、
U+10000以上のコードの文字の場合に、UTF-16でのサロゲートペア表現を
表示してくれません。UTF-16のバイナリデータを読み書きする需要はそれ
なりにあると思いますので、これを同時に表示するようにすることを検討して
いただけないでしょうか。

U+10000以上の場合は既存の表示の下に「Unicode(UTF-&16): 0xD83C 0xDFBD」
といった1行を追加する、という仕様が、既存のコードからの変更が最小で
済みそうです。

☆ ☆ ☆

さらに便乗して、日本語以外の文字セットの場合は「&Shift-JIS:」の部分が
「CP936:」のような文言に差し替わりますが、これを「&CP936:」のようにして、
表示されたコードをキー操作でも選択できるようにしていただければ嬉しいです。

よろしくご検討のほどお願いします。

[ ]
RE:09281 「文字コード表示」に要望(grepNo.09283
でるもんたいいじま さん 17/01/22 14:08
 
でるもんた・いいじまです。

> 「文字コードの表示」コマンドについてです。
> (コマンド一覧→その他。メニュー編集をして[表示(V)]に出すこともできる。)
>
> このコマンド、色々な文字コードを表示してくれて重宝しているのですが、
> U+10000以上のコードの文字の場合に、UTF-16でのサロゲートペア表現を
> 表示してくれません。UTF-16のバイナリデータを読み書きする需要はそれ
> なりにあると思いますので、これを同時に表示するようにすることを検討して
> いただけないでしょうか。
>
> U+10000以上の場合は既存の表示の下に「Unicode(UTF-&16): 0xD83C 0xDFBD」
> といった1行を追加する、という仕様が、既存のコードからの変更が最小で
> 済みそうです。

この部分、個人的には美しくないと思うのですが、カッコ書きなしの
「Unicode」を廃して、下記のような表記にしてしまうのもひとつの
方法かもしれません。

文字サンプル:A
&Shift-JIS: 0x41
&EUC: 0x41
&JIS: 0x41
Unicode (UTF-&16): 0x0041
Unicode (UTF-&8): 0x41
Unicode (UTF-&32): 0x00000041

詳細はお任せします。
最低限、U+10000以上の文字についてUTF-16値とUTF-32値が両方わかるように
なっていればそれで大丈夫です。

ただし、U+10000以上の文字のUTF-16値については、リトルエンディアンの場合に
話が少々ややこしくなりますので、「0xD8xxDFxx」のような単一の32bit値の
形式はできる限り避けて、「0xD8xx 0xDFxx」のように16bit値ふたつの形式に
してほしいです。

[ ]
RE:09283 「文字コード表示」に要望(grepNo.09285
秀丸担当 さん 17/01/23 12:23
 

文字コード表示コマンドで、サロゲートペアの情報も表示できたらより良いと思
います。
ついでに、Unicodeは「U+xxxx」という表記にしたほうがいいのではということ
と、UTF-8は「あ」で「0xE38182」といったように表示されていますがバイト列
なので「0xE3 0x81 0x82」としたほうがいいとか、さらに結合文字があると長く
なり「0xE3 0x81 0x82 0xE3 0x82 0x99」とかもあったりするので、いっそのこ
と「0x」は全て取り払ったほうがいいということもあります。

V8.69βが長引きそうであればV8.69で修正するかもしれないですが、一転二転し
そうなので、とりあえず手元では修正しつつ、今後のバージョンで反映を検討し
たいと思います。

[ ]
RE:09285 「文字コード表示」に要望(grepNo.09286
でるもんたいいじま さん 17/01/23 13:52
 
でるもんた・いいじまです。

> V8.69βが長引きそうであればV8.69で修正するかもしれないですが、一転二転し
> そうなので、とりあえず手元では修正しつつ、今後のバージョンで反映を検討し
> たいと思います。

ありがとうございます。よろしくお願いします。

> いっそのこと「0x」は全て取り払ったほうがいいということもあります。

同意しますが、JISコードだけは微妙ですね。JIS規格では16進表記と10進の
面句点表記とが併存しているので、たとえば2121とあった場合に0x2121
(=全角スペース)なのか21区21点(='亀')なのかの曖昧さが残ります。
#後者は21-21(または1-21-21)と書くのが正式な表記ですね。

よろしくご検討ください。

[ ]
RE:09286 「文字コード表示」に要望(grepNo.09290
秀丸担当 さん 17/01/23 16:53
 

確かにJISコードはあやふやになりそうです。
やっぱり0xはあったほうがいいと思います。
UTFはバイト列ではありますが、UTF-16とUTF-32はBEとLEで逆になり、バイト列
は解釈次第なので、0x付きの4桁または8桁ほうがよさそうです。
UTF-8はBEやLEは無いのでバイト列でいいと思います。(ただ長くなるのが気が
かりです)
Unicodeは純粋に文字コードということにして、現時点では以下のようにしよう
かと考えています。また変わるかもしれません。

文字サンプル あ
&Shift-JIS: 0x82A0
&EUC: 0xA4A2
&JIS: 0x2422
&Unicode: U+3042
Unicode (UTF-&16): 0x3042
Unicode (UTF-&8): 0xE3 0x81 0x82
Unicode (UTF-&32): 0x00003042

[ ]
RE:09290 「文字コード表示」に要望(grepNo.09295
でるもんたいいじま さん 17/01/26 06:58
 
でるもんた・いいじまです。お返事ありがとうございます。

> 確かにJISコードはあやふやになりそうです。
> やっぱり0xはあったほうがいいと思います。
...
> UTF-8はBEやLEは無いのでバイト列でいいと思います。
> (ただ長くなるのが気がかりです)

確かに長くなるのは気がかりですね。
確認のため列挙すると、思い当たる範囲では次のようなものがあります。

  1.平仮名・片仮名に濁点・半濁点を合成すると6バイト
  2.ASCII文字にアクセント記号類を2つ合成すると5バイト、
   ASCII以外のアルファベット類にアクセント記号類を2つ合成すると6バイト
  3.BMP(U+xxxx)の漢字に異体字セレクタ(U+E0001など)をつけると7バイト
  4.ハングルを完成形1文字ではなく各音素の合成で表現すると6または9バイト
  5.第1面(U+1xxxx)にある絵文字類には3つ以上を合成可能な例が知られており、
   この場合は12バイト以上
  6.聞くところによると、最近の規格では、「f」(=ヘクタール)のような
   組み文字の新パターンが必要になった場合に備えて任意の文字の並びを
   まとめて1文字として扱う機構が用意されているようで、仮にそれを前提と
   すると片仮名5文字、漢字4文字が射程に入るので、「BMPの漢字4文字」で
   12バイト、「補助漢字面(U+2xxxx)の漢字ばかり4文字」で16バイト、
   「1.で濁点・半濁点と合成した片仮名ばかり5文字」だと何と30バイト

さすがに6.は実装例が少ない(せいぜいWebブラウザくらい)ので今のところ
buffer overflowにだけ注意しておけばいいと思いますが、4.は現代韓国語に
ない古典の発音を表現するために必要ですし、5.あたりも既にツイッターなどで
散見される(=遠からず、こういった合成絵文字を簡単に作出できるスマホ
アプリが出現する可能性が高い)ので、頭の片隅に入れておく必要はあるかと
思います。

> Unicodeは純粋に文字コードということにして、現時点では以下の
> ようにしようかと考えています。また変わるかもしれません。
>
> 文字サンプル あ
> &Shift-JIS: 0x82A0
...
> &Unicode: U+3042
> Unicode (UTF-&16): 0x3042
> Unicode (UTF-&8): 0xE3 0x81 0x82
> Unicode (UTF-&32): 0x00003042

U+xxxxxとUTF-32は常に同じ値が出るはずですので、どちらか片方だけで
いいような気がします。
(ただ、私はユニコードの規格を正確に理解していないので、
 もしかしたら認識を誤っているかもしれません。)

UTF-8は上記のように長くなりそうですし、16進法以外の記法は滅多に使われ
ませんし、定型句 "0x" が総文字数の50%を占めるというのも外見的に煩雑
なので、UTF-8に限って "0x" を省く、というのもありだと思います。

で、合成で複数のコードポイントが一気に並ぶ可能性を考えると(例えば、
上記5.をサポートしようとすればUTF-16のほうも6ワードになります)、
長くなる場合にはウィンドウ内のコントロールの配置を動的に変更して
右側のテキストを2行にする、ということを将来の話として考慮して
いただいてもいいと思います。

気長にお待ちしております。

[ ]
RE:09295 「文字コード表示」に要望(grepNo.09298
秀丸担当 さん 17/01/26 17:05
 

6.の例のようなことまでは今のところ対応していませんが、濁点などの合成や、
異体字セレクタは対応していて、ある程度既に長くなっています。ダイアログの
サイズを自動調整するなども考えたいと思います。
UTF-8は0xはやっぱりいらないと思います。
U+xxxxとUTF-32は同じなのでどちらかでいいと思います。
ご意見参考にさせていただきます。

[ ]