[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/22 16:06 / Filesize : 183 KB / Number-of Response : 805
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

UnicodeとUTF-8の違いは? その2



1 名前:デフォルトの名無しさん [2010/11/30(火) 09:00:05 ]
富士通だとデフォルトでは生成されない
frt -c -Am -M./ (なんとか.f90)
でいけるのではなかろうか。いずれにせよ、
frt -help | less
とかやって、"module"で検索を掛けるのが吉。


232 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 03:52:20.12 ]
Windowsでサロゲートペアのファイル名がZIP圧縮出来ないんだけど、なんとかならんの?
今時シフトJISしか扱えないなんて糞過ぎる。
スマホ上で作ったUTF-8ファイル名のZIP持ってくると文字化けしまくる。
ファイル名にBOM付けてもいいからマジ何とかしてほしい

233 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 05:03:45.92 ]
コントロールパネル
 →個人設定
  →システムロケールの変更
   →再起動

234 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 05:33:52.76 ]
ZIPそのものが古代の遺物。7-Zipにすればよろしい。




235 名前:デフォルトの名無しさん mailto:sage [2011/07/03(日) 14:42:31.19 ]
>>232
お前が使ってる糞解凍ツールを見直すべきかと

236 名前:デフォルトの名無しさん mailto:sage [2011/07/09(土) 13:45:03.50 ]
Unicodeの文字に言語情報ってある? 日本語かどうか判断したいんだけど。
JIS2004は日本語と判断したい

237 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 04:31:44.19 ]
>>236
そんなものは無いし、JIS2004をそのまま含んでいる訳ではないので不可能。

JIS2004に追加された文字でUNICODEに無かった分をUNICODE3.1や3.2でUNICODEに追加した分というのなら調べればわかる。

238 名前:デフォルトの名無しさん [2011/07/10(日) 17:04:21.42 ]
極端な話アルファベットで日本語の文章を書くことも出来るわけで、
言語とスクリプトは別というのはわりと基礎知識。


239 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 19:43:44.83 ]
そんな極論聞いてるわけじゃないんだよねえ

240 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 20:40:34.17 ]
極論じゃないでしょ。
>>236の言う「日本語かどうか」がどういう意味かによって、
やり方が全然変わってくるんだから。
JISで登録されてる文字集合に含まれてるかどうかでいいってのなら、
テーブル見れば済む。
けどそんなこと質問するかね。



241 名前:デフォルトの名無しさん mailto:sage [2011/07/10(日) 21:22:02.68 ]
>>240
Unicodeの文字集合はUnifiedだから、一つの文字が複数の言語に
対応するのは>>236もわかってるでしょ。>>236
 「A」: 英語,日本語
 「百」: 日本語,中国語
 「あ」: 日本語
みたいなテーブルが欲しかったんでしょ。そんなものは無い。

>>240
>テーブル見れば済む
どこかに正式なものが公開されてる?
無保証でいいなら x0213.org/codetable/sjis-0213-2004-std.txt とかあるけど

242 名前:デフォルトの名無しさん mailto:sage [2011/07/11(月) 13:36:38.84 ]
>>218
超一般論として、説明してもわからない
我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ

エラーが出るテストを作ってそれをつき突けろ
最終的にはそれしかない
「よくわからんがこのテストが通ってるんだからあちらでも問題はないんだろう」というものを作ってさしあげろ

243 名前:デフォルトの名無しさん mailto:sage [2011/07/11(月) 19:57:07.03 ]
一塊の文章としてなら、IMultiLanguageで文字コードを推定することはできるはずだぜ?

244 名前:デフォルトの名無しさん mailto:sage [2011/07/12(火) 08:47:17.73 ]
>>242
>我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ

ぶっちゃけこの業界はコミュ障が多いから
そこまで他人の立場に立って理解出来る香具師は少ない

245 名前:デフォルトの名無しさん mailto:sage [2011/07/12(火) 16:41:00.55 ]
つーか、駄目なコードの例と正しいコードの例を提示すればいいだけなんじゃねーの?

246 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 00:29:31.56 ]
流れを断ち切って申し訳ないが、
UTF-8がバイトオーダーの影響を受けてLE,BEに分かれないのはどうして?
いや、UTF-16だけが特殊なのか?
CPUがメモリ上の複数バイトを読み書きする際の配置の都合からLE,BEがあるのなら、
UTF-8だってASCII文字以外は複数バイトでしょ?

247 名前: 忍法帖【Lv=24,xxxPT】 mailto:sage [2011/07/14(木) 00:58:37.24 ]
UTF-8は1バイトずつ読み書きする。


248 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 01:17:06.25 ]
>>246
1文字(16bit整数値1つ)を、どういうバイト列に変換するかの問題。
UTF-16LEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 42 30
UTF-16BEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 30 42
UTF-8は、UCSの1文字を1-4byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → e3 81 82

2byteの整数をサイズ2のバイト列に変換する方法は、簡単で合理的な2種類ある(BE,LE)ので、
どちらを使えばいいか迷ってしまい、みんなで混乱する。
一方、2byteの整数をサイズ1〜3のバイト列に変換する方法は、それほど自明ではないので、
誰かが「UTF-8」としての変換ルールを決めた。そしてみんながそれに従った。現状、それがうまくいっている。

仮に、「UTF-8なんとか」というUTF-8に似て非なるルールが乱立するなら、UTF-16のLE/BEの混乱と
近いことが起こるかもしれないけど、たまたま現実はそうなっていない。

249 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 07:28:59.02 ]
MIME64と一緒か

250 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 08:26:50.94 ]
>>246
UTF-8はエンコーディングフォームが1オクテット単位だから、
UTF-8エンコーディングスキームはバイトオーダーに依存しない。

UTF-16とUTF-32エンコーディングフォームが2/4オクテット単位だから、
エンコーディングスキームが複数必要となった。



251 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 19:26:49.50 ]
LEとかBEとか分けないで、どちらかに統一すればいいのに。

252 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 20:23:18.94 ]
できなかったからこうなってるんだろ

253 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 21:58:52.88 ]
UTF-16/32は内部表現として採用されることが多い。
だからバイトオーダーの問題が出てくる。

UTF-8はそんまんま垂れ流すのでなければ、
内部表現としてのUTF-16/32と併用されることが多く、
その場合decodeがいずれにせよ必要となるので、
バイトオーダーと逆順になっていても大した手間じゃない。



254 名前:デフォルトの名無しさん mailto:sage [2011/07/14(木) 22:48:24.40 ]
LEとBEは、規格上で相互運用とかをあんまり考えなかった結果…ではある
どっちかに我慢してもらって無理してでもどっちかに決めてしまえばよかった
本当はね
LEでもBEでもどちらでももちろん構わないというのは、うんざりするほど正当で当たり前だが、うんざりだ

255 名前:246 mailto:sage [2011/07/15(金) 07:20:47.59 ]
レスthxです。
おかげさまでずっと疑問だったのが解消しました。
CPUの都合を考慮して2種類規格化してくれただけなんですね。
>>253
これは少し考えていました。
画像ファイルに例えるならばUTF-8=JPEG,UTF-16=BMPで、
JPEGはメモリ上にBMP形式で展開&編集され、最終的にJPEGで再保存される。
JPEG(UTF-8)がデータ交換用としての相互運用性を重視される一方、
BMP(UTF-16)はメモリ上での編集のし易さが重視される。
UTF-16においては、それはLE,BEの許容にあたる。
という認識です。

しかし内部形式って意識されるべきですか?
恥ずかしながらVB以降の言語しか分かりませんが、
通常charの型変換には符号化方式の指定が必要なので気にしたことがありません。
(short)charをファイルにシリアル化するような事があったとしても、
これはテキストと見せかけてバイナリファイルですと言い張るかも。

C言語なんかだと意識するんですか?
UNICODEをAPIで扱うならば内部的にはポインタ/byte[]で持つんですよね?
だとしたら意識しないといけないのかな?

あ、JAVAでもif('A'<=VALUE || VALUE <= 'Z')と書けるのはUTF-16BEだからですか!
無意識に書いてましたorz

256 名前: 忍法帖【Lv=25,xxxPT】 mailto:sage [2011/07/15(金) 07:47:31.64 ]
画像に擬える辺り、根本から判ってない悪寒。

257 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 07:59:23.90 ]
低レベルの挙動を考えたら、LEとBEは両方必要だろと普通に思うがな

258 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 08:02:47.23 ]
ネットワークバイトオーダーっつうもんがあるように、
交換形式はどっちかにしちまえよ、って思ったことはある。

259 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 08:59:25.19 ]
>>258
それは実質UTF-8だな
UTF16/32のままネットワークを流れることはあまりない

260 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 14:23:43.37 ]
>>258
大量のテキストを処理したい時に、
内部表現と同じテキスト形式が存在しないのは不便。
実行環境の内部形式に依存しても、軽快に扱いたい局面はある。
たとえばテキストデータベースの二次記憶保存など。

ネットワークバイトオーダーについては、
TCP/IPのヘッダー部はデータ量が少ないし、
最近はハードウェア評価だからオーバーヘッドにはならない。
それにデータ交換についてはプロトコル毎に決めればいい。



261 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 21:33:02.35 ]
>>255
>しかし内部形式って意識されるべきですか?
意識する必要は無いし、UTF-16フォームにLEとBEの区別は無い。
ただし外部形式であるUTF-16スキームにはLEとBE区別が当然ある。

262 名前:デフォルトの名無しさん mailto:sage [2011/07/15(金) 23:55:08.88 ]
>>255
せめてPNGにしとけ。それなら話が通じる

263 名前:デフォルトの名無しさん [2011/07/16(土) 11:30:38.92 ]
ヒント:
Unicode = UTF-16
UTF-8 = UTF-8


もともと、Unicodeに準拠した文字コードはUTF-16しかなかったから
文字コードはUnicodeという記述をするとUTF-16をさす

その後、UTF-8というものが増えた為、
それと差別をするために、UTF-16という言葉が発生しました

なので今となっては
Unicodeは文字一覧を指し、
UTF-16/UTF-8は文字コードの種類を指す
という意味が正しいのだが、昔の事情があったため、
文字コードUTF-16をUnicodeという言い方をする場合がある

264 名前:デフォルトの名無しさん mailto:sage [2011/07/16(土) 11:37:43.86 ]
ドヤ顔でそんな事言われても

265 名前:デフォルトの名無しさん mailto:sage [2011/07/16(土) 12:16:52.83 ]
しかしエンコーディングをUnicodeって言うのはやめてほしい
昔はそうだったのかもしれないけど、気持ち悪くて

266 名前:デフォルトの名無しさん mailto:sage [2011/07/16(土) 12:37:51.74 ]
UCS-2ですよ。Unicodeって言われた時代はありません。

267 名前:デフォルトの名無しさん mailto:sage [2011/07/16(土) 20:26:19.26 ]
>>263
> 文字一覧

文字セットの方が好き

268 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 16:28:44.12 ]
マクのSJIS-Unicode変換ルールを知りたいのですが、
どこかに公開されていないでしょうか。
特にNEC特殊文字やIBM拡張文字(「@」(U+2460)など)がどうなるか知りたいです。

269 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 16:53:25.93 ]
どうもならんよ

270 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 17:13:37.77 ]
数多いShift_JISベンダー拡張の「MacJapanese」からのなら
unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
にあるけど、今もこの変換通りなのか不明。
Microsoft拡張のCP932との関係も少しだけコメントが書いてある。




271 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 17:14:29.89 ]
どうにもならない、というのは、
U+2460をシフトジスに変換すると24 60の2バイトになるということかな?

272 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 17:15:05.68 ]
これを挙げ忘れた。
unicode.org/Public/MAPPINGS/VENDORS/APPLE/Readme.txt

273 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 19:22:02.19 ]
>>270
>今もこの変換通りなのか不明
今も昔もこのルールか実装されたためしなんて無い。
|0x5C 0x00A5 # YEN SIGN

274 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 20:23:16.02 ]
>>273
Character ViewerからShift-JIS(X0208)指定して005Cダブルクリックで入力すると
アプリ側にはU+00A5が渡るけど
CoreFoundationで変換してもU+00A5になる。

275 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 21:07:44.60 ]
>>268
MacはもうShift_JISは使ってないよ。
UnicodeとShift_JISの変換は当然できるけど、動作はAPIに対するパラメータ次第。
例えばU+2460に対しては古いMacJapaneseを指示すれば0x8540が返るし、X0208を
指示すると変換できずエラー、X0213を指示すると0x8740が返る。
端的に言うとパラメータで指示した規格に沿った値に変換される。

276 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 22:33:23.51 ]
シフトJISを規定の文字コードとするアプリケーションは、Mac OS Xには無いそうです。
JDK 6とかな。

277 名前:デフォルトの名無しさん mailto:sage [2011/07/17(日) 23:13:50.55 ]
Shift_JISX0213のエンコーディングを実装してるなんて、マッコステンて無駄にすげーな。
シフトジスの84 BF(丸付き21)をUTF-16に変換すると27D0になったり、
シフトジスのFCA3をUTF-16に変換するとD867 DFCEになっちゃうわけ

278 名前:デフォルトの名無しさん [2011/07/18(月) 21:57:13.75 ]
Windowsも正確には MS932(CP932やWIN31Jとも言うが)なんだけどな

279 名前:デフォルトの名無しさん mailto:sage [2011/07/18(月) 23:46:46.27 ]
そんな偉そうにIANAに登録されていない名前を列挙されても

280 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 01:26:36.91 ]
ドヤ顔でズレたこと言ってるのはお前じゃねーの
>>278はshift_jsと違うってことが言いたいんだろ



281 名前:デフォルトの名無しさん [2011/07/19(火) 02:20:03.27 ]
まぁ、ちゃんとした名前で言っておけばつっこまれなかったかもしれんぞ。
Windows-31J な。
www.iana.org/assignments/character-sets


282 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 03:23:11.11 ]
WIN31J「とは言わない」からな
その時点でいろいろ知れる

283 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 06:06:29.06 ]
>>280
node.jsの親戚かと。

284 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 10:14:52.68 ]
>>278
MS932とはあまり言わないだろう、Microsoftの「Code Page 932」って規格だから略称としては「CP932」が適切

285 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 10:39:36.67 ]
>>284
MS932はJava語で、おおむね、Windows-31Jを指すはず(IBM版CP932とは違う)
Javaが独自分類表現を使用しているなんて夢にも思わない人がJavaの外に持ち出して恥をかくことがある

286 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 11:26:26.69 ]
よくこんな細かいことで争えるなあ・ω・

287 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 11:39:43.38 ]
別に細かくはない
ギョウザを頼んだらシュウマイが出てきた、くらいには違う

288 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 11:44:54.65 ]
Wikipediaが正しいかわからないけど、色々な経緯が載ってる

ja.wikipedia.org/wiki/Microsoft%e3%82%b3%e3%83%bc%e3%83%89%e3%83%9a%e3%83%bc%e3%82%b8932

289 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 14:43:58.56 ]
CP932はLLのコード指定なんかでも良く使われる名前だし、突っ込むほどでもないと思うがな

290 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 15:44:26.12 ]
>>289
CP932は問題になってはいない
っていうかお前>>278だろ



