半角カナ
歴史
ASCIIには、7ビットで表現される128文字分のエリアにしか文字は定義されておらず、そこに制御文字、ラテン文字、数字、約物などが配置されている。ASCIIを元に制定された国際規格ISO 646では10文字が各国特有の文字、記号と交換可能であったが、ラテン文字以外で書かれる言語を符号化するには不足していたため、日本では、ラテン文字集合とは別に片仮名と日本語用の句読点などを収録した片仮名文字集合を規定し、7ビット環境または8ビット環境で運用するJIS X 0201が制定された。規格で規定された符号化方式のうち、広く使われたのは0x20–0x7Eにラテン文字集合、0xA1–0xDFに片仮名文字集合を割り当てた8ビット符号化方式である。コンピュータで漢字を扱うことが困難であった創始期は、この片仮名を用いて日本語でメッセージを表示していた。そして後にJIS X 0208が規定され漢字などが扱えるようになった際、それまでのJIS X 0201の資産がそのまま使えるように、JIS X 0208をそのまま使うのではなく、JIS X 0201で空いていた領域にJIS X 0208の文字コードを移動 (Shift) して当てはめるShift_JISが開発され、使用されるようになった。
大型コンピュータ（メインフレーム）で使われていたEBCDICコードでは、各社ごとに8ビットで表現されるカタカナや日本語の句読点コードを定義していたために、各社間の互換性を欠いていた。
また、コンピュータによる漢字処理が一般化するのは1980年代中頃からで、それまでは8ビットのカタカナを用いてメッセージの表示やデータベースが構築されていた。そのため、たとえばダイレクトメールのコンピュータによる宛名印字はすべてカタカナであった。
Unicode や JIS X 0213
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の方の片仮名は「半角カナ」、「半角カタカナ」と呼ばれるようになった。（マイクロソフトでの呼び名、MS-IMEでの呼称は半角カタカナ）しかしそもそも半角・全角は字体・フォントの文脈で使われる言葉であり、また一般に文字コードは文字の幅を規定するものではないため、この表現は間違いである。ただし、EUC-JPには文字表示幅の定義が含まれる。またUnicodeにも文字幅に関する規定が存在する。東アジアの文字幅を参照すること。
Shift_JISではJIS X 0201の片仮名は1バイト、漢字などは2バイトで表されることから「1バイトカナ」と呼ばれることもある。しかし文字をあらわすのに必要なバイト数は符号化方式でそれぞれ異なる。実際、「半角カナ」相当の文字を表現するのに、EUC-JPでは2バイト、UTF-16では2バイト、UTF-8では3バイトを要する。
このように正しい名称を与えることが難しいため、結局慣用的な「半角カナ」という呼称が用いられることが多いが、正確性に問題があることに意識がある場合は「いわゆる半角カナ」といった言い方をされることもある。「半角カナ」にこだわらず厳密な定義が必要な場合は、その文脈で使われている文字集合によって「JIS X 0201のほうの片仮名」や「Unicodeの半角・全角形の片仮名」と呼ばれる。
ISO-2022-JP
ISO-2022-JPは電子メール等で使われる符号化方式であり、エスケープシーケンスによって7ビットの領域に文字集合を指示して運用する。指示可能な文字集合はASCII、JIS X 0201ラテン文字、JIS X 0208-1978およびJIS X 0208-1983であり、JIS X 0201片仮名は含まれていない。一般に「メールでは半角カナは使えない」といわれるのはこの事による。
Shift_JIS
Shift_JISは、JIS X 0201の8ビット符号の未使用領域に漢字などの1バイト目を割り当てたエンコーディングであるので、エスケープシーケンスなどを用いず半角カナや漢字を使用できる。MS-DOSが全盛であった頃は、全角文字を使用できない環境との互換性の問題や、データ量や画面表示幅の節約などの面から、2バイト日本語に半角カナが併用されることが頻繁であった。
1バイトJIS X 0201との共存を前提としたため、JIS X 0208文字の1バイト目に使用できる領域が限られた結果、2バイト目に7ビットコードを使用せざるを得なくなり、8ビットを利用した符号化にも関わらず、Shift_JISを理解しない処理系での扱いを難しいものにしてしまった。
EUC-JP
日本語EUC (EUC-JP) も8ビット環境を前提とした文字コードだが、JIS X 0208の1文字目にあたるコードは、JIS X 0201を1バイトで表した場合の半角カナ部分に重なるように配置されている。そのため、半角カナに相当する文字を使用する必要がある場合は制御文字SS2（シングルシフト2、0x8E）に続けて使用することになる（このため一見2バイトに見えるが、SS2は文字集合を次の1文字分だけ切り替えるという印のため、片仮名自体はやはり1バイトで符号化される）。この記法によるカナ使用を実装していない処理系も多い。
EUC-JPにおいてJIS X 0208を表すために使用されるコード範囲 (0xA1-0xFE) は、1バイトカナのコード範囲 (0xA1-0xDF) を完全に内包するため、偶数の文字数で書かれたShift_JISの半角カナは、EUC-JP文字列と（頻度やパターンからの推測以外の方法では）区別がつかない。逆に、EUC-JPの半角カナ（1バイト目0x8E、2バイト目0xA1-0xFE）文字列も、Shift_JIS文字列と区別がつかない。これが「半角カナは文字化けする」と言われる理由の1つである。
Unicode (UTF-8, UTF-16 など)
過去、すでに多くのShift_JIS等の文書で半角カナが使用されており、それらの文書のコード変換において情報が欠損しないようにするために（いわゆるround-trip conversionの保証）、Unicodeには通常（Fullwidth）の片仮名とは別に半角カナに相当する互換用文字が定義されている。具体的にはHalfwidth and Fullwidth Formsの中にHalfwidth CJK punctuation（U+FF61〜FF64）とHalfwidth Katakana variants（U+FF65〜FF9F）が含まれている。あくまで過去の文章との互換性を保つためとはいえ、半角カナ、文字コード間の対応が保証されたことにより、将来のシステムで半角カナが非サポートとなるような事態はまず無くなったと考えてよい。
World Wide Web
転送プロトコルであるHTTPにはSMTPのように8ビットコードを扱えないという問題は存在しない。文書を記述するHTMLについては、Shift_JISやEUC-JP、Unicodeなど半角カナを扱える文字コードであれば、そのまま半角カナを使用できる。
インターネットバンキングでは全国銀行データ通信システムの互換性上、振込などでの口座名義に半角カナを直接入力する場合がある。全角入力した文字を半角カナのデータに変換する事で意図しない文字数の変化を避ける信頼性確保のためでもある。
電子掲示板に半角カナを書き込んでも、ほとんどの場合、文字化けしない。ただし、半角カナを使用した場合、前述したようにShift_JISとEUC-JPを区別することが難しいため、ブラウザやCGIなどで文字コードの自動認識に失敗する事が多いという問題がある。また、半角カナを表示不能な端末もある。
文字コードの自動認識は完全たり得ない為、HTTPレスポンスヘッダやMETA要素で文字コード情報のオプションパラメータを指定する場合もある。また、HTMLのフォームでは、漢字を含むあらかじめ決められた文字列をhiddenフィールドなどを経由しクライアントから送信させるなど、自動認識に依存せずに送信コードを判別する手法も用いられている。このような確実な対応があれば、文字コード誤認の問題は発生しない。
半角カナが使用されるケース
現在でもJIS X 0201しか扱えない機器・端末などでは、日本語を表現する手段として半角カナが使用されている。またソフトウェアやデータの互換性を保つ目的で使用している場合もある。
なお、全角カナとの視覚的差異があることや、文字コード（8ビット）によって、全角カナ（16ビット）の約半分のバイト数しか要さないことなどの特徴から、携帯電話IP接続サービスでは積極的に使用されていた。
前者の特徴は、等幅フォントを使用してテキストのみで表形式を表示する場合などで、上下位置などを合わせる目的として多く使用された。また、ニュアンスの微妙な違いを伝えたり、アスキーアートを作成するために用いられることも多かった（ただし、発信者と受信者のフォントセットが異なる場合、これはうまくいかないことがある）。
後者の特徴は、例えばデータベースなどで使用可能なバイト数に制限がある場合や、1バイトの文字しか使用できないシステムで使用されていた。また、文字（パケット）通信に課金がなされるような場合（特に携帯電話などのパケット通信）に有利になるため、使用されることもあった。
一般的なフォントでは幅が狭く表示されることから、Microsoft Windowsではメニュー部などで少ない面積でユーザーに情報を与える必要のある場面によく利用されていた。その後、ひらがな・（全角の）カタカナが細い造型のフォント (MS UI Gothic) を用意することによって脱半角カナを図った結果、新規のアプリケーションで半角カナをメニューに用いる例は無くなったとみてよい。ただ、一般的なデスクトップコンピュータシステムと異なり、表示情報量に制約の大きいフィーチャー・フォンなどの画面を前提としたシステムでは、半角カナによるシステムが引き続き開発されていた。また，金融機関のシステムにコンピュータが導入された頃、当時は、高速なコンピュータもネットワーク網もない時代で、日本のコンピュータ全体が、情報量が少なくて済む1バイトの半角カタカナを使っていた。故に、銀行のシステムも半角カタカナで統一され、全国の金融機関に定着していった。後に、コンピュータの進化とともに全角文字が使えるようになったものの、一度莫大な資金を投入して出来上がったシステムは簡単に変更出来ず、現在もシステムが未熟な金融機関に合わせ、共通する形式は半角カタカナのままであるケースが多い。