11/08/14 04:45:13.50
>>381
そのバイトオーダーでは迷う要素がどこにもないのだが…
383:デフォルトの名無しさん
11/08/14 04:57:36.54
>>381
ならff fe 00 00ならどうするのよ？
384:デフォルトの名無しさん
11/08/15 00:39:15.78
>>382
FE FF 00 00ってのは例が悪くて>>383の間違いなんだろうけど、
「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね？
385:デフォルトの名無しさん
11/08/15 00:50:44.72
Unicodeでは先頭のU+FEFFは常にBOMと解釈すべし、というルールだから、BOMであることに疑問はない。
ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは
一意に決定する方法がない、という意味で>>383の指摘は正しいものだと思う。
386:デフォルトの名無しさん
11/08/15 01:05:17.86
つ URLﾘﾝｸ(stackoverflow.com)
バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ
387:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/08/18 00:42:00.98
先頭の<FE FF>がBOMなのかfeff文字なのか判断できないなんて、
BOM考えた奴、ばかなの？
389:デフォルトの名無しさん
11/08/18 07:30:27.15
Unicode自体が馬鹿の塊なのは欧米人以外なら即分かると思うが
390:デフォルトの名無しさん
11/08/18 22:29:40.94
>>389
どの辺が馬鹿の塊なのか解説よろしく
391:デフォルトの名無しさん
11/08/19 15:06:30.40
香具師らの認識している「表意文字」とはアイコンのことだからなぁ
392:デフォルトの名無しさん
11/08/19 20:08:38.83
だから今は漢字のことを表語文字と呼んだりするね
393:デフォルトの名無しさん
11/08/28 23:49:09.53
>>390
当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。
394:デフォルトの名無しさん
11/08/29 01:00:05.33
>>393
かつてそう考えたミスは事実だが、今はコードポイントが
U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
対応出来てるだろ。
「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな？
395:デフォルトの名無しさん
11/08/29 01:32:35.26
>>389でも>>393でもないが
正規化すると互換漢字が統一漢字になるところは時々キレそうになる
自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める
あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・
396:デフォルトの名無しさん
11/08/29 01:43:05.53
>>394
無理はあるだろ
16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の
コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし
他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな
397:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/08/29 03:31:52.42
＞もう一文字がすべて同じ32bitの世界は絶望的だよ。
いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる
UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし
399:デフォルトの名無しさん
11/08/29 08:01:59.08
>>395
自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。
外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。
400:デフォルトの名無しさん
11/08/29 08:11:50.68
ぜんぜんCJK非分離の解決になっていない件
401:デフォルトの名無しさん
11/08/29 11:17:14.00
漢字は本当に、普通に見た目が違う字が出るもんなぁ
402:デフォルトの名無しさん
11/08/29 11:41:22.44
>>399
要件にわざわざ『Unicode正規化(C方式)』と入ってなければ
或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら
Apple独自規格だろうがなんだろうが喜んで使おう
ただ、その場合はそもそも正規化する必要がないんだけど
403:デフォルトの名無しさん
11/08/29 11:55:21.11
>>399
＞外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
必要だからやる→>>395
自分勝手にnormalizeしたところで何の解決にもならん罠
404:デフォルトの名無しさん
11/08/30 22:01:52.91
正規化についても、みんなで仲良く正規化しないと、
いろいろ面倒なんだよなあ。
例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。
内部的には正規化してから処理するとしても、
再度書きこむ時に正規化すべきか、それとも元のままにしておくか、
元のままにしておく場合、保存しておかなければならないし。
>>397
> UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。
ちょっとこの列挙の仕方はどうかと。
言わんとしていることは分からないでもないが、
最初から32bitじゃまとまらなかっただろう。
405:デフォルトの名無しさん
11/08/31 10:41:56.92
受け入れられるためには理想の仕様は諦めて妥協しないといけない、
かといって妥協しまくりのダメ仕様でも誰も使わない。
その結果を一見して「迷走」と決めつけることは誰にもできるw
406:デフォルトの名無しさん
11/08/31 11:50:16.72
16bitは必要な妥協だったとは思わんがな
407:デフォルトの名無しさん
11/09/01 14:44:18.72
根拠は？
どうなっていたのと思うの？
408:デフォルトの名無しさん
11/09/01 19:30:44.11
必要な妥協だった、迷走ではない、と開き直るほうが簡単だよね
でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり
規格作ってるやつらは実装しなくていいんだから楽だよなあ
409:デフォルトの名無しさん
11/09/02 12:27:42.35
必要な妥協なんてものはそもそも無い。
ないものを攻撃している奴は馬鹿。
仕方ない妥協があるだけ。
410:デフォルトの名無しさん
11/09/02 12:47:09.80
仕方も工夫も色々あったけど
馬鹿が都合悪い部分放置でそのままreleaseしたんだろ
なんで「仕方なかった」なんて嘘が通ると思うのか
まだ「必要だった」って言い訳のほうがマシだよ
411:デフォルトの名無しさん
11/09/02 13:14:29.07
>>409
>>408だけど、妥協そのものを攻撃してるんじゃなくて
>>399みたいな開き直りについて言ってるだけだから
必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから
412:デフォルトの名無しさん
11/09/02 13:15:49.10
安価ミスすまん
>>399じゃなくて>>405ね
413:デフォルトの名無しさん
11/09/02 15:51:45.81
経緯をよく知らないけど、中国/日本の当局者に6万語で収まるのかをきちんと聞いたのか？
単に憶測で6万語で収まると判断したのか？
414:デフォルトの名無しさん
11/09/02 18:11:44.98
Unicodeは最初からHan Unificationありき。
Xerox(とApple)でHan Unificationが研究されたから、
Unicodeが誕生のきっかけが出来た。
日本ではEmacsやArenaの多言語化を、
ISO 2022ベースでやっていた頃。
415:デフォルトの名無しさん
11/09/04 05:22:06.88
>>414
最初から、というか、最初だけ。
誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん
同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに
さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて
統一漢字＋異体字セレクタで統一漢字でも字体を変更できるようになって
と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて
トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから……
416:デフォルトの名無しさん
11/09/04 17:42:35.37
>>415
> 機能してるとは言えん
はあ?
417:デフォルトの名無しさん
11/09/04 19:33:51.55
うん、そうだね
418:デフォルトの名無しさん
11/09/05 04:04:33.03
その通りだ
419:デフォルトの名無しさん
11/09/05 22:01:45.96
>>294
アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う
420:デフォルトの名無しさん
11/09/05 22:32:53.25
狂気はお前だ。
421:デフォルトの名無しさん
11/09/06 01:33:22.31
アンスコあるのと無いのでは全然違うだろ。
422:デフォルトの名無しさん
11/09/06 02:42:07.11
アンダースコートは無い方が良い
423:デフォルトの名無しさん
11/09/10 15:51:03.10
>>413
まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず
424:デフォルトの名無しさん
11/09/10 18:02:22.29
収まらないのはUnicodeが開発される前からわかっていた。
収めるためのHan Unificationが適切かどうかが議論になった。
>>414
> Unicodeは最初からHan Unificationありき。
> Xerox(とApple)でHan Unificationが研究されたから、
> Unicodeが誕生のきっかけが出来た。
425:デフォルトの名無しさん
11/09/10 18:18:33.20
で、不適切だったと
426:デフォルトの名無しさん
11/09/10 23:32:57.71
まだ天安門の頃か
427:デフォルトの名無しさん
11/11/08 00:10:00.22
>>423
それでも説得して変えさせることは出来なかった。
かといって代替を用意して
それを普及させるだけの力もなかった。
ガラパゴス規格を作っては国内オンリーで威張る
だけの親方日の丸体質では最初から無理でした。
せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。
無理か。無能なJIS関係者や学者に金撒くんじゃなくて
最初から、ロビイストに金を突っ込むのが正しいな。
428:デフォルトの名無しさん
11/11/08 00:46:24.54
今更お金撒いてももう無理なんじゃない？
文字コードには詳しくないんだけど
プログラマのための文字コード入門読む限りでは
今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。
実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。
429:デフォルトの名無しさん
11/11/08 00:51:01.90
.Netでもそんな扱いだっけ？
430:デフォルトの名無しさん
11/11/08 01:05:01.98
シフトJISってWindows以外じゃ使わないんだけどなあ…
431:デフォルトの名無しさん
11/11/08 01:09:02.77
シフトJISって恥ずかしいよね
432:デフォルトの名無しさん
11/11/08 01:21:12.38
Windows使いだが、業務用のバッチファイル以外でシフトJISなんか使わねーぞ。
ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。
ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので
なかなかUTF-8に移行できない。
433:デフォルトの名無しさん
11/11/08 01:24:56.95
Visual C++がコードページにうにコードをセットできないのがすべての敗因。
コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても
ファイル名をやり取りするAPIの中にうにコード版が存在しないものが…
WindowsだけシフトJISで。
434:デフォルトの名無しさん
11/11/08 01:32:12.35
>コマンドプロンプトも未だにうにコード使えないし
cp 65001
435:デフォルトの名無しさん
11/11/08 01:39:37.21
>>433
URLﾘﾝｸ(yukarin.wiki.fc2.com)
436:デフォルトの名無しさん
11/11/08 02:07:10.34
よし、コマンドプロンプトのうにコード問題は解決したぞ
あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。
437:デフォルトの名無しさん
11/11/08 02:07:27.82
ほー。
chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい？
_tsetlocale(LC_CTYPE, _T(""));
_tprintf(_T("マンコ\n"));
438:デフォルトの名無しさん
11/11/08 02:56:46.07
windows のシステムロケールを変更して再起動
439:デフォルトの名無しさん
11/11/08 08:53:05.57
mendoxer!
440:デフォルトの名無しさん
11/11/17 03:47:25.53
囗囘囙囚四囜囝回囟因囡团団囤囥囦囧囨囩囪囫囬园囮囯困囱囲図围囵囶囷囸囹固囻囼国图
囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞
441:デフォルトの名無しさん
11/11/19 21:17:47.39
シフトJISはWindowsだけってことはないと思うぞ。
むしろ自分の周りだとWindows以外のシステムはいろいろあるけど
情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる
ことのほうが滅多にない。
442:デフォルトの名無しさん
11/11/20 04:14:11.87
>>441
> 情報交換はシフトJISでまず問題がない。
老害しねや
443:デフォルトの名無しさん
11/11/20 11:36:54.27
最近は中国人の顧客とかも増えてるからUnicode対応じゃねーと死ぬわ俺んとこは
444:デフォルトの名無しさん
11/11/20 12:29:01.95
異体字セレクタと互換漢字どっち使うにしてもUnicodeは地獄
445:デフォルトの名無しさん
11/11/20 20:58:49.78
互換漢字・意自体セレクタはUnicodeよりシフトジスの方が優れていると？
446:デフォルトの名無しさん
11/11/20 21:12:01.10
中国の客とか、その時点で死だろ
447:デフォルトの名無しさん
11/11/20 21:17:11.83
異体字があっても意味を区別できるヤツなんて
1000人に1も居ないんだから、異体字なんて駆逐してしまえ。
国も時代に合わせろよ。
448:デフォルトの名無しさん
11/11/20 22:39:49.13
全国の渡邊さんと渡邉さんがアップをはじめたようです
449:デフォルトの名無しさん
11/11/21 02:15:21.62
源規格分離のUnicodeに移行すれば、メリットは多数あってもデメリットは無いだろ。
互換漢字とか話をすり替えてユニコード批判するしかないとは。
いつまで20世紀に生きてるんだよ
450:デフォルトの名無しさん
11/11/21 13:52:38.60
>>444だけど、>>441書いたのは俺じゃないからな
当然だけどShift_JISが使えない規格ってのが大前提だが
>>449みたいなやつも程度としては>>441と同レベルだわ
デメリットないとか本気で言ってんならな
そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど
使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ
使われてるうちにデータがどういう惨状になるか分かってんのか……
451:デフォルトの名無しさん
11/11/21 15:03:02.41
>>449 は全ての問題が解決した22世紀から来た人なんだろう、多分
452:デフォルトの名無しさん
11/11/23 20:24:22.16
>>449
合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。
だから、PDFに複数のエンコーディングを同時に使いたいという需要が
あったりする。
453:デフォルトの名無しさん
11/11/24 08:26:11.02
原規格分離でも、別規格の文字が同じコードポイントという致命的欠点を「前世紀に批判」と誤魔化してみても、
その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw
454:デフォルトの名無しさん
11/11/24 20:20:13.17
>453
それは別に致命的な欠点ではないだろう
統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ
最初から異体字はセレクタでよかった
455:デフォルトの名無しさん
11/11/24 20:50:09.36
使い物にならないままでよかった、とw
456:デフォルトの名無しさん
11/11/24 20:56:22.92
ﾊｧ?
457:デフォルトの名無しさん
11/11/26 11:51:28.97
痛い字セレクたん
458:デフォルトの名無しさん
12/01/09 10:04:59.13
>>457
459:デフォルトの名無しさん
12/01/09 10:20:35.33
れ
460:デフォルトの名無しさん
12/01/15 21:54:45.42
書き込みが少ないようだが、スレタイの疑問には
コンセンサスが得られたってことでいいんだよな
Unicode: UTF-16リトルエンディアンBOMあり
UTF-8: よく使うアレ
461:デフォルトの名無しさん
12/01/16 09:15:50.56
そんなコンセンサスはない。
MSがそう表記したがってるのは事実。
'Unicode'と'UTF-16LE'を同一視するような言い方をすれば
頭の弱いかわいそうな人と見なされる。
少なくともそいつと技術の話はできない。
462:デフォルトの名無しさん
12/01/16 14:23:26.17
JavaもUTF-16の意で使うよね。MSだけじゃなくて
463:デフォルトの名無しさん
12/01/16 15:19:44.52
>>462
使わねーよ。よほど古い、1990年代にかかれたような文書ならともかく。
単に文字列の内部表現がUTF-16というだけ。
464:デフォルトの名無しさん
12/01/16 15:45:26.60
つまり使ってるという訳ですね
465:デフォルトの名無しさん
12/01/16 17:06:14.95
使ってないじゃんｗ
466:デフォルトの名無しさん
12/01/16 18:40:17.48
実質UTF-16しかなかった時代には、Unicode＝UTF-16として扱っているドキュメントは多かった
MSは、単に旧時代の言い方をいつまでも引きずっているだけ。別にそう表記したがっているわけじゃない
467:デフォルトの名無しさん
12/01/16 18:43:23.43
かつては符号化文字集合と文字符号化方式は一対一で不可分だったからね
でも時代は変わったんだからマイクロソフトは自分の所でしか通じない用語は改善するべきだと思う
468:デフォルトの名無しさん
12/01/16 22:54:53.28
>>463 おＪＡＶＡ様はUnicodeがUTF-16BEの様ですね。
System.out.printf(new String(new byte[]{(byte)0x30, (byte)0x70, (byte)0x30, (byte)0x4B}, "Unicode"));
469:デフォルトの名無しさん
12/01/17 08:39:03.98
お前も頭悪いな。そんなところの互換性無くして誰か喜ぶと思ったのか？
470:デフォルトの名無しさん
12/01/17 13:55:57.57
つまり使ってる
MSと同じ
471:デフォルトの名無しさん
12/01/17 14:10:23.18
>>467
そりゃ、無理な相談だ
472:デフォルトの名無しさん
12/01/28 03:34:36.69
>>467
日本語でおk
473:デフォルトの名無しさん
12/01/28 23:14:28.00
結局Unicodeの定義にコンセンサスがないので、違いを語ることができないということでOK?
Unicodeは規格の名前だが、文字集合の意味で使われたり、UTF-16の意味で使われたり、意味も分からずユニコードと言ってみたりカオス？
474:デフォルトの名無しさん
12/01/29 07:23:52.01
混同してるバカがいる、ってだけの話
475:デフォルトの名無しさん
12/02/07 21:50:52.80
英語は大小あわせて46文字しかないし、数字10文字、記号もろもろ入れても7bitで128種類も有れば足りるよね。1byteは8bitだから頭は常に0にしとくよ。
-> ascii (7bit)
んじゃ「頭に1つけたときは半角カタカナ」ってことにしといたらasciiに日本語混ぜれるんじゃね？
いろは47文字に濁点、半濁点、カギカッコとか句読点も入れとくわ。
日本でバックスラッシュとか使わんからこいつは円記号と一緒なｗｗｗ俺天才ｗｗ
-> JIS X 0201
アルファベットだけじゃヨーロッパは物足りないんで、
日本が半角カナ入れたところにウムラウト付きの文字とか入れときます。
-> latin-1
漢字絶対必要なんで、asciiとかほっといてとりあえず2バイトで表現できる文字集合選定しときます。
限りある空間資源なんで「掴」と「摑」とかは一緒ってことで堪忍してください。(包摂)
あ、英語書く時は全部全角でおながいします。
-> 97JIS符号化方式によるJIS X 0208文字集合の利用
いやいや、英語重要なんで。マジ。無視とかありえないんで。
はい、頭が1のバイト隣同士でasciiサンに迷惑かけないよう二人組作ってー。
JIS X 0201のカナ文字は無視しておｋ。これでJIS X 0208の文字も表現できる。
……あれ、半角と全角でアルファベットダブっちまってるけど……まいいか。
-> EUC-JP
おい、メールは7bit符号しか使ったあかんらしいぞ。えー。
切替用の透明文字（エスケープ文字）作ってその文字以降はそれぞれのコードってことにしよ。
-> ISO-2022-JP
asciiもJIS X 0201の半角カナも無視とか親泣くぞ。過去の遺産大事にしろ。
まぁ漢字使いたいけどエスケープ文字とかダルすぎるし、
JIS X 0201の空いたトコもらって2byteで使わせてもらうわ。
え？そこは制御文字用って？知るかボケ。
-> Shift_JIS
476:デフォルトの名無しさん
12/02/07 21:51:23.32
結局同じ文章に外国語入り混じらせて使いたい？
分かった分かった。お前ら黙れ。4バイトで世界中の文字全部平等に並べ直そう。な。
-> ISO/IEC 10646
ちょっとまって同じ事やろうとしてるんだけど。2byteで。
-> Unicode
足並みそろえよか。4byteやけど上2byte全部0の実質Unicodeでやってこや。
おうアジアの土人ども、母国語の文字数すら数えられんのに大きい顔すんなよ？
迷惑なんだから、似たような文字はガンガン同じにまとめとけ。(CJK統合漢字)
-> 10646とUnicodeサブセット
メンゴメンゴ。65536個じゃ足らんかったわｗ
Unicodeの2byte2つ組み合わせる方針にします。
2つのbyteのうち前後どっちを先にするかは文章の始めに印を付けて表すことにしましょう。(BOM)
素直に全部前から読む時はビッグエンディアン、天邪鬼さんはリトルエンディアンってことで。
でもでも、やっぱよく使う文字とよく使わない文字が同じビット数占拠するのもバカらしいんでー、
よく使う文字(BMPの文字)は2byte単体、それ以外は2つくっつけて表す事にします。(サロゲートペア)
-> UTF-16
結局くっつけるんかいｗｗｗそれやったらasciiとの互換も考えれｗｗｗ
1文字あたりのバイト数は可変長だけどasciiの文字しか使わなかったらasciiと一緒になる。
-> UTF-8
サロゲートペアは甘え。容量も懐も大きいとこ見せろ。
Unicodeをそのまま直書きで4byte固定符号化方式。どや。
Unicodeの文字並び(U+00303Dとか)がそのまんま0000303Dで分かりやすい。
-> UTF-32
477:デフォルトの名無しさん
12/02/07 23:14:02.83
符号化文字集合の一文字1コードっていう大原則を破った時点でもうぐちゃぐちゃだったんだよ。
もうどんな符号化文字集合を持ってきても絶対に誰も幸せになれない。
478:デフォルトの名無しさん
12/02/07 23:57:30.91
>>476
Unicodeの意味をを勘違いしている典型例ですね
円コーディングフォームと円コーディングスキームの区別もつかなくて、
リトルエンディアンが天の邪鬼とか言い出すバカ
479:デフォルトの名無しさん
12/02/08 00:00:19.79
わけ判らん駄文を読むヤツが居たという事の方に笑ってしまったわ
480:デフォルトの名無しさん
12/02/08 00:07:39.59
円コーディングｗ
481:デフォルトの名無しさん
12/02/08 07:36:46.60
誰も46文字にはつっこまんのか。
482:デフォルトの名無しさん
12/02/08 16:12:14.16
>>475-476がまるっきり変遷の歴史と違う上に、技術屋とは思えないレベルの勘違いがありすぎ
483:デフォルトの名無しさん
12/02/08 17:20:13.44
英語は大小あわせて46文字しかないね。
-> ascii (7bit)
アイちゃん言語訓練には足りないね。
-> UTF-32
484:デフォルトの名無しさん
12/02/08 18:50:51.84
いろは48文字につっこむのが先
485:デフォルトの名無しさん
12/02/08 23:04:17.54
なんでバイトオーダーとキャストの話が出てこない？
486:デフォルトの名無しさん
12/02/09 01:11:51.86
kwsk
487:デフォルトの名無しさん
12/02/09 23:29:02.94
>>475-476 はセンスあるね
エンディアンの説明がおかしい他はいい線いってる。
時系列を変えてるのはわかりやすさのためだろ
488:デフォルトの名無しさん
12/02/10 00:57:08.24
TCP/IPの立場から考えればリトルエンディアンは十分天邪鬼だろ。
Intel CPUはリトルエンディアンだが
整数値を小さな型にキャストしようとする時
先頭アドレスを変えずに読み込みを途中で打ち切るだけで済む。
ビッグエンディアンだとスライドさせないといけない。
その分リソースを食う。
でも数値をどこかで切り捨てたい時とか上から順にダンプかけたいときは
メリット・デメリットが逆になる。
円記号問題の根底はJIS X 0201というよりISO 646各国版の普及にあって、
もっと世界的なもんじゃないのか？ トライグラフとか。
誰か詳しい人解説頼む。
489:デフォルトの名無しさん
12/02/10 08:33:56.11
トライグラフはEBCDICでもC言語を書けるようにしたものだから、あまり関係ない。
490:デフォルトの名無しさん
12/02/10 21:48:22.40
えっ？
491:デフォルトの名無しさん
12/02/11 01:09:06.04
ビッグエンディアンがマトモだと信じているバカはプログロマー止めた方がいい
492:デフォルトの名無しさん
12/02/11 08:38:33.85
なんで？
ワード長の拡張で、対応がずれる、以外のディスアドバンテージがあるならどうぞ。
493:デフォルトの名無しさん
12/02/11 09:53:05.21
どう考えても下位ビットが下位アドレスに格納されるリトル園ディンのが自然じゃね?
ビッグエンディアンは奇数アドレスアクセスとかできないでしょ。
GIF画像の圧縮みたいな可変ビット長データの連続してパッキングは、ビッグエンディアンじゃやってられない。
デメリットは「ビットの上位の方向とバイトの上位の方向が逆」に尽きる。
494:デフォルトの名無しさん
12/02/11 10:07:27.29
こうして小人さんたちの戦いは続くのであった。
495:デフォルトの名無しさん
12/02/11 10:10:47.68
まともなビッグエンディアンのアーキテクチャなら、ビットにアドレスが付く命令でも、
MSBがアドレス0だよ？
ビットアドレスが2の冪と対応してない、とは言えるけど、直感的でない、以外に問題ある？
496:デフォルトの名無しさん
12/02/11 10:21:38.52
1バイト内のビットアドレスじゃなくてメモリ(バイト)アドレスのことだろ。
4バイト整数12345678hの上位バイト12が上位メモリアドレス3に書かれるのがリトル。
4バイト整数12345678hの上位バイト12が下位メモリアドレス0に書かれるのがビッグ。
FFhに1足して上位桁に繰り上がったら、より下位のアドレスが変わるなんて変と思わないの?
497:デフォルトの名無しさん
12/02/11 10:31:03.80
アドレスが大きい方が下位と思えばどうということはない。
498:デフォルトの名無しさん
12/02/11 10:41:26.87
二つ前のレスも読めないなんて、
こういうバカがビッグエンディアンを設計したんだろうな
499:デフォルトの名無しさん
12/02/11 10:49:46.08
UTF-8は上位ビットが下位アドレス側に格納されるから、設計者は馬鹿だし、
リトルエンディアン信者は当然使わないよなw
500:デフォルトの名無しさん
12/02/11 11:02:53.62
どうやら自分以外は全て馬鹿病の患者が、リトルエンディアン凄い、偉い、と吠えてるだけのようですねw
準TADのTRONコードでも使ってろw
501:デフォルトの名無しさん
12/02/11 11:44:58.61
>>388
考えたのはＭ＄だからな。
502:デフォルトの名無しさん
12/02/11 11:48:27.56
MS叩きとか、いまどき流行らんわ
503:デフォルトの名無しさん
12/02/11 11:51:29.54
>>499
cpuがメモリに直接ワードアクセスする時のメモリイメージの話と、
バイトオリエントにシリアライズしたutf-8の話を一緒にするのはいくないぜ
504:デフォルトの名無しさん
12/02/11 12:13:02.50
>>501
いやほんとbomのおかげで助かるわ。
utf-8とその他のコードをほぼ確実に判別できる
505:デフォルトの名無しさん
12/02/11 20:26:42.27
>>504
utf-8なのにBOMって
506:デフォルトの名無しさん
12/02/11 21:38:11.32
>>505
何か問題が？
UTF-8のシグネチャーとして大活躍じゃないか
507:デフォルトの名無しさん
12/02/12 02:20:34.14
名前が良くないな。
援交ディングスキームシグネチャー
これでおk
508:デフォルトの名無しさん
12/02/12 02:52:52.82
異体字セレクたん
みたいだな
509:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/12 11:27:09.36
よくありません
511:デフォルトの名無しさん
12/02/12 12:25:31.41
why?
512:デフォルトの名無しさん
12/02/12 15:56:41.47
U+FEFFはBOM限定になったような
513:デフォルトの名無しさん
12/02/12 23:11:21.56
既存の文書の存在は認めないのですね
514:デフォルトの名無しさん
12/02/12 23:28:04.18
はい
はい
515:デフォルトの名無しさん
12/02/13 00:47:58.80
>>512
ソースｷﾎﾞﾝﾇ
516:デフォルトの名無しさん
12/02/13 12:43:00.82
URLﾘﾝｸ(www.unicode.org)
のU+FEFFで、non-breakingは代わりにU+2060を使ってね、と。
URLﾘﾝｸ(www.unicode.org)
のU+2060で、BOMの曖昧さを無くす為に、と。
その方向で行こうね、位の意味合い？
517:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/14 13:05:58.68
なるほど。やっと理解しました。ありがとう。
521:デフォルトの名無しさん
12/02/14 17:43:30.45
URLﾘﾝｸ(www.unicode.org)
> kHanyuPinyin 10760.010:g�i
文字化けワロス
522:デフォルトの名無しさん
12/02/19 00:37:27.03
今来た俺に違いを3行で教えてくれ
523:デフォルトの名無しさん
12/02/19 01:31:55.27
Unicode・・・文字集合
UTF-8・・・文字表現
です
524:デフォルトの名無しさん
12/02/19 01:37:04.34
>>523
ほう、ではUnicode 6.0のどこに「Unicodeが文字集合の一つ」と
書かれているのかね？
525:デフォルトの名無しさん
12/02/19 01:40:16.48
3行オーバーしたので答えられません。
自分でぐぐってください。
526:デフォルトの名無しさん
12/02/19 01:42:59.62
仕様のどこと訊かれてググれと答える奴は
プログラマーに剥いていない
527:デフォルトの名無しさん
12/02/19 01:47:33.04
ハゲは結構多いよ
528:デフォルトの名無しさん
12/02/19 01:49:36.68
プログラマーの童貞率、アスペ率は異常
529:デフォルトの名無しさん
12/02/19 01:57:06.64
細かいことにこだわらない奴はプログラマー向いてない。
向いてない人「ちょっとくらいいいでしょ？多めに見てよ」
コンピュータ「はあ？」
530:デフォルトの名無しさん
12/02/19 02:11:33.76
そもそも「文字表現」ってなんだよ。ちゃんとした用語使えよ。
531:デフォルトの名無しさん
12/02/19 02:23:21.28
文字表現は文字表現だよ
(T-T)悲しい
(^-^)うれしい
こんなのが最近たくさん追加されてるだろ
532:522
12/02/19 02:54:14.52
おいおい、2スレ目にもなってケツ論出てないのかよ
533:デフォルトの名無しさん
12/02/19 15:37:07.51
>>523
痴呆があらわれたか
534:デフォルトの名無しさん
12/02/19 22:52:12.18
Unicode=UTF-8
一般人に違いなどわからんからこれでよし
535:デフォルトの名無しさん
12/02/19 23:03:51.63
いいわけないだろカスが＾＾
536:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/20 18:09:07.05
ぜんぜんダメ
538:デフォルトの名無しさん
12/02/20 18:10:40.38
このスレで何度か書かれてるけど、
そろそろencoding formとencoding schemeの違いを
理解した方がいいよ
539:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/20 20:40:31.47
最初の二つを間違えた。正しくは ↓
UTF-8 (BOMなし)
UTF-8 (BOMあり) ←MSの「UTF-8」
541:デフォルトの名無しさん
12/02/20 23:14:05.93
そもそもBOMってMSの拡張じゃないの？
Unicodeにそんな仕様はいってるの？
542:デフォルトの名無しさん
12/02/21 00:42:33.77
入ってますがな。
なければどんなに幸せだったことか…
BOMのない世界にforkしたい。
543:デフォルトの名無しさん
12/02/21 04:01:27.70
無くて困ったことはあるが、
あって困ったことはありませぬ。
544:デフォルトの名無しさん
12/02/21 04:24:21.16
BOMあるとshebangが正常に動作しない
545:デフォルトの名無しさん
12/02/21 05:19:27.61
そのファイルだけBOMとれば？
文字コード不明なファイルを読み取ろうとするシバンはウンコ(・∀・)ノ●。
日本語のパスはどうすんだよ。
546:デフォルトの名無しさん
12/02/21 06:46:27.45
BOM が MS拡張とかどんだけ……
まだ ISO-10646 が正式な規格になる以前からありますがな。
547:デフォルトの名無しさん
12/02/21 17:29:35.79
>>537
えーなんでダメなんだよ？これjavaのエンコードライブラリそのまんまなんだぜ？
548:デフォルトの名無しさん
12/02/21 20:08:10.74
>>547
JavaはBOM周りの処理のバグを認識しつつ
バグを永久に直さないことに決定済みだろ
『マイクロソフトが追加した規格』が『おJavaの認識する名前』で
BOMがMS独自という誤った記述が無ければおけ
549:デフォルトの名無しさん
12/02/21 22:38:40.98
>>544
shebangに関して言えば、
shebangを読み取るプログラムが
Unicodeに対応していないというべきだろうね。
たぶん、UTF32で書かれたshebangも読み取れないはず。
550:デフォルトの名無しさん
12/02/21 22:45:12.38
>>543
無くて困ったことは皆無ですが、
あって困ったことはいやほどあります。
551:デフォルトの名無しさん
12/02/21 22:52:15.54
>>550
無くて困ったというのは文字コードが明確でなかったと想像できるけど、
あって困ったというのは、具体的にどんなこと？
552:デフォルトの名無しさん
12/02/21 23:04:12.52
>>551
上にあるけどshbangが通らないとか(頻発するので慣れた)、
ビルドが通らないとか(頻発するので慣れた)、
SQLの実行に失敗するとか(多数のDDLの実行途中だったのでリカバーに泣いた)。
553:デフォルトの名無しさん
12/02/21 23:09:04.25
ああ、あと複数のファイルをcatで繋いだら境目にゴミが混じったってのもあった。
554:デフォルトの名無しさん
12/02/21 23:12:44.31
あるテキストの改行が
Cr
CrLf
Lf
の
三つが混ざっちゃうことあるの?
555:デフォルトの名無しさん
12/02/21 23:14:57.14
>>551
単なるバイトストリームとして扱えなくなるケース。
556:デフォルトの名無しさん
12/02/21 23:19:30.60
BOMが認識できないバギーなコンパイラはともかく、catは違うような。
テキストファイルをバイナリで結合することが間違ってると思う。
結合するファイルの文字コードが違ってたら破綻するし、
ISO-2022はそもそもバイナリ結合できなくね？
557:デフォルトの名無しさん
12/02/22 09:08:20.78
>>556
>>553, >>555 は、BOM なし UTF-8 ならば cat で連結できる、って話じゃないの？
別なコードの話を持ちだしても意味ないと思う。
558:デフォルトの名無しさん
12/02/22 09:10:14.09
>>556
＞バギーなコンパイラ
言いがかり。
そういうことがないようにUTF-8を使うのに
BOMがあるだけでパー。
＞結合するファイルの文字コードが違ってたら破綻
同じUTF-8だけどな。
BOMがあるだけでパー。
559:デフォルトの名無しさん
12/02/22 09:28:36.68
utf-8対応をうたうならbomを認識できなくてはならないのに
僕のＫＵＳＯコンパイラはダメなんです。と言われてもなあ。
取り敢えずＫＵＳＯコンパイラユーザーにデメリットが有るのはわかったw
560:デフォルトの名無しさん
12/02/22 09:34:37.56
catでbomが困るなんて、
「テキストに日本語を書くと様々な問題を起こすので日本語の使用はデメリット」
とか
「csvにヘッダー行を書くとcatできない問題があるので書かないようにしている」
ってのと同レベル
561:デフォルトの名無しさん
12/02/22 13:10:05.23
>>559
BOMさえなければ、とくにUTF-8に
対応することがそもそも不要。
バギーでもクソでもない。
UTF-8原理主義者は面倒くさいな。
562:デフォルトの名無しさん
12/02/22 14:07:48.03
バイトオーダーという概念がないUTF-8でBOMとはこれいかに？
563:デフォルトの名無しさん
12/02/22 14:21:41.35
仕様に従っているかどうかの話と
仕様自体の妥当性は別の話。
utf-8安置は頭が悪いな
564:デフォルトの名無しさん
12/02/22 14:25:08.95
うにコード安置はいるがutf-8安置はいるのだろうか？
565:デフォルトの名無しさん
12/02/22 15:03:18.48
ファイル名に日本語を使ってはいけないとか、メールのタイトルに日本語を
使ってはいけないというのは、UNIXの伝統的な掟です。
LinuxはUNIXに憧れているので、UNIXの掟を忠実に守ります。
掟を守るのは大事なことです。
UTF-8を許せば日本語を使う馬鹿が出てきますよ。
566:デフォルトの名無しさん
12/02/22 15:03:29.36
UTF-8は、ASCII上位互換コーディングシステムとして設計された。
バイトストリームとして扱えば、プログラムがそのまま使えるように。
Ken Thompson先生が。Unicodeの外の世界で。
だからUnicode.orgがUTF-8にもBOMを付けるのは味噌をつけてしまったようなもの。
ただ既にBOMがあるのだから、当然の帰結ではあるのだが。
もともとのUnicodeの考え(wide character主義)とUTF-8は乖離しているから、
こういう残念な状態になってしまった。
567:デフォルトの名無しさん
12/02/22 15:06:40.21
>>565
パス名といえば、例えば、
"￥Users￥漢字名さん￥ドキュメント"
"漢字名さん"
"ドキュメント"
それぞれにBOMが付くとパス名処理がすごく面倒になる。
Unicode互換の処理系を名乗るにはやらないといけないけど、
そういうOS、ミドルウェアは未だ存在しない。
568:デフォルトの名無しさん
12/02/22 15:18:27.13
大体BOM付きとか滅茶苦茶不合理じゃん。
"a" だけで何バイトだよ？
旧来のBOM無しUnicodeを新しいUnicodeとして制定しなおしましょう。
569:デフォルトの名無しさん
12/02/22 15:18:31.69
>>567
だからこそ許してはいけないのです。
ファイル名やメールの件名に日本語を使ってはいけません。
570:デフォルトの名無しさん
12/02/22 15:19:17.81
さあ、早くEF BB BFを削る作業に戻るんだ。
571:デフォルトの名無しさん
12/02/22 15:20:33.65
>>568
それは思い上がりですね。
ASCIIだけで充分です。
572:デフォルトの名無しさん
12/02/22 15:20:40.10
NotePad BOM付きしか認識しない。
UNIX系 BOM無しを前提にしている。
やっぱM$の陰謀以外考えられないわけだが。
573:デフォルトの名無しさん
12/02/22 15:21:39.18
>>571
ならば、おまえだけは日本語で書き込むなよ。
574:デフォルトの名無しさん
12/02/22 15:28:41.23
kokoha tanoshii intaaneto desune
575:デフォルトの名無しさん
12/02/22 15:29:14.05
>>573
俺はUNIXもLinuxも使っていないのでメールの件名に日本語を使うし、
ファイル名にも日本語を使います。
HTMLメールが送られてきたからと言って怒ったりしません。
576:デフォルトの名無しさん
12/02/22 15:35:24.27
571 名前：デフォルトの名無しさん ：2012/02/22(水) 15:20:33.65
>>568
それは思い上がりですね。
ASCIIだけで充分です。
>>575
だからおまえは日本語でこの掲示板に書き込む権利は一切無いの。
577:デフォルトの名無しさん
12/02/22 15:41:57.47
>>576
いえいえ、俺はUNIXもLinuxも使わないので歴史的に日本語OKなのです。
ご心配には及びません。
578:デフォルトの名無しさん
12/02/22 15:42:52.80
nanda tadano baka dattaka
579:デフォルトの名無しさん
12/02/22 16:46:17.18
>>567
Unicode規格のencoding formとencoding schemeの説明を読み直してこい
フォルダー名にbomが付くとかあり得ないから
580:デフォルトの名無しさん
12/02/22 16:51:22.56
asciiとかどれだけ可搬性のないのものを持ち出すんだよ。
@とか[とかは機種依存文字なのを知らんのか最近の若いモンは。
581:デフォルトの名無しさん
12/02/22 16:57:58.84
>>580
8bit目を立てるのはマナー違反です。
582:デフォルトの名無しさん
12/02/22 17:18:50.84
>>579
何言ってるかさっぱりわからん。
パス名はメモリ上のデータに限られてると限定しているわけ？
583:デフォルトの名無しさん
12/02/22 18:05:31.10
>>572
NotePad は BOM なくても UTF-8 を認識するよ。
でも保存するときに強制的に BOM がつくのが問題。
Unix でなくても、たとえば文書のヘッダやフッタを別のテキストファイルから
include してくるというのは、よくある処理だと思うけど、そういう場合に、
いちいち BOM の処理が必要というのは不合理。
字数とかワードラップとかの処理が必要な場合は仕方ないけれど、そうでない
場合はバイナリとテキストで同じプログラムが使えるようになっているのが望
ましい。
584:デフォルトの名無しさん
12/02/22 18:11:47.88
>>582
Unicode規格ではEncoding FormにBOMの概念は無いんですよ。(ここらへんはRFC 3629と定義が違う)
Windowsのフォルダー名はEncoding SchemeでなくEncoding Form単位で読み書きするので、
フォルダー名にBOMが入ることはないです
585:デフォルトの名無しさん
12/02/22 18:22:59.79
>>583
>たとえば文書のヘッダやフッタを別のテキストファイルから
>include してくるというのは、よくある処理だと思うけど、そういう場合に、
MS Word文書をバイナリで結合したら読み取れませんでした。てのと同レベル。
バイナリデータを挿入するんでなく、「テキスト」を挿入するよう見直した方がいい。
ISO/IEC 2022だって二つのファイルをバイナリで結合したら壊れるだろ
586:デフォルトの名無しさん
12/02/22 18:31:25.66
>>580
ASCIIの7ビット文字は、現代で現実的に
充分ポータブルだろ。
どのあたりを心配してる？
587:デフォルトの名無しさん
12/02/22 18:34:04.47
>>586
∩＿∩
／ ＼ ／＼
| （^）=（^） | 人人人人人人人人人人
| ●_● | ＜ BOM否定派に対する皮肉だろ＞
/ // ///ヽ ＜言わせんな恥ずかしい＞
| 〃 ------ ヾ | ＹＹＹＹＹＹＹＹＹＹＹＹＹＹ
＼＿＿二＿＿ノ
588:デフォルトの名無しさん
12/02/22 20:32:33.68
>>584
フォルダ名が外からもたらされたら、
>フォルダー名にBOMが入ることはないです
なんて課程は全くできないけど?
589:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/22 22:20:02.08
> 外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、
> BOMを取り除いた形で
こういう処理をユーザがしないといけないって話なんだけど？
591:デフォルトの名無しさん
12/02/22 22:49:40.36
話がずれてないか？
もとはパス名処理が大変と言う567に対し、
文字列になってる時点でBOMは無いので単純だというのが579。
バイナリを文字列に変換するのにBOM処理は当然必要なんだけど、
それは567の「パス名処理が大変」「実装が存在しない」とは違う話。
592:デフォルトの名無しさん
12/02/22 23:09:53.07
BOMっていうのはファイルにしか存在しないものだよ。
BOM付きの文字列を半分に分けたらどうする？
前半の文字列にはBOMがついて、
後半の文字列にはBOMがついてない？
それともわざわざ付けると思う？
BOMが存在するのは外部リソースのみ
それをUNICODE文書として読み取った時、
BOMは消さないといけない。
だから、APIに渡す文字列がBOM無しなのはアタリマエのこと。
593:デフォルトの名無しさん
12/02/22 23:11:12.92
プログラマが頑張らないといけない実装しかないから、
パス名処理が大変なんでしょ？
> 文字列になってる時点でBOMは無い
「文字列になって」
この定義自体が難しいから、
プログラマが何も気にしないでも問題が起きない実装はないわけだ。
そもそも利用者のレベルでも問題が起きうる。
594:デフォルトの名無しさん
12/02/22 23:12:42.87
>>592
> BOMっていうのはファイルにしか存在しないものだよ。
外部リソースならどんなものにも付く可能性がある。
595:デフォルトの名無しさん
12/02/22 23:22:35.82
>>593
> 「文字列になって」
> この定義自体が難しいから、
簡単。バイナリではなく文字列として解釈できる準備ができた時。
それは文字列型に代入した時や、
UTF8フラグなんかをつけた時。
596:デフォルトの名無しさん
12/02/22 23:23:34.45
そもそも「ファイル」っていう概念をちゃんと>>592が分かって書いてるのかどうかも怪しい
597:デフォルトの名無しさん
12/02/22 23:27:15.21
UNIXでいう「ファイル」だけど？
598:デフォルトの名無しさん
12/02/23 00:11:05.68
そもそもBOM付きデータは「バイナリ」であって「テキスト」ではない、と考えてる。
「テキスト」は純粋に「文字列」を表現する要素のみで構成されたものであるべき。
599:デフォルトの名無しさん
12/02/23 00:44:37.73
バイト列だから順序が必要なんじゃろ？
整数列だから順序が必要ないんじゃろ？
それがエンコードスキームとエンコードフォームを分けた由来じゃろ？
Unicodeのエンコードフォームでは文字列は数値列だから、ひとつの文字はひとつの数値として扱われる。
しかしこれが物理的にコンピュータ上で扱われるとき、
コンピュータはその数値列を一つのバイト値として扱えない。
つまり、一つの文字は複数のバイト列になる。
だからバイト列に順序が必要になる。
一方、UTF-8はいずれの場合もバイト列として扱う。
文字列はバイト列であるので順番が必要ない。
という話じゃなかったっけあはん大陸。
600:デフォルトの名無しさん
12/02/23 00:46:24.77
ん
＞一方、UTF-8はいずれの場合もバイト列として扱う。
＞文字列はバイト列であるので順番が必要ない。
これは「文字列もまたバイト列であるので順番が必要ない」と書くべきか＾＾；
601:デフォルトの名無しさん
12/02/23 00:52:52.91
>>565
UTF-8 許されてるなら日本語使っても良いと思う
むしろファイル名に半角 space 入れる香具師の方が
もう阿呆かと
602:デフォルトの名無しさん
12/02/23 00:53:52.69
>>594
ファイルじゃない外部リソースなんかあるのか
603:デフォルトの名無しさん
12/02/23 00:54:42.23
>>601
何がいけないんだ？
604:デフォルトの名無しさん
12/02/23 00:56:47.75
>>602
メモリ、ストリームなどなど＾＾
605:デフォルトの名無しさん
12/02/23 01:00:55.19
>>604
それって、つまり、ずーっと辿るとファイルに行き着くだろ
ファイル以外でBOMなんて付かないだろ
606:デフォルトの名無しさん
12/02/23 01:05:04.93
>>605
いやいや。
例えばリアルタイムにコード変換してる時は元ファイルにはBOMついてないし＾＾；
メモリに展開される時にBOMがつく（つかないと判別できない＾＾）
そもそもプログラム内部は論理表現なのでBOMなどというものはありえない。
これがメモリに展開される瞬間、つまり物理表現に変わる瞬間にバイト順序が必要になる。
ストリームも同じ。
607:デフォルトの名無しさん
12/02/23 01:16:51.20
>>603
だろ？
608:デフォルトの名無しさん
12/02/23 01:18:14.42
恥ずかしいスレだな
609:デフォルトの名無しさん
12/02/23 01:35:10.93
J( 'ｰ`)し ごめんね。おかあさんはじめてUnicode使ったから、ごめんね
610:デフォルトの名無しさん
12/02/23 01:40:10.04
>>606
'\0'を文字列の途中に突っ込むのと同じ話だけど。
やろうと思えば出来る。でも普通はメモリ中のデータにBOMは入れない。
くだらない話だから伸ばすな。
611:デフォルトの名無しさん
12/02/23 02:46:18.12
>>605
> それって、つまり、ずーっと辿るとファイルに行き着くだろ
アホなの?
612:デフォルトの名無しさん
12/02/23 05:51:03.86
>>593
明確だよ。
byte[]型は文字列でない。stringは文字列。
CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
CでもASCII NUL終端で扱っている時点でBOMが有るのは間違い。
UTF-16とか扱えなくなるだろ
613:デフォルトの名無しさん
12/02/23 06:10:47.12
>>601
むしろ半角スペースで動かなくなる方が殺害モノだね。
やるべきことをやってないだけ。
"c:\a b��cacls.exe" "c:��d��e f" /R "SYSTEM"
SET "PATH=c:��a b"
常にこう書けば何が渡されても破綻しない
614:デフォルトの名無しさん
12/02/23 07:36:47.91
crlf->lf
cr->lf
lf->crlf
---------------
->の意味わ?
615:デフォルトの名無しさん
12/02/23 07:41:56.77
>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
アホなの?
616:デフォルトの名無しさん
12/02/23 08:15:36.17
そもそもUTF-16やUTF-32は
文字に\0が含まれるのでchar[]では扱えない。
617:デフォルトの名無しさん
12/02/23 08:24:03.69
>>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
char[] == TCHAR[]
618:デフォルトの名無しさん
12/02/23 09:58:23.45
犬が混じると低レベル化するな。
619:デフォルトの名無しさん
12/02/23 10:36:35.75
また犬が来たｗ
620:デフォルトの名無しさん
12/02/23 13:52:22.90
テーブル(Unicode)とデータ表現(UTF-8)の違いじゃねーの？
621:デフォルトの名無しさん
12/02/23 13:58:47.78
>612
> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
Windowsでは#define UNICODEとしないと文字列を扱えないそうです。
622:デフォルトの名無しさん
12/02/23 14:02:47.03
>>616
いや扱える。
<stdio.h><string.h>などが文字列はnull terminate前提、
Cコンパイラも文字列リテラルが同様ってだけ。
ex.
struct UTF16String {
int length;
char data[];
};
623:デフォルトの名無しさん
12/02/23 16:55:20.64
MessageBoxA と MessageBoxW の違いも判ってなさそう出汁
624:デフォルトの名無しさん
12/02/23 20:02:43.63
Shift_JISは常にビッグエンディアンだけど
UTF-16はBEとLEがあるクソ仕様、SJISとCP932の問題よりさらに酷い
おまけにサロゲートペアのせいで何が16なのかと言うレベル
バイトストリームとしてはBEに限定して
APIなどではuint16_t*なりwchar_t*で扱えばいいのに
何故バイトストリームでBE版とLE版を用意したのかと
625:デフォルトの名無しさん
12/02/23 20:31:26.64
ネットワークバイトオーダーもJavaのデータアウトプットもBEに規定されてたよな。
たしかOracleもBEだったか。16LEは確かに誰得。
626:デフォルトの名無しさん
12/02/23 21:06:35.37
同じchar[]でもバイト列と文字列ではセマンティクスは別物になる
ファイル or メモリ、char[] or TCHAR[]
重要なのはデータソースでも型でも無く、データの意味そのもの
同じintでも電圧の変数に電流の値を代入して良いわけがなく
同じstringでも通常の文字列とhtml文字列を混同すればxssに一直線だ
内部表現は[文字符号化方式]でなく[符号化文字集合]と考えるのが適切
バイナリとして読み込んだUTF-16文書のバッファ(文字符号化方式)のポインタを
wchar_t*(符号化文字集合)に単純キャストするような荒業でも動作する環境はあるが
wchar_tが4バイトの処理系ではそうはいかない
627:デフォルトの名無しさん
12/02/23 21:42:14.43
何でキチガイが湧いてるの？
628:デフォルトの名無しさん
12/02/23 21:46:52.94
なんでレッテル厨が湧いてるの？
具体的な反論するのが怖いの？
629:デフォルトの名無しさん
12/02/23 21:59:21.69
>>624
>Shift_JISは常にビッグエンディアンだけど
「Ａ」は82h 60hという2バイトであって、3260h(33376)ではありません。
>>621
長さとペアでバイナリデータを保持するcharと、ヌル終端前提のTCHARを区別しろってことでしょ。
TCHARがcharかwchar_tかは関係無い。
>>626の言う「重要なのはデータソースでも型でも無く、データの意味そのもの」を少しは理解しな
630:デフォルトの名無しさん
12/02/23 23:09:37.18
文字集合JIS X 0208の Ａ : コードポイント3区33点(3-33)
→ JIS X 0208の符号化方式Shift JISでは 0x82 0x60 と表現
→ JIS X 0208の別の符号化方式EUC-JPでは 0xA3 0xC1 と表現
つまりUTF-32BEが最強
631:デフォルトの名無しさん
12/02/24 00:24:42.69
>>628
Cの時代にcharで文字列とバイナリの両方を扱って
きた人間には理解を超えているので、
相手に罵声を浴びせることしかできないんだぜ。
エンコードスキーム(バイトデータ)とエンコードフォームの
違いがこのスレで何度説明されたことか。
未だに全く理解できていないし
632:デフォルトの名無しさん
12/02/24 00:31:43.04
Unicodeはwchar_tのために作られたわけじゃねーだろ
633:デフォルトの名無しさん
12/02/24 00:41:41.68
>>631
まだ言ってるのかw
634:デフォルトの名無しさん
12/02/24 00:50:25.32
>>626
この解釈間違ってると思うんだが
誰も突っ込まないのな
635:デフォルトの名無しさん
12/02/24 00:50:38.49
>>631
Windowsのwchar_tは２バイトでutf-16で固定長じゃないんだから、
charでutf-8を扱った方がまし。
636:デフォルトの名無しさん
12/02/24 01:03:21.88
>>635
utf-8はいいけど
BOMのあり得るエンコードスキームUTF-8と
BOMの無いエンコードフォームUTF-8は
異なる概念なので区別しろよw
でないと、UTF-16BEはヌルが含まれるのでcで扱えないとか
とんちんかんなことを言い出しかねん
637:デフォルトの名無しさん
12/02/24 01:20:18.39
BOMありUTF-8使ってるのって日本だけなん？
638:デフォルトの名無しさん
12/02/24 01:21:59.80
>>634
頼んだぞ
639:デフォルトの名無しさん
12/02/24 01:24:48.19
>>637
Windowsのメモ帳が付けるというのに、
どうしてそんな考えに至ったのか知りたい
640:デフォルトの名無しさん
12/02/24 02:40:35.01
>>636
メモリ上にはUnicode encoding formしかないと勘違いしている人？
641:デフォルトの名無しさん
12/02/24 06:13:03.23
それだとファイルを読み込むことが不可能になってしまいます
読み取ったバイナリデータをテキストとして処理する前に
エンコードフォームに直すと言うことでは?
642:デフォルトの名無しさん
12/02/24 21:05:08.82
ヌル終端の文字列って超使われてるけどさ
struct{char* begin, char* end}の値渡しか、その構造体へのポインタを渡すようにした方が良かったよね
今更ってレベルじゃないけど
643:デフォルトの名無しさん
12/02/24 21:23:26.59
struct{char* begin, int len)の方がいい。
644:デフォルトの名無しさん
12/02/24 21:27:00.18
struct{char*end;chars[];};の方がいい
645:デフォルトの名無しさん
12/02/24 21:32:30.58
>>642
最初はstructなんてなかったんだよ。
そこまで斜めだと後出しですらないだろ。
646:デフォルトの名無しさん
12/02/24 21:34:20.57
>>643
Pascalがそれ。
実装によってはnull characterも持てた。
けど勝利したのはCのシンプルさ。
同じデータ構造(char [])でバイナリも持てる。
647:デフォルトの名無しさん
12/02/24 21:35:14.65
そのせいでCはUTF16や32に
特殊な型を持ち出さないと対応できなくなった。
648:デフォルトの名無しさん
12/02/24 21:36:10.43
それどころかstrlenやstrcpyでも
UTF16やUTF32専用の関数が必要になった。
649:デフォルトの名無しさん
12/02/25 00:27:19.29
>>643
intじゃポインタで表現可能な範囲を持てる保証が無いよ
実際殆どの64bit環境(LP64やLLP64)でintでは4Gの壁が出来上がる
せめてptrdiff_tにしないとね
>>645
マジか、struct無かったのか・・・
でも斜めではなくね？STLでもbegin(),end()が基本だしさ
650:デフォルトの名無しさん
12/02/25 00:36:53.09
>>649
昔の話だとして…
Cの前身はT *とintの区別なかったんだよ。
型指定がなくて、型は名前のついてないWORD型しかない。
今で言うところのILP16で。(Integer, Long, Pointerが16bit)
だからその影響でCでもしばらく型指定なしの変数宣言するとintだった。
651:デフォルトの名無しさん
12/02/25 00:53:57.92
>>649
ならsize_tでいいだろ。
strlenの戻り値の型だ。
652:デフォルトの名無しさん
12/02/25 08:59:27.50
>>650
cの前身っていったら1971年？
そんな時代に16ビットが普及してたはずもないのだが
653:デフォルトの名無しさん
12/02/25 11:01:25.83
パソコンの16ビットはそりゃそうだろうけど、
ミニコンの16ビットは70年代に16ビットは普通では？
654:デフォルトの名無しさん
12/02/25 11:05:36.97
BCPLはPDP-7だっけかな。
と思って調べたらまさかの18ビット
655:デフォルトの名無しさん
12/02/25 11:06:15.46
DECという会社があったこと #平成生まれが知らないことを挙げていこうぜ
656:デフォルトの名無しさん
12/02/25 13:22:49.45
ここは加齢臭漂うスレとなりました。
657:デフォルトの名無しさん
12/02/25 23:22:28.04
ファブリーズしても全然ダメなぐらい
658:デフォルトの名無しさん
12/02/26 15:47:27.68
CrCrLfはWindowsだと1回の改行でMacだと2回の改行?
659:デフォルトの名無しさん
12/02/26 16:11:51.66
CR/CRLF/LF が混在してるテキストなんて基本的に想定外という扱いでいいだろJK
660:デフォルトの名無しさん
12/02/26 19:02:49.96
>>658
ソフトラインブレークは発狂の元
661:デフォルトの名無しさん
12/02/26 19:09:25.17
CRとLFの連続を改行として扱えばいい
空行が無くなるが
662:デフォルトの名無しさん
12/02/27 06:35:19.89
>>658
CrCrLfはWindowsだと不正な改行。
なのでそれを受け入れたい場合は、どう処理するかをソフトウェアの仕様で
決めなければならない。
663:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/02/27 13:18:33.44
WIN/UNIX/MACごちゃまぜのソフトでWINのクライアントから編集するたびに改行が倍になってくやつがあったな
665:デフォルトの名無しさん
12/02/27 15:26:35.50
CRのみは歴史的文書しかないから、特殊なアプリ以外は無視して問題なし。
666:デフォルトの名無しさん
12/02/27 16:24:28.49
>>659
一方Microsoft Excelさんは平然と混ぜてくるのであった
CSV形式で保存すると行の区切りにCRLFを使用するけど
セル内に改行がある場合は""で囲った上でLFのみで出してくる斜め上仕様
そうした理由は分からんでもないけど・・・
667:デフォルトの名無しさん
12/02/27 18:18:57.20
自分が作る場合はこんなふうに処理している。
1. CR または LF が連続していたら、それぞれの数を数える
2. LF が一個でもあったら CR は無視してその個数を改行数とする
3. LF がひとつもなかったら CR の個数を改行数とする
4. 出力の改行を決める必要があるときは、入力の最初の改行によって決める
(入力がないときはOS依存……最近は LF 決め打ちが多いけど)
わざと混在させる必要がある場合以外、これで問題ない。
もっとも、CR のみの文書っていまだかつて見たことないが。
668:デフォルトの名無しさん
12/02/27 18:20:19.66
RFC4180ってAccessのCSVと同じだろ
669:デフォルトの名無しさん
12/02/27 19:07:55.38
RFC4180読んでみた
2005年公開でこの内容ってことは単にMS Officeに合わせただけか
MSの頭悪いCSVの仕様がRFCになってるとは
素直にメタ文字エスケープすればいいのに
670:デフォルトの名無しさん
12/02/27 22:26:43.04
メタ文字こそウンコ。
パーサーのことだけで読みやすさを考えてないだろ。
671:デフォルトの名無しさん
12/02/28 11:05:23.12
俺はエスケープの方が途中で改行が混じっていない分読みやすい
まぁその辺は人によるから不毛だな
あとパーサーだけじゃないぞ
ちょっとした文字の置換とかも、しやすさが全然違う
672:デフォルトの名無しさん
12/02/29 07:10:49.12
\を入力するとなんで/になっちゃうの?
673:デフォルトの名無しさん
12/02/29 16:32:24.20
なるのは君だけ
674:デフォルトの名無しさん
12/03/02 19:25:17.78
＼
675:デフォルトの名無しさん
12/03/02 19:43:07.92
∖
∖
╲
╲
＼
＼
676:デフォルトの名無しさん
12/03/02 19:43:31.69
>>675
みえる化
677:デフォルトの名無しさん
12/03/02 19:48:04.83
クイックス懐かしいな・・・
678:デフォルトの名無しさん
12/03/03 05:57:10.92
1ヶ月のケってなんなの?
679:デフォルトの名無しさん
12/03/03 07:43:55.61
箇ないし个の変形。「け」ではない。
680:デフォルトの名無しさん
12/03/03 16:13:06.06
へーへーへー。10へー。
681:デフォルトの名無しさん
12/03/03 16:41:16.18
1ヵ月のカってなんなの?
682:デフォルトの名無しさん
12/03/03 16:46:52.04
30人日の力だろ？
683:デフォルトの名無しさん
12/03/03 17:05:29.99
ヵゕかｶカ力刀
684:デフォルトの名無しさん
12/03/03 17:11:27.73
>>681 それも >>679
685:デフォルトの名無しさん
12/03/04 23:00:24.18
【
これはキーボードのローマ字入力でどのキーを押せば
686:デフォルトの名無しさん
12/03/04 23:51:46.85
消せますか？
687:デフォルトの名無しさん
12/03/12 07:21:55.87
もう面倒くさいから
1文字1MBで表現しろよ！
688:デフォルトの名無しさん
12/03/12 08:07:52.93
らめぇ、回線が壊れちゃうよぉ
689:デフォルトの名無しさん
12/03/12 15:01:53.43
原稿用紙一枚分のテキストが400MB
690:デフォルトの名無しさん
12/03/12 15:22:57.77
動画でテキストを表現ですか。
691:デフォルトの名無しさん
12/03/12 20:10:02.36
トントンツーツーは2進法なの?
692:デフォルトの名無しさん
12/03/12 20:31:58.10
文字間セパレータがあるから記号としては3つじゃないか?
693:デフォルトの名無しさん
12/03/12 21:20:31.96
∧,,∧
( `･ω･) ｳｰﾑ…？
/ ∽ |
しー-Ｊ
694:デフォルトの名無しさん
12/03/12 22:00:02.92
>>692
ストップビット２
０：1ビット
１：１．５ビット
695:デフォルトの名無しさん
12/03/12 22:01:50.36
>>694
書き直す
ストップビット：4
０：2ビット
１：3ビット
696:デフォルトの名無しさん
12/03/12 22:17:33.78
三進数
697:デフォルトの名無しさん
12/03/13 10:00:05.44
学習塾
698:デフォルトの名無しさん
12/03/13 10:02:10.36
痛い児セレクたん
699:デフォルトの名無しさん
12/03/13 23:25:06.32
やっぱり二進数だわ
トン、ツー
700:デフォルトの名無しさん
12/03/14 12:43:51.04
>>699
その様子だと、お前は次の問題が解けねぇな。
英文が成立する最低限度のキャラクタのうち、出現頻度が一番高いのは、何？
701:デフォルトの名無しさん
12/03/14 12:57:27.42
kumi
702:デフォルトの名無しさん
12/03/14 16:28:08.33
すポース
703:デフォルトの名無しさん
12/03/14 17:02:49.10
Siri
704:デフォルトの名無しさん
12/03/14 23:11:46.61
chinbo
705:デフォルトの名無しさん
12/03/16 00:03:13.48
>>700
話そらすバカ
706:デフォルトの名無しさん
12/03/27 00:05:22.70
>>705
全くそれていないんだが、それが理解できないと言うことは、
1200 8N1 とか言っても理解できんのんだよなｗｗｗ
707:デフォルトの名無しさん
12/03/27 07:50:36.57
レイヤ1と2の区別がつかないハード屋さんですね。
わかります。
しかも1200っていつの時代
708:デフォルトの名無しさん
12/03/27 13:12:53.93
ATZ
ATZ
ATDT110
709:デフォルトの名無しさん
12/03/27 15:45:33.29
年寄りの加齢臭話はいいから文字コードの話しに戻ろうぜ
710:デフォルトの名無しさん
12/03/28 09:08:44.45
>>707
お前・・・・分かるんだｗｗｗ
711:デフォルトの名無しさん
12/03/28 09:41:33.96
50歳以下は帰ってくれないか?
712:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/08 02:17:17.24
ヘボン式ってなに?
713:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/08 02:20:11.84
トイレに…
714:デフォルトの名無しさん
12/04/12 12:01:16.85
フランソワ・漏れション
715:デフォルトの名無しさん
12/04/15 04:48:40.36
ヘボン式ローマ字は、英語と親和性がたかいが、音韻学的、言語学的な日本語表記法ではない。
ドイツ語、ポルトガル語など、英語以外の言語では、発音がことなるおそれがある。
「ヘボン式ローマ字は英語の発音に準拠したので、日本語の表記法としては破綻が多い（中略）
日本式は音韻学理論の結実として、日本国内外の少なくない言語学者の賛同を得た。
しかし、英語の発音への準拠を排除した日本式ローマ字は英語話者や日本人英語教育者から激しい抵抗を受け」
ローマ字 - Wikipedia
716:デフォルトの名無しさん
12/04/15 05:43:55.65
オードリーヘッバン
717:デフォルトの名無しさん
12/04/15 12:15:22.24
ローマ字って習う必要あったのかな？
718:デフォルトの名無しさん
12/04/16 13:41:08.05
ハングルよりいいんじゃない？
719:デフォルトの名無しさん
12/04/21 23:43:35.82
↑会話の出来ないばか
720:デフォルトの名無しさん
12/04/22 05:43:04.90
住所の番号の部分を全角数字で書かせるホームページってなんなの
721:デフォルトの名無しさん
12/04/22 10:56:29.77
新聞記事で良く見るのが
ユニホーム
とか
ビルヂング
722:デフォルトの名無しさん
12/04/22 11:34:27.88
でもセーターとかミルクセーキとかは気にならない
723:デフォルトの名無しさん
12/04/22 11:48:55.63
メールは微妙
724:デフォルトの名無しさん
12/04/22 12:00:05.69
それより、
ス マ ホ
をなんとかしろ。
725:デフォルトの名無しさん
12/04/22 12:09:28.76
マスコミュ
726:デフォルトの名無しさん
12/04/22 13:51:12.05
全角URL
727:デフォルトの名無しさん
12/04/22 20:35:53.60
>>720
何なのとは？
お前が何を問題視しているのかを説明してもらおうか
728:デフォルトの名無しさん
12/04/22 20:45:02.96
このスレだとUnicode処理系とは認められないってことじゃないかね。
729:デフォルトの名無しさん
12/04/23 18:35:00.20
「千代田区一丁目」って入力させたいんだろ？ いいじゃねーか
730:デフォルトの名無しさん
12/04/23 19:54:19.70
○丁目はそこまでが町名だから許せるんだけどねぇ。
731:デフォルトの名無しさん
12/04/23 20:49:49.64
全角文字は人生を不必要に複雑化する
732:デフォルトの名無しさん
12/04/24 02:44:24.00
姓と名の間の空白を全角にするか半角にするか
プログラミングを意識したら、半角がいいとおもう（区切りだから）
実際には、全角がつかわれてもしょうがない
733:デフォルトの名無しさん
12/04/24 02:52:38.61
1桁の数字を全角にするように〝スタイルガイド〟がきまってたりする。
2桁以上を半角にする。
たとえば、新聞、雑誌など、縦書きを意識したら、何桁でも全角数字がいいとか。
734:デフォルトの名無しさん
12/04/24 10:37:30.00
なんで「縦書き」を文字コードが意識しなければいけないのだ＾＾
使っている文字フォントの縦横比が1:40000だったりしたらどうするのだｗ
全角半角という呼び方もそうだが、
文字幅は文字フォントの問題であり、文字コードの責任ではない。
って、件の本に書いてあったじゃろ？＾＾
735:デフォルトの名無しさん
12/04/24 12:24:24.96
全角半角くらいプログラム側で変換しろよと思う
736:デフォルトの名無しさん
12/04/24 21:58:39.23
>>733
縦書きで2桁は半角だろ？
平
成
24
年
737:デフォルトの名無しさん
12/04/25 17:45:04.43
>>734
Unicodeは東アジア圏の文字幅(半角/全角含む)については、その取り扱いは規定されているだろ。
Unicode Standard Annex #11
East Asian Width
URLﾘﾝｸ(www.unicode.org)
東アジアの文字幅
URLﾘﾝｸ(ja.wikipedia.org)
738:デフォルトの名無しさん
12/04/25 19:36:54.24
といっても、それは参考特性だからなぁ。フォントの横幅を必ず2桁分にしろよという約束とはちと違うし。
実際、たいていのプロポーショナルフォントでは2倍になっとらんし…。
何とかならんもんかね。
739:デフォルトの名無しさん
12/04/25 20:14:29.55
>>736
英語圏から見るとほんとカオスなんだろうなｗ
740:デフォルトの名無しさん
12/04/25 20:28:09.29
>>738
プロポーショナルフォントで1:2の関係になるわけないでしょ。
プロポーショナルフォントの意味分かってるの?
1:2にしたければ固定幅フォントを使え。
741:デフォルトの名無しさん
12/04/25 20:29:33.25
Unicodeにおけるhalfwidth,fullwidthはroundtrip conversionの
ための単なる呼び名でglyphの幅とは関係無い。
今は同じフォントでも文字幅いくつも持って切換えられるから、全角半角の
文字幅比はフォント固定でも変わる。
文字幅半分のglyphを生成したいとかはレンダリングで対処すべき問題
742:デフォルトの名無しさん
12/04/25 20:35:04.43
UnicodeのEast Asian Widthは、既存の文字コードとの互換の為に用意されているのだから、
固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。
743:デフォルトの名無しさん
12/04/25 20:56:48.08
>>742
>固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。
レンダリングで対処すべき問題ってことね。
固定ピッチフォントなんてのはUnicodeの関知する所じゃないし。
744:デフォルトの名無しさん
12/04/25 21:00:49.88
>>743
文字の特性値を見れば
全角／半角の切り分けはできるって言いたいだけだよ。
745:デフォルトの名無しさん
12/04/25 21:24:40.16
だからそれは文字コードの責任じゃないでしょｗ
最初から話が噛み合ってないねｗ
746:デフォルトの名無しさん
12/04/25 21:28:35.44
>>745
文字コードの責任だよ。
Unicodeの仕様を見てごらん。
Fullwidthと書いてあるよね？
Halfwidthと書いてあるよね。
Halfは半分という意味、Widthは幅という意味だよ。
747:デフォルトの名無しさん
12/04/25 21:31:01.29
お前の中ではな＾＾；
件の本を読めれ＾＾；
748:デフォルトの名無しさん
12/04/25 21:34:31.61
>>745
全角／半角を見分けてレンダリングする、レンダラを作ろうとする場合に、
どの文字を全角として扱って、どの文字を半角として扱うかの根拠になるのは、
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
この2つだろ。
Unicodeが文字コードの規格では無いとでも言うつもりか?
749:デフォルトの名無しさん
12/04/25 21:36:46.68
いや、だから、おまえらの勝手な仕様解釈なんてクソ以下なんだってば
俺は別にUnicodeの仕様策定者でも解釈者でもなく
単におまえらより偉い先生の書いた本の内容通りに言ってるだけなわけで
おまえらが偉いなら本書いて世間に認められてからその珍妙な説を展開してくれ
750:デフォルトの名無しさん
12/04/25 21:38:39.18
クソ本をヨイショする事しかできないなら黙ってろよ。
751:デフォルトの名無しさん
12/04/25 21:40:11.73
少なくとも糞本も書けないおまえらの珍説をありがたがるほどノーテンキじゃねーんだよ
それともここでおまえらの珍説をたかが一人の人間に納得させると何かおまえらは勝った気になるのか？ｗ
752:デフォルトの名無しさん
12/04/25 21:41:42.62
うん
753:デフォルトの名無しさん
12/04/25 21:43:41.68
べつにおまえにありがたがってもらう必要はねーよ。
勝った気になるとか何の話だ？アホか。
754:デフォルトの名無しさん
12/04/25 21:51:18.70
以下珍説またはスレタイと無関係な煽り合いで１０００まで↓
755:デフォルトの名無しさん
12/04/26 00:10:30.79
＿＿_
:／ u＼; ＿＿＿＿
;/ ノﾙ(＜)＼; ／ ;u ノ し＼
;| （＞） ＿) ＼;/ ⌒ ＼
;|::: ⌒（__ノｪｿ / 、 |
;.＼ u ´ ソ / ＾ |
;＼ , | |
,ヾ ＼_ ｎ^^- ＼ j; __／
;/ ∠＿;i ￣丶／￣ ＼
;（ ⌒） ´ ノ ＼
756:デフォルトの名無しさん
12/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:デフォルトの名無しさん
12/04/26 17:15:34.07
文字コードでなくフォントの問題であるべきって主張はいいけど、
「半角」「全角」って言葉が現実的に無視できない存在であることは理解した方がいいよ。
少なくとも半角全角を区別する文字コードが存在して
それに対応する文字がUnicodeに登録されているのは事実。
758:デフォルトの名無しさん
12/04/26 17:40:43.57
「した方が良い」と「しなければならない」を区別して話した方が良いと思うんだ
・East Asian Width参考特性が半角なら、フォントは1/2のサイズにしなければならない
・East Asian Width参考特性が半角なら、フォントは1/2のサイズにした方が良い
後者なら反対してる人は居ないんじゃないかな
759:デフォルトの名無しさん
12/04/26 18:58:59.64
仕様も読まなきゃ本も読まないアホに何言っても無駄
自分の解釈が間違ってるって認めたら死んじまうような
ペラペラのアイデンティティの上でぎりぎり生きてるような連中だから
760:デフォルトの名無しさん
12/04/26 22:41:20.21
仕様＝建前
現実＝本音
761:デフォルトの名無しさん
12/04/26 22:53:08.42
固定ピッチフォントがlegacyとかふざけるなターミナルエミュレータは現役だし将来も無くなる予定なんぞないわ、とtr11を見たときオモタ。
762:デフォルトの名無しさん
12/04/26 23:06:35.26
固定幅フォントであっても半角と全角の文字の幅比が1:2であるとは限らない。
こんなの常識。
763:デフォルトの名無しさん
12/04/26 23:26:45.82
建前「固定幅フォントであっても半角と全角の文字の幅比が1:2であるとは限らない。 」
本音「1:2にするべきだ」
764:デフォルトの名無しさん
12/04/27 05:09:05.83
一人顔真っ赤な奴がいる？
765:デフォルトの名無しさん
12/04/27 05:50:54.33
ASCIIの1文字が8x8ドットで表現されていた頃、漢字は4倍角だった。
そのうち半角全角も、ただの歴史になるだろ。
766:デフォルトの名無しさん
12/04/27 20:44:56.57
話をぶった切るけど、Unicode関係のお勧めの本ってどんなのがあります？
767:デフォルトの名無しさん
12/04/27 22:03:45.30
amazon
768:デフォルトの名無しさん
12/04/28 11:43:55.63
UTF-8にわくわしいのに香具師の意味がわかんないだけど
769:デフォルトの名無しさん
12/04/28 20:44:13.87
わくわくしいって何か楽しげだな
770:デフォルトの名無しさん
12/04/28 21:09:07.62
わくわく死？
771:デフォルトの名無しさん
12/04/29 05:40:27.80
奴（ヤツ）
ヤシ
香具師（やし）
772:デフォルトの名無しさん
12/05/03 13:16:56.46
何を言っているのかよくわからんが・・・
少なくとも半角と全角を同一視するうにコードは、市ね、
と言いたい。
少なくとも、半角と全角を同一視したうえで勝手に全角半角を切り替えるアプリ書いたぼけ、市ね、
と言いたい。
773:デフォルトの名無しさん
12/05/03 17:10:28.08
>>772
君の方こそ何を言っているのかわからないよ。
>半角と全角を同一視するうにコード
774:デフォルトの名無しさん
12/05/03 20:04:15.75
>>773
Unicode風でありながら、半角と全角の空白を同一のコードポイントを割り当てた文字コード
それが、うにコード
775:デフォルトの名無しさん
12/05/03 21:45:35.05
てか、
￥ U+00a5 を
\ 0x5C
に変換するライブラリ、市ね
776:デフォルトの名無しさん
12/05/03 23:14:36.68
>>775
それはUnicodeでなくて「Unicodeとローカルエンコードとの変換ルール」の話だと思うが、
既定でCP932変換ルール(Unicodeコンソーシアム公開のもの)でないのはＫＵＳＯだな。
オプションでCP932以外を指定できるなら可。
777:デフォルトの名無しさん
12/05/04 16:50:18.92
Altキーはなんとよめば
778:デフォルトの名無しさん
12/05/06 09:29:11.27
>>777
あらどっこいしょ
779:デフォルトの名無しさん
12/05/06 11:08:02.26
Alertキーだろ
アラート
780:デフォルトの名無しさん
12/05/07 21:09:03.92
>>777
alternateなんだからアルトに決まってんだろ！
＼アルタネーッテ／
781:デフォルトの名無しさん
12/05/07 21:31:02.38
オ・・
782:デフォルトの名無しさん
12/05/09 01:21:11.83
居る棚恥部
783:デフォルトの名無しさん
12/05/11 06:48:00.44
単にUnicodeって言ったときは
一般的にはUTF16インディアン付なんでしょ?
784:デフォルトの名無しさん
12/05/11 07:26:20.20
ねーよ。
そんなことをやるのはバカだ。
いくらたくさんいようが、バカはバカだ。
785:デフォルトの名無しさん
12/05/11 07:56:49.55
>>783
ちげーよ
単に「文字コードはUnicode」と言ったら
言ってる奴がアホなのでその意味を汲み取ってあげないといけない。
Windows意外ならBOM無しが多い。
ってかエンディアン月とか、もうアホかと
786:デフォルトの名無しさん
12/05/11 19:18:13.50
Windowsメモ帳に
Unicodeで保存する項目があるけどどんなUnicodeまでかまでわ表示されないだけど
787:デフォルトの名無しさん
12/05/11 19:32:02.13
続きは？
788:デフォルトの名無しさん
12/05/12 15:12:52.52
インディアン付とは、新たな概念ですね
789:デフォルトの名無しさん
12/05/12 17:29:03.25
ふんどし級の驚きだねｗ
790:デフォルトの名無しさん
12/05/13 05:27:44.76
インディアン嘘つかない
791:デフォルトの名無しさん
12/05/13 05:33:56.53
UTF-8:エンコードの一つ。
インディアンは付かない
UTF-16:Unicodeのインディアン付エンコード
792:デフォルトの名無しさん
12/05/13 12:09:07.66
UTF-8:USOなし
インディアン嘘付かない
UTF16:USOあり
インディアン嘘つき
793:デフォルトの名無しさん
12/05/13 13:25:10.90
ビッグインディアンに勝てる気がしない
794:デフォルトの名無しさん
12/05/13 14:33:09.62
ちんこビンビン
795:デフォルトの名無しさん
12/05/13 16:37:51.40
>>794
796:デフォルトの名無しさん
12/05/13 22:39:55.24
>>791
マジレスじゃないよね？
797:791
12/05/13 22:45:59.54
>>796
マジレスのつもりでした。
UTF-8はバイトオーダーに依存しないので
インディアン無しと掻きました
798:デフォルトの名無しさん
12/05/13 23:59:25.40
依存もなにもbyte orderなんだからbyte単位データの並び多種になってたまるかよ
799:デフォルトの名無しさん
12/05/14 00:36:19.59
おい、バイト！ オーダー取ってこい！
800:デフォルトの名無しさん
12/05/14 00:54:01.43
じわっときたが
がっかりした
残念だ
801:デフォルトの名無しさん
12/05/14 06:11:25.37
インディアン
802:デフォルトの名無しさん
12/05/14 11:09:05.25
リトルインディアン
803:デフォルトの名無しさん
12/05/14 21:49:46.07
ワンリルートゥーリル
↓
804:デフォルトの名無しさん
12/05/14 21:58:08.99
ウディタの新バージョン「ウディタ2.00」が公開されました（2011年10月27日）
「WOLF RPGエディター」とは？
・高度なRPG開発が可能な、完全無料のゲーム作成ツールです。
・雰囲気はRPGツクール2000に近い。RPGツクール2000で自作システムを作りこむ際に
不満だったところがいろいろ解消されていて、かなり自由度が高いです。ただし
その分初心者には難しいかも。すでにツクール2000で自作システムを組むのに
慣れた人やＲＰＧツクールでは物足りないけどプログラミングはちょっとという方にお勧め。
・作成したゲームは自由に配布したり、コンテストに投稿することも可能。
また本ソフトを持たない人でもプレイ可能！ファイル暗号化も完備！
■作り方しだいでパズル系やカードゲームやシミュレーションやシューティングや
アクション、RTSや他なんでも作れます。
■また他の人がネット上で公開している「コモンイベント」を組み合わせて利用すれば、
自分では開発が難しいゲームシステムも容易に実現することができます。