VCASMO

Search Results for 'loadvars'


If you use POST method to send parameters, the received result is XML, you should use LoadVars or XML? sendAndLoad from LoadVars cannot handle received XML format, sendAndLoad from XML can use GET method to send parameters only, cannot use POST Method. I have already sticked to write AS3, suddenly switch back to AS1, I forgot how to code, googling (cannot find any useful tutorial). Finally, I find out by myself: LoadVars’ sendAndLoad can assign receive Object, usually assign itself, so never consider it can be others before, that is XML Object, ha!

login_lv = new LoadVars();
login_xml = new XML();
login_xml.ignoreWhite = true;
login_xml.onLoad = function(suc) {
        // parse XML result here
};
login_lv.loginname = loginName_tf.text;
login_lv.password = pwd_tf.text;
login_lv.sendAndLoad("login.php", login_xml, "POST");

Main concern: better QA on Flash Player, make it more cross-platform/browsers and backward/forward compatible.

Flash Player is cross-platforms/browsers“, I think it is a successful marketing wording deeply printed in every SWF developer brain. In fact, Flash Player does not 100% running the same in any platforms/browsers and even minor Flash Player versions.

When people said AJAX have to deal with a lot of cross-browsers problem, they are not truly modern browser JavaScript developers, it was the old story in browser wars (IE4 vs Netscape 4), to access a layer, we have to even use different script. The situation has changed, JavaScript is running “the same” in modern browsers (IE6+, Firefox, Safari, Opera), except the problem mainly due to the weakness/wrong support on CSS in IE and Opera. If you develop AJAX application and not using DIV+CSS (tableless) layout, you are quite easy to make it run perfectly in cross-browsers.

AJAX developers understand their own problem and more concern users, they will testing their applications thoroughly between different browsers, but SWF developers are different, they trust Adobe, they trust Flash Player. We only test in one browser+one Flash Player minor version during development. It cause us into a dangerous situation when production.

Here are some of the Flash Player differences:

Cross-platforms/browsers

If you argue it is a problem Flash Player deal with browsers and what is the difference I argue that DOM+CSS deal with browsers? Overall performance are cross-platforms/browsers in AJAX/SWF but those minor flaws cause no difference between AJAX/SWF developers.

Here are some of the Flash Player differences:

Changes in major/minor Flash Player version

You should check Ticore’s blog (Chinese), he wrote many cases Flash Player is not backward/forward compatible:

Have you forgot every time Flash Player tighten its sand box? Sometimes it affects our previous work online (not local content):

Every major Flash Player upgrade introduces tons of new feature, but in between minor version, Flash Player has also improved with new features, bug/security fixes, so if you target for a major Flash version users, you have to be careful with what minor version they get, too:

You should also check Adobe site for every Flash player major/minor version released, what existing contents have broken or any previous problems have fixed:

Finally, EOLAS case (not Adobe/Flash Player fault) caused SWF developers have to work back on our old works by a sudden mid-night call from clients? Flash Player is cross-platforms/browsers? Flash Player is backward/forward compatible? LOL, we faced the same situation as AJAX developers…

Follow up

經過2005年的時間,做過大大小小不同的Flash應用,當我忙於為2006年第一個重頭而大型的Ajax專案做準備、文檔和可行性研究等時,我不禁不斷問自己,Flash的未來在哪裡?Flash的優勢在哪裡?Flash的重要性在哪裡?

我的角色

先從自己的角色說起,我平日工作是做Flash,這是人所共知的,但不只是Flash這麼簡單,我可是一個諮詢、協調和開發的角色,首先因應客戶的問題和預算,提供硬體上和軟體上的建議,例如要用什麼Server?什麼OS?Linux/Windows?什麼Server-side Program和Database等。

在Client-side/Browser/Front End上,我是一個UI Designer,我非常關心怎樣給予使用者最好體驗,包括:

  • 快速下載
  • 簡易操作
  • 界面流暢,慢的電腦也跑得順
  • 不佔用過多CPU Power
  • Cross Browser和Cross Platform

同時我也是一個Information Architect,思考怎樣將Server傳來的數據(Data)轉化為清楚、有用、條理分明的資料(Information/Content),不單只在展示(Presentation)上滿足使用者,更要協助使用者可以將資料再運用,例如:選取Copy-n-Paste、列印、另存、Bookmark、Forward Link等。同時,我更為應用系統研究合適的操作步驟,包括每個操作的Screen Flow,怎樣協助使用者操作、找出錯誤、處理Back Button,提交資料到Server前優化工作等。

到了Server-side,我變成一個中間人角色,跟Programmer溝通,告訴他們需要什麼API供給Front End使用。最簡單層次也要跟很多不懂Flash的Programmer溝通,告訴他們怎樣跟Flash作LoadVars。這個中間人角色在開發過程中,變成了一個System Analysist,因為我要思考的既是怎樣分工,也要考慮到應用系統將來維護和擴展性。分工上簡單地說是怎樣去將應用系統MVC化,讓美工只專注在設計上。維護和擴展性,要考慮到將來增加功能、Localization多語言版本等問題、開放API等Web 2.0的東西。因此,Front End我要周旋於HTML, CSS, JavaScript, XML, XSLT, Flash的取捨,Back End要想2-Tier還是3-Tier,SOA等等問題。這也是我諮詢一部分,給客戶建議,告訴Programmer該做什麼。

因為這個背景,所以我對於Front End技術的選擇非常關心,過去是HTML vs Flash?現在是AJAX vs Flash?Adobe vs M$ vs Open Source?因為HTML對Flash取捨,已經影響了我關心的「使用者最好體驗」,就是剛才提到幾點,同時它也影響了Server架構,例如用Flash是否可以直接連Web Services產生一個簡單2-Tier的SOA?

我的專案

我所有專案,99%都有Flash,基本上所有Flash Spectrum東西我都有做過。我將範圍收窄在網上,即Browser裡東西。Browser裡東西,除了新聞純文字資訊性的網站絕對不需要用Flash外(看新聞影片Video除外),我看到要用Flash地方,其實分為四種:自我介紹的中小企公司網站、電影娛樂產品宣傳的行銷性網站、網上商貿資料搜索性網站、Web Based Application(即純粹解決商業問題的應用程式,由過去C/S搬上B/S)。

公司網站,考慮因素很低,使用者不會長時間留在網站裡,沒有什麼操作,內容更新規模低至少,因此運用HTML或是Flash,基本上由客戶和價錢決定。其實這類網站很依靠Search Engine帶來瀏覽者,純Flash網站怎辦?沒有我提醒,客戶其實很難察覺這大問題。

行銷性網站,一定是Flash,因為多姿多彩,影音娛樂聲色俱全是這些網站必需的,目前有的技術,唯有Flash才能勝任。行銷性網站不會長時間在線,將來維護問題需要很少。

分析運用Flash的優劣

後兩者,就是我最關心的所在。網上商貿資料搜索性網站(下簡稱「資搜網」),除了一般網上購物外,還包括資料搜索性,例如地圖上增值服務、找餐廳、訂酒店機票等服務。這類網站,對於我關心的「使用者最好體驗」最為重要,因為使用者除了要經常使用外,還要對資料再運用。一個用戶體驗為主的網站,如果這方面做得不好,直接是損失商機,例如放棄Check out等。雖然Macromedia的口號是體驗攸關(Experience Matters),不過,我看來,Flash正為這類網站提供最差體驗。

一、 失去Back Button和Bookmark/Forward Link能力
有些基本Flash缺點,前人都已經說了(Flash: 99% Bad),「資搜網」對Back Button和Bookmark/Forward Link非常重要。以HTML一頁為單位的「資搜網」,可以用GET Method來查詢,搜索的參數都在網址上,既可以按Back Button就再搜尋(大部分使用者,對錯誤操作仍然是習慣按Back Button),也可以Bookmark和Forward Link,試比較HTML的Flickr和Flash的Fotologue.jp,後者網站怎樣告訴朋友我喜歡的一張相片?

FlashNoLink1.jpg
FlashNoLink2.jpg

雖然這些問題(Ajax也有面對)Flash有解決方法(參考我的《AS2與RIA》),但絕對是痛苦開發過程。

二、 不能資料再運用
資料再運用上,Flash網頁難以讓使用者儲存和列印,雖然Flash提供了PrintJob API,可以弄一個Button供使用者列印,不過一天Flash寄生在Browser裡,一天使用者直覺上會按Browser裡Menu Bar上的Print(難怪Adobe要攪她那個Flash+PDF+HTML+CSS的Apollo,努力跳出Browser框框)。Ajax也有難以讓使用者儲存問題,因為網頁內容是動態產生。

三、 文本處理能力不快不方便
Flash一直強調自己展示能力,可惜這又正正曝露出它天生致命點,文本(Text)處理能力不快不方便,我不會說它不強,它可以Embed Font,Flash 8更可以控制Leading Kerning等,可惜它很慢,而且不方便使用者!文字根本是HTML天生原素,在Browser裡可以自由快速地滾動瀏覽,自由選取,更可以隨便讓使用者控制字體大小。在美工主導下的Flash字體,非常細小難於閱讀,大量文字滾動起來又慢又吃力(我以前批評過Flash Paper)。另一方面,HTML文字可以隨Browser大小自由換行,Flash裡又花費大量功夫。Localization上,HTML有很多方法,例如套用不同Template代表不同語言版本等,文字因為儲存在純文字檔案,可以給翻譯容易處理。在Flash裡,又是另一個使人頭痛問題,抽出來放在XML裡?Dynamic TextField會失去美麗字體!結果又要花費美工複製多個FLA語言版本,將來維護上又是一個極大煩惱。

四、 文字/圖文列表處理能力弱
在「資搜網」上,經常要顯示大量文字/圖文夾雜搜尋資料時:

FlashNotSupportTable1.gif
FlashNotSupportTable2.gif
FlashNotSupportTable3.gif

Flash就顯得軟弱無力,用DataGrid?它慢得可怕,又非常難Hack,CellRenderer不是一般開發者懂得。對於這樣資料,要先攪清楚它們是Tabular Data還是只需要Tabular Format,前者需要一個DataGrid形式顯示,因為DataGrid可以用Columns排序、做分頁等。Tabular Format只不過在HTML上,用Table排列出,在Flash裡用duplicateMovieClip或者Flex的mx:Repeater。HTML Table列出,ScrollBar由Browser負責,快速而方便;在Flash裡則要自製ScrollBar,慢和不方便。

五、自製界面困擾使用者
談到自製ScrollBar,Jakob Nielsen有文章指出Flash自製ScrollBar的問題。Flash界面不單是ScrollBar問題。它更引申,因為Flash非常自由,美工可以自由發揮,變成界面可以有一些新奇古怪的操作方法,使用者面對不是他們熟悉的OS操作方法,就有猶疑。難道我們可以坐在使用者旁邊教他們用,還是提供使用者手冊給他們看?「資搜網」用戶是廣大的,根本沒有可能教他們用,因此,簡單而平常界面才最重要。

