C言語なら俺に聞け 163 (987ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
860(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5f98-4xcB) [sage] 2025/07/01(火) 05:48:42.66 ID:M5z4vIa80(1/10) AAS
>>859859(2): デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM6b-fGW2) [sage] 2025/07/01(火) 02:30:13.65 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言語で作っていれば子の様な齟齬は起きない。
× > PHPの文字列は
○ unicodeは
× > C言語で作っていれば
○ asciiに限定すれば
お前は基本的なところがまるで理解出来てない
そもそも文字コードの話なのだから、どの言語でも同じ
特定の言語を使用すると回避出来るとかいう話にはなり得ない
861(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5f98-4xcB) [sage] 2025/07/01(火) 06:18:52.12 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は、どうやら全自動で出来るみたいね…
863: デフォルトの名無しさん (ﾜｯﾁｮｲ 5f01-4xcB) [sage] 2025/07/01(火) 09:47:54.97 ID:M5z4vIa80(3/10) AAS
>>862俺は859は根本的に勘違いしてる(≒間違っている)という見方を今も変えてないが、
少なくとも862の方が詳しいようだから(859の相手は)お前に任せるわ。
俺より詳しい奴が居る場所で俺が説法する意味もなく、
馬鹿と初心者が無限に沸くネットで間違いを全部指摘して回るのは無理だし。
下から目線のゆとりZ様同士でよろしくやってくれ。
どのみち俺とお前らではどうやっても合わないのはこれまでも散々経験してきた事だ。
864: デフォルトの名無しさん (ﾜｯﾁｮｲ 5f01-4xcB) [sage] 2025/07/01(火) 09:48:28.12 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がコミュ障な所だ。
まあそれでもお互いにやるのは自由、よろしくやってくれ。
俺は降りる。
867: デフォルトの名無しさん (ﾜｯﾁｮｲ 5f01-4xcB) [sage] 2025/07/01(火) 10:57:25.82 ID:M5z4vIa80(5/10) AAS
リンクは以下の方がよかったかも
外部ﾘﾝｸ[html]:hydrocul.github.io
> Grapheme cluster の境界定義
> CR の次に LF が続く箇所は境界にならない
これだとCRLFは一文字扱いだから、utf-8の0x7f以下だけ使っても(厳密には)asciiとは違うって事か？
なんで一々仕様を無駄に変更するのだ？という気はするが、
見てる限りunicodeって自然言語学者が策定してる仕様で、プログラミングのし易さなんてまるで考慮して無いな
876: デフォルトの名無しさん (ﾜｯﾁｮｲ 5ffc-4xcB) [sage] 2025/07/01(火) 20:03:31.00 ID:M5z4vIa80(6/10) AAS
>>874まあ859もゆとりZだったというオチだよ。
見えてた展開ではあったが、放置するのも問題かと思って最低限のツッコミを860でしたつもりだったが、
ゆとりZが釣れまくってどうにもならねえ。脱線しすぎ。
5chにはコミュ障が多いのでついでに解説しとくと、
859のテイ、何だかよく分からん独り言は、ゆとりZ特有のムーブで、
・質問して答えてもらえないと傷つくし、
・議論提起してボコられたら嫌だし、
・何だかよく分からん独り言にしとけば、どういう展開になっても逃げられるし！！！
って事で、傷つかない為に予防線張りまくりの戦術、連中なりの「コミュ上手」な手法らしい。
いやいや、お前ら一々メンドクセエわ。
877(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5ffc-4xcB) [sage] 2025/07/01(火) 20:04:09.01 ID:M5z4vIa80(7/10) AAS
>>868> 860は、馬鹿だから理解できない。
お前がどう思おうと自由だが、さすがに俺よりお前の方が賢いと思う奴は居ないと思うぞ。
まあこれも862と同様のゆとりZ特有ムーブで、「ばかにされた！！！」事が内容に勝ってる。
いやいや、お前がそもそもマヌケな事を言わなければ防げた展開だろ、とはならない。
> PHPに限らず、文字コードを勝手にいじくる言語は脆弱性の温床になる。
> 特に問題なのはオープンソースのフレームワークだ
少なくとも今のお前より理解してる連中が作ってるから、
今のお前の知識と知能で作った物よりは安全だろうよ。
ついでに言うとこれもゆとりZの特徴で、
心根で他人を見下してるからこんな発言になるし、また、
心根で他人に対してマウントを取りたい、上から目線で話したい、と思ってて、でも我慢してるからこそ、「上から目線」に過敏になる。
オープンソースにゴミが多いのも事実としても、
同じ物を作るのはかなり大変なのも、結果的に生き残ってる物はそれなりに鍛えられた品質なのも事実。
各言語処理系なんて相当の人数が関わって改善された結果だから、同等以上の品質の物を作るのは事実上無理だと思うけど。
ゆとりZは「謎の心根の『上から目線』」がありすぎ。
それでいて「表面的な『上から目線』」にゼロトレランスなのはちゃんちゃらおかしいのだが、まあ連中はここら辺を矛盾に感じないらしい。
連中は表面的なコミュニケーションしか出来てないってのがこの辺から分かる。
880(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5ffc-4xcB) [sage] 2025/07/01(火) 20:35:01.95 ID:M5z4vIa80(8/10) AAS
>>879その意味なら、OSレベルの自動変換はされてないぞ。
例えば、SJISファイルはSJISファイルとして保存されてるだろ。
Windowsに保存する限りあらゆるファイルが自動的にutf-16にされ、
もう二度と各ファイルのエンコードを気にする必要がないのなら、大半の人はこの方が助かるとは思うが。(俺もこれでいい)
同様に、.NETでファイルストリームを開いたら、あらゆるエンコードが自動的にutf-16になって見える、って事もないだろ。
(APIチラ見する限り、Text.Encodingがあるから手動で切り換えのはず)
ただこれを目指した物がBOMなのだろうけど、上手く機能してるとは思えないね。
884: デフォルトの名無しさん (ﾜｯﾁｮｲ 5ffc-4xcB) [sage] 2025/07/01(火) 20:43:09.72 ID:M5z4vIa80(9/10) AAS
>>879
あ、ちなみにコピペなら、あれはアプリ側がやってるらしいぞ。
例えばメモ帳でSJISファイル開いて、Ctrl-C、その後utf-8の別アプリ(メモ帳でもいい)でCtrl-Vしたとき、
正しくコピペされる(＝文字化けしない)が、これはアプリが対応してるかららしい。
ソースは、以前、対応してないアプリがあって、コピペが上手く機能しなかったとき、
「Windowsのメモ帳ですら対応してるのに、なんだこの糞アプリはッ!!!とブチ切れてた奴を見たから。
OSがやってくれてるのならこうはならない。
885: デフォルトの名無しさん (ﾜｯﾁｮｲ 5ffc-4xcB) [sage] 2025/07/01(火) 20:56:30.50 ID:M5z4vIa80(10/10) AAS
>>882-883
確認した。
AとWがあり、Aは自動変換してくれるようね。
Win32APIだから、「OSが自動変換してくれる」と表現するのも正しいね。
>>879
上記で了解した。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s