コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Webにおけるウォーターマークに関してざっくり調べる

水滴のマークではない

Webサイト制作で語られる意味

ウォーターマークとは、主に著作権保護などの目的から、画像や映像などのデジタルコンテンツに識別用情報を追加することである。あるいは、そのようにして付け加えられた情報のことである - ウォーターマークとは 「デジタルウォーターマーク, 電子透かし」 (watermark): - IT用語辞典バイナリ

語源

もともと印刷業界の言葉

漉き桁には針金で模様がつけられ、漉きあがった紙にはその模様が紙の薄い部分として転写されました。紙を光にかざすとその部分が浮き上がって見え、この透かし模様をウォーターマークと呼んでいます。このマークにより製紙業者が特定され、紙の年代がわかるのではないかということから、20世紀に入って透かしの研究が進められています。 - 第三章 印刷とブック・デザイン | インキュナブラ

どういうものがあるか

著者を示すウォーターマーク

一般的に画像などに施すウォーターマークは誰が権利者か、というのを記載している。画像などにおいてはシンプルで自分の著作物である旨の情報を重ねて記載するケースが多い。

その場合、技術的に何か特殊なアプローチを施すのではなく、画像のレイヤとして一枚足してあげるなどの手法を取る。絵画の作者サインなどに近い考え方。

具体のやり方は参考リンクを参照のこと。

不正使用の出元を特定する電子透かしとしてのウォーターマーク

コンテンツを見る人には一見してわからない技術的なウォーターマークも存在する。

電子透かしで著作権者の情報や,提供 先に関わる情報を埋め込むことで,けん制効果によ り違法行為を抑止することが可能となる)。(中略) コンテンツが誰の著作物かという著作権者情報 を埋め込む方法は,固定的な情報をあらかじめ埋め 込んでおくことができるため,システムは簡単で作 業負荷も少ないが,流出時には誰が流出させたのか まではわからず,抑止力も限定的である。一方,コンテンツを誰に渡したかという提供先情 報を埋め込む方法は,流出元を特定することができ, 強力な抑止力となる。- 電子透かしによる著作権保護への取り組み

上記にあるように「誰の著作物か」を示すものではなく、「不正拡散の出元はどこかを書き足すことによってコピーをしづらくさせる、特定させやすくする」というアプローチ。ただこの場合は、誰でも同じ手法でできてしまうと、効力がなくなるので、下記のようなアプローチをとる

また,映像,画像,電子書籍に埋 め込まれた電子透かしは人の目に見えず,音声に埋 め込まれた電子透かしは人の耳には聞こえない。ど こに埋め込まれているかはわからないという点では, 目には見えるが技術的に複製が困難なことで偽造を 防止する紙幣の透かしとは考え方が異なる。電子デー タにおいては,どこに埋め込まれているかがわかる と,埋め込まれた情報の除去や改ざんが容易にでき てしまうため,アルゴリズムは非公開とし,限られ た人しか埋め込み・検出もしくは除去ができないよ うにするのである - 電子透かしによる著作権保護への取り組み

上記の通り、コンテンツ内にアルゴリズムを非公開にした形で情報を埋め込むことで容易に透かしの施しそのものをさせないというアプローチ

参考リンク

英単語の間に数字を入れて略すことをヌメロニム(数略語)という

i18nとかk8sとか

意味

数略語は、長い英単語を数字で省略して表現する語。 - ヌメロニム - Wikipedia

初出

英語版のwikipediaから出典をたどると以下のエピソードが出てくる

JanScherpenhuizen という名前のDECの従業員は、名前が長すぎてアカウント名ではないため、システム管理者からS12nの電子メールアカウントを与えられました。長い名前を短縮するこのアプローチは、ユーモラスなものであることが意図され、DECで一般化されました。条約は、1985年までに数字を使用していたDECの「国際化」に適用されました 。用語の使用は広まりました。 - Origin Of The Abbreviation I18n For Internationalization

代表的なヌメロニム

ヌメロニム表記 正式名称
i18n internationalization
g11n globalisation / globalization
a11y accessibility
l10n localisation
p13n personalization
m12n modularisation / modularization

参考サイト

ダブルチェックが有効なものは何かを考えるときにみたい資料『ダブルチェックの有効性を再考する』

ダブルチェックって再発防止に有効なんだっけ?を考えるときに役に立つ知識を。

資料スライド

https://kouseikyoku.mhlw.go.jp/shikoku/kenko_fukushi/000085434.pdf

読みどころ