小結
「資搜網」最適合一頁頁的HTML來顯示,Ajax/Flash只適合作搜索操作步驟上改善使用者體驗,例如提示錯誤,快速跟Server驗證等。Refreshless Page是盲目無意義的追求!

Flash沒有幫助開發者開發RIA
應用開發是很多ISV和開發者日常的工作,因為商業公司有很多數據化後業務操作,不是一般盒裝軟體能夠滿足,因此需要這類公司或開發者為他們訂製或客製。這類應用程式簡單地只是一個資料輸入,數據儲存,資料輸出的過程,因此所謂應用程式只不過是一個輸入界面Form加一個Database。以前是Client-Server(C/S)架構,現在只不過搬到Browser裡。

一、劣質界面組件
輸入界面包括TextInput, Button, Radio Button, CheckBox, List, ComboBox等,就是Flash裡v2 Component,可惜v2 Component非常慢,Buggy和檔案大,缺乏優質界面組件一直是Flash開發應用程式第一大問題。Flex組件好很多,可惜昂貴價錢使大部分開發者望門輕嘆。雖然Flex Builder 2和AS3組件可以改善這問題,可惜待推出至Flash Player 8.5普及,還有一段長時間,遠水不能救近火。不過,這些基本界面組件,HTML已經有,由於它們是HTML天生原素,在Browser裡支援十分好,反應快,又支援Tab Focus和鍵盤。

二、兩邊不討好界面製作過程
在Flash Timeline以Drag-n-Drop組件的方式製作界面,還是在Dreamweaver裡也是以視覺化的方式製作界面,不過同樣容易地以純文字方式去調節來得方便和快速?(Flex Builder也是視覺化+文字化,不過高貴Flex根本不是一般開發者用)。程式員怎樣選擇?對於美工,他們想自訂界面外觀,Flash v2 Component/Flex的方式,他們可以參與多深入呢?HTML+CSS方式修改是否最簡單快捷方便?

當重要界面組件被商業企業Adobe以謀利方式控制著時,我們是否應該考慮更討好,免費、標準和廣大Browser支持的HTML Form Element呢?

三、難以容入的團隊開發
FLA難以整合到CVS,MXML只有乾看,沒有錢用,沒有文字化Flash應用開發方式,不能純用自己喜歡的Editor開發,SWF Compiler遙遙無期,MTASC自我放棄。Flash應用開發成本比HTML貴很多,單時等Flash MMC Compile的時間已經浪費了一個人生(見用MTASC可以生仔)。

四、根本沒有所謂桌面軟體操作經驗和需要
Flash喜歡說可以有桌面軟體操作經驗的RIA,即是有Drap-n-Drop。大部分B/S應用,剛才已經指出了,是一個資料輸入的Form而已,有需要什麼創新的Drag-n-Drop操作方法嗎?

五、應用程式需要頁面無刷新
所有應用程式開發者都很怕使用者按Back Button,因為容易產生數據不完整錯誤,也討厭Reload這Button,容易產生數據重覆問題。從C/S走過來,應用程式從來不需要Back和Reload Button。因此頁面無刷新是對開發者很重要功能,也是Flash當初賣點。

六、Cross Platform和Cross Browser
應用程式以Web Based來部署,B/S廣泛代替C/S,原因是Internet/Intranet和Browser是一個廣泛和容易部署的應用程式平台。不過,因為廣泛,所以有Cross Platform和Cross Browser問題,Flash冒起正正因為它真的可以Write Once, Run Anywhere。

第五、六點不是Flash缺點,而是提出來因為這兩個Flash獨特優點,正正被Ajax代替。第五、六點其實是Web Based Application開發者很需要,因此當Ajax出現時,立即引起轟動!為什麼他們卻無視Flash存在?Ajax冒出,除了以上技術上優勢外,還有多家著名Web 2.0概念的網站都是用Ajax,變成了Web 2.0概念中都包含Ajax,可憐Flash要拚命躋身入去(Mike ChambersKevin Lynch說法),說服世人Flash也是Web 2.0一分子。

小結
HTML Form Element和HTML文字/圖文列表處理能力,純文字開發過程、XMLHttpRequest提供無刷新數據交換,Cross Platform和Cross Browser,所有Web Based Application開發需要的東西,Ajax都比Flash好,Flash有何優勢,難道以為那些Expressiveness和Transitions Effect來騙騙門外漢?應用程式貴乎實用而非花巧,當使用者每天都使用程式時,還要他們浪費時間等Flash用Transitions Effect將一張Form旋轉放大Fade In出來嗎?

邪惡的Adobe

封閉收費 vs 公開免費
當完成合併那天的FAQ提到要將Flash Player和PDF合併,Flash社群震撼是如何大!這要Adobe方面漏夜修正FAQ字眼,Mike Chambers等走出來澄清。我想人們應該要明白Flash無論多de facto standard都好,始終是控制在一家牟利的商業企業裡,人家要給你劣質Component,賣你12萬美元Flex,你是沒辦法的。同樣道理,因為公開、免費、標準的技術大湊合Ajax會被人重視,原因在此(見Open Source Action Items中Aral Balkan意見)。開發者不可以將自己將來、前途和錢途寄託在單一公司、單一封閉技術裡。

