新しいアーカイバプラグインを開発するスレ

だね

期待保守age

副副(略)委員長のネタだったら面白いんだが。

ラジオなんて放送してる暇が有るならさっさと作っちゃいなさい

約束の２２日がちかづいてまいりました

さぁ営農ギコ氏今こそ漢を見せるときです。

残り9分

あと24時間待ってやる

ﾑｽｶ「時間だ！答えを聞こう！」

(´･ω･`)

営農ギコ「バルス！」

>>218
そうか？
これが固まってりゃかなり進んだと見れると俺は思うけど。
引継ぎも楽だしなー

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

つか22日に作業再開って言ってるだけで、何を出すって話ではないだろ
なにをそんなにがっついてるんだ？

いや本人から報告してもらわんと（･∀･）ﾆﾔﾆﾔ

22日キター

>>215
進んでるかい？

22日もあと30分なわけだが

復活してるじゃん。ホーム見て来なって。

はい、ご無沙汰しますた。いままで保守ってくれた方に感謝でつ。
これから約1ヶ月間開発期間がとれるので、できるところまで突っ走ります。

まず5月中にWikiの内容の充実とhikocrtをなんとかすべく。

ちなみに。上旬にWikiの内容が�dだ事件ですが、どうやらsf.netの全域で
ﾊﾟｰﾐｯｼｮﾝ全開とか管理者が居ないファイルが削除されてようで。まったくもぅ。

>>223
SYNさんの意見により、UTF-8でつ。
んでも、UCS-2への変換関数とかも用意できると思います。

>>228
今日は失敗してたんだって。

sf.jpで再構築してくらさい。.net嫌い。

>>244
期待してます
頑張って下さい

DGCAｽﾚでもお呼びがかかったし(；´Д｀)

>>245
その手もあるんだけど、sf.netの方と使い分けるのメンドイ(Unaceの方で経験済)

sf.netってMLとか謎の文字化けするし…

なんでデメリットばかりのUTF−8を無理に使おうとするのか理解できん。
まーアンチUCS-2で使いたくないってのが本音だろうな。

ところでHPDの仕様決まったの？

　　 ／￣￣￣￣￣ ミ
　 /　　 ,――――-ミ
　/　　／　 ／　　 ＼ |
　|　 /　　　,（･）　（･） |
　 (6　　　　　　 つ　　|
　 |　　　　　　＿＿_　 |　　 ／￣￣￣￣￣￣￣￣￣
　 | 　　　　 /＿＿/ ／　 ＜　 時間かかるよ！
／|　　　　　　　　 ／＼　　 ＼＿＿＿＿＿＿＿＿＿

>>249
どのあたりがデメリット？
ASCII7bit文字がそのまま使えるメリットは凄く大きいよ。
世界を相手にするならUTF-8がいい。

日本語しかねーのに

UTF-8でいいんじゃない？

cabとか7zとかまで考えるならUTF-8は必須だろう
XPあたりからUTF16だからWCHARのメリット無いし

>>255
Unicodeは処理中はUCS-2(UTF-16)、保存時はUTF-8というのが基本では？

>>256
処理も保存もUTF-8がいいよ。
UTF-16にはUTF-8に対するアドバンテージは一切無い。
サロゲートペアが出てきた時点でUCS2のメリットは死んだ。

>>252
UTF-8じゃそのまま処理する事は出来ないから変換しなきゃならない。
ASCII7bit文字がそのまま使えるメリットなんて絶対7bit文字しか使わないってところでしか意味無い。
ほかの文字が少しでも使われる可能性があるなら結局その事を考えた仕様にしなければならない。
絶対7bit文字しか使わないってところなんて世界中捜してもあるか？
英語圏だって結構ASCII以外の文字使うこと多いぞ。

>>258
違う。
UTF-8のメリットは、7bit文字もそれ以外のunicode文字も表現できながら、
7bit文字がそのまま使えるということ。SJISが成功したのと同じなんだよ。これは。

>>259
だからそのまま使えたとこで意味が無いといってんの。
そりゃ、保存の時は都合が良いかもしれないがそんなの関係ない。

>>259
じゃあSJISでいいじゃん。

>>260
意味が無いと思っているだけだろ？
既に日本や欧州や米国でUTF-8を使っている奴がたくさんいるのは、
メリットがあることの証明だよ。
そいつらは何らかのメリットがあって使っているのは確実だし、
そういう奴らと仕事するにもUTF-8はメリットがある。

>>261
UTF-8採用している書庫形式もあるんだからSJISだと困るでしょ

>>261
SJISでは表現できる文字が少ないし、全言語の文字を同時表示することを考えると、
unicode系でないと話にならない。

実際にすべての文字を格納することを考えると、UCS4かUTF8しかない。

>>265
「将来拡張されても」が抜けていた。念のため。

結局、どういう話し合いだったのですか？

激安ソフト！！

ご提供するソフトは
　Illustrator10 : Photoshop7 :FLASH MX：Painter6.0j
で一本五千円でご提供します！！

新規インストール版のCDとシリアルナンバーのみお渡しします。
その他箱、説明書等の付属品はありません。登録はできません｡
細かいことは気にせず使えれば良いという方､安く手に入れたい
という方や学生さんにお勧めです｡

購入を希望される方は

[email protected]

までをメールください。
まっております。

>>262
だから保存の時と処理の時をいっしょにしないでよ。
で、内部処理でUTF-8を使ってる奴がたくさんいるってのはどこで調べたの？
そんなにたくさん人のソース見て回ったの?
俺も勉強の為に山ほど見てきたがUTF-8使って何か処理するたびにUCS2なりSJISに変換してる奴は見たこと無い。
逆にUCS2なりSJISで処理してUTF-8で書き出すってものなら見かけるが。

処理の時にASCII7bit文字しか使わないことが前提のソフトなんて只のバグ持ちだ。
だからそんなものは意味が無いといってるの。
UTF-8自体が意味のないものだとは言っていない。

あと将来拡張云々言ってるけどそんときゃ今のWiindowsもその他OSも大きな仕様変更されてるし
どの道その時にはプラグインも調整しなくちゃならないだろうよ。

じゃあ文字セットは UCS-4 でエンコードは UTF-8 でいいんじゃないの。

なーんか理想ばっかり追っかけて結局何もできなそうだな。
頭でっかちのプログラミングヲタにありがちな結末(w

>>271
理想を追わないなら統合アーカイバで十分じゃないか

>>271
理想を追い求めてスレを消費しているのは、その他の一般人だろ？

>>271
てかここでやり合ってるのは部外者同士だから

理想を追いかけるにはそれ相応の実力が必要。
>>247 にはそれがあるかは微妙なところ。

動かない実力者より、動く未熟者を応援したいな、俺は。

他人の足を引っ張る事しかできんヘタレがいるな。

鹿毛ながら応援しとります｛´・ω・｀｝ｶﾞﾝﾊﾞｯﾃ

>>269
SJISで処理しているのなんて、世界的に見れば無いに等しい。
分かっている人間のコードや、新規格にはUTF8ベースが多い。javaもUTF8だ。
マルチプラットフォームを考えるなら間違いなくUTF8にアドバンテージがある。
さらに、wchar系のエンコードには根本的な問題がある。
それは、文字列の任意の一部のバイト列を正しく解釈できないという問題。
データの破壊に弱く、ビュアは非常に作りにくいが、これがUTF8なら全く起こらない。

まぁ、ここでも読んどけ。
http://homepage1.nifty.com/nomenclator/unicode/ucs_utf.htm

特に、
>UTF-16では，UCS-4のU+110000以降の文字を表現することができません。
とかの問題もな。

UTF-8を使うからには、全てのDLL及び対応アプリはUCS-4のU+110000以降の文字に対応して、
そうじゃないDLLやアプリは（ベータ版とかの限定的な扱いだとしても）絶対に出ないってこと？

>>280
UTF-16 じゃない(XPのNTFSとかで扱えない)文字が扱えると、
それはそれで混乱のもとになる気がしなくも無いが。

>>279
Java が UTF-8 ってのは何処の事を差して言ってるんだ？

まぁ決定権は作る人間にあると思うので UTF-8 でやれば良いと思うけど。

そもそもWin専用じゃないんだからUTF-16を選ぶメリットはまったく無い

>>279
＞SJISで処理しているのなんて、世界的に見れば無いに等しい。
相変わらず分かってないなぁ、ここは日本だぞ？
だから例でSJISの名前出しただけであって世界中でSJIS使われてるだなんて事いってる訳じゃないんだが。
韓国行けば韓国の文字コード、中国なら中国、ロシアならロシア、それぞれの文字コード使ってるだろうよ。

＞分かっている人間のコードや
誰よ？具体例あげてソースの場所教えてくれ。

＞新規格にはUTF8ベースが多い
新規格の言語がどうだろうがこれはCだぞ。関係ない。
WindowsAPIがそのままUTF-8を扱えるのであればそれで良いだろうがそうじゃない。

＞それは、文字列の任意の一部のバイト列を正しく解釈できないという問題。
安心しろ、UCS-2のWiindowsも同じ問題を抱えている。
いくらプラグインのほうが対応してようがWindowｓの方でこけるだろうよ。
そもそも、UCS-4のU+110000以降の文字なんて今のWindowsで扱えないだろう。
将来、対応した時のため?その時そのプラグインも手を加えなくちゃ使えないだろうっての。
素直にUCS-2使っておいて、変更された時にプラグインのほうも調整すればいい。

>>285
メリットが無かろうが無理に扱いづらいUTF-8を使う必要も無い。

>>287
目標はクロスプラットフォーム(Win32,Linux,MacOS X,etc...) なんだってば

Linux,MacOS X,etc...がUTF-8に対応してるとは知らなかったよ。

結局UTF-8とUTF-16ってどっちの方がたくさんの文字表せるの？

>>290
UTF-8

けどども道使えないから一緒

ドモドウ？

>>292
確かに現時点ではFSの方が対応していなかったりするけど
だからといってUTF-16を選ぶ意味は無い
WinNT系で変換がいらないからといってそれが大きなアドバンテージにはなりえない

トモゾウ

>>291
つことはUTF-16はもう使えない？

>>294
だからといってUTF-16を選ぶ意味は無いというなら
同じくUTF-8を選ぶ意味も無い。

何を根拠に大きなアドバンテージにはなりえないといってるのか分からないが
少なくともアドバンテージが存在するということは認めるんですね。
だったらそんなものを使う必要も無い。

サルでも分かる説明。

対応アプリが"C:\ほげほげ.txt"を圧縮しようとする時
UNICODEを定義してプログラムを書いていている場合。

プラグインがUCS2の時
wchar lpszFileName[MAX_PATH];
::lstrcpy(lpszFileName, L"C:\ほげほげ.txt");
hc_add(lpszFileName, option); // 以降プラグイン内部でもlpszFileNameはそのまま使用することが可能。

UTF8の時
wchar lpszFileName[MAX_PATH];
::lstrcpy(lpszFileName, L"C:\ほげほげ.txt");
DWORD dwLen = ::WideCharToMultiByte(CP_UTF8, 0, lpszFileName, -1, NULL, 0, NULL, NULL);
char* lpszU8FileName = malloc(dwLen + 1);
::WideCharToMultiByte(CP_UTF8, 0, lpszFileName, -1,lpszU8FileName, dwLen + 1, NULL, NULL);
hc_add(lpszU8FileName, option);　// プラグイン内部でAPIを使う際はwcharに戻す必要がある。
frre(lpszU8FileName);

仮に文字コード変換のマクロを定義しても見た目が多少良くなるだけでやってることに変わりは無い。
さてどちらがスマートか。どちらがバグを生む可能性が低いだろうか。
これはプラグイン作者が書くコードではなく利用者が書くコードだということを忘れずに。

あ、どうでも良い事だが\\としなくちゃならんかったな

WinNT系専用ならそれでもいいんだがね

>>300
だからさ、これはプラグインのコードじゃないって言ってるでしょうが。

>>301
インターフェースの問題なら利用者がラッパでも書けば良いだろ

>>302
インターフェイスとかそんな問題じゃない。
どれだけ利用しやすいかだ。
で、インターフェイスの問題というのが何かわからないが利用者にラッパまで書かせるきですか。
とことん使いにくくなっていくな。

>>289
http://www.apple.co.jp/macosx/technologies/darwin.html
http://www.zdnet.co.jp/help/tips/linux/l0672.html
http://www.olug.gr.jp/~hhide/OIA/19980704/beos.html
http://jp.sun.com/products/software/solaris/fcc/ucc-details1000.html
http://www-online.kek.jp/~keibun/javaprog/unicode.html

>>298
プラグインがUTF-8のとき
　int main( int argc, char* argv[] ) {
　　hc_add( "MyArchive", argv[1] );
　}
UCS2のとき
　int main( int argc, char* argv[] ) {
　　size_t len1 = strlen(argv[2])+1, len2 = len1*2;
　　char* buf = (char*)malloc( len2 ), name=buf;
　　iconv( iconv_open("UCS2", "UTF-8"), &argv[1], &len1, &buf, &len2 );
　　hc_add( "M\0y\0A\0r\0c\0h\0i\0v\0e\0\0", name );
　　free( name );
}

>>304
UTF-8の方の引数にASCII以外の文字列が来た時が考慮されてない｡
0点｡

あと、VC++限定なら_wmainもあるのだが｡