291 名前:デフォルトの名無しさん mailto:sage [2011/07/19(火) 23:27:12.20 ]
Windows-31J はJavaのJSPだっけ?でしか
聞いたことがない。

292 名前:デフォルトの名無しさん mailto:sage [2011/07/21(木) 23:17:57.44 ]
日本語版Windowsのメモ帳の文字コードがWindows-31Jなのは
間違いないし、Shift_JISでないのも確かだが、
「シフトジスではない」と言われるとそれは違うだろう。
どう考えてもWindows-31Jはシフトジス。

293 名前:デフォルトの名無しさん mailto:sage [2011/07/21(木) 23:33:26.32 ]
>>288
|マイクロソフト及び、MS-DOS の OEM ベンダが Shift JIS を独自に拡張した文字コードである。
でたらめな説明だな。

もともとアスキーマイクロソフトが考えた文字コードが「シフトJIS」と呼ばれ、
正確な定義はどこにも無かった。
1997年にJISが「Shift_JIS」を定め、それは世の中にあるシフトJISの
共通部分であるX 0201,X 0208のみを対象としたものだった。

だからShift_JISもWindows-31JもシフトJISの一種でしか無い。
拡張なんて嘘がどこからでてきたんだ。

294 名前:デフォルトの名無しさん mailto:sage [2011/07/21(木) 23:55:46.23 ]
文中では「Shift JIS」で、
wikipedia項目に飛ぶと「Shift_JIS」になってるな。無茶だなw

Windows-31Jは、初期の「Shift JIS」からは文字が足されて拡張されているけど、
その飛び先が「Shift_JIS」ではな。
「Shift_JIS」の項目内で「Shift JIS」と「Shift_JIS」の使い分けが甘い。

295 名前:デフォルトの名無しさん mailto:sage [2011/07/22(金) 02:15:49.92 ]
>>294

Wikipedia のリンク名には制約があって、「_」と「 」が区別できない。


296 名前:デフォルトの名無しさん mailto:sage [2011/07/22(金) 02:17:52.27 ]
リンク名というか記事名だな
他にも記事名に使えない記号ってあるのよね

297 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 09:13:21.14 ]
Wikipedia のタイトルの制約には昔から悩まされてる。

1. アンダースコアが空白になる
2. ふたつ以上の空白がひとつにまとめられる
3. 先頭と最後の空白が除去される
4. [ ] { } < > | # が使えない
5. : が特殊な意味を持つことがあり、たとえば「:」からはじまるタイトルが作れない
6. 先頭の1文字が大文字になる
7. 長さ制限(UTF-8 で 255バイト以内)がある

リンクするときにはさらに複雑な制約がかかる。


298 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 10:12:07.29 ]
文字コードの話じゃないけど、入力文字に複雑な制限があるのは
エスケープ前と後の区別がつけられないできの悪いエンジニアが
作ったんだろうな。そういう人たちがSQLインジェクションとか起こす。

299 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 10:46:25.58 ]
記事名がURLになる、というのは便利なんだがそういう弊害もあるよな。
逆にハッシュ値のような長いURLは不便だし、シリアルナンバーも微妙。

MediaWikiって内部的に持ってる記事名も空白が _ になってたりして、
そのへんの設計も微妙だな。

300 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 12:35:06.53 ]
スレ違い



301 名前:デフォルトの名無しさん [2011/07/23(土) 13:06:04.48 ]
Not スレ違い

ja.wikipedia.org/wiki/~
ja.wikipedia.org/wiki/%EF%A8%99
ja.wikipedia.org/wiki/%E7%A5%9E


302 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 17:00:46.82 ]
記事名の問題だけじゃなくShift JISの記事は内容がおかしいな。


303 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 19:16:54.74 ]
そういう時は君が修正すれば良い。

誰でも修正できるのだから、それをせずに
間違っていると言ったところで信用されない。

言う前に直してから、直したよと報告すればいい。

304 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 19:50:47.55 ]
>そういう時は君が修正すれば良い。
これはそうなんだが

>誰でも修正できるのだから、それをせずに
>間違っていると言ったところで信用されない。
こういうことを言う奴って頭おかしいんじゃないかと思う。
ただ間違ってるものを見たときに間違ってると言ってはいけないだろうか。

305 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:02:27.38 ]
好きにすればいいんじゃねーの?
俺は>>304みたいのを見ると頭おかしい人なんだなと思うけど
言いたいこと言うのはいいことだと思うようん

306 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:12:44.57 ]
>>304
お前は間違っている。


間違っているものを見たので
つい言ってしまったw

307 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:28:03.23 ]
A: ○△に〜って書いてあったよ
B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの

>>304はともかく、>>303が変なのは確定的に明らか

308 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:32:53.91 ]
A: ○△に〜って書いてあったよ
B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの
A: ○△は誰でも修正できるものだから。


309 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:41:10.14 ]
「誰でも修正できる」がなんで「見つけた人は修正する義務がある」にすり替わるよ。
頭だいじょうぶ?

310 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 21:44:07.47 ]
誰が義務があるって言ったんだ?



311 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 22:19:21.22 ]
おまえら楽しそうだな。

312 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 22:44:52.69 ]
仲良くしてね

313 名前:デフォルトの名無しさん mailto:sage [2011/07/23(土) 23:11:11.98 ]
とりあえずシフトジスって書かれたときは99%はWindows-31Jのことだから、
Windows-31Jって書いておけば問題ない。

314 名前:デフォルトの名無しさん mailto:sage [2011/07/24(日) 10:08:13.04 ]
Windows-31JはJava用語で一般的ではないから
他では通じない。CP932と言ったほうがいい。

315 名前:デフォルトの名無しさん mailto:sage [2011/07/24(日) 10:26:45.92 ]
>>314
2点
レス欲しいなら狂人の真似を

316 名前:デフォルトの名無しさん mailto:sage [2011/07/24(日) 11:58:46.32 ]
いや事実を言っただけなんだが。

317 名前:デフォルトの名無しさん mailto:sage [2011/07/24(日) 12:50:28.09 ]
「Windows-31J」はIANAに登録された一般的な名前で、Java固有ではない。
HTTPのContent-Typeにも(条件付きではあるが)正式に使用できる名前。

なお.NET FrameworkのEncoding.GetEncodingは、文字コード名をパラメーターに
取るのではなくWindowsコードページ名を受け取るので、Windows-31Jは指定できない。

318 名前:デフォルトの名無しさん mailto:sage [2011/07/24(日) 17:21:27.70 ]
>>317
GetEncodingは.NETのウニコード文字をローカルに
変換するルールでしょ
IANAが決めているのは文字コードであって、
ユニコードとの変換ルールでないんだから当然

319 名前:デフォルトの名無しさん [2011/07/24(日) 20:34:52.28 ]
>>315
861 :デフォルトの名無しさん:2011/01/04(火) 20:39:59
SJISはウンコ、CP932はウンチ

320 名前:デフォルトの名無しさん mailto:sage [2011/07/25(月) 11:13:51.23 ]
IANAのcharset名、Windows関連は
"Windows-コードページ番号"で統一できたらよかったのにな。




321 名前:デフォルトの名無しさん mailto:sage [2011/07/25(月) 15:50:16.53 ]
Wikipediaなんて間違いだらけなのは、まともな技術屋ならしょっちゅう見て理解してるだろ…
内輪ルールがめんどくさすぎて修正しねーことも多いわ
一応、楽に修正できそうな範囲ならするけどな

322 名前:デフォルトの名無しさん mailto:sage [2011/07/25(月) 18:40:44.97 ]
間違いっていうか意図的な捏造もかなりあるぞ
特に反日歴史関連は酷い


323 名前:デフォルトの名無しさん mailto:sage [2011/07/25(月) 18:53:37.20 ]
ウヨ脳乙

324 名前:デフォルトの名無しさん mailto:sage [2011/07/25(月) 22:23:54.09 ]
えっ

325 名前:デフォルトの名無しさん mailto:sage [2011/07/26(火) 18:33:59.96 ]
要するに>>278の言いたい「正確」ってのが何だったのかが分からんということだな

326 名前:278 [2011/07/27(水) 01:27:57.83 ]
拡張漢字(NEC選定IBM拡張・IBM選定IBM拡張・NEC特殊文字)を含む場合は
MS932かCP932あるいはWindows-31J
が正しい
Shift_JISに拡張文字は無い

なので、
「MS932かCP932あるいはWindows-31J」>「Shift_JIS」
なのだろう

それが正確

327 名前:デフォルトの名無しさん mailto:sage [2011/07/27(水) 08:04:57.93 ]
正式名称と通称は区別してよ。

シフトジス
 ├Windows-31J(X 0201,X 0208,NE特殊,NEC選定IBM拡張,IBM拡張)→通称MS932,CP932
 └Shift_JIS(X 0201,X 0208)

328 名前:デフォルトの名無しさん mailto:sage [2011/07/27(水) 10:09:52.09 ]
文字エンコーディング・文字コードは技術ではなく(おそらくは残念なことに)ただの政治なので、
ちょろっと読んだ人がしたり顔できるほど相関関係は単純ではない

329 名前:デフォルトの名無しさん mailto:sage [2011/07/27(水) 11:56:11.29 ]
CP932はMicrosoft的には正式名称でしょ。

330 名前:デフォルトの名無しさん mailto:sage [2011/07/27(水) 20:47:15.11 ]
>>329
コードページの932番というのは正式な番号だけど、
「CP932」という名前はちょっと違うんじゃね



331 名前:デフォルトの名無しさん mailto:sage [2011/07/27(水) 23:11:17.71 ]
microsoft.comの公式文書でcp932と表現してる所がある。

332 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 04:13:07.78 ]
cp65001

333 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 13:21:19.41 ]
IANAだけ正式だと思ってるのは勘違いだわな

334 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 22:52:57.57 ]
ソースが出てこないから突っ込まれるんだよ。
MSの文書で文字コード名cp932が定義されているソース出してみろや。
コードページの932番じゃなくて「cp932」な

335 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 23:41:20.22 ]
後付けくさい理由で絡んでるようにしか見えないが

336 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 23:41:29.23 ]
ぐぐれ
social.msdn.microsoft.com/search/ja-JP?query=cp932

337 名前:デフォルトの名無しさん mailto:sage [2011/07/28(木) 23:48:40.52 ]
socialはちょっと…
msdn本家ページにもあるよ。

338 名前:デフォルトの名無しさん mailto:sage [2011/07/29(金) 16:00:03.50 ]
今度は「使っているというだけでは正式な定義ではない」とか絡んでくるんじゃねーの
ぶっちゃけ心底どうでもいいんだが

339 名前:デフォルトの名無しさん mailto:sage [2011/07/29(金) 23:51:06.97 ]
仕様がどうでもいいとかいうやつは、
プログラマーやめたほうがいいんじゃねーの

340 名前:デフォルトの名無しさん mailto:sage [2011/07/29(金) 23:59:57.74 ]
プログラマにとっての仕様なんて、
「コメントを求む」程度の文章でいいんだよ。



341 名前:デフォルトの名無しさん mailto:sage [2011/07/30(土) 02:47:52.95 ]
自ら勉強する気が無いならやめてしまえ

342 名前:デフォルトの名無しさん mailto:sage [2011/07/30(土) 10:43:39.89 ]
自ら勉強する気はあるが、
会社のためにしかならないことを
勉強する気にはならない。

343 名前:デフォルトの名無しさん mailto:sage [2011/07/30(土) 14:40:35.21 ]
向上心が無いのは仕方ないが、仕様が守れない奴は会社やめれ
例えば Content-Type=text/htm; charset=Shift_JIS
で、丸付き数字とか送られてきた日にはブチ切れですよ。
僕のパソコンの僕のブラウザでは表示できましたとか言い出すと殺意を覚える

344 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 00:31:57.60 ]
text/htmってのひどいな

345 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 01:37:05.98 ]
typoにマジレス。カコワルイ

346 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 03:22:17.45 ]
>>343
世の中仕様が全てではないんだよ。

347 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 03:33:15.68 ]
仕様書に必要なこと全てが書いてあるとは限らんが、
>>343のは仕様で禁止されたことをやってんでしょ。
それはまずい。

348 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 11:22:19.48 ]
charset=Windows_31J
なら良かったのか

349 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 13:39:25.25 ]
JavaやってるとContent-Typeと文字コードがリンクしてるから死活問題だな。
鯖と端末双方が「@」を使うと合意した上でWindows-31J使うのが正しいと思う。

350 名前:デフォルトの名無しさん mailto:sage [2011/07/31(日) 22:12:23.38 ]
> JavaやってるとContent-Typeと文字コードがリンクしてるから

設計が現実を処理できない仕様になってる。
ダメな設計だ。



351 名前:デフォルトの名無しさん mailto:sage [2011/08/01(月) 06:21:06.64 ]
Ruby1.9.3がSJISをWindows-31Jと認識するようになった

352 名前:デフォルトの名無しさん mailto:sage [2011/08/01(月) 07:09:08.98 ]
何か問題が?

353 名前:デフォルトの名無しさん mailto:sage [2011/08/04(木) 20:55:45.64 ]
世の中で使われているシフトジスの実態を考えれば
SJISをWindows-31Jにすることは妥当だと思うが。
SJISをShift_JISにしたところで安岡センセイ以外喜ばない。

354 名前:デフォルトの名無しさん mailto:sage [2011/08/04(木) 21:26:58.69 ]
>>353
> SJISをWindows-31Jにする
> SJISをShift_JISに

どういう意味で言っているのか?
「SJIS」とは何なのだ?


355 名前:デフォルトの名無しさん mailto:sage [2011/08/04(木) 22:49:17.03 ]
文字コード名に"SJIS"を指定されたときの動作をどうするかってことじゃねーの

356 名前:デフォルトの名無しさん mailto:sage [2011/08/04(木) 22:53:19.60 ]
そんなの好きにしたらいいじゃん。

357 名前:デフォルトの名無しさん mailto:sage [2011/08/06(土) 00:15:01.41 ]
もともとこのスレはUnicodeをUTF-16系のエンコーディングと勘違いした
人が立てたんだと思うが、MSだけでなくJavaもUnicode=UTF-16なんだっけ?

358 名前:デフォルトの名無しさん [2011/08/06(土) 00:38:20.18 ]
>>354
>>351

359 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 04:48:33.66 ]
>>357
おJAVA様の"Unicode"は
 デコード時:ビッグエンディアンUTF-16、BOM許可
 エンコード時:ビッグエンディアンUTF-16、BOMあり
Windowsの"Unicode"は
 デコード時:リトルエンディアンUTF-16、BOM許可
 エンコード時:リトルエンディアンUTF-16、BOMあり

360 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:43:57.06 ]
>>359
>UTF-16、BOM許可
冗長な表現だな。UTF-16エンコーディングスキームは常にBOM許可なんだよ。
"UTF-16LE"→BOM禁止
"UTF-16BE"→BOM禁止
"UTF-16"→BOM許可
Javaの"Unicode"は先頭のBOMを読み飛ばすから"UTF-16"。
ちなみにJavaの"UTF-8"はBOMをNBSPと認識する統一性の無い仕様。

