[過去ﾛｸﾞ] C言語なら俺に聞け 163 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
858: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7b32-T+w5) 06/30(月)20:57 ID:bv4WQiut0(1) AAS
その規模なら C で書くにしても配慮すべき低レイヤの事情がありすぎてあまり C の甲斐がなさそうだと私も思う。
859(2): (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) 07/01(火)02:30 ID:LkiphQyhM(1) AAS
PHPの文字列は、1つの文字列の中でも、文字によってバイト数が異なるそうだ。
だから、$str[$k] の $k は、文字単位ではなくバイト単位。
文字単位で指定したい場合には、
mb_substr($str, $k, 1, "UTF-8")
とするとのこと。
文字列の終端には一応 0x00 が入っているが、文字の長さはバイト数で管理されており、0を
終端とはみなしていない。だから、文字コードが 0x00 の文字も文字列の中に含めることが可能。
$str = "こんにちは";
echo strlen($str); // バイト数（UTF-8なら15）
echo mb_strlen($str); // 文字数（5文字）
ところが、正規表現を扱う場合には、0x00 のバイトが含まれていると、文字列の終端と
みなされることがある。だから、ユーザーによって入力された文字列を正規表現で
安全チェックをしたつもりでも、文字列の途中に 0x00 のバイトが含まれていて、
それ以後に危険なコードをが含まれている倍がある。
C言語で作っていれば子の様な齟齬は起きない。
860(1): (ﾜｯﾁｮｲ 5f98-4xcB) 07/01(火)05:48 ID:M5z4vIa80(1/10) AAS
>>859
× > PHPの文字列は
○ unicodeは
× > C言語で作っていれば
○ asciiに限定すれば
お前は基本的なところがまるで理解出来てない
そもそも文字コードの話なのだから、どの言語でも同じ
特定の言語を使用すると回避出来るとかいう話にはなり得ない
861(1): (ﾜｯﾁｮｲ 5f98-4xcB) 07/01(火)06:18 ID:M5z4vIa80(2/10) AAS
と思ったが、もしかして最近の言語はutf-8をネイティブサポートしていて、(＝内部文字列がutf-8)
この辺を全部自動的に回避出来るのか？（＝プログラマに文字コードの知識が全く必要ない)
Cはutf以前だから勿論サポート無し
PHPはWeb言語だから文字列＝バイトストリーム扱いで、共用体が駆使されるネット向けになってるだけ
JSはutf-16だったがサロゲートペア導入でAPIが2つある(サロゲートペア対応版と非対応版)
Rustは知らんが、さらっと調べた限りutf-8で、逆にインデックスアクセスが出来ないらしい(3文字目を[3]で取得出来ない)
ただこれだと遅くなるだけなので、Cを駆逐したいと言いながら便利さを追求してるRustは迷走してる
Pythonは、どうやら全自動で出来るみたいね…
862(1): (ﾌﾞｰｲﾓ MM02-nkZs) 07/01(火)08:38 ID:WjfKubzqM(1) AAS
>>860
859は別に間違ったこと言ってないでしょ
そこまで上から目線で言いたいならunicodeは書記素クラスタで考えないといけないので可変、ぐらい言わないとね
コードポイントならUTF-32は4バイト固定だし
むしろc言語はasciiという言い方は複数の意味でおかしい
863: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)09:47 ID:M5z4vIa80(3/10) AAS
>>862
俺は859は根本的に勘違いしてる(≒間違っている)という見方を今も変えてないが、
少なくとも862の方が詳しいようだから(859の相手は)お前に任せるわ。
俺より詳しい奴が居る場所で俺が説法する意味もなく、
馬鹿と初心者が無限に沸くネットで間違いを全部指摘して回るのは無理だし。
下から目線のゆとりZ様同士でよろしくやってくれ。
どのみち俺とお前らではどうやっても合わないのはこれまでも散々経験してきた事だ。
864: (ﾜｯﾁｮｲ 5f01-4xcB) 07/01(火)09:48 ID:M5z4vIa80(4/10) AAS
とはいえ一応内容について触れておくと、
> 書記素クラスタ
重ね文字等の事は知ってるぞ。ただ俺はこれは仕様が決まってないかと思っていたのだが、一応あるんだな。
外部ﾘﾝｸ:unicode.org
ただこれ、問題は"Unicode 16.0.0"と、バージョンがやたら高い事にあると思う。
自然言語が既に16回も改訂してるわけはないので、中途半端な仕様を決め、改訂しまくってるという事だから。
今の仕様で実装しても、出来上がる頃には仕様が改訂されている事もあり得る。
> コードポイントならUTF-32は4バイト固定だし
当然これも知ってるが、現実的にutf-32を使う事はほぼあり得ないだろ。
文字列処理は結局の所速度/メモリ重視だから、utf-32ではコードは書きやすいかもだが使い物にならない。
つかこの辺859に言ったところで通じるわけもなく、マウントが目的になってるのはお前の方だ。
だからこそ「上から目線」に過度に敏感なのがゆとりZの傾向でもあるが。
> むしろc言語はasciiという言い方は複数の意味でおかしい
話を続ける気があるなら、何の事なのかもう少し具体的に言え。
まあ一言ずつに纏めると、
859: PHPは文字の扱いに色々問題があるが、C言語にはない
860: お前は根本的に間違ってるから、文字コードについて勉強し直せ ← 859に通じる範囲で返事してる
862: 俺の方が詳しいのに上から目線ウゼエ ← マウントを取り返しただけで、859に通じるようには書いてない
ここら辺がゆとりZがコミュ障な所だ。
まあそれでもお互いにやるのは自由、よろしくやってくれ。
俺は降りる。
865: (ﾜｯﾁｮｲ c379-SOZQ) 07/01(火)10:03 ID:0aieN+8C0(1/2) AAS
普通に何も考えずに使ってて問題起きないならstrlen以外にもmbslenとかwcslenみたいなのを用意されることはないんだよな
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での文字の処理の話
なのか
上下前次1-新書関写板覧索設栞歴
あと 115 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s