HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2016
0304
tds12HSPランタイムのUnicode対応について52解決


tds12

リンク

2016/3/4(Fri) 12:58:07|NO.74766

HSPランタイムのUnicodeについて、
対応したランタイムがひとまず形になったので、
その宣伝・説明・動作確認募集・改良案募集 などを兼ねて、
雑談スレとさせていただきます。

Unicode対応HSPランタイム「hsp3W」
https://www.dropbox.com/s/vojb2kazbrqntpu/hsp3W_001.zip?dl=0

ソースコードは後から公開するつもりです。

反応お願いします。



この記事に返信する


tds12

リンク

2016/3/4(Fri) 21:11:37|NO.74771

すみません。書き忘れていました。
コンパイル実行する場合は、
以下のようなスクリプトで実行してください。
「ファイル名」には、実行したいhspファイルの
ファイル名から、拡張子を除いたものが入ります。

#include "hspcmp.as" hsc_ini "ファイル名.hsp" hsc_comp 4,0,0 exec "hsp3W ファイル名.ax"



tds12

リンク

2016/3/4(Fri) 21:30:56|NO.74772

ランタイム内部では、utf8が使用されていて、
#func func "funcA" str,sptr
のように、strやsptrを指定した場合、
utf8で渡ってしまうため、Unicode版関数〜〜Wを使うか、
MultiByteToWideCharとcnvwtosを使ってください。

日本語を使うためには、hspcmpでaxファイルへ、utf8で出力し、
実行する必要があります。
そのため、No.74771のスクリプトを使ってください。

現在、utf8からsjisやutf8からUnicode(utf16)へ変換する
命令や関数がないのは、改良すべきかと思っています。

意見あればよろしくお願いします。



zakki

リンク

2016/3/4(Fri) 22:39:32|NO.74773

面白いですね。
定義だけされてるHSC3_OPT_UTF8IN 32も使えるとソースもUnicodeでかけていいんですが。



おにたま(管理人)

リンク

2016/3/4(Fri) 22:47:33|NO.74776

HSPランタイムのUnicode化、興味深いですね。
内部の描画やテキスト処理は、WideChar(UTF16)を使用しているということですか?
プラグインの相性とか、DLLを使用するモジュールの互換性のためにsjisに変換して渡すような仕組みとかあると便利かもしれませんね。



cats

リンク

2016/3/4(Fri) 22:55:16|NO.74779

ちょっとだけ使ってみました。
個人的にマルチバイトはあまり使いませんが、動作に問題がなければ使いたいです。
いくつか質問があります。

1.
毎回NO.74771のようなコードを走らせる必要があるんですか?
#runtime "hsp3W"
だけで動くようになったら嬉しいです。

2.
デバッグモードが使えないようですが、対応していますか?(個人的にかなり痛い)

3.
こんな感じで使えたら嬉しいです。

#uselib "user32.dll" #func MessageBox "MessageBoxW" int, wptr, wptr, int MessageBox 0, "The quick brown fox jumps over the lazy dog!", "Hello, world!", 0

あと、cnvwtosとcnvstowでUnicode->SJIS->Unicodeをしたら元に戻りませんでした。
もしかしたらHSPの命令側のバグかもしれませんが。

#runtime "hsp3W" sdim s1, 64 : sdim u1, 64 : sdim u2, 64 u1 = "こんにちは" s1 = cnvwtos(u1) cnvstow u2, s1 // u1 != u2

少なくともデバッグができるようになるのと、APIへ文字列を渡すときの
仕様というか正しい使い方がドキュメント化されれば是非使いたいです。



tds12

リンク

2016/3/5(Sat) 15:07:00|NO.74784

>面白いですね。
zakkiさん、ありがとうございます。

>定義だけされてるHSC3_OPT_UTF8IN 32も使えるとソースもUnicodeでかけていいんですが。
できるといいですね。いまのところ、スクリプトへUnicodeの文字を直接記述できないので、
入出力時の効果が主ですね。
わたしは、コンパイラの方がよくわかっていないので、他の方に期待しようと思いますが、
試すだけ試してみようかと思いもします。

>HSPランタイムのUnicode化、興味深いですね。
おにたまさん、ありがとうございます。