Javaも.NETも、文字コードに表現の曖昧さのあるものは
区別できるようならないものかな
 "UTF-8" →実行環境の規定のUTF-8表現
 "UTF-8:wBOM" →先頭にBOM必須
 "UTF-8:w/BOM "→先頭のFEFFはNBSP
 "UTF-8:autoBOM" → 先頭にFEFFがあればBOM  みたいな



361 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:47:36.25 ]
BOMって文字コードの一部なのか?

たとえば、「あいうえおかきくけこ」という文字列を
split関数で2つに分けたとき、「(BOM)あいうえお」「(BOM)かきくけこ」になるのか?
違うだろう?

BOMはマックバイナリみたいなもので
文字の一部ではなくファイル形式の一種だと思うんだが。

362 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:55:48.67 ]
BOMはデータストリームの一部で、
データストリームの先頭にあるとシグネチャと看做されます。

363 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 15:02:40.62 ]
ISO-2022のエスケープシーケンスを文字コードに含むぐらいには文字コードかな。

Unicode 6.0の16.8には「U+FEFF at the very beginning of a file or stream」とあるね。
ただの文字列がstreamに含まれるかと言えば普通の感覚ではNoだけど、
絶対ダメと断言するには表現が曖昧な気がする。
streamの定義をきかれたら「一連のcharacter」としか言いようが無いから。

364 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 15:29:54.27 ]
はっきりとin the unicode data streamと書いてる。

unicode.org/faq/utf_bom.html#bom1
Byte Order Mark (BOM) FAQ

Q: What is a BOM?

A: A byte order mark (BOM) consists of the character code U+FEFF at
the beginning of a data stream, where it can be used as a signature
defining the byte order and encoding form, primarily of unmarked
plaintext files. Under some higher level protocols, use of a BOM may
be mandatory (or prohibited) in the Unicode data stream defined in
that protocol. [AF]


365 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 16:33:38.94 ]
仕様でないものを仕様と勘違いする奴とか、常に正しい仕様が存在してくれていると思ってる奴とか、
プログラマやめた方がいいんじゃねーの

366 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:35:37.51 ]
文盲がいるな。
>はっきりとin the unicode data streamと書いてる
一つ前のレスも読めないのか

367 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:49:21.22 ]
unicode data streamってのが
何かよくわからないけど、
わざわざ書いてるってことは、
特別扱い、つまり通常の文字とは別扱いなんだな。

368 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:52:20.46 ]
プログラム言語で扱う文字型はencoding schemeでなくencoding formの単位なので
BOMになり得ない。
 encoding scheme: バイトデータ表現。BOMが付くことがある
 encoding form:「文字」単位の表現。BOMの概念無し。splitで扱うのはこっち

char型(UTF-16/32文字)のFEFFはZWNBSとみなさなければならない。
それをバイトデータにエンコードして初めてBOMが付く。

369 名前:デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:55:16.42 ]
BOMが途中にあったらどうなるの?
切り替わるの?

370 名前:デフォルトの名無しさん mailto:sage [2011/08/08(月) 00:01:50.41 ]
文盲がいるな。
バイト配列をwchar_t(C)とかchar(Java)にデコードした時点でBOMは消えなきゃいけないの。
ちなみに途中にあらわれるものはBOMでなくU+FEFF文字として扱わなければならない



371 名前:デフォルトの名無しさん mailto:sage [2011/08/08(月) 01:07:46.83 ]
途中で現れるのは後方互換性のために許されてるだけで、
本当は途中に現れちゃ駄目。

372 名前:デフォルトの名無しさん mailto:sage [2011/08/08(月) 01:17:08.95 ]
deprecateでも許されてるってことは、書き込むプログラムはともかく
読み込むプログラムは処理しなきゃいけないってこった

373 名前:デフォルトの名無しさん mailto:sage [2011/08/13(土) 06:53:27.25 ]
Windows7HP 64bit、MS-IME2010ですが、IMEで変換中の文字コードは何でしょうか?
質問は以下2点で、例えば、EUC-JPのテキストをエディタで編集中とします。

1.MS-IMEで変換中(この時の文字コードは?)
2.変換した文字を確定(変換中の文字コード → EUC-JPの変換は誰がどのタイミングで行っているのでしょうか?)

374 名前:デフォルトの名無しさん mailto:sage [2011/08/13(土) 10:46:33.19 ]
>>373
1.ふつうはUTF-16
2.ふつうはテキストエディタの保存時

375 名前:デフォルトの名無しさん mailto:sage [2011/08/13(土) 10:57:29.48 ]
>>373
普通はEUC-JPで表現できない文字も入力できて、保存時にエラーが出るよね。
ってことは編集中はEUC-JPじゃないってこった

376 名前:デフォルトの名無しさん mailto:sage [2011/08/13(土) 12:10:50.38 ]
>>374-375
なるほど。
d

377 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:13:50.65 ]
他スレから来ました。
UNIXのshebangってBOMに対応できないの?

378 名前:デフォルトの名無しさん [2011/08/14(日) 01:17:53.45 ]
カーネルがバイナリファイルの先頭で #! の存在をチェックしている
ところで、まずBOMの有無をチェックするように改造すれば可能かも。


379 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:26:25.04 ]
ファイルの先頭にFE FF 00 00を見つけたとき、
・UTF-16BEのU+FEFF, U+0000
・UTF-16のBOM, U+0000
・UTF-32のBOM
のいずれであるかの見分けはつくのでしょうか

380 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:53:40.23 ]
>>379
そのバイトオーダーでは迷う要素がどこにもないのだが…



381 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:44:20.21 ]
先頭がBOMかU+feffかは、
エンコードスキームがutf-16なのかutf-16beなのか
の情報が必要。
つまりエンコードスキーム情報無しに読むことは不可

382 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:45:13.50 ]
>>381
そのバイトオーダーでは迷う要素がどこにもないのだが…

383 名前:デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:57:36.54 ]
>>381
ならff fe 00 00ならどうするのよ?

384 名前:デフォルトの名無しさん mailto:sage [2011/08/15(月) 00:39:15.78 ]
>>382
FE FF 00 00ってのは例が悪くて>>383の間違いなんだろうけど、
「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね?

385 名前:デフォルトの名無しさん mailto:sage [2011/08/15(月) 00:50:44.72 ]
Unicodeでは先頭のU+FEFFは常にBOMと解釈すべし、というルールだから、BOMであることに疑問はない。
ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは
一意に決定する方法がない、という意味で>>383の指摘は正しいものだと思う。

386 名前:デフォルトの名無しさん mailto:sage [2011/08/15(月) 01:05:17.86 ]
つ ttp://stackoverflow.com/questions/1929962/unicode-bom-for-utf-16le-vs-utf32-le
バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ

387 名前:デフォルトの名無しさん mailto:sage [2011/08/15(月) 02:30:12.19 ]
>>385
>先頭のU+FEFFは常にBOMと解釈すべし
んなこたーない。
Unicode 6.0.0「3.10 Unicode Encoding Schemes」D96
『In UTF-16BE, an initial byte sequence <FE FF> is interpreted as U+FEFF zero width no-break space』
D98
『In the UTF-16 encoding scheme, an initial byte sequence corresponding to U+FEFF is interpreted as a byte order mark』

UTF-16BEなら先頭のFE FFはU+FEFF。UTF-16なら先頭のFE FFはBOM。データから区別は出来ない。

388 名前:デフォルトの名無しさん mailto:sage [2011/08/18(木) 00:42:00.98 ]
先頭の<FE FF>がBOMなのかfeff文字なのか判断できないなんて、
BOM考えた奴、ばかなの?

389 名前:デフォルトの名無しさん mailto:sage [2011/08/18(木) 07:30:27.15 ]
Unicode自体が馬鹿の塊なのは欧米人以外なら即分かると思うが

390 名前:デフォルトの名無しさん mailto:sage [2011/08/18(木) 22:29:40.94 ]
>>389
どの辺が馬鹿の塊なのか解説よろしく



391 名前:デフォルトの名無しさん mailto:sage [2011/08/19(金) 15:06:30.40 ]
香具師らの認識している「表意文字」とはアイコンのことだからなぁ

392 名前:デフォルトの名無しさん mailto:sage [2011/08/19(金) 20:08:38.83 ]
だから今は漢字のことを表語文字と呼んだりするね

393 名前:デフォルトの名無しさん mailto:sage [2011/08/28(日) 23:49:09.53 ]
>>390
当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。

394 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:00:05.33 ]
>>393
かつてそう考えたミスは事実だが、今はコードポイントが
U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
対応出来てるだろ。
「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな?

395 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:32:35.26 ]
>>389でも>>393でもないが
正規化すると互換漢字が統一漢字になるところは時々キレそうになる

自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める
あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・

396 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:43:05.53 ]
>>394
無理はあるだろ
16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の
コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし
他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな

397 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 02:27:50.75 ]
>>394
> かつてそう考えたミスは事実だが、今はコードポイントが
> U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
> 対応出来てるだろ。

その代償として、Unicodeは複雑化してしまった。
UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。
最初から世の中の文字はすべて32bitで扱うとなっていれば、プログラムも簡単だっただろうに。
OS、言語、すべてが同じUTF-32を使う。さっさと移行しておけばよかったのに。

第一の失敗UTF-16、これがあったせいでWindows、Mac、JavaはUTF-16を
標準のものとしてサポートしてしまった。今更UTF-32にはやすやすと移行できないだろう。
おかげでサロゲートペア対応とか変なモノが後で導入された。

第二の失敗UTF-8、これのせいでUnix系はASCII文字と互換性を保てるようになってしまった。
そのせいで、UTF-8はなかなか消せなくなっただろう。

もう一文字がすべて同じ32bitの世界は絶望的だよ。

398 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 03:31:52.42 ]
>もう一文字がすべて同じ32bitの世界は絶望的だよ。
いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる
UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし

399 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 08:01:59.08 ]
>>395
自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。
外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。

400 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 08:11:50.68 ]
ぜんぜんCJK非分離の解決になっていない件



401 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:17:14.00 ]
漢字は本当に、普通に見た目が違う字が出るもんなぁ

402 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:41:22.44 ]
>>399
要件にわざわざ『Unicode正規化(C方式)』と入ってなければ
或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら
Apple独自規格だろうがなんだろうが喜んで使おう
ただ、その場合はそもそも正規化する必要がないんだけど

403 名前:デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:55:21.11 ]
>>399
>外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。

必要だからやる→>>395
自分勝手にnormalizeしたところで何の解決にもならん罠

404 名前:デフォルトの名無しさん mailto:sage [2011/08/30(火) 22:01:52.91 ]
正規化についても、みんなで仲良く正規化しないと、
いろいろ面倒なんだよなあ。

例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。
内部的には正規化してから処理するとしても、
再度書きこむ時に正規化すべきか、それとも元のままにしておくか、
元のままにしておく場合、保存しておかなければならないし。

>>397
> UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。

ちょっとこの列挙の仕方はどうかと。
言わんとしていることは分からないでもないが、
最初から32bitじゃまとまらなかっただろう。

405 名前:デフォルトの名無しさん mailto:sage [2011/08/31(水) 10:41:56.92 ]
受け入れられるためには理想の仕様は諦めて妥協しないといけない、
かといって妥協しまくりのダメ仕様でも誰も使わない。

その結果を一見して「迷走」と決めつけることは誰にもできるw

406 名前:デフォルトの名無しさん mailto:sage [2011/08/31(水) 11:50:16.72 ]
16bitは必要な妥協だったとは思わんがな

407 名前:デフォルトの名無しさん mailto:sage [2011/09/01(木) 14:44:18.72 ]
根拠は?
どうなっていたのと思うの?

408 名前:デフォルトの名無しさん mailto:sage [2011/09/01(木) 19:30:44.11 ]
必要な妥協だった、迷走ではない、と開き直るほうが簡単だよね

でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり
規格作ってるやつらは実装しなくていいんだから楽だよなあ

409 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 12:27:42.35 ]
必要な妥協なんてものはそもそも無い。
ないものを攻撃している奴は馬鹿。
仕方ない妥協があるだけ。

410 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 12:47:09.80 ]
仕方も工夫も色々あったけど
馬鹿が都合悪い部分放置でそのままreleaseしたんだろ
なんで「仕方なかった」なんて嘘が通ると思うのか
まだ「必要だった」って言い訳のほうがマシだよ



411 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 13:14:29.07 ]
>>409
>>408だけど、妥協そのものを攻撃してるんじゃなくて
>>399みたいな開き直りについて言ってるだけだから
必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから

412 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 13:15:49.10 ]
安価ミスすまん
>>399じゃなくて>>405

413 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 15:51:45.81 ]
経緯をよく知らないけど、中国/日本の当局者に6万語で収まるのかをきちんと聞いたのか?
単に憶測で6万語で収まると判断したのか?

414 名前:デフォルトの名無しさん mailto:sage [2011/09/02(金) 18:11:44.98 ]
Unicodeは最初からHan Unificationありき。
Xerox(とApple)でHan Unificationが研究されたから、
Unicodeが誕生のきっかけが出来た。

日本ではEmacsやArenaの多言語化を、
ISO 2022ベースでやっていた頃。

415 名前:デフォルトの名無しさん mailto:sage [2011/09/04(日) 05:22:06.88 ]
>>414
最初から、というか、最初だけ。
誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん

同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに
さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて
統一漢字+異体字セレクタで統一漢字でも字体を変更できるようになって
と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて
トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから……

416 名前:デフォルトの名無しさん mailto:sage [2011/09/04(日) 17:42:35.37 ]
>>415
> 機能してるとは言えん

はあ?

417 名前:デフォルトの名無しさん mailto:sage [2011/09/04(日) 19:33:51.55 ]
うん、そうだね

418 名前:デフォルトの名無しさん mailto:sage [2011/09/05(月) 04:04:33.03 ]
その通りだ

419 名前:デフォルトの名無しさん mailto:sage [2011/09/05(月) 22:01:45.96 ]
>>294
アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う

420 名前:デフォルトの名無しさん mailto:sage [2011/09/05(月) 22:32:53.25 ]
狂気はお前だ。



421 名前:デフォルトの名無しさん mailto:sage [2011/09/06(火) 01:33:22.31 ]
アンスコあるのと無いのでは全然違うだろ。

422 名前:デフォルトの名無しさん mailto:sage [2011/09/06(火) 02:42:07.11 ]
アンダースコートは無い方が良い

423 名前:デフォルトの名無しさん mailto:sage [2011/09/10(土) 15:51:03.10 ]
>>413
まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず

424 名前:デフォルトの名無しさん mailto:sage [2011/09/10(土) 18:02:22.29 ]
収まらないのはUnicodeが開発される前からわかっていた。
収めるためのHan Unificationが適切かどうかが議論になった。

>>414
> Unicodeは最初からHan Unificationありき。
> Xerox(とApple)でHan Unificationが研究されたから、
> Unicodeが誕生のきっかけが出来た。


425 名前:デフォルトの名無しさん mailto:sage [2011/09/10(土) 18:18:33.20 ]
で、不適切だったと

426 名前:デフォルトの名無しさん [2011/09/10(土) 23:32:57.71 ]
まだ天安門の頃か

