WEBVTT

1
00:00:00.000 --> 00:00:00.812
こんにちは。

2
00:00:00.812 --> 00:00:05.816
今回はジャバスクリプトの文字列メソッド、イズウェルフォームドを紹介します。

3
00:00:05.816 --> 00:00:09.874
これは、文字列の中に壊れた部分がないかを調べるメソッドです。

4
00:00:09.874 --> 00:00:13.323
たとえば絵文字を含む文字列を途中で切り出すと、文字を表すペアが分断され、

5
00:00:13.323 --> 00:00:16.773
片方だけが残ることがあります。

6
00:00:16.773 --> 00:00:22.589
その壊れた文字列をそのままユーアールエル変換などに渡すと、エラーになる場合があります。

7
00:00:22.589 --> 00:00:28.000
イズウェルフォームドは、そうした破損を処理の入口で早めに見つけるための道具です。

8
00:00:28.000 --> 00:00:32.599
この動画では、仕組み、基本の使い方、実例と限界までを順に解説します。

9
00:00:32.599 --> 00:00:37.468
特に外部から受け取った文字列を扱う場面を思い浮かべながら聞いてください。

10
00:00:37.468 --> 00:00:39.269
まず背景を知りましょう。

11
00:00:39.269 --> 00:00:45.872
ジャバスクリプトの文字列は、ユーティーエフじゅうろくという形式のコード単位で扱われます。

12
00:00:45.872 --> 00:00:52.175
日本語のあは一つの単位で表せますが、笑顔の絵文字は二つの単位を組み合わせて表します。

13
00:00:52.175 --> 00:00:55.177
この二つの組をサロゲートペアと呼びます。

14
00:00:55.177 --> 00:01:00.129
ペアの前半だけ、または後半だけが残った状態が、孤立サロゲートです。

15
00:01:00.129 --> 00:01:08.084
たとえば絵文字をスライスで先頭一単位だけ切り取ると、見た目の一文字を取るつもりでもペアを壊してしまいます。

16
00:01:08.084 --> 00:01:14.237
ジャバスクリプトは壊れた文字列も保持できますが、外部へ渡す変換では問題になります。

17
00:01:14.237 --> 00:01:20.840
この仕組みを知ると、なぜ一文字ずつ数える処理で絵文字がずれるのかも理解しやすくなります。

18
00:01:20.840 --> 00:01:23.590
基本の使い方はとてもシンプルです。

19
00:01:23.590 --> 00:01:28.766
調べたい文字列に続けて、イズウェルフォームドを呼び出すだけです。

20
00:01:28.766 --> 00:01:30.221
引数はありません。

21
00:01:30.221 --> 00:01:37.662
戻り値は真偽値で、孤立サロゲートが一つもなければトゥルー、一つでもあればフォルスを返します。

22
00:01:37.662 --> 00:01:39.603
空文字列もトゥルーです。

23
00:01:39.603 --> 00:01:42.352
そして、元の文字列は変更しません。

24
00:01:42.352 --> 00:01:48.013
文字数を数えるメソッドでも、文字列を書き換えるメソッドでもありません。

25
00:01:48.013 --> 00:01:53.028
また、不正な文字列だからといって例外を投げることもありません。

26
00:01:53.028 --> 00:01:58.203
結果に応じて、処理を続けるか止めるかを自分で選べる点が特徴です。

27
00:01:58.203 --> 00:02:04.188
呼び出しは一回で終わるので、条件分岐の中にそのまま書けるのも便利な点です。

28
00:02:04.188 --> 00:02:06.900
使う前に注意したいのが、入力の型です。

29
00:02:06.900 --> 00:02:13.181
イズウェルフォームドは文字列のメソッドなので、すべての値が持っているわけではありません。

30
00:02:13.181 --> 00:02:19.747
ヌルや数値を受け取る可能性がある処理では、先にタイプオブで文字列かどうかを確認してください。

31
00:02:19.747 --> 00:02:25.743
先にストリングで変換してしまうと、ヌルがヌルという四文字の文字列になってしまいます。

32
00:02:25.743 --> 00:02:28.883
それを受け入れてよいかは、業務上の判断です。

