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や他なんでも作れます。
■また他の人がネット上で公開している「コモンイベント」を組み合わせて利用すれば、
自分では開発が難しいゲームシステムも容易に実現することができます。