想要深入理解ORB的工作過程與原理，學(xué)習(xí)與了解GIOP消息格式必不可少。我們知道GIOP是獨(dú)立于具體通信的更高級(jí)別的抽象，因此這里針對(duì)GIOP在TCP/IP上的實(shí)現(xiàn)IIOP協(xié)議進(jìn)行學(xué)習(xí)與分析（IIOP是規(guī)范中要求所有的ORB廠商都必要實(shí)現(xiàn)的協(xié)議，因此GIOP規(guī)范中也對(duì)IIOP協(xié)議進(jìn)行了具體的定義）。

根據(jù)CORBA Specification的相關(guān)闡述，GIOP規(guī)范主要包括了以下三個(gè)方面：

1、Common Data Representation(CDR) definition（公共數(shù)據(jù)表達(dá)定義），CDR定義了IDL數(shù)據(jù)類型序列化為底層的byte流的規(guī)范。

2、GIOP Message Formats（GIOP消息格式），GIOP消息是ORB之間的通信最小單元。GIOP消息的類型有對(duì)象請(qǐng)求，對(duì)象定位和通信連接管理等等。

3、GIOP Transport Assumptions（GIOP傳輸層注意項(xiàng)，不知道這里翻譯成”注意項(xiàng)“是否合適）。GIOP規(guī)范描述了一些底層協(xié)議的實(shí)現(xiàn)在傳輸GIOP消息時(shí)需要關(guān)注的事項(xiàng)，GIOP給出了一些假設(shè)/建議，另外規(guī)范還描述了應(yīng)該如何去管理連接（建立與斷開），保證GIOP消息順序等等。

通常情況下我們并不會(huì)去關(guān)注第三點(diǎn)。

好了，我們一點(diǎn)一點(diǎn)學(xué)習(xí)以上三點(diǎn)（大部分情況下我只是作為規(guī)范的搬運(yùn)工而已）。

Common Data Representation(CDR)：

CDR描述了IDL數(shù)據(jù)類型應(yīng)該如何序列化。包括了以下幾點(diǎn)：

1、Byte Ordering，也就是我們所說的大端小端，這里不多陳述大端小端的知識(shí)了，讀者如有不懂可以自行baidu/google之。每個(gè)GIOP消息/Encapsulation（Encapsulation的闡述請(qǐng)點(diǎn)這里）都包含了一個(gè)用于標(biāo)識(shí)大小端的標(biāo)識(shí)。

2、Aligned Primitive Types基本類型（如int, short, string)的對(duì)齊，就像我們?cè)赾/c++接觸到的內(nèi)存對(duì)齊情況一樣，如此可以使得我們更快地序列化/反序列化消息。

3、Complete OMG IDL Mapping完整的IDL類型映射：CDR描述了所有IDL類型的底層表示，除了基本類型以外，還包括了可以傳輸?shù)膒seudo-object（偽對(duì)象）比如TypeCodes（用于在DII和Any中表示參數(shù)的類型信息），Object Reference和異常等等（說它們是偽對(duì)象，是因?yàn)樗鼈儾⒉皇钦鎸?shí)的對(duì)象，而是對(duì)象的另一種表達(dá)，比如Object Reference可以用來傳送一個(gè)對(duì)象，但Object Reference只是一個(gè)IOR）。

首先來看一下第二點(diǎn)，基本類型的序列化。

首先在邊界對(duì)齊上，數(shù)據(jù)類型必須對(duì)齊到它的大小的倍數(shù)的位置上。比如依次序列化下面的struct：

module alignmenttest{struct TestStruct{short sa;short sb;char ca;char cb;long la; } } octet index-------------------01 short sa-------------------23 short sb-------------------4 char ca-------------------5 char cb-------------------67-------------------8910 long la11-------------------

這與我們的C語言在大部分機(jī)器的上的內(nèi)存對(duì)齊規(guī)則是一致的。因此GIOP甚至可以不經(jīng)過任何處理直接搬到內(nèi)存中去就可以操作，使用。

Encapsulation

這里不知道怎么去翻譯這個(gè)詞，也許用”封裝“比較合適吧，它就像是我們C語言中的struct，java中的class，代表一個(gè)集合，并且可以相互嵌套。GIOP規(guī)范這里所指的Encapsulation，還有以下兩個(gè)含義：

