リリース 2026.9.0: sgcWebSockets、sgcSign、sgcIndy、sgcOpenAPI

· リリース
Delphi、C++ Builder、.NET 向け eSeGeCe コンポーネントライブラリのリリース 2026.9.0

2026.9.0 がすべての製品で同時にリリースされました。sgcWebSockets、sgcWebSockets .NET、sgcSign、sgcIndy、sgcOpenAPI です。今年最大のリリースです。まったく新しい2つのパッケージが sgcWebSockets に加わり、長いあいだリクエストを取りこぼしていた問題を中心にサーバーエンジンが作り直され、署名ライブラリは署名をそれ自身以外のものに照らして検証できるようになりました。

この記事では、各製品で重要なポイントを、役に立つ場面では Delphi コードを添えて紹介します。すべての内容は変更履歴に記載されており、既存の動作を変更する部分は記事の終わり近くにまとめてあるので、アップグレードの前に目を通せます。

4分でわかるリリース全体。 YouTube でもご覧いただけます.

製品新機能修正破壊的変更
sgcWebSockets255622
sgcSign257021
sgcOpenAPI9255
sgcWebSockets .NET52410
sgcIndy050

sgcWebSockets 2026.9.0

sgcWebRTC、ネイティブ WebRTC メディアエンジン

新しい sgcWebRTC パッケージは TsgcRTCPeerConnection を完全な WebRTC エンドポイントに変えます。音声通話とビデオ通話、画面共有、SCTP データチャネル、そのすべてが Pascal で実装されており、ブラウザも WebView コントロールも外部のメディアライブラリも必要ありません。Windows、Linux、macOS、iOS、Android で動作し、生成および解釈する SDP が本物なので、相手側のピアはブラウザでもかまいません。

オファーとアンサーの交換は W3C の形式に従っているため、CreateOffer、CreateAnswer、SetLocalDescription、SetRemoteDescription、AddIceCandidate は名前のとおりに動作します。SDP は、すでにお持ちのシグナリングチャネルであれば何を使って運んでもかまいません。同じライブラリで構築した WebSocket サーバーでも問題ありません。

uses
  sgcP2P;

var
  oRTC: TsgcRTCPeerConnection;
begin
  oRTC := TsgcRTCPeerConnection.Create(nil);
  oRTC.RTCOptions.ICEServers.AddURL('stun:stun.l.google.com:19302');
  oRTC.OnLocalDescription      := OnLocalDescriptionHandler;
  oRTC.OnICECandidate          := OnICECandidateHandler;
  oRTC.OnConnectionStateChange := OnConnectionStateChangeHandler;
  oRTC.OnDataChannel           := OnDataChannelHandler;

  oRTC.CreateDataChannel('chat');   // forces RTCOptions.DTLS on
  oRTC.CreateOffer;                 // gathers ICE candidates, builds the SDP offer
end;

procedure TForm1.OnLocalDescriptionHandler(Sender: TObject;
  const aType, aSDP: string);
begin
  // send aType + aSDP to the remote peer over your own signalling channel
end;

メディアも同じように動きます。AddTrack は Opus または G.711 の音声トラック、あるいは VP8、H.264、Motion JPEG のビデオトラックを追加し、SendPCM と SendVideoFrame はキャプチャしたメディアを送り込み、OnAudio と OnVideoFrame はデコード済みのリモートトラックを渡します。

ブラウザ時代の古いフォールバックは逆の道をたどりました。AppRTC プロトコルと RTCMultiConnection API のサポートは削除され、2020年にサポートが終了した Flash フォールバックも削除されました。記事の最後にあるアップグレードの注意事項をご覧ください。

sgcCrypto、OpenSSL なしの暗号処理

