© RAKUS Co., Ltd. PHP8.2にバージョンアップしたら文字化けが発 生して道頓堀に飛び込みたくなった話 #phperkaigi 株式会社ラクス 大阪第一開発部メールディーラー開発課 藤掛治 2024/3/9 1

2 自己紹介 ● 株式会社ラクス ○ 2014年3月入社 ○ メールディーラーの運用・サポートエンジニア ● 吹田市在住 ● 家族は妻と中2男子 ● 趣味はサッカー ○ ボランチ ○ ガンバ大阪のガチサポーター 藤掛治(ふじかけおさむ)

運用・サポートエンジニア 3 ● 2014年の入社以来、開発チームで運用・サポートエンジニアとして下 記のようなことを行ってきました ○ アプリケーションの保守：不具合の修正、データの補正 ○ サーバの運用 ：M/Wのバージョンアップ、リリース ○ 顧客からの問い合せ対応：仕様の確認、使い方の提案 PHPの話もさることながら、運用や顧客対応で苦労したことをお話しよう と思います

© RAKUS Co., Ltd. 4 PHP8.2にバージョンアップしたら文字化けが 発生して道頓堀に飛び込みたくなった話 株式会社ラクス 大阪第一開発部メールディーラー開発課 運用・サポートエンジニアチームリーダー 藤掛治 PHP8.2にバージョンアップしたら文字化けが 発生して道頓堀に飛び込みたくなった話 株式会社ラクス 大阪第一開発部メールディーラー開発課 運用・サポートエンジニアチームリーダー 藤掛治

5 お話する内容 1. 運用・サポートエンジニアについて ○ メールディーラー開発チームの構成 2. メールディーラーの紹介 3. 文字化けの不具合と顧客対応について ○ PHPのバージョンアップ ○ 不具合の原因 ○ プログラムの修正方法 ○ 顧客対応

メールディーラー 開発課 メールディーラー 開発課 6 メールディーラー開発チームの構成 運用サポート チーム 実装チーム ・実装 ・オフショア対応 ・問合わせ対応 ・運用の課題解決 上流チーム ・要件定義 CSチーム ・問合わせ1次対応 ・顧客支援 製品企画

7 メールディーラーのご紹介 ● メール共有管理サービス ○ メールの処理を複数人で対応可能にするWebメーラー ○ 主に企業の問い合せの対応と管理に利用されています ■ 対応漏れや重複対応を防止する ■ 問い合せに起因するアクションの管理 ● メール共有管理システム市場で15年連続売上シェアNo1(※) ● 累計導入社数8000社以上 ※出典：ITR「ITR Market View：メール／Webマーケティング市場2024」メール 処理市場：ベンダー別売上金額推移およびシェア2009－2023年度（予測値）

8 ありがたいことにたくさんの お客様にご利用いただいているので、 いろんなことが起こります

9 いろんなことの一例 1. サーバが差し押さえられそうになる ○ あるお客様が警察の捜査対象になり、その証拠集めのため ○ サーバは勘弁してもらい、メールデータを引っこ抜いて提出 ○ 人生で初めて捜査令状を見る。多分コレが最後。 2. 嫌がらせのメールを大量に受信し、ハードディスクが枯渇しそうになる ○ 「このままだと日曜日にディスクが枯渇します！！」 3. スパムメールを受信するのは日常茶飯事 ○ Fromがない、フィッシングメール、文字化けしたメール などなど、いろんなことが起こります

10 ようやく本題

11 リリース後にメールが文字化けした 「昨日まで読めてたメールが今日から文字化けして読めなくなった」 ● お客様からCSチームに問い合せ ● 前日にメールディーラーのバージョンアップを行った ● その際にPHPを8.0から8.2にバージョンアップした 不具合の可能性が高いので急いで調査！ ● 調査した結果・・・ ● メールに文字コードの設定が無い！ → 次ページで説明します ● それってメールディーラーのせいじゃないよね

12 ここでメールの構造の説明 メール ヘッダ(header) 本文(body) テキストパート Content-Type:text/plain; charset=”utf-8” ・ ・ ・ HTMLパート Content-Type:text/html; charset=”utf-8” ・ ・ ・ メールは大きく2つにわかれている ● ヘッダ(header) ○ 属性情報(日付、件名など) ○ 経由したサーバ などが記載 ● 本文(body) ○ メールの本文 ○ テキストメール、HTMLメール、 添付ファイルなどいくつかに分か れている このフォーマットはRFCで規定されている

