[13] euc-jp
は、日本でかつてよく使われていた文字コードでした。
[35] 20世紀に UNIX 系の OS では日本語の標準文字コードとして用いられていました。
[36] ASCII のバイトが常に ASCII を表す特徴から、 Perl などの ASCII ベースのプログラミング言語のソースコードの記述に適切とされていました。 90年代末から00年代初頭には CGIスクリプト等の Webアプリケーションの内部コードおよび入出力用コードとしてよく採用されていました。
[96] DTI ユビキタスプロバイダ | My DTIログイン, https://oc.dti.ne.jp/cgi-bin/uss/index.cgi
<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" />
[16] 日本国内では外にシフトJISや ISO-2022-JP がよく使われていました。
[14] 歴史的に無数の変種があります。
[34] 日本語 UNIX システム諮問委員会が1985年に UNIX システム日本語機能提案書で日本語 EUC の内部コードを定義したといわれています。
[37] AT&T の System V Interface Definition が、それに基づき SCS (Supplementary Code Set) を規定したといわれています。
[38] 更に、 AT&T UNIX Pacific が SCS のことを EUC と呼んだと言われています。
[15] AT&T UNIX Pacific の JAE (Japanese Application Environment) が規定したのは... となっていたようです。
[39] 日本語EUC、AT&T code、eucjis、JA16EUC、EUC-jis、euc などと呼ばれました。
[33] UJIS (Unixnized extended JIS) は、 Σ OS が採用した文字コードとされています。 実際には当時の日本語EUCと同じものだったようです。
[22] 日本語EUCの歴史 ( 版) http://d.hatena.ne.jp/nurse/20090308#1236517235
[23] 石井晴久氏による EUC 前史 ( 版) http://d.hatena.ne.jp/nurse/20090310#1236625695
[45] 1993年5月21日の UI-OSF Japanese Localization Group の UI-OSF 日本語環境実装規約 Version 1.1 は、 附属書Cで「UI-OSF共通日本語EUC」を規定していました。 これは1991年12月12日のUI-OSF-USLP 共同技術資料: 日本語EUC の定義と解説と同じもので、 AJEC (Advanced Japanese EUC) を規定していました。
[46] AJEC は、 G1 の 85〜94区と G3 の 78〜94区を共通自由領域としていました。
[47] この AJEC に対して eucJP
という名前が定義されていました。
[59] 1992年に出版された UNIX インターナショナルの UNIX SYSTEM V リリース 4 日本語環境共通規約 第1版にも定義が含まれていると言われます。
[30] CALS 「共通符号の案」 >>29, NCALS共通文字符号 >>32
[31] G3 を左側に呼び出すところだけEUCと違います (古い ISO/IEC 2022 に忠実な仕様)。 理由は SGML の具象構文との整合性 >>32。
[19] numa's diary:補助漢字と日本語 EUC - livedoor Blog(ブログ) (2007-06-09 05:12:05 +09:00
版) http://blog.livedoor.jp/numa2666/archives/50236450.html
(名無しさん 2007-06-24 10:28:35 +00:00)
[20] Linux における日本語ロケールに関する指針 (2001-10-28 23:57:31 +09:00
版) http://www.linux.or.jp/JF/JFdocs/Japanese-Locale-Policy.txt
(名無しさん 2007-06-24 10:40:34 +00:00)
[21] 革命の日々! IEがEUCのJIS X 212をサポートしていないのは規格違反なのか (2007-06-24 19:43:01 +09:00
版) http://mkosaki.blog46.fc2.com/blog-entry-260.html
[18] JIS X 0208:1997の附属書にはシフト符号化表現とRFC1468符号化表現のみが定義されており、日本語EUCに相当するものはありません(おそらくなかったことにする予定だったJIS X 0212に触れたくなかったのでしょう)。 ただし本体の国際基準版・漢字用8ビット符号はJIS X 0201 片仮名とJISX0212-1990を含まない日本語EUCであるとみなせます。 (名無しさん 2007-05-17 19:57:27 +00:00)
[40] UJIS に IBM拡張漢字を加えたものが IBM-eucJP と言われています。
[41] UJIS の G1 に利用者定義領域 (外字) を加えたものが S90 と言われています。
[42] Data General が用いたものが IKIS code といわれています。 UJIS とは JIS X 0201片仮名用図形文字集合が異なっていたそうです。
[43] EUC-HJ (Extended UNIX Code HITACHI) は 0xA121-FE7E を利用者定義 (外字) に使っていました。
[44] OCMP (NEC + SONY) は、 OCMP-ABI 「日本語共通アプリケーションバイナリ規約」 で G3 の空き領域に共通外字を規定していました。
[56] 富士通の U90 と呼ばれる拡張は、 G0 に JIS X 0201ラテン文字用図形文字集合 (!)、 G1 に JIS X 0208-1990、 G2 に JIS X 0201片仮名用図形文字集合を採用し、 JIS X 0208 の61〜93区 (?) は利用者定義 (外字)、 85〜94区は OASYS の独自の非漢字としています。 更に G3 の1〜48区は JEF の独自の漢字、 49〜60区は JEF の独自の非漢字としているようです。
[58] G3 の1-26区をシフトJISの 0xF040-FCFC に対応付ける実装もあったようです。
[74] [PATCH libX11 4/5] i18n: Remove ja.S90 and ja.U90 locales., , https://lists.x.org/archives/xorg-devel/2012-December/034661.html
[97] DAL-データ・アプリケーション|リリースノート|RACCOON V2.6.1 リリースノート情報, https://www.dal.co.jp/release-notes/raccoon/20240411_0.html
[57] インフォミックスの拡張は、 0x8DF040-8DFCFC をシフトSJIS 0xF040-FCFC に相当するものとして使っていました。
eucJP-open
[48] eucJP-open
は、 UI-OSF 日本語環境実装規約の
eucJP
の共通自由領域に IBM拡張漢字を追加したものでした。
[49] G1 は JIS X 0208-1990 で、85-94区が共通自由領域でした。
[50] G3 は JIS X 0212-1990 で、78-94区が共通自由領域でしたが、 そのうち83区と84区に IBM の拡張が割り当てられていました。
[51] SJIS-open
との対応関係が規定されていました。
[67] eucJP-ms, , http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html
[75] eucJP-open ‐ 通信用語の基礎知識, https://www.wdic.org/w/WDIC/eucJP-open
[17] JIS X 0213:2000 は EUC-JISX0213 を定義しています。
[85] JIS X 0213:2000 本体に国際基準版・漢字用8ビット符号なるものがあり、 その拡張と書いてあります。
[86] 実装水準3であることを明示するため EUC-JISX0213-plane1 と呼んでもよいとされます。 EUC-JISX0213 は実装水準3と実装水準4の両方を含むようです。 実装水準4と明示する方法はなさそうです。
SP
DEL
SS2
/ G2 : 使用しない、ただし代替名称SS3
/ G3 : JIS X 0213:2000 第2面[88] 国際基準版・漢字用8ビット符号との違いは G2。 G2 は JIS X 0201 片仮名用図形文字相当 (代替名称)。
[89] G2, G3 は EUC なら右側に呼び出すべきだが、 左か右か明記されていない。 (インデント的に直前の GR 領域云々の箇条には含まれなそう。)
[82] x-euc-jisx0213-packed は、 EUC-JISX0213 の空き領域に JIS X 0212-1990 を割り当てたものです。
[80]
Perl の Encode.pm
の euc-jp
は、
一般的な EUC-JP の相互変換に加え、
JIS X 0213:2000 の第1面、第2面の復号に対応しています。
JIS X 0212 の TILDE
も復号のみ対応しています。
>>81
[83]
JIS X 0213:2004
では第1面が改正されました。
[84] ORCA Project: 拡張漢字(JISX0213:2004)の使用, , https://www.orca.med.or.jp/receipt/use/jisx0213/
[90] 文字セットについて - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/06-05-07.html
[91] 超漢字メールはEUC-JPJISX0213 (+ テキスト形式TRONコード) の送受信に対応していました。 >>90 EUC-JISX0213 のことでしょう。
EUC-JP
[5] IANAのcharset登録簿には、2006年3月現在
Name: Extended_UNIX_Code_Packed_Format_for_Japanese MIBenum: 18 Source: Standardized by OSF, UNIX International, and UNIX Systems Laboratories Pacific. Uses ISO 2022 rules to select code set 0: US-ASCII (a single 7-bit byte set) code set 1: JIS X0208-1990 (a double 8-bit byte set) restricted to A0-FF in both bytes code set 2: Half Width Katakana (a single 7-bit byte set) requiring SS2 as the character prefix code set 3: JIS X0212-1990 (a double 7-bit byte set) restricted to A0-FF in both bytes requiring SS3 as the character prefix Alias: csEUCPkdFmtJapanese Alias: EUC-JP (preferred MIME name)
とあります。
EUC-JP
(XML)[4]
XML 1.0およびXML 1.1の仕様書
IW:XML1:"#charencoding" では、
符号化宣言 (encoding
擬似属性)
の値EUC-JP
は
SHOULD be used for the various encoded forms of JIS X-0208-1997
とされています。
これをどう解釈するべきかははっきりしません。
JIS X 0208:1997にはEUC-JP
とよばれる符号化文字集合は規定されていないようです。
だとすると、一般にEUC-JP
と呼ばれている符号化文字集合の亜種で
JIS X 0208:1997を採用したものと考えるべきでしょうか。
[7] JIS X 0208:1997 の解説には、EUC
と呼ばれるISO/IEC 2022とJIS X 0208を用いた文字コードが実装されていることが指摘されています。
従って、JIS X 0208:1997の制定当時一般にEUC
と呼ばれていたものを、
JISでは本来新旧版が並存することはなく、最新版だけが有効だという原則
(同解説の別の箇所にそうあります。)
に従い、JISを最新の規格に改めたものがJIS X 0208:1997のEUC-JP
ではないかと考えられます。
[8] ISO/IEC 2022に従った文字コードだとすると、 図形文字の一意な符号化に関する制限 (JIS X 0202:1998 7.5) が適用される可能性がありますが、 JIS X 0208:1997 9.2 によればこれまでの慣用的な利用との互換のために代替名称を用いても構いません。
その場合、REVERSE SOLIDUS
とYEN SIGN
の問題があります。
(図形文字の一意な符号化の項を参照。)
また、ASCIIとJIS X 0212‐1990 が含まれるので、
TILDE
も問題があります。
(図形文字の一意な符号化の項を参照。)
[9] 更に厳密には、そのEUC
の1バイト左半分がASCIIなのかISO/IEC 646なのか、
という問題があります。JIS X 0208:1997はISO/IEC 646と併用する際に代替名称を認めていますが、
ASCIIとは認めていません。 (ASCIIとISO/IEC 646
IRVはたまたま1997年の時点では (少なくても文字名称によって比較すれば)
同じ符号化文字集合を規定しています。)
注意して読むとJIS X 0208:1997の規定はISO/IEC 646に関するもので、 ISO/IEC 646 IRVとは書いていませんから、 IRVに対するものとも、ISO/IEC 646の版いずれに対するものとも読めますが、 ISO/IEC 646とJIS X 0201が併記されていることから、 IRVと解釈する方が適当だと思われます。 (ただし、7.2にはIRVと明記されていますが、こちらでは明記されていないのが気に掛かります。)
[77] Windows の CP51932 は Unicode ←→ CP932 の変換に シフトJIS ←→ EUC変換を組合せたものらしい。
Unicode → CP932 → CP51932 の途中で EUC に変換できないものが出てもそのまま素通しする。 (変換できない EUDC と変換できる NEC選定IBM拡張文字の一部がだぶるなどして復元不可、 CP51932 自身も復号できないらしい。)
[26] Registration of new charset CP51932 ( 版) http://mail.apps.ietf.org/ietf/charsets/msg01877.html
[68] Firefox は CP51932 + JIS X 0212 を実装していました。 復号だけでなく符号化にも使っていました。 >>69, >>70, >>71
[72] 7444 – EUC-JP and ISO-2022-JP also need replacement encodings: CP51932 (or eucJP-ms) and CP50221., , https://www.w3.org/Bugs/Public/show_bug.cgi?id=7444
[24] Web Applications 1.0 r5560 Canonical mapping for EUC-JP for compat reasons.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7444 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5559&to=5560
[25] ブログ オンラインサービス - Infoseekディレクトリ ( 版) http://directory.www.infoseek.co.jp/Topic/14/180/22633
Content-Type: text/html;charset=eucJp-open
<meta http-equiv="content-type" content="text/html; charset=euc-jp">
EUC-JP
で、 EUC-JP
の G3
は JISX0212-1990 で、その JIS X 0212-1990 には COPYRIGHT SIGN
が規定されているので、きちんと保存・表示出来て当たり前なのでした。[53] なお、JIS X 0212 エンコーダの削除が Mozilla では提案されている http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5184
[10] Bug 600715 – Remove JIS X 0212 support from EUC-JP encoder ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=600715
[11] Bug 16689 – consider a flag for euc-jp ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=16689
[12] Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e ( 版) https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd
[60] Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6 ( 版) https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84
[61] Editorial: avoid upsetting lazy compilers (#55) ( (annevk著, )) https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11
[62] Note >8835 pointers in index jis0208 cannot be reached (annevk著, ) https://github.com/whatwg/encoding/commit/fb87552bfa03cc93a1077c8f13e2f58535d0e97c
[63] EUC-JP decoder: only unwind ASCII bytes (annevk著, ) https://github.com/whatwg/encoding/commit/a85149b9eb973e3ec543690fa1b8d5c441e8b3c0
[64] Editorial: check non-null before null (annevk著, ) https://github.com/whatwg/encoding/commit/4e53e160b9e0ade6e33a25d21580106a0db2c47f
[65] Comments on XML Part 1 from Japanese experts (Murata Makoto著, ) https://lists.w3.org/Archives/Public/w3c-sgml-wg/1997May/0612.html
[92] 超漢字4の新機能・変更点, , http://www.chokanji.com/support/ck4/chokanjians/vupguider4.html
EUC-JISX0208(補助漢字なし)の出力変換の機能を追加しました。