アカウント名:
パスワード:
例えば、「ガ」と「ガ」は、画面上の表示ではほぼ同じですが、データとしては全く別物になっています。
ガ … \u30ac (濁点まで含めて1つの文字)ガ … \u30ab\u3099 (カ+結合文字の濁点)
別にUnicode上違反というわけではないのですが、わざわざ3バイトですむ文字にゴミを入れて6バイトにするMacは美しくないと思います。
Mac OS X ではシェルによって、入力文字列にUnicodeの結合文字列が混ざることがあります。その場合、同じ単語でも内部的に違う扱いになって検索に引っかからないなどの問題が生じる恐れがあります。それを避けるために、例えば MySQLのutf8mb4_unicode_ciのようなCollationを使うと、今度は、は ば ぱ ハ バ パ ハ 全部が同じ扱いになって「はっぱ」で検索したら「バッハ」もヒットしてしまいます。余計なCollationを使うと速度も遅くなりますので、大量のデータを処理するシステムなら半角カナへの統一というのも合理的ではないでしょうか。
古いプログラムで結合文字を処理できないなどの問題も生じることがあるので、一周回って半角カナの方が互換性が高くなりました。
結局昔からMacが互換性の癌ンっていうのは変わってないのか。
Windowsユーザーは波ダッシュのかわりに全角チルダを使いがち。
Appleは過去なんか振り返らない。その瞳に映るのは常に未来のみ。
一般にはNFD(分解された形式)の方が安定とされている。NFC(合成済みの形式)を積極的に使うとUnicodeのバージョンアップでそれまで組で表すしか無かった文字に対応する合成済みの文字が追加された場合に非互換になる。だから互換性を求めるならMacの挙動の方が望ましい。
# 必要な漢字はレア人名含めてあらかた提案済みなので今後あるとしても相当なレアケース、というのはまあ
一周回るまでもなくUS-ASCIIと組み合わせて1バイトコードで日本語が表記できる半角カタカナは互換性が高いですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
全角カナはMACが絡むとゴミ(結合文字の濁点等)が混ざる (スコア:2, 興味深い)
例えば、「ガ」と「ガ」は、画面上の表示ではほぼ同じですが、データとしては全く別物になっています。
ガ … \u30ac (濁点まで含めて1つの文字)
ガ … \u30ab\u3099 (カ+結合文字の濁点)
別にUnicode上違反というわけではないのですが、わざわざ3バイトですむ文字にゴミを入れて6バイトにするMacは美しくないと思います。
Mac OS X ではシェルによって、入力文字列にUnicodeの結合文字列が混ざることがあります。
その場合、同じ単語でも内部的に違う扱いになって検索に引っかからないなどの問題が生じる恐れがあります。
それを避けるために、例えば MySQLのutf8mb4_unicode_ciのようなCollationを使うと、
今度は、は ば ぱ ハ バ パ ハ 全部が同じ扱いになって「はっぱ」で検索したら「バッハ」もヒットしてしまいます。
余計なCollationを使うと速度も遅くなりますので、大量のデータを処理するシステムなら半角カナへの統一というのも合理的ではないでしょうか。
古いプログラムで結合文字を処理できないなどの問題も生じることがあるので、一周回って半角カナの方が互換性が高くなりました。
Re: (スコア:0)
結局昔からMacが互換性の癌ンっていうのは変わってないのか。
Re: (スコア:0)
Windowsユーザーは波ダッシュのかわりに全角チルダを使いがち。
Re: (スコア:0)
Appleは過去なんか振り返らない。その瞳に映るのは常に未来のみ。
Re: (スコア:0)
一般にはNFD(分解された形式)の方が安定とされている。
NFC(合成済みの形式)を積極的に使うとUnicodeのバージョンアップでそれまで組で表すしか無かった文字に対応する合成済みの文字が追加された場合に非互換になる。
だから互換性を求めるならMacの挙動の方が望ましい。
# 必要な漢字はレア人名含めてあらかた提案済みなので今後あるとしても相当なレアケース、というのはまあ
Re: (スコア:0)
一周回るまでもなくUS-ASCIIと組み合わせて1バイトコードで日本語が表記できる半角カタカナは互換性が高いですよ。