Webの世界では昔から
「半角カナ文字は使用しないでください」
との表記を良く見かける。
昨今の上記問題点について改めて確認した情報を記載しておく
・７bit以降に半角カナ番地が存在する為にEUCなどで半角カナが文字化けする
ようするに日本語Windows(Shift-jis)などでない場合に文字化け対象になる
・昨今のWeb文字コードはUTF-8になっておりWindowsはもちろん、Linux環境でも半角カナも使用可能
・使用Webソフトが対応しているかも重要（Japanで使用できるブラウザは、ほぼ使用できる）
・HTTPの規定では8bt=1オクテットでの伝達を認めている
RFC-Translations related HTTP
・伝送経路によってUnixサーバーなどが７bit対応しかしていないので、
そこで文字化けするという話はHTTP規定を守っているなら嘘になる
しかし、海外経路サーバーにてなんらかの変換プログラムを走らせている場合は文字化けする可能性がある
HTTP規定を考えれば変換プログラムが7Bit対応しかしていない(海外では7bitが当たり前)のであれば
これはこれで問題である
ということになっている
結果、現状の日本では半角カナのやりとりは可能と判断する。
そもそも2000年頃からJavaScriptで半角カナをCheckする関数が存在しているて、
そのjsファイルだってクライアント環境までHTTP経由で運ばれるのであるからその中に記述されている
チェック用の半角カナ文字が文字化けしてしまう可能性があるのにと管理人はいつも思っていた（苦笑）
function tozenkaku(){
//配列を用意する
hankaku = new Array("ｶﾞ", "ｷﾞ", "ｸﾞ", "ｹﾞ", "ｺﾞ", "ｻﾞ", "ｼﾞ", "ｽﾞ", "ｾﾞ", "ｿﾞ");
zenkaku = new Array("ガ", "ギ", "グ", "ゲ", "ゴ", "ザ", "ジ", "ズ", "ゼ", "ゾ");
thismoji = document.test.moji.value;
//変換開始
for (i=0; i<=NN; i++) {
while (thismoji.indexOf(hankaku[i]) >= 0){
thismoji = thismoji.replace(hankaku[i], zenkaku[i]);
}
}
window.alert(thismoji);
}
これは文字コードとぶつけるべきじゃないと（上記半角カナ文字はちゃんと表示されてるでしょ？）
ここに便利なのがあります。作者様感謝です！
この問題はWebアプリとDBの絡みでも文字コード問題として発生している、やはり海外では7bitのことしか
考えていない製品が昔は多く、半角カナがそもそも入らないDBもあればSort処理が機能しないというのもあったが
現在ではshift-jisはもちろんIBMのDB2ではwindows-31jの使用も可になっており大分、半角カナも使用に耐える
ようになってきており、UTF-8の登場で使用環境が整ってきた感じがある。
DBまで話が広がったが、要するにWebServer、AppServer(perl,php,Javaなど)、DBServerとアプリに欠かせない
オーケストラ者たちが外国圏から生まれており、おのおので8bit動作にそれぞれ問題を抱えていたために
「使えないのは仕様です」で開発者が逃げていた感じだと（笑）
なぜ半角カナにこだわるのか？
日本の金融業では昔から半角カナが顧客管理（読み方）に必須項目になっており、ホストにも情報があがっている
情報管理として読み方なんてアルファベット圏ビジネスでは無いのでは？（笑）
ここが日本のストロングポイント？じゃなくて半角カナの切っても切れない日本事情になっている
今尚、金融は絶対ホスト至上なのでどうしても最後にはInで半角カナ、Outで半角カナが存在するcsvが多い。
銀行間などでは全銀手順プロトコルで半角カナも通している
まとめるとシステムの役割は人間の行動を潤滑させるためにあり、日本の習慣、文化で半角カナを昔から必然的に
使用しているのだから、システムは仕様で出来なくさせるのではなく、人間に優しい機能を充実させるべきである。
システムに人間があわせるのではなく人間にシステムが合わせるのが正しい。
最後に半角カナを全面的にWebで使用することをお勧めしないしているのではなく、可能性として
使用に耐えるだけの環境になってきていると感じる今日この頃である。
補足：メールですが、ESTMPやクライアント環境は8bit化されていると思いますが、7bitの考えですので、Base64使うか、半角カナはやめましょう（苦笑）
