表面的なバグ報告の奥底にある長い歴史
あるエンジニアのもとに、シンプルに見えるフロントエンドチケットが舞い込みました。アラビア文字で書かれたテキストブロックが「ragged right」—つまり左端が凸凹になっているという内容です。ただし、デザインチームは正当化（justified）表示を指定していたはずでした。
この一件が発端で、過去6ヶ月に閉じたアラビア文字関連のバグ報告が全4件、いずれも「うちだけの問題」に見えていたことが判明します。
掘り下げてみると、問題はスタイルシートの不具合ではなく、アラビア文字をWeb上で扱うことの根本的な困難さでした。
主記事では、このチケット報告者が過去6ヶ月に経験した他の3つの案件が列挙されています。
- PDF生成サーバーのライブラリが古く、テキストシェーピングエンジンを持たないため、顧客名の文字が分断表示された
- 2017年のデータインポート時に、1991年のUnicode符号位置と1995年のそれが混在してしまい、検索インデックスが機能しなくなった
- ブラウザ間でレンダリング結果がばらついた
いずれも「単独の不具合」に見えますが、すべて同じ根本原因—Webのアラビア文字サポート基盤の脆弱さ—に由来していました。
アラビア文字の正当化は、なぜスペース伸張では成り立たないのか
ラテン文字では、行の両端に揃えるために単語間のスペースを伸ばします。これはアラビア文字の伝統的な組版では使われません。むしろ文字そのものを伸張する—特に文字同士の連結ストローク（kashida）を長くすることで、行を右マージンまで引き出します。
主記事に示されているインタラクティブなデモでは、text-align: justify だけではアラビア文字が正しく正当化されていないことを視覚的に確認できます。
| 項目 | ラテン文字の方法 | アラビア文字の伝統的方法 |
|---|---|---|
| 行揃えの手法 | 単語間スペースを拡大 | 文字の連結ストロークを延長（kashida） |
| Web標準での実装状況 | ブラウザネイティブサポート | 別途Webフォント + シェーピングエンジン必須 |
| 表示品質 | 標準機能で十分 | 専門的な実装が必要 |
現在のWebブラウザは、ネイティブではアラビア文字の正当化に対応していません。
この状況を示すため、主記事は自作ホスト型のWebフォント「Amiri」（150キロバイト、OFL ライセンス）を用いてデモを提供しています。デモが成立するために専用フォントが必要という事実そのものが、問題の深さを語っています。
Unicode符号位置の混在—1991年と1995年の「違う文字列」
アラビア文字関連バグの第二の層として、エンコーディング問題があります。前述の検索インデックス問題は、2017年のデータインポート時に1991年のUnicode符号位置と1995年のそれが混在していたために起きました。
インデックスシステムは、見た目は同じでも異なるUnicode符号位置で表現されたテキストを「別の文字列」として扱い、マッチしません。
これはデータベースに保存されている値と検索条件が、外見は同じでも内部表現が異なる場合、クエリが無効になるという古典的な課題です。アラビア文字特有の問題というより、Unicode標準化の歴史がもたらした、業界全体の負債と言えるでしょう。
フロントエンド開発者が今できることと、今後の課題
このような状況のなか、開発者ができることは限定的です。主記事の筆者は、複数のフォントファミリーと direction 指定の組み合わせを試行錯誤しても、ブラウザネイティブでは正当化が機能しないことを確認しています。
現実的な対策は以下の通りです。
- アラビア文字を使う場合、テキストシェーピングエンジン対応のWebフォント（AmiriやNoto Sans Arabicなど）を採用する
- PDF生成など、サーバーサイド処理ではシェーピングエンジン内蔵のライブラリを選定する（古いライブラリの使用は避ける）
- データインポート・マイグレーション時には、Unicode標準化の時期を意識し、符号位置の統一を事前に検証する
- 多言語対応システムでは、テキストレンダリングのテストケースにアラビア文字を含める
この問題は、フロントエンドだけでは解決できず、フォント・Unicode標準・ブラウザエンジン・PDFライブラリなど、スタック全体の成熟度に依存しています。
主記事の筆者は、この5世紀分の技術的負債が積み重なった理由を、オスマン帝国時代の印刷所から現代のコンピュータサイエンスまで、壮大な文脈で解説しています。単なるバグ報告ではなく、技術史の学びとして読む価値があります。
