Skip to content

Latest commit

 

History

History
111 lines (73 loc) · 7.36 KB

README.md

File metadata and controls

111 lines (73 loc) · 7.36 KB
Raw

秀丸独自スタートユニコード関係

CC0

秀丸スタートユニコード ⇒ wstring

この「G:\repogitory\hm_analyze_unique_encode\秀丸独自スターユニコードからwstringへ」のフォルダのやり方で十分だと思われる。
(このデコードを扱う必要があるシーンというのは非常に限られており、直接扱う際にそんな大長文といったことは考えられないため)

wstring ⇒ 秀丸スタートユニコード

「wstringから秀丸独自スタートユニコードへ」のやり方で全ての文字が正しく変換可能(=現在秀丸本体が行っている変換と全てのwstring文字で一致する)、
しかし、これでは非常に遅くなってしまう。
(多少は改善できるだろうが、根本的に秀丸本体とは異なり、スタート時点がwstringになってしまっている時点で改善が難しい)

hmPython3やhm.NETやHm.CppInvokeのように直接wstring⇒秀丸スタートユニコードも含めた変換マップを0x0000～0xFFFF持ってしまったほうが良い。
(50倍以上速いのではなかろうか...)

0x0000～0xFFFFの変換ではあるが、ちゃんとサロゲート系も含め変換・再現される。

C#について

  • エンコード C#については、Stringのutf16からcp932など、エンコード変更の際のフォールバックの機能や実装方法が整理されているため、
    エンコードを全変換マップを予め持つ方法ではなく、秀丸エディタがやっている計算による変換方法でやるのもギリギリありかもしれない。
    しかし、それでも「ソースを直接渡し、相手がそのソースを直接使う」シーンのみに限られると思う。
    （例えば Hm.NetCOM）
    コンパイルしたものしか渡さない場合は、「直接のマップ」でやった方がやるかに速い。 (全マップを持っていれば、文字列のSJISへの変換、計算、フォールバックからの再計算、など一切不要で、直接変換していくため。 UTF16の状態から秀丸エディタのやり方を踏襲すると、１文字に対して、４回５回と多段に変換式と計算式が入るため非常に遅くなる)

  • デコード デコードのアルゴリズムについては、hm.NET, Hm.NetCOM, hmV8, hmJS 他、.NET Framework / .NET Core ベースのものでは全て、 上記秀丸掲示板で公開されたアルゴリズムに従ったもので実装されている。

掲示板からの抜粋

　一応簡単に内部のデータ構造を説明させていただきますと・・・

　内部の文字列は基本charの配列（普通のクラシックなC言語の文字列）になってまして、Shift-JISそのまま（いわゆるMBCS文字列）が基本です。そして、Shift-JIS範囲外の文字がある場合、たとえばそれがwchって値だったとすると、それを以下のルールで４バイトに変換します。

　１バイト目 ... \x1Aの文字。
　２バイト目 ... 0x80 | LOBYTE(wch)
　３バイト目 ... 0x80 | HIBYTE(wch)
　４バイト目 ... ((wch & 0x80) >> 7) + ((wch & 0x8000) >> 14) + 4 + nZenkaku

　でして、上記の「nZenkaku」は、全角文字なら8、そうでないなら0って値になります。

　全角文字かどうかは別途ユニコード範囲のマップをもっててそれで決めています。


[ △ ]
RE:39777 正規表現DLLに検索文字列などとして渡される秀丸独	No.39778
秀まるお2 さん　22/05/24 18:31　[ コメントを投稿する ]
　	　４バイト目 ... ((wch & 0x80) >> 7) + ((wch & 0x8000) >> 14) + 4 + nZenkaku

　の間違いでした。

　秀丸メールの中では\x1Aで始まる４バイトのデータを「STARTUNI」と呼んでまして、

#define IsSTARTUNI_inline( p ) ( (*(DWORD*)(p) & 0xF4808000) == 0x04808000 )

　ってマクロでそれかどうか判定します。

WCHAR inline GetUnicodeInText( char* pchSrc ) {
    return MAKEWORD( (pchSrc[1] & 0x7F | ((pchSrc[3] & 0x01) << 7)),
                    (pchSrc[2] & 0x7F | ((pchSrc[3] & 0x02) << 6)) );
}

　って関数でWCHARに変換するだけです。

　秀丸エディタの内部テキストをユニコードに変換するのは上記のロジックで簡単に出来ます。

　逆方向にするなら全角文字かどうかの判定が必要でして、それはライブラリが無いと対応できないと思います。HmJre.dllの代替品を作るだけなら上記のロジックが分かってるだけで簡単に対応できると思います。ライブラリも不要です。

　この辺サクっと理解できるならいいですが、ちんぷんかんぷんってことでしたら、難しいことはやめた方がいいんじゃないかと思います。デバッグの手伝いも僕はやるつもりはありませんし、プログラミングに関係することに長文で質問されるだけでも、それを読むだけでも大変なので、勘弁してほしい所です。
[ △ ]
RE:39778 正規表現DLLに検索文字列などとして渡される秀丸独	No.39779
秀まるお2 さん　22/05/24 18:40　[ コメントを投稿する ]
　	　今さらながら思ったんですが、HmJre.dllの代替品を作るって話でしたっけか？
　（という、根本的な所に戻ってしまうのですが）

　もしそういうことでしたら、大変ハードルが高いです。

　参考資料として、HmJre.dllの秀丸エディタとやりとりしてるインタフェース部分のソースコードだけならお渡ししてもいいです。メールにて「xxxxx@mitene.or.jp」に連絡くれれば返信します。

　正規表現の処理をしてる本体ソースコードはお渡しできません。または、渡しししたソースコードの中で果たして何をしてるのかは、特にちゃんとしたドキュメントも書いてないし、質問されてもお返事しません。自分で考えて分からなかったらあきらめてもらうしかありません。

　そういう条件（質問一切不可）でならソースコードをお渡しします。

　たぶんそういうことなら変換用のライブラリは不要です。


---以下の内容はコミュニテックス会議室システムにより付加されました。
本文中のメールアドレスは伏せ字に変換されました。伏せ字にしたくない場合
はメールアドレスを""で囲んで書き込んでください。

nZenkaku が明言されていないが、

  • 非常に入り組んでおり、単純な判定ではない。
    1(1万6000文字):4(4万9000文字)程度の比率で半角・全角が入り混じって設定されており、単純な話ではない。 　「全角半角マップ」フォルダにExcelが入っているので参照のこと。
    　全て半角想定、全て全角想定、実際で秀丸エディタで利用されている変換値から、全角・半角のマップが弾きだされている。