アカウント名:
パスワード:
私の姓には、髙(いわゆる「はしご高」が入っているのですが、この手の文字の中ではメジャーなおかげか、20年以上前に作った銀行口座なんかでもちゃんと登録できてます。当時はネット上に流れるデータとしてはまったく使えませんでしたが、最近はUnicodeベースのシステムが増えたおかげか、通常のWeb系でも問題ない場合も多いですね。
で、問題ない場合が多い、ってことでかなり油断してたんですが、お歳暮・お中元のネット通販サービスで、注文管理上はまったく問題ないのに、届けられた商品に貼られた送り状は文字化けしてた [it.srad.jp]なんてことがありました。それにこりて、今はもう冒険はせず、インターネット上に流れるデータとしてはISO-2022-JPでも使える第1水準な「くち高」を使うようにしています。
「まだれ」に「黄」が使えない。ことえりで「ひろ」と打っても広しか出ないし、Unicodeでも廣しかないし…
そりゃ髙は昔からMS932に含まれてましたからね。なのでCP932にも含まれるので事実上標準化されていた。で、下手なPC-UNIXでShift_JIS使うと対応されてないとかなんだよな。Shift_JISとCP932の違いを分かってない奴は多い。# 素直にUTF-8使えって話ではあるが。
私も同じ問題で、マンション購入するときに、銀行と戸籍だか住民票で字が違うって言われて面倒なことになりました。区のシステムがクソなだけだったんですけど。
最近減りましたが、バックエンドがSolaris(Linux)+OracleでEUCなんてのもごろごろと
EBCDIC(IBM漢字コード)かもしれませんよ(^^;
あと単独ではUTF-8対応しててもバックエンドの連携フォーマットが第二水準までってのはよくありますし。
銀行ならEBCDIC(K)の可能性ありますよね。あとは全角半角判定するためにいったんSJIS変換してバイト数チェックするのが仇になってたり。
# 汎用機ってUTF-8対応できるのかな。
UTF-8なにそれ？だし可変長など認めないコボラーな世界ですからね。汎用機系の人は漏れなくそれ。Oracleも集合前提の設計なのに構造がアレなもんばかりでしょ。
同じく、JIS X 0213非漢字が含まれている苗字なので、システムによっては数値参照になってズコーなAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ヒトゴトじゃない… (スコア:4, 興味深い)
エラーが出ないように見えても、あとで確認すると数値文字参照になってしまったりする。
似ている JIS第1水準の別の字を代用として使うことで対処していることが殆どですが、例えばみずほ銀行では、口座名が手書きで、三菱東京UFJ銀行ではカタカナになっています。
# 未だに Shift_JIS を使っているということなのかな…いい加減 UTF-8 に切り替えて欲しい
Re:ヒトゴトじゃない… (スコア:2)
私の姓には、髙(いわゆる「はしご高」が入っているのですが、この手の文字の中ではメジャーなおかげか、20年以上前に作った銀行口座なんかでもちゃんと登録できてます。
当時はネット上に流れるデータとしてはまったく使えませんでしたが、最近はUnicodeベースのシステムが増えたおかげか、通常のWeb系でも問題ない場合も多いですね。
で、問題ない場合が多い、ってことでかなり油断してたんですが、お歳暮・お中元のネット通販サービスで、注文管理上はまったく問題ないのに、届けられた商品に貼られた送り状は文字化けしてた [it.srad.jp]なんてことがありました。
それにこりて、今はもう冒険はせず、インターネット上に流れるデータとしてはISO-2022-JPでも使える第1水準な「くち高」を使うようにしています。
Re:ヒトゴトじゃない… (スコア:1)
「まだれ」に「黄」が使えない。
ことえりで「ひろ」と打っても広しか出ないし、Unicodeでも廣しかないし…
the.ACount
Re: (スコア:0)
そりゃ髙は昔からMS932に含まれてましたからね。
なのでCP932にも含まれるので事実上標準化されていた。
で、下手なPC-UNIXでShift_JIS使うと対応されてないとかなんだよな。Shift_JISとCP932の違いを分かってない奴は多い。
# 素直にUTF-8使えって話ではあるが。
Re: (スコア:0)
私も同じ問題で、マンション購入するときに、銀行と戸籍だか住民票で字が違うって言われて面倒なことになりました。区のシステムがクソなだけだったんですけど。
Re:ヒトゴトじゃない… (スコア:1)
ですので、基幹で顧客情報を見ると文字化けしている事が稀にありますね（カナからこれやろ、って漢字に書き直してます）。
まぁウチのPOSレジ（XP Embededded/Embedded POSReady 2009）も基幹システム同様にWindowsで、そういう設計になっているから仕方ないっていう。
#結構、そんな企業は多そうだ。
Re: (スコア:0)
最近減りましたが、バックエンドがSolaris(Linux)+OracleでEUCなんてのもごろごろと
Re: (スコア:0)
EBCDIC(IBM漢字コード)かもしれませんよ(^^;
あと単独ではUTF-8対応しててもバックエンドの連携フォーマットが第二水準までってのはよくありますし。
Re: (スコア:0)
銀行ならEBCDIC(K)の可能性ありますよね。
あとは全角半角判定するためにいったんSJIS変換してバイト数チェックするのが仇になってたり。
# 汎用機ってUTF-8対応できるのかな。
Re: (スコア:0)
UTF-8なにそれ？だし可変長など認めないコボラーな世界ですからね。
汎用機系の人は漏れなくそれ。
Oracleも集合前提の設計なのに構造がアレなもんばかりでしょ。
Re: (スコア:0)
同じく、JIS X 0213非漢字が含まれている苗字なので、システムによっては数値参照になってズコーなAC