$ch = curl_init('https://api.ip2location.io/?ip=8.8.8.8'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $json = curl_exec($ch); curl_close($ch); $api_result = json_decode($json, true); echo '<pre>'; var_dump($api_result); echo '</pre>';
APIキーなしでも動作するが、1日あたり1,000件のクエリに制限される。
無料プランに登録するとAPIキーを取得でき、1か月あたり5万件のクエリを利用できる。
| 集計関数 | 用途 |
|---|---|
| COUNT | 項目のデータ件数を取得する |
| SUM | 項目のデータ合計値を取得する |
| AVG | 項目のデータ平均値を取得する |
| MAX | 項目のデータ最大値を取得する |
| MIN | 項目のデータ最小値を取得する |
<table style="margin: 1em auto;">
// tracking.php // 訪問データの取得 $ip = $_SERVER['REMOTE_ADDR']; $page = $_SERVER['REQUEST_URI']; $time = date('Y-m-d H:i:s'); $referrer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : ''; $user_agent = $_SERVER['HTTP_USER_AGENT']; // ここでデータベースへの接続および記録処理を行います try { $pdo = new PDO('mysql:host=ホスト名;dbname=データベース名', 'ユーザー名', 'パスワード', [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION ]); $stmt = $pdo->prepare("INSERT INTO access_logs (ip, page, access_time, referrer, user_agent) VALUES (?, ?, ?, ?, ?)"); $stmt->execute([$ip, $page, $time, $referrer, $user_agent]); } catch (PDOException $e) { error_log("DBエラー: " . $e->getMessage()); }
echo substr('abcdef', 0, 8); // abcdef
// 絵文字制限（例: VARCHAR(30)） $maxLength = 30; $maxBytes = $maxLength * 4; // 文字数，バイト数を確認 if (mb_strlen($_POST['text'], 'UTF-8') > $maxLength || strlen($_POST['text']) > $maxBytes) { $error = "文字数またはバイト数がオーバーしています。"; }
<?php $array = ['apple', 'banana', 'cherry']; // 'banana'を削除したい $key = array_search('banana', $array); // インデックスを取得 if ($key !== false) { unset($array[$key]); // 配列から削除 $array = array_values($array); // インデックスを再構築 } print_r($array); ?>
絵文字のバイト数についての質問ですね。絵文字はUnicodeで表現され、通常は1文字あたりのバイト数が可変です。一般的に、絵文字は以下のようにバイト数が異なります。
3バイト: 多くの一般的な絵文字は3バイトで表現されます。
4バイト: 一部の絵文字、特に特定の漢字や複雑な絵文字は4バイトを必要とします。
最近のUnicode標準では、最もバイト数が多い絵文字は、複数の要素を組み合わせたものです。例えば、2人の人がキスをしている絵文字（🧑🏻❤️💋🧑🏼）は、スキントーン修飾子を含むため、合計で35バイトを必要とします。
このように、絵文字のバイト数はその構成によって大きく異なるため、特定の絵文字が何バイトかを知ることは、使用する場面によって重要です。
大きい目の笑顔：😃
直でもいいの？😃
どちらを使っても表示されるので、基本的には好きな方を選んで問題ありません！ただ、状況によって使い分けることをおすすめします。
😀 (絵文字そのものを入力する方法)
この方法はシンプルで直感的ですが、ファイルのエンコーディングがUTF-8である必要があります。もしエンコーディングが適切でない場合、文字化けが発生する可能性があります。
😀 (文字参照を使う方法)
HTMLエンティティを使うと、エンコーディングに依存しないので安全性が高まります。また、コードを扱う際に明示的でわかりやすい点も利点です。ただし、読みづらくなる可能性があるので、複数の絵文字を使う場合は注意が必要です。
つまり、簡単な作業や個人用のページでは「😀」を使い、エンコーディングの問題や他人が読むことを考慮する場面では「😀」を選ぶのが良いかもしれません。
「絵文字そのもの」をMySQLに保存する
CREATE TABLE emojis ( id INT AUTO_INCREMENT PRIMARY KEY, emoji_text VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL );
指定する文字数（例: 255）は文字数そのものを指します。つまり、絵文字そのものを保存した場合でも、文字参照（例: 😀）を保存した場合でも、MySQLの文字列の長さとして扱われるのはエンコード後のバイト数ではなく、論理的な文字数です。
ただし、以下の点に注意してください：
絵文字そのもの（例: 😀）は通常1文字とカウントされます。ただし、utf8mb4を使用している場合に限ります。
文字参照（例: 😀）はそのまま保存すると、その文字列の全体の長さがカウントされます。例えば、😀は9文字としてカウントされます。
AES_ENCRYPT('データ', '鍵')
キーの長さ: AESではキーの長さが暗号化の強度に影響します。AES_ENCRYPTでは、使用するキーの長さに基づいて暗号化が行われますが、長さが16バイト、24バイト、32バイト（128ビット、192ビット、256ビット）である必要があります。
指定したキーがそれ以外の長さの場合、MySQLは自動的にキーを適切な長さに切り詰めたり、ゼロ埋めを行う場合があります。
キーの長さが正確に16、24、32バイトの場合は、何の調整も行われずそのまま使用されます。
ゼロ埋めや切り捨ては、意図しない暗号化結果を引き起こす可能性があるため、使用するキーは明示的に適切な長さで生成することが推奨されます。
MySQLのAES_ENCRYPT関数は、ECBモードを使用します。このモードは各ブロックを独立して暗号化するため、初期化ベクトルを必要としません。
ECBモードの欠点として、同じ平文が同じ暗号文になるという特徴があります。これにより、暗号のパターンが推測されやすくなるという弱点があります。
AES_ENCRYPT(str, key) を使った場合、暗号化されたデータのサイズは以下のように決まります：
AESのブロックサイズは 16バイト（128ビット）です。
暗号化する文字列のサイズが 16バイトの倍数でない場合、パディングによってサイズが増加します。
暗号化後のデータサイズ ≈ 元のデータサイズ + (16 - 元のデータサイズ % 16)（パディングを考慮）
MySQL 8.0以降では、AES_ENCRYPTとAES_DECRYPTでAES-GCMモードをサポートするようになり、このモードでは暗号化に初期化ベクトル（IV）が内部的に使用されます。ただし、IVをユーザーが直接指定することはできません。システムが自動で管理します。
MariaDBでは、AES-GCMモードはサポートされていません。
暗号文サイズ = 平文のサイズ（バイト） + IVサイズ（12バイト） + 認証タグサイズ（16バイト）
AES-GCM以外の暗号化モード（例: AES-CBC, AES-ECBなど）では、認証タグが生成されない。
AES-GCMではパディングは発生しない。
MySQLのAES_ENCRYPT()はバイナリデータとして暗号化結果を返すため、保存するときはVARBINARYを使うのが適切です。
Fedora 42 users can install gnome-shell-extension-appindicator which is already ready for Gnome 48
$ sudo dnf install gnome-shell-extension-appindicator Package Arch Version Repository Size Installing: gnome-shell-extension-appindicator noarch 59-2.fc41 fedora 246.0 KiB Installing dependencies: libappindicator-gtk3 x86_64 12.10.1-5.fc41 fedora 108.6 KiB libdbusmenu x86_64 16.04.0-28.fc41 fedora 540.3 KiB libdbusmenu-gtk3 x86_64 16.04.0-28.fc41 fedora 88.5 KiB Transaction Summary: Installing: 4 packages $ sudo dnf install libappindicator-gtk3
「NOT NULL」を指定しない場合、デフォルトでそのカラムはNULL値を許容します。つまり、データを挿入するときにそのカラムの値を指定しなくても、NULL値が設定されます。
「NULL値を許容している場合」に「DEFAULT NULL」を明示的に指定しなくても、結果として同じ動作になります。つまり、デフォルトでNULL値が設定可能な状態となり、値を挿入しない場合そのカラムの値はNULLになります。
CREATE TABLE example_table1 ( column1 INT -- デフォルトでNULLが許容される );
CREATE TABLE example_table2 ( column1 INT DEFAULT NULL -- 明示的にNULLをデフォルト値として指定 );
この2つは動作に違いはなく、どちらの定義でもcolumn1に値を挿入しない場合はNULLが自動的に設定されます。ただし、「DEFAULT NULL」を明示することには利点があります。
例えば：
テーブルの定義をより読みやすくする（意図が明確になる）
他の開発者への理解を助ける