2つめの新しいパッケージは sgcCrypto です。ほとんどのアプリケーションが実際に必要とするプリミティブを、純粋な Pascal で実装しています。AES と ChaCha20/XChaCha20-Poly1305 による認証付き暗号化、SHA-2 と SHA-3、パスワードと鍵導出のための Argon2、scrypt、HKDF、Ed25519、Ed448、X25519、X448、secp256k1、RSA 鍵生成、X.509 証明書と CSR の生成、そしてポスト量子の ML-KEM、ML-DSA、SLH-DSA アルゴリズムです。

各プリミティブは単純な関数です。生成、設定、解放が必要なコンテキストオブジェクトはなく、実行ファイルと一緒に配布する DLL もありません。

uses
  sgcCrypto_Random, sgcCrypto_AES, sgcCrypto_Keccak, sgcCrypto_Ed25519,
  sgcCrypto_MLKEM;

var
  vKey, vIV, vPlain, vAAD, vTag, vCipher: TBytes;
  vDigest, vSeed, vSignature, vMessage: TBytes;
  vPublicKey, vPrivateKey, vSharedSecret, vCiphertext: TBytes;
begin
  // AES-256-GCM: authenticated encryption in one call
  vKey    := sgcRandomBytes(32);
  vIV     := sgcRandomBytes(12);
  vPlain  := TEncoding.UTF8.GetBytes('confidential payload');
  vCipher := sgcAES_GCM_Encrypt(vKey, vIV, vPlain, vAAD, vTag);

  // SHA-3-256, one call, no context object to manage
  vDigest := sgcSHA3_256(vPlain);

  // Ed25519: sign, then verify
  vSeed      := sgcRandomBytes(32);
  vMessage   := TEncoding.UTF8.GetBytes('sign me');
  vSignature := sgcEd25519_Sign(vSeed, vMessage);

  // ML-KEM-768: post-quantum key encapsulation (FIPS 203)
  sgcMLKEM_GenerateKeyPair(mlkem768, vPublicKey, vPrivateKey);
  sgcMLKEM_Encapsulate(mlkem768, vPublicKey, vCiphertext, vSharedSecret);
end;

5つの完全な sgcHTML アプリケーション

sgcHTML に4つのコンポーネントと5つのデモが加わります。コンポーネントは CameraScanner、ブラウザに内蔵されたスキャナーでバーコードと QR コードを読み取り、常に手入力のフォールバックも用意しているライブカメラパネルです。さらに NumPad、CommandPalette、EmptyState があります。

5つのデモは断片的なサンプルではありません。それぞれがサインイン、データベース、印刷可能なレポートを備えた完全なアプリケーションで、Demos\60.HTML\01.RunTime の下にあります。倉庫管理、POS、レポートポータル、マルチテナント SaaS のコントロールプレーン、フィールドサービスの配車です。

新しいヘルプトピック「Runtime vs Design-Time」も追加されました。コードで組み立てる代わりに VCL フォームにコンポーネントを配置して同じページを構築する方法を示すデモが付いています。

リバースプロキシ背後での実クライアントアドレス

nginx、Apache、あるいはクラウドのロードバランサーの背後にあるサーバーは、すべての接続でプロキシのアドレスを見ることになります。つまり、ブラックリスト、ホワイトリスト、GeoIP、そして独自のルールは、すべて誤ったクライアントを見ていたわけです。TsgcWebSocketFirewall の新しい ForwardedHeaders 設定は、プロキシが転送したアドレスを復元します。

この設計は意図的に疑い深くできています。X-Forwarded-For や X-Real-IP にあるアドレスは、接続そのものが TrustedProxies に登録されたアドレスから届いた場合にのみ信用されるため、クライアントが勝手にでっち上げることはできません。また、最も左のエントリはクライアントが提供したものなので、チェーンは右から、TrustedHops で指定されたプロキシの数だけさかのぼって読まれます。プロキシは異なる呼び出し元からのリクエストで1つの接続を使い回すため、解決はリクエストごとに実行されます。

uses
  sgcWebSocket;

