OSX専用2chブラウザ"CocoMonar"(26)

某次期OSで使ってみたらなんか挙動がおかしい感が...
リンクが機能してないし、投稿確認が出るとき自分のレス部分が化けてる。
OSのインストールにしくじっている/OSにまだバグがあるw 可能性もあるけど。
もしかして言語環境が非日本語だったりするとまずい?

禁則事項です♡

>>433
＞言語環境が非日本語
日本語以外の言語リソースは入っていない。日本語以外で使っている場合の不具合のフィードバックは
相対的に少ないので、対応されていない部分があるのかも。
対応された部分: ChangeLog.txt: 2003-09-08

いいこと聞いちゃった。

で、日本語環境にしてみて、挙動どうなったか知りたい

>>436
やはり駄目でした。
Japanese.lprojしかないのだから英語環境でも同じリソースが読み込まれ
ますよね。もし言語環境で挙動に問題が出るとすればコード内かと...
だけど英語でも日本語でも駄目なんで、そうじゃないみたいです。

CocoMonarが一応ビルドできたので少し調べてみた。
うーん、とりあえずNSCharacterSetのサブクラスがうまく動いていなくて、
リンクの認識に失敗している模様。クラスクラスタ関連?

...ま、近いうちに次期OSの正式版は発表されるんでしょうし、
そのときもしCocoMonarがちゃんと動かないなら、手を加えていただくということで。
逆にちゃんと動いたなら... CocoMonarはバグの発見に貢献したか、単に俺の勘違いw

>>433
＞リンクが機能してない
リソース（テキストファイル）のロード部分でこけてる？
（メソッドがなくなれば実行時コンソール見れば済むから、メソッドはあるが動作が変わった？）
　　NSString stringWithContentsOfFile: // Deprecated in 10.4.0
を
　　NSString stringWithContentsOfFile:encoding:error: // 10.4.0 or later
または、
　　NSDataで読んだ後、
　　NSString initWithData:encoding: // 10.0.0 or later
に変更かな？
/*
　　CocoMonar.app/Contents/Resources/innerLink*.txt (UTF-16)
　　application/src/NG/construct/NSCharacterSet+CMXAdditions.m
　　static NSCharacterSet *characterSetFromBundleWithFilename(NSString *filename)

　　CocoMonar.app/Contents/Resources/Zenkaku*.txt or Hankaku*.txt (UTF-16)
　　application/src/v1/application/util/JStringAdditions.m
　　static NSString *loadStringResource(NSString *target, NSString *resource, NSString *type)

　　CocoMonar.app/Contents/Resources/numericCharacters.txt
　　ロード部分不明
*/

情報ありがとうございます。

10.4でdeprecatedになったメソッドはそこかしこにあって、ネットワーク周り(SGNetwork.frameworks)が一番やばそうかと思ってましたが、それ以外もいろいろありそうですね。

>>439
>リソース（テキストファイル）のロード部分でこけてる？

えーと NDA 的に微妙ですがw
以下、自分が調べて理解した（と思っている）前提での話

リンクの不等号部分はテキストファイルからロードした文字でパースしていて（確か）
そこは大丈夫ですが、リンクのレス番部のパースに失敗しています。

具体的には CMRAttributedMessageComposer-Anchor.m の中で
+[NSCharacterSet numberCharacterSet_JP] でインスタンスを生成してレス番部分を
パースしている箇所がありますが、それが機能していません。
何故か、サブクラスのメソッド(-characterIsMember:)自体が呼ばれないようです。
Cocoa 側の問題のような?

とりあえず上記を [NSCharacterSet decimalDigitCharacterSet] にしたらリンクは出ます。
（当然、レス番が半角のときのみですが）

>>441 何故か見えないことになっている。
NSScanner scanCharactersFromSet:intoString: が NSCharacterSet characterIsMember:
を使わずに別のを使っている可能性があると。
CMRNumberCharacterSet_JP の bitmapRepresentation
（今はsuperのを返しているだけ）か longCharacterIsMember: (10.2.0 or later)を実装すればいいのかな？

