おす! 久しぶりだなぁ。みんな元気にしてっか?
あのよぅ、ちょっと聞きてぇ事ができたんだ。
PHP の事なんだけんどもよぅ、
\x41 も \u{41} も使わねぇで A の文字列リテラルの定義って、出来ると思うか?
勿論、ソースコードのエンコードは UTF-8 なんだけんどもな、
なんかいい方法知らねぇか?
コードゴルフみてぇな話だから、気楽になんでも言ってくれよ。
おら、わっくわくしながら回答待ってっからさぁ、頼むよ。
hex2bin とか pack はあり?
おす! 聞いてくれてありがとな。
縛りに関してはとりあえず、"A"はダメだ、ってのと、
定義をするにあたって直接関数を通すのもダメだ、って縛りだけのはずだ。
だけんども、リテラルの中に関数を記述する事で、
ある時点において、その関数が実行されて結果的に A が定義できる方法があるってんなら、
それは、場合によってはありかもしれねぇんだ。
だから、心あたりがあったらなんでも言ってくれよ。
あと、この質問に関しては、
回答そのものでなくても回答欄の方に書いてもらった方がいいかもしんねぇな。
あっちはスレッドになるし、Markdownが使えっから、あっちの方がいろいろと便利かもしんねぇ。
わりぃけど、頼むよ。
「直接関数を通すのもダメ」っていうのは、sprintf('%c', 65); はダメっていう意味?
8進数(\101)はアリ?
>「直接関数を通すのもダメ」っていうのは、sprintf('%c', 65); はダメっていう意味?
そうそう。あくまでもリテラルとして定義しなきゃなんねぇから、
$val = sprintf('%c', 65);
みてぇのは、ナシってルールらしいんだ。
だけんども、例えば
$val = "sprintf('%c', 65)";
みてぇにしておいて、後でそれが構文解析されて結果的に A っつー string になるのは、場合によってはでぇじょうぶらしいんだ。
>8進数(\101)はアリ?
それなんだけんどもさぁ、ルールを守ってっか調べてるらしくてよう、
リテラル定義直後に、変数内に 0x41 が存在しねぇか、バイナリレベルで調べてんだよ。
んだから、その後で 0x41 になるのは構わねぇけど、
リテラル定義の時点でインタプリタが 0x41 として解釈しちまうのは、ダメって事らしいんだ。
だから \x41 も \u{41} ダメ、みてぇな、
すっげぇめんどくせぇ事になってんだ。
後出ししたみてぇですまねぇな。
んだから、勿論、
$val = "\\x41";
みてぇにしておいて、後でそれが 0x41 として解釈されるっていうのなら、場合によってはでぇじょうぶらしいんだ。
そんで、『場合によっては』の場合っつーのは、一番でぇじょうぶそうな処理でいうと、
. を使った単純な string 連結とかだったりするらしいんだ。
そんだから、eval() みてぇに危険な関数を通すのは、当然、ナシって事らしいぞ。
おす!久しぶりだなぁ!
1, \x41 or \u{41}以外の文字列リテラルで、Aを定義
2, \x41 or \u{41}でないことを確認
3, Aと出力
ということでええんか?
だいてぇそんな解釈でいいけどよぅ、
『2, \x41 or \u{41}でないことを確認』
については、
定義された string 中に 0x41 が存在しねぇ事を確認してるみてぇだ。
> リテラル定義直後に、変数内に 0x41 が存在しねぇか、バイナリレベルで調べてんだよ。
これが抜けてたか
キャストでいけるかと思って試したら、そのまま文字列になりやがる…
な、最初に思ってたよりは、割と難易度高ぇだろ?
無理かもしんねぇけど、本当にできるってぇなら、
色々と、わっくわくしてこねぇか?
あなたの回答
tips
プレビュー