begin
  oFirewall.ForwardedHeaders.Enabled := True;
  oFirewall.ForwardedHeaders.TrustedProxies.Add('10.0.0.0/8');
  oFirewall.ForwardedHeaders.TrustedProxies.Add('::1');
  oFirewall.ForwardedHeaders.TrustedHops := 1;

  oServer.Firewall := oFirewall;
end;

procedure TForm1.OnServerConnectHandler(Connection: TsgcWSConnection);
begin
  // Connection.IP is now the end client
  // Connection.PeerIP is still the proxy that opened the socket
end;

いったん解決されると、そのアドレスが、すべてのブラックリストエントリ、すべてのカスタムルール、すべてのイベント、そしてご自身のハンドラコードから見えるアドレスになります。この設定は http.sys サーバーでも Indy サーバーでも同じように動作し、同じ機能が sgcSign Server にも server.firewall.forwarded_headers として追加されます。

測定できるバックプレッシャー

遅いクライアントに対して、そのクライアントが読み取るより速く書き込むと、送信キューはどこかが破綻するまで膨らみ続けます。アプリケーションの内部からそれが起きていることを知る方法がなかったため、中継処理は安全を確保するためだけに、通信路上でストップアンドウェイトのやり取りをする羽目になっていました。

2つの追加機能がそれを置き換えます。TsgcWSConnection の PendingCount は、その接続について3つの優先度レベル全体でまだキューに残っているメッセージ数を報告します。読み取り時にメモリを一切割り当てないため、ポーリングできます。OnQueueDrained は、接続のキューがメッセージを保持した状態から空になったときに、接続スレッド上で、キューが空になった直後、次の読み取りの前に発生します。そのため、まったく遅延なくクレジットを渡せます。

procedure TForm1.OnQueueDrainedHandler(Connection: TsgcWSConnection);
begin
  // raised on the connection thread: do not touch the user interface here
  SendNextBatch(Connection);
end;

procedure TForm1.SendIfRoom(Connection: TsgcWSConnection; const aText: string);
begin
  if Connection.PendingCount < 100 then
    Connection.WriteData(aText);
end;

どちらも DLL の境界を越えるため、.NET ラッパーや sgcWebSockets.dll を利用する他のホストでも使えます。新しいエクスポートは末尾に追加されているので、既存のエクスポート順序は変わりません。

EPOLL エンジンと IOCP エンジン

高性能エンジンには、1つの原因から生じる一群の不具合がありました。リクエストが1回のソケット読み取りで到着すると想定していたのです。これはループバックのテストでは正しくても、MTU の境界、VPN 経由、あるいは大きなボディが複数のパケットに分割される場合には成り立ちません。

全体が到着しなかったリクエストは、応答なしで接続を閉じて破棄されていました。また、2つの TCP セグメントに分割された TLS レコードは、接続をそのまま切断していました。どちらも修正され、新しい PartialRequestTimeout オプションが、サーバーが残りを待つ時間に上限を設けます。これは別のスレッドプールで動作するため、遅いクライアントが他のクライアントを妨げることはありません。EPOLL エンジンでは、クライアントが接続を閉じたあともサーバー側の接続が解放されないままだったため、OnDisconnect が発生せず、すべてのブロードキャストが死んだ接続に書き込み続けていました。

これが WorkOpThreads の意味が変わった理由でもあります。リクエストの残りを待っている接続が、同じスレッド上の他のすべての接続を止めてしまっていたため、接続を1つのスレッドに固定しなくなりました。現在は、常に準備しておくワーカーの最小数を指定するもので、プールはそこから拡張されます。

QUIC と HTTP/3

QUIC と HTTP/3 のクライアントおよびサーバーが IPv6 に対応しました。コロンを含むアドレスは IPv6 として扱われ、URL では角かっこで囲んで指定でき、ホスト名は両方のファミリーで解決されます。以前は IPv4 しか試されていませんでした。ホストを設定していない HTTP/3 リスナーは、1つのソケットで両方のファミリーに対応し、HTTP3Options の新しい Host プロパティで、必要に応じて1つのインターフェイスに固定できます。

