跨平台技术_在线百科全书查询
跨平台技术
跨平台泛指程序语言、软件或硬件设备可以在多种作业系统或不同硬件架构的电脑上运作。跨平台最民生最简单的理解就是在一个熟悉的平台上面开发的软件或者程序，直接可以在其他平台上正常的运行显示而不需要对其原始文件或者原始代码进行修改。
广义面言
一般的计算语言都可做到跨平台，开发商只需要提供各种平台下的Runtime/中间件环境即可。严格而言是指用某种计算机语言编制的程序只需要做小量的修改，编译之后即可在另外一种平台下运行，此时并不提供Runtime/中间件环境。例如Java是一种提供Runtime环境的跨平台解决方案，而C只是一种标准且严格的跨平台语言。
跨平台概念
是软件开发中一个重要的概念，即不依赖于操作系统，也不信赖硬件环境。一个操作系统下开发的应用，放到另一个操作系统下依然可以运行。相对而言如果某种计算机语言不用修改代码即可做到高度跨平台，那么此语言就越抽象，硬件控制力就越低，只适合开发高度抽象的模型系统。诸如java,delphi和易语言，都已做到了跨平台。它们将可以在多种系统下开发，运行和维护。
跨平台 语言
大部分电脑语言从绝对意义而言
都是跨平台的：因为都是以高级的、人类可读的方式来对CPU发号指令，这样也就没必要依赖于任何作业系统。但如果要用系统的部件工具箱，来新建用户图形界面（GUI），就可能会用到开发员特定系统中的API函数或库类。虽然C++是跨平台的，但Windows下用到Win32 API的C++程式，一般就不能在Unix机器上编译。不同编译器对语言规范的解释也有所差异。这样的话，在针对不同系统进行构建之前，程式就得加以考虑。
一些如Java这样的语言，从一开始就意识到要在各个平台下运行，所以跨平台在其平台的本地语言环境中已经实现。例如，Java可以跨平台使用，正是由于Swing库在许多平台下的实现。类似的，能进行跨平台的文件存取，是因为有各自平台下文件存取的库（实际上java里面的部分东西在windows平台下编写好后，移植到Linux平台下是会出现少许问题的，问题比较小并且不多，我们还是可以理解为sun公司所说的跨平台的）。以此类推，各种跨平台问题，都需要各自的本地库来解决。wxWidgets框架就是这样的一个跨平台库，根据不同的跨平台问题，提供了许多不同的解决方案；类似的库有许多，可以根据不同语言的跨平台开发，而采用相应的库。
针对每种作业系统、CPU，而提供并测试各自的编译版本，这种做法的可行性很小；开源软体则允许用户自己来编译目的码（object code），这样在跨平台方面更好一些。类似的，那些解释型语言，或者需要虚拟机的语言，也更加符合跨平台的要求，因为用户也要自己进行编译。Sun公司的Java虚拟机Hotspot，只针对几种而不是全部平台，提供编译好的二进位文件。例如，Sun对于GNU/Linux，只支持i386平台，但如果谁在PowerPC或者SPARC电脑上运行Linux，就只好自己编译本地的机器码（machinecode），或者使用第三方软体，才能运行Java程式。
许多API（应用程式介面）依赖于平台。OpenGL可以看作是跨平台的，因为其不依赖于任何特定的作业系统、CPU构架或者某个牌子的图形设备。特定平台的API可以在其他系统上作为兼容层而新建，例如WINE的库，Windows程式就可以在UNIX系统上运行。
另外许多程式语言还有跨平台的扩展以及中间件，这样程式设计师对于同样的原始码，只要进行一点小修改，就可以在不同平台下编译/运行，例如Qt和wxWidgets。
跨平台应用
跨应用服务器
这一点，看起来好像有些多余，java的口号之一不就是“一次编译，到外运行”嘛，可实际经验告诉我们，这仅仅是一个口号而已。实际中是“一次编译，到处调试”。为什么会这样？从应用服务器来说，各个产品或多或少都在标准的java规范之上进行了一些拓展，小规模的应用开发，多以tomcat为基准；大规模的应用，多以weblogic/websphere为基准。
那么开发完成的应用，可否在所有的应用服务器上正常部署呢？答案是否定的。在tomcat5上部署没问题，在tomcat4上却可能有问题；在tomcat5/4上没问题，却可能在resin/jetty/weblogic/websphere上有问题。在我的经历中，在resin/jetty/weblogic为基准进行开发的应用，部署到tomcat上基本上没什么问题。但是以tomcat为基准的应用，部署到其他应用服务器中，却可能出现各种各样的问题。这与tomcat本身的定位和开发方式有关，它更像是一个学术产品，而不是一个商业产品。
小型的应用，我偏好resin，它的速度、稳定性、兼容性、中文处理，都是非常不错的。相比而言，以“纯java、快速”著称的jetty，就不太令人满意。jetty的4/5/6各个版本中，对session的存放位置、web.xml的标准、struts的plugin的支持、log4j的处理，都各不相同。在最新的jetty6中，竟然会要命地“不能使用session.validate()”方法，一使用此方法之后，就无法再使用set/getAttribute了。
也曾经在将一个应用转移到websphere5上时，费劲周折。这个应用跑在其他应用服务器上都没问题，但是一部署到ws5上，就无法正常加载struts的配置文件。本以为是struts配置文件写得有问题，但即便把所有的action/form配置均去掉，只保留一个空的配置文件，也无法正常启动。最后实在无法，只能乱碰运气，考虑是否是struts的几个jar包版本有问题，经检查，发现应用中使用的是struts1.2的jar包，换成struts1.1的jar包，再启动后就一切正常。这样的问题，可真的是折磨人呢。
所以，我认为跨应用服务器是很重要的。你不能告诉客户，俺们的系统只能跑在tomcat下面，至于您花重金购买的weblogic/websphere，对不起，我们暂时还不支持。客户会吐血的。
跨数据库
经常看到某大公司产品，要求必须使用oracle或者sqlserver数据库，你想换个数据库来部署？没门，人家说了，我们的产品只支持这一种数据库，你就老实的用吧。但对于客户方来说，为了减少投资，并且保证内部系统尽可能使用同一种数据库以减少维护成本（总不能请一个oracle DBA，再请一个sqlserver DBA吧？），总会希望新系统使用的数据库是以前用过的吧。
现在有了hibernate，在此基础上开发的应用，基本上是能满足跨数据库要求的，个人认为这是hibernate最大的亮点。但也要注意，在开发中尽可能考虑到不同数据库的特性。诸如sqlserver的text/image字段上不能查distinct，oracle内的各种对象名称长度不得超过30等，尽量不要调用数据库的内部特性（如存储过程、视图等）
跨操作系统
这一点，貌似没有什么可说的，很少有开发出的系统只能部署在一种操作系统上的。不过有一点也要注意，如果系统中某些功能依赖于通过JNI来调用windows本地组件的话，比如打印、word/excel操作，或与只能运行在windows下的报表组件(如国内的数巨报表、如意报表)集成的话。
跨浏览器
窃以为，如果只是做国内的应用，这一点倒不重要，就以IE为标准来开发也未尝不可。
PS：完全支持IE也不是一件容易的事情，IE5/6本身就有不少的差异。
但如果产品本身想立足于世界，想与国外产品竞争，对浏览器的全面支持也必不可少。至少应该同时支持ie和firefox吧，如果对自身严格要求的话，我认为应以opera为标准，opera对html/css/javascript的标准是实现和支持得最好的浏览器。
