List of Normalization [text.Baldanders.info]

GNKF 最初のリリース

2020-07-30T13:49:26+00:00

貴方は3年前に書いた自分のコードにウンザリしたことはありませんか。私はあります。それもしょっちゅう（笑）まぁ，3年前と今とで同じコードを書いてたら，それはそれで進歩がないっちう話だけど。

閑話休題 (それはさておき) 。

3年前に最初のリリースを公開した「nkf っぽいなにか」はあまりにコードの出来が悪すぎてメンテする気も起こらなくなったので，リポジトリを放棄して新たに作り直すことにした（☆を付けてくださってる方，ごめんなさい）。

spiegel-im-spiegel/gnkf: Network Kanji Filter by Golang

元のコードの70%くらいは捨てました（笑）

詳しい使い方は以下を参考にどうぞ。

GNKF: Network Kanji Filter by Golang

これでようやく「かなカナ変換」や「康熙部首の正規化」を組み込めた。

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

GNKF: Network Kanji Filter by Golang

2020-07-30T13:41:38+00:00

goark/gnkf: Network Kanji Filter by Golang

gnkf は，コマンドラインで動作する，特に日本語テキストを操作するためのフィルタプログラムである。昔からある nkf コマンドの劣化コピー版と思っていただければ概ね間違いない（笑）

gnkf には以下の機能を組み込んでいる。

以降からもう少し詳しく紹介する。

文字エンコーディングの推測

$ gnkf guess -h
Guess character encoding of the text

Usage:
  gnkf guess [flags]

Aliases:
  guess, g

Flags:
      --all           print all guesses
  -f, --file string   path of input text file
  -h, --help          help for guess

Global Flags:
      --debug   for debug

たとえば以下のように使う。

$ echo こんにちは，世界 | gnkf g
UTF-8

元祖 nkf コマンドは改行コードの推測も行うが， gnkf では文字エンコーディングの推測のみ行う。テキスト全文を一旦メモリ内に読み込むので，巨大ファイルを扱う場合はご注意を。

文字エンコーディングの推測には saintfish/chardet パッケージを使っているが，正直に言ってあまり精度がよくない（ただの plain text なら golang.org/x/net/html/charset よりはイケてる感じだが）。

そこで --all オプションを使って複数の候補を表示できるようにしている。こんな感じで蓋然性が高い順に表示している。

$ echo こんにちは，世界 | gnkf g --all
UTF-8
windows-1255
windows-1253
Big5
GB-18030
Shift_JIS

文字エンコーディング変換

$ gnkf enc -h
Convert character encoding of the text.
 Using MIME and IANA name as the character encoding name.
 Refer: http://www.iana.org/assignments/character-sets/character-sets.xhtml

Usage:
  gnkf enc [flags]

Aliases:
  enc, encoding, e

Flags:
  -d, --dst-encoding string   character encoding name of output text (default "utf-8")
  -f, --file string           path of input text file
  -g, --guess                 guess character encoding of source text
  -h, --help                  help for enc
  -o, --output string         path of output file
  -b, --remove-bom            remove BOM character in source text (UTF-8 only)
  -s, --src-encoding string   character encoding name of source text (default "utf-8")

Global Flags:
      --debug   for debug

-s および -d オプションで文字エンコーディング名を指定する際は IANA の登録名称を使う（大文字・小文字は区別しない）。たとえば，こんな感じ。

$ echo こんにちは，世界 | gnkf e -d shift_jis

ただし golang.org/x/text 以下のサブパッケージで変換器が用意されていない文字エンコーディングについては変換できないのであしからず。

日本語であれば japanese.EUCJP, japanese.ISO2022JP, japanese.ShiftJIS 等が用意されているので，それぞれ "euc-jp", "iso-2022-jp", "shift_jis" と指定すれば，いい感じに変換してくれる。

-g オプションを付けると gnkf guess コマンドと同じロジックで変換元テキストの文字エンコーディングを推測する。が，前節で述べたように，よく間違うので過信は禁物である。

改行コードの一括変換

$ gnkf newline -h
Convert newline form in the text.

Usage:
  gnkf newline [flags]

Aliases:
  newline, nwln, nl

Flags:
  -f, --file string           path of input text file
  -h, --help                  help for newline
  -n, --newline-form string   newline form: [lf|cr|crlf] (default "lf")
  -o, --output string         path of output file

Global Flags:
      --debug   for debug

こんな感じで使う。

$ echo こんにちは，世界 | gnkf nl -n crlf

テキスト全文を一旦メモリ内に読み込んで一括変換するため，巨大ファイルを扱う場合はご注意を。一応，複数の改行コードが混在している場合でも上手く処理してくれる（筈）

Unicode 正規化

$ gnkf norm -h
Unicode normalization of the text (UTF-8 encoding only).

Usage:
  gnkf norm [flags]

Aliases:
  norm, normalize, nrm, nm

Flags:
  -f, --file string        path of input text file
  -h, --help               help for norm
  -k, --kangxi-radicals    normalize kangxi radicals only (with nfkc or nfkd form)
  -n, --norm-form string   Unicode normalization form: [nfc|nfd|nfkc|nfkd] (default "nfc")
  -o, --output string      path of output file
  -b, --remove-bom         remove BOM character

Global Flags:
      --debug   for debug

