現在、リージョンをまたいだIMが文字化けしています。
日本語が ????? で表示されてしまいます。
同一リージョン内でのIMは正常に表示されます。
レポートありがとうございます．
たぶん，OpenSimのソースでIMのコード系が ASCIIになっているような気がします．
後で OpenSimのソースコードを見直してみます．
しばらくお待ちください．（間違い箇所を発見した後，パッチ配布，再コンパイル，再起動が必要です）
今日8月23日に Shinobar Annexで受け取った DAIKIさんからのIMはちゃんと日本語が表示されてました。SIMのバージョンなのかなあ？
すみません．
8/26 のDBクラッシュでデータが飛んでしまったので，できる範囲で手動で代理再投稿します．
--------------
2018年 08月 24日(金曜日) 21:43 - Iseki Fumikazu の投稿
いろいろ情報が不正確なので，上記の２つの投稿は "なし" にしてください．
OpenSim のソースコードは，読めば読むほど謎が深まる!!
--------------
2018年 08月 25日(土曜日) 10:26 - Shinobar Martinek の投稿
IMの文字化けについて実験しました。M&Fcreation01, Shinobar Annex, JOG Center SIM いずれもSIMのバージョンが異なります。
２人のアバターが同一SIMであれば文字化けは起こりません。
1人を JOG Center Sim に、他を Shinobar Annexに置きます。このとき、JOG Center SIM → Shinobar AnnexへのIMは文字化けするが、逆の Shinobar Annex → JOG Center SIM は文字化けしません。
1人を M&Fcreation01 に、他を Shinobar Annex に置きます。このとき双方向とも文字化けせず正常です。
面白いことに、どちらかのアバターがofflineで、IMが保存された場合は、いずれのSIMから打ったものでも受けたものでも文字化けは無いようです。
何かヒントになれば。
--------------
2018年 08月 25日(土曜日) 12:12 - Xpyoda Janus の投稿
あ、上記の方法でDBを設定しても、ProfileやSearchは日本語化けます....。この部分は、パッチが必要になるかも。いずれにしろ、エンコーディングがあってないのが原因だと思います。うーむ、あっち立てればこちらが立たず....。
--------------
2018年 08月 25日(土曜日) 12:01 - Xpyoda Janus の投稿
以前の「質問コーナー」でのスレッド
独自グリッドでの文字化けについて教えてください
https://www.jogrid.net/wi/mod/forum/discuss.php?d=1197
が関連してるかもです。
サーバーをSSDディスクで再構築したということなので、DBのデフォルトエンコーディンがutf8になってなかったりするんじゃないでしょうか?自前のグリッド(NXGrid、Robust.exe DBはMySQL)では、OSGridのソースコードそのまんまでオンライン・オフラインともに日本語メッセージがつかえてるような雰囲気です。OfflineMessageモジュールも、外部PHPサーバーつくる必要ありません。
JOGrid謹製の(Offline)Messaging モジュールは、(OpenSimで使っている)XmlRpc.dllのエンコーディングがASCIIで決め打ちされているので、文字コードの問題を避けるために、Base64エンコーディングを使って、DBにもBase64の文字列のまま保存していますが、DBはutf8エンコードにすれば、対応できます。
ただし、XmlRpc.dllのデフォルトエンコーディングがASCIIなので、HTTPでやり取りされる日本語文字列は、URLエンコードされるのでデーターサイズが3倍になります。例: あ(3 byte) --> %e3%81%82 (9 byte)。
C#の中では文字列はUNICODE(2 byte???)で統一されています(昔からのMicrosoftの流儀だとおもう)。これをDBに書き込むときにDBのエンコードで書き込むので、DBがutf8になってないと化けてしまうということではないでしょうか?
ということで、OSGrid、OpenSimのコードそのもので日本語が問題なければ、十分なテストをした上で、JOG謹製のメッセージ関連モジュールを廃止してはどうでしょう? (メンテナンスする人材の問題もありますし...) 。
将来的には、XmlRpc.dllの デフォルトエンコーディングをASCIIからUTF8に変えてもらうように説得するのもありかもしれません。Webは既にUTF8が大勢をしめていますし、そこは問題ないかも。ただDBを、今Latain1でうまくいっている人たちに、utf8をデフォルトにしてもらうのは、反発があるかもとは思います....。
結局 XmlRpc が UTF-8 を通さないようなので，文字化けする個所は全て Bas64でエンコードして送ることにしました．
現在，SIMを再起動すれば直るはずです．
タイミングを見て再起動します．
OpenSIm の新しいProfile モジュール (v2) は頭の痛い問題で，これを使うには現在の DBを全て作り変えないといけません．
テーブルに互換性がありませんので．
IMの文字化けについて再度の実験しました。結論から言うと、さらに問題が拡大しています。
M&Fcreation01, Shinobar Annex, JOG Center SIM いずれもSIMのバージョンが異なります。JOG Center Sim, Dejima, JOG meetsのバージョンは同じはず。
M&Fcreation01←→Shinobar Annex 相互は従来どおり何も問題が無いことを再確認しました。
Dejima ←→JOG meets間でも少なくとも１度は文字化けなくIMできました。
しかし Shinobar Annex ←→JOG Center SIM 間では User offlineとかでIMが届かない
あるいは Dejima ←→JOG Center SIM 間でもIMが届かないことがあります。
たまたま通信できても文字化け(Base64に変換されたものがそのまま表示される)ます。JOG Center SIMなど→Shinobar Annexはもちろん、Dejima ←→JOG Center SIM 間でも文字化けすることがあります。
不安定な気がするので、報告はこれぐらいにとどめます。
再々実験しました。これまで一方のアバターはスタンドアロンHGでしたが、今回はどちらもJOGのアバターとしました。
今回実験のSIMは Shinobar Annexと JOG Center Simの間だけです。
JOG Center Sim → Shinobar Annex のIMが文字化けすることは同じだが、先日は ???の表示だったが、今日は Base64に変換されたものがそのまま表示される。
Shinobar Annex → JOG Center Sim はUser offlineとされ、IMは保存される。（これまでに無い異常）
JOG Center Sim 側のアバターをリログさせると、保存されていたIMが文字化けなく表示される。
今度は Shinobar Annex 側のアバターを落とし、JOG Center Sim側からIMを打つと、当然ながらIMは保存される。
Shinobar Annex 側で再ログイン。保存されていた JOG Center Simからの IMがBase64に変換されたものがそのまま表示される。(これまでは保存されたIMはどこから発信されたものも文字化けなく表示されていた。）
以上です。
「opensimのソースコード」とは、どれをベースとしてご覧になっているのでしょうか？
最新の本家公式リリース opensim-0.9.0.1でスタンドアロンHGを動かしていますが、SIMを越えてのIMに文字化けはありません。
また最近のOSGからリリースされた opensim-OSGを用いた Shinobar Annexや M&Fcreations01でも文字化けがないことは、すでに報告したとおりです。
この問題でDBは関係ないと思います。27日の修正以前で申しますと、文字化けがあったのは他所のSIMに居るオンラインのアバターとの間だけで、オフラインの保存メッセージに文字化けは無かったからです。
加えて言うと、profileの文字化けについて私は確認していません。報告されているprofileの文字化けは偶発的事故か、いずれにせよIMの文字化けとは関連しない別問題だと思います。
すみません、IMの文字化けの症状でいまだにとても困っています。
先日のグリッドダウン騒動の後から
外部からの自前接続シムbyakko（OpenSIMバージョンはJOG公式の0.9.0）で発生します。
いただいたメッセージが
「 [04:05] xxxxx（相手のアバターさんの名前）: 44GT44KT44Gw44KT44Gv772X 」
どれもこのような意味不明の文字になってしまいます。
イベントなども控えており、いろいろな方からメッセージをいただくのですが
どのメッセージも同じような症状で困っています。
IMなどのコミュニケーションはこの世界ではとても重要なツールなので
どうか早急のご対応をお願いいたします。
Base64でエンコードされた文字列がそのままでてますね。
おそらく、やる必要のないところまで、Base64エンコードしてしまってるのかなぁ...。
というわけで、文字化けしてしまったIMを元の文字列になおせる(かもしれない)HUDを作りました。llBase64ToString()を呼んでるだけの簡単なものです。
このBase64 Decorder HUDのGiverBoxは、JOG meetsリージョンの (71, 110, 22)の座標の場所にあります
(カオナシアバターを配布した場所と同じところ)
hop://jogrid.net:8002/JOG%20meets/71/111/22
ちなみに、「44GT44KT44Gw44KT44Gv772X」は「こんばんはｗ」ですね。試してみてね。
P.S.
もうあるとは思うけど、特定の人の間でしかしらないキーで暗号化すれば、周辺チャット経由で会話しても、盗聴されないツールつくれそうですね。周りの人は訳が分からないので嫌がられそうですけど....ww
あ、Decoder の綴りが間違ってる。ハズカシー....w
近日中に、こっそりと直しておきますww
返信が遅れて申し訳ありまでせん．
JOGの現在の OpenSim のバージョンは 2018年 8/20 の gitリポジトリの最新版です．(0.9.1Dev の最新版)
ver. 0.9.0 との間のどこかで IM のコードに関する取扱いが変わったようです．
現在 JOGのメインSIMからのIMは全て Base64にエンコードされて送信されます．
新旧のバージョンのSIMが混在した場合の対応を考えてみます．
回答ありがとうございます。
さきに報告しましたように、openism本家公式 0.9.0.1リリースのバイナリでスタンドアロンでOKでした。今回JOGの Boraboraに0.9.0.1リリースのバイナリを適用、M&Fcreations01やIzumo(JOG 2016/3/30 配布0.9.0Dev Rev.1)などとのIMが相互に正常であることを確認しました。
openism本家公式 0.9.0.1リリースは git 2018/06/30 相当だそうです。ご参考まで。
新旧バージョンの混在した環境では難しいですね．
JOG に適用されているパッチとか設定ファイルを可能な範囲で subversion のリポジトリにしました．
自分でソースをコンパイルする人やソースコードを読みたい人は参考にしてください．
http://www.nsl.tuis.ac.jp/svn/opensim/jogrid.config/trunk/
また，以前から公開していますが，JOGの独自モジュール関連はこちら
http://www.nsl.tuis.ac.jp/svn/opensim/opensim.modules/trunk/
Modlos はこちら
opensimのgitから最新ソースを落としてきて、mono-5.14.0 でコンパイルしました。Fumiさんがおっしゃったように、ver. 0.9.0 と0.9.1Devとの間のどこかでおかしくなったようです。
0.9.0.1リリースのバイナリでJOGに接続したSIMは、センター地域以外のJOG接続SIMとの間で相互に問題なくIMできることを報告しました。
今回、opensimの最新ソースからコンパイルした OpenSim 0.9.1.0 Snail Dev でJOGに接続した Izumoリージョンで、0.9.0.1 Release のSIMとのIMを実験しました。いずれも JOGのパッチは当てていませんが、JOG独自のモジュールは使っています。
その結果、8月27日の修正以前の状態が再現できました。
OpenSim 0.9.0.1 Release → OpenSim 0.9.1.0 Snail Dev 文字化けなし
OpenSim 0.9.1.0 Snail Dev → OpenSim 0.9.0.1 Release 文字化け(???と表示される)
OpenSim 0.9.0.1 Releaseは git 2018-06-30 相当とのことなので、そこから 2018-08-20 までに、gitのソースのどこかがおかしくなったようです。
Monoのバージョンも疑ったのですが、同じMono-5.14.0 で OpenSim 0.9.0.1 Releaseのバイナリで文字化けのないことを再確認しました。また、OpenSim 0.9.1.0 Snail Devのスタンドアロンは文字化けしません。スタンドアロンの場合は別リージョンであっても同一リージョン内と同じ処理になるのかもしれません。
久しぶりにOSGridを訪問しました。
OSG着地点の Lbsa PlazaのSIMバージョンは OpenSim 0.9.1.0 Snail Dev 50627304a6: 2018-08-30 20:09:12 +0100 (Unix/Mono) です。 Snoopies Freebies Shopping Mall (Samansa) は OpenSim 0.9.0.0 Dev ab12a142798a1358b82d927f3d6046e30fcc57c2 (Unix/Mono) です。
OpenSim 0.9.0.0 Dev → OpenSim 0.9.1.0 Snail Dev のIMは文字化けなし
OpenSim 0.9.1.0 Snail Dev →OpenSim 0.9.0.0 Dev のIMは文字化け(???)
したがって、これは JOG固有の問題ではなく、OpenSim 0.9.0系と OpenSim 0.9.1.系 Snail Dev との間の問題のようです。
どの時点で変わったのか、はっきりしました。
opensim の git を睨んでいましたが、 0.9.0.1 Release が 6月30日相当というのは間違いでした。正しくは 2018-05-04 22:00 です。
この直後 2018-05-04 22:01 Merge branch 'master' into httptest ということで、大量に変更がなされており、その中にバグが潜り込んでいると思われます。
http://opensimulator.org/viewgit/?a=shortlog&p=opensim&h=HEAD&pg=7
2018-05-04 22:01 のものをダウンロード、コンパイルし、JOGの（パッチは当てておりません。）設定やモジュールを組み込んで接続し、0.9.0.1 Releaseとの間で文字化け再現を確認しました。
すでに報告しているように、文字化けが起きるのはリージョンをまたぐIMのみで、offline IMやグループチャットでは文字化けは起きません。
なお、現在のJOGセンター地域(2018-08-25 のJOGパッチが当たったもの)からのIM、Offline IM, グループチャット、TPコールなどで Baise64に変換されたものが表示され、逆にJOGセンター地域への IMは相手がofflineであるかのように、IMは保存され、グループチャット、TPコールは無視されます。実験はしておりませんが、これは opensim 最新 0.9.1.0 Snail DEV や OSG配布のもので 2018-08-25 のJOGパッチを当てていない SIMとの間でも同様の問題が起きると思われます。
JOG 2018-08-25パッチの当たっていない 0.9.1.0 Snail Dev 同士で文字化けが起きるのは、「リージョンをまたぐ」IMのみと報告しましたが、実験すると同一サーバーの別リージョンへのIMで文字化けはありません。正確には「SIMサーバーをまたぐ」IMにのみ文字化けが生じます。
大元の XMLRPC.dll に手を入れて，UTF8が通るようにしました．
たぶんこれでOKな筈．
おお〜！ Dejima ←→ Shinobar Annex 相互にIMできることを確認しました。
おつかれさまでした。ありがとうございます。
ここ数日間 opensimのgitからソースとにらめっこしていました。もしかしたら見当外れかもしれないという気もしていました。やはり問題はそこには無かったのですね。bin以下に問題があったとは。
opensim 0.9.0.1 Release のbinに含まれる XMLRPC.dll のサイズは 41kBであるのに対し、 git 2018-05-04 22:01 以降の XMLRPC.dll のサイズは 25kB。2018-05-04 22:01に入れ替わってしまっています。
最新の git 2018-09-12 をコンパイルし、文字化けを確認。その後 XMLRPC.dll をopensim 0.9.0.1 Releaseのものと入れ替えることで、文字化けが解消されることを確認しました。
いちおう本家バグレポートに上げておきました。
本家 git 2018-09-17 にて文字化けの解消を確認しました。意外に対応が早かったですね。安心しました。
フミさん、みなさま、お疲れさまでした。
私も先ほど、opnesim-libs のリポジトリの「trunk/managed/XmlRpc」が更新され、utf8がデフォルトエンコーディングになっているのを確認しました。(ビルドはまだしてない、そのうちするw)。
commit 5ccd80a710f9ab00e8098e90af55a7f13dfb652d
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Sep 17 15:59:28 2018 +0100
allow override of XmlRpcRequest HttpWebRequest ServerCertificateValidationCallback
commit af2e4cc36e9d13b2cd4ca8726d42fed09ec414ba
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Sep 17 15:14:36 2018 +0100
mantis 8372: XMLRPC change default encode to utf8
opensimのリポジトリにある bin/XMLRPC.dll はこれが反映されたものなのでしょう。
あと、「if(..)」というようにifの後ろにスペースがつくようになったり、
「...(a,b,c)」が、「...(a, b, c)」というように引数区切りの後ろにスペースがついたりと、見やすく(私好み)になりましたwww。
フミ先生、シノさん、どうもお疲れさまでした。
opnesim-libs のリポジトリの「trunk/managed/XmlRpc」をビルドしてみて、OpenSimの bin/XMLRPC.dll と入れ替えてみました。すると、ログインできなくなりました。
OpenSim.logをログをみると
2018-09-21 10:57:52,380 ERROR [SCENEGRAPH]: Error in MyRegion: System.MissingMethodException: Nwc.XmlRpc.XmlRpcResponse Nwc.XmlRpc.XmlRpcRequest.Send(string,int)
at OpenSim.Services.Connectors.Hypergrid.UserAgentServiceConnector.LogoutAgent (OpenMetaverse.UUID userID, OpenMetaverse.UUID sessionID) [0x00059] in /opt/OpenSim/opensim/NXGrid/2018-01-18/opensim-0.9.0-17
...
のようなエラーがでてます。
これは、XmlRpcRequest.csのSendメンバー関数の引数の数が変わり仕様がかわっているからです。
diff -r XmlRpcRequest.cc.orig XmlRpcRequest.cs
...
104c105
< public XmlRpcResponse Send(String url,int timeout = 100000)
---
> public XmlRpcResponse Send(String url, int timeout = 100000, RemoteCertificateValidationCallback certCallBack = null)
...
Send()メンバ関数の引数が2つから3つに増えてますので、古いバイナリーが呼び出すSend()と型が異なります。ソースコード的には引数省略のパターンで問題ないのですが、バイナリー的には互換性がありません。
従来の「public XmlRpcResponse Send(String url,int timeout = 100000)」もオーバーロード関数として定義し内部から「Send(url, timeout, null)」と呼び出していれば、バイナリー互換性は保てたかもしれません。
OpenSimのソースから全部コンパイルし直せば問題なく動作しました。まあ、依存するライブラリが修正されたのですから、コンパイルし直した方がいいとは思います。このXMLRPC.dll と、コンパイルしなおしたOpenSimで、日本語IMは問題なく通りました。
以上、ハマりやすいポイントなので、ご注意ください。
P.S.
ちなみに、trunk/managed/XmlRpc のビルド方法は次のようにしました。
% cd opensim-libs/trunk/managed/XmlRpc
% xbuild
....
Build succeeded.
Warnings:
/opt/OpenSim/opensim/opensim-libs/trunk/managed/XmlRpc/xmlrpc.sln: warning : Don't know how to handle GlobalSection ExtensibilityGlobals, Ignoring.
1 Warning(s)
0 Error(s)
% ls bin/Debug
XMLRPC.dll XMLRPC.pdb
bin/Debug/XMLRPC.dll を、従来のXMLRPC.dll と入れ替えます。入れ替えるだけではダメで、OpenSimをソースコードからコンパイルしなくてはいけないのは、上に書いた通り。
お疲れさまです。
よく分からないのですが、XMLRPC.dll をソースからビルドする必要はあるでしょうか？ ビルド済みのものがopensimのソースの binディレクトリ内に入っています。Linuxだろうが Windowsだろうがプラットフォームに依存しないから、ここに入れられているのではないでしょうか。
私がやったことは、opensim本家のソース git 2018-09-17 を落としてきて Ubuntu 18.04 + Mono 5.14.0 の環境でビルド、JOGの設定を入れてJOGに接続して確認したものです。このとき XMLRPC.dll は落としてきたソースの binディレクトリに最初から入っており、ビルドの対象ではありません。他の環境下でもそれは同じかと思います。
> よく分からないのですが、XMLRPC.dll をソースからビルドする必要はあるでしょうか？
ビルドする必要はないですw。シノさんがおっしゃるように gitから落として来たら、bin/XMLRPC.dll に入ってますから、2018-09-17 以後に更新したならば、通常はそのまま使ってビルドすれば問題ありません。
あえて言うなら、XMLRPC.dllが2018-09-17以前と以後では、いまのままではバイナリ互換性がないので、OpenSimのバイナリーは、ビルドした時期によって、どちらのXMLRPC.dllを使えばいいかが決まります。(新しいバイナリーパッケージがでたら、同梱されるから問題ないですけど)。
まあ、私がソースからビルドできた方が安心する質なんで、やってみた、やってみたかった、という以上の理由はないですw。またOpenSimのソースはOSGridで配布されているのをとってきてるのでgitで追っかけてないというのもあります。どうやって作られたからわからないバイナリーがあるってのは、なんかスッキリしないっていう気分の問題でしょうか..(Linuxの中にソースコードがない正体不明なバイナリがあったらいやじゃないですか?)。オープンソースなシステムならソースがないと、そこでメンテ不能になってしまいますからね(自分がメンテできるとはいってないww)。
で、ここまで書いて、試しに、従来のバイナリーでも、互換性に問題がでないであろうXMLRPC.dll を作ってみることにしました。以下のように、単に従来と互換があるようにSend()メンバー関数(メソッド)をオーバーロードさせました。
% diff -u XmlRpcRequest.cs.orig XmlRpcRequest.cs
--- XmlRpcRequest.cs.orig 2018-09-21 20:06:40.993545000 +0900
+++ XmlRpcRequest.cs 2018-09-21 20:20:16.593721000 +0900
@@ -102,6 +102,11 @@
/// <summary>Send the request to the server.</summary>
/// <param name="url"><c>String</c> The url of the XML-RPC server.</param>
/// <returns><c>XmlRpcResponse</c> The response generated.</returns>
+ public XmlRpcResponse Send(String url, int timeout = 100000)
+ {
+ return this.Send(url, timeout, null);
+ }
+
public XmlRpcResponse Send(String url, int timeout = 100000, RemoteCertificateValidationCallback certCallBack = null)
{
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
これをビルドして、2018-09-17以前につくられたOpenSimバイナリーのbinにコピーしてみて動かしてみましたが、特に警告はでませんでした。従来のSend()に依存しているものが無いのであれば、このオーバーロードメンバ関数は必要ありませんが...。
このコンパイルした、XMLRPC.dll.20180921 を、もの好きな人の為に添付しておきます。
なにが起こるか、保証できないので、試すなら自己責任でバックアップとってからにしてくださいwww。
# 濃い話?ばかり続いてしまったので、テディさんからクレーム来そうだなぁ...ww。
> XMLRPC.dllが2018-09-17以前と以後では、いまのままではバイナリ互換性がないので、OpenSimのバイナリーは、ビルドした時期によって、どちらのXMLRPC.dllを使えばいいかが決まります。
いえ、それはないです。
2018-09-17以前の gitからビルドしたバイナリ(IMが文字化け)に 2018-09-17 の XMLRPC.dillを突っ込んだら、IM文字化けなしに正常に動きます。
このスレッドで 2018年 09月 13日(木曜日) 09:33 に報告しています。
>> XMLRPC.dllが2018-09-17以前と以後では、いまのままではバイナリ互換性がな
>> いので、OpenSimのバイナリーは、ビルドした時期によって、どちらのXMLRPC.dllを
>> 使えばいいかが決まります。
>
>いえ、それはないです。
理由が分かりました。
opensimリポジトリ と opensim-libリポジトリにある、XMLRPC.dll のバージョンが違います。
opensim-libにある、trunk/managed/XmlRpc の方がバージョンが進んでいます。
opensimの bin/XMLRPC.dll は、ひとつ前のバージョンのデフォルトエンコーディングをUTF-8に修正したもので、Send()メンバー関数の引数仕様はそのままでした。この為、互換性問題は生じなかったようです。
opensim リポジトリの bin/XMLRPC.dll のコミットログ
% git log bin/XMLRPC.dll
commit a5d6a394ef8838230aeeb4f1721bd40ee0b302a5 (HEAD -> master, origin/master, origin/HEAD)
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Sep 17 15:12:02 2018 +0100
mantis 8372: replace XMLRPC.dll with utf8 fix
....
opensim-lib リポジトリの trunk/managed/XmlRpc のコミットログ
% git log trunk/managed/XmlRpc
commit 5ccd80a710f9ab00e8098e90af55a7f13dfb652d (HEAD -> master, origin/master, origin/HEAD)
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Sep 17 15:59:28 2018 +0100
allow override of XmlRpcRequest HttpWebRequest ServerCertificateValidationCallback
commit af2e4cc36e9d13b2cd4ca8726d42fed09ec414ba
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Sep 17 15:14:36 2018 +0100
mantis 8372: XMLRPC change default encode to utf8
...
opensim-lib の方が、コメントから推測するに、通信相手方を確認するコールバック関数を仕込める仕様を追加したものになっており、これがバイナリーレベルの互換性を壊すものになっています。ソースコード全部コンパイルするのなら、特に問題は発生しません。
ちなみに、「mantis 8372」というのは、シノさんが上げられたバグレポートの番号です。
"Notes about Me" もしくは「私にまつわるエトセトラ」のスレッドでも、言及しましたけど、OpenSimのいまのXmlRpcの使い方だと、セキュリティは無いに等しいですから、それを強化する方向に進もうとしているのだと思います。
あと、もう一つ蛇足。
monodisという、monoに付属の逆アセンブラを使うと、XMLRPC.dll がどの仕様のSend()を使っているか確認できます。
opensim リポジトリの bin/XMLRPC.dll
% monodis bin/XMLRPC.dll | grep 'Send('
IL_0007: call instance class Nwc.XmlRpc.XmlRpcResponse class Nwc.XmlRpc.XmlRpcRequest::Send(string, int32)
opensim-lib リポジトリの trunk/managed/XmlRpc
% cd trunk/managed/XmlRpc
% xbuild (ビルド)
...
% monodis bin/Debug/XMLRPC.dll | grep 'Send('
IL_0009: call instance class Nwc.XmlRpc.XmlRpcResponse class Nwc.XmlRpc.XmlRpcRequest::Send(string, int32, class [System]System.Net.Security.RemoteCertificateValidationCallback
もういっちょ、蛇足追加ww
私の調べた範囲ではXmlRpcの C#実装は、似たような亜流がいっぱいあって、OpenSimは、いったいどれをベースにしてるのか、ずっともやもやしてたのです。今回の件で、XmlRpcのソースが opensim-lib にあるのが分かり、UTF-8をデフォルトエンコーディングにしてくれたことで、私的にはかなりスッキリしました。
とりとめのない、殴り書きにお付き合いいただき、どうもありがとうございました。
濃ゆい話ついでに...(まだやるのか...私...ww)
opensim リポジトリの bin/XMLRPC.dll を過去のバージョンも含めてすべて取り出してみました。
% ls
XMLRPC.dll.2007-06-27_646bbbc84b8010e0dacbeed5342cdb045f46cc49
XMLRPC.dll.2007-07-05_8bdbdf48c7896a7cb47d49544ab528a508e557c9
XMLRPC.dll.2007-07-08_24ed79ba122d8f24d29ea1a32e0de63033abaf6e
XMLRPC.dll.2007-07-08_c578d0c37d620d0d1dafc5df8a6902a2be6edb8e
XMLRPC.dll.2007-07_08_c617cf7d84341f025c2b19560c7885102105a419
XMLRPC.dll.2011-04-27_5e3893ca5c8c985bf9b2a1e1dbc94d48a4eb3e96
XMLRPC.dll.2018-01-12_98f79cf7353dda79e235ed76058f8ea990c1f9e1
XMLRPC.dll.2018-09-17_a5d6a394ef8838230aeeb4f1721bd40ee0b302a5
これを 次のshスクリプトで monodisで逆アセンブルし、UTF8,ASCII どちらのエンコーディングを使っているのかしらべたところ次のような結果になりました(単純すぎるやりかたですけど、まあ推測はできる)。
% cat monodis.sh
for f in XMLRPC.dll.*
do
echo "--- $f ---"
monodis $f | grep -E '(UTF8|ASCII)'
done
% sh monodis.sh
--- XMLRPC.dll.2007-06-27_646bbbc84b8010e0dacbeed5342cdb045f46cc49 ---
IL_0001: newobj instance void class [mscorlib]System.Text.ASCIIEncoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.ASCIIEncoding::'.ctor'()
--- XMLRPC.dll.2007-07-05_8bdbdf48c7896a7cb47d49544ab528a508e557c9 ---
class [mscorlib]System.Text.UTF8Encoding V_3,
IL_000e: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
IL_0040: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_002b: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
IL_0041: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
--- XMLRPC.dll.2007-07-08_24ed79ba122d8f24d29ea1a32e0de63033abaf6e ---
class [mscorlib]System.Text.UTF8Encoding V_3,
IL_000c: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
IL_003a: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0014: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
IL_002a: call class [mscorlib]System.Text.Encoding class [mscorlib]System.Text.Encoding::get_UTF8()
--- XMLRPC.dll.2007-07-08_c578d0c37d620d0d1dafc5df8a6902a2be6edb8e ---
class [mscorlib]System.Text.UTF8Encoding V_3,
IL_003c: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
--- XMLRPC.dll.2007-07_08_c617cf7d84341f025c2b19560c7885102105a419 ---
class [mscorlib]System.Text.UTF8Encoding V_3,
IL_0040: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
--- XMLRPC.dll.2011-04-27_5e3893ca5c8c985bf9b2a1e1dbc94d48a4eb3e96 ---
class [mscorlib]System.Text.UTF8Encoding V_3,
IL_003c: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0008: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
--- XMLRPC.dll.2018-01-12_98f79cf7353dda79e235ed76058f8ea990c1f9e1 ---
IL_0001: newobj instance void class [mscorlib]System.Text.ASCIIEncoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.ASCIIEncoding::'.ctor'()
--- XMLRPC.dll.2018-09-17_a5d6a394ef8838230aeeb4f1721bd40ee0b302a5 ---
IL_0001: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
IL_0001: newobj instance void class [mscorlib]System.Text.UTF8Encoding::'.ctor'()
これをみると、つぎのようにデフォルトエンコーディングが途中で変わっています。
2007-06-27 ASCIIEncoding
2007-07-05 ～ 2011-04-27 UTF8Encoding
2018-01-12 ASCIIEncoding
2018-09-17 UTF8Encoding
git log のコメントをみると、2018-01-12から 以前のソースコードとは違うものを使い始めていて、ASCIIEncodingに巻き戻ってしまっています。コミッターもUbitUmarov <ajlduarte@sapo.pt>さんに変わっています。
JOGridのIMの文字化けも、これに影響されてしまったんだと思います。
なんで名指し？ｗｗ
クレームどころか勉強になる濃ゆいお話をいつも傍観（頭に入ってこないだけｗ）しておりますｗ
クレームどころか勉強になる濃ゆいお話をいつも傍観（頭に入ってこないだけｗ）しておりますｗ
メンテナンス作業ご苦労様です。
この話題になんらかの返信しようと思っていましたが、台風関係でバタバタしてて遅れてしまいました。
若干質問があります。気が向いた時で結構ですので、情報をいただければと思います。
質問 1.
> 大元の XMLRPC.dll に手を入れて，UTF8が通るようにしました．
(https://www.jogrid.net/wi/mod/forum/discuss.php?d=1311#p4822)
具体的には、どの元コードをベースに、どのように手をいれたのでしょうか?
http://opensimulator.org/wiki/Development にある、opnesim-libs のリポジトリにある「trunk/managed/XmlRpc」でしょうか?
この「trunk/managed/XmlRpc」は、git log してみたところ 2018-01-11頃にできたもののようです。以前にはありませんでした(FreeBSD用にODEのライブラリをコンパイルするのに古いopnesim-libsが手元にあったのですが、git pull したら、XmlRpcが生えてきました)。このXmlRpcライブラリは、libopenmetaverse 由来のもののようです。
OpenMetaverse Library
https://github.com/jhs/libopenmetaverse/tree/master/Programs/GridProxy/XmlRpcCS
ソースコードを比較したところ、コーディング規約的変更、using ディレクティブの位置の変更、using()ステートメントを使用してソースコードを簡略化、してるようで、それ以外に本質的な変更はなさそうです。
質問の繰り返しになりますが、どの元コードベースに、どのように手をいれたのでしょうか? patchなどありましたら、教えてください。
本件に関する余談。
OSGridのDownloadから2018-01-18版として落としてきたソースコードで自前Gird(NXGrid)動かしてますが、付属のXMLRPC.dllをそのままつかって日本語のIMはやりとりできてます(たまたまなのかもしれませんけど)。
https://www.jogrid.net/wi/mod/forum/discuss.php?d=1197#p4384 にも書いたように、この場合、HTTPボディ部としてはASCIIにエンコードされるので、UTF-8バイト列がURLエンコードされて送られます。デコードする側で、C#のstring(UTF-16) にうまくデコードできているのであれば、文字化けしなさそうです。
質問 2.
> 結局 XmlRpc が UTF-8 を通さないようなので，文字化けする個所は全て Bas64でエンコードして送ることにしました．
(https://www.jogrid.net/wi/mod/forum/discuss.php?d=1311#p4768)
というように、IMが文字化けする問題の対処方法としてBase64エンコードするとありましたが、現在も Base64エンコードしているのでしょうか?
C#の文字列 stringは、内部的にはUTF-16です。サロゲートペアを考えなくていいのであれば、とりあえず一般的に使う日本語文字は通るはずです。フミ先生には必要ないとは思いますが、C#の入門あたりをうろうろしている私も含めてC#やUnicode関係に不案内な人にちょうどいい解説のWebページがありましたので、リンクを書いておきます。
C#と文字コード（前編） Unicodeとは？ その歴史と進化、開発者向け基礎知識
https://www.buildinsider.net/language/csharpunicode/01
C#と文字コード（後編） Unicodeと、C#での文字列の扱い
https://www.buildinsider.net/language/csharpunicode/02
C#の外部環境とのやり取りで、相手方のエンコードに合わせたりする必要はあると思いますが、OpenSimの内部の文字列としては、一貫して C#のstringで保持しておいたほうが、後々の事を考えるといいように思います。たぶん、そうされているのだとは思いますが...。
DBのテキストのエンコーディングも、ちゃんと日本語がはいるものを採用していれば、SQLで検索とかも普通にできていいと思います。
質問の繰り返しになりますが、IMが文字化けする問題の対処方法としてのBase64エンコードは、今も行っているのでしょうか?
お気が向いた時で結構ですので、情報をいただければと思います。
質問１
仰る通り trunk/managed/XmlRpc の XmlRpcRequest.cs です．
最初はわざわざ ASCII にしているのは意味があるのかと思い，エンコードを変えるメソッドを追加しましたが，その後 ASCIIには特に意味がなさそうなので
private Encoding _encoding = new UTF8Encoding();
としています．
この XMLRPC は元々は NWC の XmlRpcCS で，色々なところで改造されて色々なバージョンがあるようです．
質問２
XmlRpcRequest.cs がUTF-8 を通すようになったので，IMについては Base64 のエンコードは中止しています．
Profileモジュールについては以前より一部の通信で Base64化しています．
XmlRpcRequest.cs が Base64 を通すならこれもBase64化しなくても良いかもしれませんので，そのうち修正するかもしれません．（結構色々と忘れている）
C# は私もよく分かりません．(^^; 全てその場しのぎでやっています．
Java と一緒でクラスとか覚えるのが面倒で....
Unicode はプログラマにとっては悪夢のような気が....
なるべく関わらないようにしたい....