>内部の描画やテキスト処理は、WideChar(UTF16)を使用しているということですか?
内部のテキスト処理は、utf8が主で、一部にutf16の部分があります。
描画の部分は、utf8からその都度変換してutf16としてAPIへ渡しています。

>プラグインの相性とか
BMSCR構造体やHSPCTX構造体は特に触れていないので、その部分は問題ないと思うのですが、
code_getsで取得できる文字列はShiftJISではなく、utf8なので、
多くの関数に変更が必要になるかと思います。

>sjisに変換して渡すような仕組み
やはり、#func時のstrやsptrはsjisの方がよいかもしれませんね。

>ちょっとだけ使ってみました。
catsさん、ありがとうございます。

>毎回NO.74771のようなコードを走らせる必要があるんですか?
その必要がありました。
スクリプトエディタの方でutf8出力を指定できればよいのですが、
まだできないので、
コンパイル実行用のランタイムを別に作りましたので、
あとのリンクからダウンロードし、使ってみてください。

>デバッグモードが使えないようですが、対応していますか?(個人的にかなり痛い)
まだ、ランタイム側の変更のみなので、後で対応したいと思っていますが、
今のところできません。
また、同じDLLだと、Windows98を使っている方がデバッグウィンドウを使えなくなるので、
工夫が必要だと思っています(このランタイムの環境はWindowsXP以降のため)。

>こんな感じで使えたら嬉しいです。
wstrではできたのですが、wptrで出来なかったのは、バグです。
修正してきました。
あとのリンクからインストールすることで、治ると思います。

>あと、cnvwtosとcnvstowでUnicode->SJIS->Unicodeをしたら元に戻りませんでした。
Wという名が誤解を招いてる気もしますが、内部ではutf8です。
str型の変数もutf8で格納されているので、元にもは戻りません。
cnvwtosはUnicode(utf16)からShiftJISへ変換していて、
cnvstowはShiftJISからUnicode(utf16)へ変換されるのは、仕様です。
ただし、cnv8tow(utf8からUnicode(utf16)へ変換)や
cnvsto8(ShiftJISからutf8へ変換)
のような命令は用意しようかとも考えています。

----
バグ修正とコンパイル用ランタイムの追加で、
改良してきました。
https://www.dropbox.com/s/x3fjkjkrf97g5gu/hsp3W_002.zip?dl=0

コンパイル用ランタイムは、utf8でaxファイルを生成し、hsp3Wに実行させます。
使い方は、↓
スクリプトに
「#runtime "hsp3Wcmp"」と書き、
実行したいhspファイルのフルパスをダブルクォーテーションで囲んで
起動オプションの先頭へ追加し、実行してください。

また、よろしくお願いします。



waw

リンク

2016/3/6(Sun) 01:55:09|NO.74790

疑問なんですがなぜutf8なんでしょうか。
Win32APIみたいなライブラリではutf16なんでそっちに合わせないと不便な気がしますが。
utf8はバイト単位でutf16は文字単位なのでstrlenみたいな命令を使う場合単位の変換が面倒ですよね。



tds12

リンク

2016/3/6(Sun) 10:39:18|NO.74792

>疑問なんですがなぜutf8なんでしょうか。

コンパイラに触れたくなかったのが主な理由です。

utf8ならばhspcmp.dllに標準で出力させることができることを
利用したかったのです。

axファイルのことを考えなければ、utf16対応は比較的簡単だとは思いますが、
axファイルがutf8だったので、utf8のほうがメリットが有ると思いました。



skyblue

リンク

2016/3/6(Sun) 10:48:44|NO.74793

>疑問なんですがなぜutf8なんでしょうか。
utf16はサローゲートペアというめんどくさいものがあります。
それに対して、utf8はどこから読んでもバイト位置がわかるという特性があります。
あと、最近のLinuxの標準です。

つまり、適当な位置のバイトを読み込んで
それが1バイト目かそうでないかがビット単位で比較すれば分かります。
それ以外にもASCIIコードと互換性があります。

utf16にはASCIIと互換性がありませんし半角文字が必ず2バイトだし
一部4バイトになるというややこしいものがあります。