33
00:02:28.883 --> 00:02:32.737
今回の例では、文字列以外は明確に拒否する方針にします。

34
00:02:32.737 --> 00:02:37.163
型の確認と壊れ具合の確認は、別の役割として分けて考えましょう。

35
00:02:37.163 --> 00:02:42.016
入口で型をそろえておくと、後続の処理が安心して文字列として扱えます。

36
00:02:42.016 --> 00:02:43.816
対応環境を確認しましょう。

37
00:02:43.816 --> 00:02:46.862
イズウェルフォームドは比較的新しい機能です。

38
00:02:46.862 --> 00:02:53.507
クロームとエッジは百十一以降、ファイアフォックスは百十九以降、サファリは十六点四以降で使えます。

39
00:02:53.507 --> 00:02:56.276
ノードジェイエスでは二十以降が目安です。

40
00:02:56.276 --> 00:03:01.399
ブラウザーでもノードでも動き、画面操作の仕組みや外部パッケージは不要です。

41
00:03:01.399 --> 00:03:05.968
ただし、メソッドがない環境で直接呼び出すとタイプエラーになります。

42
00:03:05.968 --> 00:03:10.121
実行前に、タイプオブで関数として存在するかを確認しましょう。

43
00:03:10.121 --> 00:03:14.690
機能がないときに検証を省略して正常扱いにする設計は避けてください。

44
00:03:14.690 --> 00:03:20.228
対応状況は変わることがあるので、公開前に実際の環境で一度確かめる習慣が大切です。

45
00:03:20.228 --> 00:03:22.970
ここからは入力検証のサンプルです。

46
00:03:22.970 --> 00:03:31.358
インスペクトテキストという独自の関数を用意し、イズウェルフォームドの結果を使って判定の文字列を返します。

47
00:03:31.358 --> 00:03:32.809
流れは二段階です。

48
00:03:32.809 --> 00:03:38.132
まずタイプオブで文字列かどうかを調べ、文字列でなければ拒否します。

49
00:03:38.132 --> 00:03:44.423
次にイズウェルフォームドを呼び、壊れていれば拒否、問題なければ受理と返します。

50
00:03:44.423 --> 00:03:48.778
このサンプルは外部通信やファイル読み込みを行いません。

51
00:03:48.778 --> 00:03:52.972
ブラウザーのコンソールに貼るか、ノードジェイエスのファイルとして保存すれば、

52
00:03:52.972 --> 00:03:57.165
そのまま試すことができます。

53
00:03:57.165 --> 00:04:03.456
判定の理由が文字列で返るため、画面への表示や記録にもそのまま使いやすい形です。

54
00:04:03.456 --> 00:04:05.942
サンプルの結果を読みましょう。

55
00:04:05.942 --> 00:04:10.665
用意したのは、日本語、絵文字、空文字、前半だけ残ったもの、後半だけ残ったもの、

56
00:04:10.665 --> 00:04:15.389
途中で切断したもの、そして数値です。

57
00:04:15.389 --> 00:04:19.201
日本語と正しい絵文字、空文字は受理になります。

58
00:04:19.201 --> 00:04:26.493
一方、前半だけ、後半だけ、途中で切断した文字列は、孤立サロゲートがあるため拒否されます。

59
00:04:26.493 --> 00:04:29.310
数値は文字列ではないので拒否です。

60
00:04:29.310 --> 00:04:36.934
絵文字をコード上でエスケープ表記にしているのは、ペアの前半と後半を区別しやすくするためです。

61
00:04:36.934 --> 00:04:43.729
なお、必須項目では空文字も拒否したい場合があるので、その条件は別に加えてください。

62
00:04:43.729 --> 00:04:50.524
結果を比べると、見た目では分からない破損を真偽値で区別できることがよく分かります。

63
00:04:50.524 --> 00:04:53.536
判定せずに変換するとどうなるかを見ましょう。

64
00:04:53.536 --> 00:04:57.849
孤立サロゲートを含む文字列を、エンコードユーアールアイコンポーネントへ直接渡すと、

