MS Office 2010 + SharePoint 2010のコラボレーションメカニズム：プロトコルとパッケージ
共著メカニズムは、MS Office 2010およびSharePoint 2010のリリースで登場しました。多くの人々は、登場した機能を「待望の」と呼んでいますが、実際、その使いやすさを軽視する意味はありません。 しかし、この記事では、このメカニズムがどのように機能し、どのような利点が得られるかについて説明します。 最後のアクティビティの新しいフィールド！
まず、共著者メカニズムの動作がどのように見えるかに注意を払う必要があります。 インターネットの広大さを調べてみると、彼らはすでにこれを十分に詳細に行っていたことがわかったので、繰り返しはせず、 慣れ親しむことをお勧めします。
ユーザーアクションがこのプロセスで生成されるパッケージにどのように関連するかを理解することは、私にとって興味深いことでした。 転送されたパケットに対するアクションを識別する方法を学びます。 これにより、HTTPモジュールを記述することにより、企業ポータルでユーザー（および私の場合は従業員）の作業に関する情報を収集できます。 このような情報は、たとえば、変換の数を増やしたり、ドキュメントの準備に関する作業の強度を追跡したりするのに役立ちます。 さらに、実際には、送信パケットよりもサーバーに入るパケットをリッスンする方が効率的で安全であることが示されています。
ドキュメントのキャッシュにより、MS-FSSHTTPプロトコルのレベルの情報がユーザーのアクションをあいまいに決定する場合があるため、タスクは複雑になります。 たとえば、ドキュメントを開くイベントが初めて発生したとき、ドキュメントはダウンロードされ、パッケージの説明から簡単に判断できます。ドキュメントを2回目に開いたとき、ドキュメントはダウンロードされませんが、キャッシュでは、開かれたときにサーバー上のドキュメントと比較されますが、これらの2つのイベントは意味的にはドキュメントでの作業の開始を意味します。
共著者メカニズムは、Word 2010、Excel 2010、OneNote 2010、SharePoint Workspace 2010 with SharePoint Foundation 2010またはSharePoint Server 2010で正常に機能します。これは仕様に示されています。
SharePointサーバーとMS Office 2010ユーザーの間のすべての通信は、MS-FSSHTTP（SOAP over HTTPプロトコル仕様によるファイル同期）およびMS-FSSHTTPB（SOAPプロトコル仕様によるファイル同期のバイナリ要求）プロトコルを使用して行われます。
便宜上、プロトコルの説明へのリンクをすぐに提供します。
-MS-FSSHTTPに関するMSDNまたはMS-FSSHTTP仕様のダウンロード
-MS-FSSHTTPBに関するMSDNまたはMS-FSSHTTPB仕様のダウンロード
パケットを交換する場合、MS-FSSHTTPプロトコルは、作業を開始するエンティティ（そのUrl）、エンティティでの作業を開始する作成者、および動作モードに関する情報を送信します（読み取り専用と編集には異なる特権が必要です）。 パッケージのMS-FSSHTTP部分はXMLであり、このプロトコルに猶予を追加しません。 パッケージ内のXMLサブディビジョンには、SubRequestTokenパラメーターによって番号が付けられます。 DependsOnパラメーターを使用して、パッケージの整合性を確認することが可能になります。 MS-FSSHTTPおよびMS-FSSHTTPBプロトコル内のエンティティは、セルと呼ばれます。
MS-FSSHTTP要求の構造は、次のパターンに適合します。
MS-FSSHTTPプロトコルの構造に関するいくつかの説明：
ユーザーからサーバーへのパケットのMS-FSSHTTP部分の例（要求）：
パッケージは、ドキュメント2MB.docxが指定されたアドレスでアクセスされており、ユーザーがドキュメントを受信する準備ができていることを報告します。 BinaryDataSizeは、タグ内の値の長さ、つまり MS-FSSHTTPBパーツ。
仕様を検討したところ、ドキュメントの作業の開始を判断する方法についての答えは見つかりませんでした。 したがって、さまざまな種類およびサイズのドキュメントを含むパッケージの分析中に識別された兆候を確認し、クラッシュテストを手配する必要があります。そうでない場合、兆候を真と呼ぶことは難しく、作業は正当化されます。 したがって、従来使用されていたすべての形式は、最大30Mbのドキュメントサイズで分析されました。
分析の結果：
MS-FSSHTTPBプロトコルに精通する時が来ました。 データはBase64エンコーディングで表示されます。構造を決定するには、HEXおよびバイナリコードに変換する必要があります。 さらに、88に等しいBinaryDataSizeは、「空の」MS-FSSHTTPB部分であり、クリーンなMS-FSSHTTPB要求テンプレートです。 MS-FSSHTTPB要求のすべてのセクションが含まれていますが、セクションには情報がありません。
2つのプロトコル間での役割の分散について話す場合、MS-FSSHTTPはドキュメントの外部に表示される情報、つまり ファイルを開かなくてもわかるすべてのこと。MS-FSSHTTPBは、ドキュメント内で何が起こっているか、どのような変更が行われたか、ドキュメントのどの場所で行われたかを通知します。 したがって、パッケージのMS-FSSHTTPB部分にエンコードされた情報により、共同作成者からのドキュメントのステータスを同期し、ドキュメントの変更された部分のみを送信できるため、ネットワークの負荷が大幅に軽減されます。 確かに、私の観点から見ると、別の実装は論理的ではありません。
MS-FSSHTTBプロトコルで送信される文字列について考えてみましょう。BinaryDataSizeは88です。
MS-FSSHTTPプロトコルのXMLタグの元の値：
デコードされたHEXコード（MS-FSSHTTPB仕様p。71-73を参照）：
現在、MS-FSSHTTPBの新しい反復と分析が、以前に実行された分析に追加されています。 読者から退屈な例の喜びを奪い、分析の結果をもたらします。
わかりやすくするために、このようなパッケージを解析する例を示します。
HEXデコードコード：
セルの知識範囲の内容を解析するのはそれほど簡単ではありません（37ページのMS-FSSHTTPB仕様を参照）。 変数FROMに渡されるコードの一部として繰り返しデータ+ GUIDバンドルを選択しましたが、チェックされるファイルのサイズが小さいパッケージには必ずしも存在しないため、このデザインはサインとは見なされません。 この設計のセマンティクスに関しては、同様の設計が応答パッケージに記載されています。 要求パッケージが応答からの構成を使用する理由を説明しようとすることができますが、これらの構造の説明が要求要求仕様に記述されていない理由を説明するのは困難です。 次に、変数FROMと変数TOで囲まれたデータに注目しましょう。 これは、コーナーストーンが存在する場所です。つまり、単語「7b 00」と「b5 13」の間にコンテンツが正規表現「\ w {2} [00]」に収まりますが、スペースは読みやすさを高めるためにのみ設定されることを忘れないでください。 この症状は、文書を使用したすべてのテストで証明されています。 やれやれ！ しかし、そのようなデザインのセマンティクスを止めて侵入しようとすることはできません。 経験豊富な開発者は、UTF-16（16進数）でエンコードされたデータがこの形式で表示されることに気付くでしょう。 在庫の変換
UTF-16（16進数）では
その結果、検討中の構造ではパラメーターが送信されます。GUIDと2つの数値パラメーター。構造を意味のあるものにし、開発者がそのセマンティクスを理解しようとすることさえできます。 GUIDを使用して、キャッシュされたドキュメントの有効性をチェックすると仮定できます。 このバージョンは、可能なすべての批判に耐え、非常に成功しているようです！
この記事では、プロトコルレベルでMS Office 2010 + SharePoint 2010の共著メカニズムを強調してみました。 うまくいけば、プロトコル仕様でカバーされておらず、以前は注目されていなかったいくつかの機能を明確に説明できたと思います。 MS-FSSHTTPおよびMS-FSSHTTPBプロトコルの動作に関する個人的な調査が終了してから、MSDNのドキュメントは実質的に補足されていることに注意してください。
一般に、共著者の仕事は、Unixベースのシステムでのドキュメントの編集に関する仕事の基本原則に非常に似ています。 違いは、共著者メカニズムを革新的と呼ぶほど重要ではありません。 この考えでこの記事を終えたいと思います。
興味深い研究をお祈りします！
この記事のソースコードは、 ソースコードハイライターで強調表示されました。
興味深いユーザー
まず、共著者メカニズムの動作がどのように見えるかに注意を払う必要があります。 インターネットの広大さを調べてみると、彼らはすでにこれを十分に詳細に行っていたことがわかったので、繰り返しはせず、 慣れ親しむことをお勧めします。
開発者にとって興味深い
ユーザーアクションがこのプロセスで生成されるパッケージにどのように関連するかを理解することは、私にとって興味深いことでした。 転送されたパケットに対するアクションを識別する方法を学びます。 これにより、HTTPモジュールを記述することにより、企業ポータルでユーザー（および私の場合は従業員）の作業に関する情報を収集できます。 このような情報は、たとえば、変換の数を増やしたり、ドキュメントの準備に関する作業の強度を追跡したりするのに役立ちます。 さらに、実際には、送信パケットよりもサーバーに入るパケットをリッスンする方が効率的で安全であることが示されています。
ドキュメントのキャッシュにより、MS-FSSHTTPプロトコルのレベルの情報がユーザーのアクションをあいまいに決定する場合があるため、タスクは複雑になります。 たとえば、ドキュメントを開くイベントが初めて発生したとき、ドキュメントはダウンロードされ、パッケージの説明から簡単に判断できます。ドキュメントを2回目に開いたとき、ドキュメントはダウンロードされませんが、キャッシュでは、開かれたときにサーバー上のドキュメントと比較されますが、これらの2つのイベントは意味的にはドキュメントでの作業の開始を意味します。
共著者メカニズムは、Word 2010、Excel 2010、OneNote 2010、SharePoint Workspace 2010 with SharePoint Foundation 2010またはSharePoint Server 2010で正常に機能します。これは仕様に示されています。
プロトコルとパッケージ
SharePointサーバーとMS Office 2010ユーザーの間のすべての通信は、MS-FSSHTTP（SOAP over HTTPプロトコル仕様によるファイル同期）およびMS-FSSHTTPB（SOAPプロトコル仕様によるファイル同期のバイナリ要求）プロトコルを使用して行われます。
便宜上、プロトコルの説明へのリンクをすぐに提供します。
-MS-FSSHTTPに関するMSDNまたはMS-FSSHTTP仕様のダウンロード
-MS-FSSHTTPBに関するMSDNまたはMS-FSSHTTPB仕様のダウンロード
パケットを交換する場合、MS-FSSHTTPプロトコルは、作業を開始するエンティティ（そのUrl）、エンティティでの作業を開始する作成者、および動作モードに関する情報を送信します（読み取り専用と編集には異なる特権が必要です）。 パッケージのMS-FSSHTTP部分はXMLであり、このプロトコルに猶予を追加しません。 パッケージ内のXMLサブディビジョンには、SubRequestTokenパラメーターによって番号が付けられます。 DependsOnパラメーターを使用して、パッケージの整合性を確認することが可能になります。 MS-FSSHTTPおよびMS-FSSHTTPBプロトコル内のエンティティは、セルと呼ばれます。
MS-FSSHTTP要求の構造は、次のパターンに適合します。
< s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" >
< s:Body >
< RequestVersion … > //
< RequestCollection … > // CorrelationID, guid
// .
< Request … > // URL
< SubRequest … /> //
</ SubRequest >
…
</ Request >
</ RequestCollection >
</ s:Body >
</ s:Envelope >
MS-FSSHTTPプロトコルの構造に関するいくつかの説明：
-要求の宛先となるドキュメントを示すプロトコルパッケージの必須構造。< Request Url ="http://serverName/documentFullPath" RequestToken ="1" >
-共著者モードのアナウンス、添付タグは、どのタイプの共著者が使用されているかを示します。< SubRequest Type ="Coauth" SubRequestToken ="1" >
-ネストされたタグ内のドキュメントロックとそのタイプの存在を示します。 応答として、サーバーは、最初にドキュメントを使用して作業を開始するか、共著者として参加するかを示します。< SubRequest Type ="SchemaLock" SubRequestToken ="2" DependsOn ="1" DependencyType ="OnNotSupported" >
-ドキュメントの変更に関する直接情報を伝達します。 パッケージのMS-FSSHTTPB部分が含まれています。< SubRequest Type ="Cell" SubRequestToken ="3" >
-ユーザー情報。< SubRequest Type ="WhoAmI" SubRequestToken ="2" />
ユーザーからサーバーへのパケットのMS-FSSHTTP部分の例（要求）：
パッケージは、ドキュメント2MB.docxが指定されたアドレスでアクセスされており、ユーザーがドキュメントを受信する準備ができていることを報告します。 BinaryDataSizeは、タグ内の値の長さ、つまり MS-FSSHTTPBパーツ。
< s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" >
< s:Body >
< RequestVersion Version ="2" MinorVersion ="0" xmlns ="http://schemas.microsoft.com/sharepoint/soap/" />
< RequestCollection CorrelationId ="{010F340A-ACB5-442C-B11E-95CB877EEBA5}" xmlns ="http://schemas.microsoft.com/sharepoint/soap/" >
< Request Url ="http://moss14/Something/2MB.docx" RequestToken ="1" >
< SubRequest Type ="Cell" SubRequestToken ="1" >
< SubRequestData PartitionID ="383adc0b-e66e-4438-95e6-e39ef9720122" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
< SubRequest Type ="WhoAmI" SubRequestToken ="2" />
< SubRequest Type ="Cell" SubRequestToken ="3" >
< SubRequestData PartitionID ="7808f4dd-2385-49d6-b7ce-37aca5e43602" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
< SubRequest Type ="ServerTime" SubRequestToken ="4" />
< SubRequest Type ="Cell" SubRequestToken ="5" >
< SubRequestData GetFileProps ="true" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
</ Request >
</ RequestCollection >
</ s:Body >
</ s:Envelope >
パッケージ調査
仕様を検討したところ、ドキュメントの作業の開始を判断する方法についての答えは見つかりませんでした。 したがって、さまざまな種類およびサイズのドキュメントを含むパッケージの分析中に識別された兆候を確認し、クラッシュテストを手配する必要があります。そうでない場合、兆候を真と呼ぶことは難しく、作業は正当化されます。 したがって、従来使用されていたすべての形式は、最大30Mbのドキュメントサイズで分析されました。
分析の結果：
- 最大パケットサイズは3 MBを超えません。つまり、10パケットに対して30 MBのファイルが転送されます。
- MS-FSSHTTPを分析することによってのみ、ドキュメントのオープンを決定する問題を解決することは不可能です（キャッシュ機能を備えたアップロードセンターの操作のため）、残りのアクションが決定されます。
- MS-FSSHTTPパーツを含むパッケージにはmoss14 / _vti_bin / cellstorage.svc / CellStorageServiceでアクセスしますが、残りはこのタスクでは重要ではありません。 つまり、HTTP要求を分析するためのフィルターになります。
MS-FSSHTTPBプロトコルに精通する時が来ました。 データはBase64エンコーディングで表示されます。構造を決定するには、HEXおよびバイナリコードに変換する必要があります。 さらに、88に等しいBinaryDataSizeは、「空の」MS-FSSHTTPB部分であり、クリーンなMS-FSSHTTPB要求テンプレートです。 MS-FSSHTTPB要求のすべてのセクションが含まれていますが、セクションには情報がありません。
2つのプロトコル間での役割の分散について話す場合、MS-FSSHTTPはドキュメントの外部に表示される情報、つまり ファイルを開かなくてもわかるすべてのこと。MS-FSSHTTPBは、ドキュメント内で何が起こっているか、どのような変更が行われたか、ドキュメントのどの場所で行われたかを通知します。 したがって、パッケージのMS-FSSHTTPB部分にエンコードされた情報により、共同作成者からのドキュメントのステータスを同期し、ドキュメントの変更された部分のみを送信できるため、ネットワークの負荷が大幅に軽減されます。 確かに、私の観点から見ると、別の実装は論理的ではありません。
MS-FSSHTTBプロトコルで送信される文字列について考えてみましょう。BinaryDataSizeは88です。
MS-FSSHTTPプロトコルのXMLタグの元の値：
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAg<br>YAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
デコードされたHEXコード（MS-FSSHTTPB仕様p。71-73を参照）：
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + SubRequest Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
41 //Knowledge End
0b 01 ac 02 //SubRequest End + Data Element Packege Start
00 55 03 01 //Reversed + Data Emlement Packege End + Cell Request End
現在、MS-FSSHTTPBの新しい反復と分析が、以前に実行された分析に追加されています。 読者から退屈な例の喜びを奪い、分析の結果をもたらします。
- 1.空のパケットは、ドキュメントを受信する準備ができていることのシグナルです。つまり、サーバーからドキュメントを開くイベントを判断するのに役立ちます。 フィルタリング要求モジュールの重要な行は次のとおりです。
< SubRequestData GetFileProps ="true" BinaryDataSize ="88" >
ただし、ドキュメントがアップロードセンターにキャッシュされた場合、BinaryDataSizeは88を超えます。 文書の有効性を確認する必要があるため、空のテンプレートにはなりません。 そのようなケースを識別するために、別の機能が見つかりました。
- 2.アップロードセンターでキャッシュされたドキュメントをチェックするパッケージには、このリストのパラグラフ1で指定された行も含まれます。 ただし、BinaryDataSizeパラメーターの値が大きいほど、アップロードセンターからチェックされるドキュメントが大きくなります。
わかりやすくするために、このようなパッケージを解析する例を示します。
< SubRequestData GetFileProps ="true" BinaryDataSize ="443" > DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+
9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQc
URJaGUekAZnpNpAB4KCn1koJCYUFHqgOvQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9r
j3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB4KCn1koJCYUFHqgOvQEOf2v0+
QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrGjv1Ojie167QDOAngmua8bdL
Ef8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMIdbAFw0Qz5C0E3b9GZRKbD
JyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQANwA0ADEALQBBAEEAMA
AzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAAAtRMBJgIgAA7pdjoy
gAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwGsAgBVAwE= </ SubRequestData >
HEXデコードコード：
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + SubRequest Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
\\ ,
26 02 20 00 //cell knowledge range
f6 35 7a 32 61 07 14 44 96 86 51 e9 00 66 7a 4d //GUID in cell knowlegde range
a4 00 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
c2 35 96 3d 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
ae 3d e2 3e 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
fa 3e 26 40 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
3e 40 6a 41 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
82 41 9e 42 78 26 46 50 e4 8b 4e e0 0e b1 a3 bf 53 a3 89 ed 7a ed 00
ce 02 78 26 //Pre DATA
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before FROM number
00 66 0f //FROM number
51 13 01 26 02 20 00 13 1f 09 10 82 c8 fb 40 98 86 65 33 f9 34 c2 1d 6c 01 70 d1 0c f9 0b 41 37 6f d1 99 44 a6 c3 27 23 2e dc a7 11 ad
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31 00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33 00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41 00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
b5 13 01 26 02 20 00 0e e9 76 3a 32 80 0c 4d b9 dd f3 c6 50 29 43 3e 4c 01 20 28 0c //DATA changeset
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before TO number
66 0f 00 //To number
a5 //Cell range End
13 01 //Cell End
//
41 //Knowledge End
0b 01 ac 02 //SubRequest End + Data Element Packege Start
00 55 03 //Reversed + Data Emlement Packege End + Cell Request End
セルの知識範囲の内容を解析するのはそれほど簡単ではありません（37ページのMS-FSSHTTPB仕様を参照）。 変数FROMに渡されるコードの一部として繰り返しデータ+ GUIDバンドルを選択しましたが、チェックされるファイルのサイズが小さいパッケージには必ずしも存在しないため、このデザインはサインとは見なされません。 この設計のセマンティクスに関しては、同様の設計が応答パッケージに記載されています。 要求パッケージが応答からの構成を使用する理由を説明しようとすることができますが、これらの構造の説明が要求要求仕様に記述されていない理由を説明するのは困難です。 次に、変数FROMと変数TOで囲まれたデータに注目しましょう。 これは、コーナーストーンが存在する場所です。つまり、単語「7b 00」と「b5 13」の間にコンテンツが正規表現「\ w {2} [00]」に収まりますが、スペースは読みやすさを高めるためにのみ設定されることを忘れないでください。 この症状は、文書を使用したすべてのテストで証明されています。 やれやれ！ しかし、そのようなデザインのセマンティクスを止めて侵入しようとすることはできません。 経験豊富な開発者は、UTF-16（16進数）でエンコードされたデータがこの形式で表示されることに気付くでしょう。 在庫の変換
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31 00 34 00 32 00 <br>2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33 00 2d 00 41 00 46 00 34 00 30 00 34 00 <br>33 00 39 00 46 00 44 00 41 00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
UTF-16（16進数）では
{8292f529-6142-4741-aa03-af40439fdafd},3,3
その結果、検討中の構造ではパラメーターが送信されます。GUIDと2つの数値パラメーター。構造を意味のあるものにし、開発者がそのセマンティクスを理解しようとすることさえできます。 GUIDを使用して、キャッシュされたドキュメントの有効性をチェックすると仮定できます。 このバージョンは、可能なすべての批判に耐え、非常に成功しているようです！
おわりに
この記事では、プロトコルレベルでMS Office 2010 + SharePoint 2010の共著メカニズムを強調してみました。 うまくいけば、プロトコル仕様でカバーされておらず、以前は注目されていなかったいくつかの機能を明確に説明できたと思います。 MS-FSSHTTPおよびMS-FSSHTTPBプロトコルの動作に関する個人的な調査が終了してから、MSDNのドキュメントは実質的に補足されていることに注意してください。
一般に、共著者の仕事は、Unixベースのシステムでのドキュメントの編集に関する仕事の基本原則に非常に似ています。 違いは、共著者メカニズムを革新的と呼ぶほど重要ではありません。 この考えでこの記事を終えたいと思います。
興味深い研究をお祈りします！
この記事のソースコードは、 ソースコードハイライターで強調表示されました。
All Articles