Hackの文字列操作を掌握せよ：HSLがもたらす「予測可能性」という名の武器
PHPのレガシーを引きずる開発者の多くが、いまだに `strlen()` や `substr()` を無防備に使い、マルチバイト文字の地雷原を歩いている。もし君が、本番環境で「謎の文字化け」や「オフセット境界エラー」に頭を抱えたくないのであれば、今すぐ古い道具を捨て、HSL（Hack Standard Library）の `Str` モジュールを手に取るべきだ。
これは単なるAPIの置き換えではない。型システムとメモリ管理の観点から見た「計算機的安全性」の向上である。
—
1. なぜ「PHPの文字列関数」はエンジニアを裏切るのか
PHPの標準関数は、歴史的経緯から「バイト単位」で動作するものと「マルチバイト対応（mbstring）」が混在している。開発者がこれらを厳密に使い分けることを期待するのは、エラーを誘発してくださいと言っているに等しい。
- バイト単位の関数 (`strlen`, `substr`): UTF-8のマルチバイト文字を1文字としてカウントせず、バイト数で切断する。これにより、コードポイントの途中で文字列が分断され、不正なバイトシーケンスが生成される。
- mbstring系の関数 (`mb_strlen`): 設定（`mbstring.internal_encoding`）に依存する。これは「環境によって挙動が変わる」という、分散システムにおいて最も避けるべき動的挙動の温床だ。
Hackの `Str` モジュールは、これら全ての曖昧さを排除し、常にUTF-8を前提とした明示的な操作を強制する。 型チェッカーが介入することで、実行前にエラーを潰す。これが我々がHackを選んだ理由だ。
—
2. 実務で直面する「罠」：オフセットと境界値
文字列操作で最も悲劇を生むのが「マルチバイト文字の途中での分割」だ。以下の設計パターンを叩き込んでおいてほしい。
アンチパターン：PHPスタイルの闇
// 危険：バイト単位の処理をマルチバイト文字列に行うと、文字が破壊される
$str = “ハック言語”;
$part = substr($str, 0, 3); // 期待値: “ハ”, 実際: 不正なバイト列
推奨パターン：HSLによる堅牢な実装
HSLは「バイト」と「コードポイント」を明確に分離している。`Str\slice` を使う際、それが文字列の論理的な長さに基づいていることを意識せよ。
use namespace HH\Lib\Str;
/
- 安全な文字列の切り出し（切り捨て）
- 境界チェックを厳格に行い、不整合を防ぐ
/
function safe_truncate(string $input, int $max_length): string {
// Str\lengthは常に文字数（コードポイント数）を返すため、バイト破壊が起きない
if (Str\length($input) <= $max_length) {
return $input;
}
// 明示的な切り出し
return Str\slice($input, 0, $max_length);
}
---
3. パフォーマンスとメモリアロケーションの真実
HHVMのアーキテクチャにおいて、文字列は不変（Immutable）である。`Str` モジュールのメソッドを呼び出すたびに、メモリ上で新しい文字列が生成される。ループ内でこれらを多用すると、GC（ガベージコレクタ）に不要な負荷をかけ、レイテンシを増大させる。
極限の最適化テクニック：
大量の文字列を連結する場合、個別の `.` 演算子や `Str\concat` を繰り返すのは愚策だ。
use namespace HH\Lib\Vec;
use namespace HH\Lib\Str;
// パフォーマンスを意識した文字列連結のベストプラクティス
function build_log_message(vec
// 個別に連結せず、Vecから一気にjoinする
// 内部的なアロケーション回数が最小化される
return Str\join($parts, ” | “);
}
—
4. 非同期API連携における「型」の重要性
外部APIからJSONを受け取る際、文字列のエンコーディングが保証されていないケースが多い。ここで `Str` モジュールの検証機能を組み合わせることで、システム全体の境界で「無効なデータ」を弾くことができる。
use namespace HH\Lib\Str;
function process_api_response(string $raw_data): void {
// 入力が有効なUTF-8かを確認する（必要に応じて）
// HSLは常にUTF-8を期待するが、境界での検証は重要
invariant(Str\is_utf8($raw_data), “API response contains invalid characters”);
// 後続の処理は、安全な文字列として扱う
// …
}
—
チーフアーキテクトからの提言：コードは「読み手」のためにある
Hackの `Str` モジュールを使うことは、単に便利なツールを使うことではない。「このコードは文字列のエンコーディングと境界について深く思考している」という意思表示だ。
- `Str\contains`: `strpos(…) !== false` という冗長で分かりにくい判定を廃止し、boolを返す。
- `Str\split`: デリミタが見つからない場合の挙動が明確に定義されている。
君たちが書くコードは、次世代のエンジニアが引き継ぐ資産だ。曖昧なPHPの残滓をコードベースから駆逐し、HSLの持つ厳格で美しい型システムを最大限に活用せよ。バグはコードが書かれた瞬間に、型チェッカーによって殺されるべきなのだから。
今すぐプロジェクトの `use namespace HH\Lib\Str;` を確認せよ。そこに君の設計能力の全てが反映されているはずだ。