TL;DR - クイック解決策
このエラーが表示される原因は、送信しようとしているデータ（通常は大きな画像や動画）が、PHPで設定されている許容サイズを超えているためです。解決するには、php.iniファイルの2つの特定の設定値を増やす必要があります。
php.iniファイル（通常は/etc/php/8.x/fpm/や/etc/php/8.x/apache2/にあります）を探します。post_max_size = 64M（または必要なサイズ）に設定します。upload_max_filesize = 64Mに設定します。- Webサーバーを再起動します（例：
sudo systemctl restart php-fpm）。
このエラーが特殊な理由
エラーメッセージに「Unknown on line 0」と表示されるのには理由があります。PHPは、スクリプトの実行を開始する前のリクエスト開始フェーズでこの警告を発生させます。コードが実行される頃には、PHPはすでに入力データが大きすぎると判断しており、自身を保護するために$_POSTと$_FILESのスーパーグローバル変数を空にします。
この警告が表示されると、スクリプトはユーザーが空のフォームを送信したかのように動作します。ファイルアップローダーの構築や大きなJSONペイロードを扱う際によく遭遇する、非常に厄介な問題です。
ステップ別の修正手順
1. php.iniを更新する（標準的な方法）
メインの設定ファイルを変更するのが最も確実な方法です。正しいファイルを見つけるには、ターミナルでphp --iniを実行するか、phpinfo();ページの「Loaded Configuration File」のパスを確認してください。
; 例：100MBのアップロードをサポートする場合
upload_max_filesize = 100M
post_max_size = 100M
ヒント： post_max_sizeはupload_max_filesize以上の値にする必要があります。例えば、20MBのファイルを4つ同時にアップロードする場合、upload_max_filesizeが25MBであっても、post_max_sizeは少なくとも80MB必要です。
2. Apacheでの回避策（.htaccess）
共用サーバーを利用している場合、php.iniを編集できないことがあります。ホスト側で設定の上書きが許可されている場合は、ルートディレクトリの.htaccessファイルに以下の行を追加してください。
php_value upload_max_filesize 100M
php_value post_max_size 100M
3. Nginxと413エラー
Nginxをリバースプロキシとして使用している場合、PHPの制限を増やすだけでは不十分な場合があります。Nginxにはデフォルトで1MBの制限があります。リクエストがこれを超えると、NginxはPHPに届く前にリクエストをブロックし、多くの場合「413 Request Entity Too Large」エラーを返します。
Nginxのサイト設定（例：/etc/nginx/sites-available/default）を開き、serverブロックにclient_max_body_sizeを追加します。
server {
client_max_body_size 100M;
...
}
sudo nginx -s reloadを実行して変更を適用します。
確認：正しく動作しているか？
設定ファイルだけを信じず、一時的なPHPスクリプトを作成して実際のライブ設定を確認しましょう。
<?php
echo "アップロード制限: " . ini_get('upload_max_filesize') . "<br>";
echo "POST制限: " . ini_get('post_max_size');
?>
数値が変更内容と一致しない場合は、間違ったphp.iniを編集した可能性があります。多くのシステムでは、CLI（ターミナル）用とWebサーバー（FPM/Apache）用で別々の設定ファイルが保持されています。
最終的な考慮事項
memory_limitにも注意してください。post_max_sizeは生データを扱いますが、スクリプトが高解像度画像のサイズ変更などをすべてメモリ上で行おうとすると、クラッシュする可能性があります。一般的に、memory_limitはpost_max_sizeよりも高い値に設定すべきです。
異なる環境間でこれらの値を管理するのは煩雑になりがちです。自動デプロイ用にYAMLやJSONファイルで設定を保存している場合は、ToolCraftのYAML ↔ JSONコンバーターの使用をお勧めします。構文を検証し、余計なタブや括弧によるデプロイスクリプトの失敗を防ぐ簡単な方法です。
最後に、「念のため」という理由でこれらの制限を2GBなどに設定するのは避けてください。制限が高すぎると、サーバーがサービス拒否（DoS）攻撃に対して脆弱になります。攻撃者が巨大なリクエストを送り続け、ディスク容量やメモリを使い果たしてしまう可能性があるため、ユーザーが実際に必要とする最小限の値に留めるようにしましょう。