WEBVTT

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

2
00:00:00.976 --> 00:00:07.482
今回はジャバスクリプトのテキストエンコーダー・エンコードイントゥーを紹介します。

3
00:00:07.482 --> 00:00:15.288
これは、文字列を、あらかじめ用意したバッファーへユーティーエフエイトで直接書き込むメソッドです。

4
00:00:15.288 --> 00:00:22.119
新しい配列を作るのではなく、渡したユーインティーエイトアレイの中身が書き換わります。

5
00:00:22.119 --> 00:00:27.974
戻り値では、入力をどこまで読み進めたかと、何バイト書けたかが分かります。

6
00:00:27.974 --> 00:00:33.829
この動画では、基本の使い方から、日本語と絵文字を含む文字列を小さなバッファーへ分けて書く方法、

7
00:00:33.829 --> 00:00:39.685
容量不足への対処までを、実行結果と一緒に学びます。

8
00:00:39.685 --> 00:00:43.588
ブラウザーとノード・ジェイエスの両方で使えます。

9
00:00:43.588 --> 00:00:45.352
まず、使いどころです。

10
00:00:45.352 --> 00:00:51.126
バイナリーデータを作るときは、文字列をバイト列へ変換する必要があります。

11
00:00:51.126 --> 00:01:00.909
例えば、先頭に管理情報を置き、その後ろにメッセージを入れる形式では、あらかじめ用意した領域へ文字列を書き込みたくなります。

12
00:01:00.909 --> 00:01:05.560
似たメソッドのエンコードは、毎回新しいバイト列を作ります。

13
00:01:05.560 --> 00:01:09.970
一方、エンコードイントゥーは、既存のバッファーへ直接書くので、領域の使い回しや、

14
00:01:09.970 --> 00:01:14.381
書き込む位置の指定ができます。

15
00:01:14.381 --> 00:01:20.796
通信やファイル保存で、決められたサイズの枠へデータを収める場面で役立つ違いです。

16
00:01:20.796 --> 00:01:25.928
結果は文字列ではなく、数値のバイト列になる点も押さえてください。

17
00:01:25.928 --> 00:01:28.193
引数と戻り値のルールです。

18
00:01:28.193 --> 00:01:33.594
呼び出し方は、エンコーダー・ドット・エンコードイントゥーで、括弧の中に変換したい文字列と、

19
00:01:33.594 --> 00:01:38.996
書き込み先のバッファーを渡します。

20
00:01:38.996 --> 00:01:43.351
注意したいのは、戻り値がバイト列ではないことです。

21
00:01:43.351 --> 00:01:50.146
戻り値は、リードとリトゥンという二つの数値を持つ、進捗を表すオブジェクトです。

22
00:01:50.146 --> 00:01:54.154
データ本体は、渡したバッファーの中に入ります。

23
00:01:54.154 --> 00:02:01.820
画面の例では、エーと、あ、という二文字を処理して、リードが二、リトゥンが四になりました。

24
00:02:01.820 --> 00:02:10.183
書き込まれた四バイトを取り出すと、六十五、二百二十七、百二十九、百三十という並びが確認できます。

25
00:02:10.183 --> 00:02:13.668
処理は同期で進み、プロミスは返りません。

26
00:02:13.668 --> 00:02:15.729
ここが一番のポイントです。

27
00:02:15.729 --> 00:02:19.534
入力の位置と出力の長さは、数える単位が違います。

28
00:02:19.534 --> 00:02:24.608
例として、エー、あ、笑顔の絵文字、ビー、という文字列を考えます。

29
00:02:24.608 --> 00:02:28.016
ジャバスクリプトのレングスでは、エーが一、あが一、絵文字が二、ビーが一で、

30
00:02:28.016 --> 00:02:31.425
合計五です。

31
00:02:31.425 --> 00:02:35.785
一方、ユーティーエフエイトでは、それぞれ一バイト、三バイト、四バイト、一バイトとなり、

32
00:02:35.785 --> 00:02:40.145
全体で九バイト必要です。

