記事のディレクトリ
序文
心の状態に先立ってパフォーマンスステータス、前決意の習慣は、好みに最初に焦点を当てます
いくつかの混乱コンセプト
。8-フォーマットようGBK、UTFをコード
Unicodeは標準仕様である、実際には、従来の8ビット、16ビットおよび32ビット符号化部、それぞれ、UTF-8、UTF-16、 UTF-32は、
MD5などダイジェストアルゴリズム、不可逆的です、共通言語検出データの整合性
バイナリ変換方法は、バイナリデータメソッドを表すためのBase64 64個の印刷可能な文字に基づいており、変換からなるバイナリ文字列を話すことができ、これは暗号強調されていない
URLに対して、URLエンコードを中国の特殊文字とエスケープ、処理を容易にする通常のブラウザ
データの暗号化の特徴部、暗号化と復号化に同じ鍵であるようなDES、AESのような対称暗号化アルゴリズムのを、
RSAなどの非対称暗号化アルゴリズムを、二つの重要な特性が必要とされ、一般的に、秘密鍵と公開鍵と呼ばれる一つのキーを用いて暗号化し、他のキーを解読することができます。
エンコード形式
Unicodeエンコーディング標準
ASCII、UTF8、GBK、GB2312等
ダイジェストアルゴリズム
Base64のプロフィール
Base64では、バイナリデータ表現へ64個の印刷可能な文字に基づいています。
RFC2045〜RFC2049を参照してくださいすることができます
文字列にのみバイト配列にBase64で、それ以外、Base64で、ある程度までは、実際に、よりUTF8、GBK同じ符号化方式のような-乱雑に見えます彼らは、このようなUTF8またはGBKとして、文字エンコーディング形式として認識することはできませんので、あなたが、あなたは彼らがリテラルまたはシンボリックことができます知っています。
BASE64は、形質転換能バイトデータ列との間に設けられています
：BASE64は、能力提供
文字化けのように見える- Base64でエンコードされた文字列に1バイト配列を
バイト配列に、2 Base64文字列を
文字の数を設定するように、文字符号化フォーマットUTF8から来るかもしれません文字列は、文字列もGBKエンコーディングから来るかもしれないが、Base64でエンコードされた文字列のエンコード形式を使用するときにどのような場合には、問題を心配する必要はありません
標準のBase64エンコードのルール
本質的に、バイト文字および実装規則にBase64では、
Base64では、印刷可能な、実質的に64個のシンボルを使用します
0-9：10図
26小文字：AZ
26は大文字である：AZ
2シンボル：+ /を
Base64エンコード規則は、変異体を存在します
標準のBase64既存の記号+および/は自動的にいくつかのシーンでエスケープされているので、問題のデータベースに、このようなURLのようにBase64で実際のアプリケーションを使用すると、特殊記号の変換を含むので。
あなたが理解することができます実際の使用においては、Base64でエンコードされた文字は、次のような、特定の変形に応じて他のシンボルを含んでいてもよい、実質的に64個のシンボルに限定されるものではなく=、 - ！_等
次の抜粋Baiduの百科事典：
URL標準のBase64エンコーダは、「/」と「+」の文字は、フォームの「％XX」になり、これられるので、標準のBase64 URLには、直接伝送には適していません「％」はANSI SQLは「％」になっているので、データベースShihaiに変換する必要がワイルドカードとして使用されませんでした。
この問題を解決するには、URLのは、Base64エンコーディング、「=」記号の充填で終わり、そして標準Base64で「+」を改善するために使用することができ、「/」に変更されている「 - 」「と。」、これは、オブジェクト識別子を形成する等、この方法で符号化情報の長さを増加させる避けるために、行われるべき変換、URLデータベースに格納コーデック時の必要がなくなり、統一データベース形式。
「！」「 - 」 "「*」、「+」ため、以前のIRCuでの使用の改善をBase64バリアントのための正規表現がありますが、それは「+」と「/」に変更して、意志正規表現で」[「と」]は特別な意味を持つことができます。
いくつかの亜種もありますが、彼ら意志「+ /」を「 - 」または「「「でも（のNmtoken XML使用されている）と、」（識別子名のプログラミング言語として使用）または」.-は：」（で使用される名前のXML）。
1/3程度の文字の元の長さよりもBase64エンコード
8ビットBase64では各バイトの3つのバイトは、4つの6ビット（3に変換される必要。8 = 4 6 = 24）、その後、別の二つの高6ビット0を追加し、8ビットの組成物の4バイト、すなわち、弦理論は、元の長さよりも1/3に変換します。
ルールは、問題の程度の差はありますが、処理のために別の文字エンコーディング形式は同じではありませんですので、理由が席を埋め、理論的です。
ベース64は、暗号化アルゴリズムではありません
Base64で最も一般的な誤解は、大きな間違いである暗号化方式、ある作業です。
その使用は一般的にdecode- encode-ビューの符号化と復号化で
異なる文字エンコーディング間の共通表現を解決するための主な問題
Base64での使用シナリオ
歪みがBase64での一般的に表示されますので、データ処理の一部として使用することができ
、それは属性を文字コードではなく、いわゆるゴミ問題ではありません- -もちろん、あなたは、Base64を復元します異なるシステム間でのデータ交換のために使用することができるのBase64元の文字エンコード形式の文字列は、まだ注意を払うように対応するとき。
JavaでのBase64使用
方法はApache Commonsのコーデックはjdk1.8が提供する、または使用するようにアドバイスを提供。
会場：JavaでBase64でいくつかの実装を
URLエンコード
対称暗号化
非対称暗号（公開鍵暗号）
RFC2246：米国政府は、ソフトウェアの512以上のビットRSA暗号輸出キーモジュールを含んでいないかもしれませんが、デジタル署名のためのより大きい512 RSAアルゴリズムのキーを制限するものではありません。
RSA非対称暗号化、暗号化された平文拘束長117は、復号化されます暗号文は128を制限します
デジタル署名アルゴリズム
MACアルゴリズム
参考資料
[1] https://www.cnblogs.com/sunxuchu/p/5483956.html
[2] https://www.jianshu.com/p/a8070920810d
[3] HTTPS：//www.cnblogs。 COM / sunxuchu / P / 5483956.html
[4] https://baike.baidu.com/item/base64/8545775?fr=aladdin
[5] https://blog.csdn.net/qq_20545367/article/詳細/ 79538530