427 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:10:00.22 ]
>>423
それでも説得して変えさせることは出来なかった。
かといって代替を用意して
それを普及させるだけの力もなかった。

ガラパゴス規格を作っては国内オンリーで威張る
だけの親方日の丸体質では最初から無理でした。

せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。
無理か。無能なJIS関係者や学者に金撒くんじゃなくて
最初から、ロビイストに金を突っ込むのが正しいな。


428 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:46:24.54 ]
今更お金撒いてももう無理なんじゃない?
文字コードには詳しくないんだけど
プログラマのための文字コード入門読む限りでは
今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。
実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。

429 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:51:01.90 ]
.Netでもそんな扱いだっけ?

430 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:05:01.98 ]
シフトJISってWindows以外じゃ使わないんだけどなあ…



431 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:09:02.77 ]
シフトJISって恥ずかしいよね

432 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:21:12.38 ]
Windows使いだが、業務用のバッチファイル以外でシフトJISなんか使わねーぞ。
ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。
ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので
なかなかUTF-8に移行できない。

433 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:24:56.95 ]
Visual C++がコードページにうにコードをセットできないのがすべての敗因。
コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても
ファイル名をやり取りするAPIの中にうにコード版が存在しないものが…

WindowsだけシフトJISで。

434 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:32:12.35 ]
>コマンドプロンプトも未だにうにコード使えないし

cp 65001

435 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:39:37.21 ]
>>433
ttp://yukarin.wiki.fc2.com/wiki/Tips


436 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:07:10.34 ]
よし、コマンドプロンプトのうにコード問題は解決したぞ
あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。

437 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:07:27.82 ]
ほー。
chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい?
 _tsetlocale(LC_CTYPE, _T(""));
 _tprintf(_T("マンコ\n"));

438 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:56:46.07 ]
windows のシステムロケールを変更して再起動

439 名前:デフォルトの名無しさん mailto:sage [2011/11/08(火) 08:53:05.57 ]
mendoxer!

440 名前:デフォルトの名無しさん mailto:sage [2011/11/17(木) 03:47:25.53 ]
囗囘囙囚四囜囝回囟因囡团団囤囥囦囧囨囩囪囫囬园囮囯困囱囲図围囵囶囷囸囹固囻囼国图
囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞



441 名前:デフォルトの名無しさん mailto:sage [2011/11/19(土) 21:17:47.39 ]
シフトJISはWindowsだけってことはないと思うぞ。
むしろ自分の周りだとWindows以外のシステムはいろいろあるけど
情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる
ことのほうが滅多にない。

442 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 04:14:11.87 ]
>>441
> 情報交換はシフトJISでまず問題がない。

老害しねや


443 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 11:36:54.27 ]
最近は中国人の顧客とかも増えてるからUnicode対応じゃねーと死ぬわ俺んとこは

444 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 12:29:01.95 ]
異体字セレクタと互換漢字どっち使うにしてもUnicodeは地獄

445 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 20:58:49.78 ]
互換漢字・意自体セレクタはUnicodeよりシフトジスの方が優れていると?

446 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:12:01.10 ]
中国の客とか、その時点で死だろ

447 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:17:11.83 ]
異体字があっても意味を区別できるヤツなんて
1000人に1も居ないんだから、異体字なんて駆逐してしまえ。
国も時代に合わせろよ。

448 名前:デフォルトの名無しさん mailto:sage [2011/11/20(日) 22:39:49.13 ]
全国の渡邊さんと渡邉さんがアップをはじめたようです

449 名前:デフォルトの名無しさん mailto:sage [2011/11/21(月) 02:15:21.62 ]
源規格分離のUnicodeに移行すれば、メリットは多数あってもデメリットは無いだろ。

互換漢字とか話をすり替えてユニコード批判するしかないとは。
いつまで20世紀に生きてるんだよ

450 名前:デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:52:38.60 ]
>>444だけど、>>441書いたのは俺じゃないからな
当然だけどShift_JISが使えない規格ってのが大前提だが

>>449みたいなやつも程度としては>>441と同レベルだわ
デメリットないとか本気で言ってんならな
そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど
使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ
使われてるうちにデータがどういう惨状になるか分かってんのか……



451 名前:デフォルトの名無しさん mailto:sage [2011/11/21(月) 15:03:02.41 ]
>>449 は全ての問題が解決した22世紀から来た人なんだろう、多分

452 名前:デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:24:22.16 ]
>>449
合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。
だから、PDFに複数のエンコーディングを同時に使いたいという需要が
あったりする。

453 名前:デフォルトの名無しさん mailto:sage [2011/11/24(木) 08:26:11.02 ]
原規格分離でも、別規格の文字が同じコードポイントという致命的欠点を「前世紀に批判」と誤魔化してみても、
その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw

454 名前:デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:20:13.17 ]
>453
それは別に致命的な欠点ではないだろう
統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ
最初から異体字はセレクタでよかった

455 名前:デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:50:09.36 ]
使い物にならないままでよかった、とw

456 名前:デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:56:22.92 ]
ハァ?

457 名前:デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:51:28.97 ]
痛い字セレクたん

458 名前:デフォルトの名無しさん [2012/01/09(月) 10:04:59.13 ]
>>457


459 名前:デフォルトの名無しさん mailto:sage [2012/01/09(月) 10:20:35.33 ]


460 名前:デフォルトの名無しさん mailto:sage [2012/01/15(日) 21:54:45.42 ]
書き込みが少ないようだが、スレタイの疑問には
コンセンサスが得られたってことでいいんだよな

Unicode: UTF-16リトルエンディアンBOMあり
UTF-8: よく使うアレ



461 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 09:15:50.56 ]
そんなコンセンサスはない。
MSがそう表記したがってるのは事実。
'Unicode'と'UTF-16LE'を同一視するような言い方をすれば
頭の弱いかわいそうな人と見なされる。
少なくともそいつと技術の話はできない。

462 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 14:23:26.17 ]
JavaもUTF-16の意で使うよね。MSだけじゃなくて

463 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 15:19:44.52 ]
>>462
使わねーよ。よほど古い、1990年代にかかれたような文書ならともかく。
単に文字列の内部表現がUTF-16というだけ。

464 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 15:45:26.60 ]
つまり使ってるという訳ですね

465 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 17:06:14.95 ]
使ってないじゃんw

466 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 18:40:17.48 ]
実質UTF-16しかなかった時代には、Unicode=UTF-16として扱っているドキュメントは多かった
MSは、単に旧時代の言い方をいつまでも引きずっているだけ。別にそう表記したがっているわけじゃない

467 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 18:43:23.43 ]
かつては符号化文字集合と文字符号化方式は一対一で不可分だったからね
でも時代は変わったんだからマイクロソフトは自分の所でしか通じない用語は改善するべきだと思う


468 名前:デフォルトの名無しさん mailto:sage [2012/01/16(月) 22:54:53.28 ]
>>463 おJAVA様はUnicodeがUTF-16BEの様ですね。
System.out.printf(new String(new byte[]{(byte)0x30, (byte)0x70, (byte)0x30, (byte)0x4B}, "Unicode"));

469 名前:デフォルトの名無しさん mailto:sage [2012/01/17(火) 08:39:03.98 ]
お前も頭悪いな。そんなところの互換性無くして誰か喜ぶと思ったのか?

470 名前:デフォルトの名無しさん mailto:sage [2012/01/17(火) 13:55:57.57 ]
つまり使ってる
MSと同じ



471 名前:デフォルトの名無しさん mailto:sage [2012/01/17(火) 14:10:23.18 ]
>>467
そりゃ、無理な相談だ

472 名前:デフォルトの名無しさん mailto:sage [2012/01/28(土) 03:34:36.69 ]
>>467
日本語でおk

473 名前:デフォルトの名無しさん mailto:sage [2012/01/28(土) 23:14:28.00 ]
結局Unicodeの定義にコンセンサスがないので、違いを語ることができないということでOK?
Unicodeは規格の名前だが、文字集合の意味で使われたり、UTF-16の意味で使われたり、意味も分からずユニコードと言ってみたりカオス?

474 名前:デフォルトの名無しさん mailto:sage [2012/01/29(日) 07:23:52.01 ]
混同してるバカがいる、ってだけの話

475 名前:デフォルトの名無しさん mailto:sage [2012/02/07(火) 21:50:52.80 ]
英語は大小あわせて46文字しかないし、数字10文字、記号もろもろ入れても7bitで128種類も有れば足りるよね。1byteは8bitだから頭は常に0にしとくよ。
-> ascii (7bit)

んじゃ「頭に1つけたときは半角カタカナ」ってことにしといたらasciiに日本語混ぜれるんじゃね?
いろは47文字に濁点、半濁点、カギカッコとか句読点も入れとくわ。
日本でバックスラッシュとか使わんからこいつは円記号と一緒なwww俺天才ww
-> JIS X 0201

アルファベットだけじゃヨーロッパは物足りないんで、
日本が半角カナ入れたところにウムラウト付きの文字とか入れときます。
-> latin-1

漢字絶対必要なんで、asciiとかほっといてとりあえず2バイトで表現できる文字集合選定しときます。
限りある空間資源なんで「掴」と「摑」とかは一緒ってことで堪忍してください。(包摂)
あ、英語書く時は全部全角でおながいします。
-> 97JIS符号化方式によるJIS X 0208文字集合の利用

いやいや、英語重要なんで。マジ。無視とかありえないんで。
はい、頭が1のバイト隣同士でasciiサンに迷惑かけないよう二人組作ってー。
JIS X 0201のカナ文字は無視しておk。これでJIS X 0208の文字も表現できる。
……あれ、半角と全角でアルファベットダブっちまってるけど……まいいか。
-> EUC-JP

おい、メールは7bit符号しか使ったあかんらしいぞ。えー。
切替用の透明文字(エスケープ文字)作ってその文字以降はそれぞれのコードってことにしよ。
-> ISO-2022-JP

asciiもJIS X 0201の半角カナも無視とか親泣くぞ。過去の遺産大事にしろ。
まぁ漢字使いたいけどエスケープ文字とかダルすぎるし、
JIS X 0201の空いたトコもらって2byteで使わせてもらうわ。
え?そこは制御文字用って?知るかボケ。
-> Shift_JIS

476 名前:デフォルトの名無しさん mailto:sage [2012/02/07(火) 21:51:23.32 ]
結局同じ文章に外国語入り混じらせて使いたい?
分かった分かった。お前ら黙れ。4バイトで世界中の文字全部平等に並べ直そう。な。
-> ISO/IEC 10646

ちょっとまって同じ事やろうとしてるんだけど。2byteで。
-> Unicode

足並みそろえよか。4byteやけど上2byte全部0の実質Unicodeでやってこや。
おうアジアの土人ども、母国語の文字数すら数えられんのに大きい顔すんなよ?
迷惑なんだから、似たような文字はガンガン同じにまとめとけ。(CJK統合漢字)
-> 10646とUnicodeサブセット

メンゴメンゴ。65536個じゃ足らんかったわw
Unicodeの2byte2つ組み合わせる方針にします。
2つのbyteのうち前後どっちを先にするかは文章の始めに印を付けて表すことにしましょう。(BOM)
素直に全部前から読む時はビッグエンディアン、天邪鬼さんはリトルエンディアンってことで。
でもでも、やっぱよく使う文字とよく使わない文字が同じビット数占拠するのもバカらしいんでー、
よく使う文字(BMPの文字)は2byte単体、それ以外は2つくっつけて表す事にします。(サロゲートペア)
-> UTF-16

結局くっつけるんかいwwwそれやったらasciiとの互換も考えれwww
1文字あたりのバイト数は可変長だけどasciiの文字しか使わなかったらasciiと一緒になる。
-> UTF-8

サロゲートペアは甘え。容量も懐も大きいとこ見せろ。
Unicodeをそのまま直書きで4byte固定符号化方式。どや。
Unicodeの文字並び(U+00303Dとか)がそのまんま0000303Dで分かりやすい。
-> UTF-32

477 名前:デフォルトの名無しさん mailto:sage [2012/02/07(火) 23:14:02.83 ]
符号化文字集合の一文字1コードっていう大原則を破った時点でもうぐちゃぐちゃだったんだよ。
もうどんな符号化文字集合を持ってきても絶対に誰も幸せになれない。

478 名前:デフォルトの名無しさん mailto:sage [2012/02/07(火) 23:57:30.91 ]
>>476
Unicodeの意味をを勘違いしている典型例ですね 
円コーディングフォームと円コーディングスキームの区別もつかなくて、
リトルエンディアンが天の邪鬼とか言い出すバカ

479 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 00:00:19.79 ]
わけ判らん駄文を読むヤツが居たという事の方に笑ってしまったわ

480 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 00:07:39.59 ]
円コーディングw



481 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 07:36:46.60 ]
誰も46文字にはつっこまんのか。


482 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 16:12:14.16 ]
>>475-476がまるっきり変遷の歴史と違う上に、技術屋とは思えないレベルの勘違いがありすぎ

483 名前:デフォルトの名無しさん [2012/02/08(水) 17:20:13.44 ]
英語は大小あわせて46文字しかないね。
-> ascii (7bit)

アイちゃん言語訓練には足りないね。
-> UTF-32

484 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 18:50:51.84 ]
いろは48文字につっこむのが先

485 名前:デフォルトの名無しさん mailto:sage [2012/02/08(水) 23:04:17.54 ]
なんでバイトオーダーとキャストの話が出てこない?

486 名前:デフォルトの名無しさん mailto:sage [2012/02/09(木) 01:11:51.86 ]
kwsk

487 名前:デフォルトの名無しさん mailto:sage [2012/02/09(木) 23:29:02.94 ]
>>475-476 はセンスあるね
エンディアンの説明がおかしい他はいい線いってる。
時系列を変えてるのはわかりやすさのためだろ

488 名前:デフォルトの名無しさん mailto:sage [2012/02/10(金) 00:57:08.24 ]
TCP/IPの立場から考えればリトルエンディアンは十分天邪鬼だろ。

Intel CPUはリトルエンディアンだが
整数値を小さな型にキャストしようとする時
先頭アドレスを変えずに読み込みを途中で打ち切るだけで済む。
ビッグエンディアンだとスライドさせないといけない。
その分リソースを食う。

でも数値をどこかで切り捨てたい時とか上から順にダンプかけたいときは
メリット・デメリットが逆になる。

円記号問題の根底はJIS X 0201というよりISO 646各国版の普及にあって、
もっと世界的なもんじゃないのか? トライグラフとか。

誰か詳しい人解説頼む。

489 名前:デフォルトの名無しさん mailto:sage [2012/02/10(金) 08:33:56.11 ]
トライグラフはEBCDICでもC言語を書けるようにしたものだから、あまり関係ない。

490 名前:デフォルトの名無しさん mailto:sage [2012/02/10(金) 21:48:22.40 ]
えっ?



491 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 01:09:06.04 ]
ビッグエンディアンがマトモだと信じているバカはプログロマー止めた方がいい

492 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 08:38:33.85 ]
なんで?

ワード長の拡張で、対応がずれる、以外のディスアドバンテージがあるならどうぞ。