utf8はASCIIとが互換性があるし半角は1バイトです。
必ず1バイトです。(ビットでバイト位置を判別できる)
エンディアンがutf16にはあるけど、utf8には無いという所です。



waw

リンク

2016/3/6(Sun) 22:22:55|NO.74803

>コンパイラに触れたくなかったのが主な理由です。
なるほどです。
現状だとそれしかないんでしょうね。
でもWindowsプログラミングではutf16以外だとデメリットの方ずっと多い気がするんですよね。

それは置いといても、正式にHSPがunicode対応になってくれればいいんですが。
シフトjisにない文字を使った名前のファイルに対応できないので、正直今のHSPは仕様が古くて
ツール作成には使えないと思うので。



skyblue

リンク

2016/3/7(Mon) 11:43:44|NO.74808

>シフトjisにない文字を使った名前のファイルに対応できないので、正直今のHSPは仕様が古くて
そこは、Unicode用のWin32APIを使って作るとか?
そして表示の時とかはない文字だけ読みを表示とかにするとか、工夫すれば大丈夫?



waw

リンク

2016/3/7(Mon) 20:59:29|NO.74810

>そこは、Unicode用のWin32APIを使って作るとか?
>そして表示の時とかはない文字だけ読みを表示とかにするとか、工夫すれば大丈夫?
実際にやってみればわかりますがとても面倒で全然大丈夫じゃないです。



zakki

リンク

2016/3/7(Mon) 22:34:39|NO.74811

文字列の内部表現をUCS-2で16bitにするとW系のWin32APIを直接呼ぶのには楽ですが
コンパイラとランタイムとスクリプトとプラグインの全部の内部表現をwchar_tに
する必要があるのでそれはそれで全然大丈夫じゃないですね
UTF-8だとnull終端のマルチバイト文字として扱ってる限りは現状のプログラム使えて
外部API呼び出し箇所の変更で済みます

内部表現をUTF-8/UTF-16/UTF-32にするのはそれぞれ一長一短あってなんとも



skyblue

リンク

2016/3/8(Tue) 10:14:06|NO.74815

>文字列の内部表現をUCS-2で16bitにするとW系のWin32APIを直接呼ぶのには楽ですが
注意しないといけないのはUTF-16は4バイトの文字もあると言うところです。

>内部表現をUTF-8/UTF-16/UTF-32にするのはそれぞれ一長一短あってなんとも
UTF-8の場合内部表現の変更はほとんど要らなさそうと言うところです。
日本語などのマルチバイト関係の処理の所だけ変更すれば言いだけです。



waw

リンク

2016/3/8(Tue) 20:13:24|NO.74826

>全部の内部表現をwchar_tにする必要があるのでそれはそれで全然大丈夫じゃないですね
>UTF-8だとnull終端のマルチバイト文字として扱ってる限りは現状のプログラム使えて外部API呼び出し箇所の変更で済みます
文字列のコピーや加算程度ならともかくその他の文字列処理は全部unicode用に置き換えなければいけないと思うんですが。
utf8がutf16より大きく楽になるとはあまり思えないです



skyblue

リンク

2016/3/9(Wed) 10:40:11|NO.74832

>文字列のコピーや加算程度ならともかくその他の文字列処理は全部unicode用に置き換えなければいけないと思うんですが。
>utf8がutf16より大きく楽になるとはあまり思えないです
内部に文字コードのフラグを追加して、
連結はUnicode側に変換して連結
検索は専用関数を呼び出すか、処理を分けるかです
挿入も検索と同じです。
表示はUnicode専用のAPIがあるのでUTF-16に変換して呼び出したりとか

工夫すれば書いた通りに出来ます。
数値や半角については事前にCP932に変換してしまえばほとんど修正が要らないですし、
全角の所だけ考えれば大丈夫です。



waw

リンク

2016/3/9(Wed) 21:03:39|NO.74841

>工夫すれば書いた通りに出来ます。
わざわざそんなことをするのにどんな意味があるんでしょうか。



skyblue

リンク

2016/3/10(Thu) 10:44:03|NO.74846

>わざわざそんなことをするのにどんな意味があるんでしょうか。
出来る限り修正せずに少ない労力で対応にする事が出来る



