あなたは、人目の訪問者です。
| リンク |
ASCII コード表 |
| ファイル終端コード |
|
MS-DOS 時代は、ファイル終端を示すコードとして、0x1a を使用している。 Windows のメモ帳などで見ると「^Z」とかって表示するゴミっす。 |
| テキストの改行コード |
CR=0x0D,LF=0x0A |
|
BER (Basic Encoding Rules) |
||||||||||||
|
SNMP で利用。 ISO8825-1 で定義されている。 基本的には、
|
| BER の型の値 | ||||||||||||||||||||||||||||||||||||||||||||||||||
型の値(SNMP コマンド)
型の値(その他)
|
| BER の構造体 | |||||||||||
大抵はこんな感じ
|
|
ASN.1 (Abstract Syntax Notation One) |
|
構造化記述の一つ。 |
| ASN.1 と BER の違い |
|
マイクロソフトへリンク(KB=KB252648) |
|
DER (Distinguished Encoding Rules) |
|
BER のサブセット |
|
CER (Cannonical Encoding Rules) |
|
ASN.1 のデータ構造のエンコード方式の一つ |
|
XDR (eXternal Data Representation) |
|
Sun RPC で利用されているコーディング法 RFC1041 で定義されている。 サポートされるデータ型は、
|
| Base64 |
|
RFC1521,RFC1522 で定義されているかも。 SMTP(ESMTP) で利用 日本でのデフォルトエンコード法でしょう。 8bit 3つ(24bit) を、6bit 4つに分ける。 割り当てる ASCII キャラクタは、 6bit 値が、 0x00 の時 A で、0x01 の時 B で、....0x19 の時 Z で、0x1a の時 a で、0x1b の時 b で、....0x33 の時 z で、0x34 の時 0 で、0x35 の時 1 で、....0x3d の時 9 で、0x3e の時 + で、0x3f の時 / です。 バイトが足りない場合、ヌル(0x00)を一つパッドして入れられ計算される。 変換後は、4の倍数個にするためのパッドとして、"=(イコール)"がパッドとして利用される。 (変換後は、"A-Z,a-z,0-9,/" で、"=" はない) 例えば、i(0x69) の場合、i(0x69) + NULL(0x00) - > aQ 変換後は、4の倍数にするため aQ -> aQ== ちなみに、
BASE64 エンコード/デコードを行う COM コンポーネント |
| uuencode/uudecode |
|
Base64 の元になった方法 3byte から、6bitづつ取ってきて、その値に 0x20 を加算。 その値の文字コードをそのまま使用する。 ただし、0x20 の場合(0x20 を加える前の値が 0x00)は、さらに 0x40 を加算する。 つまり「`!"#$%&'()*+,-./0123456789:;<='gt;?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_」が変換テーブル BASE64 エンコード/デコードを行う COM コンポーネント に uuencode/uudecode を追加 |
| uuencode/uudecode コマンド | |||||||||||||
ファイルのエンコード/デコードの UNIX 上のコマンドでは、
|
| Q-Encoding 法 |
|
下の Quoted-printable 法 |
| Quoted-printable 法 |
|
RFC1522 で定義されているかも。 SMTP(ESMTP) で利用 主に欧州圏? 8bit目がオンの文字は、=(イコール)に続く、2桁の16進によって記述される。 = が、% の場合、そのまま CGI でコーディングと同等と言える。 COM を作ったです。 |
| MIME のフォーマット | ||||||||||
|
| MIME | ||||||||||||||
|
MIME(Multiple Internet Mail Extentions){多目的インターネット・メール拡張機能}とは、メール本文に構造化機能を与えるものであるが、SMTP との下位互換性も十分に備える。 RFC1590 に概説がある。 RFC1521 で定義されている。 さらに、RFC2045,RFC2046,RFC2047,RFC2048 でも、定義されている。 ESMTP とのからみが、RFC1892 で議論されている。 メールヘッダ部に新しいヘッダを追加することで、実現する。 MIME エンコードされたデータは、NVT ASCII の文字列となる。 という事で、旧来の SMTP システム(MTA システム)でも十分整合性が保たれる。 MIME に必須に条件は、MIME に対応した MUA だけであり、MTA は旧来のままでもよい。 RFC1521 で推奨している組み合わせ
その他
|
| MIME 用のメールヘッダ | ||||||||||||
|
|
MIME 用のメールヘッダ Content-Type ヘッダ |
||||||||||||||||||||||||||||||||||||||||||||||
|
RFC1521 では タイプは、7 種類。 サブタイプは、16 種類。
コンテンツのタイプなどを指定するのであるが、
Octet-Stream の場合、 ファイル名をつけることがある
|
|
MIME 用のメールヘッダ Content-Disposition ヘッダ |
|
|
受信者がコンテンツをどう扱うかを示すヘッダ。 元々は、電子メールを受信したら、音を鳴らしたりしたかったためと考えられる。
Content-Type ヘッダよりも、添付ファイルのファイル名は、こちら側を使うのが原則であるが、Content-Type ヘッダと Content-Disposition ヘッダの両方に同じ値を書く場合が多いかも。 |
|
MIME 用のメールヘッダ Content-Transfer-Encoding ヘッダ |
種類は、5 種類。
下の 2 種(8bit,binary)については、ESMTP の 8bit 拡張モード(8bitmime コマンド)が受け入れられるサーバにのみ利用可能。 |
| MIME による subject エンコーディング | |
エンコード形式は、BASE64 の場合は、B |
| MIME - multipart の例 | |
|
| 定義済みの MIME タイプ |
|
IANA のここかな または、ここかな |
|
定義済み文字コード キャラクタ・セット |
|
IANA のここかな |
| S/MIME |
|
RSA データ・セキュリティ社が主催のグループが、MIME メッセージの暗号・署名方法を規定した。 RSA データ・セキュリティ社が開発した PKCS#7 方式を利用。 |
| 品質値 |
|
MIME で指定できるのかな。 とりあえず、HTTP では使用する。 q= 値で、値の範囲は、0.000 から 1.000 まで。 大きい値ほど優先されます。 省略された場合、q=1.000 となります。 というか、一番優先させたいものだけが省略できます。 HTTP はここを参照 |
|
CGI エンコーディング URL エンコーディング |
|
ここを参照 それと、URL の項かな。 COM を作ったです。 こっちにもメモあり |
| 数値実体参照 |
|
関連性は CGI なのかな。 「&#文字コード;」というエンコード方式です。 例えば、「'」->「'」となる。 クロスサイト・スクリプティング対策とかでお目にかかりますな ここを参照 それと、URL の項かな。 COM を作ったです。 こっちにもメモあり リンク: |
| 文字集合と、コード集合 | ||||||||||||||||
|
以下、文字コード関連が続くので....自分なりのメモ まずは、意味(目的)の異なる集合が二つあるので、その違いを明確に認識しないといけないらしい。
文字コードのサイズによって....
|
||||||||||||||||
| ISO8859 | ||||||||||||||||||||
ヨーロッパ系の SBCS
|
| ASCII(American Standard Code for Information Interchange) |
|
ISO646 半角カタカナが追加されて JIS X 0201 |
| EBCDIC(Extended Binary Coded Decimal Interchange Code) |
|
IBM が規格したメインフレーム用の文字コード(8bit) |
| KEIS(Kanji processing Extended Information System code) |
|
日立独自の JIS ベースのメインフレーム向け文字コード 1byte 部分は、EBCDIC を使用する |
|
UCS-2(ISO/IEC 10646-1) Unicode のエンコーディング CJKV |
|
|
16bit で世界中の文字を表現しようという文字集合/(文字セット) 文化/国を超えて似た漢字をまとめちゃったので、UCS-2 の漢字の集合を CJKV(Chinese Japanese Korean Vietnamese)という。 といっても、ベトナムは脱退した模様なので、CJK とも言うらしい Windows では、内部で UCS-2 に似たコード体系を採用している。 一文字を16bit固定としている。 2Byte の Unicode Character Set (UCS-2) は、2byte の 16 進数コードを NNNN として、
|
| Windows の UNICODE |
|
UTF-16 だったらしい。 といっても、WindowsXP からサロゲート機能(4byte の UTF-16)に対応したらしい リンク: |
|
UCS-4 ISO/IEC 10646-1 |
|
16bit では足りなかったので、31bit(4byte) 空間での UNICODE の文字集合 先頭 Byte から、群(group)、面(plane)、区(row)、点(cell)という。 群は、128個(7bit) 「群=0x00,面=0xE0-0xff」と「群=60-7F」の空間は予約済みである。 「群=0x00,面=0x00」の空間は UCS-2 そのものとしている。 |
| UTF-8 可変長 UNICODE | |||||||||||||||||||||
|
2byte のデータ(まぁ、文字ですな)の UTF-8(UCS Transformation Format) での表現。 RFC2279 7bit(7bit ASCII)を z を 0 or 1 として 1byte を y,z を 0 or 1 として、 2byte を x,y,z を 0 or 1 として
(o は 0 or 1 の場所にある 0 を示す) (0 は定義されて、0 でなければいけない値) (1 は定義されて、1 でなければいけない値)
表現できる最も少ないバイト数で表現する事が仕様上、求められている。 (これを用いた不正行為として MS00-057 を参照しよう) よく見ると、先頭の最初の 0 が出るまでの 1 の数が、データの長さ。 それ以降は、10... で始まる byte となっているねぇ。 ASCII に限れば UTF-8 と同値。 実際には、UCS-4 まで表現可能(1-4Byte)。 UTF-8 では、1-6Byte で表現。 リンク: |
| ISO-2022-JP |
|
インターネット電子メールにて標準で利用されている。 RFC1468 で定義されている。 |
| UTF-7 |
|
電子メール用? |
| UTF-16 |
|
UCS-2 の領域は、そのまま使う (UCS-2 以外の)UCS-4 は 4Byte で表現する(サロゲート機能) ただし、UCS-4 の全てを表現することはできないらしい ビックエンディアンとリトルエンディアンのパターンがある BOM の登場... |
| UTF-32 |
|
こんなものもあるらしい |
| BOM(Byte Order Mark) |
|
データ先頭に位置する ビックエンディアンかリトルエンディアンの判定につかう 16進数で「0xFEFF」として正しく読めるエンディアンが正解という事 最近では「UNICODE である」という目印として使われる場合があるらしい。 ISO-10646(≒UNICODE)では、途中に出てもいいらしい(Zero Width NonBreaking Space) |
| JIS 漢字コード | ||||
旧JIS と新JIS があるらしい
UNICODE は新JIS をベースにしている |
| IBM 拡張 |
|
旧 JIS(JIS-C-6266) に追加(FA40以降) |
|
NEC 拡張 NEC特殊文字 NEC選定IBM拡張文字 98文字 |
|
IBM 拡張にさらに追加 |
| マイクロソフト標準キャラクタセット |
|
JIS-X-0208 に加えて、IBM 拡張とNEC 拡張を加えた文字集合 重複している場合もある NEC 拡張では一部が除かれた |
| JIS | ||||||||||
|
JIS は、基本的に漢字インコードと呼ばれるコードの次のコードから、漢字モード(日本語モード)。 漢字アウトコードと呼ばれるコードによって、ASCII コードに移行する方法。 JIS 漢字コードは、 ASCII コードと衝突(どちらを指し示しているのか判断できない) するので、インコード、アウトコードによって、漢字モード、ASCII モードというモード切り替え方式によって、ASCII 文字と共存します。 欠点としては、不可視のコードが増えるので、直感的に分かりにくい。という点。 例えば、abc漢字de という文字列の場合、9byte に、漢字インコードと漢字アウトコードを加える必要がある。 これはつまり文字列のメモリを計算(確保)しにくい。 一方、ShiftJIS,EUC の場合、9byte (文字を数えれば{半角に 1 加えて、全角に 2 を加えるだけ}いいだけ)で済むという事でプログラミングは簡単になる。 ASCII エスケープ文字 "\(0x5C)" と衝突する。 表
RFC-1468 では、JISカナとJIS補助漢字は除外されている |
| JIS エスケープシーケンス | |||||||||||||||||||||
エスケープシーケンスを使うことで、一つのコードを複数の文字(文字集合に割り当てられる)
|
|
JIS JIS X 0208 旧JIS C 6226 |
|
|
JIS ISO2022-jp |
|
|
SJIS(Shift-JIS) JIS C 6220 |
||||||||
|
パソコン関連で利用されている。 MS-Windows,MS-DOS,Macintosh,UNIX(一部)で利用されている。 JIS コードの第一バイトを、ASCII セットの定義されていない 0x81 以降にずらした(シフト)文字セット。 文字列処理としては、1byte ずつ処理をしていき、もし、ASCII 文字でなければ、ShiftJIS 第一バイトとして、次の 1byte を会わせて、2byte 文字として処理をします。 ただ、漢字2バイト目は、ASCII 文字セットと衝突する事に注意。 ASCII エスケープ文字 "\(0x5C)" と衝突する。 日本語対応コンパイラが対応してくれる場合もあり。 コードは、sNKF32COM.dll にも追加した。
|
| JIS <--> S-JIS |
|
| EUC(Extended Unix Code) | ||||||||||
UNIX で利用。
|
| UNICODE |
|
MS-WindowsNT4.0,MS-Windows2000 の内部で利用されている。 UNICODE 表へリンク |
| RACE |
|
マルチ・バイト・ドメイン(日本語ドメイン)などで利用されている。 まだ、InternetDraft の状態のようだ。 5 つの byte を 8 個に分ける? draft-ietf-idn-race-02.txt |
| ACE |
|
ACE とは、ASCII Compatible Encoding 日本語ドメイン用の変換アルゴリズム!? |
| Punycode |
|
国際化ドメイン用の変換アルゴリズム UNICODE 符号化方式の一つ。 非 ASCII ドメイン名を「XN--」+「ASCII文字列」に変換する。 |
| ヒドゥン・ドット・アルゴリズム(RFC821) | ||||||
|
SMTP のメール本文では、.(ピリオド) だけの行をメール・メッセージ終了を意味しているので、行頭に .(ピリオド)がある場合、..(ピリオドを二つ)にして、送信する。 例えば、
|
| URL エンコーディング |
|
文字のビット列(8bit)を 16進数表示の 2 桁と、その前方に「%」をつける。 a -> %61 半角スペース(0x20)は、クエリー文字列内では、「+」に変換する。 そうでない場合は、「%20」へ変換する。 16進数表記時のアルファベット(a-f)は、大文字でも小文字でもよい。 変換する必要の無い文字列などは、ここ |
| X.509 証明書 | ||||||||||||||||||||||
|
ISO,IEC,ITC が定めた電子証明書の形式。 バージョン1 が、1988年。 バージョン2 が、1993年に登場。 バージョン3 が、1996年に登場。
SNMP のようだ。 トップレベルは、 0 = ITU 1 = ISO 2 = ISO-ITU ISO では、第二レベルが 0 = ISO 標準 2 = ISO が認定した国 3 = ISO が認定した国際機関 ISO-ITU では、第二レベルが 16 = 国 となり、その下には、840(米国{ANSI が管理})があり、その下に、1(米国組織)がある。 一般には、セパレータは、半角スペースを用いる。 「{コメント(番号) コメント(番号)...}」 という感じ。 暗号のオブジェクト識別子
|
| X.509 証明書 ver3 | |||
|
基本的に上述の通りであるが、X.500 名でなければいけなかった名前が、同一性、一意性が保証できる名前ならなんでもよくなった。 よく使われる名前は、
ver3 から追加
|
| MD5 |
|
MD5 ハッシュ関数は、RFC1321 に定義されている。 JavaScript で MD5 を実装してみました。ここ |
| MD4 |
|
MD4 ハッシュ関数は、RFC1320 に定義されている。 JavaScript で MD4 を実装してみました。ここ |
| PGP の文字列エンコード |
|
PGP のデータと署名が分離しているデータは、データ列の各行の先頭が「-」の場合は、「-(半角スペース)-」に置換されている。 PGP メモはここのどこか PGP を使うようにする COM は |
| Mac Binary |
|
COM があるそうだ。 リンク: |