493 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 09:53:05.21 ]
どう考えても下位ビットが下位アドレスに格納されるリトル園ディンのが自然じゃね?
ビッグエンディアンは奇数アドレスアクセスとかできないでしょ。
GIF画像の圧縮みたいな可変ビット長データの連続してパッキングは、ビッグエンディアンじゃやってられない。

デメリットは「ビットの上位の方向とバイトの上位の方向が逆」に尽きる。

494 名前:デフォルトの名無しさん [2012/02/11(土) 10:07:27.29 ]
こうして小人さんたちの戦いは続くのであった。


495 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 10:10:47.68 ]
まともなビッグエンディアンのアーキテクチャなら、ビットにアドレスが付く命令でも、
MSBがアドレス0だよ?

ビットアドレスが2の冪と対応してない、とは言えるけど、直感的でない、以外に問題ある?

496 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 10:21:38.52 ]
1バイト内のビットアドレスじゃなくてメモリ(バイト)アドレスのことだろ。
4バイト整数12345678hの上位バイト12が上位メモリアドレス3に書かれるのがリトル。
4バイト整数12345678hの上位バイト12が下位メモリアドレス0に書かれるのがビッグ。
FFhに1足して上位桁に繰り上がったら、より下位のアドレスが変わるなんて変と思わないの?

497 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 10:31:03.80 ]
アドレスが大きい方が下位と思えばどうということはない。

498 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 10:41:26.87 ]
二つ前のレスも読めないなんて、
こういうバカがビッグエンディアンを設計したんだろうな

499 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 10:49:46.08 ]
UTF-8は上位ビットが下位アドレス側に格納されるから、設計者は馬鹿だし、
リトルエンディアン信者は当然使わないよなw

500 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 11:02:53.62 ]
どうやら自分以外は全て馬鹿病の患者が、リトルエンディアン凄い、偉い、と吠えてるだけのようですねw

準TADのTRONコードでも使ってろw



501 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 11:44:58.61 ]
>>388
考えたのはM$だからな。

502 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 11:48:27.56 ]
MS叩きとか、いまどき流行らんわ

503 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 11:51:29.54 ]
>>499
cpuがメモリに直接ワードアクセスする時のメモリイメージの話と、
バイトオリエントにシリアライズしたutf-8の話を一緒にするのはいくないぜ

504 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 12:13:02.50 ]
>>501
いやほんとbomのおかげで助かるわ。
utf-8とその他のコードをほぼ確実に判別できる

505 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 20:26:42.27 ]
>>504
utf-8なのにBOMって

506 名前:デフォルトの名無しさん mailto:sage [2012/02/11(土) 21:38:11.32 ]
>>505
何か問題が?
UTF-8のシグネチャーとして大活躍じゃないか

507 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 02:20:34.14 ]
名前が良くないな。
援交ディングスキームシグネチャー
これでおk

508 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 02:52:52.82 ]
異体字セレクたん
みたいだな

509 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 08:16:34.20 ]
UTF-8のBOMって、オプションなのでしょうか?

例えばUTF-16の場合、先頭の<FE FF>はU+FEFFでなくBOMと見なす必要がありますが、
UTF-8ではUnicode 6の3.10D95をみると『can』とあるので、UTF-8の先頭の<EF BB BF>を
U+FEFFと見なすことは禁止されていないように見えます。

先頭<EF BB BF>の解釈は自由という理解で良いでしょうか?

510 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 11:27:09.36 ]
よくありません



511 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 12:25:31.41 ]
why?

512 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 15:56:41.47 ]
U+FEFFはBOM限定になったような

513 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 23:11:21.56 ]
既存の文書の存在は認めないのですね

514 名前:デフォルトの名無しさん mailto:sage [2012/02/12(日) 23:28:04.18 ]
はい
はい

515 名前:デフォルトの名無しさん mailto:sage [2012/02/13(月) 00:47:58.80 ]
>>512
ソースキボンヌ

516 名前:デフォルトの名無しさん mailto:sage [2012/02/13(月) 12:43:00.82 ]
www.unicode.org/charts/PDF/UFE70.pdf
のU+FEFFで、non-breakingは代わりにU+2060を使ってね、と。
www.unicode.org/charts/PDF/U2000.pdf
のU+2060で、BOMの曖昧さを無くす為に、と。
その方向で行こうね、位の意味合い?

517 名前:デフォルトの名無しさん mailto:sage [2012/02/13(月) 23:32:42.50 ]
先頭のU+FEFFは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSPになるのか。
で、UTF-8ではUTF-16やUTF-32から変換されたときBOMが付くことがあって、
UTF-8としては不要だけどUTF-8かどうかの識別として使えるし違反ではないよ。
途中のU+FEFFは、ZWNBSPとして扱うけどなるべくU+2060を使ってね。
こんな感じの認識でいい?

518 名前:デフォルトの名無しさん mailto:sage [2012/02/14(火) 07:21:36.14 ]
>先頭のU+FEFFは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSPになるのか。

いいと思うけど、細かい所がちょっと違う。
先頭のFE FFやFF FEの2バイトは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSP文字相当になる。
バイナリデータ(Encoding Scheme)をEncoding Formに読み取った時点でBOMは無くなる。
U+FEFFというのはUTF-16orUTF-32のEncoding FormだからBOMになり得ない。

>UTF-16やUTF-32から変換されたときBOMが付くことがあって
これも同じく、Encoding FormをEncoding Schemeに変換したときにBOMが付くことがある

519 名前:デフォルトの名無しさん mailto:sage [2012/02/14(火) 07:47:25.15 ]
「U+」はコードポイントの表記。Formじゃない。
 コードポイント: u+feff (ZWNBS文字(非推奨))
 UTF-16エンコードフォーム: <FEFF>(16ビット単位、u+は付かない)
 UTF-16エンコードスキーム: <FE FF FE FF>または<FF FE FF FE> (8バイト単位)。先頭のFE FFはBOM
 UTF-16BEエンコードスキーム: <FE FF>(8バイト単位)、先頭の<FE FF>はZWNBS文字だがZWNBSが非推奨

520 名前:デフォルトの名無しさん mailto:sage [2012/02/14(火) 13:05:58.68 ]
なるほど。やっと理解しました。ありがとう。



521 名前:デフォルトの名無しさん mailto:sage [2012/02/14(火) 17:43:30.45 ]
www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=4E62
> kHanyuPinyin 10760.010:g�i

文字化けワロス

522 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 00:37:27.03 ]
今来た俺に違いを3行で教えてくれ

523 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:31:55.27 ]
Unicode・・・文字集合
UTF-8・・・文字表現
です

524 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:37:04.34 ]
>>523
ほう、ではUnicode 6.0のどこに「Unicodeが文字集合の一つ」と
書かれているのかね?

525 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:40:16.48 ]
3行オーバーしたので答えられません。
自分でぐぐってください。

526 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:42:59.62 ]
仕様のどこと訊かれてググれと答える奴は
プログラマーに剥いていない

527 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:47:33.04 ]
ハゲは結構多いよ

528 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:49:36.68 ]
プログラマーの童貞率、アスペ率は異常

529 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 01:57:06.64 ]
細かいことにこだわらない奴はプログラマー向いてない。

向いてない人「ちょっとくらいいいでしょ?多めに見てよ」
コンピュータ「はあ?」

530 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 02:11:33.76 ]
そもそも「文字表現」ってなんだよ。ちゃんとした用語使えよ。



531 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 02:23:21.28 ]
文字表現は文字表現だよ
(T-T)悲しい
(^-^)うれしい
こんなのが最近たくさん追加されてるだろ

532 名前:522 mailto:sage [2012/02/19(日) 02:54:14.52 ]
おいおい、2スレ目にもなってケツ論出てないのかよ

533 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 15:37:07.51 ]
>>523
痴呆があらわれたか

534 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 22:52:12.18 ]
Unicode=UTF-8
一般人に違いなどわからんからこれでよし

535 名前:デフォルトの名無しさん mailto:sage [2012/02/19(日) 23:03:51.63 ]
いいわけないだろカスが^^

536 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 11:24:52.62 ]
元々の規格
UTF-8
UTF-16BE
UTF-16LE
UTF-32BE
UTF-32LE

マイクロソフトが追加した規格 (いずれもBOM付き)
UTF-8 (上記と重複する)
UTF-16 (省略BE-BOM)
UTF-16LE-BOM
UTF-32 (省略BE-BOM)
UTF-32BE-BOM
UTF-32LE-BOM

ってことでよろしいですか?

537 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 18:09:07.05 ]
ぜんぜんダメ

538 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 18:10:40.38 ]
このスレで何度か書かれてるけど、
そろそろencoding formとencoding schemeの違いを
理解した方がいいよ

539 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 20:38:04.20 ]
Unicode規格で定義されるEncoding Scheme
 UTF-8 (BOMなし) ←MSの「UTF-8」
 UTF-8 (BOM付き)
 UTF-16 (BOMなしBE、先頭にU+FEFFは書けない)
 UTF-16 (BOMありBE、先頭の<FE FF>はU+FEFFでなくBOM) ←MSの「Unicode big endian」
 UTF-16 (BOMありLE、先頭の<FF FE>はU+FEFFでなくBOM) ←MSの「Unicode」
 UTF-16BE (BOMなしBE、先頭の<FE FF>はBOMでなくU+FEFF)
 UTF-16LE (BOMなしLE、先頭の<FF FE>はBOMでなくU+FEFF)
 UTF-32 (BOMなしBE、先頭にU+FEFFは書けない)
 UTF-32 (BOMありBE、先頭の<00 00 FE FF>はU+FEFFでなくBOM)
 UTF-32 (BOMありLE、先頭の<FF FE 00 00>はU+FEFFでなくBOM)
 UTF-32BE (BOMなしBE、先頭の<00 00 FE FF>はBOMでなくU+FEFF)
 UTF-32LE (BOMなしLE、先頭の<FF FE 00 00>はBOMでなくU+FEFF)

540 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 20:40:31.47 ]
最初の二つを間違えた。正しくは ↓
 UTF-8 (BOMなし)
 UTF-8 (BOMあり) ←MSの「UTF-8」



541 名前:デフォルトの名無しさん mailto:sage [2012/02/20(月) 23:14:05.93 ]
そもそもBOMってMSの拡張じゃないの?
Unicodeにそんな仕様はいってるの?

542 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 00:42:33.77 ]
入ってますがな。
なければどんなに幸せだったことか…
BOMのない世界にforkしたい。

543 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 04:01:27.70 ]
無くて困ったことはあるが、
あって困ったことはありませぬ。

544 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 04:24:21.16 ]
BOMあるとshebangが正常に動作しない


545 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 05:19:27.61 ]
そのファイルだけBOMとれば?

文字コード不明なファイルを読み取ろうとするシバンはウンコ(・∀・)ノ●。
日本語のパスはどうすんだよ。

546 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 06:46:27.45 ]
BOM が MS拡張とかどんだけ……
まだ ISO-10646 が正式な規格になる以前からありますがな。


547 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 17:29:35.79 ]
>>537
えーなんでダメなんだよ?これjavaのエンコードライブラリそのまんまなんだぜ?

548 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 20:08:10.74 ]
>>547
JavaはBOM周りの処理のバグを認識しつつ
バグを永久に直さないことに決定済みだろ

『マイクロソフトが追加した規格』が『おJavaの認識する名前』で
BOMがMS独自という誤った記述が無ければおけ

549 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 22:38:40.98 ]
>>544
shebangに関して言えば、
shebangを読み取るプログラムが
Unicodeに対応していないというべきだろうね。

たぶん、UTF32で書かれたshebangも読み取れないはず。

550 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 22:45:12.38 ]
>>543
無くて困ったことは皆無ですが、
あって困ったことはいやほどあります。




551 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 22:52:15.54 ]
>>550
無くて困ったというのは文字コードが明確でなかったと想像できるけど、
あって困ったというのは、具体的にどんなこと?

552 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 23:04:12.52 ]
>>551
上にあるけどshbangが通らないとか(頻発するので慣れた)、
ビルドが通らないとか(頻発するので慣れた)、
SQLの実行に失敗するとか(多数のDDLの実行途中だったのでリカバーに泣いた)。

553 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 23:09:04.25 ]
ああ、あと複数のファイルをcatで繋いだら境目にゴミが混じったってのもあった。

554 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 23:12:44.31 ]
あるテキストの改行が
Cr
CrLf
Lf

三つが混ざっちゃうことあるの?

555 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 23:14:57.14 ]
>>551
単なるバイトストリームとして扱えなくなるケース。

556 名前:デフォルトの名無しさん mailto:sage [2012/02/21(火) 23:19:30.60 ]
BOMが認識できないバギーなコンパイラはともかく、catは違うような。

テキストファイルをバイナリで結合することが間違ってると思う。
結合するファイルの文字コードが違ってたら破綻するし、
ISO-2022はそもそもバイナリ結合できなくね?

557 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 09:08:20.78 ]
>>556
>>553, >>555 は、BOM なし UTF-8 ならば cat で連結できる、って話じゃないの?

別なコードの話を持ちだしても意味ないと思う。


558 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 09:10:14.09 ]
>>556
>バギーなコンパイラ
言いがかり。
そういうことがないようにUTF-8を使うのに
BOMがあるだけでパー。

>結合するファイルの文字コードが違ってたら破綻
同じUTF-8だけどな。
BOMがあるだけでパー。


559 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 09:28:36.68 ]
utf-8対応をうたうならbomを認識できなくてはならないのに
僕のKUSOコンパイラはダメなんです。と言われてもなあ。
取り敢えずKUSOコンパイラユーザーにデメリットが有るのはわかったw

560 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 09:34:37.56 ]
catでbomが困るなんて、
「テキストに日本語を書くと様々な問題を起こすので日本語の使用はデメリット」
とか
「csvにヘッダー行を書くとcatできない問題があるので書かないようにしている」
ってのと同レベル



561 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 13:10:05.23 ]
>>559
BOMさえなければ、とくにUTF-8に
対応することがそもそも不要。

バギーでもクソでもない。


UTF-8原理主義者は面倒くさいな。


562 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 14:07:48.03 ]
バイトオーダーという概念がないUTF-8でBOMとはこれいかに?

563 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 14:21:41.35 ]
仕様に従っているかどうかの話と
仕様自体の妥当性は別の話。
utf-8安置は頭が悪いな

564 名前:デフォルトの名無しさん [2012/02/22(水) 14:25:08.95 ]
うにコード安置はいるがutf-8安置はいるのだろうか?

565 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:03:18.48 ]
ファイル名に日本語を使ってはいけないとか、メールのタイトルに日本語を
使ってはいけないというのは、UNIXの伝統的な掟です。
LinuxはUNIXに憧れているので、UNIXの掟を忠実に守ります。
掟を守るのは大事なことです。

UTF-8を許せば日本語を使う馬鹿が出てきますよ。

566 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:03:29.36 ]
UTF-8は、ASCII上位互換コーディングシステムとして設計された。
バイトストリームとして扱えば、プログラムがそのまま使えるように。
Ken Thompson先生が。Unicodeの外の世界で。

だからUnicode.orgがUTF-8にもBOMを付けるのは味噌をつけてしまったようなもの。
ただ既にBOMがあるのだから、当然の帰結ではあるのだが。

