欧米仕様の為か、0が省略される
- 0.1→.1
- 1.1→1.1
- 0.01→.01
0に相当する文字列を渡した場合フォーマットされない
- 00.01→.01
- 00.00→00.00
- 001→1
- 000→000
useThousandsSeparatorがfalseの場合、整数部はフォーマットされない
※precision=”2″の場合
- 01234→01234.00
- 002.5→002.50
欧米仕様の為か、0が省略される
0に相当する文字列を渡した場合フォーマットされない
useThousandsSeparatorがfalseの場合、整数部はフォーマットされない
※precision=”2″の場合
OracleSQLでは/**/の開始文字と終了文字は空白や改行でテキストから切り離す必要は無いが、SQL*Plusでは空けなければならない。
- スラッシュとアスタリスク(/*)を使用してコメントを開始します。コメントのテキストを続けます。このテキストは複数行にまたがってもかまいません。アスタリスクとスラッシュ(*/)を使用してコメントを終了します。開始文字と終了文字は、空白や改行によってテキストから切り離す必要はありません。
- –(ハイフン2個)を使用してコメントを開始します。コメントのテキストを続けます。このテキストは複数行にまたがることはできません。改行によってコメントを終了します。
SQLの入力に使用するツール製品には、追加の制限事項があるものもあります。たとえば、SQL*Plusを使用している場合、デフォルトでは複数行のコメント内に空白行を入れることはできません。詳細は、データベースのインタフェースとして使用するツール製品のドキュメントを参照してください。
SQLのコメント・デリミタ(/*…*/)は、スクリプト内の個別の行に入力するか、SQLコマンドと同じ行に入力するか、またはPL/SQLブロック内の行に入力します。
コメントの初めのスラッシュとアスタリスク(/*)の後に空白を入力する必要があります。
コメントは、次のように複数の行にわたっていてもかまいませんが、コメント内にコメントをネストさせることはできません。
※ RFC7230 時点の情報に更新 → HTTP/1.1 のコネクション管理の理解メモ – CAT EARS
HTTPリクエストの処理中(長いAPサーバーの処理等)にタイムアウトなどでTCPコネクションが切断された場合、HTTPクライアントはRFC2616に従い同じリクエストを勝手に再送する事がある。(SHOLDとなっているのでその場合の方が多いかと)
なので、場合によっては二重POSTとなってしまう。。
非冪等メソッドの自動再試行は不可。
これはHTTPベースのプロトコル(SOAPやAMF、WebDAV等のRPC)全てに当てはまるため、RPCを使用する際には注意が必要である。
失敗パターンは リクエスト送信→失敗→再送信→失敗→切断(エラー?) が標準動作。
RFC2616 8.1.4 Practical Considerations より抜粋
A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request
at the same time that the server has decided to close the “idle”
connection. From the server’s point of view, the connection is being
closed while it was idle, but from the client’s point of view, a
request is in progress.This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s). Confirmation by
user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails.
参考:
参考:
RSAの話。
modulusをpublicKey.getModulus().toByteArray()
で取得した際くっついてくる符号ビットが曲者。。
※BigInteger#toByteArrayは符号ビット付き2の補数表現となる
符号ビット1bit + モジュラス本体1024bit(鍵長1024bitの場合) → 129ByteのByte配列
となるため、C#のRSAParameters.Modulus
に突っ込むには先頭の符号ビットに相当する1バイトを削って渡す必要がある。
ヘルプに何にも書いてないので謎だが、符号なしにしないとだめなようで。。
as3cryptoはそのまま突っ込んでも大丈夫なのに・・・
PrivateExponentはJavaでしか処理しないためそのままでも問題なく、PublicExponentについては17bit(65537固定)のデータのため、符号ビット”0″が付加されても無害。
(modulusは1024bit(8bitの倍数)なため符号ビットを付加するとあふれて129Byteになってしまうのが今回の場合問題となる)
//modulusの先頭符号ビットを除去
byte[] modulusBytes = stripLeadingZeros(publicKey.getModulus().toByteArray());
//Bse64エンコードしてC#へわたす
BASE64Encoder encoder = new BASE64Encoder();
String modulus = encoder.encode(modulusBytes); //→C#に渡す
String publicExponent = encoder.encode(publicKey.getPublicExponent().toByteArray()); //→C#に渡す
[/java]
RSACryptoServiceProvider rsaProvider = new RSACryptoServiceProvider();
rsaProvider.ImportParameters(rsaParams);
//暗号化してJavaに渡す
byte[] targetBytes = new UTF8Encoding().GetBytes(target); //target:暗号化対象文字列。UTF-8でバイト配列化
//とりあえずPKCS#1パディング。第二引数をtrueにすればOAEPパディングも使える。
byte[] resultBytes = rsaProvider.Encrypt(targetBytes, false);
string result = Convert.ToBase64String(resultBytes); //Javaに返す
[/csharp]
//ここでパディングや暗号化サービスプロバイダを指定できる。
//”RSA”は”RSA/ECB/PKCS1Padding”と同じ。
Cipher cipher = Cipher.getInstance(“RSA”);
cipher.init(Cipher.DECRYPT_MODE, privateKey); //とっておいた秘密鍵で初期化
byte[] resultBytes = cipher.doFinal(src);
String result = new String(resultBytes, “UTF-8”); //復号結果。UTF-8で復元
[/java]
Oracle Technology Network (OTN) Japan – 掲示板 : Linux版Oracle10g …
- Exp時は、常にデータベースのキャラクターセットで行われる。
- Imp時は、dmpファイル内に記録されてたキャラクターセットからImp先のデータベースのキャラクターセットに自動的に変換される。
XMLデータは、他のデータベース・オブジェクトの場合と同様に、エクスポート側サーバーのキャラクタ・セットでエクスポートされます。インポート中、このデータはインポート側サーバーのキャラクタ・セットに変換されます。
XMLDB関係あるのかな?
Oracleエクスポートおよびインポートとキャラクタ・セット。Oracle Database expユーティリティは、常に、エクスポート・サーバーのキャラクタ・セットでユーザー・データ(Unicodeデータを含む)をエクスポートします。キャラクタ・セットはデータベースの作成時に指定します。
Oracle Database impユーティリティは、インポート・サーバーのキャラクタ・セットにデータを自動的に変換します。
8ビット・キャラクタ・セットのエクスポート・ファイルをインポートすると、一部の8ビット・キャラクタが失われる(つまり7ビットの対応するキャラクタに変換される)場合があります。この現象は、クライアント・システムに固有の7ビット・キャラクタ・セットがある場合、またはオペレーティング・システムの環境変数NLS_LANGが7ビット・キャラクタ・セットに設定されている場合に発生します。アクセント記号のある文字は、ほとんどの場合、アクセント記号が失われます。
Oracle Databaseのexpユーティリティとimpユーティリティでは、データをエクスポートまたはインポートする前に必要なキャラクタ・セットの変換が示されます。
注意:
エクスポート・クライアントとエクスポート・サーバーの間でキャラクタ・セットの幅が異なる場合は、変換によってデータが拡張されるとデータが切り捨てられることがあります。切捨てが発生する場合は、警告メッセージが表示されます。
FTPタスクが使用しているcommons-netライブラリが日本語環境のFTPに対応していない事が原因。
Antのドキュメントにも記載されている。
Warning: there have been problems reported concerning the ftp get with the newer attribute. Problems might be due to format of ls -l differing from what is expected by commons-net, for instance due to specificities of language used by the ftp server in the directory listing. If you encounter such a problem, please send an email including a sample directory listing coming from your ftp server (ls -l on the ftp prompt).
ファイル一覧を取得する際、日付が日本語で返されるとうまく解析できない模様。
また、Ant1.5以前はcommons-netではなくNetComponentsを使用するが、こちらでも同様の問題が発生する。
恐らく大抵のFTPクライアントは日本語環境のFTPサーバーに対応していない気がする…
方法1.ftp.exeを使う
BATを書く要領で使える。多分。
方法2.サーバー環境を変更する
日付が英語で返されるようにすれば良い。
方法3.commons-netを改造する
面倒。
参考:
環境:Apache2.2.6@WindowsXP SP2
SVN+WebDAVの場合も、LocationディレクティブでSVNPathあるいはSVNParentPathに仮想ドライブを指定すると、Apacheの起動はできるがリポジトリの参照ができない。