この資料は主に医療現場におけるダブルチェックの有用性に関しての資料なのですが、すべてのオペレーションに共通するエッセンスも含んでいます。

資料内ではダブルチェックするべき内容に関して思考プロセスから考えるアプローチをとっており、内容としては2つあります。

名称 内容
システム1 速い思考。自動的に高速に働く思考モード。自動運転。省エネモード。
システム2 遅い思考。複雑な計算など頭を使わなければできない困難な知的活動にしかるべき注意を払う思考モード。

このシステム1(単純作業)とシステム2(認知的作業)と分けた際に、システム2の場合はダブルチェックが有効であるが、単純作業ではダブルチェックを用いてエラー検出するのは有効ではない、という話となっている。

ダブルチェックに関しても有効に働かせるためにはどうしたらいいか、単純作業のエラーを減らすにはどうしたらいいかが医療現場の実例に基づいて説明がされているので、具体例から自分の体験にも落としやすい資料となっている。

関連サイト

HTMLでスライダーUIを作りたいときはinputタグのrangeタイプで作れる

マジでググってすぐ出てこず、jqueryの方ばかり出てきて、自分の記憶違いを疑ったのでメモ

参照元

< input type="range" > - HTML: HyperText Markup Language | MDN

スライダーの定義

今回とりあげる「スライダー」は以下の意味のもの

つまみを直線移動させる入力機器またはウィジェット (GUI)。 - スライダー - Wikipedia

「カルーセルスライダー」の略称として「スライダー」が用いられることがあるが、今回は別のものとする。

HTML例

See the Pen range sample by しんくう (@shinkufencer) on CodePen.

属性の詳細はMDNのドキュメントのほうが詳しくのっているので、そちらを参照してほしいですが、よく使う属性としては以下のようなものがある。

  • 値の最高値と最低値の maxmin
  • 初期値の設定の value
  • スライドの幅の単位を設定する step

注意点

通常の <button>要素同様にWebブラウザによってスライダーのトグルなどのUIパーツの絵は異なる。そのため、CSSで同じ形になるように整える必要がある

参考サイト

RailsのActiveRecordでは add_column するときに after を指定すると追加するカラム位置がコントロールできる

主にMySQL向け

環境

rails (5.0.2)

やり方

カラム追加の記述の場合にafterを指定する。

name というカラムのあとに profile_text というカラムを足したい場合

class AddColumnHogeHoge < ActiveRecord::Migration[5.0]
  def change
    add_column :users, :profile_text, :string, after: :name, default: "", null: false
  end
end

原理

以下メソッドに記述があるとおり、AFTER文を継ぎ足している。そのため、AFTER文の概念がないpostgresqlにはできない。

def add_column_position!(sql, options)
if options[:first]
  sql << " FIRST"
elsif options[:after]
  sql << " AFTER #{quote_column_name(options[:after])}"
end

from: rails/schema_creation.rb at 36a6d935d2994e776054797be3c00cd50c19b1e9 · rails/rails

参考リンク

色覚多様性(色覚特性)を鑑みた見え方をチェックするときに便利なスマホアプリ「色のシュミレータ」

便利だったのでメモ的に

公式サイト

色のシミュレータ

このアプリでできること

公式サイトに記載のある通り

1型(P型)、2型(D型)、3型(T型)の2色覚の色の見えをリアルタイムに確認し、一般型(C型)の色の見えと比較することができます。 - 色のシミュレータ

一般的な普通の人が感じると言われている「C型」と他の見え方と窓を分割して確認することができる・

補足:それぞれの型の意味

ざっくりとした説明でいくと以下の通り

型名 特徴
P型 赤色の光を感じる力がない、もしくは感じる力が弱く暗く感じる
D型 緑色の光を感じる力がない、もしくは感じる力が弱く暗く感じる
T型 青色の光を感じる力がない、もしくは感じる力が弱く暗く感じる
A型 3種類の光を感じる力のうち、2つがない、もしくは全てがないため、明暗でしか判断ができない

C型を除き、多いとされているのはP型とD型

参考リンク

MySQL5.6にてひらがなとカタカナを同一のものとして検索するためにcollationsを使うのはリスクが多いのでメリット・デメリットを把握する

あいまい検索を実装する際に安易に飛びつくとやけどする気がするのでまとめた。

環境

今回はMySQL5.6のドキュメントをベースにしているためそちらの前提で記載しています。

そもそもMySQLのcollationsとは

日本語で表現すると「照合順序」という言葉になり。MySQLのヘルプには以下のように書かれている。