もともとのUnicodeの考え(wide character主義)とUTF-8は乖離しているから、
こういう残念な状態になってしまった。

567 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:06:40.21 ]
>>565
パス名といえば、例えば、
"¥Users¥漢字名さん¥ドキュメント"
"漢字名さん"
"ドキュメント"
それぞれにBOMが付くとパス名処理がすごく面倒になる。
Unicode互換の処理系を名乗るにはやらないといけないけど、
そういうOS、ミドルウェアは未だ存在しない。

568 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:18:27.13 ]
大体BOM付きとか滅茶苦茶不合理じゃん。
"a" だけで何バイトだよ?
旧来のBOM無しUnicodeを新しいUnicodeとして制定しなおしましょう。

569 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:18:31.69 ]
>>567
だからこそ許してはいけないのです。
ファイル名やメールの件名に日本語を使ってはいけません。

570 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:19:17.81 ]
さあ、早くEF BB BFを削る作業に戻るんだ。



571 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:20:33.65 ]
>>568
それは思い上がりですね。
ASCIIだけで充分です。

572 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:20:40.10 ]
NotePad BOM付きしか認識しない。
UNIX系 BOM無しを前提にしている。

やっぱM$の陰謀以外考えられないわけだが。

573 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:21:39.18 ]
>>571
ならば、おまえだけは日本語で書き込むなよ。

574 名前:デフォルトの名無しさん [2012/02/22(水) 15:28:41.23 ]
kokoha tanoshii intaaneto desune

575 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:29:14.05 ]
>>573
俺はUNIXもLinuxも使っていないのでメールの件名に日本語を使うし、
ファイル名にも日本語を使います。
HTMLメールが送られてきたからと言って怒ったりしません。

576 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:35:24.27 ]
571 名前:デフォルトの名無しさん :2012/02/22(水) 15:20:33.65
>>568
それは思い上がりですね。
ASCIIだけで充分です。

>>575
だからおまえは日本語でこの掲示板に書き込む権利は一切無いの。


577 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:41:57.47 ]
>>576
いえいえ、俺はUNIXもLinuxも使わないので歴史的に日本語OKなのです。
ご心配には及びません。

578 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 15:42:52.80 ]
nanda tadano baka dattaka


579 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 16:46:17.18 ]
>>567
Unicode規格のencoding formとencoding schemeの説明を読み直してこい

フォルダー名にbomが付くとかあり得ないから


580 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 16:51:22.56 ]
asciiとかどれだけ可搬性のないのものを持ち出すんだよ。
@とか[とかは機種依存文字なのを知らんのか最近の若いモンは。



581 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 16:57:58.84 ]
>>580
8bit目を立てるのはマナー違反です。

582 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 17:18:50.84 ]
>>579
何言ってるかさっぱりわからん。
パス名はメモリ上のデータに限られてると限定しているわけ?

583 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 18:05:31.10 ]
>>572
NotePad は BOM なくても UTF-8 を認識するよ。
でも保存するときに強制的に BOM がつくのが問題。

Unix でなくても、たとえば文書のヘッダやフッタを別のテキストファイルから
include してくるというのは、よくある処理だと思うけど、そういう場合に、
いちいち BOM の処理が必要というのは不合理。

字数とかワードラップとかの処理が必要な場合は仕方ないけれど、そうでない
場合はバイナリとテキストで同じプログラムが使えるようになっているのが望
ましい。



584 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 18:11:47.88 ]
>>582
Unicode規格ではEncoding FormにBOMの概念は無いんですよ。(ここらへんはRFC 3629と定義が違う)
Windowsのフォルダー名はEncoding SchemeでなくEncoding Form単位で読み書きするので、
フォルダー名にBOMが入ることはないです

585 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 18:22:59.79 ]
>>583
>たとえば文書のヘッダやフッタを別のテキストファイルから
>include してくるというのは、よくある処理だと思うけど、そういう場合に、

MS Word文書をバイナリで結合したら読み取れませんでした。てのと同レベル。
バイナリデータを挿入するんでなく、「テキスト」を挿入するよう見直した方がいい。
ISO/IEC 2022だって二つのファイルをバイナリで結合したら壊れるだろ

586 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 18:31:25.66 ]
>>580
ASCIIの7ビット文字は、現代で現実的に
充分ポータブルだろ。

どのあたりを心配してる?


587 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 18:34:04.47 ]
>>586
    ∩_∩     
   / \ /\   
  |  (^)=(^) |    人人人人人人人人人人
  |  ●_●  |   < BOM否定派に対する皮肉だろ>
 / //   ///ヽ  <言わせんな恥ずかしい>
 | 〃 ------ ヾ |   YYYYYYYYYYYYYY
 \__二__ノ

588 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 20:32:33.68 ]
>>584
フォルダ名が外からもたらされたら、
>フォルダー名にBOMが入ることはないです
なんて課程は全くできないけど?

589 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:16:57.21 ]
>>588
BOMとU+FEFFは違う物です。Encoding SchemeとEncoding Formの違いを理解してください。

Windows APIでフォルダーを作成する際の名前は「UTF-16(Encoding Form)」でしか指定できないのです。
「UTF-16(Encoding Scheme)」を受け取るAPIは有りません。
外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、
BOMを取り除いた形でWindowsに渡す必要があります。

590 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:20:02.08 ]
> 外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、
> BOMを取り除いた形で

こういう処理をユーザがしないといけないって話なんだけど?



591 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:49:40.36 ]
話がずれてないか?
もとはパス名処理が大変と言う567に対し、
文字列になってる時点でBOMは無いので単純だというのが579。

バイナリを文字列に変換するのにBOM処理は当然必要なんだけど、
それは567の「パス名処理が大変」「実装が存在しない」とは違う話。

592 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:09:53.07 ]
BOMっていうのはファイルにしか存在しないものだよ。

BOM付きの文字列を半分に分けたらどうする?
前半の文字列にはBOMがついて、
後半の文字列にはBOMがついてない?
それともわざわざ付けると思う?

BOMが存在するのは外部リソースのみ
それをUNICODE文書として読み取った時、
BOMは消さないといけない。

だから、APIに渡す文字列がBOM無しなのはアタリマエのこと。



593 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:11:12.92 ]
プログラマが頑張らないといけない実装しかないから、
パス名処理が大変なんでしょ?

> 文字列になってる時点でBOMは無い

「文字列になって」
この定義自体が難しいから、
プログラマが何も気にしないでも問題が起きない実装はないわけだ。
そもそも利用者のレベルでも問題が起きうる。

594 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:12:42.87 ]
>>592
> BOMっていうのはファイルにしか存在しないものだよ。

外部リソースならどんなものにも付く可能性がある。

595 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:22:35.82 ]
>>593

> 「文字列になって」
> この定義自体が難しいから、

簡単。バイナリではなく文字列として解釈できる準備ができた時。
それは文字列型に代入した時や、
UTF8フラグなんかをつけた時。

596 名前:デフォルトの名無しさん [2012/02/22(水) 23:23:34.45 ]
そもそも「ファイル」っていう概念をちゃんと>>592が分かって書いてるのかどうかも怪しい

597 名前:デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:27:15.21 ]
UNIXでいう「ファイル」だけど?

598 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:11:05.68 ]
そもそもBOM付きデータは「バイナリ」であって「テキスト」ではない、と考えてる。
「テキスト」は純粋に「文字列」を表現する要素のみで構成されたものであるべき。


599 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:44:37.73 ]
バイト列だから順序が必要なんじゃろ?
整数列だから順序が必要ないんじゃろ?
それがエンコードスキームとエンコードフォームを分けた由来じゃろ?

Unicodeのエンコードフォームでは文字列は数値列だから、ひとつの文字はひとつの数値として扱われる。
しかしこれが物理的にコンピュータ上で扱われるとき、
コンピュータはその数値列を一つのバイト値として扱えない。
つまり、一つの文字は複数のバイト列になる。
だからバイト列に順序が必要になる。

一方、UTF-8はいずれの場合もバイト列として扱う。
文字列はバイト列であるので順番が必要ない。

という話じゃなかったっけあはん大陸。

600 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:46:24.77 ]


>一方、UTF-8はいずれの場合もバイト列として扱う。
>文字列はバイト列であるので順番が必要ない。

これは「文字列もまたバイト列であるので順番が必要ない」と書くべきか^^;



601 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:52:52.91 ]
>>565
UTF-8 許されてるなら日本語使っても良いと思う
むしろファイル名に半角 space 入れる香具師の方が
もう阿呆かと

602 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:53:52.69 ]
>>594
ファイルじゃない外部リソースなんかあるのか

603 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:54:42.23 ]
>>601
何がいけないんだ?

604 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 00:56:47.75 ]
>>602
メモリ、ストリームなどなど^^

605 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:00:55.19 ]
>>604
それって、つまり、ずーっと辿るとファイルに行き着くだろ
ファイル以外でBOMなんて付かないだろ

606 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:05:04.93 ]
>>605
いやいや。
例えばリアルタイムにコード変換してる時は元ファイルにはBOMついてないし^^;
メモリに展開される時にBOMがつく(つかないと判別できない^^)
そもそもプログラム内部は論理表現なのでBOMなどというものはありえない。
これがメモリに展開される瞬間、つまり物理表現に変わる瞬間にバイト順序が必要になる。
ストリームも同じ。

607 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:16:51.20 ]
>>603
だろ?

608 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:18:14.42 ]
恥ずかしいスレだな

609 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:35:10.93 ]
J( 'ー`)し ごめんね。おかあさんはじめてUnicode使ったから、ごめんね

610 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 01:40:10.04 ]
>>606
'\0'を文字列の途中に突っ込むのと同じ話だけど。
やろうと思えば出来る。でも普通はメモリ中のデータにBOMは入れない。
くだらない話だから伸ばすな。



611 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 02:46:18.12 ]
>>605
> それって、つまり、ずーっと辿るとファイルに行き着くだろ

アホなの?


612 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 05:51:03.86 ]
>>593
明確だよ。
byte[]型は文字列でない。stringは文字列。
CでもWindowsならchar[]からTCHAR[]になった時点で文字列。

CでもASCII NUL終端で扱っている時点でBOMが有るのは間違い。
UTF-16とか扱えなくなるだろ

613 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 06:10:47.12 ]
>>601
むしろ半角スペースで動かなくなる方が殺害モノだね。
やるべきことをやってないだけ。

"c:\a bcacls.exe" "c:de f" /R "SYSTEM"
SET "PATH=c:a b"

常にこう書けば何が渡されても破綻しない

614 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 07:36:47.91 ]
crlf->lf
cr->lf
lf->crlf
---------------
->の意味わ?

615 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 07:41:56.77 ]
>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。

アホなの?

616 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 08:15:36.17 ]
そもそもUTF-16やUTF-32は
文字に\0が含まれるのでchar[]では扱えない。

617 名前:デフォルトの名無しさん [2012/02/23(木) 08:24:03.69 ]
>>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
char[] == TCHAR[]

618 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 09:58:23.45 ]
犬が混じると低レベル化するな。

619 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 10:36:35.75 ]
また犬が来たw

620 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 13:52:22.90 ]
テーブル(Unicode)とデータ表現(UTF-8)の違いじゃねーの?



621 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 13:58:47.78 ]
>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。

Windowsでは#define UNICODEとしないと文字列を扱えないそうです。


622 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 14:02:47.03 ]
>>616
いや扱える。
<stdio.h><string.h>などが文字列はnull terminate前提、
Cコンパイラも文字列リテラルが同様ってだけ。

ex.
struct UTF16String {
int length;
char data[];
};


623 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 16:55:20.64 ]
MessageBoxA と MessageBoxW の違いも判ってなさそう出汁

624 名前:デフォルトの名無しさん [2012/02/23(木) 20:02:43.63 ]
Shift_JISは常にビッグエンディアンだけど
UTF-16はBEとLEがあるクソ仕様、SJISとCP932の問題よりさらに酷い
おまけにサロゲートペアのせいで何が16なのかと言うレベル

バイトストリームとしてはBEに限定して
APIなどではuint16_t*なりwchar_t*で扱えばいいのに
何故バイトストリームでBE版とLE版を用意したのかと

625 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 20:31:26.64 ]
ネットワークバイトオーダーもJavaのデータアウトプットもBEに規定されてたよな。
たしかOracleもBEだったか。16LEは確かに誰得。

626 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 21:06:35.37 ]
同じchar[]でもバイト列と文字列ではセマンティクスは別物になる
ファイル or メモリ、char[] or TCHAR[]
重要なのはデータソースでも型でも無く、データの意味そのもの

同じintでも電圧の変数に電流の値を代入して良いわけがなく
同じstringでも通常の文字列とhtml文字列を混同すればxssに一直線だ

内部表現は[文字符号化方式]でなく[符号化文字集合]と考えるのが適切
バイナリとして読み込んだUTF-16文書のバッファ(文字符号化方式)のポインタを
wchar_t*(符号化文字集合)に単純キャストするような荒業でも動作する環境はあるが
wchar_tが4バイトの処理系ではそうはいかない

627 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 21:42:14.43 ]
何でキチガイが湧いてるの?

628 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 21:46:52.94 ]
なんでレッテル厨が湧いてるの?
具体的な反論するのが怖いの?

629 名前:デフォルトの名無しさん mailto:sage [2012/02/23(木) 21:59:21.69 ]
>>624
>Shift_JISは常にビッグエンディアンだけど
「A」は82h 60hという2バイトであって、3260h(33376)ではありません。

>>621
長さとペアでバイナリデータを保持するcharと、ヌル終端前提のTCHARを区別しろってことでしょ。
TCHARがcharかwchar_tかは関係無い。
>>626の言う「重要なのはデータソースでも型でも無く、データの意味そのもの」を少しは理解しな

630 名前:デフォルトの名無しさん [2012/02/23(木) 23:09:37.18 ]
文字集合JIS X 0208の A : コードポイント3区33点(3-33)
→ JIS X 0208の符号化方式Shift JISでは 0x82 0x60 と表現
→ JIS X 0208の別の符号化方式EUC-JPでは 0xA3 0xC1 と表現

つまりUTF-32BEが最強



631 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 00:24:42.69 ]
>>628
Cの時代にcharで文字列とバイナリの両方を扱って
きた人間には理解を超えているので、
相手に罵声を浴びせることしかできないんだぜ。

エンコードスキーム(バイトデータ)とエンコードフォームの
違いがこのスレで何度説明されたことか。
未だに全く理解できていないし

632 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 00:31:43.04 ]
Unicodeはwchar_tのために作られたわけじゃねーだろ

633 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 00:41:41.68 ]
>>631
まだ言ってるのかw

634 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 00:50:25.32 ]
>>626
この解釈間違ってると思うんだが
誰も突っ込まないのな

635 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 00:50:38.49 ]
>>631
Windowsのwchar_tは2バイトでutf-16で固定長じゃないんだから、
charでutf-8を扱った方がまし。

636 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 01:03:21.88 ]
>>635
utf-8はいいけど
BOMのあり得るエンコードスキームUTF-8と
BOMの無いエンコードフォームUTF-8は
異なる概念なので区別しろよw