より大きな変更は、HTTP/3 のリクエストが HTTP/1.1 のリクエストと同じ経路をたどるようになったことです。OpenAPI、MCP、REST API の各サーバー、リクエスト転送、CORS、マルチテナンシー、メトリクスは、このトランスポートが独自の経路を持っていたために、HTTP/3 ではまったく応答していませんでした。これらはすべて動作するようになりました。

HTTP/3 の証明書検証は、二度読んでいただきたい項目です。TsgcHTTP3Client では TLSOptions.VerifyCertificate が既定で True であり、チェックは実行されていましたが、その結果は破棄されていました。そのため、すべての HTTP/3 クライアントは、どの認証局が発行したものであれ、どのホスト向けであれ、あらゆる証明書を受け入れていました。現在はチェック結果が適用されるので、自己署名のエンドポイントと通信する HTTP/3 クライアントは、トラストストアか証明書を正しく設定するまで接続できなくなります。

取引所 API クライアント

すぐに使える取引所クライアントには、はるかに不可解な症状として現れる再接続の問題がありました。プライベートなサブスクリプション、つまり注文、残高、約定のフィードが、Bitstamp、Coinbase、Deribit、Huobi、Kraken のスポットと先物、Kucoin、MEXC、ThreeCommas で、再接続後に一度も再登録されていませんでした。コンポーネントは再接続を成功として報告する一方で、これらのフィードは何も告げずに失われていました。BitMEX、Bitfinex、Crypto.com、Deribit、Kraken 先物では、再登録が認証の前に実行されており、これも機能しません。有効期間の短い認証情報を含むフレームは、そのまま再送されるのではなく、再登録の時点で新しい認証情報を使って組み立て直されるようになりました。

金額は署名される前に丸められていました。固定の小数点以下8桁のマスクによって、0.000000004 のような数量がゼロになり、システムのロケールによっては、値が指数表記やカンマ区切りで送信されることもありました。Binance、Bybit、Cex、Cryptohopper、Kucoin、MEXC、ThreeCommas では、値が損失なく、通常の10進表記で、ピリオドを使って書き出されるようになりました。

同じ領域の新機能としては、v1 に加えて Kraken WebSocket v2 コンポーネント、内部で2つめの接続を開いて1つのインスタンスでパブリックデータとプライベートデータを同時に扱う Huobi クライアント、時計がずれているホスト向けの Binance の UseServerTimeOffset、そして、大量のサブスクリプションが取引所のレート制限に引っかかるのを防ぎ、再接続時の再登録をバックグラウンドワーカーに移す2つのスロットルオプション PaceBatch と AsyncResubscribe があります。

sgcWebSockets .NET 2026.9.0

.NET ライブラリは Delphi 版に追随します。OnQueueDrained と PendingCount が同じ意味で追加され、あわせて Throttle.AsyncResubscribe、Cryptohopper クライアントの AllowUnsignedWebhooks、そして新しい OnBinanceUserStreamSubscribed イベントも追加されました。これにより、ユーザーデータストリームの準備完了をプロパティのポーリングで調べる必要はなくなりました。

上に挙げた取引所の再接続と署名に関する修正はすべてここにも適用され、削除された機能も同様です。AppRTC プロトコル、RTCMultiConnection API、Flash フォールバックのクラスはなくなり、その結果 TwsTransport の番号が振り直されます。トランスポートの数値を保存したり送信したりしていたコードは、見直しが必要です。

取り上げておくべきリークが2つあります。クライアントがまだ接続されたまま解放された WebSocket API コンポーネントが、メッセージハンドラのたどるリストから自身を削除していなかった件と、コンポーネントを破棄するたびにハートビートタイマーのスレッドが2つリークしていた件です。後者が、正常終了のはずが時折エラーになっていた理由です。

sgcSign 2026.9.0

このリリースの大半はお客様からのご要望から生まれたもので、内容は3つの領域にまたがります。これから署名に使う証明書がどれなのかを把握すること、10年後も検証ツールに受け入れられる署名を構築すること、そして署名をそれ自身以外のものに照らして検証することです。

