VIDEO LESSON

JavaScriptのisWellFormed()：孤立サロゲートを検出して文字列の破損を見つけるの解説動画

再生時間 7:34動画を別のタブで開く ↗

動画の字幕・文字起こしを読む

再生中の字幕を濃い黒で表示し、一番上に追従します。字幕の行を選ぶと、その位置から再生できます。

0:00こんにちは。
0:00今回はジャバスクリプトの文字列メソッド、イズウェルフォームドを紹介します。
0:05これは、文字列の中に壊れた部分がないかを調べるメソッドです。
0:09たとえば絵文字を含む文字列を途中で切り出すと、文字を表すペアが分断され、
0:13片方だけが残ることがあります。
0:16その壊れた文字列をそのままユーアールエル変換などに渡すと、エラーになる場合があります。
0:22イズウェルフォームドは、そうした破損を処理の入口で早めに見つけるための道具です。
0:28この動画では、仕組み、基本の使い方、実例と限界までを順に解説します。
0:32特に外部から受け取った文字列を扱う場面を思い浮かべながら聞いてください。
0:37まず背景を知りましょう。
0:39ジャバスクリプトの文字列は、ユーティーエフじゅうろくという形式のコード単位で扱われます。
0:45日本語のあは一つの単位で表せますが、笑顔の絵文字は二つの単位を組み合わせて表します。
0:52この二つの組をサロゲートペアと呼びます。
0:55ペアの前半だけ、または後半だけが残った状態が、孤立サロゲートです。
1:00たとえば絵文字をスライスで先頭一単位だけ切り取ると、見た目の一文字を取るつもりでもペアを壊してしまいます。
1:08ジャバスクリプトは壊れた文字列も保持できますが、外部へ渡す変換では問題になります。
1:14この仕組みを知ると、なぜ一文字ずつ数える処理で絵文字がずれるのかも理解しやすくなります。
1:20基本の使い方はとてもシンプルです。
1:23調べたい文字列に続けて、イズウェルフォームドを呼び出すだけです。
1:28引数はありません。
1:30戻り値は真偽値で、孤立サロゲートが一つもなければトゥルー、一つでもあればフォルスを返します。
1:37空文字列もトゥルーです。
1:39そして、元の文字列は変更しません。
1:42文字数を数えるメソッドでも、文字列を書き換えるメソッドでもありません。
1:48また、不正な文字列だからといって例外を投げることもありません。
1:53結果に応じて、処理を続けるか止めるかを自分で選べる点が特徴です。
1:58呼び出しは一回で終わるので、条件分岐の中にそのまま書けるのも便利な点です。
2:04使う前に注意したいのが、入力の型です。
2:06イズウェルフォームドは文字列のメソッドなので、すべての値が持っているわけではありません。
2:13ヌルや数値を受け取る可能性がある処理では、先にタイプオブで文字列かどうかを確認してください。
2:19先にストリングで変換してしまうと、ヌルがヌルという四文字の文字列になってしまいます。
2:25それを受け入れてよいかは、業務上の判断です。
2:28今回の例では、文字列以外は明確に拒否する方針にします。
2:32型の確認と壊れ具合の確認は、別の役割として分けて考えましょう。
2:37入口で型をそろえておくと、後続の処理が安心して文字列として扱えます。
2:42対応環境を確認しましょう。
2:43イズウェルフォームドは比較的新しい機能です。
2:46クロームとエッジは百十一以降、ファイアフォックスは百十九以降、サファリは十六点四以降で使えます。
2:53ノードジェイエスでは二十以降が目安です。
2:56ブラウザーでもノードでも動き、画面操作の仕組みや外部パッケージは不要です。
3:01ただし、メソッドがない環境で直接呼び出すとタイプエラーになります。
3:05実行前に、タイプオブで関数として存在するかを確認しましょう。
3:10機能がないときに検証を省略して正常扱いにする設計は避けてください。
3:14対応状況は変わることがあるので、公開前に実際の環境で一度確かめる習慣が大切です。
3:20ここからは入力検証のサンプルです。
3:22インスペクトテキストという独自の関数を用意し、イズウェルフォームドの結果を使って判定の文字列を返します。
3:31流れは二段階です。
3:32まずタイプオブで文字列かどうかを調べ、文字列でなければ拒否します。
3:38次にイズウェルフォームドを呼び、壊れていれば拒否、問題なければ受理と返します。
3:44このサンプルは外部通信やファイル読み込みを行いません。
3:48ブラウザーのコンソールに貼るか、ノードジェイエスのファイルとして保存すれば、
3:52そのまま試すことができます。
3:57判定の理由が文字列で返るため、画面への表示や記録にもそのまま使いやすい形です。
4:03サンプルの結果を読みましょう。
4:05用意したのは、日本語、絵文字、空文字、前半だけ残ったもの、後半だけ残ったもの、
4:10途中で切断したもの、そして数値です。
4:15日本語と正しい絵文字、空文字は受理になります。
4:19一方、前半だけ、後半だけ、途中で切断した文字列は、孤立サロゲートがあるため拒否されます。
4:26数値は文字列ではないので拒否です。
4:29絵文字をコード上でエスケープ表記にしているのは、ペアの前半と後半を区別しやすくするためです。
4:36なお、必須項目では空文字も拒否したい場合があるので、その条件は別に加えてください。
4:43結果を比べると、見た目では分からない破損を真偽値で区別できることがよく分かります。
4:50判定せずに変換するとどうなるかを見ましょう。
4:53孤立サロゲートを含む文字列を、エンコードユーアールアイコンポーネントへ直接渡すと、
4:57ユーアールアイエラーという例外が発生します。
5:02変換の途中で失敗するため、処理全体が止まってしまうのが困りどころです。
5:06ここで大切なのは、イズウェルフォームド自体は同期処理で、プロミスを返さず、
5:10例外も投げないという点です。
5:13変換の前に真偽値で判定できれば、失敗する前に止めることができます。
5:18例外処理に頼る前に、事前判定を挟む発想を持ちましょう。
5:22失敗を先に体験しておくと、事前判定の必要性が実感として伝わります。
5:26事前判定の書き方は単純です。
5:28変換したい文字列について、まずイズウェルフォームドを確認します。
5:33フォルスなら、不正な文字列のため変換を中止すると伝えて処理を止めます。
5:39トゥルーのときだけ、エンコードユーアールアイコンポーネントへ進みます。
5:44こうすると、例外で突然止まるのではなく、どこで何が問題だったのかを自分の言葉で伝えられます。
5:52利用者向けの案内や、記録への残し方も設計しやすくなります。
5:56小さな一手間ですが、入力検証としてはとても効果的な使い方です。
6:01不正な行だけを対象にできれば、全体を止めずに運用できる場面も増えます。
6:07判定の限界も知っておきましょう。
6:09トゥルーは、孤立サロゲートがないという意味だけです。
6:13文字化けした文章、制御文字、見た目が似た紛らわしい文字、不適切な内容も、
6:17サロゲートが壊れていなければ通過します。
6:21また、表示上の文字数を数えること、文字列の正規化、エイチティーエムエルへ安全に出力すること、
6:26ユーアールエルの許可判定は、それぞれ別の問題です。
6:32イズウェルフォームドだけで入力検証を完結させないでください。
6:36ほかの検証と組み合わせて使うことが大切です。
6:39役割を正しく分けることが、検証漏れを防ぐ第一歩になります。
6:43たとえば長さの制限や必須チェックは、別途用意してください。
6:48最後に実務での使い方です。
6:50検査が活きるのは、外部データを取り込むときや、独自の文字列加工を終えた直後です。
6:57たとえば取り込んだ商品名を検査し、不正な行だけを修正対象として返す使い方ができます。
7:04ただし、検査のあとにコード単位で切り出すと、正常だった文字列を再び壊す恐れがあります。
7:12入口だけでなく、変換先へ渡す最終的な文字列にも適用しましょう。
7:17検出しても失われたペアは復元できないので、元データの再取得や修正を促す方針も決めておいてください。
7:26拒否理由と対象の識別子を返す形にすると、後から問題を追いやすくなります。
7:32お疲れさまでした。

日本語字幕をダウンロード（WebVTT）

この動画で学べること

String.prototype.isWellFormed()で不正なUTF-16文字列を検出する方法を解説。引数・戻り値、ブラウザーとNode.jsの実行手順、期待出力、入力検証の実例と判定の限界を学べます。

解説記事・サンプルコードを読む：JavaScriptのisWellFormed()：孤立サロゲートを検出して文字列の破損を見つける →