でないと、UTF-16BEはヌルが含まれるのでcで扱えないとか
とんちんかんなことを言い出しかねん

637 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 01:20:18.39 ]
BOMありUTF-8使ってるのって日本だけなん?

638 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 01:21:59.80 ]
>>634
頼んだぞ

639 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 01:24:48.19 ]
>>637
Windowsのメモ帳が付けるというのに、
どうしてそんな考えに至ったのか知りたい

640 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 02:40:35.01 ]
>>636
メモリ上にはUnicode encoding formしかないと勘違いしている人?



641 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 06:13:03.23 ]
それだとファイルを読み込むことが不可能になってしまいます

読み取ったバイナリデータをテキストとして処理する前に
エンコードフォームに直すと言うことでは?

642 名前:デフォルトの名無しさん [2012/02/24(金) 21:05:08.82 ]
ヌル終端の文字列って超使われてるけどさ
struct{char* begin, char* end}の値渡しか、その構造体へのポインタを渡すようにした方が良かったよね
今更ってレベルじゃないけど

643 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:23:26.59 ]
struct{char* begin, int len)の方がいい。

644 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:27:00.18 ]
struct{char*end;chars[];};の方がいい

645 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:32:30.58 ]
>>642
最初はstructなんてなかったんだよ。
そこまで斜めだと後出しですらないだろ。

646 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:34:20.57 ]
>>643
Pascalがそれ。
実装によってはnull characterも持てた。
けど勝利したのはCのシンプルさ。
同じデータ構造(char [])でバイナリも持てる。


647 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:35:14.65 ]
そのせいでCはUTF16や32に
特殊な型を持ち出さないと対応できなくなった。

648 名前:デフォルトの名無しさん mailto:sage [2012/02/24(金) 21:36:10.43 ]
それどころかstrlenやstrcpyでも
UTF16やUTF32専用の関数が必要になった。

649 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 00:27:19.29 ]
>>643
intじゃポインタで表現可能な範囲を持てる保証が無いよ
実際殆どの64bit環境(LP64やLLP64)でintでは4Gの壁が出来上がる
せめてptrdiff_tにしないとね

>>645
マジか、struct無かったのか・・・
でも斜めではなくね?STLでもbegin(),end()が基本だしさ

650 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 00:36:53.09 ]
>>649
昔の話だとして…
Cの前身はT *とintの区別なかったんだよ。
型指定がなくて、型は名前のついてないWORD型しかない。
今で言うところのILP16で。(Integer, Long, Pointerが16bit)
だからその影響でCでもしばらく型指定なしの変数宣言するとintだった。




651 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 00:53:57.92 ]
>>649
ならsize_tでいいだろ。
strlenの戻り値の型だ。

652 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 08:59:27.50 ]
>>650
cの前身っていったら1971年?
そんな時代に16ビットが普及してたはずもないのだが

653 名前:デフォルトの名無しさん [2012/02/25(土) 11:01:25.83 ]
パソコンの16ビットはそりゃそうだろうけど、
ミニコンの16ビットは70年代に16ビットは普通では?


654 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 11:05:36.97 ]
BCPLはPDP-7だっけかな。
と思って調べたらまさかの18ビット

655 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 11:06:15.46 ]
DECという会社があったこと #平成生まれが知らないことを挙げていこうぜ

656 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 13:22:49.45 ]
ここは加齢臭漂うスレとなりました。

657 名前:デフォルトの名無しさん mailto:sage [2012/02/25(土) 23:22:28.04 ]
ファブリーズしても全然ダメなぐらい

658 名前:デフォルトの名無しさん mailto:sage [2012/02/26(日) 15:47:27.68 ]
CrCrLfはWindowsだと1回の改行でMacだと2回の改行?

659 名前:デフォルトの名無しさん mailto:sage [2012/02/26(日) 16:11:51.66 ]
CR/CRLF/LF が混在してるテキストなんて基本的に想定外という扱いでいいだろJK

660 名前:デフォルトの名無しさん mailto:sage [2012/02/26(日) 19:02:49.96 ]
>>658
ソフトラインブレークは発狂の元



661 名前:デフォルトの名無しさん mailto:sage [2012/02/26(日) 19:09:25.17 ]
CRとLFの連続を改行として扱えばいい
空行が無くなるが

662 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 06:35:19.89 ]
>>658
CrCrLfはWindowsだと不正な改行。
なのでそれを受け入れたい場合は、どう処理するかをソフトウェアの仕様で
決めなければならない。

663 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 12:08:54.55 ]
Crの次がLfならひとまとめ、Lfの次がCrならひとまとめって感じの実装が多い気がする
混ざってても大体うまくいくし
CrCrLfLfLfCrLfLfCr → Cr,CrLf,Lf,LfCr,Lf,LfCr → 改行6個

CrLfCrLfCrLf → CrLf,CrLf,CrLf (Windows)
LfLfLf → Lf,Lf,Lf (Linux)
CrCrCr → Cr,Cr,Cr (Mac9以前)

664 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 13:18:33.44 ]
WIN/UNIX/MACごちゃまぜのソフトでWINのクライアントから編集するたびに改行が倍になってくやつがあったな

665 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 15:26:35.50 ]
CRのみは歴史的文書しかないから、特殊なアプリ以外は無視して問題なし。

666 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 16:24:28.49 ]
>>659
一方Microsoft Excelさんは平然と混ぜてくるのであった

CSV形式で保存すると行の区切りにCRLFを使用するけど
セル内に改行がある場合は""で囲った上でLFのみで出してくる斜め上仕様
そうした理由は分からんでもないけど・・・

667 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 18:18:57.20 ]
自分が作る場合はこんなふうに処理している。

1. CR または LF が連続していたら、それぞれの数を数える
2. LF が一個でもあったら CR は無視してその個数を改行数とする
3. LF がひとつもなかったら CR の個数を改行数とする
4. 出力の改行を決める必要があるときは、入力の最初の改行によって決める
(入力がないときはOS依存……最近は LF 決め打ちが多いけど)

わざと混在させる必要がある場合以外、これで問題ない。

もっとも、CR のみの文書っていまだかつて見たことないが。


668 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 18:20:19.66 ]
RFC4180ってAccessのCSVと同じだろ

669 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 19:07:55.38 ]
RFC4180読んでみた
2005年公開でこの内容ってことは単にMS Officeに合わせただけか
MSの頭悪いCSVの仕様がRFCになってるとは

素直にメタ文字エスケープすればいいのに

670 名前:デフォルトの名無しさん mailto:sage [2012/02/27(月) 22:26:43.04 ]
メタ文字こそウンコ。
パーサーのことだけで読みやすさを考えてないだろ。



671 名前:デフォルトの名無しさん mailto:sage [2012/02/28(火) 11:05:23.12 ]
俺はエスケープの方が途中で改行が混じっていない分読みやすい
まぁその辺は人によるから不毛だな

あとパーサーだけじゃないぞ
ちょっとした文字の置換とかも、しやすさが全然違う

672 名前:デフォルトの名無しさん mailto:sage [2012/02/29(水) 07:10:49.12 ]
\を入力するとなんで/になっちゃうの?

673 名前:デフォルトの名無しさん mailto:sage [2012/02/29(水) 16:32:24.20 ]
なるのは君だけ

674 名前:デフォルトの名無しさん mailto:sage [2012/03/02(金) 19:25:17.78 ]


675 名前:デフォルトの名無しさん mailto:sage [2012/03/02(金) 19:43:07.92 ]







676 名前:デフォルトの名無しさん mailto:sage [2012/03/02(金) 19:43:31.69 ]
>>675
みえる化

677 名前:デフォルトの名無しさん mailto:sage [2012/03/02(金) 19:48:04.83 ]
クイックス懐かしいな・・・

678 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 05:57:10.92 ]
1ヶ月のケってなんなの?

679 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 07:43:55.61 ]
箇ないし个の変形。「け」ではない。

680 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 16:13:06.06 ]
へーへーへー。10へー。



681 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 16:41:16.18 ]
1ヵ月のカってなんなの?


682 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 16:46:52.04 ]
30人日の力だろ?

683 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 17:05:29.99 ]
ヵゕかカカ力刀

684 名前:デフォルトの名無しさん mailto:sage [2012/03/03(土) 17:11:27.73 ]
>>681 それも >>679

685 名前:デフォルトの名無しさん mailto:sage [2012/03/04(日) 23:00:24.18 ]

これはキーボードのローマ字入力でどのキーを押せば

686 名前:デフォルトの名無しさん mailto:sage [2012/03/04(日) 23:51:46.85 ]
消せますか?

687 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 07:21:55.87 ]
もう面倒くさいから
1文字1MBで表現しろよ!

688 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 08:07:52.93 ]
らめぇ、回線が壊れちゃうよぉ

689 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 15:01:53.43 ]
原稿用紙一枚分のテキストが400MB

690 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 15:22:57.77 ]
動画でテキストを表現ですか。



691 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 20:10:02.36 ]
トントンツーツーは2進法なの?

692 名前:デフォルトの名無しさん [2012/03/12(月) 20:31:58.10 ]
文字間セパレータがあるから記号としては3つじゃないか?