こんな感じで使う。

$ echo ﾍﾟﾝｷﾞﾝ | gnkf nm -n nfkc
ペンギン

Unicode 正規化は色々と副作用があるのでご注意を。全角・半角変換については後述の gnkf width コマンドを使うのがオススメである。

康熙部首の正規化

NFKC または NFKD 正規化を行う際に -k オプションを付けることで康熙部首の正規化のみを行うようにした。

たとえば「㈱埼⽟」の「⽟（U+2f5f）」のみを正規化したい場合は

$ echo ㈱埼⽟ | gnkf nm -n nfkc -k

などとすればよい。

全角・半角変換

$ gnkf width -h
Convert character width in the text (UTF-8 encoding only).

Usage:
  gnkf width [flags]

Aliases:
  width, wdth, w

Flags:
  -c, --conversion-form string   conversion form: [fold|narrow|widen] (default "fold")
  -f, --file string              path of input text file
  -h, --help                     help for width
  -o, --output string            path of output file
  -b, --remove-bom               remove BOM character

Global Flags:
      --debug   for debug

こんな感じで使う。

$ echo ペンギン | gnkf w -c narrow
ﾍﾟﾝｷﾞﾝ

"fold" フォームを使うと，英数字は半角にカナは全角に，といい感じに変換してくれる。

変換には golang.org/x/text/width パッケージを使っているが，濁点・半濁点を含む文字や全角と半角で一対一に対応していない文字は上手く扱えないため，例外部分については内部で強制的に置換している。

また，このためにテキスト全文を一旦メモリ内に読み込んでいる。巨大ファイルを扱う場合はご注意を。

かなカナ変換

$ gnkf kana -h
Convert kana characters in the text.
 UTF-8 encoding only.
 "hiragana" and "katakana" forms are valid only for full-width kana character.

Usage:
  gnkf kana [flags]

Aliases:
  kana, k

Flags:
  -c, --conversion-form string   conversion form: [hiragana|katakana|chokuon] (default "katakana")
  -f, --file string              path of input text file
      --fold                     convert character width by fold form
  -h, --help                     help for kana
  -o, --output string            path of output file
  -b, --remove-bom               remove BOM character

Global Flags:
      --debug   for debug

こんな感じで使う。

$ echo こんにちは | gnkf k -c katakana
コンニチハ

かなカナ変換は全角文字のみが対象だが --fold オプションを付けることで全角・半角変換（"fold" フォーム）も同時に行うことができる。

$ echo 123 ｺﾝﾆﾁﾊ | gnkf k -c hiragana --fold
123 こんにちは

テキスト全文を一旦メモリ内に読み込むので，巨大ファイルを扱う場合はご注意を。

直音への変換

"chokuon" フォームを指定して拗音 (ようおん) （小さい 'ゃ', 'ゅ', 'ょ' など）や促音（小さい 'っ'）を直音（'や', 'ゆ', 'よ', 'つ'）に変換する。

$ echo ニッポン | gnkf k -c chokuon
ニツポン

半角カナも変換可能。

BASE64 符号化

$ gnkf base64 -h
Encode/Decode BASE64.

Usage:
  gnkf base64 [flags]

Aliases:
  base64, b64

Flags:
  -d, --decode          decode BASE64 string
  -f, --file string     path of input text file
  -u, --for-url         encoding/decoding defined in RFC 4648
  -h, --help            help for base64
  -p, --no-padding      no padding
  -o, --output string   path of output file

Global Flags:
      --debug   for debug

BASE64 符号化および復号機能。 Linux 系の base64 コマンドや openssl base64 コマンドの代わりに使える。

$ echo Hello World | gnkf b64
SGVsbG8gV29ybGQK

$ echo SGVsbG8gV29ybGQK | gnkf b64 -d
Hello World

これで base64 や openssl コマンドがない環境でも大丈夫。

BCrypt 符号化と検証

$ gnkf bcrypt -h
Hash and compare by BCrypt.

Usage:
  gnkf bcrypt [flags] string [string...]

Aliases:
  bcrypt, bc

Flags:
      --compare string   compare to BCrypt hashed string
  -c, --cost int         BCrypt cost (4-31) (default 10)
  -h, --help             help for bcrypt

Global Flags:
      --debug   for debug

パスワードの符号化アルゴリズムとして有名な BCrypt を使った文字列の符号化と符号化された文字列の検証ができる。

$ gnkf bcrypt password
$2a$10$ES0KxMf9p.t0FEMp8WB6we8X43rMzfXb9r5WvFeUSk8Q2z3wdjrCS

$ gnkf bc --compare '$2a$10$ES0KxMf9p.t0FEMp8WB6we8X43rMzfXb9r5WvFeUSk8Q2z3wdjrCS' password
compare BCrypt hashed string '$2a$10$ES0KxMf9p.t0FEMp8WB6we8X43rMzfXb9r5WvFeUSk8Q2z3wdjrCS' to...
password : match!

Hash 符号化と検証

$ gnkf hash -h
Print or check hash value.
  Support algorithm:
  MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256

Usage:
  gnkf hash [flags] [file]

Aliases:
  hash, h

Flags:
  -a, --algorithm string   hash algorithm (default "SHA-256")
  -c, --check              don't fail or report status for missing files
  -h, --help               help for hash
      --ignore-missing     don't fail or report status for missing files (with check option)
      --quiet              don't print OK for each successfully verified file (with check option)

Global Flags:
      --debug   for debug

ハッシュ関数を使ったデータの要約と検証。 Linux 系の sha256sum コマンド等の代わりに使える。

たとえば SHA-256 アルゴリズムでハッシュ値を取得するには

$ echo Hello World | gnkf h
d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26  -

という感じ。 SHA-256 以外で，たとえば MD5 アルゴリズムを使いたい場合はアルゴリズムを指定して

$ echo Hello World | gnkf h -a md5
e59ff97941044f85df5297e1c302d260  -

などとする。ファイルを指定すると

$ gnkf h gnkf_0.5.0_Linux_64bit.tar.gz 
c64ef70a7ed23261b9ec9000e075ee7c6c441b604e00609b9d10078b123b7cb5  gnkf_0.5.0_Linux_64bit.tar.gz

といった感じに出力する。

また

$ cat gnkf_0.5.0_checksums.txt 
01904595df1a438caac6bdecdfa7c9befb4aa43cdb246cbdfba7b7e3bb7153db  gnkf_0.5.0_Linux_ARMv6.tar.gz
02e695cd16cc591eb8094c999ee326a6a15817f857596c6a644cecbb416c3d74  gnkf_0.5.0_Windows_64bit.zip
322734ceb9e927503f620d9ed67fe1b1b0f8df3f09fca15b0d94786890ec07b6  gnkf_0.5.0_FreeBSD_64bit.tar.gz
33d1d7ee4a6417e56ea76cf874b7175b6e5c47ba64216ba8f2f5f347a3bb635d  gnkf_0.5.0_FreeBSD_ARM64.tar.gz
7df75e6d4b458017f4f05cd4ba7007a3852c9f95607c48d2848b383ff463d79f  gnkf_0.5.0_Windows_ARMv6.zip
95528de1b027ac292faacca8d31ae13c7678d2dd15fda3f72744eccaa414dcd4  gnkf_0.5.0_macOS_ARM64.tar.gz
9e32933a3f96bd31a5df80712589beeb37df7d5caa0d0d1de82a30660a816fd6  gnkf_0.5.0_FreeBSD_ARMv6.tar.gz
b46912edf2de327ae2ecbc86d8d27f41a2be977da4adf4e3edbc37ae88d23cd3  gnkf_0.5.0_macOS_64bit.tar.gz
c64ef70a7ed23261b9ec9000e075ee7c6c441b604e00609b9d10078b123b7cb5  gnkf_0.5.0_Linux_64bit.tar.gz
dbaf68c77197780389b714a7fbbbe553874e9f733c5126c31737767d107e0835  gnkf_0.5.0_Linux_ARM64.tar.gz

などとハッシュ値の一覧が用意されている場合は -c オプションを使って

$ gnkf h --ignore-missing -c gnkf_0.5.0_checksums.txt 
gnkf_0.5.0_Linux_64bit.tar.gz: OK
WARNING in 9 items: no such file or directory

とすればハッシュ値が正しいかどうか検証することができる。

BOM の除去

$ gnkf remove-bom -h
Remove BOM character in UTF-8 string.

Usage:
  gnkf remove-bom [flags]

Aliases:
  remove-bom, rbom, rb

Flags:
  -f, --file string     path of input text file
  -h, --help            help for remove-bom
  -o, --output string   path of output file

Global Flags:
      --debug   for debug

UTF-8 テキストに BOM (Byte Order Mark; U+FEFF) が含まれている場合

$ echo Hello | gnkf dump
0xef, 0xbb, 0xbf, 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x0a

これを除去する。

$ echo Hello | gnkf remove-bom | gnkf dump
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x0a

先頭だけでなく，文字列中の全ての BOM を除去する。テキスト全文を一旦メモリ内に読み込むので，巨大ファイルを扱う場合はご注意を。

16進ダンプ

$ gnkf dump -h
Hexadecimal view of octet data stream with C language array style.

Usage:
  gnkf dump [flags]

Aliases:
  dump, hexdump, d, hd

Flags:
  -f, --file string   path of input text file
  -h, --help          help for dump
  -u, --unicode       print by Unicode code point (UTF-8 only)

Global Flags:
      --debug   for debug

デバッグ用に用意した機能（笑）以下のようにオクテット単位でダンプ表示する。

$ echo ㈱埼⽟ | gnkf d
0xe3, 0x88, 0xb1, 0xe5, 0x9f, 0xbc, 0xe2, 0xbd, 0x9f, 0x0a

更に -u オプションを付けると Unicode 符号点に変換して表示してくれる。

$ echo ㈱埼⽟ | gnkf d -u
0x3231, 0x57fc, 0x2f5f, 0x000a

これを使って，たとえば

$ echo ㈱埼⽟ | gnkf nm -n nfkc -k | gnkf d -u
0x3231, 0x57fc, 0x7389, 0x000a

てな感じにパイプで繋いで動作確認できる。我ながらありがたい機能だ（笑）

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

こんな埼「玉」修正してやるぅ

2020-07-14T04:12:59+00:00

Twitter を眺めていたら

