[過去ログ] 2ちゃんねる専用ブラウザ開発者の皆さまへ ★5 (1001レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
197: 2014/09/15(月)11:48 ID:4EAYGkfP0(1) AAS
まあユーザーが使い慣れた専ブラを変更してくれれば思惑通り。
変更しなければ別のところが主流の可能性がある、ってところか。

この道筋をうまく用意ができるかどうかで成否決まりそう。
198
(1): 2014/09/15(月)13:41 ID:plypuxgq0(1) AAS
ところでこれは清算されたのかい?

$8 ツール開発者に行くはずが現在支払われてない様子。
$1 ツール開発者に行くはずが現在支払われてない様子。
199
(2): 2014/09/15(月)14:21 ID:nCAuPnb+0(2/11) AAS
>>177
3バイト以上だとそのまま扱えないの意味が分からん
200: 2014/09/15(月)14:37 ID:4Hn5hIVK0(2/6) AAS
>>199
UTf-8以外の文字コードは多くても2バイト。
なので1文字が2バイト以下であることを前提にした古いシステムでは不具合が起こる可能性有。
Windowsの半角全角という区別も半角=1バイト、全角=2バイト。3バイト以上は想定外。
201
(2): 2014/09/15(月)14:51 ID:nCAuPnb+0(3/11) AAS
???
ISO-2022-JPの時点でESC-$-Bとか入って1文字が何バイトとか意味をなしてないと思うんだが...
1文字が何バイト以下を前提にしていようとUTF-8であることを知らなければ文字化けするだけでは?
202
(1): 2014/09/15(月)15:17 ID:DSvwrPRd0(1) AAS
KI/KOが入るJISコードは内部でそのまま扱わないで変換するだろ。
WindowsにおけるUTF-8も同様の扱い。

>>177のは、Windows内部でUTF-8がまともに扱えないって言いたいんでしょ。
ただ単に文字列という名のバイト列を受け渡しするだけならそんなの関係ないんだけどね。
文字列操作とか文字の区切りを理解した操作をする必要がある時に困るだけで。
203: 2014/09/15(月)15:32 ID:rZ/tGyVx0(1) AAS
どうせシェア上位の開発者様のみによって決められるだけなんだから
無駄無駄

過去ログは無料で見られますからと
過去ログサイトも順調につぶして
浪人がないと過去ログは見られない仕様になりましたごめんなさいっ!
で浪人売った後で流出させたと思ったら
●の時と一緒で
浪人を売っていたのは2ch.netとは別会社ですから!
で終了
更にユーザーが減る
省1
204
(2): 2014/09/15(月)15:36 ID:nCAuPnb+0(4/11) AAS
>>202
1文字が2バイト以下の未知のコードとだと不具合がなくて
UTF-8だと「3バイト以上の文字が存在するため」ダメな理由を知りたいのだがね
205
(1): 2014/09/15(月)15:42 ID:4Hn5hIVK0(3/6) AAS
>>204
例えば、文字列バッファメモリを2バイト*文字数でとっているようなシステムだと不具合が起こる。
Mac OS Xなんかがその例。unicharというUTF16の文字1個を格納するための2バイトの文字型があって、文字列はその配列になってる。
unichar型は2バイトなのでUTF-8バイト列はそのまま入らない。iconvなどによる変換が必要
206
(1): 2014/09/15(月)15:53 ID:nCAuPnb+0(5/11) AAS
>>205
UTF-8を知らないのに文字数は分かり、それをわざわざunicharの配列に突っ込むケースが存在するのかいな
そもそもOSXでunicharの配列で文字列なんて扱わないよ
NSStringか、それをUTF8Stringメソッドで変換したバイト列のどちらかだよ
207
(1): 2014/09/15(月)16:05 ID:4Hn5hIVK0(4/6) AAS
>>206
NSStringの内部表現がunichar配列でUTF8Stringで得られるのがその配列そのものなんですが
208
(1): 2014/09/15(月)16:13 ID:nCAuPnb+0(6/11) AAS
>>207
いやいやいや
UTF8Stringで得られるのはUTF-8でエンコードされたバイト列だよ...
返り値はconst char *だからね const unichar *じゃないよ
209
(1): 2014/09/15(月)16:17 ID:4Hn5hIVK0(5/6) AAS
>>208
あ、間違えたわ
UTF8Stringで得られるのはUTF8バイト列。
unichar*が返されるのはgetCharacters:range:メソッドでした。
でも内部表現がunichar*なのは間違いないよ
とにかく、今時はプログラムで扱うのに可変バイト長のUTF8は不都合。
UTF16かUTF32の配列で扱っているのがほとんどだと思う。
バイト長が変わるUTF8とやりとりするのは、相性が悪い。
210: 2014/09/15(月)16:18 ID:CPd7ub/U0(2/2) AAS
unicharだかwcharだか知らないけど
UTF16にUTF8やUTF32突っ込めばおかしくなるのは当たり前だろ・・
211
(1): 2014/09/15(月)16:25 ID:nCAuPnb+0(7/11) AAS
getCharactersで得られるのはそもそも\0で終わっておらず文字列ではない
NSStringの内部表現は外に露出しておらず
stringWithUTF8String:でUTF-8のバイト列を直接NSStringに変換できるので不都合も何もない
212
(1): 2014/09/15(月)16:36 ID:4Hn5hIVK0(6/6) AAS
>>211
終端がヌル文字となるのを文字列とするのは、C言語の、しかもC++のstring型より以前の、char型=ASCII文字しか扱えない古い文字列処理系だけでの話。
Objective-CのNSStringはC言語のchar*文字列の拡張ではなく、C言語の文字列処理系に依存しない独自実装なのでヌル文字どうこうの指摘は無意味。
例えばPASCALの文字列はヌル文字入らない。余ったメモリはスペースで埋める実装。ヌル文字で終わってないと文字列じゃないなんてことはない。
213
(1): 2014/09/15(月)16:43 ID:nCAuPnb+0(8/11) AAS
>>212
いやだから、OSXでunicharの配列なんて使う機会がそもそも無いのよ
214
(1): 2014/09/15(月)18:25 ID:U3PKg0PM0(2/3) AAS
>>193
サービス自体がクローズドになったら元も子もないけど、
そこんところわかってなさそうな連中が今の運営だしなぁ…
>>198
精算するとしても「シェア上位の開発者様」(≒山下?)だけじゃねーかな
>>199>>204
C99でのMB_CUR_MAXが2な環境が有るんだよ…この場合mblen使ってても死ぬ。
>>201
次の文字が先行バイトかだけ見て2バイト文字しか処理しない奴が普通にいる。
そういう奴は当然シフトも考慮しないだろうからISO-2022-JPでも死ぬだろうね。
省2
215
(1): 2014/09/15(月)18:27 ID:D9dRTBGD0(1/2) AAS
UTF-8-MACとかだと半濁点のみの入力に対応できないだろ、実際は2文字でもそれを分けることが出来ない。
216
(2): 2014/09/15(月)18:30 ID:xmiLuA7v0(1) AAS
>>170
>>159は内部コードって言っているし、
>>150>>159>>161の流れだと思うんだがな。
開発環境における内部コードの話だと思ったんだけど、
内部コードってのは2chDATの文字コードの話だったのかな?

というかメモ帳でUnicode見れないの?
ちょっとそこが気になった。
1-
あと 785 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.015s