ふりがな付きHTML文書に対する文字列探索の過去と未来

第65回 プログラミング・シンポジウム 山内奨励賞受賞講演
https://prosym.org/65/program.html#day2
https://prosym.org/awards/

Transcript

1. ふりがな付きHTML文書に対する文字列探索の 過去と未来 第 65 回 プログラミング・シンポジウム 齋藤 ただし 匡 1 岩崎 英哉2 2024 年 1 月 7 日 1 電気通信大学 大学院情報理工学研究科 博士後期課程 2 年 2 明治大学 理工学部
2. 発表の概要 昨年の発表と論文「ふりがな付き HTML 文書に 対する文字列探索」に対して「山内奨励賞」を いただくこととなり，深く感謝申し上げます． 発表の全体は大きく 2 つに分かれます． 1. 前回発表の要約・振り返り 2. 過去の経緯・未来への展望 1 / 17
3. ふりがなとは ふりがなは日本語に欠かせない存在．漢字の読みを仮名で注釈するためによ く用いられる．ふりがなで注釈される文字は 親文字と呼ばれる． わがはい は 吾輩 ふりがな 親文字 利用例 • 難読漢字の読み • 日本語・漢字の学習 • 文芸作品での特徴的な表現 近年，HTML を通して Web ページでふ りがなに触れる機会も増えている． 2 / 17
4. ‌ <ruby> ‌ タグ HTML のふりがなは ‌ <ruby> ‌ タグで表す． 例えば， ‌ ‌ ‌ わがはい ‌ ‌ 吾輩 ‌ ‌ は ‌ は以下のように表現する． ‌ ‌ <ruby> ‌ 吾輩 ‌ ‌ <rp>（</rp> ‌ ‌ <rt>わがはい</rt> ‌ ‌ <rp>）</rp> ‌ </ruby> ‌ は ‌ ‌ <ruby> ‌ ふりがな・親文字の全体 ‌ <ruby> ‌ 直下 親文字 ‌ <rt> ‌ ふりがな ‌ <rp> ‌ 古いブラウザ用， ‌ <ruby> ‌ 対応ブラウザでは無視 これらの入れ子になった 4 要素によって ‌ <ruby> ‌ タグ全体が成り立つ． 3 / 17
5. 主要ブラウザの問題点 現在普及する主要なブラウザ 3 つは，ふりがなのページ内検索においてそれ ぞれ，別の問題を抱えている． Google Chrome 120 の例 Chrome ‌ <ruby> ‌ の各要素やタグの前後を跨ぐ検索 がマッチしない ‌ わがはい ‌‌ 吾輩 ‌‌ は... ‌ Firefox ふりがながテキストにならない ‌ 吾輩は... ‌ Safari 親文字とふりがなが 1 つのテキストとし て連結される ‌ 吾輩わがはいは... ‌ 4 / 17
6. 本研究の目的 ふりがな付き HTML 文書での自然な文字列探索を実現し， 主要ブラウザすべての問題を解決する 方針 • 「自然な文字列探索」として望ましい挙動を考察・定義 • ふりがなに適したデータ構造・アルゴリズムを設計 • すぐ使い始められる JavaScript ライブラリとして実装 5 / 17
7. 望ましい挙動の考察 「親文字」と「ふりがな」は区別せず検索できることが望ましい． ユーザが「親文字か，ふりがなか」 「タグの境界を跨ぐか」といった条件まで 悩むべきではない． • 任意の箇所・数の ‌ <ruby> ‌ 内部をテキストと見做す • 親文字とふりがなを「重なった」文字列として対等に探索する 6 / 17
8. テキスト構造の再考 ふりがな付きテキスト全体を分岐・合流する文字列であると捉える． わがはい ねこ なまえ な ⋯⋯ は はまだ である� �輩 � 名前 � い�⋯⋯ ⋯⋯ • 内部に通常の文字列を複数持つ • 冒頭の「は」は，親文字「猫」 ・ふりがな「ねこ」の両方へつながる • 親文字・ふりがなの両方が後続の「である。」へつながる このようなグラフ構造を分岐文字列と呼ぶ． 7 / 17
9. 分岐文字列の探索 (1) 力任せ法 安直に連結して通常文字列にすると，分岐数に対し O(2n) 個の文字列が必要 となる．そのため，グラフ構造を保ったままの探索を実装した． ねこ 猫 は である。 8 / 17
10. 分岐文字列の探索 (1) 力任せ法 安直に連結して通常文字列にすると，分岐数に対し O(2n) 個の文字列が必要 となる．そのため，グラフ構造を保ったままの探索を実装した． ねこ 猫 は である。 ① ③ ② ④ 8 / 17
11. 分岐文字列の探索 (1) 力任せ法 安直に連結して通常文字列にすると，分岐数に対し O(2n) 個の文字列が必要 となる．そのため，グラフ構造を保ったままの探索を実装した． ねこ 猫 は である。 ① ③ ② ④ 1 1 1 1 2 3 4 2 ただし，力任せで列挙するのは探索開始位置のみ．そこから JS の組込文字列 関数 ‌ startsWith() ‌ を利用し，効率化を図った． 8 / 17
12. 分岐文字列の探索 (2) 力任せ法の改良 パターンの 1 文字目が各通常文字列に含まれている場合のみ，残りの探索を 行うよう改良を施した．判定には組込の ‌ indexOf() ‌ を活用した． ねこ 猫 は である。 ① ③ ② ④ 1 パターンが ‌ ねこである ‌ の場合， ‌ indexOf() ‌ をノード数 = 4 回分呼び出した 後は，従来 8 回だった探索の開始が 1 回で済む． 9 / 17
13. 実装 有効性評価のため，JavaScript ライブラリ Ruby Finder として実装した． 一般ユーザの利用例 (Firefox 121) • DOM ノードから分岐文字列を構築・探索 • ブラウザで動作する通常のライブラリ • 外部依存はなく，ページへの組込が容易 • 主要 3 ブラウザすべてで動作確認済み 10 / 17
14. 評価: 概要 文字列探索実行の時間を計測した．現実的なサイズ (約 44 KB) の短編小説 「手紙」に対し，パターン 2 文字を 10 回探索した平均時間 (マイクロ秒)． 探索方式 Firefox Chromium WebKit 力任せ 16,042 33,738 18,598 改良力任せ 4,315 1,819 3,376 （組み込み） 912 471 480 • 力任せ法: 最悪でも約 0.034 秒，十分実用的 • 改良力任せ法: 最大で 18.5 倍以上の高速化 • (組み込み): 連結済みの通常文字列による参考値 • 現状の Safari と同等のもの．例 ‌ 吾輩わがはいは猫ねこである ‌ 11 / 17
15. まとめ • ふりがな付き文書での自然な文字列探索を考察 • ふりがな付き HTML 文書の文字列探索手法を設計・実装 • 評価によって望ましい探索結果と十分な性能を確認 今後の課題 • オープンソースソフトウェアとして公開 • アルゴリズムの改良 • HTML 以外の領域への応用 12 / 17
16. 過去の経緯・未来への展望
17. 前回の議論 発表での質疑とその後を含め，多くの有益なコメントをいただいた． • W3C による Issue ページ • 各ブラウザのバグトラッカーページ • Q. 複数の親文字・ふりがなの対応を自動で割り振れないか? A. HTML での構造を保つ前提で実装を行ったため未検討 A2. 「 き ょ う 今日」のような「熟字訓」を考えると，分割は困難 自由闊達で興味深い意見交換と雰囲気に勇気付けられた． 13 / 17
18. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 2018 プ ロ シ ン で の 発 表 14 / 17
19. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 2018 プ ロ シ ン で の 発 表 14 / 17
20. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 最 初 の コ ミ ッ ト 2018 プ ロ シ ン で の 発 表 14 / 17
21. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 最 初 の コ ミ ッ ト ～ 大 半 を 実 装 2018 プ ロ シ ン で の 発 表 14 / 17
22. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 最 初 の コ ミ ッ ト ～ 大 半 を 実 装 大 学 院 へ 入 学 2018 社会人 学生 プ ロ シ ン で の 発 表 14 / 17
23. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 最 初 の コ ミ ッ ト ～ 大 半 を 実 装 大 学 院 へ 入 学 2018 社会人 学生 指 導 教 員 (共 著 者 ) に 相 談 ? プ ロ シ ン で の 発 表 14 / 17
24. 発表までの経緯 (1) 完全な「趣味のプログラム」のつもりで，登壇・発表という予定もなく， ローペースな開発だった． 2019 2020 2021 2022 2023 趣 味 の サ イ ト 製 作 ～ 問 題 を 自 覚 最 初 の コ ミ ッ ト ～ 大 半 を 実 装 大 学 院 へ 入 学 2018 社会人 学生 指 導 教 員 (共 著 者 ) に 相 談 ? 久 々 に 開 発 ， 現 状 を ま と め る プ ロ シ ン で の 発 表 14 / 17
25. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • 自分にとっての JS:「カーソルを猫が追いかける」 「画面に雪を降らせる」 ⇒ 人気のある言語の新しい機能を全く知らなかった，知りたい 2019 2020 2021 2022 2023 問 題 の 自 覚 2018 プ ロ シ ン で の 発 表 15 / 17
26. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • せっかくなので，新しい言語仕様・機能を使ってみよう 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses 2018 プ ロ シ ン で の 発 表 15 / 17
27. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • せっかくなので，新しいツールでテストしてみよう 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses +Puppeteer で ユ ニ ッ ト テ ス ト 2018 プ ロ シ ン で の 発 表 15 / 17
28. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • =⇒ 思ったより新し過ぎて定番ツールが使えず，自分で治す 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses +Puppeteer で ユ ニ ッ ト テ ス ト +M ocha に 手 パ ッ チ 2018 プ ロ シ ン で の 発 表 15 / 17
29. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • 新しいツールでもっとたくさんの環境を 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses +Puppeteer で ユ ニ ッ ト テ ス ト +M ocha に 手 パ ッ チ Playw right 化 で 3 ブ ラ ウ ザ 対 応 2018 プ ロ シ ン で の 発 表 15 / 17
30. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • 定番に変化があったので移行しよう 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses +Puppeteer で ユ ニ ッ ト テ ス ト +M ocha に 手 パ ッ チ Playw right 化 で 3 ブ ラ ウ ザ 対 応 Jest に 乗 り 換 え 2018 プ ロ シ ン で の 発 表 15 / 17
31. 発表までの経緯 (2) 技術要素 「趣味のプログラム」として，技術要素の選定で大いにリスクを冒した． • =⇒ 新しければより良くなるとは限らない 2019 2020 2021 2022 2023 問 題 の 自 覚 最 初 か ら ES M odules+C lasses +Puppeteer で ユ ニ ッ ト テ ス ト +M ocha に 手 パ ッ チ Playw right 化 で 3 ブ ラ ウ ザ 対 応 Jest に 乗 り 換 え ， 少 し 遅 く な る 2018 プ ロ シ ン で の 発 表 15 / 17
32. 未来への展望: 1 年間での差分 1. オープンソースソフトウェア化 • 自分にとっての “MVP” (Minimum-Viable Product): ハイライトできる • 手を付けると思った以上に辛く，一区切りまでの足枷に • =⇒ 来月 20 日ごろ楽に (CSS Custom Hightlight API) 2. アルゴリズムの改良 • KMP の利用に挑戦 =⇒ 間に合わず⋯⋯ • 途中だが，改良に必要な理解・仮説が得られたのは成果 16 / 17
33. 未来への展望: 中途成果・まとめ • あと一日 (×n) で動きそうな実装 • 現実 (Chrome/V8 実装) の ‌ startsWith ‌ の複雑さ • BM 法/BMS 法を含めて場合分けが 6 つ • 仮説: 失敗時の情報が豊富な KMP 関数が内部に必要? • 成功時よりも失敗時のインデックスが欲しい まとめ • 知らない技術を学ぶのは楽しい • プログラミングは楽しい ねこ 猫 は である。 ① ③ ② ④ 1 1 1 1 2 3 4 2 17 / 17