総務省のマイナンバーカード交付状況をデータ化していて、データの結合がうまくいかないなーと思ったら、なんと、同じ埼玉でも文字コードが違うという落とし穴が・・
3月8日では \u2f5f が使われていて、それ以降では\u7389…https://t.co/AOkV3iojaz pic.twitter.com/jU4P583Ad5
— Hal Seki (@hal_sk) July 11, 2020

という tweet を見かけた。これは Adobe Acrobat Distiller の不具合なんだそうで，2019年9月には既に話題に登っているのだが，2020年7月の時点でも修正されていないようだ。

Create PDF, why KANJI 9AD8(高) will be changed to 2… - Adobe Support Community - 10625575

Adobe Acrobat Distiller が見捨てられてるのか，それとも「日本語」が見捨てられているのか…

【2021-0129 追記】 PostScript プリンタドライバ経由で PostScript データを吐き出すと似たようなことが起きるらしい。もしかしたら Distiller の不具合ってこれが原因？かも。

閑話休題 (それはさておき) 。問題となっているのは「康熙部首（kangxi radicals）」と呼ばれる漢字の部首を集めた以下の Unicode 符号点領域である。

“Kangxi radical - Wikipedia” より抜粋

要するに，これらの領域の文字を本来の符号点に変換してやればいいわけだ。件の tweet のスレッドを見ると，幸いにも Unicode の NFKC 正規化で変換可能らしい。

試しに以下のコードを組んで

package main

import (
    "fmt"

    "golang.org/x/text/unicode/norm"
)

func main() {
    for r := rune(0x2f00); r <= 0x2fd5; r++ {
        rr := []rune(norm.NFKC.String(string([]rune{r})))
        if r != rr[0] {
            fmt.Printf("%#U -(NFKC)-> %#U\n", r, rr[0])
        }
    }
}

実行してみると

$ go run sample1.go 
U+2F00 '⼀' -(NFKC)-> U+4E00 '一'
U+2F01 '⼁' -(NFKC)-> U+4E28 '丨'
U+2F02 '⼂' -(NFKC)-> U+4E36 '丶'
...
U+2F5F '⽟' -(NFKC)-> U+7389 '玉'
...
U+2FD4 '⿔' -(NFKC)-> U+9F9C '龜'
U+2FD5 '⿕' -(NFKC)-> U+9FA0 '龠'

てな出力（一部割愛）になって，ちゃんと変換されていることが分かる。

ただし Unicode 正規化は副作用があるので安直には使えない。となると，前回の「かなカナ変換」で紹介した方法が使えるかな。

変換後の符号点の値は散らばっていて且つ数も多く手作業でコードを書くのは不毛なので，まずは unicode.SpecialCase を生成するコードを書いてみよう（笑）

package main

import (
    "fmt"
    "strconv"

    "golang.org/x/text/unicode/norm"
)

func main() {
    fmt.Println("var KangxiRadicals = unicode.SpecialCase{")
    for kr := rune(0x2f00); kr <= 0x2fd5; kr++ {
        rr := []rune(norm.NFKC.String(string([]rune{kr})))
        if kr != rr[0] {
            fmt.Printf("\tunicode.CaseRange{%#[1]x, %#[1]x, [unicode.MaxCase]rune{%#[2]x - %#[1]x, 0, 0}}, // %#[1]U -> %#[2]U\n", kr, rr[0])
        }
    }
    fmt.Println("}")
}

これを実行するとこんなコードが得られる（一部割愛）。

$ go run sample1b.go
var KangxiRadicals = unicode.SpecialCase{
    unicode.CaseRange{0x2f00, 0x2f00, [unicode.MaxCase]rune{0x4e00 - 0x2f00, 0, 0}}, // U+2F00 '⼀' -> U+4E00 '一'
    unicode.CaseRange{0x2f01, 0x2f01, [unicode.MaxCase]rune{0x4e28 - 0x2f01, 0, 0}}, // U+2F01 '⼁' -> U+4E28 '丨'
    unicode.CaseRange{0x2f02, 0x2f02, [unicode.MaxCase]rune{0x4e36 - 0x2f02, 0, 0}}, // U+2F02 '⼂' -> U+4E36 '丶'
    ...
    unicode.CaseRange{0x2f5f, 0x2f5f, [unicode.MaxCase]rune{0x7389 - 0x2f5f, 0, 0}}, // U+2F5F '⽟' -> U+7389 '玉'
    ...
    unicode.CaseRange{0x2fd4, 0x2fd4, [unicode.MaxCase]rune{0x9f9c - 0x2fd4, 0, 0}}, // U+2FD4 '⿔' -> U+9F9C '龜'
    unicode.CaseRange{0x2fd5, 0x2fd5, [unicode.MaxCase]rune{0x9fa0 - 0x2fd5, 0, 0}}, // U+2FD5 '⿕' -> U+9FA0 '龠'
}

あとはこれを組み込んで使えばいいだけ。たとえばこんな感じに使える。

func unicodePrint(s string) {
    ss := []string{}
    for _, r := range s {
        ss = append(ss, fmt.Sprintf("{%#U}", r))
    }
    fmt.Println(strings.Join(ss, " "))
}

func main() {
    saitama := "埼⽟"
    unicodePrint(saitama)
    unicodePrint(strings.ToUpperSpecial(KangxiRadicals, saitama))
}

これを実行すると

