バグ。Flex3で修正済み
7月 132012
7月 132012
7月 132012
- ActionScript 3.0のイベント処理について | デベロッパーセンター
- ActionScript 3.0 イベント処理の以前のバージョンとの違い
- Document Object Model (DOM) Level 3 Events Specification
- MetaGraphic Cell B4F – Scripts
- Adobe ActionScript 3.0 * イベント処理
DOM3Events関連
- ActionScript3(以下AS3)はDOM Level3 Eventsに準拠している。
(イベントリスナの優先度など、一部に非準拠仕様も追加されている) - リスナは同期処理であると定義されており、1つのリスナ実行中に他のリスナが同時に実行される事はない。
- リスナは追加された順に実行される。
※AS3ではaddEventListenerメソッドで実行優先度を指定できる。 - リスナの実行順序は規定されているが、
MouseEventやKeyboardEvent等の一部を除きイベントの発生順序までは規定されていない。 EventTarget.dispatchEvent()によって新たにイベントが発生させられた場合、発生させたリスナの処理は新たなイベントの伝播が完了するまで再開しない。EventオブジェクトのcurrentTarget、eventPhaseプロパティは、DOM Eventsの実装によって自動的に更新されるもので、読み取り専用である。
7月 132012
環境：Flex2.0.1(どうやらFlex3.0でも変わってなさそう？)
このメモ以降にも色々調べたりAdobeとやりとりしたはずだが、よく覚えてない…
FlashPlayer10との絡みもあったはず。
FlexのTextInputはimeModeプロパティを指定した時変な動きをする。
以下のように入力項目が並んでいるとする。
- 入力①：IME制御なし
- 入力②：ひらがな
- 入力③：IME制御なし
①にフォーカスがある状態で、IMEがONかつひらがな入力の場合、
①→②→③とフォーカスを移動すると③の時点でIMEがOFFになってしまう。
ちなみにIMEはOFFにされるが、変換モード(全角カタカナ、半角英数など)は①の状態を記憶しておき、③に移る時に元に戻している。
③では、②で変更されたモードをそのまま引き継ぐのが通常の動作のように感じる。
個人的には①のモードを記憶しておいて、戻ってくれたほうが使い勝手がいいと思うのだけど。。
Continue reading »
7月 132012
- タイトルの長さとボタンの幅で決まる。
- 継承でどうにかする事もできそうにない。
- タイトルの末尾にスペースを付加して調整する事は可能。
7月 132012
欧米仕様の為か、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
7月 122012
OracleSQLでは/**/の開始文字と終了文字は空白や改行でテキストから切り離す必要は無いが、SQL*Plusでは空けなければならない。
- スラッシュとアスタリスク（/*）を使用してコメントを開始します。コメントのテキストを続けます。このテキストは複数行にまたがってもかまいません。アスタリスクとスラッシュ（*/）を使用してコメントを終了します。開始文字と終了文字は、空白や改行によってテキストから切り離す必要はありません。
- –（ハイフン2個）を使用してコメントを開始します。コメントのテキストを続けます。このテキストは複数行にまたがることはできません。改行によってコメントを終了します。
SQLの入力に使用するツール製品には、追加の制限事項があるものもあります。たとえば、SQL*Plusを使用している場合、デフォルトでは複数行のコメント内に空白行を入れることはできません。詳細は、データベースのインタフェースとして使用するツール製品のドキュメントを参照してください。
SQLのコメント・デリミタ（/*…*/）は、スクリプト内の個別の行に入力するか、SQLコマンドと同じ行に入力するか、またはPL/SQLブロック内の行に入力します。
コメントの初めのスラッシュとアスタリスク（/*）の後に空白を入力する必要があります。
コメントは、次のように複数の行にわたっていてもかまいませんが、コメント内にコメントをネストさせることはできません。
[sql]/* Commission Report
to be run monthly. */
COLUMN LAST_NAME HEADING ‘LAST_NAME’;
COLUMN SALARY HEADING ‘MONTHLY SALARY’ FORMAT $99,999;
COLUMN COMMISSION_PCT HEADING ‘COMMISSION %’ FORMAT 90.90;
REMARK Includes only salesmen;
SELECT LAST_NAME, SALARY, COMMISSION_PCT
FROM EMP_DETAILS_VIEW
/* Include only salesmen.*/
WHERE JOB_ID=’SA_MAN’; [/sql]
to be run monthly. */
COLUMN LAST_NAME HEADING ‘LAST_NAME’;
COLUMN SALARY HEADING ‘MONTHLY SALARY’ FORMAT $99,999;
COLUMN COMMISSION_PCT HEADING ‘COMMISSION %’ FORMAT 90.90;
REMARK Includes only salesmen;
SELECT LAST_NAME, SALARY, COMMISSION_PCT
FROM EMP_DETAILS_VIEW
/* Include only salesmen.*/
WHERE JOB_ID=’SA_MAN’; [/sql]
7月 122012
※ 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.
参考:
7月 122012
- コマンドの引数として渡されるFQDNの末尾にスペースかドットが付加された場合に発生する事が多い。
→HELO、EHLO、MAIL FROMなどのコマンド - コード5.5.4は、RFC1893に定義されたとおり、コマンド引数が不正であり、送り先などを修正しなければ解決できそうにない恒久的なエラーを示す。
- 大抵のSMTPサーバは末尾のスペースやドットを無視するが、RFC821および1869に厳しいサーバではエラーとなる事がある。
→Microsoft Exchange 2000やMicrosoft Exchange Server 5.5 SP4など
参考:
7月 122012
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になってしまうのが今回の場合問題となる)
キーペア作成＠Java
[java]
//鍵作る
KeyPairGenerator generator = KeyPairGenerator.getInstance(“RSA”);
generator.initialize(2048);
KeyPair keyPair = generator.generateKeyPair();
RSAPrivateKey privateKey = (RSAPrivateKey)keyPair.getPrivate(); //Javaでとっとく
RSAPublicKey publicKey = (RSAPublicKey)keyPair.getPublic();
//鍵作る
KeyPairGenerator generator = KeyPairGenerator.getInstance(“RSA”);
generator.initialize(2048);
KeyPair keyPair = generator.generateKeyPair();
RSAPrivateKey privateKey = (RSAPrivateKey)keyPair.getPrivate(); //Javaでとっとく
RSAPublicKey publicKey = (RSAPublicKey)keyPair.getPublic();
//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]
暗号化＠C#
[csharp]
//鍵の取り込み
RSAParameters rsaParams = new RSAParameters();
rsaParams.Modulus = Convert.FromBase64String(modulus); //Javaから受け取る
rsaParams.Exponent = Convert.FromBase64String(exponent); //Javaから受け取る
//鍵の取り込み
RSAParameters rsaParams = new RSAParameters();
rsaParams.Modulus = Convert.FromBase64String(modulus); //Javaから受け取る
rsaParams.Exponent = Convert.FromBase64String(exponent); //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]
復号化＠Java
[java]
BASE64Decoder decoder = new BASE64Decoder();
byte[] src = decoder.decodeBuffer(cryptedData); //cryptedData:C#から受け取る
BASE64Decoder decoder = new BASE64Decoder();
byte[] src = decoder.decodeBuffer(cryptedData); //cryptedData:C#から受け取る
//ここでパディングや暗号化サービスプロバイダを指定できる。
//”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]