選択できる証明書リスト

証明書の列挙は、これまで表示名を返すだけでした。コンボボックスを埋めるには十分でも、判断を下すには不十分です。同じ認証局が同じ人物に発行した2枚のカードは、そのリストでは見分けがつきません。列挙結果には、SHA-1 のサムプリント、納税者識別番号、シリアル番号、発行者、有効期間が含まれるようになり、Windows 証明書ストア、PKCS#11 トークン、PFX ファイルのいずれでも同じ形で取得できます。

uses
  sgcSign_KeyProvider_WinCertStore, sgcSign_X509, sgcSign_Types;

var
  oProvider: TsgcWindowsCertStoreProvider;
  oList: TsgcX509CertificateList;
  i: Integer;
begin
  oProvider := TsgcWindowsCertStoreProvider.Create(nil);
  Try
    // only certificates that are still valid and hold a private key
    oList := oProvider.EnumerateCertificateList([cfNotExpired, cfPrivateKey]);
    Try
      for i := 0 to oList.Count - 1 do
        Memo1.Lines.Add(Format('%s | %s | %s .. %s | %s',
          [oList[i].Subject, oList[i].SerialNumber,
           DateToStr(oList[i].NotBefore), DateToStr(oList[i].NotAfter),
           oList[i].Thumbprint]));

      // and sign with exactly the one that was chosen
      oProvider.SelectCertificateByThumbprint(oList[0].Thumbprint);
    Finally
      oList.Free;
    End;
  Finally
    oProvider.Free;
  End;
end;

複数スロットの PKCS#11 カードは、別々の PIN の背後に別々の証明書を置くポーランドの適格署名カードでよく見られますが、PIN をまったく使わずに内容を一覧できるようになりました。EnumerateCertificateListAllSlots はすべてのスロットを読み取り、各エントリがどこから来たのかを記録します。TokenSlotCount は、実際にトークンが入っているスロットの数を報告します。

証明書自体も、パーサーがこれまで認識していた7つの属性だけでなく、保持しているすべての情報を報告するようになりました。郵便住所は読みやすい行にデコードされ、どの属性も OID で取得できます。

検証可能であり続ける署名

PAdES に2つのプロファイルが追加されました。spPAdESBasicT は埋め込みタイムスタンプ付きで失効情報なしの署名を行い、spPAdESDocumentArchive は長期保存プロファイルの上にアーカイブタイムスタンプを追加して、失効情報を含む文書全体を対象とします。これにより、最初のタイムスタンプ自体の有効期間が過ぎたあとも、ファイルは検証可能なまま保たれます。

ほとんどの適格署名カードには自分自身の証明書しか入っていないため、発行元の証明書を見つけるのは、これまで利用者側の課題でした。新しい GetIssuerCertificate と GetCertificateChain の呼び出しは、署名に使う証明書を発行した証明書と、その上のパス全体を見つけます。照合は名前ではなく暗号的に行われるため、署名鍵を変更した認証局が、その前身と取り違えられることはありません。IssuerLookup がどこを検索するかを決めます。既定では Windows 証明書ストア、同梱した PEM または DER ファイル、あるいは証明書内に記載されたアドレスで、最後のものは既定でオフです。

タイムスタンプ要求に署名できるようになりました。これは一部の適格認証局、特にポーランドの認証局が要求するものです。RequestFormat を trfCMS に設定し、鍵プロバイダを割り当ててください。OnBeforeSendRequest と OnAfterReceiveResponse が、送受信された正確なバイト列を渡します。

トラストアンカーによる検証

これは注意して読んでいただきたい変更です。これまで検証機能は、検査対象の文書から署名証明書を取り出し、その鍵がその文書に署名したことを確認していました。これで証明できるのは、文書を書いた者がその中の署名も書いた、ということだけです。