waw

リンク

2016/3/10(Thu) 21:42:39|NO.74853

わざわざそんなことするくらいなら普通にunicode対応の処理に置き換えたほうが簡単でしょうという意味だったんですが



skyblue

リンク

2016/3/11(Fri) 10:58:03|NO.74863

>わざわざそんなことするくらいなら普通にunicode対応の処理に置き換えたほうが簡単でしょうという意味だったんですが
Unicodeと言う語には8,16,32の違いがあり(基本16)
さらにはUTFには2種類の表記ゆれがあり、かつエンディアンの問題があります。
なので、一番対応がしやすいのはエンディアンの問題が実質無いUTF-8になります。

全部置き換えると、互換性という最大の壁があります。
それ以外にもエンディアンとかサローゲートペアとかBOMの有無とかがあります。
UTF-8にはエンディアンとかサローゲートペアとかBOMの有無とかがありません。
内部処理だけならばUTF-32がお勧めです、固定長なので。
UTF-32にはサローゲートペアはありませんが。



waw

リンク

2016/3/11(Fri) 22:37:30|NO.74873

なんか話がずれてますよね。
従来のシフトJIS用に書かれたコードをunicode対応にするときutf16よりutf8ならかんたんになるのかという話なんですが
windowsプログラミングのutf16は普通リトルエンディアンですがそのことでutf8が簡単になるんですか?
utf8だとutf16用であるAPIやランタイム関数呼び出し時の変換も面倒になると思うのですがそれらの手間を差し引いてもその方が有益ですか?



skyblue

リンク

2016/3/12(Sat) 12:52:32|NO.74883

従来のシフトJIS用に書かれたコードをunicode対応にするときutf16よりutf8ならかんたんになるのかという話なんですが
どちらも変わりません。実装のしやすさです。
SJISであるけど、Unicodeでないものやその逆など普通にあります。
ひとまず、あなたはUnicode対応ってどういうようなものを指しますか?
自分は実装のしやすさやファイルへの入出力時のエンディアンなどの問題などを含めてです。
ファイルから読み込む場合はUTF-8以外の2つはエンディアンの問題と
BOMがないときの問題があります。
本来は必要ないけどUTF-8にもBOMはあるときがありますが、
BOMの有無によるエンディアンの問題は発生しません。BOMは無視しても大丈夫です。
上記の事から忙しいおにたまさんが実装しやすいように
日本語の所だけをUnicodeの処理を追加するだけを言っています。


utf-16/32はASCIIと互換性がありません。(エンディアンの問題があるため)
hspcmp.dll内部の文字コードは上記の通り固定長なUTF-32がお勧めです。
SJISからの変換は面倒です。ASCIIの範囲だったら比較的どれでもしやすい



>windowsプログラミングのutf16は普通リトルエンディアンですがそのことでutf8が簡単になるんですか?
>utf8だとutf16用であるAPIやランタイム関数呼び出し時の変換も面倒になると思うのですがそれらの手間を差し引いてもその方が有益ですか?
たいていの人はWin32APIを呼び出すような事はしません。
ゲームなどの凝ったものを作る人だけです。



zakki

リンク

2016/3/12(Sat) 19:01:59|NO.74889

dishのWindows以外の環境では既に内部UTF-8なので、Windows版でも内部UTF-8でWindows APIとのやり取りだけ
UTF-16使うのにも一定の合理性あると言いたいだけでwawさんがUTF-16版作られるのに反対なわけではないです

API呼び出すのには2バイトが楽だし、BMP外の文字扱うのには4バイト表現が楽ですし。



waw

リンク

2016/3/13(Sun) 01:26:12|NO.74892

>ひとまず、あなたはUnicode対応ってどういうようなものを指しますか?
だからソースコードをシフトJISからunicode対応にすることですよ。
>たいていの人はWin32APIを呼び出すような事はしません。
何の話なんでしょうか。
HSPのソースでAPI使ってないんですか。

>dishのWindows以外の環境では既に内部UTF-8なので、Windows版でも内部UTF-8でWindows APIとのやり取りだけUTF-16使うのにも一定の合理性あると
全然そんなこと言ってなかった気がしますが、このことは納得できました。
>wawさんがUTF-16版作られるのに反対なわけではないです
どんな脳内変換したのか知りませんが単に議論してるだけで別につくるとは言ってないです。