/*
　　bitmapRepresentation 実装 patch@ロダ
　　bitmapRepresentationってunicharのベタバッファじゃないのか。よくわからないからNSStringを経由した。

　　application/src/v1/application/composer/CMRAttributedMessageComposer-Anchor.m
　 - (BOOL) makeResLinkAnchor: startingRange:withScanner:startCharacterSet:withAttribute:
// (ry
　　　　cset_ = [NSCharacterSet numberCharacterSet_JP];
　　から、NSCharacterSet characterSetWithBitmapRepresentation: で生成したNSCharacterSetを使って、
　　スレ内リンク化確認。
　　@OS X 10.4.10, G4
*/

Leopardでもドロワーってあるのかな？

>>443
さあ？Tigerのレファレンスには何も書いていない。
ドロワー使っていたアプリが使わなくなってるスクショは見た記憶あるんだけど、
何のアプリだったか忘れた。

＞何のアプリ
Preview.appだった。

>>442
少し調べたら、インスタンスのクラスが常に NSCFCharacterSet になるようです。
なんで、サブクラスでいくら文字判定系のメソッドを実装しても駄目っぽいです。

ひょっとすると Leopard で -init とかの挙動を意図的に変えてきたのかもしれませんが、
このように互換性を損なうわけなので、おそらく純粋に Cocoa 側のバグかと。

というわけで、強いて workaround するなら -init も実装? しかし [super init] しちゃ
いけないでしょうから、どうなんでしょう。実質独自クラス?

しかし、今、中の人的にどういう状況かわからないけど、もしもう GM モードに入っていると、
10.5 では駄目かも...

>>446
CFCharacterSet*() 使ってBitmapRepresentationをセットかなぁ。
当面は
>>441 ＞[NSCharacterSet decimalDigitCharacterSet] にしたらリンクは出ます。
で回避かな。

実環境ないままじゃ、はずれまくりｗ　リリースまでおとなしくしてるか。Sawtoothじゃ足切りくらいそうだけど。

>>447
＞CFCharacterSet*() 使ってBitmapRepresentationをセット　×
サブクラスを使わなくても
application/src/NG/construct/NSCharacterSet+CMXAdditions.m
@implementation NSCharacterSet(CMRCharacterSetAddition)
+ (NSCharacterSet *) numberCharacterSet_JP
内で
NSCharacterSet characterSetWithCharactersInString: か
NSCharacterSet characterSetWithBitmapRepresentation: が動いてくれればいいんで、訂正。

CMRNumberCharacterSet_JPインスタンスは使用せずにBitmapRepresentationをセットした
NSCharacterSetインスタンスを返すように変更。patch@ロダ
>>442は破棄。

>>448
素早い対応ありがとうございます。そっか、サブクラス化しなくてもいけますよね。
自分の環境だけな可能性もなくもないんですが、多分大丈夫(?)かと

いい加減GM待て&ここはdevかっていう話もあるんですが、乗りかけた船という
ことであと一点だけ。

次期OS候補上では、レスが化けるようです。
実際にはクッキーの確認のダイアログが出て、その中の「内容：」の部分が
化けていました（???になっていた）。

SG2chConnector.m の writeForm: の中で
selialized_ = [params_ dataUsingEncoding : NSASCIIStringEncoding
allowLossyConversion : YES];
となってますね。どうやらここっぽいです...
最終的には charset="x-sjis" な html で送信するんですよね?
（今まで上記コードで動いていたのは興味深いですが...）

ちなみに上記変数の名前は英語的には serialized_ 方がいいかもw

>>450
うひ、コードレビューで１番恥ずかしいツッコミだｗ

>>450
＞ [params_ dataUsingEncoding : NSASCIIStringEncoding allowLossyConversion : YES];
その時点でURLエンコードされているようです。

URLエンコード時に、
frameworks/SGFoundation/framework/source/extensions/string/String+Utils.m
stringByURLEncodingUsingEncoding:
[NSCharacterSet URLToBeEscapedCharacterSet]
(NSCharacterSetのサブクラス SGURLToBeEscapedCharacterSet)
を使って判定失敗。
NSStringがそのまま返ってきて送信されているってことかもしれないですね。

>>452
なーるほど、リンク表示の件で NSCharacterSet のサブクラスが死亡する
ことが判明したので辻褄が合いますね。

デバッガで追ってみたところ確かに SGURLToBeEscapedCharacterSet を使った
判定が失敗しているようです。
とりあえず、その部分をコメントアウトして常にエンコードするように
したら、化けなくなりました。
ちなみにエンコードの必要性を判定するのはパフォーマンス対策か何かですか?