新しい TrustedCertificates と TrustedCertificateStore プロパティで、どのルートを信頼するかを指定し、RequireTrustedChain、CheckKeyUsage、RequireCompleteRevocationCheck で結果の厳格さを決めます。アンカーの照合は、SHA-256 のサムプリント、またはそのアンカー自身の鍵での検証によって行われ、名前で照合されることはありません。アンカーを設定していない検証機能は以前と同じ判定を返しますが、ETSI TS 119 102-2 のレポートは、アンカーまでチェーンが構築されていない署名に対して total-passed とは報告しなくなりました。そのため、アンカーなしで作成して保存したレポートは、作り直す必要があります。

Authenticode 署名は、signtool /ac と同じように、追加の証明書を埋め込めるようになりました。これにより、カーネルモードドライバの署名を、クロス証明書を経由して Microsoft Code Verification Root までチェーンさせることができます。

プロキシに対応した共通の HTTP トランスポート

ライブラリが行うすべてのリクエストは、共通の HTTPOptions プロパティを持つ1つのトランスポートを通るようになりました。タイムスタンプクライアント、OCSP と失効リストのクライアント、EU トラストリストのダウンロード、クラウド鍵プロバイダのすべてです。このトランスポートが扱うのは、プロキシ（システムのもの、なし、明示的なアドレス、あるいはマシンがアドレスごとに解決するもの）、プロキシが要求する場合の資格情報、クライアント証明書、受け入れる最も低い TLS バージョン、そしてユーザーエージェントです。すべての設定は、これらのリクエストが以前行っていたとおりの動作が既定値になっており、これらの設定では表現できないゲートウェイのために、新しい OnHTTPRequest イベントがトランスポートを完全に置き換えます。

署名サーバー

API キーと、それを作成するユーザーがプロジェクトごとに分離されるようになり、プロジェクト管理者は、他のプロジェクトのキーを見ることなく、自分のプロジェクトのキーを管理できます。キーは一方向に失効させるだけでなく、有効化と無効化ができるようになり、レート制限と1日あたりのクォータは作成後に編集でき、監査ログは、コンソールでも CSV エクスポートでも、ようやくクライアントアドレスで絞り込めるようになりました。

Authenticode 署名は、それぞれ異なる証明書を使った3つ以上の入れ子署名を保持できるようになりました。これは、有効期限が近づいた証明書とその後継証明書の両方で署名した1つのファイルを配布する際に必要になるものです。Windows のカタログファイルにも署名できるようになり、新しい /api/v1/sign/raw エンドポイントは、すでに計算済みのダイジェストに署名して署名値だけを返します。これは signtool が /dlib コールバックを通じて要求するものそのものです。渡されたダイジェストなら何でも署名してしまうため、既定ではオフで、プロバイダごとに個別に有効化します。

サーバーの既定値のいくつかが、正当な理由で変更されました。server.listen の設定は、指定したアドレスに実際にバインドするようになりました。管理操作にはワンタイムトークンを伴うフォームの POST が必要になり、HTTPS 経由の Webhook 配信は、送信先アドレスの証明書を検証します。この3つはすべてアップグレードの注意事項に記載しています。

sgcIndy 2026.9.0

小規模なリリースですが、含まれる項目はどれも価値のある修正です。

ALPN で合意したプロトコル名が、OpenSSL がその長さのために確保している1バイトに対して4バイトで書き込まれていたため、プロトコルをネゴシエートしたハンドシェイクはすべて、その隣のメモリを上書きしていました。IOCP または EPOLL エンジン上の TLS サーバーは、相手側が再ネゴシエーションを要求したときに、OpenSSL がすでに用意していたデータを送信せずに書き込みを何度も再試行し、1スレッド分の CPU を使い切っていました。Linux では、書き込み中に相手側が接続をリセットすると、TLS アプリケーションがオペレーティングシステムによって終了させられていました。OpenSSL の書き込み方法では、broken pipe シグナルの抑制をシステムに要求できないためです。FPC と Lazarus における同じ問題も修正されており、まだ影響が残っていた macOS のサーバー側で受け入れた接続も含まれます。