skyblue

リンク

2016/3/13(Sun) 10:17:46|NO.74895

>だからソースコードをシフトJISからunicode対応にすることですよ。
HSPのソースコードをUnicodeにするだけでしたら対応とは言いません。
HSPのスクリプトコードをUnicodeにするだけでも対応とは言いません。
スクリプトだけだと結局、内部はSJISのままと言う事なので

>何の話なんでしょうか。
>HSPのソースでAPI使ってないんですか。
スクリプトではなくHSP自体のソースコードと言う意味では
使っています。しかし、自分たちが気にする必要がありません。
例え、いちいち変換しなければいけなくても、
気にするのはHSP自体の開発者であって、自分たちではないからです。
自分はHSP自体の内部処理コードのUnicodeに変えると言う事も含めて言っています。

総論としては、
HSP自体の開発者の立場とHSPを使う開発者の立場と言う
似ているようでまったく違う立場で話が進むと言う認識の齟齬が起きていたということです。



skyblue

リンク

2016/3/13(Sun) 11:26:58|NO.74897

連投になりますが修正と言うか補足を
HSPのスクリプトのUnicode対応とは
かかれた文字列がUnicodeとして認識されるくらいまで言って対応って言うと思っています。

HSP自体のソースコードをUnicodeに変えることは今の時点でも出来ます。
正確に言ったら、VSはUTF-16だと思いますが。
GCCはUnicode(8,16,32)などに限らず、
たいていの文字コードで書かれたソースコードを使えます。



waw

リンク

2016/3/14(Mon) 01:01:03|NO.74913

他の人とは議論が成立してるつもりですがあなたとは全然かみ合わないです。
あなたの言ってることはあちこちポイントずれてて理解するのも一苦労です。
レスするならもうちょっと理解したうえで要点まとめてレスしてください。



tds12

リンク

2016/3/18(Fri) 22:30:34|NO.74956

>プラグインの相性
>code_getsで取得できる文字列はShiftJISではなく、utf8なので、
この解決法が浮かんだ気がするので試してみます。

>cnvwtosとcnvstowでUnicode->SJIS->Unicodeをしたら元に戻りませんでした。
cnv8towやcnvwto8という名で実装してみました。
次の公開で使えるようになると思います。

>少なくともデバッグができるようになるのと
デバッグウィンドウのutf8対応もしてみたので、
しばらくしたら公開します。

>ドキュメント化されれば
ドキュメントが一番やる気が起きなくて、
すみません。
しばらくしたら公開するつもりです。

>正式にHSPがunicode対応になってくれればいいんですが。
MLの方で提案してみます。



素人

リンク

2016/3/21(Mon) 10:09:03|NO.75006

Unicode対応ありがとうございます
Unicodeのテキストファイルを扱わねばならず、文字化けは仕方が無いと我慢していたのですが、こちらのランタイムで文字化けせずに処理できるようになりました

ところで、実行ファイルを作るにはどのようにすればよいのでしょうか?
「実行ファイル自動作成」で作成されたexeは、起動直後に「動作を停止しました」とエラーとなります
START.AXを作成、PACKFILE編集でSTART.AXを指定し、EXEファイル作成で作られたexeは、S-JIS対応のようで半角文字以外は文字化けしてしまいます

すみませんが、実行ファイルの作り方を教えていただけないでしょうか?



tds12

リンク

2016/3/26(Sat) 16:07:01|NO.75083

>、実行ファイルの作り方を教えていただけないでしょうか?
すみません。
バグのためまだ作ることができません。

手元では修正したものがあるので、
配布までお待ち下さい。



tds12

リンク

2016/3/26(Sat) 18:55:26|NO.75085

改良し、アップロードしました。

ランタイムです。
https://www.dropbox.com/s/xmm51a8844b01m8/hsp3W_003.zip?dl=0

ソースコードです。
https://www.dropbox.com/s/lu7i8exuz2ul2yk/hsp3W_003_src.zip?dl=0