65
00:04:57.849 --> 00:05:02.163
ユーアールアイエラーという例外が発生します。

66
00:05:02.163 --> 00:05:06.955
変換の途中で失敗するため、処理全体が止まってしまうのが困りどころです。

67
00:05:06.955 --> 00:05:10.446
ここで大切なのは、イズウェルフォームド自体は同期処理で、プロミスを返さず、

68
00:05:10.446 --> 00:05:13.938
例外も投げないという点です。

69
00:05:13.938 --> 00:05:18.457
変換の前に真偽値で判定できれば、失敗する前に止めることができます。

70
00:05:18.457 --> 00:05:22.154
例外処理に頼る前に、事前判定を挟む発想を持ちましょう。

71
00:05:22.154 --> 00:05:26.672
失敗を先に体験しておくと、事前判定の必要性が実感として伝わります。

72
00:05:26.672 --> 00:05:28.880
事前判定の書き方は単純です。

73
00:05:28.880 --> 00:05:33.928
変換したい文字列について、まずイズウェルフォームドを確認します。

74
00:05:33.928 --> 00:05:39.449
フォルスなら、不正な文字列のため変換を中止すると伝えて処理を止めます。

75
00:05:39.449 --> 00:05:44.970
トゥルーのときだけ、エンコードユーアールアイコンポーネントへ進みます。

76
00:05:44.970 --> 00:05:52.226
こうすると、例外で突然止まるのではなく、どこで何が問題だったのかを自分の言葉で伝えられます。

77
00:05:52.226 --> 00:05:56.801
利用者向けの案内や、記録への残し方も設計しやすくなります。

78
00:05:56.801 --> 00:06:01.691
小さな一手間ですが、入力検証としてはとても効果的な使い方です。

79
00:06:01.691 --> 00:06:07.212
不正な行だけを対象にできれば、全体を止めずに運用できる場面も増えます。

80
00:06:07.212 --> 00:06:09.560
判定の限界も知っておきましょう。

81
00:06:09.560 --> 00:06:13.376
トゥルーは、孤立サロゲートがないという意味だけです。

82
00:06:13.376 --> 00:06:17.486
文字化けした文章、制御文字、見た目が似た紛らわしい文字、不適切な内容も、

83
00:06:17.486 --> 00:06:21.595
サロゲートが壊れていなければ通過します。

84
00:06:21.595 --> 00:06:26.805
また、表示上の文字数を数えること、文字列の正規化、エイチティーエムエルへ安全に出力すること、

85
00:06:26.805 --> 00:06:32.016
ユーアールエルの許可判定は、それぞれ別の問題です。

86
00:06:32.016 --> 00:06:36.419
イズウェルフォームドだけで入力検証を完結させないでください。

87
00:06:36.419 --> 00:06:39.648
ほかの検証と組み合わせて使うことが大切です。

88
00:06:39.648 --> 00:06:43.904
役割を正しく分けることが、検証漏れを防ぐ第一歩になります。

89
00:06:43.904 --> 00:06:48.160
たとえば長さの制限や必須チェックは、別途用意してください。

90
00:06:48.160 --> 00:06:50.421
最後に実務での使い方です。

91
00:06:50.421 --> 00:06:57.379
検査が活きるのは、外部データを取り込むときや、独自の文字列加工を終えた直後です。

92
00:06:57.379 --> 00:07:04.685
たとえば取り込んだ商品名を検査し、不正な行だけを修正対象として返す使い方ができます。

93
00:07:04.685 --> 00:07:12.165
ただし、検査のあとにコード単位で切り出すと、正常だった文字列を再び壊す恐れがあります。

94
00:07:12.165 --> 00:07:17.557
入口だけでなく、変換先へ渡す最終的な文字列にも適用しましょう。

95
00:07:17.557 --> 00:07:26.080
検出しても失われたペアは復元できないので、元データの再取得や修正を促す方針も決めておいてください。

96
00:07:26.080 --> 00:07:32.342
拒否理由と対象の識別子を返す形にすると、後から問題を追いやすくなります。

97
00:07:32.342 --> 00:07:33.908
お疲れさまでした。