Community 版のセットアップでは、プリコンパイル済みの Delphi 13 バイナリが Delphi 12 のプロジェクトから生成されていたため、Delphi 13 のインストーラが想定する 370 の名前ではなく 290 の名前が付いており、Windows ARM64EC はまったくビルドされていませんでした。Delphi 13 は、サポートされるすべてのプラットフォームについて、自身のプロジェクトをビルドするようになりました。

sgcOpenAPI 2026.9.0

パーサーが黙って失敗することはなくなりました。すべてのドキュメントは Warnings リストとともに返されるようになり、そこには、openapi や info メンバーの欠落、JSON の型が誤っているメンバー、生成できなかった操作、解決できないパスアイテム参照、読み取られてはいるがまだ反映されていない JSON Schema キーワードが記録されます。

uses
  sgcOpenAPI_Classes, sgcOpenAPI_Parser_Client_Pascal;

var
  oParser: TsgcOpenAPI_Parser_Client_Pascal;
  i: Integer;
begin
  oParser := TsgcOpenAPI_Parser_Client_Pascal.Create;
  Try
    oParser.OpenAPIClassName := 'TPetStoreClient';
    oParser.OutputFileName := 'PetStoreClient.pas';

    oParser.ReadFromFile('petstore.json');

    for i := 0 to oParser.Warnings.Count - 1 do
      Memo1.Lines.Add('warning: ' + oParser.Warnings[i]);

    oParser.SaveToFile('PetStoreClient.pas');
  Finally
    oParser.Free;
  End;
end;

また、読み込んでいる仕様のバージョンを認識するため、3.0 のドキュメントと 3.1 のドキュメントが同じものとして扱われることはなくなりました。exclusiveMinimum と exclusiveMaximum が分かりやすい例です。OpenAPI 3.1 の webhooks、jsonSchemaDialect、components.pathItems、ライセンス識別子、mutualTLS セキュリティスキーム、["string","null"] のように配列として宣言された型、真偽値として宣言されたスキーマがすべてサポートされ、OpenAPI 3.2 の query 操作と additionalOperations マップも同様です。

コード生成は、これまで諦めていた箇所で改善されました。インラインのオブジェクトスキーマは、文字列に格下げされる代わりに独自のクラスを生成するようになり、items は完全なスキーマとして読み取られ、生成されたクライアントは cookie パラメータと、パラメータのシリアライズ規則一式、つまり matrix、label、simple、form、spaceDelimited、pipeDelimited、deepObject を explode および allowReserved 付きでサポートします。

コマンドラインがようやくビルドスクリプトで使えるようになりました。終了コードを設定し、成功は 0、各種の失敗は 1 から 7 を返します。エラーは常に標準エラー出力に送られます。新しい -r スイッチは、YAML または Swagger 2.0 のドキュメントを公開コンバーターを通じて変換します。既定ではオフです。

同じ OpenAPI の改善は sgcWebSockets にも搭載されており、サーバー側のバリデーターは、ValidateHeaderParams、ValidateCookieParams、EnforceRequired によって、ヘッダーと cookie のパラメータも検証するようになりました。

アップグレードの前に

今回はすべての製品に破壊的変更があります。以下は、影響を受ける可能性が最も高いものです。

それぞれの理由を添えた完全な一覧は、各製品の変更履歴に記載しています。

入手方法

リリース 2026.9.0 は、完全なソースコードと1年間のアップデート付きで、Delphi 7 から Delphi 13 Florence まで、対応する C++ Builder の各バージョン、そして .NET 向けに、現在提供されています。

sgcWebSockets · sgcWebRTC · sgcCrypto · sgcHTML · sgcSign · sgcIndy · sgcOpenAPI

トライアル版をダウンロード · 変更履歴

ご質問やご意見はありませんか？ お問い合わせください。コードを書いた本人から返信が届きます。