Flash是二線產品
我對Adobe吞併Macromedia感覺,如香港回歸大陸一樣,雖然有強勁經濟靠山,但香港獨特國際優勢會逐步被大陸化而變成中國一個沿海普通城市。Flash現在只不過淪為Adobe裡一個二線產品,Adobe可以繼續放主力在她賺錢的Documentation和PDF業務、Flash和那可能賺大錢的Flash Mobile遠景,Adobe會重視嗎(見Adobe Faces Tough Choices)?香港不再生金蛋,Flash也不再閃爍!

Macromedia精神不再
況且,我從來不認為Flash Mobile會成功(1,2)。Macromedia精神和Vision究竟有多少能夠再延續在Adobe裡?雖然有五位Macromedia高層入了Adobe管理層,但有實權嗎?Stephen A. Elop所謂President, Worldwide Field Operations,看來有虛名沒有實權,新安插出來職位?Adobe雖然接收了Macromedia的員工,但多少會長期留下,我知道一些高層合併過程中已經離開,Flash開發團隊的精英會否一年半載後意興闌珊而離開或另起爐灶?(如Macromedia買了RoboHelp後,RoboHelp員工拉隊離開1,2

Adobe得不到Macromedia開發社團信任,雖然她已經發公開信保證,但各MMUG將準備以行動證明拒絕Adobe化決心(見LondonMMUGCPMMUG和香港MMUG)。

最後總結
Flash最適合多媒體的行銷網站運用,其他方面,它正是腹背受敵中,視覺實驗可以玩Processing,應用程式可以考慮Ajax。我建議所有熱愛Flash的RIA Developer,2006年應該將目光多投向Ajax,因為同樣是ECMAScript,同樣是XML Parsing,非常容易學。我們Flash Developer有5年時間,從過去錯誤經驗成長,如果將這些經驗知識運用到Ajax上,一定能找到我們自己的優勢的。

最後,我不是今天的我打倒昨天的我,我曾經對Ajax作出批判,但了解過我的工作背景:我是由鑽研DHTML討厭Flash到開始轉玩Flash的;長期關心本站的朋友都知道,我是一個關心Client-side技術發展的人(1,2,3,4)。所以,任何對改善使用者經驗、改善開發者工作的有價值技術,我們都不能放過。

祝Flash好運!祝大家新年進步!

註:標題「未來未有來」取自我朋友科幻作家蕭炫(蕭志勇)的一個短篇故事

別人文章

因為Flash Lite 2.0已經開賣,所以可以講一下Flash Lite 2.0一些我認為有意思的新功能,依照重要程度排列:

  1. Unicode:動態文字可以展示中文,在我們華文地區來說,非常重要!
  2. Mobile Shared Object (MSO):即PC上LSO,可以儲存資料到手機,不用再為遊戲儲存等問題尋求其他Fscommand Flash2File的解決方法。注意:MSO只在Standalone
    Mode支援,如果Flash內容是在Browser Mode、Messaging Application或者Nokia File Manager,MSO是不支援的。

  3. 可以LoadMovie載入圖像檔案,不用再尋求JPG2SWF等工具在Server先轉換,由於Decode能力借助手機支援,所以可以載入JPG/GIF/PNG,不支援Animated GIF/PNG Animation,由於要知道手機是否支援該格式,所以有System.capabilities的ActionScript來偵測。
  4. 同樣道理,loadSound支援動態載入MP3/MIDI,也是靠手機支援。
  5. 同樣道理,Video可以播放3gp,其實也是靠手機支援,3gp影像一定蓋在Flash內容上面,至於Embed Video in SWF也可以,不過File Size這麼大,可行嗎?
  6. Stage Object可以知道SWF畫面大小,onResize也支援,是否代表可以用一個SWF通吃不同手機畫面大小?
  7. SetInputTextType,可以限制Input TextField為Numeric, Alpha, Alphanumeric, Latin, NonLatin and NoRestriction。
  8. ExtendBacklightDuration,控制手機光亮時間(如果手機支援的話),感動!

以下則是一些一般人認為有意思的新功能,我則不以為然:

  • Flash Lite 1.1載入數據方法只可以用loadVariables載入URLEncode(myName=luar&age=12)格式數據,Flash Lite 2.0可以用LoadVars,更甚是用XML Object載入XML,不過實際上作用不大,因為XML檔案一般較大,現實是避免使用,另外,也花手機運算能力去Parsing。
  • Flash Lite 2.0是基於Flash Player 7和ActionScript 2.0,很多人對此有嚴重誤會和憧憬,首先我認為Flash Player 7的東西大都不支援,下面會解釋,另外,是否真的需要用到ActionScript 2.0?我覺得Flash Lite 2.0最好好處是可以用回Dot Sytnax去編寫,還有Array、Function、Math Class等,對大部人是方便了。

因為一句Flash Lite 2.0是基於Flash Player 7,很多人對此有嚴重誤會和憧憬,我必須澄清一些錯誤:

  • 先說動態數據載入方面,其實沒有什麼改變,只是多了XML而已(現實中是否有用則另說),不支援Flash Remoting,不支援XML Socket,不支援RTMP。最大進步反而是Unicode,終於可以用中文數據!
  • Video方面,不要妄想有Camera Object可以接收手機鏡頭的影像,不支援Sorenson Codec,不支援FlashCom的Video Streaming。
  • 不支援Microphone Object,所以不要以為可以用手機錄音。
  • Flash Lite 2.0對手機硬體軟體提高了,最少要Series60 2nd Edition。所以我覺得Flash Lite對高手機性能要求本質沒有變,Flash Lite性能也沒有進步,只是貴價手機性能提高了,剛好可以跑Flash Lite 2.0。

(新增以橙色表示)

页数 勘误
第1章
18 [表1-3] 新版SEPY已经有「检查语法」功能
26 [第17行] 第5帧找->第1帧找
44 顶[4)总结] 第二和第三种次序乱了,换句话说,该段第3行:第种->第种、该段第5行前:第种->第种、该段第5行后:第种->第
74 [表2-2] 5011000元->501~1000元
 
第2章
103 [图2-24] 应该在[注意]之前
 
第4章
186 [图4-13] WebServices误指FlashCom
186 [图4-14] WebServices误指FlashCom
 
第5章
208 [第3行] 将mc4搬到mc1之上->将mc2搬到mc3之下
264 [图5-118] loginID_ti的属性应该是TextInput
283 [代码第23行]
place_cd->place_cb
285 最顶端的标题“以ActionScript控制滚动条”,应该放在第284页图5-141之下
289 [内文尾2行] 高度=Accordion.组件….,少个=
293 [代码尾2] 加入import MemSys.utils.PopUpWindow;(因为这个类在Accordion版没有需要,所以也要删除,光盘范例是正确,只是书漏了)
300 [中间内文] 修改GetPwdView类继承ScrollViewContent类
->修改LoginView类别继承FormNavigation类别
309 如果List有超过10选项,搬移后有些选项在原来List不能删去,原因在于程序里的dp.sortOn(”indexNo”),因为Array.sortOn默认任何数字/字符都是当作String来处理,要以数字处理的话,要改为dp.sortOn(”indexNo”, 16)。另外,var dp:Array = fromList.selectedItems.sort(); 的.sort()是多余。下载修正后list5.fla
334 [中间] createChildren():Void:单元格(Cell),应该是“定义
364 [程序代码第1行] 0xFFFFFFF多了一个F
 
第6章
401 [程序代码2]应加一个Tab在 LoadVars2.实例timeout = 新数值;
 
第7章
424 [图7-19] 排错了,正确图在此
 
第8章
458 [第二种做法的代码] var myResponder = new RelayResponder(this, “方法_Result”, “方法_Fault”);应该删去。下一句:var service:Service = new Service(”gateway路径”, null, “Remote service 名称或命名空间”, null, myResponder);中myResponder应该改为null

在HTML中傳送參數到Flash,常用的方法有兩種:路徑參數(foo.swf?par=123)或FlashVars(<param name=”FlashVars” value=”par=123″ />),參數又可以再分為是否URLEncoded;對於傳送中文,又再分為非Unicode(Big5/GB2312)和Unicode。最後IE和Mozilla處理上又有分別,換句話說,總共有2*2*2*2=16種可能性。

再加上SWF格式為Flash5或以前,Flash是用使用者系統編碼處理中文(非Unicode),Flash6或以後,Flash是用Unicode處理中文。因此,在HTML中傳送中文到Flash,看似很簡單的事,其實包含很多複雜的變化。(16*2=32種可能!!)

在新技術湧現的時代,要將參數傳送到Flash,可以用LoadVars、XML、Flash Remoting和Web Services等,但是在非Browser和連線的環境下,例如嵌入裝置、Flash嵌入其他程式和Server-side的Flash執行環境,仍然需要靠「路徑參數」這方法傳送參數到Flash。

以下講解會以Big5和Unicode為例,比較處理非Unicode和Unicode中文的分別,對於GB2312處理方法,跟Big5相同。第二,例子會用一個中英文混合句子來示範:

可以支援非Unicode的URLEncoded中文了!

Big5 URLEncoded為:

%A5i%A5H%A4%E4%B4%A9%ABDUnicode%AA%BAURLEncoded%A4%A4
%A4%E5%A4F%A1I

UTF-8 URLEncoded為:

%E5%8F%AF%E4%BB%A5%E6%94%AF%E6%8F%B4%E9%9D%9EUnicode
%E7%9A%84URLEncoded%E4%B8%AD%E6%96%87%E4%BA%86%EF%BC
%81

路徑參數

一個SWF格式為Flash6或以後,以路徑參數傳送中文,有以下結果:


Big5: debugTxt.swf?inTxt=%A5i%A5H…


Big5: debugTxt.swf?inTxt=可以…


UTF-8: debugTxt.swf?inTxt=%E5%8F…


UTF-8: debugTxt.swf?inTxt=可以…

Unicode當然沒有什麼問題,只是Big5 URLEncoded會出現亂碼,在Mozilla情況更壞,無論是否URLEncoded,都是亂碼。


Big5: debugTxt.swf?inTxt=%A5i%A5H…


Big5: debugTxt.swf?inTxt=可以…

第一個本能反應,當然是在Flash裡加上

System.useCodepage = true;

打開swfpath\original\debugTxt.fla看看,其實早已加了,但不起作用。因為所有參數都是在任何ActionScript執行前,已經進入了Flash,所以Flash是用Unicode去解碼這些URLEncoded的Big5,結果發生亂碼。

解決方法,當然是使Flash預設不是Unicode解碼,怎可能?將SWF發佈成Flash5就可以!Flash5的SWF只是一個加載器,主要用作接收參數,然後將真正的Flash加載到_level0,並傳入參數,這樣真正的Flash已經完全取代了Flash5的SWF,只要Flash Player是6/7,仍然可以執行Flash6/7支援的ActionScript。