693 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 21:20:31.96 ]

  ∧,,∧
 ( `・ω・) ウーム…?
 / ∽ |
 しー-J

694 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 22:00:02.92 ]
>>692
ストップビット2
0:1ビット
1:1.5ビット

695 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 22:01:50.36 ]
>>694
書き直す

ストップビット:4
0:2ビット
1:3ビット

696 名前:デフォルトの名無しさん mailto:sage [2012/03/12(月) 22:17:33.78 ]
三進数

697 名前:デフォルトの名無しさん mailto:sage [2012/03/13(火) 10:00:05.44 ]
学習塾

698 名前:デフォルトの名無しさん mailto:sage [2012/03/13(火) 10:02:10.36 ]
痛い児セレクたん

699 名前:デフォルトの名無しさん mailto:sage [2012/03/13(火) 23:25:06.32 ]
やっぱり二進数だわ
トン、ツー


700 名前:デフォルトの名無しさん mailto:sage [2012/03/14(水) 12:43:51.04 ]
>>699
その様子だと、お前は次の問題が解けねぇな。

英文が成立する最低限度のキャラクタのうち、出現頻度が一番高いのは、何?



701 名前:デフォルトの名無しさん mailto:sage [2012/03/14(水) 12:57:27.42 ]
kumi

702 名前:デフォルトの名無しさん mailto:sage [2012/03/14(水) 16:28:08.33 ]
すポース

703 名前:デフォルトの名無しさん mailto:sage [2012/03/14(水) 17:02:49.10 ]
Siri

704 名前:デフォルトの名無しさん mailto:sage [2012/03/14(水) 23:11:46.61 ]
chinbo

705 名前:デフォルトの名無しさん mailto:sage [2012/03/16(金) 00:03:13.48 ]
>>700
話そらすバカ

706 名前:デフォルトの名無しさん mailto:sage [2012/03/27(火) 00:05:22.70 ]
>>705
全くそれていないんだが、それが理解できないと言うことは、
1200 8N1 とか言っても理解できんのんだよなwww

707 名前:デフォルトの名無しさん mailto:sage [2012/03/27(火) 07:50:36.57 ]
レイヤ1と2の区別がつかないハード屋さんですね。
わかります。
しかも1200っていつの時代

708 名前:デフォルトの名無しさん mailto:sage [2012/03/27(火) 13:12:53.93 ]
ATZ
ATZ
ATDT110

709 名前:デフォルトの名無しさん mailto:sage [2012/03/27(火) 15:45:33.29 ]
年寄りの加齢臭話はいいから文字コードの話しに戻ろうぜ

710 名前:デフォルトの名無しさん mailto:sage [2012/03/28(水) 09:08:44.45 ]
>>707
お前・・・・分かるんだwww



711 名前:デフォルトの名無しさん mailto:sage [2012/03/28(水) 09:41:33.96 ]
50歳以下は帰ってくれないか?

712 名前:営利利用に関するLR審議中@詳細は自治スレへ mailto:sage [2012/04/08(日) 02:17:17.24 ]
ヘボン式ってなに?

713 名前:営利利用に関するLR審議中@詳細は自治スレへ mailto:sage [2012/04/08(日) 02:20:11.84 ]
トイレに…

714 名前:デフォルトの名無しさん mailto:sage [2012/04/12(木) 12:01:16.85 ]
フランソワ・漏れション

715 名前:デフォルトの名無しさん mailto:sage [2012/04/15(日) 04:48:40.36 ]
ヘボン式ローマ字は、英語と親和性がたかいが、音韻学的、言語学的な日本語表記法ではない。
ドイツ語、ポルトガル語など、英語以外の言語では、発音がことなるおそれがある。

「ヘボン式ローマ字は英語の発音に準拠したので、日本語の表記法としては破綻が多い(中略)
日本式は音韻学理論の結実として、日本国内外の少なくない言語学者の賛同を得た。
しかし、英語の発音への準拠を排除した日本式ローマ字は英語話者や日本人英語教育者から激しい抵抗を受け」
ローマ字 - Wikipedia

716 名前:デフォルトの名無しさん [2012/04/15(日) 05:43:55.65 ]
オードリーヘッバン


717 名前:デフォルトの名無しさん mailto:sage [2012/04/15(日) 12:15:22.24 ]
ローマ字って習う必要あったのかな?

718 名前:デフォルトの名無しさん mailto:sage [2012/04/16(月) 13:41:08.05 ]
ハングルよりいいんじゃない?

719 名前:デフォルトの名無しさん mailto:sage [2012/04/21(土) 23:43:35.82 ]
↑会話の出来ないばか

720 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 05:43:04.90 ]
住所の番号の部分を全角数字で書かせるホームページってなんなの



721 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 10:56:29.77 ]
新聞記事で良く見るのが
ユニホーム
とか
ビルヂング

722 名前:デフォルトの名無しさん [2012/04/22(日) 11:34:27.88 ]
でもセーターとかミルクセーキとかは気にならない


723 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 11:48:55.63 ]
メールは微妙

724 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 12:00:05.69 ]
それより、

 ス マ ホ

をなんとかしろ。

725 名前:デフォルトの名無しさん [2012/04/22(日) 12:09:28.76 ]
マスコミュ

726 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 13:51:12.05 ]
全角URL

727 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 20:35:53.60 ]
>>720
何なのとは?
お前が何を問題視しているのかを説明してもらおうか

728 名前:デフォルトの名無しさん mailto:sage [2012/04/22(日) 20:45:02.96 ]
このスレだとUnicode処理系とは認められないってことじゃないかね。

729 名前:デフォルトの名無しさん mailto:sage [2012/04/23(月) 18:35:00.20 ]
「千代田区一丁目」って入力させたいんだろ? いいじゃねーか

730 名前:デフォルトの名無しさん [2012/04/23(月) 19:54:19.70 ]
○丁目はそこまでが町名だから許せるんだけどねぇ。




731 名前:デフォルトの名無しさん mailto:sage [2012/04/23(月) 20:49:49.64 ]
全角文字は人生を不必要に複雑化する

732 名前:デフォルトの名無しさん mailto:sage [2012/04/24(火) 02:44:24.00 ]
姓と名の間の空白を全角にするか半角にするか
プログラミングを意識したら、半角がいいとおもう(区切りだから)
実際には、全角がつかわれてもしょうがない

733 名前:デフォルトの名無しさん mailto:sage [2012/04/24(火) 02:52:38.61 ]
1桁の数字を全角にするようにスタイルガイド≠ェきまってたりする。
2桁以上を半角にする。

たとえば、新聞、雑誌など、縦書きを意識したら、何桁でも全角数字がいいとか。

734 名前:デフォルトの名無しさん mailto:sage [2012/04/24(火) 10:37:30.00 ]
なんで「縦書き」を文字コードが意識しなければいけないのだ^^
使っている文字フォントの縦横比が1:40000だったりしたらどうするのだw

全角半角という呼び方もそうだが、
文字幅は文字フォントの問題であり、文字コードの責任ではない。

って、件の本に書いてあったじゃろ?^^

735 名前:デフォルトの名無しさん mailto:sage [2012/04/24(火) 12:24:24.96 ]
全角半角くらいプログラム側で変換しろよと思う

736 名前:デフォルトの名無しさん mailto:sage [2012/04/24(火) 21:58:39.23 ]
>>733
縦書きで2桁は半角だろ?



24


737 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 17:45:04.43 ]
>>734
Unicodeは東アジア圏の文字幅(半角/全角含む)については、その取り扱いは規定されているだろ。

Unicode Standard Annex #11
East Asian Width
www.unicode.org/reports/tr11/

東アジアの文字幅
ja.wikipedia.org/wiki/%E6%9D%B1%E3%82%A2%E3%82%B8%E3%82%A2%E3%81%AE%E6%96%87%E5%AD%97%E5%B9%85


738 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 19:36:54.24 ]
といっても、それは参考特性だからなぁ。フォントの横幅を必ず2桁分にしろよという約束とはちと違うし。
実際、たいていのプロポーショナルフォントでは2倍になっとらんし…。
何とかならんもんかね。

739 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 20:14:29.55 ]
>>736
英語圏から見るとほんとカオスなんだろうなw

740 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 20:28:09.29 ]
>>738
プロポーショナルフォントで1:2の関係になるわけないでしょ。
プロポーショナルフォントの意味分かってるの?

1:2にしたければ固定幅フォントを使え。



741 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 20:29:33.25 ]
Unicodeにおけるhalfwidth,fullwidthはroundtrip conversionの
ための単なる呼び名でglyphの幅とは関係無い。
今は同じフォントでも文字幅いくつも持って切換えられるから、全角半角の
文字幅比はフォント固定でも変わる。
文字幅半分のglyphを生成したいとかはレンダリングで対処すべき問題

742 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 20:35:04.43 ]
UnicodeのEast Asian Widthは、既存の文字コードとの互換の為に用意されているのだから、
固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。

743 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 20:56:48.08 ]
>>742
>固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。
レンダリングで対処すべき問題ってことね。
固定ピッチフォントなんてのはUnicodeの関知する所じゃないし。

744 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:00:49.88 ]
>>743
文字の特性値を見れば
全角/半角の切り分けはできるって言いたいだけだよ。

745 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:24:40.16 ]
だからそれは文字コードの責任じゃないでしょw
最初から話が噛み合ってないねw

746 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:28:35.44 ]
>>745
文字コードの責任だよ。

Unicodeの仕様を見てごらん。

Fullwidthと書いてあるよね?
Halfwidthと書いてあるよね。

Halfは半分という意味、Widthは幅という意味だよ。

747 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:31:01.29 ]
お前の中ではな^^;
件の本を読めれ^^;

748 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:34:31.61 ]
>>745
全角/半角を見分けてレンダリングする、レンダラを作ろうとする場合に、
どの文字を全角として扱って、どの文字を半角として扱うかの根拠になるのは、
www.unicode.org/reports/tr11/
www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
この2つだろ。

Unicodeが文字コードの規格では無いとでも言うつもりか?

749 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:36:46.68 ]
いや、だから、おまえらの勝手な仕様解釈なんてクソ以下なんだってば
俺は別にUnicodeの仕様策定者でも解釈者でもなく
単におまえらより偉い先生の書いた本の内容通りに言ってるだけなわけで

おまえらが偉いなら本書いて世間に認められてからその珍妙な説を展開してくれ

750 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:38:39.18 ]
クソ本をヨイショする事しかできないなら黙ってろよ。



751 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:40:11.73 ]
少なくとも糞本も書けないおまえらの珍説をありがたがるほどノーテンキじゃねーんだよ
それともここでおまえらの珍説をたかが一人の人間に納得させると何かおまえらは勝った気になるのか?w

752 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:41:42.62 ]
うん

753 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:43:41.68 ]
べつにおまえにありがたがってもらう必要はねーよ。
勝った気になるとか何の話だ?アホか。

754 名前:デフォルトの名無しさん mailto:sage [2012/04/25(水) 21:51:18.70 ]
以下珍説またはスレタイと無関係な煽り合いで1000まで↓

755 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 00:10:30.79 ]
     ___
  :/   u\;       ____
 ;/   ノル(<)\;   / ;u  ノ し\
 ;|  (>)  _)  \;/      ⌒   \
 ;|::: ⌒(__ノェソ   /       、    |
 ;.\ u ´   ソ /       ^     |
    ;\     ,  |             |
   ,ヾ \_ n^^- \         j; __/
  ;/  浴Q;i  ̄丶/ ̄        \
  ;(     ⌒)  ´   ノ         \

756 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 07:22:30.80 ]
>>746
だから、それはUnicodeと旧来のエンコーディングとの対応を取るための単なるラベル。
Glyphの幅は何も規定しない。どういうglyph幅を採用するかはフォントデザイナの裁量。
UAX #11にもわざわざ
In legacy implementations, there is often a corresponding difference in encoding
length (one or two bytes) as well as a difference in displayed width.
However, the actual display width of a glyph is given by the font and may be further
adjusted by layout.
って書いてあるでしょ。

757 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 17:15:34.07 ]
文字コードでなくフォントの問題であるべきって主張はいいけど、
「半角」「全角」って言葉が現実的に無視できない存在であることは理解した方がいいよ。

少なくとも半角全角を区別する文字コードが存在して
それに対応する文字がUnicodeに登録されているのは事実。

758 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 17:40:43.57 ]
「した方が良い」と「しなければならない」を区別して話した方が良いと思うんだ

・East Asian Width参考特性が半角なら、フォントは1/2のサイズにしなければならない
・East Asian Width参考特性が半角なら、フォントは1/2のサイズにした方が良い

後者なら反対してる人は居ないんじゃないかな

759 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 18:58:59.64 ]
仕様も読まなきゃ本も読まないアホに何言っても無駄
自分の解釈が間違ってるって認めたら死んじまうような
ペラペラのアイデンティティの上でぎりぎり生きてるような連中だから

760 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 22:41:20.21 ]
仕様=建前
現実=本音



761 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 22:53:08.42 ]
固定ピッチフォントがlegacyとかふざけるなターミナルエミュレータは現役だし将来も無くなる予定なんぞないわ、とtr11を見たときオモタ。

762 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 23:06:35.26 ]
固定幅フォントであっても半角と全角の文字の幅比が1:2であるとは限らない。
こんなの常識。

763 名前:デフォルトの名無しさん mailto:sage [2012/04/26(木) 23:26:45.82 ]
建前「固定幅フォントであっても半角と全角の文字の幅比が1:2であるとは限らない。 」

本音「1:2にするべきだ」

764 名前:デフォルトの名無しさん mailto:sage [2012/04/27(金) 05:09:05.83 ]
一人顔真っ赤な奴がいる?

765 名前:デフォルトの名無しさん mailto:sage [2012/04/27(金) 05:50:54.33 ]
ASCIIの1文字が8x8ドットで表現されていた頃、漢字は4倍角だった。
そのうち半角全角も、ただの歴史になるだろ。

766 名前:デフォルトの名無しさん mailto:sage [2012/04/27(金) 20:44:56.57 ]
話をぶった切るけど、Unicode関係のお勧めの本ってどんなのがあります?

767 名前:デフォルトの名無しさん mailto:sage [2012/04/27(金) 22:03:45.30 ]
amazon

768 名前:デフォルトの名無しさん mailto:sage [2012/04/28(土) 11:43:55.63 ]
UTF-8にわくわしいのに香具師の意味がわかんないだけど

769 名前:デフォルトの名無しさん mailto:sage [2012/04/28(土) 20:44:13.87 ]
わくわくしいって何か楽しげだな

770 名前:デフォルトの名無しさん mailto:sage [2012/04/28(土) 21:09:07.62 ]
わくわく死?



771 名前:デフォルトの名無しさん mailto:sage [2012/04/29(日) 05:40:27.80 ]
奴(ヤツ)
ヤシ
香具師(やし)

772 名前:デフォルトの名無しさん mailto:sage [2012/05/03(木) 13:16:56.46 ]
何を言っているのかよくわからんが・・・

少なくとも半角と全角を同一視するうにコードは、市ね、
と言いたい。

少なくとも、半角と全角を同一視したうえで勝手に全角半角を切り替えるアプリ書いたぼけ、市ね、
と言いたい。

773 名前:デフォルトの名無しさん mailto:sage [2012/05/03(木) 17:10:28.08 ]
>>772
君の方こそ何を言っているのかわからないよ。
>半角と全角を同一視するうにコード

774 名前:デフォルトの名無しさん mailto:sage [2012/05/03(木) 20:04:15.75 ]
>>773
Unicode風でありながら、半角と全角の空白を同一のコードポイントを割り当てた文字コード
それが、うにコード

775 名前:デフォルトの名無しさん mailto:sage [2012/05/03(木) 21:45:35.05 ]
てか、
¥ U+00a5 を
\ 0x5C
に変換するライブラリ、市ね


776 名前:デフォルトの名無しさん mailto:sage [2012/05/03(木) 23:14:36.68 ]
>>775
それはUnicodeでなくて「Unicodeとローカルエンコードとの変換ルール」の話だと思うが、
既定でCP932変換ルール(Unicodeコンソーシアム公開のもの)でないのはKUSOだな。
オプションでCP932以外を指定できるなら可。

777 名前:デフォルトの名無しさん mailto:sage [2012/05/04(金) 16:50:18.92 ]
Altキーはなんとよめば

778 名前:デフォルトの名無しさん mailto:sage [2012/05/06(日) 09:29:11.27 ]
>>777
あらどっこいしょ

779 名前:デフォルトの名無しさん mailto:sage [2012/05/06(日) 11:08:02.26 ]
Alertキーだろ
アラート

780 名前:デフォルトの名無しさん mailto:sage [2012/05/07(月) 21:09:03.92 ]
>>777
alternateなんだからアルトに決まってんだろ!


\アルタネーッテ/



781 名前:デフォルトの名無しさん mailto:sage [2012/05/07(月) 21:31:02.38 ]
オ・・

782 名前:デフォルトの名無しさん mailto:sage [2012/05/09(水) 01:21:11.83 ]
居る棚恥部

783 名前:デフォルトの名無しさん mailto:sage [2012/05/11(金) 06:48:00.44 ]
単にUnicodeって言ったときは
一般的にはUTF16インディアン付なんでしょ?

784 名前:デフォルトの名無しさん mailto:sage [2012/05/11(金) 07:26:20.20 ]
ねーよ。
そんなことをやるのはバカだ。
いくらたくさんいようが、バカはバカだ。

785 名前:デフォルトの名無しさん mailto:sage [2012/05/11(金) 07:56:49.55 ]
>>783
ちげーよ
単に「文字コードはUnicode」と言ったら
言ってる奴がアホなのでその意味を汲み取ってあげないといけない。
Windows意外ならBOM無しが多い。
ってかエンディアン月とか、もうアホかと

786 名前:デフォルトの名無しさん mailto:sage [2012/05/11(金) 19:18:13.50 ]
Windowsメモ帳に
Unicodeで保存する項目があるけどどんなUnicodeまでかまでわ表示されないだけど

787 名前:デフォルトの名無しさん mailto:sage [2012/05/11(金) 19:32:02.13 ]
続きは?

788 名前:デフォルトの名無しさん mailto:sage [2012/05/12(土) 15:12:52.52 ]
インディアン付とは、新たな概念ですね

789 名前:デフォルトの名無しさん mailto:sage [2012/05/12(土) 17:29:03.25 ]
ふんどし級の驚きだねw

790 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 05:27:44.76 ]
インディアン嘘つかない



791 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 05:33:56.53 ]
UTF-8:エンコードの一つ。
 インディアンは付かない

UTF-16:Unicodeのインディアン付エンコード

792 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 12:09:07.66 ]
UTF-8:USOなし
 インディアン嘘付かない

UTF16:USOあり
 インディアン嘘つき

793 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 13:25:10.90 ]
ビッグインディアンに勝てる気がしない

794 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 14:33:09.62 ]
ちんこビンビン

795 名前:デフォルトの名無しさん [2012/05/13(日) 16:37:51.40 ]
>>794


796 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 22:39:55.24 ]
>>791
マジレスじゃないよね?

797 名前:791 mailto:sage [2012/05/13(日) 22:45:59.54 ]
>>796
マジレスのつもりでした。
UTF-8はバイトオーダーに依存しないので
インディアン無しと掻きました

798 名前:デフォルトの名無しさん mailto:sage [2012/05/13(日) 23:59:25.40 ]
依存もなにもbyte orderなんだからbyte単位データの並び多種になってたまるかよ

799 名前:デフォルトの名無しさん mailto:sage [2012/05/14(月) 00:36:19.59 ]
おい、バイト! オーダー取ってこい!

800 名前:デフォルトの名無しさん mailto:sage [2012/05/14(月) 00:54:01.43 ]
じわっときたが
がっかりした
残念だ



801 名前:デフォルトの名無しさん mailto:sage [2012/05/14(月) 06:11:25.37 ]
インディアン

802 名前:デフォルトの名無しさん mailto:sage [2012/05/14(月) 11:09:05.25 ]
リトルインディアン

803 名前:デフォルトの名無しさん [2012/05/14(月) 21:49:46.07 ]
ワンリルートゥーリル


804 名前:デフォルトの名無しさん [2012/05/14(月) 21:58:08.99 ]
ウディタの新バージョン「ウディタ2.00」が公開されました(2011年10月27日)

「WOLF RPGエディター」とは? 
・高度なRPG開発が可能な、完全無料のゲーム作成ツールです。
・雰囲気はRPGツクール2000に近い。RPGツクール2000で自作システムを作りこむ際に
 不満だったところがいろいろ解消されていて、かなり自由度が高いです。ただし
 その分初心者には難しいかも。すでにツクール2000で自作システムを組むのに
 慣れた人やRPGツクールでは物足りないけどプログラミングはちょっとという方にお勧め。
・作成したゲームは自由に配布したり、コンテストに投稿することも可能。
 また本ソフトを持たない人でもプレイ可能!ファイル暗号化も完備!
■作り方しだいでパズル系やカードゲームやシミュレーションやシューティングや
アクション、RTSや他なんでも作れます。
■また他の人がネット上で公開している「コモンイベント」を組み合わせて利用すれば、
自分では開発が難しいゲームシステムも容易に実現することができます。







[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<183KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef