declare @idoc int -- 声明xml文档指针 
declare @doc varchar(1000) --xml文档文本 
declare @table table(cell1 varchar(20),cell2 varchar(20)) --临时表 
 
set @doc = ' 
<root> 
<row><cell1>adf</cell1><cell2>234</cell2></row> 
<row><cell1>adf</cell1><cell2>234</cell2></row> 
</root> 
' 
--打开xml文档 
EXEC sp_xml_preparedocument @idoc OUTPUT, @doc 
 
--选择xml内容并插入临时表 
insert  @table 
select * FROM       OPENXML (@idoc, '/root/row',2 ) 
      WITH (cell1  varchar(20), cell2 varchar(20)) 
 
EXEC sp_xml_removedocument @idoc --关闭xml文档指针 
 
declare @cell1 varchar(20),@cell2 varchar(20) 
 
--声明游标 
declare tcursor cursor for select * from @table 
--打开游标 
open tcursor 
 
--开始事务 
BEGIN TRANSACTION modifyData    WITH MARK N'some remarks'; 
 
fetch next from tcursor into @cell1,@cell2 
while @@FETCH_STATUS = 0 begin 
    print @cell1 + @cell2 
    fetch next from tcursor into @cell1,@cell2 
end 
 
--提交事务 
COMMIT TRANSACTION modifyData; 
 
--关闭游标 
close tcursor 
deallocate tcursor 

J2SE中的类大致可以划分为以下的各个包：
java.*，javax.*，org.*，sun.*
除了“sun”包，其它各个包都是Java平台的标准实现，并且今后也将被继续支持。一般说来，“sun”之类的包并不包含在Java平台的标准中，它与操作系统相关，在不同的操作系统（如Solaris，Windows，Linux，Mac等等）中的实现也各不相同，并且可能随着J2SE版本不定期变化。因此，直接调用“sun”包的程序代码并不是100％的Java实现。

也就是说：
“java.*”包，“javax.*”包，“org.*”包是作为J2SE的 API公开接口的一部分，如果程序直接调用这些包中的API，那么程序是可以运行在所有Java平台上，而与操作系统无关；但“sun.*”包并不是 API公开接口的一部分，调用“sun”包的程序并不能确保工作在所有Java平台上，事实上，这样的程序并不能工作在今后的Java平台上。

正因为如此，“sun.*”包中的类并没有提供API文档。平台无关性是Java语言最大的优势之一，此外，SUN和Java许可证确保维持了今后API的向上兼容性（以后修改的那些有严重bug的代码除外）。这种兼容性意味着你写好的程序编译成的cl ass文件仍然可以工作在将来的版本当中。

每家实现Java平台的厂商都可以使用他们自己的方式。“sun.*”包中的类是 SUN 对Java平台的实现方式，它们工作在Java 2 SDK的下层，这些类未必被其它Java 平台开发商支持。比如你的Java程序如果调用了一个名为“sun.package.Foo”的类，将有可能产生 “ClassNotFoundError”的错误，同时你也将失去利用Java的一个主要的优点。

从技术上讲，并不能防止你的程序调用“sun.*”包中的类。在版本的变迁当中，这些类可能会被删除或转移到其它包路径下，而且它的接口（包括名称、标签等）也很有可能发生变化，（根据SUN的观点，我们应当能够通过对“sun.*”包的修改来提高Java平台的性能。）在这种情况下，即便你希望程序仅仅运行在SUN的实现平台下，你仍将承受新的版本给你的系统带来破坏的风险。总之，编写依赖于“sun.*”包的Java程序是不安全的，他们将变得无法移植，无法被很好地支持。

byte src[] = {(byte)228,(byte)184,(byte)173,(byte)229,(byte)155,(byte)189,0};  //中国 
 
int ucCharLen = MultiByteToWideChar(CP_UTF8,0,(LPCSTR)src,-1,NULL,0); 
LPWSTR wbuf = new WCHAR[ucCharLen]; 
memset(wbuf,0,sizeof(wbuf)); 
MultiByteToWideChar(CP_UTF8,0,(LPCSTR)src,-1,wbuf,ucCharLen); 
 
byte* buf = NULL; 
 
int byteLength = WideCharToMultiByte(CP_UTF8,0,(LPCWSTR)wbuf,-1,NULL,0,NULL,NULL); 
buf = new byte[byteLength]; 
memset(buf,0,sizeof(buf)); 
WideCharToMultiByte(CP_UTF8,0,(LPCWSTR)wbuf,-1,(LPSTR)buf,byteLength,NULL,NULL); 
 
delete buf; 
delete wbuf; 

在用进行文件操作时,少不了和目录的递归打交道,但我一般认为.递归算法比较慢.如果可以采用非递归实现,就不要递归.

在非递归算法中,一般我们用一个队列来保存相应的数据.一会列出代码.
还有一个问题,我们递归目录,无非是想对文件进行操作,或者想得到文件的一个列表. 这时,你可以会采用回调函数. 但在我看来,还有更好的实现文案,让"回调"函数是一个对象,就既可以实现回调,也可以保存数据,这就是C++语言的仿函数.今天,我们就用仿函数来对指 定的文件进行操作,例如修改文件,或者得到文件列表.
先看一下递归函数的实现:

用法：
1、追加文件：jpgexe.js jpg1.jpg + exe1.exe jpgout.jpg
程序exe1已经到图片jpgout.jpg 中了。
2.、分离：jpgexe.js jpgout.jpg  exe2.exe
程序exe2已经分离出来了。
脚本：

//增大音量: 
keybd_event(VK_VOLUME_UP,MapVirtualKey(VK_VOLUME_UP,0),KEYEVENTF_EXTENDEDKEY,0); 
keybd_event(VK_VOLUME_UP,MapVirtualKey(VK_VOLUME_UP,0),KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP,0); 
 
//减小音量: 
keybd_event(VK_VOLUME_DOWN,MapVirtualKey(VK_VOLUME_DOWN,0),KEYEVENTF_EXTENDEDKEY,0); 
keybd_event(VK_VOLUME_DOWN,MapVirtualKey(VK_VOLUME_DOWN,0),KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP,0); 
//静音: 
keybd_event(VK_VOLUME_MUTE,MapVirtualKey(VK_VOLUME_MUTE,0),KEYEVENTF_EXTENDEDKEY,0); 
keybd_event(VK_VOLUME_MUTE,MapVirtualKey(VK_VOLUME_MUTE,0),KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP,0);