| No.055 | 投稿日時: | 2003/04/17(木) 20:22 <親記事> |
| 投稿者: | えびはら |
初めまして、えびはらと申します。
異種システム間のデータ連携に関連して、文字コードのことを色々調べております。
さて、早速の質問で恐縮ですが、シフトJIS系のエンコーディングには色々とありますが、
それぞれがどのように異なるのかについてご教示いただきたいと思っています。
以下は私が調査した結果なのですが、もしこの中に誤解があればご指摘いただけないでしょうか。
よろしくお願いします。
--
各エンコーディングがサポートする文字集合は以下の通り。
Shift_JIS
- JIS X 0201.1976
- JIS X 0208.1983 or 1990
Cp932
- JIS X 0201.1976
- JIS X 0208.1983
- IBM拡張文字
(※ http://www.unet.univie.ac.at/aix/aixprggd/genprogc/codeset_over.htm より)
Cp943
Cp943C
MS932
- JIS X 0201.1976
- JIS X 0208.1990
- NEC特殊文字
- NEC選定IBM拡張文字
- IBM拡張文字
これらのエンコーディングにおいては各キャラクタのコードポイントは同じなので、
コード変換は不要である。
例えばMS932のテキストはそのままCp943C(Cp943)として取り扱うことができる。
ただしCp943は他の2つに比べ、以下のコードポイントも持つ。
・0x80: Cent sign(Cp943)
・0xA0: Pound sterling sign(Cp943)
・0xFD: Not sign(Cp943)
・0xFE: Backslash(Cp943)
・0xFF: Tilde(Cp943)
また、一部の文字のUnicodeへのマッピングポイントが異なる。
MS932とCp943C
"−", "〜", "‖", "―", "〓"
(※ http://www-6.ibm.com/jp/software/websphere/developer/wsv35wslib/pdf/was35_psj5_1.pdf より)
Cp943とCp943C
・0x5C("\") → U007F(Cp943C, Back Slash), U00A5(Cp943, Yen Sign)
・0x7E("~") → U007E(Cp943C, Tilde), U203E(Cp943, Overline)
(※ http://www.os2ss.com/news/misc/java114.readme より)
そのためMS932のテキストをUnicodeに変換し、その後Cp943Cに変換すると、元のテキストとは
異なるコードになってしまう文字がある。
| No.056 | 投稿日時: | 2003/04/18(金) 07:31 <↑親記事:No.055> |
| 投稿者: | 森山 将之 |
はじめまして、えびはらさん。
コードページとして CpXXX (IBM のコードページ) と MSXXX (Windows のコードページ) の 2種類を使い分けているという所を見ると、Java の事でしょうか?
以前、Windowsのコードページ 932 (Windows-31J) 絡みで Java のエンコーディングも少しだけ調べてみた事があるという程度の知識しかなく、Cp932(IBM-932)、Cp943、Cp943C に関しては、よく分かっていないのですが、えびはらさんの調査結果に関して誤解されているというところはないのではないかと思います。(私自身、IBM のコードページについては勉強不足で確かなことは言えませんが。)
Cp932 に関しては、Java の用法に従うと IBM のコードページ 932 のようですが、Java 以外では、cp932 を Windows のコードページ 932 (Java の MS932) として扱っているソフトもあるので、注意を要するといったくらいでしょうか。
> また、一部の文字のUnicodeへのマッピングポイントが異なる。
> MS932とCp943C
> "−", "〜", "‖", "―", "〓"
> (※ http://www-6.ibm.com/jp/software/websphere/developer/wsv35wslib/pdf/was35_psj5_1.pdf より)
一部文字化けしていますね。
左から順番に次のようになっていると思われます。
"−" [817C] 01区61点
"〜" [8160] 01区33点
"‖" (U2016)→"‖" [8161] 01区34点
"―" [815C] 01区29点
"〓" [FA55] 115区23点 IBM拡張文字 (いわゆる機種依存文字なので、この掲示板ではゲタ記号"〓" に変換しています。)
他の注意点としては次のような事があります。
SJIS と MS932 では、次の文字について Unicode との対応関係が異なります。
"〜" [8160]
"‖" [8161]
"−" [817C]
"¢" [8191]
"£" [8192]
"¬" [81CA]
SJIS と Cp943C では、次の文字について Unicode との対応関係が異なります。
"―" [815C]
"¢" [8191]
"£" [8192]
"¬" [81CA]
EUC_JP や ISO2022JP は、Unicode との対応に関しては、SJIS と同じなので、EUC_JP と MS932/Cp943C、ISO2022JP と MS932/Cp943C も同様の問題があります。
※Java の SJIS, EUC_JP, ISO2022JP は、ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT のマッピングを用いているようです。("―" 01区29点 が JIS X 0208:1997 の解釈と異なる点に注意。)
あまり参考にならなかったかもしれません。
以前調べた時に次のページを参考にしましたので紹介いたします。
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
Javaの日本語関連コンバータにおけるマッピングの違い
http://www.ingrid.org/java/i18n/encoding/ja-conv.html
サポートされているエンコーディング (Java 2 Platform, Standard Editionv 1.3)
http://java.sun.com/j2se/1.3/ja/docs/ja/guide/intl/encoding.doc.html
インストール関連情報 Hints＆Tips (コードページ 943 の簡単な説明あり)
http://www-6.ibm.com/jp/pspjinfo/os2/hints/128.html
従来の文字コードとUnicodeの対応に関する諸問題
http://euc.jp/i18n/ucsnote.ja.html
変換表がベンダーによって異なる
http://www.debian.or.jp/~kubota/unicode-symbols-map2.html
※この中で登場する CP932 は、Windows Code Page 932 (Java で は MS932) の事になります。
文字コードについてのメモ
http://www.asahi-net.or.jp/~wq6k-yn/code/
※「JIS漢字とUCSの文字の対応について」で "―" 01区29点 についての指摘あり。
IANA > Character Sets
http://www.iana.org/assignments/character-sets
※Shift_JIS, Windows-31J (MS932)
Windows-31J (Windows Code Page 932) に関しては、私が調べて分かったことをまとめたページがあります。
Windows-31J 情報
http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/index.html
実を言うと、eucJP-ms の説明は、ちょっと自信がありません。
また、Windows の API での Unicode → シフトJIS (Windows-31J) の変換に関しては、次のページに解説されている「WideCharToMultiByte の特殊処理」というのもあったりしますが、その説明は省略してあります。
JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い
http://www.asahi-net.or.jp/~ez3k-msym/charsets/jis2ucs.htm
| No.058 | 投稿日時: | 2003/04/18(金) 10:34 <↑親記事:No.056> |
| 投稿者: | えびはら |
森山さん、コメントどうもありがとうございます。
> コードページとして CpXXX (IBM のコードページ) と MSXXX (Windows のコードページ) の 2種類を使い分けているという所を見ると、Java の事でしょうか?
いえ、Javaは無関係というわけではないですが、基本的には文字コードそのものを問題にしています。
> 以前、Windowsのコードページ 932 (Windows-31J) 絡みで Java のエンコーディングも少しだけ調べてみた事があるという程度の知識しかなく、Cp932(IBM-932)、Cp943、Cp943C に関しては、よく分かっていないのですが、えびはらさんの調査結果に関して誤解されているというところはないのではないかと思います。(私自身、IBM のコードページについては勉強不足で確かなことは言えませんが。)
>
> Cp932 に関しては、Java の用法に従うと IBM のコードページ 932 のようですが、Java 以外では、cp932 を Windows のコードページ 932 (Java の MS932) として扱っているソフトもあるので、注意を要するといったくらいでしょうか。
この調査をしていて困ってしまうのが正にその辺でして、規格(定義)をベースにするか実装をベースにするかというところです。
実システムに関わる話なので実装を無視するわけにはいきませんし、かといって全ての実装を考慮するわけにも行かないので、対象システムに関係する範囲に限定せざるを得ません。
それにオリジナルの定義自体がいまいち明確になっていないのもあるようですし。
＃ Cp943なんて探すのに苦労しましたわ・・・
＃ たぶん無視してもいいんでしょうけど
おまけですが、私の身近な例だとデータベースでOracleをよく使うのですが、これのSJISの実装"JA16SJIS"、バージョンによって文字集合が変わります。
8.0まではベンダー定義文字を含まないのに対し(たぶん純粋なSJIS)、8.1以降は含みます(MS932相当)。
でも全角チルダ(＋α?)はUnicodeとのマッピングがMS932と異なり、その問題の解決のために"JA16SJISTILDE"なんてのが導入されたり。
> 一部文字化けしていますね。
すみません、確認不足でした。
しかもその他いろいろと補足までしていただきありがとうございます。
それにしても文字コードの問題に関わるときだけは日本に生まれたことを
悔やみます。
| No.059 | 投稿日時: | 2003/04/19(土) 00:36 <↑親記事:No.058> |
| 投稿者: | 森山 将之 |
Java に限らない話となると、面倒ですね。
一般的な話なら、Shift_JIS(SJIS) と Windows-31J(MS932) の違いを理解しておけば、良いかもしれません。
Shift_JIS(SJIS) と Unicode のマッピングに unicode.org の JIS0208.TXT を用いている場合は、Windows-31J(MS932) との違いで問題になるのは、次の 6 文字になります。
＿＿ [＿＿] SJIS＿ MS932
"〜" [8160] U301C UFF5E
"‖" [8161] U2016 U2225
"−" [817C] U2212 UFF0D
"¢" [8191] U00A2 UFFE0
"£" [8192] U00A3 UFFE1
"¬" [81CA] U00AC UFFE2
※GNU libiconv 1.8 の CP932 (Windows-31J) は、上記 6 文字に関して、Shift_JIS と同じマッピングになっていたりします…
Shift_JIS、Windows-31J とも、"―" [815C] は、U2015 と対応付けしていますが、JIS規格や Apple のシフトJIS では、U2014 に対応付けしています。
あと、Shift_JIS では、0x5C、0x7E に関して、次の 2 種類の対応付けが存在する可能性があります。( 実際の使用を考えると、(2) の対応付けの方が使いやすいですね。)
＿＿[＿]＿(1)＿＿(2)
"\" [5C] U00A5 U005C
"~" [7E] U203E U007E
Windows-31J に関しては、(2) の場合が、ほとんどと考えて良さそうな感じです。
Windows-31J のいわゆる機種依存文字に関しては、同じ文字が複数のコードポイントに割り当てられていたり、2 区の記号の一部が機種依存文字のコードポイントにも定義されていたりといった事も知っておくと、何か問題が生じたときに問題個所の特定の役に立つかもしれません。
重要なソフトの開発の際には、どのような実装になっているのか問題が出るまで分からないというのでは非常にマズイでしょうから、どのような実装になっているのか事前に確認するという事をした方が良いかもしれません。
> おまけですが、私の身近な例だとデータベースでOracleをよく使うのですが、これのSJISの実装"JA16SJIS"、バージョンによって文字集合が変わります。
なかなか面倒そうですね。
MS932 を IANA に登録されている Windows-31J で統一してくれるといいんですけどねぇ。
| No.060 | 投稿日時: | 2003/04/21(月) 14:07 <↑親記事:No.059> |
| 投稿者: | えびはら |
再度のコメント、どうもありがとうございます。
はっきり言ってUnicodeとのマッピングのことを考え始めると収拾が付かなく
なるので、今回は、
- 連結する各システムの文字コードはシフトJIS系に統一
- 各システム間データ連携ではコード変換が発生しないようにする
ということにしようと思っています。
これならシフトJIS系の各エンコーディングの文字集合の違いも問題なしで、外字も通りますし。
＃ 印刷・画面表示できるかどうかは別として
まあデータフローの途中にJavaアプリなどがあったりすると、また困ってしまうわけですが・・・ないことを祈ります。
| No.061 | 投稿日時: | 2003/04/23(水) 23:06 <↑親記事:No.060> |
| 投稿者: | 森山 将之 |
> まあデータフローの途中にJavaアプリなどがあったりすると、また困ってしまうわけですが・・・ないことを祈ります。
実は、最近の国際化されたソフトウェアでは、内部処理の文字コードとして Unicode を採用しているというケースが多くなってきていますので、入出力がシフトJISであっても、120区×94点 の全コードポイントを扱えるわけではないので注意が必要な場合があります。
大抵のソフトで、MS932 (Windows-31J) には対応しているでしょうから、MS932 でデータの受け渡しをするという事になるのではないかと思います。iモードの絵文字も、MS932 のユーザー定義外字領域なので対応可能ですし。
この辺のことは、実際のシステムでどのような運用するのかという事も関係してくるでしょうから、一概には言えないとは思いますが。
| No.062 | 投稿日時: | 2003/05/04(日) 22:22 <↑親記事:No.056> |
| 投稿者: | 森山 将之 |
>>056
> ※Java の SJIS, EUC_JP, ISO2022JP は、
> ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT のマッピングを用いているようです。("―" 01区29点 が JIS X 0208:1997 の解釈と異なる点に注意。)
と書きましたが、JRE1.4.0以降の変換 の Java では、"―" 01区29点も JIS 規格と同じく、U+2014 EM DASH にマッピングするようになっていたようです。
JIS-Unicode変換において問題の起こりにくい変換表
http://hp.vector.co.jp/authors/VA010341/unicode/
| No.057 | 投稿日時: | 2003/04/18(金) 08:55 <↑親記事:No.055> |
| 投稿者: | 森山 将之 |
Unicode を経由しての MS932 と Cp943C の変換では、5 文字に関して文字化けが起きる危険性がある事が(Unicode 上でのコードポイントが異なる)、えびはらさんの調べで分かりましたが、いわゆる機種依存文字に関しての扱いがどうなっているのか良く分からなかったので Java (Java 2 v 1.4.1_02) で調べてみました。
いわゆる機種依存文字の扱いで問題になってくるのが、複数のコードポイントに同じ文字が割り当てられている所で、シフトJIS → Unicode の変換で、多対1 の変換が行われる為、Unicode → シフトJIS の変換では、コードポイントを選択する必要性が出てきます。
その選択の際の規則は次のようになっているようです。
Unicode → Windows-31J (MS932) の変換規則
1. 2区にある文字は2区のコードポイントを用いる
2. 13区にある文字は13区のコードポイントを用いる
3. 115〜119区にある文字は115〜119区のコードポイントを用いる
Unicode → Cp943C の変換規則
1. 2区にある文字は2区のコードポイントを用いる
2. 115〜119区にある文字は115〜119区のコードポイントを用いる
3. 13区にある文字は13区のコードポイントを用いる
MS932, Cp943C ともに 2区(JIS文字) 優先で、89〜92区(NEC選定IBM拡張文字) は用いません。
MS932 では 13区(NEC特殊文字)を優先するのに対して、Cp943C では 115〜119区 (IBM選定拡張文字) を優先していました。
具体的に Cp943C と MS932 で異なるコードポイントは次の通りです。
Cp943C MS932 Unicode
FA40 8754 U2160 ROMAN NUMERAL ONE
FA41 8755 U2161 ROMAN NUMERAL TWO
FA42 8756 U2162 ROMAN NUMERAL THREE
FA43 8757 U2163 ROMAN NUMERAL FOUR
FA44 8758 U2164 ROMAN NUMERAL FIVE
FA45 8759 U2165 ROMAN NUMERAL SIX
FA46 875A U2166 ROMAN NUMERAL SEVEN
FA47 875B U2167 ROMAN NUMERAL EIGHT
FA48 875C U2168 ROMAN NUMERAL NINE
FA49 875D U2169 ROMAN NUMERAL TEN
FA58 878A U3231 PARENTHESIZED IDEOGRAPH STOCK
FA59 8782 U2116 NUMERO SIGN
FA5A 8784 U2121 TELEPHONE SIGN
| No.055 | 投稿日時: | 2003/04/17(木) 20:22 <親記事> |
| 投稿者: | えびはら |
初めまして、えびはらと申します。
異種システム間のデータ連携に関連して、文字コードのことを色々調べております。
さて、早速の質問で恐縮ですが、シフトJIS系のエンコーディングには色々とありますが、
それぞれがどのように異なるのかについてご教示いただきたいと思っています。
以下は私が調査した結果なのですが、もしこの中に誤解があればご指摘いただけないでしょうか。
よろしくお願いします。
--
各エンコーディングがサポートする文字集合は以下の通り。
Shift_JIS
- JIS X 0201.1976
- JIS X 0208.1983 or 1990
Cp932
- JIS X 0201.1976
- JIS X 0208.1983
- IBM拡張文字
(※ http://www.unet.univie.ac.at/aix/aixprggd/genprogc/codeset_over.htm より)
Cp943
Cp943C
MS932
- JIS X 0201.1976
- JIS X 0208.1990
- NEC特殊文字
- NEC選定IBM拡張文字
- IBM拡張文字
これらのエンコーディングにおいては各キャラクタのコードポイントは同じなので、
コード変換は不要である。
例えばMS932のテキストはそのままCp943C(Cp943)として取り扱うことができる。
ただしCp943は他の2つに比べ、以下のコードポイントも持つ。
・0x80: Cent sign(Cp943)
・0xA0: Pound sterling sign(Cp943)
・0xFD: Not sign(Cp943)
・0xFE: Backslash(Cp943)
・0xFF: Tilde(Cp943)
また、一部の文字のUnicodeへのマッピングポイントが異なる。
MS932とCp943C
"−", "〜", "‖", "―", "〓"
(※ http://www-6.ibm.com/jp/software/websphere/developer/wsv35wslib/pdf/was35_psj5_1.pdf より)
Cp943とCp943C
・0x5C("\") → U007F(Cp943C, Back Slash), U00A5(Cp943, Yen Sign)
・0x7E("~") → U007E(Cp943C, Tilde), U203E(Cp943, Overline)
(※ http://www.os2ss.com/news/misc/java114.readme より)
そのためMS932のテキストをUnicodeに変換し、その後Cp943Cに変換すると、元のテキストとは
異なるコードになってしまう文字がある。
| No.056 | 投稿日時: | 2003/04/18(金) 07:31 <↑親記事:No.055> |
| 投稿者: | 森山 将之 |
はじめまして、えびはらさん。
コードページとして CpXXX (IBM のコードページ) と MSXXX (Windows のコードページ) の 2種類を使い分けているという所を見ると、Java の事でしょうか?
以前、Windowsのコードページ 932 (Windows-31J) 絡みで Java のエンコーディングも少しだけ調べてみた事があるという程度の知識しかなく、Cp932(IBM-932)、Cp943、Cp943C に関しては、よく分かっていないのですが、えびはらさんの調査結果に関して誤解されているというところはないのではないかと思います。(私自身、IBM のコードページについては勉強不足で確かなことは言えませんが。)
Cp932 に関しては、Java の用法に従うと IBM のコードページ 932 のようですが、Java 以外では、cp932 を Windows のコードページ 932 (Java の MS932) として扱っているソフトもあるので、注意を要するといったくらいでしょうか。
> また、一部の文字のUnicodeへのマッピングポイントが異なる。
> MS932とCp943C
> "−", "〜", "‖", "―", "〓"
> (※ http://www-6.ibm.com/jp/software/websphere/developer/wsv35wslib/pdf/was35_psj5_1.pdf より)
一部文字化けしていますね。
左から順番に次のようになっていると思われます。
"−" [817C] 01区61点
"〜" [8160] 01区33点
"‖" (U2016)→"‖" [8161] 01区34点
"―" [815C] 01区29点
"〓" [FA55] 115区23点 IBM拡張文字 (いわゆる機種依存文字なので、この掲示板ではゲタ記号"〓" に変換しています。)
他の注意点としては次のような事があります。
SJIS と MS932 では、次の文字について Unicode との対応関係が異なります。
"〜" [8160]
"‖" [8161]
"−" [817C]
"¢" [8191]
"£" [8192]
"¬" [81CA]
SJIS と Cp943C では、次の文字について Unicode との対応関係が異なります。
"―" [815C]
"¢" [8191]
"£" [8192]
"¬" [81CA]
EUC_JP や ISO2022JP は、Unicode との対応に関しては、SJIS と同じなので、EUC_JP と MS932/Cp943C、ISO2022JP と MS932/Cp943C も同様の問題があります。
※Java の SJIS, EUC_JP, ISO2022JP は、ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT のマッピングを用いているようです。("―" 01区29点 が JIS X 0208:1997 の解釈と異なる点に注意。)
あまり参考にならなかったかもしれません。
以前調べた時に次のページを参考にしましたので紹介いたします。
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
Javaの日本語関連コンバータにおけるマッピングの違い
http://www.ingrid.org/java/i18n/encoding/ja-conv.html
サポートされているエンコーディング (Java 2 Platform, Standard Editionv 1.3)
http://java.sun.com/j2se/1.3/ja/docs/ja/guide/intl/encoding.doc.html
インストール関連情報 Hints＆Tips (コードページ 943 の簡単な説明あり)
http://www-6.ibm.com/jp/pspjinfo/os2/hints/128.html
従来の文字コードとUnicodeの対応に関する諸問題
http://euc.jp/i18n/ucsnote.ja.html
変換表がベンダーによって異なる
http://www.debian.or.jp/~kubota/unicode-symbols-map2.html
※この中で登場する CP932 は、Windows Code Page 932 (Java で は MS932) の事になります。
文字コードについてのメモ
http://www.asahi-net.or.jp/~wq6k-yn/code/
※「JIS漢字とUCSの文字の対応について」で "―" 01区29点 についての指摘あり。
IANA > Character Sets
http://www.iana.org/assignments/character-sets
※Shift_JIS, Windows-31J (MS932)
Windows-31J (Windows Code Page 932) に関しては、私が調べて分かったことをまとめたページがあります。
Windows-31J 情報
http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/index.html
実を言うと、eucJP-ms の説明は、ちょっと自信がありません。
また、Windows の API での Unicode → シフトJIS (Windows-31J) の変換に関しては、次のページに解説されている「WideCharToMultiByte の特殊処理」というのもあったりしますが、その説明は省略してあります。
JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い
http://www.asahi-net.or.jp/~ez3k-msym/charsets/jis2ucs.htm
| No.058 | 投稿日時: | 2003/04/18(金) 10:34 <↑親記事:No.056> |
| 投稿者: | えびはら |
森山さん、コメントどうもありがとうございます。
> コードページとして CpXXX (IBM のコードページ) と MSXXX (Windows のコードページ) の 2種類を使い分けているという所を見ると、Java の事でしょうか?
いえ、Javaは無関係というわけではないですが、基本的には文字コードそのものを問題にしています。
> 以前、Windowsのコードページ 932 (Windows-31J) 絡みで Java のエンコーディングも少しだけ調べてみた事があるという程度の知識しかなく、Cp932(IBM-932)、Cp943、Cp943C に関しては、よく分かっていないのですが、えびはらさんの調査結果に関して誤解されているというところはないのではないかと思います。(私自身、IBM のコードページについては勉強不足で確かなことは言えませんが。)
>
> Cp932 に関しては、Java の用法に従うと IBM のコードページ 932 のようですが、Java 以外では、cp932 を Windows のコードページ 932 (Java の MS932) として扱っているソフトもあるので、注意を要するといったくらいでしょうか。
この調査をしていて困ってしまうのが正にその辺でして、規格(定義)をベースにするか実装をベースにするかというところです。
実システムに関わる話なので実装を無視するわけにはいきませんし、かといって全ての実装を考慮するわけにも行かないので、対象システムに関係する範囲に限定せざるを得ません。
それにオリジナルの定義自体がいまいち明確になっていないのもあるようですし。
＃ Cp943なんて探すのに苦労しましたわ・・・
＃ たぶん無視してもいいんでしょうけど
おまけですが、私の身近な例だとデータベースでOracleをよく使うのですが、これのSJISの実装"JA16SJIS"、バージョンによって文字集合が変わります。
8.0まではベンダー定義文字を含まないのに対し(たぶん純粋なSJIS)、8.1以降は含みます(MS932相当)。
でも全角チルダ(＋α?)はUnicodeとのマッピングがMS932と異なり、その問題の解決のために"JA16SJISTILDE"なんてのが導入されたり。
> 一部文字化けしていますね。
すみません、確認不足でした。
しかもその他いろいろと補足までしていただきありがとうございます。
それにしても文字コードの問題に関わるときだけは日本に生まれたことを
悔やみます。
| No.059 | 投稿日時: | 2003/04/19(土) 00:36 <↑親記事:No.058> |
| 投稿者: | 森山 将之 |
Java に限らない話となると、面倒ですね。
一般的な話なら、Shift_JIS(SJIS) と Windows-31J(MS932) の違いを理解しておけば、良いかもしれません。
Shift_JIS(SJIS) と Unicode のマッピングに unicode.org の JIS0208.TXT を用いている場合は、Windows-31J(MS932) との違いで問題になるのは、次の 6 文字になります。
＿＿ [＿＿] SJIS＿ MS932
"〜" [8160] U301C UFF5E
"‖" [8161] U2016 U2225
"−" [817C] U2212 UFF0D
"¢" [8191] U00A2 UFFE0
"£" [8192] U00A3 UFFE1
"¬" [81CA] U00AC UFFE2
※GNU libiconv 1.8 の CP932 (Windows-31J) は、上記 6 文字に関して、Shift_JIS と同じマッピングになっていたりします…
Shift_JIS、Windows-31J とも、"―" [815C] は、U2015 と対応付けしていますが、JIS規格や Apple のシフトJIS では、U2014 に対応付けしています。
あと、Shift_JIS では、0x5C、0x7E に関して、次の 2 種類の対応付けが存在する可能性があります。( 実際の使用を考えると、(2) の対応付けの方が使いやすいですね。)
＿＿[＿]＿(1)＿＿(2)
"\" [5C] U00A5 U005C
"~" [7E] U203E U007E
Windows-31J に関しては、(2) の場合が、ほとんどと考えて良さそうな感じです。
Windows-31J のいわゆる機種依存文字に関しては、同じ文字が複数のコードポイントに割り当てられていたり、2 区の記号の一部が機種依存文字のコードポイントにも定義されていたりといった事も知っておくと、何か問題が生じたときに問題個所の特定の役に立つかもしれません。
重要なソフトの開発の際には、どのような実装になっているのか問題が出るまで分からないというのでは非常にマズイでしょうから、どのような実装になっているのか事前に確認するという事をした方が良いかもしれません。
> おまけですが、私の身近な例だとデータベースでOracleをよく使うのですが、これのSJISの実装"JA16SJIS"、バージョンによって文字集合が変わります。
なかなか面倒そうですね。
MS932 を IANA に登録されている Windows-31J で統一してくれるといいんですけどねぇ。
| No.060 | 投稿日時: | 2003/04/21(月) 14:07 <↑親記事:No.059> |
| 投稿者: | えびはら |
再度のコメント、どうもありがとうございます。
はっきり言ってUnicodeとのマッピングのことを考え始めると収拾が付かなく
なるので、今回は、
- 連結する各システムの文字コードはシフトJIS系に統一
- 各システム間データ連携ではコード変換が発生しないようにする
ということにしようと思っています。
これならシフトJIS系の各エンコーディングの文字集合の違いも問題なしで、外字も通りますし。
＃ 印刷・画面表示できるかどうかは別として
まあデータフローの途中にJavaアプリなどがあったりすると、また困ってしまうわけですが・・・ないことを祈ります。
| No.061 | 投稿日時: | 2003/04/23(水) 23:06 <↑親記事:No.060> |
| 投稿者: | 森山 将之 |
> まあデータフローの途中にJavaアプリなどがあったりすると、また困ってしまうわけですが・・・ないことを祈ります。
実は、最近の国際化されたソフトウェアでは、内部処理の文字コードとして Unicode を採用しているというケースが多くなってきていますので、入出力がシフトJISであっても、120区×94点 の全コードポイントを扱えるわけではないので注意が必要な場合があります。
大抵のソフトで、MS932 (Windows-31J) には対応しているでしょうから、MS932 でデータの受け渡しをするという事になるのではないかと思います。iモードの絵文字も、MS932 のユーザー定義外字領域なので対応可能ですし。
この辺のことは、実際のシステムでどのような運用するのかという事も関係してくるでしょうから、一概には言えないとは思いますが。
| No.062 | 投稿日時: | 2003/05/04(日) 22:22 <↑親記事:No.056> |
| 投稿者: | 森山 将之 |
>>056
> ※Java の SJIS, EUC_JP, ISO2022JP は、
> ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT のマッピングを用いているようです。("―" 01区29点 が JIS X 0208:1997 の解釈と異なる点に注意。)
と書きましたが、JRE1.4.0以降の変換 の Java では、"―" 01区29点も JIS 規格と同じく、U+2014 EM DASH にマッピングするようになっていたようです。
JIS-Unicode変換において問題の起こりにくい変換表
http://hp.vector.co.jp/authors/VA010341/unicode/
| No.057 | 投稿日時: | 2003/04/18(金) 08:55 <↑親記事:No.055> |
| 投稿者: | 森山 将之 |
Unicode を経由しての MS932 と Cp943C の変換では、5 文字に関して文字化けが起きる危険性がある事が(Unicode 上でのコードポイントが異なる)、えびはらさんの調べで分かりましたが、いわゆる機種依存文字に関しての扱いがどうなっているのか良く分からなかったので Java (Java 2 v 1.4.1_02) で調べてみました。
いわゆる機種依存文字の扱いで問題になってくるのが、複数のコードポイントに同じ文字が割り当てられている所で、シフトJIS → Unicode の変換で、多対1 の変換が行われる為、Unicode → シフトJIS の変換では、コードポイントを選択する必要性が出てきます。
その選択の際の規則は次のようになっているようです。
Unicode → Windows-31J (MS932) の変換規則
1. 2区にある文字は2区のコードポイントを用いる
2. 13区にある文字は13区のコードポイントを用いる
3. 115〜119区にある文字は115〜119区のコードポイントを用いる
Unicode → Cp943C の変換規則
1. 2区にある文字は2区のコードポイントを用いる
2. 115〜119区にある文字は115〜119区のコードポイントを用いる
3. 13区にある文字は13区のコードポイントを用いる
MS932, Cp943C ともに 2区(JIS文字) 優先で、89〜92区(NEC選定IBM拡張文字) は用いません。
MS932 では 13区(NEC特殊文字)を優先するのに対して、Cp943C では 115〜119区 (IBM選定拡張文字) を優先していました。
具体的に Cp943C と MS932 で異なるコードポイントは次の通りです。
Cp943C MS932 Unicode
FA40 8754 U2160 ROMAN NUMERAL ONE
FA41 8755 U2161 ROMAN NUMERAL TWO
FA42 8756 U2162 ROMAN NUMERAL THREE
FA43 8757 U2163 ROMAN NUMERAL FOUR
FA44 8758 U2164 ROMAN NUMERAL FIVE
FA45 8759 U2165 ROMAN NUMERAL SIX
FA46 875A U2166 ROMAN NUMERAL SEVEN
FA47 875B U2167 ROMAN NUMERAL EIGHT
FA48 875C U2168 ROMAN NUMERAL NINE
FA49 875D U2169 ROMAN NUMERAL TEN
FA58 878A U3231 PARENTHESIZED IDEOGRAPH STOCK
FA59 8782 U2116 NUMERO SIGN
FA5A 8784 U2121 TELEPHONE SIGN