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

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

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

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

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

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

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

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以降は引数のエンコードリストをすべて評価して最も適切なものを採用する これにより、想定した文字コードを返さなくなり文字化けが発生！

16 コードの修正方法 $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を使ってリストに近い文 字コードを探す

17 ここからはお客様対応の話

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

19 あるお客様とのやり取り PHPのバージョンアップのリリースノー トを見れば影響するかぐらいはわかるん じゃないですか？ そもそもPHPのバージョンアップ前と後 で比較のテストはしていないのですか？ はい、修正します・・・

20 確かに、 mb_detect_encodingの下位互換性 のない仕様変更があることはわかっていたので 「影響があるかも」ぐらいは通知できたかも

21 伏線回収

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

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

24 後日談 ● mb_detect_encodingは期待した結果が得られないときがある ● mb_check_encodingを使う ● 道頓堀に飛び込んだ人は近隣の銭湯に入れない

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