13 文字化けした原因 メール ヘッダ(header) 本文(body) テキストパート Content-Type:text/plain; charset=”utf-8” ・↑これがない ・ ・ HTMLパート Content-Type:text/html; charset=”utf-8” ・↑これがない ・ ・ 文字コードの設定がない ● 文字コードがわからないのにどう やって表示せよというのだ？ ● そもそもRFCに違反している でもお客様の話をよく聞くと・・・ ● 昨日受信したメールは見える ● 今日の受信から文字化けした つまりリリース前は文字化けはしてい なかった

14 詳しく調査した結果

15 文字化けした理由 メールディーラーの仕様で、文字コードの設定がない場合は・・・  mb_detect_encodingを使って文字コードを検出  検出した文字コードでメールをエンコードして表示する PHPのバージョンアップでmb_detect_encodingの仕様が変わった ● mb_detect_encoding(評価するデータ, エンコードリスト)  8.0以前では引数のエンコードリストの前から順に評価して適切なものがあれば、そ れが採用された  8.1以降は引数のエンコードリストをすべて評価して最も適切なものを採用する これにより、想定した文字コードを返さなくなり文字化けが発生！ Sift-JISが欲しいのにどうしてもASCIIが返ってくる

16 でもまぁ、メールが悪いよね

17 ということでお客様に報告 バージョンアップ前は見れていたのだから、 当然見れるようになるんですよね？ 文字コードが設定されていないことが原 因だったとしても、事前通知されていな いのでラクスで対応してください 文字コードを設定されていない メールは文字化けします 文字コードが設定されていな いメールが文字化けすること を弊社では把握していません ので、事前に通知することは 不可能でした 文字化けの原因は文字コード がメールに設定されていない ことです

18 するとカウンターを食らう PHPのバージョンアップのリリースノー トを見れば影響するかぐらいはわかるん じゃないですか？ そもそもPHPのバージョンアップ前と後 で比較のテストはしていないのですか？ はい、修正します・・・

19 なのでコードを修正 $encodeList = [エンコードの配列] ← 1 for ($encodeList => $encode) { if (mb_check_encoding(メールデータ, $encode) ← 2 ここでほぼ捕捉できるはず return $encode } mb_detect_encoding(メールデータ, $encodeList); ← 3 1. エンコードする文字コードの候補をリスト化 2. mb_check_encodingを使って上記1のリストでチェックする 3. 合致する文字コードがなかったらmb_detect_encodingを使ってリストに近い文 字コードを探す

20 なんとか解決できたので ふりかえり

21 障害の振り返り お客様に大きな影響のあった不具合や障害が発生した場合、対応がひと段落したのちに振 り返りを行っています。そこで同じことが起こらないように再発防止策を検討します。  確かに、事前調査でmb_detect_encodingの仕様変更は下位互換性がないとわかって いた  「影響があるかも」という通知は事前にできたかも

22 伏線回収

メールディーラー 開発課 メールディーラー 開発課 実は開発中に開発チームは文字化けすることを知って いた 23 運用サポート チーム 実装チーム 上流チーム 報告漏れ CSチーム ヘルプディスク ・問い合わせ1次対応 ・顧客支援 説明しんどい 文字化けするこ とを知っていた 謝罪 「実はわかっていました」 なんて言えない。ゆえに板挟み

24 開発チームが報告しなかった理由 PHP内部仕様の変更のため、顧客への周知の判断が甘くなった(≒報告しなくていい) 本来なら対応する必要のないメールも 文字化けしないように対応しなければならなくなった ⇨ わかっていたのであれば言おうぜ、マジで。 今後は仕様変更が発生した場合は、 PHPの内部仕様だったとしてもすべてCSチームに報告する

25 後日談

26 プログラムの修正について (PHPカンファレンス関西で聞いた話) ● mb_detect_encodingは期待した結果が得られないときがある ・バイナリで比較するとSJISとASCIIの両方に存在する文字コードがある ・例えば、SJISの「あ」→ ASCIIでは「ん」 (※)↑は説明のための「例え」なので正確ではありません ● mb_check_encodingを使う

© RAKUS Co., Ltd. 27 ご清聴 ありがとうございました