ISO-2022-JP
ISO-2022-JPは、インターネット上（特に電子メール）などで使われる日本の文字用の文字符号化方式。ISO/IEC 2022のエスケープシーケンスを利用して文字集合を切り替える7ビットのコードであることを特徴とする (アナウンス機能のエスケープシーケンスは省略される)。俗に「JISコード」と呼ばれることもある。
概要
編集日本語表記への利用が想定されている文字コードであり、日本語の利用されるネットワークにおいて、日本の規格を応用したものである。また文字集合としては、日本語で用いられる漢字、ひらがな、カタカナはもちろん、ラテン文字、ギリシア文字、キリル文字なども含んでおり、学術や産業の分野での利用も考慮したものとなっている。規格名に、ISOの日本語の言語コードであるjaではなく、国・地域名コードのJPが示されているゆえんである。
文字集合としてJIS X 0211のC0集合（制御文字）、JIS X 0201のラテン文字集合、ISO 646の国際基準版図形文字、JIS X 0208の1978年版 (JIS C 6226-1978) と1983年および1990年版が利用できる。JIS X 0201の片仮名文字集合は利用できない。1986年以降、日本の電子メールで用いられてきたJUNETコードを、村井純、Mark CrispinおよびErik van der Poelが1993年にRFC化したもの (RFC 1468)。後にJIS X 0208:1997の附属書2としてJISに規定された。MIMEにおける文字符号化方式の識別用の名前としてIANAに登録されている。
なお、符号化の仕様についてはISO/IEC 2022#ISO-2022-JPも参照。
類似の符号化方式
編集「ISO-2022-JP」に類似した符号化方式として以下のようなものがある。なお、一部は MIME で用いる文字符号化方式として IANA が登録している。
- ISO-2022-JP-1
- RFC 2237。ISO-2022-JPを拡張し、ISO-2022-JPの文字集合に加え、JIS X 0212を利用できるようにしたもの。
- ISO-2022-JP-2
- RFC 1554。ISO-2022-JPを拡張し、ISO-2022-JPの文字集合に加え、JIS X 0212、KS X 1001、GB 2312、ISO 8859-1、ISO 8859-7を利用できるようにしたもの。
- ISO-2022-JP-3
- JIS X 0213:2000の附属書2に記述される符号化表現で、ISO-2022-JPの漢字集合をJIS X 0213に変えるなどしたもの。IANA登録簿への登録が提案されたが、RFC 2278（当時。RFC 2978により廃止された）の手続きに従っていない（いっぺんに複数の文字コードを登録する手続きは存在しないのに6つ同時に申請されている）などの理由により却下された[1]。
- ISO-2022-JP-2004
- JIS X 0213:2004の附属書2に記述される符号化表現。ISO-2022-JP-3の漢字をJIS X 0213:2004に改めたもの。IANA登録簿への登録はまだされていない。
ISO-2022-JPと非標準的拡張使用
編集「JISコード」（または「ISO-2022-JP」）というコード名の規定下では、その仕様通りの使用が求められる。しかし、Windows OS上では、実際にはCP932コード（マイクロソフトによるShift_JISを拡張した亜種。ISO-2022-JP規定外文字が追加されている。）による独自拡張（の文字）を断りなく使うアプリケーションが多い。この例としてInternet ExplorerやOutlook Expressがある。また、EmEditor、秀丸エディタやThunderbirdのようなマイクロソフト以外のWindowsアプリケーションでも同様の場合がある。この場合、ISO-2022-JPの範囲外の文字を使ってしまうと、異なる製品間では未定義不明文字として認識されるか、もしくは文字化けを起こす原因となる。そのため、Windows用の電子メールクライアントであっても独自拡張の文字を使用すると警告を出したり、あえて使えないように制限しているものも存在する。さらにはISO-2022-JPの範囲内であってもCP932は非標準文字（FULLWIDTH TILDE等）を持つので文字化けの原因になり得る。Javaはバージョン6以降で、通常のISO-2022-JP形式の実装のほか、「x-windows-iso2022jp」というコード名でマイクロソフトCP932ベースの拡張ISO-2022-JPに対応している[2]。
また、符号化方式名をISO-2022-JPとしているのに、文字集合としてはJIS X 0212（補助漢字）やJIS X 0201の片仮名文字集合（いわゆる半角カナ）をも符号化している例があるが、ISO-2022-JPではこれらの文字を許容していない。これらの符号化は独自拡張の実装であり、中にはISO/IEC 2022の仕様に準拠すらしていないものもある[3]。従って受信側の電子メールクライアントがこれらの独自拡張に対応していない場合、その文字あるいはその文字を含む行、時にはテキスト全体が文字化けすることがある。
関連項目
編集参考資料
編集- J. Murai 他 (1993年6月). RFC 1468 Japanese Character Encoding for Internet Messages (『インターネットメッセージのための日本語文字符号化』).
- M. Ohta 他 (1993年12月). RFC 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP (『ISO-2022-JP-2: ISO-2022-JPの多言語拡張』).
- K. Tamaru 他 (1997年11月). RFC 2237 Japanese Character Encoding for Internet Messages (『インターネットメッセージのための日本語文字符号化』).
- 日本規格協会 (2000年). JIS X 0213:2000 『7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合』 (7-bit and 8-bit double byte coded extended Kanji sets for information interchange) 附属書2「ISO-2022-JP-3符号化表現」.
- 日本規格協会 (2004年). JIS X 0213:2000/AMENDMENT 1:2004 『7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合 (追補1)』 (7-bit and 8-bit double byte coded extended Kanji sets for information interchange (Amendment 1)) 附属書2「ISO-2022-JP-2004符号化表現」.
- ^ Harald Tveit Alvestrand (Fri, 07 Apr 2000 10:41:39 +0200). “Rejection of registration of new Japanese charsets”. ietf-charsets@w3.org Mailing List. 2008年2月2日閲覧。 - ISO-2022-JP-3登録の却下の経緯。
- ^ “サポートされているエンコーディング”. サン・マイクロシステムズ. 2017年5月29日閲覧。
- ^ 森山将之 (1997年6月3日). “JIS X 0201 片仮名”. 2008年2月2日閲覧。