33
00:02:40.145 --> 00:02:48.231
ですから、残りの文字列を取り出す位置にはリードを、書き込んだ領域を取り出す長さにはリトゥンを使います。

34
00:02:48.231 --> 00:02:55.048
この二つを取り違えると、入力を飛ばしたり、不要なバイトまで渡したりする原因になります。

35
00:02:55.048 --> 00:02:56.465
対応環境を確認します。

36
00:02:56.465 --> 00:03:05.093
このメソッドは、主要ブラウザーとノード・ジェイエスの両方で利用でき、ノード・ジェイエスではバージョン十二・十一・ゼロで追加されました。

37
00:03:05.093 --> 00:03:07.540
追加パッケージやインポートは不要です。

38
00:03:07.540 --> 00:03:13.721
ただし、テキストエンコーダー自体が存在しても、エンコードイントゥーに対応しているとは限りません。

39
00:03:13.721 --> 00:03:17.327
古いブラウザーや組み込みのウェブビューを対象にする場合は、画面のように、

40
00:03:17.327 --> 00:03:20.933
メソッド自体の有無まで確認してください。

41
00:03:20.933 --> 00:03:25.698
また、テキストエンコーダーが扱う文字コードはユーティーエフエイト専用です。

42
00:03:25.698 --> 00:03:29.948
シフトジスなどを指定して出力する機能はない点も覚えておきましょう。

43
00:03:29.948 --> 00:03:32.533
記事の中心となる実行例を読みます。

44
00:03:32.533 --> 00:03:36.411
五バイトの作業用バッファーを用意し、エー、あ、絵文字、ビーという文字列を、

45
00:03:36.411 --> 00:03:40.289
繰り返し書き込んでいきます。

46
00:03:40.289 --> 00:03:44.547
各回では、オフセット以降の残りをスライスで渡し、返ってきたリードだけ入力の位置を進め、

47
00:03:44.547 --> 00:03:48.805
リトゥンを合計に加えます。

48
00:03:48.805 --> 00:03:55.953
進捗がゼロのままでは無限ループになるため、リードがゼロならエラーで止める安全策も入れています。

49
00:03:55.953 --> 00:04:02.948
このコードはノード・ジェイエスの実機でも、記事の期待出力と同じ結果になることを確認済みです。

50
00:04:02.948 --> 00:04:06.750
ブラウザーのコンソールでも、そのまま実行できます。

51
00:04:06.750 --> 00:04:10.248
次のセクションで、各回の数字を詳しく追います。

52
00:04:10.248 --> 00:04:12.306
実行結果を読み解きます。

53
00:04:12.306 --> 00:04:18.482
一回目は、エーと、あ、までが書き込まれ、リードが二、リトゥンが四でした。

54
00:04:18.482 --> 00:04:22.599
この時点でバッファーの残りは一バイトですが、次の絵文字には四バイト必要なので、

55
00:04:22.599 --> 00:04:26.716
ここで止まります。

56
00:04:26.716 --> 00:04:32.719
ユーティーエフエイトのバイト列が、文字の途中で切れることはありません。

57
00:04:32.719 --> 00:04:39.409
二回目は、残りの絵文字とビーが処理され、リードが三、リトゥンが五になりました。

58
00:04:39.409 --> 00:04:43.526
絵文字がユーティーエフシックスティーンでは二つのコード単位に数えるため、

59
00:04:43.526 --> 00:04:47.643
二回目のリードは三です。

60
00:04:47.643 --> 00:04:54.676
合計のリードが入力のレングス五と一致すれば、入力をすべて処理できたことになります。

61
00:04:54.676 --> 00:04:55.880
失敗例を見ます。

62
00:04:55.880 --> 00:04:58.739
あ、という一文字には三バイト必要です。

63
00:04:58.739 --> 00:05:06.865
二バイトしかないバッファーを渡すと、リードもリトゥンもゼロになり、バッファーの中身はゼロのまま変わりません。

64
00:05:06.865 --> 00:05:11.380
ここで大切なのは、容量不足そのものは例外にならないことです。

