【システム】濁点分解問題について

[tnagatomi]

（このIssueはRedmineのチケットから移行されています）

作成者: Hirao Yusuke
作成日: 2015/07/10 17:07

h1. 濁点分解問題

まず、HTMLの問題として以下があります。

• テキストに「分解された濁点」が入り込んだ場合特定のWebフォントで平音文字と濁点がそれぞれ一文字分で表示される
• Windows7 IE11で「分解された濁点」を含むテキストがGoogle Webフォントの Notoフォント日本語版 はタグごと消滅する（display: none）と同じ状態

「が」→「か + \u3099」になる現象
JavaScriptで "が".length とすると2が返ってくる

h2. 「分解された濁点」が管理画面から入力される可能性がある

Mac OSでPDFからコピーした濁音文字が平音文字と濁点に分解されることがある。
デバイスフォントでは見た目は全く同じなので、管理画面上では全く気づけない。

h2. 相談点

• 自動変換を行うべきかどうか
• 自動変換はどの段階で行われるべきか（入力時にJSで、もしくは登録された時にPHPで）

原稿がPDFで、Macで入力を行った場合に容易に起こりうる事象で
Notoフォント + Window7 IE11では要素が消えるので怖いです

[tnagatomi]

投稿者: 滝下 真玄
投稿日: 2015/07/10 09:04:36

私は利用側がケアする問題なのではと思います。ページのビューファイルを直接編集して、「固定ページテンプレート読込」とかの運用をされている方もいるとおもいますが(自分はこの方法がメインです)、この場合はDB登録前に置換処理をする必要がありそうですね。また、AAとかで意図的にやっている場合に強制置換されてしまうことも考えられます。

[tnagatomi]

投稿者: 権藤 隆行
投稿日: 2015/07/10 09:52:58

私の意見させていただきます。

データの保全性を高くするためにINPUTの情報を変換することは出来るかぎりやめたほうがいいと思います。というのも、入力可能なものはユーザが意図して入力している可能性があるからです。




対応する場合については、今回の状況においてはGoogleフォントという限定的な状況で発生していることからコアにて対応すべきではないと思います。必要であればコアではなく、プラグインなりで分離してOUTPUT時に対応することが望ましいかと思います。