>実行ファイルを作るにはどのようにすればよいのでしょうか?
#include "hsp3w.as"
としながら、
スクリプトを書きます。
保存します(毎回)。
起動オプションに、
「"スクリプトのフルパス" オプション」
として、
F5で実行します。



tds12

リンク

2016/3/26(Sat) 19:16:18|NO.75086

すみません。
改良点を書き忘れていました。

デバッグウィンドウの対応、
EXEファイル作成対応、
utf8とutf16の相互変換命令・関数追加、
#funcのstrとsptrをShiftJISへ変換する仕様へ変更、
バグ修正
です。



素人

リンク

2016/3/27(Sun) 23:22:26|NO.75098

修正ありがとうございます
早速DLいたしましたのですが
「hsp3w.as」を見つけられませんでした、、、
よろしくお願いいたします



tds12

リンク

2016/3/27(Sun) 23:32:59|NO.75099

>「hsp3w.as」
入れ忘れていました。
ファイルを更新したので、もう一度ダウンロードして下さい。
https://www.dropbox.com/s/xmm51a8844b01m8/hsp3W_003.zip?dl=0



素人

リンク

2016/3/28(Mon) 23:36:23|NO.75109

早速の対応、感謝いたします

試してみましたが、以前のバージョンと結果は同じです
まずは「♫」(ユニコードの音符記号です)のみのUTF8のテキストファイルを作成

#include "hsp3w.as" notesel uni noteload "保存したテキストファイル" mes uni
をスクリプトエディタで「F5」しますと、音符記号が正常に表示されます

これを「実行ファイル自動作成」でexeを作成すると、起動直後に「Startup failed」のダイアログが表示され終了します
START.AXを作成、PACKFILE編集でSTART.AXを指定し、EXEファイル作成で作られたexeは、S-JIS対応のようで文字化けしてしまいます

現状、自分で使用するには困ってはいないのですが、もし対応可能であればお願いをいたします



kanahiron

リンク

2016/3/29(Tue) 02:15:31|NO.75112

>>75109

>実行ファイルを作るにはどのようにすればよいのでしょうか? #include "hsp3w.as" としながら、 スクリプトを書きます。 保存します(毎回)。 起動オプションに、 「"スクリプトのフルパス" オプション」 として、 F5で実行します。
とありますがそれは大丈夫でしょうか?
私の環境ではunicodeの絵文字も生成された実行ファイルで読み込み表示できています



素人

リンク

2016/3/30(Wed) 01:08:02|NO.75118

>>とありますがそれは大丈夫でしょうか?
>>私の環境ではunicodeの絵文字も生成された実行ファイルで読み込み表示できています

私の環境でも、スクリプトエディタから「コンパイル+実行」をした際は、正しく表示されています
ですが、実行ファイル単体のみを作成して動作させようとしても、上手くいきません

おそらくコマンドラインにソースファイルを指定する必要があることから、実行ファイルのみでは正常に動作しないのかな、と想像しています
このランタイムを使用して実行ファイルが作成できたら、とても有難いです



tds12

リンク

2016/3/30(Wed) 20:14:12|NO.75132

>このランタイムを使用して実行ファイルが作成できたら、とても有難いです
説明不足でした。
F5で実行するときにEXEファイルも生成しています。
スクリプトと同じフォルダを見てください。



素人

リンク

2016/3/30(Wed) 22:09:40|NO.75134

教えていただき有難うございます
>>F5で実行するときにEXEファイルも生成しています。
>>スクリプトと同じフォルダを見てください。
hsptmp.exeが作成されますが、起動直後に「Startup failed.」とタイアログが表示され、終了します
手順どおり行っているはずですし、前述の通りスクリプトエディタから「コンパイル+実行」は正常に動作しています

なお、こちらの環境はVista Home Premium SP2、HSPは3.5 beta3です



tds12

リンク

2016/3/30(Wed) 23:17:28|NO.75136

>起動直後に「Startup failed.」とタイアログが表示され、
#pack "start.ax"
と追加すれば治るかもしれません。



素人

リンク

2016/3/30(Wed) 23:48:55|NO.75137

できました!
作成された実行ファイルを試したところ、問題なく動作するようです
ユニコード対応、本当に有難うございました
そして私のような者にも対応していただき、本当に感謝いたします
お疲れ様でした!



