锘??xml version="1.0" encoding="utf-8" standalone="yes"?>
鏈榪戞棤鎰忎腑鍙戠幇錛屼綔鑰匱igerX鍘熸潵緋誨湴鐞冩潙涓浗閾訛紝嬈ц躲?br>鍦板潃錛歨ttp://www.codeproject.com/KB/tree/ctreelistctrl.aspx
榪樹互涓篶odeproject涓婃病鍏跺畠涓浗鍦熶漢鍛紝鍗庝漢鍊掓槸鐭ラ亾鏈夊ソ鍑犱釜銆?br>
淇轟篃鍦╟odeproject鍙戜簡綃囨枃绔狅紝璁瞲ml搴忓垪鍖栧鏉傚璞℃ā鍨嬬殑錛岄棬鍙綏闆鍟娿?br>http://www.codeproject.com/KB/cs/xmlable.aspx
鍡紝寰堟湁宸埆銆?br>
]]>
]]>
]]>
]]>
http://www.visualwebgui.com/
how did they do that?
]]>
鐪嬩簡鏍風珷錛屾病瑙夊緱鍝噷浣撶幇浜?#8220;楂樻晥”2瀛楋紝鍙槸浠栨帓閿欑殑鐜瀹炲湪鏄伓鍔o紝鍏跺疄嫻嬭瘯浜哄憳搴旇姣斿紑鍙戜漢鍛樼墰閫兼墠瀵癸紝浠g爜浜轟漢浼氬啓錛屾帓閿欎笉鏄漢浜鴻兘鍋氱殑錛岄渶瑕佺殑鐭ヨ瘑鍌ㄥ姣斿厜鍐欏啓浠g爜闇瑕佺殑澶氬緱澶氫簡銆?br>鏍風珷閲屼婦鐨勫伐浜哄垎閲戞潯鐨勪緥瀛愰鐩槸閿欑殑錛岃繕鐪嬪埌涓涓敊鍒瓧...浣嗕亢瀵硅繖縐嶆巿浜轟互娓旂殑鍐欐硶寰堟湁濂芥劅銆?br>
]]>
]]>
http://www.sqlite.org/
Light, Free, Fast, Cross platform.
witten in C, and there are a lot of wrappers, find what you need here: http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers
http://www.codeproject.com/KB/cpp/SQLite_Server.aspx
Implementing Server/Client architecture for that great SQLite! with visual studio C++ 2005
http://www.codeproject.com/KB/cs/InterprocessCommunicator.aspx
Interprocess Communication Between .NET and MFC using WM_COPYDATA
http://www.codeproject.com/KB/cs/WindowsServicesInAction1.aspx
http://www.codeproject.com/KB/cs/WindowsServicesInAction2.aspx
Windows Services in Action
Windows Services Hand by Hand...
http://www.codeproject.com/KB/cs/OpenS-CAD.aspx
OpenS-CAD, a simple 2D CAD application. <-- just so so
http://www.codeproject.com/KB/cs/DiskAnalyzer.aspx
I don't care about disk, i do care about the pie chart and tree gird view.
]]>
]]>
]]>
http://codeguru.earthweb.com/cpp/i-n/ieprogram/displayinginformation/article.php/c7273/
HTML Editor for VC++ 6.0
]]>
http://www.cs.man.ac.uk/~toby/alan/software/
]]>
http://blog.csdn.net/cpu88/archive/2004/11/26/195315.aspx
姝ラ錛?
//寰楀埌鎷奸煶錛堝寘鎷闊籌級
聽A:聽聽 鐢ㄨ緭鍏ユ硶鐢熸垚鍣?win2000)"C:\Program Files\Windows NT\Accessories\Imegen.exe"
聽聽聽聽聽聽 閫嗚漿鎹㈡嫾闊寵緭鍏ユ硶鏂囦歡C:\WINNT\SYSTEM32\WINPY.MB
聽聽聽聽聽 浼氱敓鎴愪竴涓狢:\WINNT\SYSTEM32\WINPY.txt鏂囦歡(綆縐?WINPY.txt鏂囦歡)
B:聽聽 WINPY.txt鏂囦歡閲岄潰鏄犅犅?姹夊瓧鎷奸煶鍒楄〃5涓囧鏉?闄ゅ幓璇嶇粍 鏈夋眽瀛?涓囧涓紙鍚闊籌級
C:聽聽 姹夊瓧鍙互杞崲鎴愭煇涓紪鐮佸彲浠ヨ嚜宸辨瀯閫犵紪鐮佹柟娉?淇濊瘉涓涓眽瀛楀搴斾竴涓紪鐮?綆縐扮紪鐮佹柟娉曪級
聽聽聽聽聽 濡?byte[] uniCode = new String(temp).getBytes(鈥淕B2312鈥?;
聽聽聽聽聽 灝哤INPY.txt閲岄潰鎵鏈夌殑姹夊瓧鍙樻垚緙栫爜銆傚緱鍒版眽瀛楃紪鐮?鎷奸煶瀵瑰簲琛紙綆縐版眽瀛楃紪鐮佽〃錛?br />聽聽聽聽聽聽聽 XXXX0,a聽聽聽 //XXXX0鏄煇涓眽瀛楃殑緙栫爜
聽聽聽聽聽聽聽 XXYX2,o聽聽聽 //XXYX2鏄煇涓眽瀛楃殑緙栫爜
聽D:聽 姹夊瓧緙栫爜琛ㄦ寜緙栫爜鎺掑簭錛岀紪鐮佽〃鎸夌紪鐮佸ぇ灝忔帓搴忋?br />聽聽聽聽聽 緙栫爜琛ㄥ垎緇勶紙鏂逛究鏌ヨ 錛?鑰屼笖寰楀埌鍒嗙粍鐨勬爣蹇椼?br />聽E: 鏌ヨ姹夊瓧鎷奸煶聽 灝嗘眽瀛楄繘琛岀紪鐮侊紙鎸夎嚜宸辯殑緙栫爜鏂規硶錛夈?br />聽聽聽聽聽 鐢ㄧ紪鐮佸湪緙栫爜琛ㄤ腑鏌ヨ灝卞彲浠ュ緱鍒版嫾闊籌紝鏌ヨ鏃跺湪緙栫爜琛ㄤ腑鐨勬煇涓垎緇勪腑鏌ヨ錛岃屼笉鏄湪鎵鏈夌紪鐮佷腑鏌ヨ銆傞熷害寰堝揩銆?br />//寰楀埌棣栧瓧絎?濡?鍖椾含'聽 寰楀埌 'bj'聽聽聽聽聽聽聽聽聽聽聽 '鍛嗗瓙'寰楀埌聽 'd[a]z '聽 //澶氶煶
//鎺掑簭聽 鏈変簡鎷奸煶 灝卞彲浠ユ寜涓浜涘父瑙佺殑鎺掑簭鏂規硶鎺掑簭
濡備綍鍦–++涓泦鎴怢ua鑴氭湰(LuaPlus綃?:
http://ly4cn.teeta.com/blog/data/44939.html
鎹鏃犳硶璋冪敤铏氬嚱鏁般傛湁鐐規檿銆傛湁絀哄啀鐪嬬湅銆?br />http://luaplus.org/
瀛楃涓插埌鍏朵粬鏍煎紡鐨勮漿鎹?
CString 聽 timestr 聽 = 聽 "2000騫?4鏈?5鏃?; 聽
聽 int 聽 a,b,c 聽 ; 聽
聽 sscanf(timestr.GetBuffer(timestr.GetLength()),"%d騫?d鏈?d鏃?,&a,&b,&c); 聽
聽 CTime 聽 time(a,b,c,0,0,0);聽聽
ANSI鍏煎錛屾垜澶闄嬪闂諱簡...
RMI for c++?:
http://www.codeproject.com/threads/RMI_For_Cpp.asp
鍙嶆鐩墠娌¤繖涓渶瑕併?br />
澹伴煶寮曟搸錛宎udiere錛屾敮鎸佽法騫沖彴:
浼間箮鎸轟笉閿欍?br />http://www.shnenglu.com/gogoplayer/archive/2006/11/29/15763.html
http://sourceforge.net/projects/audiere/
wxWidget鐨剋xSound鏀寔windows鍜寀nix銆?br />鍏跺畠鍏充簬sound:
http://www.opensound.com/oss.html
http://www.libsdl.org/
Why You Should Turn Down That Job Offer
Peer-to-peer software applications are a network administrator's nightmare. In order to be able to exchange packets with their counterpart as directly as possible they use subtle tricks to punch holes in firewalls, which shouldn't actually be letting in packets from the outside world.
Increasingly, computers are positioned behind firewalls to protect systems from internet threats. Ideally, the firewall function will be performed by a router, which also translates the PC's local network address to the public IP address (Network Address Translation, or NAT). This means an attacker cannot directly adress the PC from the outside - connections have to be established from the inside.This is of course a problem when two computers behind NAT firewalls require to talk directly to each other - if, for example, their users want to call each other using Voice over IP (VoIP). The dilemma is clear - whichever party calls the other, the recipient's firewall will decline the apparent attack and will simply discard the data packets. The telephone call doesn't happen. Or at least that's what a network administrator would expect.
But anyone who has used the popular internet telephony software Skype knows that it works as smoothly behind a NAT firewall as it does if the PC is connected directly to the internet. The reason for this is that the inventors of Skype and similar software have come up with a solution.
Naturally every firewall must also let packets through into the local network - after all the user wants to view websites, read e-mails, etc. The firewall must therefore forward the relevant data packets from outside, to the workstation computer on the LAN. However it only does so, when it is convinced that a packet represents the response to an outgoing data packet. A NAT router therefore keeps tables of which internal computer has communicated with which external computer and which ports the two have used.
The trick used by VoIP software consists of persuading the firewall that a connection has been established, to which it should allocate subsequent incoming data packets. The fact that audio data for VoIP is sent using the connectionless UDP protocol acts to Skype's advantage. In contrast to TCP, which includes additional connection information in each packet, with UDP, a firewall sees only the addresses and ports of the source and destination systems. If, for an incoming UDP packet, these match an NAT table entry, it will pass the packet on to an internal computer with a clear conscience.
The switching server, with which both ends of a call are in constant contact, plays an important role when establishing a connection using Skype. This occurs via a TCP connection, which the clients themselves establish. The Skype server therefore always knows under what address a Skype user is currently available on the internet. Where possible the actual telephone connections do not run via the Skype server; rather, the clients exchange data directly.
Let's assume that Alice wants to call her friend
Bob. Her Skype client tells the Skype server that she
wants to do so. The Skype server already knows a bit
about Alice. From the incoming query it sees that Alice
is currently registered at the IP address 1.1.1.1 and a
quick test reveals that her audio data always comes
from UDP port 1414. The Skype server passes this
information on to Bob's Skype client, which, according
to its database, is currently registered at the IP
address 2.2.2.2 and which, by preference uses UDP port
2828.
Bob's Skype program then punches a hole in its own network firewall: It sends a UDP packet to 1.1.1.1 port 1414. This is discarded by Alice's firewall, but Bob's firewall doesn't know that. It now thinks that anything which comes from 1.1.1.1 port 1414 and is addressed to Bob's IP address 2.2.2.2 and port 2828 is legitimate - it must be the response to the query which has just been sent.
Now the Skype server passes Bob's coordinates on to Alice, whose Skype application attempts to contact Bob at 2.2.2.2:2828. Bob's firewall sees the recognised sender address and passes the apparent response on to Bob's PC - and his Skype phone rings.
This description is of course somewhat simplified - the details depend on the specific properties of the firewalls used. But it corresponds in principle to our observations of the process of establishing a connection between two Skype clients, each of which was behind a Linux firewall. The firewalls were configured with NAT for a LAN and permitted outgoing UDP traffic.
Linux' NAT functions have the VoIP friendly property of, at least initially, not changing the ports of outgoing packets. The NAT router merely replaces the private, local IP address with its own address - the UDP source port selected by Skype is retained. Only when multiple clients on the local network use the same source port does the NAT router stick its oar in and reset the port to a previously unused value. This is because each set of two IP addresses and ports must be able to be unambiguously assigned to a connection between two computers at all times. The router will subsequently have to reconstruct the internal IP address of the original sender from the response packet's destination port.
Other NAT routers will try to assign ports in a specific range, for example ports from 30,000 onwards, and translate UDP port 1414, if possible, to 31414. This is, of course, no problem for Skype - the procedure described above continues to work in a similar manner without limitations.
It becomes a little more complicated if a firewall
simply assigns ports in sequence, like Check Point's
FireWall-1: the first connection is assigned 30001,
the next 30002, etc. The Skype server knows that Bob is
talking to it from port 31234, but the connection to
Alice will run via a different port. But even here
Skype is able to outwit the firewall. It simply runs
through the ports above 31234 in sequence, hoping at
some point to stumble on the right one. But if this
doesn't work first go, Skype doesn't give up. Bob's
Skype opens a new connection to the Skype server, the
source port of which is then used for a further
sequence of probes.
Nevertheless, in very active networks Alice may not find the correct, open port. The same also applies for a particular type of firewall, which assigns every new connection to a random source port. The Skype server is then unable to tell Alice where to look for a suitable hole in Bob's firewall.
However, even then, Skype doesn't give up. In such cases a Skype server is then used as a relay. It accepts incoming connections from both Alice and Bob and relays the packets onwards. This solution is always possible, as long as the firewall permits outgoing UDP traffic. It involves, however, an additional load on the infrastructure, because all audio data has to run through Skype's servers. The extended packet transmission times can also result in an unpleasant delay.
Use of the procedure described above is not limited to Skype and is known as "UDP hole punching". Other network services such as the Hamachi gaming VPN application, which relies on peer-to-peer communication between computers behind firewalls, use similar procedures. A more developed form has even made it to the rank of a standard - RFC 3489 "Simple Traversal of UDP through NAT" (STUN) describes a protocol which with two STUN clients can get around the restrictions of NAT with the help of a STUN server in many cases. The draft Traversal Using Relay NAT (TURN) protocol describes a possible standard for relay servers.
With a few small utilities, you can try out UDP hole punching for yourself. The tools required, hping2 and netcat, can be found in most Linux distributions. Local is a computer behind a Linux firewall (local-fw) with a stateful firewall which only permits outgoing (UDP) connections. For simplicity, in our test the test computer remote was connected directly to the internet with no firewall.
Firstly start a UDP listener on UDP port 14141 on the local/1 console behind the firewall:
local/1# nc -u -l -p 14141
An external computer "remote" then attempts to contact it.
remote# echo "hello" | nc -p 53 -u local-fw 14141
However, as expected nothing is received on local/1 and, thanks to the firewall, nothing is returned to remote. Now on a second console, local/2, hping2, our universal tool for generating IP packets, punches a hole in the firewall:
local/2# hping2 -c 1 -2 -s 14141 -p 53 remote
As long as remote is behaving itself, it will send back a "port unreachable" response via ICMP - however this is of no consequence. On the second attempt
remote# echo "hello" | nc -p 53 -u local-fw 14141
the netcat listener on console local/1 then coughs up a "hello" - the UDP packet from outside has passed through the firewall and arrived at the computer behind it.
Network administrators who do not appreciate this sort of hole in their firewall and are worried about abuse, are left with only one option - they have to block outgoing UDP traffic, or limit it to essential individual cases. UDP is not required for normal internet communication anyway - the web, e-mail and suchlike all use TCP. Streaming protocols may, however, encounter problems, as they often use UDP because of the reduced overhead.
Astonishingly, hole punching also works with TCP. After an outgoing SYN packet the firewall / NAT router will forward incoming packets with suitable IP addresses and ports to the LAN even if they fail to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at least, clearly fail to evaluate this information consistently. Establishing a TCP connection in this way is, however, not quite so simple, because Alice does not have the sequence number sent in Bob's first packet. The packet containing this information was discarded by her firewall.銆銆涓轟究浜庣悊瑙e拰璁板繂錛屽厛浠庝竴浜涙蹇靛叆鎵嬶紝鎵鏈夌壒孌婂瓧絎︽垨瀛楃緇勫悎鏈変竴涓昏〃鍦ㄥ悗闈紝鏈鍚庝竴浜涗緥瀛愪緵鐞嗚В鐩稿簲鐨勬蹇點?/p>
瀛楃 | 鍚箟 |
\cx | 鍖歸厤鐢眡鎸囨槑鐨勬帶鍒跺瓧絎︺備緥濡傦紝 \cM 鍖歸厤涓涓?Control-M 鎴栧洖杞︾銆倄 鐨勫煎繀欏諱負 A-Z 鎴?a-z 涔嬩竴銆傚惁鍒欙紝灝?c 瑙嗕負涓涓師涔夌殑 'c' 瀛楃銆?/td> |
\f | 鍖歸厤涓涓崲欏電銆傜瓑浠蜂簬 \x0c 鍜?\cL銆?/td> |
\n | 鍖歸厤涓涓崲琛岀銆傜瓑浠蜂簬 \x0a 鍜?\cJ銆?/td> |
\r | 鍖歸厤涓涓洖杞︾銆傜瓑浠蜂簬 \x0d 鍜?\cM銆?/td> |
\s | 鍖歸厤浠諱綍絀虹櫧瀛楃錛屽寘鎷┖鏍箋佸埗琛ㄧ銆佹崲欏電絳夌瓑銆傜瓑浠蜂簬 [ \f\n\r\t\v]銆?/td> |
\S | 鍖歸厤浠諱綍闈炵┖鐧藉瓧絎︺傜瓑浠蜂簬 [^ \f\n\r\t\v]銆?/td> |
\t | 鍖歸厤涓涓埗琛ㄧ銆傜瓑浠蜂簬 \x09 鍜?\cI銆?/td> |
\v | 鍖歸厤涓涓瀭鐩村埗琛ㄧ銆傜瓑浠蜂簬 \x0b 鍜?\cK銆?/td> |
鐗瑰埆瀛楃 | 璇存槑 |
$ | 鍖歸厤杈撳叆瀛楃涓茬殑緇撳熬浣嶇疆銆傚鏋滆緗簡 RegExp 瀵硅薄鐨?Multiline 灞炴э紝鍒?$ 涔熷尮閰?'\n' 鎴?'\r'銆傝鍖歸厤 $ 瀛楃鏈韓錛岃浣跨敤 \$銆?/td> |
( ) | 鏍囪涓涓瓙琛ㄨ揪寮忕殑寮濮嬪拰緇撴潫浣嶇疆銆傚瓙琛ㄨ揪寮忓彲浠ヨ幏鍙栦緵浠ュ悗浣跨敤銆傝鍖歸厤榪欎簺瀛楃錛岃浣跨敤 \( 鍜?\)銆?/td> |
* | 鍖歸厤鍓嶉潰鐨勫瓙琛ㄨ揪寮忛浂嬈℃垨澶氭銆傝鍖歸厤 * 瀛楃錛岃浣跨敤 \*銆?/td> |
+ | 鍖歸厤鍓嶉潰鐨勫瓙琛ㄨ揪寮忎竴嬈℃垨澶氭銆傝鍖歸厤 + 瀛楃錛岃浣跨敤 \+銆?/td> |
. | 鍖歸厤闄ゆ崲琛岀 \n涔嬪鐨勪換浣曞崟瀛楃銆傝鍖歸厤 .錛岃浣跨敤 \銆?/td> |
[ | 鏍囪涓涓腑鎷彿琛ㄨ揪寮忕殑寮濮嬨傝鍖歸厤 [錛岃浣跨敤 \[銆?/td> |
? | 鍖歸厤鍓嶉潰鐨勫瓙琛ㄨ揪寮忛浂嬈℃垨涓嬈★紝鎴栨寚鏄庝竴涓潪璐┆闄愬畾絎︺傝鍖歸厤 ? 瀛楃錛岃浣跨敤 \?銆?/td> |
\ | |
^ | 鍖歸厤杈撳叆瀛楃涓茬殑寮濮嬩綅緗紝闄ら潪鍦ㄦ柟鎷彿琛ㄨ揪寮忎腑浣跨敤錛屾鏃跺畠琛ㄧず涓嶆帴鍙楄瀛楃闆嗗悎銆傝鍖歸厤 ^ 瀛楃鏈韓錛岃浣跨敤 \^銆?/td> |
{ | 鏍囪闄愬畾絎﹁〃杈懼紡鐨勫紑濮嬨傝鍖歸厤 {錛岃浣跨敤 \{銆?/td> |
| | 鎸囨槑涓ら」涔嬮棿鐨勪竴涓夋嫨銆傝鍖歸厤 |錛岃浣跨敤 \|銆?/td> |
銆銆鏋勯犳鍒欒〃杈懼紡鐨勬柟娉曞拰鍒涘緩鏁板琛ㄨ揪寮忕殑鏂規硶涓鏍楓備篃灝辨槸鐢ㄥ縐嶅厓瀛楃涓庢搷浣滅灝嗗皬鐨勮〃杈懼紡緇撳悎鍦ㄤ竴璧鋒潵鍒涘緩鏇村ぇ鐨勮〃杈懼紡銆傛鍒欒〃杈懼紡鐨勭粍浠跺彲浠ユ槸鍗曚釜鐨勫瓧絎︺佸瓧絎﹂泦鍚堛佸瓧絎﹁寖鍥淬佸瓧絎﹂棿鐨勯夋嫨鎴栬呮墍鏈夎繖浜涚粍浠剁殑浠繪剰緇勫悎銆?/strong>
瀛楃 | 鎻忚堪 |
* | 鍖歸厤鍓嶉潰鐨勫瓙琛ㄨ揪寮忛浂嬈℃垨澶氭銆備緥濡傦紝zo* 鑳藉尮閰?"z" 浠ュ強 "zoo"銆? 絳変環浜巤0,}銆?/td> |
+ | |
? | |
{n} | n 鏄竴涓潪璐熸暣鏁般傚尮閰嶇‘瀹氱殑 n 嬈°備緥濡傦紝'o{2}' 涓嶈兘鍖歸厤 "Bob" 涓殑 'o'錛屼絾鏄兘鍖歸厤 "food" 涓殑涓や釜 o銆?/td> |
{n,} | n 鏄竴涓潪璐熸暣鏁般傝嚦灝戝尮閰峮 嬈°備緥濡傦紝'o{2,}' 涓嶈兘鍖歸厤 "Bob" 涓殑 'o'錛屼絾鑳藉尮閰?"foooood" 涓殑鎵鏈?o銆?o{1,}' 絳変環浜?'o+'銆?o{0,}' 鍒欑瓑浠蜂簬 'o*'銆?/td> |
{n,m} | m 鍜?n 鍧囦負闈炶礋鏁存暟錛屽叾涓璶 <= m銆傛渶灝戝尮閰?n 嬈′笖鏈澶氬尮閰?m 嬈°備緥濡傦紝"o{1,3}" 灝嗗尮閰?"fooooood" 涓殑鍓嶄笁涓?o銆?o{0,1}' 絳変環浜?'o?'銆傝娉ㄦ剰鍦ㄩ楀彿鍜屼袱涓暟涔嬮棿涓嶈兘鏈夌┖鏍箋?/td> |
鎿嶄綔絎? | 鎻忚堪 |
\ | 杞箟絎?/td> |
(), (?:), (?=), [] | 鍦嗘嫭鍙峰拰鏂規嫭鍙?/td> |
*, +, ?, {n}, {n,}, {n,m} | 闄愬畾絎?/td> |
^, $, \anymetacharacter | 浣嶇疆鍜岄『搴?/td> |
| | 鈥滄垨鈥濇搷浣?/td> |
瀛楃 | 鎻忚堪 |
\ | |
^ | 鍖歸厤杈撳叆瀛楃涓茬殑寮濮嬩綅緗傚鏋滆緗簡 RegExp 瀵硅薄鐨?Multiline 灞炴э紝^ 涔熷尮閰?'\n' 鎴?'\r' 涔嬪悗鐨勪綅緗?/td> |
$ | 鍖歸厤杈撳叆瀛楃涓茬殑緇撴潫浣嶇疆銆傚鏋滆緗簡RegExp 瀵硅薄鐨?Multiline 灞炴э紝$ 涔熷尮閰?'\n' 鎴?'\r' 涔嬪墠鐨勪綅緗?/td> |
* | 鍖歸厤鍓嶉潰鐨勫瓙琛ㄨ揪寮忛浂嬈℃垨澶氭銆備緥濡傦紝zo* 鑳藉尮閰?"z" 浠ュ強 "zoo"銆? 絳変環浜巤0,}銆?/td> |
+ | |
? | |
{n} | n 鏄竴涓潪璐熸暣鏁般傚尮閰嶇‘瀹氱殑 n 嬈°備緥濡傦紝'o{2}' 涓嶈兘鍖歸厤 "Bob" 涓殑 'o'錛屼絾鏄兘鍖歸厤 "food" 涓殑涓や釜 o銆?/td> |
{n,} | n 鏄竴涓潪璐熸暣鏁般傝嚦灝戝尮閰峮 嬈°備緥濡傦紝'o{2,}' 涓嶈兘鍖歸厤 "Bob" 涓殑 'o'錛屼絾鑳藉尮閰?"foooood" 涓殑鎵鏈?o銆?o{1,}' 絳変環浜?'o+'銆?o{0,}' 鍒欑瓑浠蜂簬 'o*'銆?/td> |
{n,m} | m 鍜?n 鍧囦負闈炶礋鏁存暟錛屽叾涓璶 <= m銆傛渶灝戝尮閰?n 嬈′笖鏈澶氬尮閰?m 嬈°備緥濡傦紝"o{1,3}" 灝嗗尮閰?"fooooood" 涓殑鍓嶄笁涓?o銆?o{0,1}' 絳変環浜?'o?'銆傝娉ㄦ剰鍦ㄩ楀彿鍜屼袱涓暟涔嬮棿涓嶈兘鏈夌┖鏍箋?/td> |
? | 褰? 璇ュ瓧絎︾揣璺熷湪浠諱綍涓涓叾浠栭檺鍒剁 (*, +, ?, {n}, {n,}, {n,m}) 鍚庨潰鏃訛紝鍖歸厤妯″紡鏄潪璐┆鐨勩傞潪璐┆妯″紡灝藉彲鑳藉皯鐨勫尮閰嶆墍鎼滅儲鐨勫瓧絎︿覆錛岃岄粯璁ょ殑璐┆妯″紡鍒欏敖鍙兘澶氱殑鍖歸厤鎵鎼滅儲鐨勫瓧絎︿覆銆備緥濡傦紝瀵逛簬瀛楃涓? "oooo"錛?o+?' 灝嗗尮閰嶅崟涓?"o"錛岃?'o+' 灝嗗尮閰嶆墍鏈?'o'銆?/td> |
. | |
(pattern) | 鍖歸厤 pattern 騫惰幏鍙栬繖涓鍖歸厤銆傛墍鑾峰彇鐨勫尮閰嶅彲浠ヤ粠浜х敓鐨?Matches 闆嗗悎寰楀埌錛屽湪VBScript 涓嬌鐢?SubMatches 闆嗗悎錛屽湪JScript 涓垯浣跨敤 $0鈥?9 灞炴с傝鍖歸厤鍦嗘嫭鍙峰瓧絎︼紝璇蜂嬌鐢?'\(' 鎴?'\)'銆?/td> |
(?:pattern) | 鍖? 閰?pattern 浣嗕笉鑾峰彇鍖歸厤緇撴灉錛屼篃灝辨槸璇磋繖鏄竴涓潪鑾峰彇鍖歸厤錛屼笉榪涜瀛樺偍渚涗互鍚庝嬌鐢ㄣ傝繖鍦ㄤ嬌鐢?"鎴? 瀛楃 (|) 鏉ョ粍鍚堜竴涓ā寮忕殑鍚勪釜閮ㄥ垎鏄緢鏈夌敤銆備緥濡傦紝 'industr(?:y|ies) 灝辨槸涓涓瘮 'industry|industries' 鏇寸畝鐣ョ殑琛ㄨ揪寮忋?/td> |
(?=pattern) | 姝? 鍚戦鏌ワ紝鍦ㄤ換浣曞尮閰?pattern 鐨勫瓧絎︿覆寮濮嬪鍖歸厤鏌ユ壘瀛楃涓層傝繖鏄竴涓潪鑾峰彇鍖歸厤錛屼篃灝辨槸璇達紝璇ュ尮閰嶄笉闇瑕佽幏鍙栦緵浠ュ悗浣跨敤銆備緥濡傦紝'Windows (?=95|98|NT|2000)' 鑳藉尮閰?"Windows 2000" 涓殑 "Windows" 錛屼絾涓嶈兘鍖歸厤 "Windows 3.1" 涓殑 "Windows"銆傞鏌ヤ笉娑堣楀瓧絎︼紝涔熷氨鏄錛屽湪涓涓尮閰嶅彂鐢熷悗錛屽湪鏈鍚庝竴嬈″尮閰嶄箣鍚庣珛鍗沖紑濮嬩笅涓嬈″尮閰嶇殑鎼滅儲錛岃屼笉鏄粠鍖呭惈棰勬煡鐨勫瓧絎︿箣鍚庡紑濮嬨?/td> |
(?!pattern) | 璐? 鍚戦鏌ワ紝鍦ㄤ換浣曚笉鍖歸厤 pattern 鐨勫瓧絎︿覆寮濮嬪鍖歸厤鏌ユ壘瀛楃涓層傝繖鏄竴涓潪鑾峰彇鍖歸厤錛屼篃灝辨槸璇達紝璇ュ尮閰嶄笉闇瑕佽幏鍙栦緵浠ュ悗浣跨敤銆備緥濡?Windows (?!95|98|NT|2000)' 鑳藉尮閰?"Windows 3.1" 涓殑 "Windows"錛屼絾涓嶈兘鍖歸厤 "Windows 2000" 涓殑 "Windows"銆傞鏌ヤ笉娑堣楀瓧絎︼紝涔熷氨鏄錛屽湪涓涓尮閰嶅彂鐢熷悗錛屽湪鏈鍚庝竴嬈″尮閰嶄箣鍚庣珛鍗沖紑濮嬩笅涓嬈″尮閰嶇殑鎼滅儲錛岃屼笉鏄粠鍖呭惈棰勬煡鐨勫瓧絎︿箣鍚庡紑濮?/td> |
x|y | 鍖歸厤 x 鎴?y銆備緥濡傦紝'z|food' 鑳藉尮閰?"z" 鎴?"food"銆?(z|f)ood' 鍒欏尮閰?"zood" 鎴?"food"銆?/td> |
[xyz] | |
[^xyz] | |
[a-z] | |
[^a-z] | |
\b | |
\B | |
\cx | 鍖歸厤鐢?x 鎸囨槑鐨勬帶鍒跺瓧絎︺備緥濡傦紝 \cM 鍖歸厤涓涓?Control-M 鎴栧洖杞︾銆倄 鐨勫煎繀欏諱負 A-Z 鎴?a-z 涔嬩竴銆傚惁鍒欙紝灝?c 瑙嗕負涓涓師涔夌殑 'c' 瀛楃銆?/td> |
\d | 鍖歸厤涓涓暟瀛楀瓧絎︺傜瓑浠蜂簬 [0-9]銆?/td> |
\D | 鍖歸厤涓涓潪鏁板瓧瀛楃銆傜瓑浠蜂簬 [^0-9]銆?/td> |
\f | 鍖歸厤涓涓崲欏電銆傜瓑浠蜂簬 \x0c 鍜?\cL銆?/td> |
\n | 鍖歸厤涓涓崲琛岀銆傜瓑浠蜂簬 \x0a 鍜?\cJ銆?/td> |
\r | 鍖歸厤涓涓洖杞︾銆傜瓑浠蜂簬 \x0d 鍜?\cM銆?/td> |
\s | 鍖歸厤浠諱綍絀虹櫧瀛楃錛屽寘鎷┖鏍箋佸埗琛ㄧ銆佹崲欏電絳夌瓑銆傜瓑浠蜂簬 [ \f\n\r\t\v]銆?/td> |
\S | 鍖歸厤浠諱綍闈炵┖鐧藉瓧絎︺傜瓑浠蜂簬 [^ \f\n\r\t\v]銆?/td> |
\t | 鍖歸厤涓涓埗琛ㄧ銆傜瓑浠蜂簬 \x09 鍜?\cI銆?/td> |
\v | 鍖歸厤涓涓瀭鐩村埗琛ㄧ銆傜瓑浠蜂簬 \x0b 鍜?\cK銆?/td> |
\w | |
\W | |
\xn | 鍖歸厤 n錛屽叾涓?n 涓哄崄鍏繘鍒惰漿涔夊箋傚崄鍏繘鍒惰漿涔夊煎繀欏諱負紜畾鐨勪袱涓暟瀛楅暱銆備緥濡傦紝'\x41' 鍖歸厤 "A"銆?\x041' 鍒欑瓑浠蜂簬 '\x04' & "1"銆傛鍒欒〃杈懼紡涓彲浠ヤ嬌鐢?ASCII 緙栫爜銆? |
\num | 鍖歸厤 num錛屽叾涓?num 鏄竴涓鏁存暟銆傚鎵鑾峰彇鐨勫尮閰嶇殑寮曠敤銆備緥濡傦紝'(.)\1' 鍖歸厤涓や釜榪炵畫鐨勭浉鍚屽瓧絎︺?/td> |
\n | 鏍囪瘑涓涓叓榪涘埗杞箟鍊兼垨涓涓悜鍚庡紩鐢ㄣ傚鏋?\n 涔嬪墠鑷沖皯 n 涓幏鍙栫殑瀛愯〃杈懼紡錛屽垯 n 涓哄悜鍚庡紩鐢ㄣ傚惁鍒欙紝濡傛灉 n 涓哄叓榪涘埗鏁板瓧 (0-7)錛屽垯 n 涓轟竴涓叓榪涘埗杞箟鍊箋?/td> |
\nm | 鏍? 璇嗕竴涓叓榪涘埗杞箟鍊兼垨涓涓悜鍚庡紩鐢ㄣ傚鏋?\nm 涔嬪墠鑷沖皯鏈?nm 涓幏寰楀瓙琛ㄨ揪寮忥紝鍒?nm 涓哄悜鍚庡紩鐢ㄣ傚鏋?\nm 涔嬪墠鑷沖皯鏈?n 涓幏鍙栵紝鍒?n 涓轟竴涓悗璺熸枃瀛?m 鐨勫悜鍚庡紩鐢ㄣ傚鏋滃墠闈㈢殑鏉′歡閮戒笉婊¤凍錛岃嫢 n 鍜?m 鍧囦負鍏繘鍒舵暟瀛?(0-7)錛屽垯 \nm 灝嗗尮閰嶅叓榪涘埗杞箟鍊?nm銆?/td> |
\nml | 濡傛灉 n 涓哄叓榪涘埗鏁板瓧 (0-3)錛屼笖 m 鍜?l 鍧囦負鍏繘鍒舵暟瀛?(0-7)錛屽垯鍖歸厤鍏繘鍒惰漿涔夊?nml銆?/td> |
\un | 鍖歸厤 n錛屽叾涓?n 鏄竴涓敤鍥涗釜鍗佸叚榪涘埗鏁板瓧琛ㄧず鐨?Unicode 瀛楃銆備緥濡傦紝 \u00A9 鍖歸厤鐗堟潈絎﹀彿 (?)銆?/td> |
姝e垯琛ㄨ揪寮?/td> | 璇存槑 |
/\b([a-z]+) \1\b/gi | 涓涓崟璇嶈繛緇嚭鐜扮殑浣嶇疆 |
/(\w+):\/\/([^/:]+)(:\d*)?([^# ]*)/ | 灝嗕竴涓猆RL瑙f瀽涓哄崗璁佸煙銆佺鍙e強鐩稿璺緞 |
/^(?:Chapter|Section) [1-9][0-9]{0,1}$/ | 瀹氫綅绔犺妭鐨勪綅緗?/td> |
/[-a-z]/ | A鑷硓鍏?6涓瓧姣嶅啀鍔犱竴涓?鍙楓?/td> |
/ter\b/ | 鍙尮閰峜hapter錛岃屼笉鑳絫erminal |
/\Bapt/ | 鍙尮閰峜hapter錛岃屼笉鑳絘ptitude |
/Windows(?=95 |98 |NT )/ | 鍙尮閰峎indows95鎴朩indows98鎴朩indowsNT,褰撴壘鍒頒竴涓尮閰嶅悗錛屼粠Windows鍚庨潰寮濮嬭繘琛屼笅涓嬈$殑媯绱㈠尮閰嶃?/td> |