go run sample2.go
{U+57FC '埼'} {U+2F5F '⽟'}
{U+57FC '埼'} {U+7389 '玉'}

となる。よーし，うむうむ，よーし。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

「神」と「神」と Chrome の文字化け

2017-12-10T03:35:07+00:00

「Go 言語による Unicode 半角/全角変換」のページを Google Chrome で見ると「神と神」が同じ「神」に見える，という報告をいただきまして，確かにこちらの環境でも再現するので，ちょっと調べてみました。

（追記： Chrome だけじゃなくて Android 用の Firefox Focus でも同じ現象を確認した。どうやら Android 用の Firefox Focus は Firefox とはレイアウトエンジンが異なり WebKit からの fork である WebView （Android に既定で入ってるやつ）を使ってるらしい。それって，もしかして全ての元凶は WebKit ってことなのか？）

（追記2： Android 用の Firefox Focus のレンダリングエンジンが GechoView に変わったが影響があるかどうか確認してない）

ちなみに「神と神」のうち前者の「神」は所謂 CJK 互換文字と呼ばれるもので Unicode コードポイントで「U+FA19 '神'」にマッピングされるものです。

まず，本サイトの状態を説明しておくと，サイトの各ページの文字は Web フォントで表示されている。ブラウザ側で Web フォントを無効にしていない（または経路途中でフィルタリングされない）限りは，こちらで指定したフォントで表示されるはずである。

本文を含む地の文章には「さわらび明朝」を利用している。 Google Fonts Early Access で唯一ふだん使いできる明朝体の Web フォントだったのが選択した理由である¹。

ただし「さわらび明朝」は，個人の方がボランティアで作成されているということもあり，全ての和文文字を網羅しているわけではなく，幾つか表示できない文字がある。「U+FA19 '神'」もそのうちのひとつである。どうもその辺に原因がありそうである。

そこで，テスト用に以下の HTML コードを用意し Chrome に表示させてみた。

<html>
<head>
<link rel='stylesheet' href='http://fonts.googleapis.com/earlyaccess/sawarabimincho.css' type='text/css'>
<title>神と神</title>
<style>
#localonly {
  font-family: sans-serif;
}
#sawarabi {
  font-family: 'Sawarabi Mincho', sans-serif;
}
</style>
</head>
<body>
<div id="localonly">
	<p>	「神」と「神」（後者が CJK 互換文字）</p>
	<p>草「彅」剛（JIS 第一・第二水準にない漢字）</p>
	<p>	「繋」ぐ（さわらび明朝にない文字）</p>
</div>
<div id="sawarabi">
	<p>	「神」と「神」（後者が CJK 互換文字）</p>
	<p>草「彅」剛（JIS 第一・第二水準にない漢字）</p>
	<p>	「繋」ぐ（さわらび明朝にない文字）</p>
</div>
</body>
</html>

これを表示させた結果は以下の通り。

Google Chrome (1)

最初の3行が Chrome デフォルトの Sans Serif で表示させたもの，次の3行が「さわらび明朝」で表示させたものである。ただし「さわらび明朝」にない文字は Sans Serif で表示するよう設定している。

「神」と「彅」と「繋」は「さわらび明朝」に収録されていない文字なのだが，何故か「神」だけが明朝体で「神」と表示されているのがお分かりだろうか²。ふむむむむ。

ここで思い出すのが Unicode 正規化による「神」の正規化である。

Go 言語と Unicode 正規化

この記事で説明している通り， CJK 互換文字である「U+FA19 '神'」は正規化によって「U+795E '神'」に変換されてしまうのである。

ならば今度は CJK 互換文字に絞って以下の HTML コードを組んでみる。

<html>
<head>
<link rel='stylesheet' href='http://fonts.googleapis.com/earlyaccess/sawarabimincho.css' type='text/css'>
<title>神と神</title>
<style>
#localonly {
  font-family: sans-serif;
}
#sawarabi {
  font-family: 'Sawarabi Mincho', sans-serif;
}
</style>
</head>
<body>
<div id="localonly">
	<p>	「朗」と「朗」（後者が CJK 互換文字，正規化される）</p>
	<p>	「欄」と「欄」（後者が CJK 互換文字，正規化される）</p>
	<p>	「崎」と「﨑」（後者が CJK 互換文字，正規化されない）</p>
</div>
<div id="sawarabi">
	<p>	「朗」と「朗」（後者が CJK 互換文字，正規化される）</p>
	<p>	「欄」と「欄」（後者が CJK 互換文字，正規化される）</p>
	<p>	「崎」と「﨑」（後者が CJK 互換文字，正規化されない）</p>
</div>
</body>
</html>

これを表示させた結果は以下の通り。

Google Chrome (2)

ビンゴ！

「朗」と「朗」は「神」と「神」の関係と同じ。 CJK 互換文字「朗」は「さわらび明朝」に収録されてなく， Unicode 正規化によって「朗」に変換される
「欄」は Unicode 正規化によって「欄」に変換されるが，どちらの文字も「さわらび明朝」に収録されていないため， Chrome デフォルトのフォントで表示されている
「﨑」は CJK 互換文字で「さわらび明朝」に収録されていないが Unicode 正規化の対象ではない（「崎」は似た字形の文字を並べてみただけ，テヘペロ）ため，そのまま Chrome デフォルトのフォントで表示されている

