Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PHP8.2にバージョンアップしたら文字化けが発生して道頓堀に飛び込みたくなった話
Search
藤掛治
March 11, 2024
0
1.1k
PHP8.2にバージョンアップしたら文字化けが発生して道頓堀に飛び込みたくなった話
藤掛治
March 11, 2024
Tweet
Share
More Decks by 藤掛治
See All by 藤掛治
PHP8.2にバージョンアップしたら文字化けが発生して道頓堀に飛び込みたくなった話
fujikake036
0
1.3k
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Practical Orchestrator
shlominoach
185
10k
Docker and Python
trallard
39
3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
A Tale of Four Properties
chriscoyier
155
22k
4 Signs Your Business is Dying
shpigford
179
21k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
Producing Creativity
orderedlist
PRO
340
39k
Typedesign – Prime Four
hannesfritz
38
2.3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
38
9.1k
Automating Front-end Workflow
addyosmani
1365
200k
Transcript
© 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 ご清聴 ありがとうございました