照合順序とは、文字セット内の文字を比較するためのルールを集めたものです。(中略)また実際には、ほとんどの照合順序は、大文字と小文字の区別だけでなく、アクセント符号 (「アクセント符号」とはドイツ語の「Ö」に見られるような文字に付けられた符号です) を区別するかどうかに関するルールや、複数文字のマッピングのルール (2 つのドイツ語の照合順序の一方における「Ö」 = 「OE」というルールなど) など多くのルールを含んでいます。 - MySQL :: MySQL 5.6 リファレンスマニュアル :: 10.1.1 一般の文字セットおよび照合順序

ざっくりとして意味としては並び替えをするルールであり「文字の並び順」と「どの文字を同一とみなすか」を決めるルールの集まり。

Unicodeにおける照合順序

基本は文字コードと照合順序はセットなので、文字コードごとに照合順序は存在する。Unicode(utf8/utf8mb)の場合はバリエーションが色々あるが、今回取り上げるのは以下のもの

  • utf8_bin
  • utf8_general_ci(デフォルト)
  • utf8_unicode_ci

*_bin命名規則文字の比較は、文字バイナリコード値に従って行われます。 と定義されており、文字のバイナリコードが合うものを同列とし、そのバイナリコードの順番で並べる。

それと比較して、*_ci命名規則大文字と小文字を区別しない照合順序を示します。と定義されており、「a」と「A」を同列で扱うような挙動をする。

そのなかでも general_ciunicode_ci は挙動が違う。ヘルプでは以下のように記載されている。

Unicode 文字セットの場合、xxx_general_ci 照合順序を使用して実行する演算は、xxx_unicode_ci 照合順序のものよりも高速です。たとえば、utf8_general_ci 照合順序の比較は、utf8_unicode_ci の比較よりも高速ですが、精度は少し低くなります。この理由は、utf8_unicode_ci では、ある文字がほかの文字の組み合わせに等しいものと見なされる拡張形式などのマッピングをサポートしているためです。たとえば、ドイツ語とほかのいくつかの言語では、「ß」は「ss」と同じです。utf8_unicode_ci は、短縮形式と無視可能な文字もサポートします。utf8_general_ci は、拡張形式、短縮形式、無視可能な文字をサポートしない従来の照合順序です。文字間で 1 対 1 の比較しかできません。 - MySQL :: MySQL 5.6 リファレンスマニュアル :: 10.1.14.1 Unicode 文字セット

上記のように unicode_ci は同一視される言語を同じ単語とするようにみなしているが、general_ci のほうは単純な大文字と小文字を同列にみなす程度のサポートしかしていないというもの

5.5のものだが、同一視される文字の一覧を見ると、「8」と「⑧」や「ル」と「ル」同一のものとみなされるなどが例に出されている。

unicode_ciによって起きるははパパ問題

ここまでの話を切り取ると「よしなに同一視しても問題ないものは unicode_ci のほうがよさそう」というように見えるが、実際はそんなに都合のいいものではなく、日本語的にはあんまり同一視してほしくないものも同一視する。

たとえば以下のようなもの

  • 「は」と「パ」
  • 「⺝」と「⽉」
  • 「⻯」と「⿓」

物によっては上記のようなものを同一視しても問題ないケースがあるかもしれないが、「は」などに関してはあとあと問題になるケースが多いと思われる。(これを「はは=パパ」問題と呼称したりする)

では general_ci ではどうか、というと今度は寿司ビール問題が発生する。

general_ciにすると起きる寿司ビール問題

寿司ビール問題というのは俗称で、🍣と🍺が同一の文字とみなされてしまう問題。

事象の原因としてはかみぽさんの記事に和訳があるのでそれを引用させてもらうと以下の通り

BMP文字で general collation (xxx_general_ci) の場合、コードポイントを使う。
・SMP文字(絵文字とか)の場合、0xfffd REPLACEMENT CHARACTER と同じ weight になる- MySQL と寿司ビール問題 - かみぽわーる

ということで絵文字はすべて同一とみなされてしまう。(なお、REPLACEMENT CHARACTERに関してはこちらを参照のこと)

そのため昨今の絵文字が日常的に使われる場面では _bin の照合順序にするほうが良いケースが多い

余談:MySQL8では

MySQL8系ではこの問題をカバーした utf8mb4_ja_0900_as_cs が登場している。こちらに関してはははパパ問題も寿司ビール問題も解決しているし、aとAを同一のものと解釈もする。詳しくは下記ブログ参照のこと。

日々の覚書: MySQL 8.0.1でutf8mb4_ja_0900_as_csが導入された

関連リンク