loadMovieNum(”debugTxt2.swf?inTxt=”+inTxt, 0);

不過,唯一要留意,由於Flash接收時已經將參數URLDecoded,再傳入真正的Flash時,也是用Unicode去接收/解碼Big5的參數,仍有危機出現亂碼,因此應該將參數兩次URLEncoded,變成普通的英文字元:

loadMovieNum(”debugTxt2.swf?inTxt=”+escape(escape(inTxt)), 0);

到了真正的Flash時,先解除Flash預設的Unicode解碼,才去URLDecode接收的參數:

System.useCodepage = true;
debugtxt.text = unescape(inTxt);

[範例下載]

FlashVars

改用FlashVars傳送參數,無論IE/Mozilla,只有Big5 URLEncoded會出現亂碼,其他Big5 URLDecoded, UTF-8 URLEncoded/URLDecoded都是正常:


Big5: debugTxt.swf?inTxt=%A5i%A5H…


Big5: debugTxt.swf?inTxt=%A5i%A5H…

用剛才方法去解決,結果出現了亂碼:


Big5: debugTxt.swf?inTxt=%A5i%A5H…


Big5: debugTxt.swf?inTxt=%A5i%A5H…

在Flash5的SWF進行URLEncode時字與字之間多了%C2:

%C2%A5i%C2%A5H%C2%A4%E4%B4%A9%C2%ABDUnicode%C2%AA
%C2%BAURLEncoded%C2%A4%C2%A4%C2%A4%EF%BF%BD%C2%A1I

因此在真正的Flash,要將%C2弄走才進行URLDecode:

