【最大10000ポイント】当たる!!質問投稿キャンペーン!

おはようございます。
文字コードには、大きく分けて4種類
・JISコード
・S-JIS
・EUC
・Unicode
がありますが、それぞれの利点・欠点を教えていただけますでしょうか。

あと、EUCはなぜ制御文字を使って、1バイト仮名や補助漢字の文字コードを割り当てているのかも教えてください。
よろしくお願いします。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

文字コードの解説はされているので、残った


>EUCはなぜ制御文字を使って、1バイト仮名や補助漢字の文字コードを割り当てているのかも教えてください。

何故かというとその方式がISO2022という規格で定められているからそれに従っています。
さらに何故ISO2022でそう定められているかというと、別の文字セットへの切り替え指示は、今の文字セットに割り当てられていない範囲を使うしかないわけで、そう言う意味で制御コードの範囲にその機能が割り当てられています。
    • good
    • 1

もう一つの質問とまとめてもよかった気がしますが…。



・旧JIS(JIS X 0201)(8bit)利点
ASCIIと同じバイト数で、ASCIIに加えてカナを扱える。
構造が単純。
欠点
漢字は扱えない

・新JIS(JIS X 0208)(7bit)利点
7bitしか使わないので昔の低性能な通信にも耐えた。(残り1bitで誤り検出)
扱う文字を増やそうと思えばいくらでも増やせる。
・欠点
ステートフルなので文字列の途中を見ても書いてある文字が分からない。
エスケープシークエンスの分容量がかさむ。

・Shift_JIS利点
旧JISの上位互換なので旧来の資源をそのまま使える。
半角カナを有効利用すると保存に必要なデータ量が新JISやEUCより少ない。
WindowsとMacで標準なのでデファクトスタンダード。
欠点
元は独自拡張なので世界の統一コードであるISO2022と互換性がない。(ただし韓国と中国にShift_JISと同じ構造のコードがある)
エンコードが複雑。
2バイトの区切りを間違えると文字列の途中から見て読めない。
2バイト目に「\」のコードが出て問題が起こる。

・EUC利点
上記Shift_JISの欠点を全て解決。
Shift_JISの漢字に加え補助漢字数千字が使える。
・欠点
半角カナが使えない(無理に使うと複雑なコードに)。
補助漢字は複雑なコード。
旧JISに互換性がない。
WindowsやMacで使いづらい。

・Unicode利点
文字数が多い。
・UTF-8利点
ASCIIの上位互換。
文字列の途中からでも読める。
・UTF-16利点
基本多言語面のみなら1文字2バイト固定で扱いやすい。
2バイトで扱える文字が最も多い。
・Unicode欠点
さまざまな文字がごちゃまぜに登録されているため、扱いが面倒。
(例: 右から左に書く文字、合成文字、文字方向を変える制御文字、同じ文字に複数のコード)
・UTF-8欠点
1文字あたりのバイト数が不定。
他のコードに比べ1文字あたりのバイト数が多い。
・UTF-16欠点
基本多言語面以外の文字を使おうとするとバイト数不定。
ASCIIに互換性がない。
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q文字コード 統一 それぞれ利点 教えてください

sjisとかutf-8とかeuc-jpとかisoなんちゃらとかutf-16とかもういっぱいありすぎて誰得なんですかこれ
それぞれ利点と、なんでこんなにいっぱいあるのか教えてください
hatenaなんかはeucからutfに変えたみたいですが・・