つまり

フォントに対象の文字が収録されていない
Unicode 正規化によって別の文字に変換可能
変換された文字がフォントに収録されている

という条件が揃った時に「文字化け」が発生する，ということのようだ³。

いや，これは酷いだろう。同じ文字化けするなら「豆腐 □」や「ゲタ〓」のほうがまだマシである。多分 Chrome の中の人は CJK 互換文字や異体字について（歴史背景などを）よく理解しないまま「正規化できる文字で代替えすればいいぢゃん♥」と軽い感じで実装してしまったのだろう。「Go 言語と Unicode 正規化」では Apple の旧ファイルシステム HFS+ を散々に貶したが， ~~Google もタイガイである~~。（Chrome だけじゃなかった）

ちなみに，この現象は Firefox （またはその系列のブラウザ）では発生しない。私のメインブラウザは Firefox (Quantum マンセー！) なので，指摘されるまで全く気づかなかった。ゴメンペコン⁴。

とはいえ，これは相当にレアケースなので滅多なことでは発現しないだろう。 ~~個人的には Noto Serif の和文フォントが Web フォントで登場するまでは「さわらび明朝」で頑張るつもりである。なので，特に対策しない予定。~~ （ゴメン。日和った）

ご不便をおかけすることもあるかもですが，悪しからずご了承の程を。

ブックマーク

「Noto Serif Japanese」を使ってみたので、自分用メモ。 - Qiita

最近発表された Noto Serif の和文フォントはまだ Web フォントとしては提供されていない。 ↩︎
デフォルトの Sans Serif が使われていないことは Chrome のデベロッパー・ツールでも確認済み。 ↩︎
今回は「異体字セレクタ（Variation Selector）」については検証していない。そもそも異体字セレクタによる文字表示はアプリケーションとフォントの両方が対応していないと成り立たない。メジャー・ブラウザは異体字セレクタに対応しているそうだが，私は対応するフォントを持ってないし，対応できる自由な Web フォントが（CDN 等で）提供されているという話も聞かない。したがって今回はスルーの方向で。 ↩︎
一応このサイトは Firefox (Quantum) と Chrome ならレイアウトが崩れないように考えているつもり。旧 Firefox や IE や Safari などレガシーなブラウザはスルーで。 Edge は対応したいところだが手元に環境を持ってないので確認＆対応できない。 Win10 を導入する予定は，今のところはない。換装するなら Linux 系のデスクトップにするつもり。 ↩︎

Go 言語と Unicode 正規化

2016-01-29T19:05:52+00:00

今回は少し目先を変えて「Unicode 正規化（normalization）」のお話。

2羽の「ペンギン」

まず「ペンギン」という文字列を思い浮かべてみる。この文字列を Unicode のコードポイントで表すと以下のようになる。

ペ：U+30DA
ン：U+30F3
ギ：U+30AE
ン：U+30F3

ところでペンギンの「ペ」と「ギ」は半濁点および濁点を含む。 Unicode は「ペ」と「ギ」をそれぞれ2つの要素に分解できる。

ペ：U+30D8 + U+309A
ン：U+30F3
ギ：U+30AD + U+3099
ン：U+30F3

U+309A および U+3099 はそれぞれ半濁点と濁点を表す「結合文字（combining character）」である。「ヘ」や「キ」のような「基底文字（base character）」に結合文字を1つ以上¹ 付加した文字を「合成列（composite sequence）」と呼ぶ。これに対して「ペ：U+30DA」や「ギ：U+30AE」のような文字を「事前合成形（precomposed）」と呼ぶ。

つまり同じ文字を同じ文字集合² で表しているのにもかかわらず複数の符号化³ が存在するわけだ。これを「重複符号化」と言う。文字集合に重複符号化があるというのは，はっきり言って「クソ仕様」である。

もちろんこれは Unicode を作った連中がヘボいのではなく（いや，ヘボいのかもしれないが），いわゆる「歴史的経緯」というやつである⁴。だからこれはこういうものだと諦めるしかない。

しかし情報処理を行う上では，この2羽の「ペンギン」が等価（equivalance）であることを示す手立てを考えなければならない。

正規等価

2羽の「ペンギン」が等価であることを示す一番簡単な方法は，文字列を事前合成形あるいは合成列のどちらかに統一（＝正規化）してしまえばいい。これを「正規等価（canonical equivalance）」と呼ぶ。このうち，事前合成形に正規化する方法を “NFC（Normalization Form Composition）”，合成列に正規化する方法を “NFD（Normalization Form Decomposition）” と呼ぶ。

Go 言語では golang.org/x/text/unicode/norm パッケージで Unicode 文字列を正規化できる。まぁ，コードで書いたほうがはやいか。

package main

import (
    "fmt"

    "golang.org/x/text/unicode/norm"
)

func main() {
    penguin := "ペンギン"
    for pos, runeValue := range penguin {
        fmt.Printf("penguin[%d] = %#U\n", pos, runeValue)
    }

    penguin2 :=norm.NFD.String(penguin)
    for pos, runeValue := range penguin2 {
        fmt.Printf("penguin2[%d] = %#U\n", pos, runeValue)
    }

    penguin3 := norm.NFC.String(penguin2)
    for pos, runeValue := range penguin3 {
        fmt.Printf("penguin3[%d] = %#U\n", pos, runeValue)
    }
}