1、Encapsulation與Encapsulation，Message之間的Byte Ordering可以是不相同的，即使它們之間是嵌套關(guān)系。

2、Encapsulation是一個(gè)抽象的表示，通常具體地它將會(huì)被編碼成sequence<octet>，編碼成sequence<octet>時(shí)，第一個(gè)octet代表著Byte Ordering。

Value Types

valuetype類似于一個(gè)加強(qiáng)版本的struct，但valuetype支持繼承并且可以定義本地方法（包括構(gòu)造函數(shù)）等而struct不支持，詳細(xì)請(qǐng)看CORBA規(guī)范的說明。基于上面這些特性，在傳輸valuetype時(shí)候，需要包含valuetype的基類信息以便客戶端進(jìn)行向上轉(zhuǎn)類等操作。在進(jìn)行序列化的時(shí)候，需要首先序列化基類的元素，再序列化子類的元素。valuetype支持自定義序列化，但客戶端和服務(wù)端的一致性由用戶自己保證。需要注意的是，valuetype中的方法是作用于本地的，它并不會(huì)像interface中的方法論一樣被傳遞到遠(yuǎn)程Servant。

Pseudo-Object Types 偽對(duì)象類型

這里主要說一下TypeCode，關(guān)于Object Reference的說明在后面IIOP消息中會(huì)有說明。TypeCode的作用上面已經(jīng)提到，這里再重復(fù)一遍，TypeCode提供了一塊數(shù)據(jù)中各個(gè)成員的信息，一般在確定動(dòng)態(tài)類型Any的時(shí)候會(huì)用到。比如：

module...{interface...{void add(in long a, n long b, Any c);} }

在運(yùn)行時(shí)Any c的具體類型才可以得知，那么在傳輸c的時(shí)候，需要附上c的序列化結(jié)構(gòu)信息，服務(wù)端才能正確地反序列化/還原c，我們可以看一下Any類型的序列化過程相關(guān)代碼:

public class CDROutputStream_1_0 extends CDROutputStreamBase {....public void write_any(Any any) {if (any == null) {throw wrapper.nullParam();}write_TypeCode(any.type());//首先寫出TypeCode信息any.write_value(parent);//寫出值信息。}.... }

下面是寫出TypeCode信息的相關(guān)代碼，它根據(jù)當(dāng)前any類型的_kind來寫出相對(duì)應(yīng)的信息。比如對(duì)應(yīng)于struct類型，那么寫出的TypeCode信息將包括struct中每個(gè)成員的類型信息，這可能是為了應(yīng)對(duì)IDL在客戶端與服務(wù)端不致的問題。

public final class TypeCodeImpl extends TypeCode {....public void write_value(TypeCodeOutputStream tcos) {...TypeCodeOutputStream topStream = tcos.getTopLevelStream();if (_kind == tk_indirect) {// The encoding used for indirection is the same as that used for recursive ,// TypeCodes i.e., a 0xffffffff indirection marker followed by a long offset// (in units of octets) from the beginning of the long offset.int pos = topStream.getPositionForID(_id);int topPos = tcos.getTopLevelPosition();tcos.writeIndirection(tk_indirect, pos);return;}tcos.write_long(_kind);// Bug fix 5034649:// Do this AFTER the write of the _kind in case the alignment// for the long changes the position.topStream.addIDAtPosition(_id, tcos.getTopLevelPosition()-4);switch (typeTable[_kind]) {case EMPTY:// nothing more to marshalbreak;case SIMPLE:switch (_kind) {case TCKind._tk_string:case TCKind._tk_wstring:// marshal the bound on string length tcos.write_long(_length);break;case TCKind._tk_fixed:tcos.write_ushort(_digits);tcos.write_short(_scale);break;default:// unknown typecode kindthrow wrapper.invalidSimpleTypecode() ;}break;case COMPLEX:TypeCodeOutputStream _encap = tcos.createEncapsulation(tcos.orb());switch(_kind) {case TCKind._tk_objref:case TCKind._tk_abstract_interface:_encap.write_string(_id);_encap.write_string(_name);break;case TCKind._tk_union:_encap.write_string(_id);_encap.write_string(_name);_discriminator.write_value(_encap);_encap.write_long(_defaultIndex);_encap.write_long(_memberCount);for (int i=0; i < _memberCount; i++) {if (i == _defaultIndex) {_encap.write_octet(_unionLabels[i].extract_octet());} else {switch (realType(_discriminator).kind().value()) {case TCKind._tk_short:_encap.write_short(_unionLabels[i].extract_short());break;case TCKind._tk_long:_encap.write_long(_unionLabels[i].extract_long());break;case TCKind._tk_ushort:_encap.write_short(_unionLabels[i].extract_ushort());break;case TCKind._tk_ulong:_encap.write_long(_unionLabels[i].extract_ulong());break;case TCKind._tk_float:_encap.write_float(_unionLabels[i].extract_float());break;case TCKind._tk_double:_encap.write_double(_unionLabels[i].extract_double());break;case TCKind._tk_boolean:_encap.write_boolean(_unionLabels[i].extract_boolean());break;case TCKind._tk_char:_encap.write_char(_unionLabels[i].extract_char());break;case TCKind._tk_enum:_encap.write_long(_unionLabels[i].extract_long());break;case TCKind._tk_longlong:_encap.write_longlong(_unionLabels[i].extract_longlong());break;case TCKind._tk_ulonglong:_encap.write_longlong(_unionLabels[i].extract_ulonglong());break;case TCKind._tk_wchar:_encap.write_wchar(_unionLabels[i].extract_wchar());break;default:throw wrapper.invalidComplexTypecode() ;}}_encap.write_string(_memberNames[i]);_memberTypes[i].write_value(_encap);}break;case TCKind._tk_enum:_encap.write_string(_id);_encap.write_string(_name);_encap.write_long(_memberCount);for (int i=0; i < _memberCount; i++) {_encap.write_string(_memberNames[i]);}break;case TCKind._tk_sequence:lazy_content_type().write_value(_encap);_encap.write_long(_length);break;case TCKind._tk_array:_contentType.write_value(_encap);_encap.write_long(_length);break;case TCKind._tk_alias:case TCKind._tk_value_box:_encap.write_string(_id);_encap.write_string(_name);_contentType.write_value(_encap);break;case TCKind._tk_struct:case TCKind._tk_except:_encap.write_string(_id);_encap.write_string(_name);_encap.write_long(_memberCount);for (int i=0; i < _memberCount; i++) {_encap.write_string(_memberNames[i]);_memberTypes[i].write_value(_encap);}break;case TCKind._tk_value:_encap.write_string(_id);_encap.write_string(_name);_encap.write_short(_type_modifier);if (_concrete_base == null) {_orb.get_primitive_tc(TCKind._tk_null).write_value(_encap);} else {_concrete_base.write_value(_encap);}_encap.write_long(_memberCount);for (int i=0; i < _memberCount; i++) {_encap.write_string(_memberNames[i]);_memberTypes[i].write_value(_encap);_encap.write_short(_memberAccess[i]);}break;default:throw wrapper.invalidTypecodeKindMarshal() ;}// marshal the encapsulation _encap.writeOctetSequenceTo(tcos);break;}}... }

Object Reference，對(duì)象引用

傳送對(duì)象引用一般情況下傳送它的IOR就可以了，IOR至少包含了以下信息：

1、版本信息，以保證低版本的ORB不會(huì)亂去解析高版本的IOR表示。

2、傳輸層面對(duì)象宿主機(jī)器的地址。

3、對(duì)象ID，用于唯一定位目標(biāo)對(duì)象 。

Abstract Interface，抽象接口

Abstract Interface是一種比較特殊的類型，它是一個(gè)方法集合，interface和valuetype類型可以繼承它，比如：

abstract interface Describable { string get_description(); }; interface Example { void display (in Describable anObject); }; interface Account : Describable {// passed by reference // add Account methods here }; valuetype Currency supports Describable {// passed by value // add Currency methods here };

如上面，如果在運(yùn)行時(shí)anObject參數(shù)是Account，那么在序列化的時(shí)候，首先用一個(gè)boolean為true的值以表明它是一個(gè)Object Reference，然后緊接著這個(gè)對(duì)象的IOR。

---------------TRUE ---------------IOR ---------------

如果在運(yùn)行時(shí)anObject參數(shù)是Currency，那么在序列化的時(shí)候，首先用一個(gè)boolean為false值以表明它是一個(gè)valuetype，然后緊接著它的值。

---------------FALSE ---------------Value ---------------

GIOP消息格式

首先我們來看一下GIOP消息的IDL聲明：

module GIOP { // IDL extended for version 1.1 and 1.2 struct Version {octet major;octet minor;};#ifndef GIOP_1_1// GIOP 1.0enum MsgType_1_0 { // Renamed from MsgType Request, Reply, CancelRequest,LocateRequest, LocateReply,CloseConnection, MessageError};#else// GIOP 1.1enum MsgType_1_1 {Request, Reply, CancelRequest,LocateRequest, LocateReply,CloseConnection, MessageError,Fragment// GIOP 1.1 addition };#endif // GIOP_1_1// GIOP 1.0struct MessageHeader_1_0 { // Renamed from MessageHeaderchar magic [4];Version GIOP_version;boolean byte_order;octet message_type;unsigned long message_size;};// GIOP 1.1 struct MessageHeader_1_1 {char magic [4];Version GIOP_version;octet flags;// GIOP 1.1 change octet message_type;unsigned long message_size;};// GIOP 1.2 typedef MessageHeader_1_1 MessageHeader_1_2; };

magic表明這是一個(gè)GIOP消息，它的值為字符串GIOP的byte："GIOP".getBytes("ISO8859-1")

GIOP_Version包含這個(gè)消息所使用的GIOP協(xié)議的版本信息，需要注意的是，它和IIOP版本號(hào)是兩碼事，雖然它們的IDL描述是一樣的

byte_order只在GIOP 1.0版本中被使用，它指定后面元素如message_size（比如占據(jù)4個(gè)字節(jié)整形）是大端表示還是小端表示的。

flags在GIOP 1.1和1.2版本中使用，它和byte_ordfer一樣都只占據(jù)一個(gè)字節(jié)，只不過flag中用bit表示一些信息：

|7|6|5|4|3|2|1|0|| | | | | | | || | | | | | | ->byte order, 0: big-endian, 1: little-endian| | | | | | ---->后面是否還有fragments, 0: No, 1: Yes---------------->保留

message_type，它的值表明了消息的類型，下面是消息類型的列表。

Message TypeOriginatorValueGIOP Versions

Request	Client	0	1.0, 1.1, 1.2
Reply	Server	1	1.0, 1.1, 1.2
CancleRequest	Client	2	1.0, 1.1, 1.2
LocateRequest	Client	3	1.0, 1.1, 1.2
LocateReply	Server	4	1.0, 1.1, 1.2
CloseConnection	Server	5	1.0, 1.1, 1.2
MessageError	Both	6	1.0, 1.1, 1.2
Fragment	Both	7	1.1, 1.2

message_size表明消息頭后面的還有多個(gè)字節(jié) （消息體Message Body的長度，不包括12個(gè)字節(jié)的消息頭），這是一個(gè)unsigned long類型，它的字節(jié)順序與上面byte_order域與flags域所指定的字節(jié)順序是一致的。注意對(duì)于GIOP1.2，message_size + 12（消息頭長度）的和一定需要可以被8整除（也許為了內(nèi)存對(duì)齊）。

下面介紹一下消息類型，因?yàn)槠?#xff0c;這里只對(duì)Request Message和Reply Message介紹。

Request Message

Request Header的IDL定義：

module GIOP { // IDL extended for version 1.1 and 1.2// GIOP 1.0struct RequestHeader_1_0 { // Renamed from RequestHeader IOP::ServiceContextListservice_context;unsigned long request_id;boolean response_expected;sequence <octet> object_key;string operation;Principal requesting_principal;};// GIOP 1.1 struct RequestHeader_1_1 {IOP::ServiceContextList service_contextunsigned long request_id;octet reserved[3];sequence<octet> object_key;string operation;Principal requesting_principal;};// GIOP 1.2typedef short AddressingDisposition;const short KeyAddr=0;const short ProfileAddr=1;const short ReferenceAddr=2;struct IORAddressingInfo {unsigned long selected_profile_index;IOP::IOR ior;};union TargetAddress switch (AddressingDisposition) {case KeyAddr: sequence<octet> object_key;case ProfileAddr: IOP::TaggedProfile profile;case ReferenceAddr: IORAddressingInfo ior;};struct RequestHeader_1_2 {unsigned long request_id;octet response_flags;octet reserved[3];TargetAddress target;string operation;IOP::ServiceContextList service_context;// Principal not in GIOP 1.2 }; };

request_id用于將服務(wù)器的響應(yīng)信息與客戶端發(fā)送的請(qǐng)求信息對(duì)應(yīng)起來，因?yàn)榭蛻舳说耐瑫r(shí)可能向服務(wù)端發(fā)送多個(gè)對(duì)象的請(qǐng)求，而它們可以共用一個(gè)連接，服務(wù)器返回的信息將包含客戶端發(fā)送的request_id，客戶端利用request_id來完成響應(yīng)信息的分發(fā)。

response_flags用于表示此請(qǐng)求是否需要返回值，它的最低位是1的話表示需要返回值，如何需要返回值，并且在DII中INV_NO_RESPONSE標(biāo)志位沒有被設(shè)置，那么response_flags必須設(shè)置為0x03。

如果此請(qǐng)求不需要返回值，或者在DII調(diào)用中設(shè)置了INV_NO_RESPONSE標(biāo)志位，那么response_flags可以設(shè)置為0x00或者0x01

reserved的值應(yīng)該設(shè)置為，它為未來保留使用。

object_key，在GIOP 1.0和1.1中，用于標(biāo)識(shí)服務(wù)端的目標(biāo)對(duì)象，它其實(shí)就是IOR IIOPProfile中的object_key的值。

target，但從GIOP 1.2開始，更換為使用target域來標(biāo)識(shí)調(diào)用的目標(biāo)。

operation是idl中定義的interface中的目標(biāo)方法名。

service_context包含了從客戶端傳遞到服務(wù)端的Service Context信息。

requesting_principal，在GIOP 1.0和GIOP 1.1版本中，它包含了關(guān)于客戶端身份信息的類，用于訪問控制和其它目的。在它已經(jīng)被棄用，并且在GIOP 1.2中不再包含這部分信息。

Request Body

在GIOP 1.0和1.1中，Request Body被序列化成Encapsulation并立即被附在消息頭的后面。從GIOP 1.2開始，Request Body的開始位置是對(duì)齊到8字節(jié)的，如果消息頭被修改之后，Request Body不需要重新序列化。Request包括了以下幾項(xiàng)內(nèi)容（按順序序列化）：

1、所有的in和inout參數(shù)，按照它們?cè)诜椒▍?shù)中出現(xiàn)的先后順序（從左到右）。

2、可選的Context pseudo object（Context偽對(duì)象），這些Context pseudo object被序列化成sequence<String>，每個(gè)Context pseudo object被序列化成一對(duì)String，Property Name和Property Value。只有操作的IDL定義包含有一個(gè)Conext Expression的情況下才會(huì)出現(xiàn)Context pseudo object，并且只會(huì)包含Context Expression中聲明的成員。

比如下面方法的

double example(in short m, out string str, inout p)

它的Request Body的將會(huì)是下面的結(jié)構(gòu)：

struct example_body{short m;long p; }

Reply Message

只有Request Message中的response expected位被設(shè)置為TRUE的情況下，服務(wù)器才會(huì)發(fā)送對(duì)應(yīng)的Reply Message。Reply Message包括了所有的inout和out參數(shù)，并且可以包含有異常值。同樣Reply Message包括了Reply Header和Reply Body兩部分。

Reply Header

首先來看一下它的IDL定義：

module GIOP { // IDL extended for 1.2 #ifndef GIOP_1_2// GIOP 1.0 and 1.1enum ReplyStatusType_1_0 { // Renamed from ReplyStatusType NO_EXCEPTION,USER_EXCEPTION,SYSTEM_EXCEPTION,LOCATION_FORWARD};// GIOP 1.0struct ReplyHeader_1_0 { // Renamed from ReplyHeader IOP::ServiceContextList service_context;unsigned long request_id;ReplyStatusType_1_0 reply_status;};// GIOP 1.1 typedef ReplyHeader_1_0 ReplyHeader_1_1;// Same Header contents for 1.0 and 1.1 #else// GIOP 1.2enum ReplyStatusType_1_2 {NO_EXCEPTION,USER_EXCEPTION,SYSTEM_EXCEPTION,LOCATION_FORWARD,LOCATION_FORWARD_PERM,// new value for 1.2NEEDS_ADDRESSING_MODE // new value for 1.2 };struct ReplyHeader_1_2 {unsigned long request_id;ReplyStatusType_1_2 reply_status;IOP:ServiceContextList service_context}; #endif // GIOP_1_2 };

request_id用于把Reply Message與對(duì)應(yīng)的Request Message關(guān)聯(lián)起來，并不是每個(gè)對(duì)象的請(qǐng)求會(huì)單獨(dú)占用整個(gè)連接，多個(gè)對(duì)象的請(qǐng)求可以通過單個(gè)連接發(fā)送到服務(wù)端。Reply Message中的request_id與對(duì)應(yīng)的Request Message中的request_id的值是一致的。

reply_status用于表示對(duì)應(yīng)請(qǐng)求的完成狀態(tài)和Reply Body的內(nèi)容 ，如何方法請(qǐng)求調(diào)用成功完成，那么它的值是NO_EXCEPTION，并且Reply Body中包含返回值。否則Reply Body中的內(nèi)容將會(huì)是：

1、異常值。

2、要求客戶端重發(fā)請(qǐng)求到另一個(gè)服務(wù)端地址上的對(duì)象。

3、要求客戶端提供更多用于定位對(duì)象的信息。

service_context包含了服務(wù)端發(fā)送給客戶端的ORB service信息

?Reply Body

和Request Body一樣，在GIOP 1.0和1.1中，Reply Header緊接著就是Reply Body。從GIOP 1.2開始，Reply Body的起始位置需要對(duì)齊到8字節(jié)。Reply Body的內(nèi)容由Reply Header中的reply_status的值決定：

如果reply_status的值為NO_EXCEPTION，那么Reply Body首先序列化返回值，然后是IDL方法定義中的out和inout參數(shù)（從左到右順序），如下面方法

double example(in short m, out string str, inout long p)

那么該方法請(qǐng)求在NO_EXCEPTION的情況下的返回值為：

struct{return double;string str;
long p; }

如果reply_status為USER_EXCEPTION或者SYSTEM_EXCEPTION的話，那么reply body包含方法拋出的異常值。

當(dāng)reply_status為SYSTEM_EXCEPTION，那么reply body的結(jié)構(gòu)如下：

module GIOP { // IDL struct SystemExceptionReplyBody {string exception_id;unsigned long minor_code_value;unsigned long completion_status;}; };

minor_code_value的高20位表示廠商Minor Codeset ID（VMCID），低12位表示minor code。一些廠商（可以是多個(gè)）可能想定義一些特有的異常MInor code，那么它們應(yīng)該向OMG去申請(qǐng)這個(gè)VMCID。注意OMG標(biāo)準(zhǔn)的VMCID為0x4f4d0（'O', 'M'）。

如果reply_status的值為LOCATION_FORWARD的話，那么Reply Body包含了一個(gè)對(duì)象的IOR，然后客戶端ORB負(fù)責(zé)將原來的請(qǐng)求重新發(fā)送到這個(gè)IOR指定的對(duì)象上，這個(gè)過程對(duì)于客戶端應(yīng)用程序是透明的（客戶端并不能知道這些過程）。

如果replay_status的值為LOCATION_FORWARD_PERM，它的行為表現(xiàn)和LOCATION_FORWARD幾乎是一樣的，另外它被服務(wù)器用來向客戶端表明 ，它可能要將當(dāng)前對(duì)象的IOR替換成新的，并且新的IOR和舊的還是有效的，但推薦使用新的。

如果reply_status的值為NEED_ADDRESSING_MODE的話，Reply Body包括了一個(gè)GIOP::AddressingDisposition，客戶端負(fù)責(zé)使用request addressing mode(提供更多對(duì)象信息)重新發(fā)送請(qǐng)求到這個(gè)對(duì)象上。同樣的，重發(fā)過程對(duì)于用于程序是透明的，ORB并不會(huì)通知客戶端的程序這個(gè)過程。

completion_state根據(jù)Standard Exception Definitions的IDL定義，它有COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE三種狀態(tài)。

轉(zhuǎn)載于:https://www.cnblogs.com/mosmith/p/5196100.html

總結(jié)

以上是生活随笔為你收集整理的CORBA GIOP消息格式学习的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。