tds12

リンク

2016/7/21(Thu) 22:41:59|NO.76292

しばらく間がありましたが、現在の状況です。

Unicode対応HSPランタイムは、hsp3utfとしてOpenHSPで管理されています。
http://dev.onionsoft.net/trac/openhsp/

No.75099のhsp3Wから、以下のバグが修正されています。
・comboxとlistboxの表示がおかしい
・sysinfoを使ったときランタイムが落ちる問題
・strrepのネスト
・NUL文字が考慮されていなかった問題
・6バイトutf8コードへの対応
・ファイルダイアログでランタイムが落ちる問題
以下の変更がありました。
・cnv8towを廃止し、utf8をsjisに変換するcnvstoaを追加
・cnvwto8を廃止し、sjisをutf8に変換するcnvatosを追加
以下の追加がありました。
・utf8で出力するコンパイルオプション
・コマンドライン版コンパイラとそのutf8入出力
・utf8のスクリプトのコンパイル
そのほか、
OpenHSP781からOpenHSP806への変更がありました。

次期パッケージからは同梱されるようです。

プラグインやDLLへ、文字列をどのように渡すか(sjisかutf8か)は今後検討されるようです。

バイナリ配布は公式パッケージの様子次第で行います。

まだまだ反応お待ちしております。



tds12

リンク

2016/7/28(Thu) 23:11:59|NO.76419

Unicode対応OpenHSP807相当の最新版です。
HSP3.5β3へのパッチです。
https://www.dropbox.com/s/gorxircx6yqtwlu/hsp3utf_20160727a.zip?dl=0
くわしくは、readmeをご覧ください。



tds12

リンク

2016/8/3(Wed) 21:37:27|NO.76510

HSP3.5β4へのパッチです。
oncmdが機能しない不具合を修正しました。

https://www.dropbox.com/s/tlobt1az4akladm/hsp810oncmd2.zip?dl=0



mem

リンク

2016/8/13(Sat) 07:16:46|NO.76606

Unicode版たとcomで文字化けします



tds12

リンク

2016/8/13(Sat) 11:29:14|NO.76608

>Unicode版たとcomで文字化けします
確認いたしました。
修正します。



tds12

リンク

2016/8/13(Sat) 19:41:15|NO.76611

>Unicode版たとcomで文字化けします
修正しました。
https://www.dropbox.com/s/raf75ilbd56ucwl/hsp3utf_20160813.zip?dl=0



tds12

リンク

2016/10/7(Fri) 00:32:41|NO.77057

更新しました。
OpenHSPの820に対応しています。
https://www.dropbox.com/s/5rckwlsdawrnj3v/hsp3utf_20161006.zip?dl=0



tds12

リンク

2016/12/1(Thu) 22:02:15|NO.77428

更新しました。
OpenHSPの822に対応しています。

また、Unicode対応版スクリプトエディタも追加されています。
スクリプトに直接Unicode文字を含めて
文字列やコメントに使うことができます。

https://www.dropbox.com/s/hldlogsl96f42zv/hsp3utf_20161128.zip?dl=0



Taker32X

リンク

2016/12/17(Sat) 19:48:17|NO.77616

Unicode対応エディタ、便利ですね。
でも、ランタイムエラーが頻繁に出るところが気になります。
バックアップを取っていたので良かったのですが、保存と同時にランタイムエラーが出た時にスクリプトのデータが消えたので、この問題の御確認をお願いしたいと思います。



tds12

リンク

2016/12/18(Sun) 12:53:34|NO.77632

ありがとうございます。

確認しました。
↓に修正しました。
https://www.dropbox.com/s/ido5m9vgkrqexmp/hsp3utf_20161218.zip?dl=0

いくつか問題の場所を見つけ修正しましたが、
また問題あればよろしくお願いします。



tds12

リンク

2017/2/1(Wed) 20:16:48|NO.78100

拡張版デバッグウィンドウであるknowbugをhsp3utf用にしてみます。
https://www.dropbox.com/s/af73x5in81kw0j4/knowbugu8_20170131a.zip?dl=0



ONION software Copyright 1997-2021(c) All rights reserved.