65
00:05:11.380 --> 00:05:15.895
エラーが出ないからこそ、戻り値を見て検出する設計が必要です。

66
00:05:15.895 --> 00:05:20.861
また、同じ入力と、同じ容量で再試行し続けても、結果は変わりません。

67
00:05:20.861 --> 00:05:28.837
容量不足を扱うときは、再試行すること自体ではなく、次の試行で容量をどう変えるかを決めておく必要があります。

68
00:05:28.837 --> 00:05:34.856
先ほどのループの進捗チェックは、この停滞を無限ループにしないための仕掛けでした。

69
00:05:34.856 --> 00:05:36.817
書き込んだ後の注意点です。

70
00:05:36.817 --> 00:05:40.587
有効な出力は、先頭からリトゥンバイトまでだけです。

71
00:05:40.587 --> 00:05:46.619
使い回したバッファーの残りの領域には、以前のデータが残っている可能性があります。

72
00:05:46.619 --> 00:05:50.691
送信や保存の対象は、必ずこの有効範囲に絞ってください。

73
00:05:50.691 --> 00:05:57.478
画面の例でも、バッファー全体にはゼロが残っていますが、正しい結果は先頭の二バイトだけです。

74
00:05:57.478 --> 00:06:03.058
もう一つ、サブアレイで切り出した部分は、元のメモリーを共有するビューです。

75
00:06:03.058 --> 00:06:10.297
切り出したつもりで保存しておいても、後からバッファーを上書きすると、中身まで変わってしまいます。

76
00:06:10.297 --> 00:06:17.988
非同期の送信へ渡す場合は、処理が終わるまで再利用を待つか、独立した配列へコピーする設計にしてください。

77
00:06:17.988 --> 00:06:21.640
容量の見積もりと、書き込み位置の指定です。

78
00:06:21.640 --> 00:06:28.595
文字列のレングスと同じバイト数では、日本語や絵文字を含む文字列を収めきれません。

79
00:06:28.595 --> 00:06:32.421
一括変換の上限の目安は、レングスの三倍です。

80
00:06:32.421 --> 00:06:41.985
ただし、大きな入力ではメモリーの消費も増えるため、小さなバッファーで分割する方式との使い分けを考えてください。

81
00:06:41.985 --> 00:06:45.115
位置の指定にはサブアレイが便利です。

82
00:06:45.115 --> 00:06:52.593
画面の例では、先頭二バイトを管理情報用に空けたビューを渡し、そこから書き始めています。

83
00:06:52.593 --> 00:06:59.722
元の配列の三バイト目に、エイチのバイト値である百四が入っていることが確認できます。

84
00:06:59.722 --> 00:07:04.765
全文が必須のデータでは、リードとレングスを照合し、未完了なら領域を広げるか、

85
00:07:04.765 --> 00:07:09.808
入力を拒否する方針も決めておきましょう。

86
00:07:09.808 --> 00:07:10.715
まとめです。

87
00:07:10.715 --> 00:07:16.912
テキストエンコーダー・エンコードイントゥーは、用意したバッファーへ文字列をユーティーエフエイトで書き込むメソッドで、

88
00:07:16.912 --> 00:07:23.109
戻り値のリードとリトゥンから進捗を確認できます。

89
00:07:23.109 --> 00:07:27.417
入力の位置はユーティーエフシックスティーンのコード単位、出力の長さはバイト数と、

90
00:07:27.417 --> 00:07:31.725
単位が違う点が最大の注意点でした。

91
00:07:31.725 --> 00:07:39.887
容量不足は例外にならず、進捗ゼロとして返ること、有効な範囲はリトゥンバイトまでであることも押さえてください。

92
00:07:39.887 --> 00:07:48.351
練習として、主例のバッファーを四バイトや九バイトに変え、各回のリードとリトゥンを予想してみると理解が深まります。

93
00:07:48.351 --> 00:07:54.700
入力と出力を別々に追えるようになると、バッファーを使う処理を組み立てやすくなります。

94
00:07:54.700 --> 00:07:56.060
お疲れさまでした。