パソコンで半角カタカナを入力する方法
投稿日時: 2005-10-31 13:20 引用: 黒獅子さんの書き込み 2005-10-31 13:10 より: これをＳＱＬ側で簡単にやる方法が無いかと思いまして。。 "簡単に" とはいかないでしょうね。 Function で結果を返すとかそういった手法になるでしょうか。 色々見てみましたが、簡単に変換できそうなものはないですよね。 Lower、Upper はアルファベットでないとダメっぽいですし 引用: プログラム側でやるにしても、方法としては１文字ずつ検索し小文字を大文字に変換するロジックを組むしかないのでしょうか？ 言語にも因りますよね。 VB であれば、StrConv 関数が使えます。 引用: じゃんぬねっとさんの書き込み 2005-10-31 13:20 より: 言語にも因りますよね。 VB であれば、StrConv 関数が使えます。 言語はVBではありません。 Powerbilderという言語です。 VBのStrConvの様な関数はありません。 引用: かつのりさんの書き込み 2005-10-31 13:46 より: テーブルに本来の名前と検索用の名前の両方を格納するようにし、 これも考えたのですが、既存のデータが数万件あるので、コンバートの処理が必要となると思います。 そういった作業をやりたくないので、ロジックで対応する事にしました。 引用: 夏椰【SUICA】さんの書き込み 2005-10-31 13:26 より: めんどくさいですが、こんな感じでしか自分は思いつきませんでした。 半角版 コード: select translate 'ｱｧｲｨｳｩｴｪｵｫｶｷｸｹｺｻｼｽｾｿﾀﾁﾂｯﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍｺﾏﾐﾑﾒﾓﾔｬﾕｭﾖｮﾗﾘﾙﾚﾛﾜｦﾝ', 'ｧｨｩｪｫｯｬｭｮ','ｱｲｳｴｵﾂﾔﾕﾖ' Ansfrom dual ; コード: ANS-------------------------------------------------------ｱｱｲｲｳｳｴｴｵｵｶｷｸｹｺｻｼｽｾｿﾀﾁﾂﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍｺﾏﾐﾑﾒﾓﾔﾔﾕﾕﾖﾖﾗﾘﾙﾚﾛﾜｦﾝ これは使えそうです v これで試してみることにします。 みなさん、情報提供ありがとうございました。
次の
大文字／小文字、半角／全角の違いについて
この記事にはが含まれているおそれがあります。 問題箇所をしして、記事の改善にご協力ください。 議論はを参照してください。 （ 2018年4月） この項目には、一部のコンピュータやで表示できない文字（ 半角カタカナ）が含まれています （）。 半角カナ（はんかくカナ）、 半角片仮名（はんかくかたかな, Halfwidth Katakana）とは、が半分（）のの事。 では、全角片仮名 Fullwidth Katakana と半角片仮名 Halfwidth Katakana が異なる文字として登録されている。 類似物として、Unicodeには半角 Halfwidth Hangul も登録されている。 では、片仮名を含む他の文字集合と同時に運用される場合におけるの文字集合の通称である。 を含む文字集合で定義された片仮名に対して、半分の文字幅で表示されることが一般的であったためこのように呼ばれる。 JIS X 0201で規定される8ビット符号化およびにおいて0xA1—0xDFの範囲の1文字がこれにあたる。 また、やなどの符号化方式やでも互換性の目的でこの文字集合をもっている。 JIS X 0208:1997『附属書 1（規定）シフト符号化表現』では、「参考 JIS X 0201 の片仮名用図形文字集合の割当ては、この規格の将来の改正では削除することを予定する。 」と記載されている。 :2000『附属書5（規定）文字の代替名称』では HALFWIDTH KATAKANA が記載されているが、「この附属書は、これまでの慣用的な利用との互換を目的としてだけ用いる文字の代替名称を規定する。 」と書かれ、削除予定とは書かれていない。 歴史 [ ] には、7で表現される128文字分のエリアにしか文字は定義されておらず、そこに制御文字、、、などが配置されている。 ASCIIを元に制定された国際規格では10文字が各国特有の文字、記号と交換可能であったが、ラテン文字以外で書かれる言語を符号化するには不足していたため、では、ラテン文字集合とは別にと用のなどを収録した片仮名文字集合を規定し、7ビット環境または8ビット環境で運用するが制定された。 規格で規定された符号化方式のうち、広く使われたのは0x20—0x7Eにラテン文字集合、0xA1—0xDFに片仮名文字集合を割り当てた8ビット符号化方式である。 でを扱うことが困難であった創始期は、この片仮名を用いて日本語でメッセージを表示していた。 そして後にが規定され漢字などが扱えるようになった際、それまでのJIS X 0201の資産がそのまま使えるように、JIS X 0208をそのまま使うのではなく、JIS X 0201で空いていた領域にJIS X 0208の文字コードを移動 Shift して当てはめるが開発され、使用されるようになった。 大型コンピュータ（）で使われていたコードでは、各社ごとに8ビットで表現されるカタカナや日本語の句読点コードを定義していたために、各社間の互換性を欠いていた。 また、コンピュータによる漢字処理が一般化するのは1980年代中頃からで、それまでは8ビットのカタカナを用いてメッセージの表示やデータベースが構築されていた。 そのため、たとえばのコンピュータによる宛名印字はすべてカタカナであった。 呼称 [ ] UnicodeやJIS X 0213 [ ] やではHalfwidth Katakana（半角片仮名）として表記され、これが正式な呼称である。 JIS X 0208 [ ] JIS X 0201（もしくはASCII）とJIS X 0208を組み合わせて使う場合、JIS X 0208側の文字はほぼ正方形で、JIS X 0201の文字はJIS X 0208の文字の半分の幅・同じ高さで表示・印刷されることが一般的であった。 そのため、JIS X 0201の文字は「半角文字」、JIS X 0208の文字は「全角文字」、特にJIS X 0201の方の片仮名は「半角カナ」、「半角カタカナ」と呼ばれるようになった。 （での呼び名、での呼称は半角カタカナ）しかしそもそも半角・全角は字体・フォントの文脈で使われる言葉であり、また一般に文字コードは文字の幅を規定するものではないため、この表現は間違いである。 ただし、EUC-JPには文字表示幅の定義が含まれる。 またUnicodeにも文字幅に関する規定が存在する。 を参照すること。 しかし文字をあらわすのに必要なバイト数は符号化方式でそれぞれ異なる。 実際、「半角カナ」相当の文字を表現するのに、EUC-JPでは2バイト、UTF-16では2バイト、UTF-8では3バイトを要する。 このように正しい名称を与えることが難しいため、結局慣用的な「半角カナ」という呼称が用いられることが多いが、正確性に問題があることに意識がある場合は「 いわゆる半角カナ」といった言い方をされることもある。 「半角カナ」にこだわらず厳密な定義が必要な場合は、その文脈で使われている文字集合によって「JIS X 0201のほうの片仮名」や「Unicodeの半角・全角形の片仮名」と呼ばれる。 符号化方式による半角カナの扱い [ ] ISO-2022-JP [ ] は等で使われる符号化方式であり、エスケープシーケンスによって7ビットの領域に文字集合を指示して運用する。 指示可能な文字集合は、ラテン文字、-1978およびJIS X 0208-1983であり、 JIS X 0201片仮名は含まれていない。 一般に「メールでは半角カナは使えない」といわれるのはこの事による。 が全盛であった頃は、全角文字を使用できない環境との互換性の問題や、データ量や画面表示幅の節約などの面から、2バイト日本語に半角カナが併用されることが頻繁であった。 EUC-JP [ ] 日本語EUC も8ビット環境を前提とした文字コードだが、JIS X 0208の1文字目にあたるコードは、JIS X 0201を1バイトで表した場合の半角カナ部分に重なるように配置されている。 そのため、半角カナに相当する文字を使用する必要がある場合は制御文字SS2（シングルシフト2、0x8E）に続けて使用することになる（このため一見2バイトに見えるが、SS2は文字集合を次の1文字分だけ切り替えるという印のため、片仮名自体はやはり1バイトで符号化される）。 この記法によるカナ使用を実装していない処理系も多い。 これが「半角カナは文字化けする」と言われる理由の1つである。 あくまで過去の文章との互換性を保つためとはいえ、半角カナ、文字コード間の対応が保証されたことにより、将来のシステムで半角カナが非サポートとなるような事態はまず無くなったと考えてよい。 インターネットにおける半角カナ [ ] 電子メール [ ] を配送するというは7ビットのみを透過し、8ビット目をゼロにする仕様であるため、日本では時代に7ビットのみを用いることがルール化された。 これは後にRFC 1468として文書化され、という名称になった。 ISO-2022-JPには半角カナが含まれないため、メッセージ中に半角カナを含むことはできない。 ソフトウェアによっては誤ってメッセージ中に半角カナが含まれていた場合に、8ビットコードのまま送信したり、エスケープシーケンスを用いたり、などでエンコードし7ビット化して送信するソフトウェアが存在した。 後者の場合には、対応したソフト同士であれば問題なく表示が出来るが、違うソフト同士や8ビットで送信された場合は正しく表示されないため、「半角カナを使うとする」と言われるようになった。 ここから、ネット上の文章からの半角カナ撲滅を唱えるような急進的な意見が出現した。 また、当初Windowsに付属していたメールソフトが、を使用した勝手な符号化方法を使用して、他のメールソフトとの互換性をなくしていたこともその意見を強めさせた。 その後、Windowsのメールソフトも、他のメールソフトと同じ符号化方法になったが、「いわゆる半角カナの利用は本来廃止すべきなので、あえて対応しない」という理由により、半角カナを実装していないメールソフトも多い。 その後、以下の事項などの変化により、をでエンコードすることなどで、半角カナを正当な方法で送受信でき、半角カナの使用により問題が発生することは減っている。 メールサーバの多くがSMTPを拡張し8ビットコードも扱えるようになったESMTPに対応した• メッセージ中に文字コードやエンコード方式の情報を明記できるようになった• World Wide Web [ ] 転送プロトコルであるにはSMTPのように8ビットコードを扱えないという問題は存在しない。 ではの上、などでの名義に半角カナを直接入力する場合がある。 全角入力した文字を半角カナのデータに変換する事で意図しない文字数の変化を避ける信頼性確保のためでもある。 に半角カナを書き込んでも、ほとんどの場合、文字化けしない。 また、半角カナを表示不能な端末もある。 文字コードの自動認識は完全たり得ない為、HTTPレスポンスヘッダやMETA要素で文字コード情報のオプションパラメータを指定する場合もある。 また、HTMLのフォームでは、漢字を含むあらかじめ決められた文字列をhiddenフィールドなどを経由しクライアントから送信させるなど、自動認識に依存せずに送信コードを判別する手法も用いられている。 このような確実な対応があれば、文字コード誤認の問題は発生しない。 半角カナが使用されるケース [ ] 現在でもJIS X 0201しか扱えない機器・端末などでは、日本語を表現する手段として半角カナが使用されている。 またソフトウェアやデータの互換性を保つ目的で使用している場合もある。 なお、全角カナとの視覚的差異があることや、文字コード（8ビット）によって、全角カナ（16ビット）の約半分のバイト数しか要さないことなどの特徴から、携帯電話IP接続サービスでは積極的に使用されていた。 前者の特徴は、を使用してテキストのみで表形式を表示する場合などで、上下位置などを合わせる目的として多く使用された。 また、ニュアンスの微妙な違いを伝えたり、を作成するために用いられることも多かった（ただし、発信者と受信者のフォントセットが異なる場合、これはうまくいかないことがある）。 後者の特徴は、例えばなどで使用可能なバイト数に制限がある場合や、1バイトの文字しか使用できないシステムで使用されていた。 また、文字（）通信に課金がなされるような場合（特になどの）に有利になるため、使用されることもあった。 一般的なフォントでは幅が狭く表示されることから、ではメニュー部などで少ない面積でユーザーに情報を与える必要のある場面によく利用されていた。 その後、ひらがな・（全角の）カタカナが細い造型のフォント を用意することによって脱半角カナを図った結果、新規のアプリケーションで半角カナをメニューに用いる例は無くなったとみてよい。 ただ、一般的なと異なり、表示情報量に制約の大きいなどの画面を前提としたシステムでは、半角カナによるシステムが引き続き開発されていた。 また，金融機関のシステムにコンピュータが導入された頃、当時は、高速なコンピュータもネットワーク網もない時代で、日本のコンピュータ全体が、情報量が少なくて済む1バイトの半角カタカナを使っていた。 故に、銀行のシステムも半角カタカナで統一され、全国の金融機関に定着していった。 後に、コンピュータの進化とともに全角文字が使えるようになったものの、一度莫大な資金を投入して出来上がったシステムは簡単に変更出来ず、現在もシステムが未熟な金融機関に合わせ、共通する形式は半角カタカナのままであるケースが多い。 "・「」、。 ー"の6記号の半角版も半角カナの領域となっている。 0xA1—0xA5, 0xB0 脚注 [ ] [].
次の
全角/半角・大文字/小文字の変換をする関数の使い方:Excel関数
この記事にはが含まれているおそれがあります。 問題箇所をしして、記事の改善にご協力ください。 議論はを参照してください。 （ 2018年4月） この項目には、一部のコンピュータやで表示できない文字（ 半角カタカナ）が含まれています （）。 半角カナ（はんかくカナ）、 半角片仮名（はんかくかたかな, Halfwidth Katakana）とは、が半分（）のの事。 では、全角片仮名 Fullwidth Katakana と半角片仮名 Halfwidth Katakana が異なる文字として登録されている。 類似物として、Unicodeには半角 Halfwidth Hangul も登録されている。 では、片仮名を含む他の文字集合と同時に運用される場合におけるの文字集合の通称である。 を含む文字集合で定義された片仮名に対して、半分の文字幅で表示されることが一般的であったためこのように呼ばれる。 JIS X 0201で規定される8ビット符号化およびにおいて0xA1—0xDFの範囲の1文字がこれにあたる。 また、やなどの符号化方式やでも互換性の目的でこの文字集合をもっている。 JIS X 0208:1997『附属書 1（規定）シフト符号化表現』では、「参考 JIS X 0201 の片仮名用図形文字集合の割当ては、この規格の将来の改正では削除することを予定する。 」と記載されている。 :2000『附属書5（規定）文字の代替名称』では HALFWIDTH KATAKANA が記載されているが、「この附属書は、これまでの慣用的な利用との互換を目的としてだけ用いる文字の代替名称を規定する。 」と書かれ、削除予定とは書かれていない。 歴史 [ ] には、7で表現される128文字分のエリアにしか文字は定義されておらず、そこに制御文字、、、などが配置されている。 ASCIIを元に制定された国際規格では10文字が各国特有の文字、記号と交換可能であったが、ラテン文字以外で書かれる言語を符号化するには不足していたため、では、ラテン文字集合とは別にと用のなどを収録した片仮名文字集合を規定し、7ビット環境または8ビット環境で運用するが制定された。 規格で規定された符号化方式のうち、広く使われたのは0x20—0x7Eにラテン文字集合、0xA1—0xDFに片仮名文字集合を割り当てた8ビット符号化方式である。 でを扱うことが困難であった創始期は、この片仮名を用いて日本語でメッセージを表示していた。 そして後にが規定され漢字などが扱えるようになった際、それまでのJIS X 0201の資産がそのまま使えるように、JIS X 0208をそのまま使うのではなく、JIS X 0201で空いていた領域にJIS X 0208の文字コードを移動 Shift して当てはめるが開発され、使用されるようになった。 大型コンピュータ（）で使われていたコードでは、各社ごとに8ビットで表現されるカタカナや日本語の句読点コードを定義していたために、各社間の互換性を欠いていた。 また、コンピュータによる漢字処理が一般化するのは1980年代中頃からで、それまでは8ビットのカタカナを用いてメッセージの表示やデータベースが構築されていた。 そのため、たとえばのコンピュータによる宛名印字はすべてカタカナであった。 呼称 [ ] UnicodeやJIS X 0213 [ ] やではHalfwidth Katakana（半角片仮名）として表記され、これが正式な呼称である。 JIS X 0208 [ ] JIS X 0201（もしくはASCII）とJIS X 0208を組み合わせて使う場合、JIS X 0208側の文字はほぼ正方形で、JIS X 0201の文字はJIS X 0208の文字の半分の幅・同じ高さで表示・印刷されることが一般的であった。 そのため、JIS X 0201の文字は「半角文字」、JIS X 0208の文字は「全角文字」、特にJIS X 0201の方の片仮名は「半角カナ」、「半角カタカナ」と呼ばれるようになった。 （での呼び名、での呼称は半角カタカナ）しかしそもそも半角・全角は字体・フォントの文脈で使われる言葉であり、また一般に文字コードは文字の幅を規定するものではないため、この表現は間違いである。 ただし、EUC-JPには文字表示幅の定義が含まれる。 またUnicodeにも文字幅に関する規定が存在する。 を参照すること。 しかし文字をあらわすのに必要なバイト数は符号化方式でそれぞれ異なる。 実際、「半角カナ」相当の文字を表現するのに、EUC-JPでは2バイト、UTF-16では2バイト、UTF-8では3バイトを要する。 このように正しい名称を与えることが難しいため、結局慣用的な「半角カナ」という呼称が用いられることが多いが、正確性に問題があることに意識がある場合は「 いわゆる半角カナ」といった言い方をされることもある。 「半角カナ」にこだわらず厳密な定義が必要な場合は、その文脈で使われている文字集合によって「JIS X 0201のほうの片仮名」や「Unicodeの半角・全角形の片仮名」と呼ばれる。 符号化方式による半角カナの扱い [ ] ISO-2022-JP [ ] は等で使われる符号化方式であり、エスケープシーケンスによって7ビットの領域に文字集合を指示して運用する。 指示可能な文字集合は、ラテン文字、-1978およびJIS X 0208-1983であり、 JIS X 0201片仮名は含まれていない。 一般に「メールでは半角カナは使えない」といわれるのはこの事による。 が全盛であった頃は、全角文字を使用できない環境との互換性の問題や、データ量や画面表示幅の節約などの面から、2バイト日本語に半角カナが併用されることが頻繁であった。 EUC-JP [ ] 日本語EUC も8ビット環境を前提とした文字コードだが、JIS X 0208の1文字目にあたるコードは、JIS X 0201を1バイトで表した場合の半角カナ部分に重なるように配置されている。 そのため、半角カナに相当する文字を使用する必要がある場合は制御文字SS2（シングルシフト2、0x8E）に続けて使用することになる（このため一見2バイトに見えるが、SS2は文字集合を次の1文字分だけ切り替えるという印のため、片仮名自体はやはり1バイトで符号化される）。 この記法によるカナ使用を実装していない処理系も多い。 これが「半角カナは文字化けする」と言われる理由の1つである。 あくまで過去の文章との互換性を保つためとはいえ、半角カナ、文字コード間の対応が保証されたことにより、将来のシステムで半角カナが非サポートとなるような事態はまず無くなったと考えてよい。 インターネットにおける半角カナ [ ] 電子メール [ ] を配送するというは7ビットのみを透過し、8ビット目をゼロにする仕様であるため、日本では時代に7ビットのみを用いることがルール化された。 これは後にRFC 1468として文書化され、という名称になった。 ISO-2022-JPには半角カナが含まれないため、メッセージ中に半角カナを含むことはできない。 ソフトウェアによっては誤ってメッセージ中に半角カナが含まれていた場合に、8ビットコードのまま送信したり、エスケープシーケンスを用いたり、などでエンコードし7ビット化して送信するソフトウェアが存在した。 後者の場合には、対応したソフト同士であれば問題なく表示が出来るが、違うソフト同士や8ビットで送信された場合は正しく表示されないため、「半角カナを使うとする」と言われるようになった。 ここから、ネット上の文章からの半角カナ撲滅を唱えるような急進的な意見が出現した。 また、当初Windowsに付属していたメールソフトが、を使用した勝手な符号化方法を使用して、他のメールソフトとの互換性をなくしていたこともその意見を強めさせた。 その後、Windowsのメールソフトも、他のメールソフトと同じ符号化方法になったが、「いわゆる半角カナの利用は本来廃止すべきなので、あえて対応しない」という理由により、半角カナを実装していないメールソフトも多い。 その後、以下の事項などの変化により、をでエンコードすることなどで、半角カナを正当な方法で送受信でき、半角カナの使用により問題が発生することは減っている。 メールサーバの多くがSMTPを拡張し8ビットコードも扱えるようになったESMTPに対応した• メッセージ中に文字コードやエンコード方式の情報を明記できるようになった• World Wide Web [ ] 転送プロトコルであるにはSMTPのように8ビットコードを扱えないという問題は存在しない。 ではの上、などでの名義に半角カナを直接入力する場合がある。 全角入力した文字を半角カナのデータに変換する事で意図しない文字数の変化を避ける信頼性確保のためでもある。 に半角カナを書き込んでも、ほとんどの場合、文字化けしない。 また、半角カナを表示不能な端末もある。 文字コードの自動認識は完全たり得ない為、HTTPレスポンスヘッダやMETA要素で文字コード情報のオプションパラメータを指定する場合もある。 また、HTMLのフォームでは、漢字を含むあらかじめ決められた文字列をhiddenフィールドなどを経由しクライアントから送信させるなど、自動認識に依存せずに送信コードを判別する手法も用いられている。 このような確実な対応があれば、文字コード誤認の問題は発生しない。 半角カナが使用されるケース [ ] 現在でもJIS X 0201しか扱えない機器・端末などでは、日本語を表現する手段として半角カナが使用されている。 またソフトウェアやデータの互換性を保つ目的で使用している場合もある。 なお、全角カナとの視覚的差異があることや、文字コード（8ビット）によって、全角カナ（16ビット）の約半分のバイト数しか要さないことなどの特徴から、携帯電話IP接続サービスでは積極的に使用されていた。 前者の特徴は、を使用してテキストのみで表形式を表示する場合などで、上下位置などを合わせる目的として多く使用された。 また、ニュアンスの微妙な違いを伝えたり、を作成するために用いられることも多かった（ただし、発信者と受信者のフォントセットが異なる場合、これはうまくいかないことがある）。 後者の特徴は、例えばなどで使用可能なバイト数に制限がある場合や、1バイトの文字しか使用できないシステムで使用されていた。 また、文字（）通信に課金がなされるような場合（特になどの）に有利になるため、使用されることもあった。 一般的なフォントでは幅が狭く表示されることから、ではメニュー部などで少ない面積でユーザーに情報を与える必要のある場面によく利用されていた。 その後、ひらがな・（全角の）カタカナが細い造型のフォント を用意することによって脱半角カナを図った結果、新規のアプリケーションで半角カナをメニューに用いる例は無くなったとみてよい。 ただ、一般的なと異なり、表示情報量に制約の大きいなどの画面を前提としたシステムでは、半角カナによるシステムが引き続き開発されていた。 また，金融機関のシステムにコンピュータが導入された頃、当時は、高速なコンピュータもネットワーク網もない時代で、日本のコンピュータ全体が、情報量が少なくて済む1バイトの半角カタカナを使っていた。 故に、銀行のシステムも半角カタカナで統一され、全国の金融機関に定着していった。 後に、コンピュータの進化とともに全角文字が使えるようになったものの、一度莫大な資金を投入して出来上がったシステムは簡単に変更出来ず、現在もシステムが未熟な金融機関に合わせ、共通する形式は半角カタカナのままであるケースが多い。 "・「」、。 ー"の6記号の半角版も半角カナの領域となっている。 0xA1—0xA5, 0xB0 脚注 [ ] [].
次の