SwiftでSHA256ハッシュ+Base64+URLセーフエンコードを行うには

サーバ屋さんが MQTT ClientID SHA256ハッシュにくわえ、Base64+URLセーフエンコード にしてくれと言われるので調べて対応した覚え書きです。単にユニーク値で記号を含まないなら、SHA256だけでもいいと思うのですが... こだわりか既存のサーバの作込みがそうなってるのかなと...

Swiftでも、SHA256ハッシュ、Base64 のAPIはありましたが、URLセーフエンコードはなく、これはロジックで組む必要がありました。またこの3段階変換を行い、デバッグ用に中間変換結果も確認しするには、少々オブジェクトの選択扱いがややこしいようでした。コードは以下のとおりです。

  public func ConvertKey(
		baesKey: String, 	// 変換対象のキー
	) -> String
    {
        var ret: String = ""
        
        //--- SHA256値をBase64にエンコードし、URL safeにする。---
        let srcBin:Data?    = baesKey.data(using: .utf8)    // Binaly変換 
        let hashVal         = SHA256.hash( data: srcBin! )  // SHA256ハッシュ (内部はByte配列)
        let hashBin:Data?   = Data( hashVal )               // Binaly変換
        
        // 生成結果のDBG用の確認トレース
        let hastStr = hashVal.compactMap { String(format: "%02x", $0) }.joined()
        print( "HASH=" + hastStr + " len=" + String(hastStr.count) )
        
        // URL64エンコード 
        if let stg1 = hashBin?.base64EncodedString() {
            // Memo: Swiftには、URLセーフAPIはないため、ハンドコードで変換する。
            let stg2    = stg1.replacingOccurrences(of: "=", with: "" )
            let stg3    = stg2.replacingOccurrences(of: "+", with: "-")
            ret         = stg3.replacingOccurrences(of: "/", with: "_")
        }
        else {
            print( "base64EncodedString() error.")
        }
        
        return ret
 }

一旦、Binaly値に変換してあげるとスマートに収まりました。

VS2022にて App Store Connect API キーとアプリ固有パスワードを指定する 【’24.11月】

WindowsのVS2022にて、xamarin project リリースアーカイブ時、App Store Connect API キー アプリ固有パスワード なるものをもとれられるようになったときの対処メモです。詳しい操作はよくおぼえていません。

発端。MAC の VS2022はサポ切れになるとのことで、WindowsのVS2022に切替ようとApple Developer アカウントを追加しようとした時、入力を求められるようになりました。

Appleのヘルプをみると、App Store Connect API キー は、App Store Connect で発行する模様。少し説明に以下不備があるようです。

結局以下のことの模様です。

新規keyを発行します。

keyをDownloadします。

VS2022にimportします。

更に以下のダイアログが現れました。

以下のページで発行する模様。

キー発行のシーケンスは、

以上です。

なおデバック開始時に以下のエラーがでました。未調査です。

gtestでfloat値をExecl計算値と照合を試みる

gtestでテスト対象モジュールで計算されたfloat値を正しく計算されたか、Execl計算値と照合するケースは多いのではないでしょうか? floatは32bitですが数値分解能は23bit(確か…)、longの方が精度が高く、実際にはあまり使わないものです。今時のPCや携帯端末では、doubleを多用してもへっちゃらです。

しかし、マイコン向け組込みソフトでは未だdoubleを多用できるほど処理能力がありません。MATLAB/simulink の自動コード生成の都合で float(single) は使う場合もあるようですが、そもそも浮動小数点数は自体あまり使うべきではないと考えますが…

とあるお客さまで、gcc 使用でfloat値 不一致が多発していたので少し調べてみました。調査は VC++2019 で行っています。


Execl計算値をそのまま EXPECT_FLOAT_EQ に指定した場合、指定した数値から精度が落ちたことを警告されます。なるほどgccよりvc++の方が賢いみたいですね。テストはgccと異なり合格になります。Execl2003はVC++でBuildされてるでしょうから同じコンパイラから生成された数値は一致しやすいのでしょうか?


Execl計算生値では精度が大きすぎるようです。値をVBAマクロでfloat(Single)化した値をEXPECT_FLOAT_EQ に指定してみると、精度が落ち切っていないようです。


Execlに精度をあわせて EXPECT_DOUBLE_EQ を使うと上手くいくのでは? と思いましたが、float -> double 拡張で数値が変わってしまうようです。


ということて面倒ですが数値公差範囲を決めて、 EXPECT_NEAR を使しかなさそうです。EXPECT_FLOAT_EQ の公差は 4 ULPs (Unit of Last Place: 下4桁?) 以内にとのこと。

BungBungame KALOS のカスタムROM化は可能か?

ユーザさんより台湾BungBungame製 KALOS のカスタムROM化が可能か問合せがあったため調べてみました。その覚え書きです。

年式2013、当時日本でもいろいろ紹介されていたようです。現在、情報も少なく、スペックはこちらのようです

Android4.22止まり、有機EL、2560×1600と解像度は当時としては高く、Wi-fiモデルのみ。

https://androidfilehost.com/ にも直接はヒットせず。しかし「BaikalOS」といキーワードが出てます。これはAndroidの派生の一つのようです。たまたま単語部分一致でヒットした模様です。
2013年製となると、どのみち最新に近いAndroid相当のROMは作られていないと思われます。

SwiftではTextEditorの縦サイズが端末毎に変わってしまう

Shitf-UI にてライセンス許諾文を、TextEditor に表示した際の覚え書きです。Xcode 14.1 です。

TextEditor は、オートサイズが無いようです。フォントサイズを指定して、ライセンス許諾文が収まるようTextEditor 横縦サイズを指定しておきました。理論上どの端末でも同じになるハズですが、端末によって、ライセンス許諾文が途中で切れてしまいます。 これは iOSシュミレータと実機での間でも発生します。付随条件としては、TextEditor だけはスクロールできないので ScrollView をかませました。この時の端末は iPad 6th です。

@State private var licenseText : String = "Error"
 :
中略
 :
var body: some View {
 :
中略
 :
    ScollView( [.vertical], showsIndicators:true) {
	     TextEditor(text: $licenseText/* $必須 */ )
	     .frame(	width: myWidth * 0.9, height:8000)
	     .disabled(true)	// 入力禁止有効 
    }
    .border(Color.black, width: 1)
 :
中略
 :
}
.onAppear {
   :
  ライセンス文読込み
   :
	licenseText = tmptxt.string
   :
 後略

おそらく端末毎に dpi が異なるためだとおもうのですが、dpiを取得して演算するまで凝りたくありません。表示領域が多い分には実害はないので、弊方では height値 を一番高性能そうなiPad Pro 12inch の iOSシュミレータで合わせこんでおきました。

    ScollView( [.vertical], showsIndicators:true) {
	     TextEditor(text: $licenseText/* $必須 */ )
	     .frame(	width: myWidth * 0.9, height:9000)
	     .disabled(true)	// 入力禁止有効 
    }

8000 -> 9000 にUPで収まったということはザックリ1割のマージンを持たせておいた方が無難という感じでしょうか?