実行結果はこんな感じ。

penguin[0] = U+30DA 'ペ'
penguin[3] = U+30F3 'ン'
penguin[6] = U+30AE 'ギ'
penguin[9] = U+30F3 'ン'
penguin2[0] = U+30D8 'ヘ'
penguin2[3] = U+309A '゚'
penguin2[6] = U+30F3 'ン'
penguin2[9] = U+30AD 'キ'
penguin2[12] = U+3099 '゙'
penguin2[15] = U+30F3 'ン'
penguin3[0] = U+30DA 'ペ'
penguin3[3] = U+30F3 'ン'
penguin3[6] = U+30AE 'ギ'
penguin3[9] = U+30F3 'ン'

NFC と NFD が交換可能であることがわかると思う。

3羽目の「ペンギン」と互換等価

さてここで3羽目の「ﾍﾟﾝｷﾞﾝ」に登場してもらおう。

ﾍ：U+FF8D
ﾟ：U+FF9F
ﾝ：U+FF9D
ｷ：U+FF77
ﾞ：U+FF9E
ﾝ：U+FF9D

これはいわゆる「半角カナ」である。半角カナの半濁点 U+FF9F および濁点 U+FF9E は結合文字の半濁点 U+309A および濁点 U+3099 と同等とみなされているが「ペ」や「ギ」に相当する半角カナの事前合成形は存在しないため NFC で事前合成形に正規化しようとしても

package main

import (
    "fmt"

    "golang.org/x/text/unicode/norm"
)

func main() {
    penguin := "ﾍﾟﾝｷﾞﾝ"
    for pos, runeValue := range penguin {
        fmt.Printf("penguin[%d] = %#U\n", pos, runeValue)
    }

    penguin2 := norm.NFC.String(penguin)
    for pos, runeValue := range penguin2 {
        fmt.Printf("penguin2[%d] = %#U\n", pos, runeValue)
    }
}

penguin[0] = U+FF8D 'ﾍ'
penguin[3] = U+FF9F 'ﾟ'
penguin[6] = U+FF9D 'ﾝ'
penguin[9] = U+FF77 'ｷ'
penguin[12] = U+FF9E 'ﾞ'
penguin[15] = U+FF9D 'ﾝ'
penguin2[0] = U+FF8D 'ﾍ'
penguin2[3] = U+FF9F 'ﾟ'
penguin2[6] = U+FF9D 'ﾝ'
penguin2[9] = U+FF77 'ｷ'
penguin2[12] = U+FF9E 'ﾞ'
penguin2[15] = U+FF9D 'ﾝ'

何も変わらないことが分かるだろう。そもそも半角カナは「互換用文字（Compatibility Character）」として異なるコードポイントが割り当てられているため，このままでは3羽目の「ﾍﾟﾝｷﾞﾝ」が等価であることを示せない。

このような場合は「ﾍﾟﾝｷﾞﾝ」と互換性のある別の文字列に正規化できるとよい。これを「互換等価（compatibility equivalance）」と呼ぶ。具体的には，事前合成形に正規化する NFKC（Normalization Form Compatibility Composition）と合成列に正規化する NFKD（Normalization Form Compatibility Decomposition）の2つがある。

早速 norm パッケージを使ってコードを書いてみる。

package main

import (
    "fmt"

    "golang.org/x/text/unicode/norm"
)

func main() {
    penguin := "ﾍﾟﾝｷﾞﾝ"
    for pos, runeValue := range penguin {
        fmt.Printf("penguin[%d] = %#U\n", pos, runeValue)
    }

    penguin2 := norm.NFKC.String(penguin)
    for pos, runeValue := range penguin2 {
        fmt.Printf("penguin2[%d] = %#U\n", pos, runeValue)
    }
}

これを実行すると

penguin[0] = U+FF8D 'ﾍ'
penguin[3] = U+FF9F 'ﾟ'
penguin[6] = U+FF9D 'ﾝ'
penguin[9] = U+FF77 'ｷ'
penguin[12] = U+FF9E 'ﾞ'
penguin[15] = U+FF9D 'ﾝ'
penguin2[0] = U+30DA 'ペ'
penguin2[3] = U+30F3 'ン'
penguin2[6] = U+30AE 'ギ'
penguin2[9] = U+30F3 'ン'

となり， NFC で正規化した「ペンギン」と等価であることがわかる。

互換等価による正規化は応用範囲が広い。たとえば「㈱」（U+3231）は「(株)」（U+0028 + U+682A + U+0029）に変換される。文字列検索の前に互換等価による正規化を行っておくことで処理がやりやすくなるというのはあるかもしれない。ただし， NFC と NFD は交換可能だが（ただしオリジナル文字列が事前合成形と合成列とで混在している場合は元に戻せないが）， NFKC や NFKD で正規化した文字列を元に戻す方法はないので注意が必要である⁵。

恐怖の CJK 互換文字

正規等価については注意すべき点がある。有名な「神」を例に挙げよう。これを NFC / NFD で正規化する。

package main

import (
    "fmt"

    "golang.org/x/text/unicode/norm"
)