もう全部統一したらいいのに・・(´Д`)
回答宜しくお願いします。

Aベストアンサー

現在文字コードが分化しているのは、歴史的事情です。

後方(過去への)互換性を重要視するわけでもなければ
今後は、Unicodeを使用していけばいいと思います。


以下はあまりにもな回答があったので。

まず、EBCDICやACIIなどの英数記号文字のコードがありました。
日本語としては、始めに1バイトのいわゆる半角カナの文字コード
JIS C 2660 現在では、JIS X 0201と言われるコードが、
次に2バイトで漢字やその他の記号も含められるようにコードが定められました。

JISコードの表現は、7bitのコードだけで表現できますが、英数字
からのコードを切り替えるために、SHIFT-IN/SHIFT-OUTという
当時のコンピュータにしてはかなり荷が重い処理体系でした。

当時80年代の一般的なパソコン、8bit CPUのころから日本語を
処理するためにまず、8bitのコードで JIS X 0201に相当する
半角カナを処理するようにしました。

さらに、そのような8bitのいわゆる半角カナのコードを活かしつつ
SHIFT-IN/OUTの処理をせずに2バイトの漢字コードも扱える
コード体系が考えられ、Shift JISと呼ばれるようになりました。

一方で、いわゆるUNIX系の処理装置で漢字が扱えるくらいCPU
パワーが上がっていました。UNIXは英数文字に対して強力な処理を
行うプログラムが数多くありましたが、それらをなるべく簡単に
日本語処理に適用させるために考えだされたのが、EUCです。

EUCは、JISコードの2バイト文字(いわゆる全角文字)の1バイト目
・2バイト目の両方共、7bit目を1にする(0x80~0xFF)コード
です。
ShiftJISに比較して、当時のASCIIだけに対応していたプログラムを
容易に日本語に対応できました。
しかし、8bitパソコンで広く使われていたいわゆる半角カナには
単純には対応できません。

この当時、80~90年代、パソコンはShiftJISコード、UNIX系はEUC
コードでした。

さらに、インターネット(日本ではその前身である JUNET)が
普及を始め、メールの日本語をどうするか議論がありました。
当時のメールを転送するプログラムは7bitの文字コードしか転送が
保証されていませんでした。

したがって、日本国内のローカルルールとして、電子メールは
JISコードで本文を書くと決められ、JISコードの処理系が実際に
広く運用されるようになりました。80~90年代初頭。
さらに国際化の対応として、JISのコードをISO表記にした
ISO-2022-JPと呼ばれるコード体系としました。

ここまでが日本国内の事情。
80年代の頃から、ASCII文字コードにない文字も使用している、西欧
(東欧)のコンピュータはASCIIコードの一部記号を独自の文字に
変更したり、日本のいわゆる半角カナのような拡張をしていました。
これらを統一し、更には世界中のコードを統一して運用できないか
というのが Unicodeの流れです。

Unicodeは紆余曲折があり、コンピュータで処理をするにも結構
大変な処理でした。しかし、コンピュータの処理能力向上や
文字コードを扱う部分を OSやライブラリで隠蔽化や簡略化を
行わせることが増え、Unicodeでも現在では、プログラムサイドからも
ユーザサイドからも問題なく処理しているコンピュータが多くなりました。
(少なくとも、Windows XP以上やLinux等が動くPC以上のコンピュータ)

以上が歴史的事情。

まとめると以下のようになります。
Shift JIS
8bitの頃から利用されていたいわゆる半角カナを活かすコード体系。
80~90年代のパソコンで利用。
ただし、プログラム的にはテクニックを要します。
WindowsもXPのころから内部は全てUnicodeになっているので、
いずれ盲腸のような扱いになると思われます。
EUC (EUC-jp)
UNIX系を中心として様々な処理系を日本語(JISコード)に使用された
コード。外国産のUnicode非対応のプログラムを簡単に日本穂対応
させる時に使用されています。これも盲腸的な扱いになるでしょう。
JIS (ISO-2022-JP)
インターネットメールを使用するために普及したコード体系。
初期の国際化を考慮したインターネットのプログラムはこの
コードを使用していました。
Unicode
コンピュータの歴史的には後発で紆余曲折を経たコードですが、
国際化の対応や、外国で実装されているプログラムの国際化対応
としては、このコードが現在はほとんど利用されている(はず)です。

この先は、Unicodeを使用するのが標準になると思われます。


ちなみに、60年代のコンピュータは大型かミニコンと言われ、互換性は
ないか、せいぜい IBMへの互換性だけです。
Webは確かにSGML等をベースにしたHTMLを定めましたが、文字コードや
エンコードにはメール等の国際化で使用したMIMEを使用していたので、
文字コードに関しては直接的には無関係です。
米国内の国防省や各省庁間のコード体系で非互換性は無かったわけでは
無いですが、現在のコード体系の分化の原因になっているわけではない
です。

今後、ましてや100年先なんぞは本格的にコンピュータの文字処理が始まって
せいぜい50年程度しか経っていないので、偉そうに予測なぞできません。が、
しかし、Unicodeには拡張の余地が大きく有り、新たに別の異なる文字体系を
作って別れるよりも、Unicodeの拡張に新たな文字体系を入れ込んで行くだけ
かと思いますよ。

先の回答は、質問への回答としても歴史的な説明としても、支離滅裂と思われる
部分が多々あったので、補足しています。

現在文字コードが分化しているのは、歴史的事情です。

後方(過去への)互換性を重要視するわけでもなければ
今後は、Unicodeを使用していけばいいと思います。


以下はあまりにもな回答があったので。

まず、EBCDICやACIIなどの英数記号文字のコードがありました。
日本語としては、始めに1バイトのいわゆる半角カナの文字コード
JIS C 2660 現在では、JIS X 0201と言われるコードが、
次に2バイトで漢字やその他の記号も含められるようにコードが定められました。

JISコードの表現は、7bitのコードだけで表現...続きを読む

QUNICODE対応にするメリットは?

VisualStudio2005 VC++を用いたアプリケーション開発に、今まではマルチバイト文字を使ってきたのですが、時代の流れとしてはUNICODEに移行すべきなのかな、と漠然と思っています。
ここで疑問なのですが、ずばりUNICODEに移行するメリットは何でしょう?
今のままマルチバイトを使っていても困ることは無いような気がしますし、日本語版・英語版の両方をリリースする場合もリソースの言語切り替えで対応できていますので、UNICODEにどのような利点があるのか、いまひとつピンときません。

Aベストアンサー

マルチバイト文字がなくなってしまうからです。
ただ、2008で、完全に使えなくなってしまう、という話は聞きませんし、特に難しい問題ではないので、いそいでユニコードに移行する必要もないのではないでしょうか。
また、2005+VISTA+ユニコードの組み合わせだと、いろいろバグが出ます。
マイクロソフトは、どうもこのまま「とぼけて」2008に移行してしまうハラのようです。

なんだか2バイトでも世界中の文字をカバーできないそうで、4バイト文字なんてのも出てきているようです。
ユニコードが定着した頃に、次の規格が出てきそうな、いかがわしさもあります。

QWindowsの標準文字コードについて

標準文字コードはシフトJISとされていますが、

例えば、windowsでメモ帳を使って文字を書いて、保存をした時。
保存する時の文字コードは自由に選択できますよね。

この時点だと、どこにシフトJISコードが使われているのかはサッパリ分かりません。

それで考えたのですが、

文章を保存する時では無く、

メモ帳に書いている時に使われている文字が、
シフトJISなのでしょうか?(その文字を16進数としてみた時にシフトJISの文字コードになっている)

つまり、
もともと、windows上でwebページのフォームに文字を入力するとか、
メモ帳で文章を書くと、
シフトJISとして書いている事になるのでしょうか?(シフトJISコードに対応した16進数で書いている)

それを、例えばメモ帳ならシフトJISコードを違うコードに変換して保存する機能が付いている
ブラウザには、その機能は無いから、フォームからはシフトJISコードとしてのデータしか遅れない。

そう考えると、
windows上では入力する全ての文字がシフトJISコードという事になり、
標準文字コードがシフトJISという言葉にも納得がいくのですが、

上記の理解で正解なのでしょうか?

よろしくお願いします。

標準文字コードはシフトJISとされていますが、

例えば、windowsでメモ帳を使って文字を書いて、保存をした時。
保存する時の文字コードは自由に選択できますよね。

この時点だと、どこにシフトJISコードが使われているのかはサッパリ分かりません。

それで考えたのですが、

文章を保存する時では無く、

メモ帳に書いている時に使われている文字が、
シフトJISなのでしょうか?(その文字を16進数としてみた時にシフトJISの文字コードになっている)

つまり、
もともと、windows上でwebペー...続きを読む

Aベストアンサー

>まず自分がEUC-JPで保存したファイルを、
>EUC-JPを保存できたエディタで開くと見れるのはどうしてでしょうか??

>EUC-JPのコード→unicode→シフトJIS(このままだと文字化け)

>エディタでEUC-JPのファイルを文字化けせずに見られるのは、
>エディタがEUC-JPをシフトJISのコードに戻しているのでしょうか?

基本的にはその通りです。EUCに対応したエディタは、読み込み時に自動的に、あるいは明示されることにより、EUCコードを変換します。
変換の流れはOSの機能をどこまで使うかによって
EUC-JPのコード→シフトJIS(→unicode OSが自動処理)
EUC-JPのコード→unicode(→シフトJIS) (OSの内部コードにアプリが変換)
の両パターンありえると思います。

>2つ目は、ブラウザで文字化けする時に、
>正しいエンコードを選ぶと正しく表示されるのは、
>指定された文字コードからシフトJISコードに変換して表示しているか>ら、正しく表示されるのでしょうか?

その通りです。例えばInternetExplorerにはその専用の変換ルーチンが用意されています。実際WEBページやテキスト文書をIEであけて、保存の際にコードを選択すると任意のコードに変換することができます。

>まず自分がEUC-JPで保存したファイルを、
>EUC-JPを保存できたエディタで開くと見れるのはどうしてでしょうか??

>EUC-JPのコード→unicode→シフトJIS(このままだと文字化け)

>エディタでEUC-JPのファイルを文字化けせずに見られるのは、
>エディタがEUC-JPをシフトJISのコードに戻しているのでしょうか?

基本的にはその通りです。EUCに対応したエディタは、読み込み時に自動的に、あるいは明示されることにより、EUCコードを変換します。
変換の流れはOSの機能をどこまで使うかによって
EUC-JPの...続きを読む

Qinterface,extend,implementのちがい

お世話になります、

Javaを勉強しているのですが、
interface,extend,implementの使い分けがわかりません。

私の解釈としては、
(1)interfaceは、グローバル変数の定義、グローバルメソッドの定義(実装はしない)。

(2)extendは、extendクラスを親クラスとして親クラスの機能を使用できる。

(3)implementは…,implementもextendと同じような意味だと解釈しているんですが、違う点は、implementで定義してあるメソッドは、使用しなくても、実装しなければならないという点でしょうか?

とにかくこの3つのを使い分けるコツとかあれば教えてください。
よろしくお願いします。

Aベストアンサー

バラバラに理解してもしょうがないッス。

まず、
(1)interface と implements
(2)class と extends

が対応しているわけっす。

JavaはC++と違って、比較的言語仕様を「簡単」にしたので「多重継承」という
概念がないです。
多重継承っていうのは、複数のクラスを親クラスにして継承するってことですね。

たとえば、 「TextFieldクラス」と「Japaneseクラス」を多重継承すると、
「JTextFieldクラス」ができるっていうのが自然な考え方でしょう?

まぁ、例えば、日本語クラスであれば、getStringLength()メソッドなどが
あったほうが良いでしょうか。
このgetStringLength()メソッドは、2バイト文字も1バイト文字も「1文字」
と数えてくれると言う点で、まさに、日本語クラス用のメソッドだと言えるでしょう。

例えば、Java的に記述すると、、、
class Japanese {
public int getStringLength() {
  ・・・
return strlength;
 }
 ・・・
}

class TextField {
・・・
}

class JTextField extends TextField, extends Japanese {
・・・・
}

C++ではそのように実装するでしょう。
しかし、Javaにはこのような高度な機能はありません。

そこで、生まれた苦肉の策が、「interfaceとimplements」です。

interface Japanese {
public int getStringLength(); // interfaceは実装を含まない!
                 // すなわち「実装の継承」ができるわけではない。
}

class TextField {
・・・
}

class JTextField extends TextField implements Japanese {
・・・・
public int getStringLength() {
  ・・・
return strlength; //implementsの実装を「各クラスで」実装してやる必要がある。
 }
}


結局のところ、Javaでは、複数のクラスを親クラスには持ち得ないため、継承できなかったクラスは「各クラスで実装してやる必要性」があるのです。


ではどのように使うのが効果的か?

なまえのままです。「代表的なインターフェイス」にたいしてinterfaceを使うのが良いと思います。

例えば、プレイヤー系であれば、ビデオ・コンポ・ウォークマン・などにかかわらず、
interface controlpanel {
public play();
public stop();
public next();
public back();
}
というような基本的インターフェイスを「持っているべき」です。

こうすることで、それぞれのクラス宣言の際に、これらの「インターフェイスを持っているべきであり、実装されるべきである」ということを「強く暗示」することができます。
class videoplayer extends player implements controlpanel {
public play() {・・・}
public stop() {・・・}
public next() {・・・}
public back() {・・・}
}

こうすることで、同様のクラスを作成するユーザーは、
「プレイヤー系は、4つ操作が出来るコントロールパネルをインターフェイスとして持つべきなのだな!?」という暗示を受け取り、自分のクラスでもそれを模倣するでしょう。

class mp3player extends player implements controlpanel {
public play() {・・・}
public stop() {・・・}
public next() {・・・}
public back() {・・・}
}

また、これらのクラスを使用するユーザーも、「implements controlpanel」という
表記を見て、「4つの基本操作は押さえられているのだな!」という基本中の基本動作を抑えることが出来ます。

まとめると、クラスに「こういう特徴もたしてください!」「こういう特徴持ってますよ!」という一種の暗示的警告や方向性を与えることができるわけですね。

バラバラに理解してもしょうがないッス。

まず、
(1)interface と implements
(2)class と extends

が対応しているわけっす。

JavaはC++と違って、比較的言語仕様を「簡単」にしたので「多重継承」という
概念がないです。
多重継承っていうのは、複数のクラスを親クラスにして継承するってことですね。

たとえば、 「TextFieldクラス」と「Japaneseクラス」を多重継承すると、
「JTextFieldクラス」ができるっていうのが自然な考え方でしょう?

まぁ、例えば、日本語クラスであれば...続きを読む

Q深さ優先探索について・・・

↓の文を参考にして、深さ優先探索のプログラムを書いてみました。
が、自分(初心者)ではできてるように思えたんですが、全然ダメみたいです。
再帰の使い方がよく分かってないというのもあるのですが(すみません)。
もしよろしければアドバイスを頂けませんか?お願いします!

『・始点(ここでは「1」)を出発して、番号が小さい順に進む位置を調べていき
 行けるところ(辺でつながっていて、まだ未訪問の節点)まで進む。
・行き場所が無くなったら、行けるところがある節点まで戻っ(再帰をリターンし) て再び進めるだけ進む。
・行き場所がなくなったなら終了(再帰からリターン)
プログラムの際に節点iから節点jへ進めるか否かは節点と枝の関係を表すテーブル(これを隣接行列と言う)の要素a[i][j]の値が1であり、かつ訪問フラグv[j]が0であった時です。
訪問フラグは初期値に0を入れ(未訪問を表す)、
節点jが訪問されたならv[j]に1を入れます』

#include<stdio.h>

int recurse(int i,int j);

int main(void){

int recurse(int i,int j);

return 0;
}

int recurse(int i,int j){
int v[j];
int a[i][j];

v[j]=0;
v[0]=0;

a[i][j]={{0,1,1,0,0,0,0,0},
{1,0,0,1,0,0,0,0},
{1,0,0,1,0,0,0,0},
{0,1,1,0,1,0,0,0},
{0,0,0,1,0,1,0,1},
{0,0,0,0,1,0,1,0},
{0,0,0,0,0,1,0,1},
{0,0,0,0,1,0,1,0}};

for(i=0;i<8;i++){
for(j=0;j<8;j++){
if(a[i][j] == 1 && v[j] == 0){
v[j]=1;
printf("%d->%d ",i,j);
break; }
else return 0;
}
}
return 0;
}

↓の文を参考にして、深さ優先探索のプログラムを書いてみました。
が、自分(初心者)ではできてるように思えたんですが、全然ダメみたいです。
再帰の使い方がよく分かってないというのもあるのですが(すみません)。
もしよろしければアドバイスを頂けませんか?お願いします!

『・始点(ここでは「1」)を出発して、番号が小さい順に進む位置を調べていき
 行けるところ(辺でつながっていて、まだ未訪問の節点)まで進む。
・行き場所が無くなったら、行けるところがある節点まで戻っ(再帰をリターン...続きを読む

Aベストアンサー

C言語の基礎から学んだ方がいいと思いますが、
こういうことでしょうか?

#define N 8

char v[N] = { 0, 0, 0, 0, 0, 0, 0, 0 };
char a[N][N] =
{ { 0, 1, 1, 0, 0, 0, 0, 0 },
{ 1, 0, 0, 1, 0, 0, 0, 0 },
{ 1, 0, 0, 1, 0, 0, 0, 0 },
{ 0, 1, 1, 0, 1, 0, 0, 0 },
{ 0, 0, 0, 1, 0, 1, 0, 1 },
{ 0, 0, 0, 0, 1, 0, 1, 0 },
{ 0, 0, 0, 0, 0, 1, 0, 1 },
{ 0, 0, 0, 0, 1, 0, 1, 0 } };

void recurse(int i)
{
int j;
printf(" %d", i+1);
v[i] = 1;
for(j = 0; j < N; j++)
if(a[i][j] && !v[j]) recurse(j);
}

void dfs()
{
int i, cnt = 0;

for(i = 0; i < N; i++)
if(!v[i])
{
printf("%d:", ++cnt);
recurse(i);
printf("\n");
}
}

int main(int argc, char *argv[])
{
dfs();
return 0;
}

C言語の基礎から学んだ方がいいと思いますが、
こういうことでしょうか?

#define N 8

char v[N] = { 0, 0, 0, 0, 0, 0, 0, 0 };
char a[N][N] =
{ { 0, 1, 1, 0, 0, 0, 0, 0 },
{ 1, 0, 0, 1, 0, 0, 0, 0 },
{ 1, 0, 0, 1, 0, 0, 0, 0 },
{ 0, 1, 1, 0, 1, 0, 0, 0 },
{ 0, 0, 0, 1, 0, 1, 0, 1 },
{ 0, 0, 0, 0, 1, 0, 1, 0 },
{ 0, 0, 0, 0, 0, 1, 0, 1 },
{ 0, 0, 0, 0, 1, 0, 1, 0 } };

void recurse(int i)
{
int j;
printf(" %d", i+1);
v[i] = 1;
for(j = ...続きを読む

Q内部仕様、外部仕様

プログラミング初心者です。来週までにレポートを出さなければならないのですが外部仕様と、内部仕様は具体的にどのように書けばよいのでしょうか?

Aベストアンサー

外部仕様 (機能仕様書 etc)
・プログラムの簡易説明、マニュアルみたいなもの
・プログラミングの知識が無い人にもわかる内容
・UI(ユーザーインターフェース)主体の仕様
・画面上の項目の説明、操作方法などをまとめる
 (画像とか載せておくと良いかも)

内部仕様 (詳細仕様書、設計書 etc)
・プログラムの詳細設計書
・開発者向けの内容
・開発環境(条件)、クラス仕様、構成、アルゴリズム等の説明
・プログラムの内部動作について詳しくまとめる
 (これとソースコードがあればプログラムの中身が全部わかる、というくらいに)
・必要に応じてコンポーネント図やフローチャート等も書く


どちらの場合も、図や箇条書きを使ってわかりやすく説明しましょう。
1つの文が長くて読みにくいものはNGです。

Qファイルやディレクトリの存在確認を行う方法

ファイルをオープンするのはfopenでOKですが、ファイルやディレクトリの存在確認を行う方法が知りたいです。

何か組み合わせて作るものなのでしょうか?
perlとか便利な演算子があるのですが、C/C++って器用ではないですね。
これは処理系?依存の内容ですか?

私の環境は VC6, VC2005 Windows2000です。

Aベストアンサー

int access(const char* path, int mode);
int stat(const char* path, struct stat* sb);

かな?
MSDN を引くと _access_s() を使えとか書いてあるけど。

Q2進数の減算のオーバーフロー/アンダーフロー

2進数の減算のオーバーフロー/アンダーフロー

2進数の加減算においてどういうときにオーバーフローするのかわかりません。
例えば、
符号付き整数加算として、
1111+0001=10000
となり、4ビットで表現しきれないので、この場合オーバーフローということでしょうか?

基本的に、元々のビット列の長さ(この場合、4ビット)を演算後、超えてしまう
結果となった場合、オーバーフロー、アンダーフローが起きていると考えてしまって
よいのでしょうか?

10進数に変換して10進数の演算結果と異なることが分かれば、オーバーフローが
起きているといえるのでしょうが、ビット長が100ビットなど多ビット長の場合に
そのようなことはできないので、簡単なオーバーフロー、アンダーフローの見分け方が
知りたいです。

ご回答お願い致します。

Aベストアンサー

ハードウェアでは
・符号なしオーバーフロー: 最上位からのキャリー/ボローがあればオーバーフロー
・符号付きオーバーフロー: 最上位からのキャリー/ボローと結果の最上位が同じならオーバーフロー
で判定できる. たとえば符号付きの
1111 + 0001 = 10000
の場合, 「最上位からのキャリー」が 1 で「結果の最上位」は (4ビットなので) 0 だからオーバーフローしていない.
演算回路をハードウェアレベルで構成するような本なら書いてあるんじゃないかな.

Qx86とARMの性能の違い

x86とARMの性能の違いについて教えていただきたいです。
それぞれの設計に基いたご説明をいただけるとなおありがたいです。
また、性能の違いの結果として、
それぞれどのような場面でよく使われるのかも知りたいです。

よろしくお願いいたします。

Aベストアンサー

まず違いを知るなら以下を読むべきかと、有志が書いているとはいえ、日本サイトのただの年表とは段違いに情報があるはずです。
http://en.wikipedia.org/wiki/ARM_architecture
http://en.wikipedia.org/wiki/X86

といって、読める人なら、質問しないのでしょうけど。
概略的に説明すると、ARMは reduced instruction set computing(RISC)プロセッサです。 それに対して、x86はベーシックに言えば、complex instruction set computer(CISC)プロセッサとなります。まあ、世間では既に差はあまりないのですけど、思想としてはCISCとRISCでは演算の基点が違います。

x86と呼ばれるプロセッサは、i8086を始まりとして(86を冠した世代が4世代目まで続いたことから)現在のCore i7プロセッサに至るまでの製品を指します。ただし、64bitモードであるx64(AMD64/Intel64)は、このx86を開発したIntelではなく、AMDが先に実装しています。このx86/64系のプロセッサは、高度で複雑な演算を行うために開発されたプロセッサであり、現在においてHPC用のプロセッサを除けば、世界最速を誇るプロセッサとなります。尚、x86/64系は処理速度を高めるために、スカラユニットの採用と分岐予測、パイプラインによる高速動作などを実現しているため、消費電力が大きなパーソナルコンピュータ、ワークステーション、サーバー分野においてこれまでは使われてきました。価格的にも高性能故にそこそこの値段であり、インテルとAMD以外のメーカーでは、VIAなど一部が進出するのみで、Intelの市場での強さもあり、他のメーカーが力をもつことはありませんでした。


ARMは、元々組み込み向けとしての素質を持つプロセッサで、コンパクトで指向性の高い命令を、速やかに処理することに長けたプロセッサとして登場しています。要は、何でも処理するというよりは、命令の方向性をある程度定め、その範囲内で処理をこなすことがARMの特徴となっていました。その代わり、消費電力はミリワット単位から数ワットまでと劇的に小さな電力/パッケージングに収まるものが主流でした。しかも、それ故に製造単価や開発単価も安く、そもそもARM.LTDは製品のライセンスビジネスで利益を出しており、インテルのように開発製造販売などを一手に手がける垂直型ではないことから、多くのメーカーが使ってきたのです。


本来この2つの製品が能力的に接近することはないと思われるほど性能差がありました。しかし、携帯電話の普及によって、ARMプロセッサは急速に進化を遂げ、スマートフォン時代に、市場規模ではインテルとAMDが開発してきたx86/64系のプロセッサに匹敵するか、それを超える市場規模になる可能性が出てきたのです。(金額ベースでは、インテルプロセッサにはまだ及びません)

ARMが急速に性能を伸ばすことになったのは、スマートフォンが登場したことが大きな理由です。当初は搭載していなかったSIMDの実装や、高機能レジスタの搭載によって、たった5年ほどで多くのラインナップが登場し、多くのメーカーがARM.Ltdとライセンス契約し新しい技術の搭載を進めたのです。
結果的に、現在ようやくインテル社が持つx86に迫る程度に性能が向上しました。ただ、性能面で上回るほどになるかというと・・・。今の段階ではまだ難しいでしょう。


尚、性能の違いの結果という点は今の段階では、高性能なx86、安価で省電力なARMです。
ただ、今後もそうである保障はありません。

単価やブランドイメージの違い、販売における製造ラインの確保の問題などもありますからね。
ただ、ARMの場合は、ライセンスさえ取得すれば、製造はある程度できますから、需要があれば数は伸びる傾向があります。ただ、単価が安いため、数が大量に出ているから、売上げが凄いわけではないのです。そのかわり、一定以上の販売が伸びれば、ソフト開発も活況を呈するため、ハードの性能も総じて向上します。
そうすると、性能が上がることで単価があがるというラインに今さしかかっています。

それに対して、x86/64は元々ブランドとして一定の地位を持っている高性能汎用プロセッサです。アプリケーション資産は既にPC市場において過半数を占めており、現在はゲーム機市場でもWiiUを除けば、PS4とX-BOX Oneに採用されています。1つのプロセッサあたりの単価もそこそこ高くなります。
高性能故にダイサイズもARMとは比べものにならないほど大きなものが主流です。最近になって、そこから性能を抑えて、ARMに対抗できる製品や、ARMより少し大きくとも消費電力が低く、性能は高い製品を出すようになりました。

尚、x86とARMでは、処理方法に違いがあり、実行できるマイクロコードの記述方法にも差異があります。そのため、x86の性能が高いからといって、ARMから簡単に移植したり、その逆にARMが普及しているからといってx86の資産を簡単に移せるわけではありません。まあ、アプリケーションはOSさえ対応し、アプリケーションの開発環境に準じた実行APIを備えてくれれば良いですけど、それを支えるAPIやOSは、ハードに最適化したプログラミングをしないと、そのハードが備えるピーク性能を発揮することはできません。

といったところでしょうか?

最後に、プロセッサには他にもMIPS(MIPS)、SPARC(SPARC/旧Sun Microsystems)、Power(IBM)、SX(NEC)、IA-64(Intel/HP)などなどのアーキテクチャが存在します。性能の違いだけで見るなら、これらの製品の方が、競争する市場が似ているものもありおもしろい製品が多いですけど。MIPSなどは、最近は少し弱いですが、MIPS-III世代では、ソニーのプレイステーション2のCPUであるEmotion EngineがこのMIPSアーキテクチャでした。SPARCはスーパーコンピューター京、Power系は、そのクライアント版(PowerPC)が、Intel Macになる前にMacintoshに使われていました。
SXは、地球シミュレーターです。IA-64は・・・。不運なプロセッサ。

設計で考えるなら、プロセッサ全体を見渡すのも大事です。そして何より、重要なのは開発されるOSやアプリケーションがどういうものかを見るのが妥当です。特にそれを如実に示すのは、SXとその他のプロセッサの違いでしょう。

まず違いを知るなら以下を読むべきかと、有志が書いているとはいえ、日本サイトのただの年表とは段違いに情報があるはずです。
http://en.wikipedia.org/wiki/ARM_architecture
http://en.wikipedia.org/wiki/X86

といって、読める人なら、質問しないのでしょうけど。
概略的に説明すると、ARMは reduced instruction set computing(RISC)プロセッサです。 それに対して、x86はベーシックに言えば、complex instruction set computer(CISC)プロセッサとなります。まあ、世間では既に差はあまりないのですけど、...続きを読む

Q文字コードの利点、欠点

シフトーJISとかEUCとか、色々文字コードが
ありますが、例えばこのふたつの文字コードの場合、
それぞれの利点、欠点は何なのでしょうか?
よく観るホームページではシフト-JISが多い気もしますが、
どちらの方がいいのでしょう?

Aベストアンサー

sjisだと、そのデータの任意の1バイトを取り出したとき,
1バイトのコードか、2バイト文字の2バイト目のコードか区別できないことでしょう。
よく見かけるのがsjisの漢字コードの2バイト目に
ファイルのセパレータである\が含まれる文字によるバグや、
日本語文字コードを意識していないプログラムに漢字を
与えた場合の誤動作です。
本来は漢字の一部なのに¥が含まれているために、
ディレクトリの区切りとして誤動作します。
まあ、全てのプログラムがきちんと作られていれば
問題無いわけですが,手間がかなり余分にかかります。
EUCやJIS方は区別がつくためこの問題は生じません。
また、これは英語圏の環境で日本語文字データを読み込んだ場合に問題を発生するかも知れません。


EUCは俗称で半角カナと呼ばれる文字を表現するのに
3バイト必要なので、これは欠点になりうるかも。

また、sjis,EUC両方の欠点として,多言語化かできません。
例えば,日本語、中国語、韓国語の文字の混在ができません。
また、どちらも8ビットを使うコードですので、環境によっては問題を起こす場合があります。
元々文字コードは7bitという前提で書かれていたことがあり、
そういう環境が無いと保証できない場合があり得るからです。


wwwの文字コードとしては本来はJISを使うべきかも知れません。
もともと通信という外部とやり取りする物はJISで
なければいけないような話があったはずです。

sjisが多いのは,単にその文字コードを基本とする
WindowsやMacの文字コードが無造作にそのまま
ページとしておかれるためでしょう。

私は自分のページはわざわざjisコードにしてます。

sjisだと、そのデータの任意の1バイトを取り出したとき,
1バイトのコードか、2バイト文字の2バイト目のコードか区別できないことでしょう。
よく見かけるのがsjisの漢字コードの2バイト目に
ファイルのセパレータである\が含まれる文字によるバグや、
日本語文字コードを意識していないプログラムに漢字を
与えた場合の誤動作です。
本来は漢字の一部なのに¥が含まれているために、
ディレクトリの区切りとして誤動作します。
まあ、全てのプログラムがきちんと作られていれば
問題無いわけですが,...続きを読む


人気Q&Aランキング