[過去ﾛｸﾞ] C言語なら俺に聞け 163 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
866: (ﾜｯﾁｮｲ 7f7b-4xcB) 07/01(火)10:07 ID:O7C1rCRT0(1/2) AAS
ああついでに言っておくと、
ゆとり以前(＝俺)：内容が正しければ態度なんてどうでもいい
ゆとりZ：ボクがどんなにマヌケな間違いをしていたとしても、
優しく丁寧に教えてくれる事が絶対条件で、
優しければ内容が多少間違っていても許容される（←いやこれは俺は許容出来ねえ)
という違いだな。まあゆとりZ同士でよろしくやってくれ。
ただまあ、Qiitaのスレとかチラ見してるが、
発言の自由がある＝どんな馬鹿でも発言出来る＝間違った情報も当然発信される、なのだから、
Qiitaに正確性を求めるのは仕様的に無理なので、連中も間違ってて、
Qiitaは玉石混淆な上で、石が大量生産されるのは仕様として甘受し、玉を探すべきだとは思うがな。
とはいえQiitaが石→玉化する機構を持ち合わせられない(＝間違いを指摘する事すら出来ない)
のは上記ゆとりZ価値観の賜だから、詰んではいるが、それでも(Qiitaというサイトが)無いよりは断然いいし。
つまりだな、お前らゆとりZは「上から目線ガー」とか一々やってるから駄目なのであって、
「相手」(今回は859)に向き合う気がないから、
Qiita等の「一方的に発信するだけ」のツールは断然相性がいいが、
そこで「双方向な議論」とかはまるで出来ないんだと思うぜ。
859にとって困るのは、「上から目線」ではなく、「間違いを指摘してもらえない」事だろ。
(ただこれがゆとりZに取っては違うらしいので俺にはどうにも合わないが)
867: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)10:57 ID:M5z4vIa80(5/10) AAS
リンクは以下の方がよかったかも
外部ﾘﾝｸ[html]:hydrocul.github.io
> Grapheme cluster の境界定義
> CR の次に LF が続く箇所は境界にならない
これだとCRLFは一文字扱いだから、utf-8の0x7f以下だけ使っても(厳密には)asciiとは違うって事か？
なんで一々仕様を無駄に変更するのだ？という気はするが、
見てる限りunicodeって自然言語学者が策定してる仕様で、プログラミングのし易さなんてまるで考慮して無いな
868(1): (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)16:58 ID:W1sziXWKM(1/5) AAS
PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
C言語は指示しない限りは何もしないから、むしろ安全。
860は、馬鹿だから理解できない。
869: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)17:04 ID:W1sziXWKM(2/5) AAS
中途半端に自動化しようとしていることが脆弱性の温床になる。
詳細な仕様を書かないで「こういう場合にはこうすれば安全ですよ」
みたいなのが結構危ない。
なぜ、そうするのか。その関数は厳密に何を行っているのか。
「簡易言語」には、そういう情報が欠落していることが多い。
870: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)17:07 ID:W1sziXWKM(3/5) AAS
フレームワークも危険だ。
「完成品」として何もカスタマイズしないで使っているなら、安全かもしれない。
ところが、「プラグイン」と呼ばれているものを組み合わせたり、
独自にカスタマイズしようとすると、とたんに危険になる。
なぜなら、仕組みが分かりにくく、ソースが巨大で解読しにくいことが多いからだ。
特に問題なのはオープンソースのフレームワークだ。
ソースが汚いものが多いから、それが原因で理解が難しくなり、脆弱性が入り込む。
871: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)17:10 ID:W1sziXWKM(4/5) AAS
860は、物事の理解が甘い。
自分が馬鹿なことに気付いてない。
5chだけで偉そうにしている馬鹿。
872(1): (ﾜｯﾁｮｲ c3ef-OGY2) 07/01(火)17:12 ID:rc7NgUjs0(1) AAS
自己紹介ですか？
873: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)17:15 ID:W1sziXWKM(5/5) AAS
>>872
おまえは、自覚が無い馬鹿だ。
874(1): (ﾜｯﾁｮｲ c379-SOZQ) 07/01(火)17:41 ID:0aieN+8C0(2/2) AAS
全然違う話になったぞ？？？
875(1): (ﾜｯﾁｮｲ 7748-ar6z) 07/01(火)19:57 ID:4pZHV5xo0(1/4) AAS
けどさ
今のWindowsって内部的にはUTF16LEなんだよな
それをアプリ側に合わせてマルチバイトに変換したりしてるわけで
876: (ﾜｯﾁｮｲ 5ffc-4xcB) 07/01(火)20:03 ID:M5z4vIa80(6/10) AAS
>>874
まあ859もゆとりZだったというオチだよ。
見えてた展開ではあったが、放置するのも問題かと思って最低限のツッコミを860でしたつもりだったが、
ゆとりZが釣れまくってどうにもならねえ。脱線しすぎ。
5chにはコミュ障が多いのでついでに解説しとくと、
859のテイ、何だかよく分からん独り言は、ゆとりZ特有のムーブで、
・質問して答えてもらえないと傷つくし、
・議論提起してボコられたら嫌だし、
・何だかよく分からん独り言にしとけば、どういう展開になっても逃げられるし！！！
って事で、傷つかない為に予防線張りまくりの戦術、連中なりの「コミュ上手」な手法らしい。
いやいや、お前ら一々メンドクセエわ。
877(1): (ﾜｯﾁｮｲ 5ffc-4xcB) 07/01(火)20:04 ID:M5z4vIa80(7/10) AAS
>>868
> 860は、馬鹿だから理解できない。
お前がどう思おうと自由だが、さすがに俺よりお前の方が賢いと思う奴は居ないと思うぞ。
まあこれも862と同様のゆとりZ特有ムーブで、「ばかにされた！！！」事が内容に勝ってる。
いやいや、お前がそもそもマヌケな事を言わなければ防げた展開だろ、とはならない。
> PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
> 特に問題なのはオープンソースのフレームワークだ
少なくとも今のお前より理解してる連中が作ってるから、
今のお前の知識と知能で作った物よりは安全だろうよ。
ついでに言うとこれもゆとりZの特徴で、
心根で他人を見下してるからこんな発言になるし、また、
心根で他人に対してマウントを取りたい、上から目線で話したい、と思ってて、でも我慢してるからこそ、「上から目線」に過敏になる。
オープンソースにゴミが多いのも事実としても、
同じ物を作るのはかなり大変なのも、結果的に生き残ってる物はそれなりに鍛えられた品質なのも事実。
各言語処理系なんて相当の人数が関わって改善された結果だから、同等以上の品質の物を作るのは事実上無理だと思うけど。
ゆとりZは「謎の心根の『上から目線』」がありすぎ。
それでいて「表面的な『上から目線』」にゼロトレランスなのはちゃんちゃらおかしいのだが、まあ連中はここら辺を矛盾に感じないらしい。
連中は表面的なコミュニケーションしか出来てないってのがこの辺から分かる。
878: (ﾜｯﾁｮｲ 7f7b-4xcB) 07/01(火)20:14 ID:O7C1rCRT0(2/2) AAS
>>875
それは正しいよ。
サロゲートペア以前はutf-16が各国文字を固定長で扱える(多分)唯一のエンコードだったから、
ローカライズ前提のwindowsの内部コードをutf-16で作るのは正しい。
逆に言えば、サロゲートペア以前はutf-32なんて使う意味なく、実際使われてもなかったはず。
今固定長に拘るならutf-32しかないけど、Rustがutf-8を選択したのは、utf-32は使い物にならないという判断のはず。
(まあゆとりZなら「俺の判断の方が正しい」となるのだろうが、
俺の心根はそこまで「上から目線」ではないので、Rust陣営の判断はそれなりに尊重する。
なおRust信者は死ねと常々思っているが、それとこれとは別の話)
879(3): (ﾜｯﾁｮｲ 7748-ar6z) 07/01(火)20:20 ID:4pZHV5xo0(2/4) AAS
そうではなく
OSレベルで自動変換が行われているのに
言語レベルの自動変換に文句言うのもなんだなぁと
そういう話
880(1): (ﾜｯﾁｮｲ 5ffc-4xcB) 07/01(火)20:35 ID:M5z4vIa80(8/10) AAS
>>879
その意味なら、OSレベルの自動変換はされてないぞ。
例えば、SJISファイルはSJISファイルとして保存されてるだろ。
Windowsに保存する限りあらゆるファイルが自動的にutf-16にされ、
もう二度と各ファイルのエンコードを気にする必要がないのなら、大半の人はこの方が助かるとは思うが。(俺もこれでいい)
同様に、.NETでファイルストリームを開いたら、あらゆるエンコードが自動的にutf-16になって見える、って事もないだろ。
(APIチラ見する限り、Text.Encodingがあるから手動で切り換えのはず)
ただこれを目指した物がBOMなのだろうけど、上手く機能してるとは思えないね。
881: (ﾜｯﾁｮｲ 7748-ar6z) 07/01(火)20:40 ID:4pZHV5xo0(3/4) AAS
sjisファイルを読み込んでメモ帳で表示させる場合、内部のレンダリングエンジンとかはutf16に変換されたものじゃねえの？
それをまたsjisで保存する際には変換されてる
882(1): (ﾜｯﾁｮｲ 7748-ar6z) 07/01(火)20:41 ID:4pZHV5xo0(4/4) AAS
winapiのA系もutf16に変換されてる表示されているんじゃないの？
883(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ afd8-0lSL) 07/01(火)20:42 ID:4QEmYdel0(1) AAS
>>880
A 付きの API は OS が変換するよ。
ファイルの読み書きもロケールの設定によっては変換する。
わかりやすく観測しやすい例としてはファイル名は変換してる。
そもそも NTFS の規格からしてファイル名は Unicode が前提だし。
884: (ﾜｯﾁｮｲ 5ffc-4xcB) 07/01(火)20:43 ID:M5z4vIa80(9/10) AAS
>>879
あ、ちなみにコピペなら、あれはアプリ側がやってるらしいぞ。
例えばメモ帳でSJISファイル開いて、Ctrl-C、その後utf-8の別アプリ(メモ帳でもいい)でCtrl-Vしたとき、
正しくコピペされる(＝文字化けしない)が、これはアプリが対応してるかららしい。
ソースは、以前、対応してないアプリがあって、コピペが上手く機能しなかったとき、
「Windowsのメモ帳ですら対応してるのに、なんだこの糞アプリはッ!!!とブチ切れてた奴を見たから。
OSがやってくれてるのならこうはならない。
885: (ﾜｯﾁｮｲ 5ffc-4xcB) 07/01(火)20:56 ID:M5z4vIa80(10/10) AAS
>>882-883
確認した。
AとWがあり、Aは自動変換してくれるようね。
Win32APIだから、「OSが自動変換してくれる」と表現するのも正しいね。
>>879
上記で了解した。
886: (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)22:22 ID:0+2Ys+XXM(1) AAS
>>877
的外れなことばかり言ってんじゃないぞ、大馬鹿ものめ！
馬鹿はC言語スレに来るな！
887: (ﾜｯﾁｮｲ 62ad-hyNN) 07/02(水)04:17 ID:ZRfP3NsY0(1) AAS
phpやアプリで入力された文字をwebアプリで扱う話
なのか
メモ帳みたいにwindows固有のShift_Sisでの文字の処理の話
なのか
888: (ﾜｯﾁｮｲ 5fcb-4xcB) 07/02(水)05:01 ID:kZMPfHAD0(1/2) AAS
文字コードとプログラミング言語の区別が付いてないゆとりZが、
「ぼくのさいこうのせきゅりてぃ！！！」を語って馬鹿にされただけの話
ついでに考えてみたが、Windowsの場合はファイル読み込み時に変換かけ、
CLR上のStringも、C#のStringも、またWindows上のStringも、全てutf-16、という美しい世界なのだろうが、
これだと同様にクリップボード上のテキストもutf-16だと思われ、文字化けする理由が分からん
(俺が遭遇した物はエンコーディングによってコピペが出来たり出来なかったりしてた《ように見えた》)
なおWin10以降はutf-8を目指しているのかも？
外部ﾘﾝｸ:www.momopoem.com
とはいえ、Cの話ではないな
unicodeスレでやれってこった
(あるのかは知らんが、スレがあってもおかしくない程度にはunicodeは複雑)
889(1): 07/02(水)06:16 ID:5Jo8M0S90(1) AAS
内部表現がUTF16LEであって、表面上はシステムで設定した文字コードってだけの話だよ
日本語環境だとデフォルトS-JISだったのをWindows10の途中からutf-8にした（ユーザ側で変更は可能）
メモ帳もデフォルトがutf-8になった
クリップボード上のテキストはアプリケーションがクリップボードにデータを預ける
その預けるデータ形式に読み取り側が対応していないと機能しないと言うだけ
シンプルなテキスト形式ならCF_TEXTがANSIでCF_UNICODETEXTがUTF16LEになる
CF_TEXTにしか対応していないか、両方対応しているけどANSI優先させてしまっている場合（ないと思うが）になら環境依存文字が文字化けすることもある
890: (ﾜｯﾁｮｲ bb95-aEED) 07/02(水)08:07 ID:c2tqUwxf0(1) AAS
わからんことはもうAIに聞いたら教えてくれるのに
891: (ﾜｯﾁｮｲ 7f7b-4xcB) 07/02(水)08:13 ID:pWg0Xl5Z0(1) AAS
>>889
了解した。
API見る限り、一つのクリップボードに複数のデータ形式を登録でき、しかも自動変換まで行ってくれるのだから、
CF_UNICODETEXTだけ対応しておけば文字化けはほぼ無くなるので、彼が糞アプリ具合にキレたのも分かった。
> システムは、特定のクリップボード形式間でデータを暗黙的に変換します。
> ウィンドウがクリップボードにない形式でデータを要求した場合、システムは使用可能な形式を要求された形式に変換します。
> 外部ﾘﾝｸ:learn.microsoft.com
> クリップボードの形式 変換形式
> (中略)
> CF_TEXT CF_UNICODETEXT
> (中略)
> CF_UNICODETEXT CF_TEXT
892: (ﾜｯﾁｮｲ 5fef-4xcB) 07/02(水)09:02 ID:kZMPfHAD0(2/2) AAS
ちな、unicodeスレ
文字コード総合スレ part15
2chｽﾚ:tech
893(1): (ﾜｯﾁｮｲ ff02-Q0Sn) 07/06(日)09:24 ID:jyZjYPic0(1/2) AAS
>>861
python(リファレンス実装、すなわちcpython)の文字列内部表現は全部UTF-32だよ
やはり(概ね)固定長がプログラムで処理しやすい
外部的にはutf-8を吐くけど
894: (ｻｻｸｯﾃﾛ Sp0b-5BqU) 07/06(日)11:52 ID:v3CN8ECgp(1) AAS
英語圏から見たら一文字に32bitも使うなんて勿体無いと思う
895: (ﾜｯﾁｮｲ bffc-3agI) 07/06(日)12:26 ID:WJe1asKY0(1/2) AAS
emoji全盛なので英語圏は～という見方は時代遅れ
上下前次1-新書関写板覧索設栞歴
あと 107 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s