func main() {
    god := "神"
    for pos, runeValue := range god {
        fmt.Printf("god[%d] = %#U\n", pos, runeValue)
    }

    god2 := norm.NFC.String(god)
    for pos, runeValue := range god2 {
        fmt.Printf("god2[%d] = %#U\n", pos, runeValue)
    }

    god3 := norm.NFC.String(god)
    for pos, runeValue := range god3 {
        fmt.Printf("god3[%d] = %#U\n", pos, runeValue)
    }
}

これを実行すると

god[0] = U+FA19 '神'
god2[0] = U+795E '神'
god3[0] = U+795E '神'

となり，NFC でも NFD でも違う文字になってしまった。ちなみに「神」から「神」へ正規化する方法はない。困ったね。

実は「神」は「CJK 互換文字」と呼ばれるグループに属し，「神」とは異体字の関係にある。故に「神」を「神」に正規化してしまったのである。

これは明らかに仕様ミスである。「神」と「神」のような異体字の関係は本来なら正規等価ではなく互換等価であるべきだからだ。

…やっぱり Unicode はクソ仕様だ。

ただ，これが実際の場面で問題になることは少ないと思われる。なぜなら，正規化を行うのは「2つの文字列が等価であるか？」を調べるための手段にすぎないからだ。普通はね。

ところが，普通でないことをする馬鹿がいるのである。

独自路線に走る Apple

Apple の OS X （iOS も？）のファイルシステムである HFS+ はファイル名を NFD 相当に正規化するという恐ろしい仕様になっている⁶。しかしそれでは先ほどの例のように異体字を別の文字に変えられてしまうため困ったことになってしまう。

そこで Apple は CJK 互換文字を含むいくつかの文字を正規化の対象から外すという蛮行に出た。俗に “UTF-8-MAC⁷” などと呼ばれる独自路線に走ってしまったわけだ。クソの上塗りである。

これにより様々な（特にマルチプラットフォームな）アプリケーションが多大なる迷惑を被ることになるが⁸，深くはツッコむまい。

追記（2017-03-29）

新しくリリースされた APFS (Apple File System) では上述のような似非正規化は行わないらしい。よーし，うむうむ，よーし。

Unicode 正規化に関するまとめ

以上， Unicode 正規化の4つの方式をまとめると以下のようになる。

	Composing	Decomposing
Canonical equivalence	`norm.NFC`	`norm.NFD`
Compatibility equivalence	`norm.NFKC`	`norm.NFKD`

via “Text normalization in Go”

ちなみに norm パッケージでは “UTF-8-MAC” なるローカル仕様には対応していないので，必要なら自作する必要がある。

Unicode 文字列の等価属性を調べる際には是非参考にどうぞ。

ブックマーク

Go 言語に関するブックマーク集はこちら。

結合文字はひとつの基底文字に対して複数付加される場合もある。しかもこの場合に結合文字同士の順序は不定である。 ↩︎
正しくは「符号化文字集合（coded character set）」である。 ↩︎
これは UTF-8 などの「文字エンコーディング」とは異なるものだ。 ↩︎
日本の JIS 規格にも「歴史的経緯」による重複符号化がある。言わずと知れた「半角」「全角」文字である。異体字も一種の重複符号化と言える。もちろんこれは日本語圏だけの問題ではなく，大抵の言語圏は似たような重複符号化の問題を抱えている。そして Unicode はそうした仕様上の欠陥も含めて併呑してしてしまっているため，このような有様になっているわけだ。問題を先送りして更に酷いことになるという失敗例の典型ですな。この辺の「歴史的経緯」の一部については大昔に拙文「文字コードとその実装」で言及しているので参考にどうぞ。古すぎて一部使えない記述もあるけど。 ↩︎
単に全角・半角変換ができればいいのなら golang.org/x/text/width パッケージをお勧めする。 ↩︎
ちなみに Windows のファイルシステムはフォルダ・ファイルの名前を正規化するとかいうアホなことはしない。事前合成形も合成列も受け入れる。見かけ同じ名前のフォルダ・ファイルが複数できる可能性はあるが，それはそれ。多分，ほとんどの OS のファイルシステムは名前の正規化なんてしてないはず。この HFS+ による Unicode 正規化のおかげで他プラットフォームはかなりの迷惑を被ることになる。たとえば複数のプラットフォームをまたぐファイル交換（例えば Linux → OS X → Windows みたいな経路）を行った場合に OS X を経由した途端にフォルダ・ファイル名を書き換えられてしまうのだ。しかもユーザやアプリケーションは基本的に干渉できない。迷惑千万な話である。もっとも Windows ユーザは Windows ファイルシステムのダメさ加減が身に沁みてるので他所を嗤えないけど（笑） ↩︎
この記事では最初 NFD-mac と書いていたのだが，どうも巷では UTF-8-MAC というのが一般的らしい。しかしこの件はあくまでも正規化の問題であり文字エンコーディングの問題ではない。なので UTF-8-MAC という呼び名は的を得ていないと思うのだが， Apple 信者ではない私がどうこう言ってもしょうがないので UTF-8-MAC 表記で統一しておく。まぁ符号化文字集合と文字エンコーディングと正規化の区別もつかない馬鹿ばっかりだからこのような愚行を犯してしまったのだろう。 ↩︎
たとえば Linus Torvalds は HFS+ に起因する git の脆弱性問題で激怒している。 ↩︎