System.useCodepage = true;
inTxt = unescape(inTxt.split(”%C2″).join(”"));
debugtxt.text = inTxt

遺憾的是,有一些字元,在FlashVars傳到Flash時,已經被破壞了,最後仍然是亂碼,例如「文」字:


Big5: debugTxt.swf?inTxt=%A5i%A5H…


Big5: debugTxt.swf?inTxt=%A5i%A5H…

[範例下載]

URLEncoding其他參考資料

不要將其他Programming Language概念帶進ActionScript,ActionScript就是ActionScript,它有自己特點,不理解只會自討沒趣。

常常見到有人問怎樣做到C的Sleep,細問下原來他想載入外部數據,希望程序停下等候,等到數據載入再繼續執行,這是因為他不知道LoadVars.onLoad這東西;又有人常將Java OO概念搬到ActionScript 2.0,強行達到他們想要Reflection、Overload和各種古怪Composition,質問ActionScript 2.0為什麼沒有這東東,那東東時,先問問自己,對ActionScript了解是否足夠,ActionScript需要這樣做?有其他更簡單做法?Object設計出了問題?強行達到會否有副作用?國外大量人用ActionScript 2.0做著同樣的大型程序,難道人人都因為ActionScript 2.0不及Java而陷入苦戰?

ActionScript不是單純無形編程,還有面對Movie Clip這視覺化東西!

嚴禁轉載

要用Flash開發一個商貿網站,提供購物、預訂等服務,當使用信用卡付款時,涉及的技術問題,都比HTML製作網站複雜和困難。很多問題源自Flash先天特性、限制CrossDomain傳送的安全政策、付款公司只有HTML刷卡方法、技術人員不懂Flash、Pop-up Window攔截,網頁轉頁破壞Flash網站整體的User Experience等。

首先,無論是HTML或Flash商貿網站,整個付款流程是相同:

  1. 先在HTML(用Cookie/Session)或Flash收集好購物數量、總款、使用者聯絡資料;
  2. 傳到Server,儲存到Database,得到一個OrderID;然後,
  3. 將OrderID和總款傳到付款網頁,通常是第三方的公司提供;
  4. 使用者輸入信用卡資料;
  5. 刷卡,刷卡成功與否狀態,記錄第三方公司的Database;
  6. 由付款網頁傳回自己網站指定的網頁,顯示刷卡成功或失敗的訊息;
  7. 整個交易完成,自己網站發出確認電郵。

以上流程,以Flash製作的話,有幾點問題要考慮:

  • 第3步,Flash怎樣傳送資料到Domain不同的付款網頁?
  • 第4步,使用者可以在Flash裡輸入信用卡資料嗎?
  • 第6步,付款網頁怎樣通知Flash?
  • 如果使用者可以在Flash裡輸入信用卡資料,第3、5至6步能否在背後進行,避免任何轉頁或Pop-up Window破壞Flash網站整體的User Experience?

以下是幾種Flash商貿網站付款部分做法、概念、分析與比較(橙色流程中:粗體代表第三方Domain,下畫線代表處於SSL裡):

一、三次轉頁

流程:Flash→SSL付款網頁→結果網頁(HTML/另一個Flash)

這是最簡單、保守和保險的做法。第2步完成後,Flash用getURL連同OrderID和總款轉到付款網頁,例如:

getURL(”http://www.differentDomain.com/payment.cgi? orderID=BUY1001&price=100″);

使用者輸入信用卡資料,刷卡後,由付款網頁(最後將之前OrderID一併)傳回指定網頁,例如:

http://www.myDomain.com/afterPay.php?orderid=BUY1001&status=1

指定網頁將刷卡狀態寫入Database,然後顯示這成功或失敗畫面。這做法在開始付款後,其實已經離開了Flash,失去了購物過程的整體User Experience。

二、Pop-up Window

流程:Flash→[Pop-up Window]→SSL付款網頁→結果網頁(另一個Flash)→[LocalConnection]→通知Flash

流程跟做法一相同,只是改為Pop-up Window顯示SSL付款網頁,本來網頁仍然是該Flash,當刷卡後的指定網頁,是一個Flash,用LocalConnection通知主Flash結果,關閉自己Pop-up Window,主Flash顯示成功或失敗訊息。這做法是目前業界主流的做法,對User Experience影響較做法一少,但越來越多Pop-up Window攔截工具,對這做法有一定影響。開發時,不要直接用Flash Call JavaScript彈出Pop-up Window,通常自動彈出Pop-up Window一定被攔截了,加一個確認按鈕,使用者按下才彈出Pop-up Window,可以視為使用者自己打開,避免被攔截了。

注意:Pop-up Window一定要有Status Bar,作為顯示SSL的金色鎖頭,讓使用者安心。

三、Hidden Frame裡Hidden Form

流程:Flash(在Frame1)→[JavaScript]→Hidden Form(在Frame2)→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[LocalConnection]→通知Flash(在Frame1)

用一個上下形的Frameset(rows=”100%,*”),上面是Flash,下面是一個HTML Form,所有Value都是Hidden,所以稱為Hidden Form,當Flash收集了信用卡資料後,連同OrderID和總款,通過JavaScript,修改了Hidden Form裡各參數的值,然後Submit出去付款網頁POST連結,這樣可以避免了Flash限制CrossDomain傳送,同時付款網頁在處理後,下面Frame會轉到刷卡後的指定網頁,裡面有一個Flash,通過LocalConnection通知上面主Flash的刷卡結果。

這種最大好處是整個過程,對使用者來說都是在Flash裡完成,資料傳送完全在背後發生,對Flash網站整體的User Experience破壞是最小。

不過,要這樣做,有幾點要注意:

  1. 必須知道付款網頁POST那一步需要什麼參數,這要向付款公司查詢,或者自行看付款網頁的Source,找出有什麼參數。
  2. 下面的Hidden Form其實是處於自己Domain裡,一個沒有SSL保護的網站,雖然它的資料是傳到有SSL保護的付款網頁POST連結,由Non-SSL傳到SSL,其實等同沒有受SSL保護。因為SSL保護,是要求輸入資料那一頁,已經是在SSL裡,送出資料時,才可以用到SSL加密保護。
  3. 現在越來越多信用卡加入3D Secure功能,要求信用卡主再輸入密碼驗證,Hidden Frame根本沒有機會讓使用者看到這一頁,因此以上做法是行不通的。

流程:Flash(在Frame1)→[JavaScript]→SSL Hidden Form(在Frame2)→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[LocalConnection]→通知Flash(在Frame1)

如果付款公司肯幫忙,只要將Hidden Form那一頁放在他們的SSL保護Domain裡,就最好不過。這種做法,我認為是現實世界最可行和折衷的做法。

不過,由於Frame網頁混合了HTTP和HTTPS內容,瀏覽器Status Bar不會出現SSL的金色鎖頭,令使用者擔心。同樣地,混合Secure和Non-secure網頁在同一版,瀏覽器(IE預設安全層級)會攔截了Cookie/Session,影響將來可能交易運作。

四、Hidden Frame裡付款網頁

流程:Flash(在Frame1)→[JavaScript]→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[JavaScript][LocalConnection]→通知Flash(在Frame1)

用一個上下形的Frameset(rows=”100%,*”),上面是Flash,下面是付款網頁。這做法不過是做法一和二的變種,將付款網頁由另一頁/Pop-up Window放到下面Frame。當使用者確認付款時,將Frameset改為rows=”*, 100%”,等於隱藏Flash,顯示付款網頁;當刷卡後轉到指定網頁,再將Frameset改回rows=”100%, *”,顯示Flash,同時指定網頁會用LocalConnection通知主Flash刷卡狀態。

要動態控制Frameset大小,可以用JavaScript(假設JavaScript是放在其中一個Frame裡):

top.document.body.rows = “*,100%”;

這種做法,避免了做法三受去SSL保護的危險和不能進行信用卡密碼驗證,也避免了做法一Flash轉頁失去狀態,和做法二可能面對Pop-up Window被攔截。

不過,由於Frame網頁混合了HTTP和HTTPS內容,瀏覽器Status Bar不會出現SSL的金色鎖頭,令使用者擔心。同樣地,混合Secure和Non-secure網頁在同一版,瀏覽器(IE預設安全層級)會攔截了Cookie/Session,影響將來可能交易運作。

五、理想世界:自行開發付款閘,整個Flash在SSL裡

流程:SSL FlashSSL付款傳送(LoadVars/Flash Remoting)SSL 結果

當然,有能力自行開發連接銀行的付款閘,以上其他4種做法的缺點都一掃而空。現實中的付款公司,如果能明白到Flash商貿網站是最能夠吸引消費者,就要盡力提供能與Flash結合的連結和交易程序,這樣能夠提供一站式服務的付款公司,更能吸引更多優質客戶。

不過,在SSL裡東西,下載速度會受影響,比平常慢一點。

總結
實踐是驗證真理最好方法,現實中,做法一仍然是最好做法,唉……

其他參考連結

如果讀者想知道第二本書出版的消息,請在主頁的「第二本書」一欄加入你的電郵。

《Flash ActionScript 2.0與RIA應用程序開發》

第三篇:跟服務器連接篇

6. Flash MX或以前做法

6.1 loadVariable()、LoadVars對象和XML對象
 6.1.1 loadVariable()和LoadVars對象
 6.1.2 XML對象

6.2 進階探討
 6.2.1 封裝成ActionScript 2.0類
  6.2.1.1 LoadVars2類
  6.2.1.2 XML自動轉對象──XMD類
 6.2.2 範例:會員登入應用程序(五)
 6.2.3 Flash Player 7安全策略
 6.2.4 不良編程引致安全漏洞
  6.2.4.1 破解網域檢查
  6.2.4.2 破解會員登入應用程序
  6.2.4.3 安全編程建議
  6.2.4.4 HTTP與HTTPS之間連接

7. Flash MX 2004做法

7.1 Data Connection Wizard和DataGrid Column Editor
 7.1.1 下載和安裝
 7.1.2 使用方法

7.2 DataSet組件對數據存儲操作
 7.2.1 離線存儲操作──LocalShared對象
 7.2.2 在線存儲操作──RDBMSResolver組件
  7.2.2.1 PHP版
  7.2.2.2 ASP版
  7.2.2.3 離線在線混合版

8. Flash Remoting

8.1 Flash Remoting簡介
 8.1.1 你需要Flash Remoting嗎?
 8.1.2 Flash Remoting架構

8.2 安裝Flash Remoting
 8.2.1 AMFPHP版
  8.2.1.1 Windows
  8.2.1.2 Linux
  8.2.1.3 每個應用程序之文件架構
  8.2.2 .NET版
  8.2.2.1 安裝
  8.2.2.2 每個應用程序之文件架構

8.3 Flash Remoting開發步驟
 8.3.1 基本Remote Service編程
  8.3.1.1 PHP版
  8.3.1.2 ASP.NET版
 8.3.2 連接Flash Remoting
  8.3.2.1 ActionScript 1.0版
  8.3.2.2 RemotingConnector組件
  8.3.2.3 ActionScript 2.0版
  8.3.2.4 連接多個Remote Service的設計模式
 8.3.3 Flash Remoting連接數據庫
  8.3.3.1 PHP版
  8.3.3.2 ASP.NET版
  8.3.3.3 RecordSet操作
  8.3.3.4 RecordSet結合DataGrid組件顯示
  8.3.3.5 分頁顯示

9. Web Services

9.1 Web Services簡介

9.2 連接Web Services
 9.2.1 WebServiceConnector
 9.2.2 WebServiceClasses
 範例:各地天氣查詢
 9.2.3 小結:Web Services對Flash Remoting
 9.2.4 Flash Remoting連接Web Services
  9.2.4.1 PHP版
  9.2.4.2 ASP.NET版
9.3 總結:XML、Flash Remoting和Web Services

第四篇:其他開發知識篇

10. 開發秘技

10.1 本地化(Localization)
 10.1.1 Flash與中文之支持
 10.1.2 PHP中文轉碼方法
 10.1.3 製作應用程序多語言版本
10.2 動態改變Flash大小
10.3 Flash上傳文件
10.4 開發支持【上一頁】按鈕及直接網址的應用程序
10.5 Flash及RIA相關開發工具下載收集

在Flash Player 6或以前,利用loadVariables()、loadVariablesNum()、LoadVars()、XML.load()等載入外部數據,是不可以跨Domain,即在domainA.com的Flash不可以載入在domainB.com的數據(需要通過Middleware作中間人)。但載入Sub Domain的數據是容許,即放在www.luar.net、luar.net、foo.luar.net的Flash都可以載入在此3個不同的Sub Domain的數據。

Flash Player 7卻帶來了壞消息,它收緊了安全政策,載入Sub Domain的數據是不容許,不過這只對使用了Absolute Path的Flash有影響,例如loadVariablesNum(”http://www.domainA.com/data.txt”, 0),一般Web Server都可以設定短網址,例如http://domainA.com,如果Flash通過短網址載入,那麼載入外部數據就會受到影響。

Flash 6版本的Flash,在Flash Player 7播放會出現警告字句,需要訪客決定是否准許載入外部數據:

crossDomainAlert.gif

Flash 7版本的Flash,在Flash Player 7播放就索性沒有警告字句,根本載入外部數據的動作已經被否決了。

解決方法,製作一個名叫crossdomain.xml,放在外部數據的Server的root,即http://www.domainB.com/crossdomain.xml。XML文件裡,有一行:

<allow-access-from domain=”" />

你可以自行加入容許路徑,例如:

<allow-access-from domain=”*” />
<allow-access-from domain=”luar.net” />
<allow-access-from domain=”www.luar.net” />
<allow-access-from domain=”*.luar.net” />

通過加入crossdomain.xml,因此也帶來一個好消息Flash Player 7可以載入跨Domain的外部數據!無論是Flash 6或7版本的Flash,只要在Flash Player 7播放,domainB.com的Server有crossdomain.xml這文件,裡面有:

<allow-access-from domain=”*.domainA.com” /> 或
<allow-access-from domain=”*” /> 容許任何domain

在domainA.com的Flash就可以載入它的數據。

補充
Flash MX 2004 Professional提供了Data Binding, Web Services組件,網絡上有不少免費公開的Web Services,但是因為Flash Player 7這安全政策,根本得物而無所用,真荒謬!(除非那些Web Services網站可以加入crossdomain.xml)