facebook api笔记

有些东西试验了一下,虽不成体系,但是放在博客上还是方便查找,所以芝麻一堆枣一堆的放上来了。

 

facebook api虽据称”荣获”最差api之列,但是我使用一下似乎还可以。

 

主要是graphic api和fql

 

文档:

http://developers.facebook.com/docs/reference/apis/

 

好用的api浏览器工具:

http://developers.facebook.com/tools/explorer

 

fql查询某个文档(post,link,图片…)的评论:

SELECT text FROM comment WHERE object_id in (
SELECT id FROM object_url WHERE url = 'http://www.facebook.com/photo.php?fbid=505965652779699&set=a.456536471055951.101000.190638967645704&type=1'
)

 

 

上面的链接是随便选的,勿要深究,因为必须是个公开的链接,如果是不公开的链接,那么会返回空数据,你不知道到底是没有评论还是未公开的原因。

Continue reading facebook api笔记

windows下左右键互换程序 Dephi源码

这天发现原来用的左右键互换被删了,翻了半天代码找到了这个左右键互换的dephi工程,这里就传上来,免得时代久远又搞忘了。代码在此,也就放心不会有毒了,确实不放心可再编译一次,非常小。

 

 

 

程序:

http://kazge.com/wp-content/uploads/2013/02/MouseSwap.exe

 

源码Dephi工程:

http://kazge.com/wp-content/uploads/2013/02/mouseswap.zip

Continue reading windows下左右键互换程序 Dephi源码

php 面向对象相关

构造函数的问题:

 

第一种情况:子类没有定义构造函数时,默认继承。

第二种情况:子类定义了构造函数,则不会被继承。

对于4.x,如果父类恰好定义了子类的同名函数,则会被当做子类的构造函数:

name="code" class="php:firstline[1]">class A { function A() { echo "I am the constructor of A.<br>\n"; }

Continue reading php 面向对象相关

跨源共享(CORS)的一点疑惑

大家都熟悉同源法则http://www.w3.org/Security/wiki/Same_Origin_Policy

现在w3c又出了跨源共享机制http://www.w3.org/TR/cors/#cors-api-specification-security

 

我有点迷糊的就是,同源法则就是出于安全的考虑禁止对其它源的访问,但是它仍然不能保证跨站脚本的攻击。同源法则也导致正常的跨域请求实现很麻烦,然而这个跨域同源机制的控制却又是在其它源服务器上(通过发Access-Control-Allow-Origin 头),而不是本源服务器或代码。

 

我就很纠结这个,照我想,安全控制应该是本源的事,是否可访问其它源应有本源来控制,如果这样的话,本源正常的跨源访问就很方便了。而实际上为什么要其它源来控制是否可访问呢,这对于跨站脚本倒是个好事,它肯定乐意跨源来执行它的脚本了。

 

我自己的理解是,从字面上看共享这个词就是控制资源是否可以共享,这个机制是控制本站资源是否允许被其它站点访问。

 

这个解释我自己都说不过去啊,公开的站点哪需要这个多余的机制来控制呢,而对于正常的跨域请求,这个机制还是不方便呢。

 

搞不清白!

 

 

参见:

http://blog.csdn.net/net_lover/article/details/5172509

Continue reading 跨源共享(CORS)的一点疑惑

php 打印error trace

对于php的Exception,可以通过getTraceAsString获得错误栈。

 

而对于error则应该如下:

 

function x()	
	$x = debug_backtrace();
	//remove stack of this function
	array_shift($x);
	$i = 0;
	$xstr = '';
	foreach ($trace as $x) {
		//TODO need check exists args
		$args = $x['args'];
		if (!$args) {
			$argstr = '';
		} else {
			$argstr = '';
			$first = true;
			foreach ($args as $arg) {
				if (!$first) {
					$argstr .= ',';					
				}
				$first = false;
				if (is_object($arg)) {
					$argstr .= 'Object[' . get_class($arg) . ']';
				}
				elseif (is_array($arg)) {
					$argstr .= 'Array';
				} else {
					$argstr .= $arg;
				}
			}
		}
		$xstr .= "[#$i] {$x['file']}({$x['line']}) {$x['function']} ($argstr)" . PHP_EOL;
		$i++;
	}
	
	return $xstr;
}

 

 

参见:

http://jarofgreen.co.uk/2011/02/more-php-error-handling-tips/

Continue reading php 打印error trace

Openfire Bosh 配合strophe.js使用

这次试了一下Openfire的Bosh协议以及strophe.js,记录一下。

 

 

有两个问题要注意:

1:直接使用javascript调用bosh往往存在同源原则的问题,例如localhost:80端口下的页面脚本要访问Bosh服务localhost:7070,那么这个ajax访问就会失败,因为违背了同源法则。(这使得我又回去看了一下cookie的问题https://blog.kazge.com/web/2012/08/26/e5-86-8d-e8-b0-88p3p-e4-b8-8e-e7-ac-ac-e4-b8-89-e6-96-b9cookie/,cookie保存却又不区分端口)因此,我们要么使用跨域插件fkXHR要么在服务器上配置代理来使bosh服务与发起请求页面“同源”。

例如apache里面在 httpd.conf 中加入下面几行:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

 

ProxyRequests Off
ProxyPass /xmpp-http http://127.0.0.1:7070
ProxyPassReverse /xmpp-http http://127.0.0.1:7070
<proxy http://127.0.0.1:7070>
    AddDefaultCharset off
    AllowOverride None
    Order Deny,Allow    
    Allow from all
</proxy>

 

上面的配置将apache监听端口下/xmpp-http 反向代理到了http://127.0.0.1:7070

 

2: 这其实和上面的第一个问题相关,如果遇到400 Bad Request的问题,你要检查你的代理配置和你请求的url, 很可能是掉了最后的反斜杠/,这个是反向代理常犯的错误。以上面的配置为例,则bosh的url应该为localhost/xmpp-http/http-bind/

[为方便国外鸟:]

if you encounter the error response from the xmpp BOSH server, you should check your url with your proxy configuration, it is you miss the last backslash of the BOSH service’s url in your javascript in most case. for example, if you make the proxy like “ProxyPassReverse /xmpp-http http://127.0.0.1:7070” then your BOSH url should be localhost/xmpp-http/http-bind/, note the last backslash.

 

使用示例官方下载包example文件夹中有。

 

这个strophe有个奇怪的行为,其Strophe.Connection.connect方法当传入的不带域名时,会尝试匿名登录。而如果传入bareJid(像[email protected]),如果密码错了或是用户名不存在,则一直没返回。

 

参见:

http://mineral.iteye.com/blog/448260

http://www.ibm.com/developerworks/cn/xml/tutorials/x-realtimeXMPPtut/section6.html

Continue reading Openfire Bosh 配合strophe.js使用

Google Speech Api使用

语音识别里,Google 现在是个Big Gun了,但是它没有公开它的API,也没有发售,许多程序使用这个api也是hack性质的,使用这种服务可能出现的问题就如Google Weather最近的更改一样。我从没想到竟然有人想拿它作为产品级别的应用服务,不过我已经比较淡定了,就像我没想到有人天天喊做震惊世界的软件,却成天想用抠门的态度来获得一本万利的回报,又想牛儿长得好又想牛儿不吃草!

嘛,嘛,嘛~ 扯远了,打住,00F829F7

 

 

从各方搜集到的情报来看,此服务性能还不错,虽然支持wav格式,但似乎官方推荐flac格式,所以我们还得转换一下,在java这方面就不得不提到两个开源项目:

https://github.com/The-Shadow/java-speech-api 这个里面包含了使用Google Speech Api的代码,可以参照,它是用了另外的一个项目

http://sourceforge.net/projects/javaflacencoder/

来转换wav到flac.

 

知道这两个事情,余下的就好办了,

请求头示例

Content-Type:audio/x-flac;rate=8000

请求地址

https://www.google.com/speech-api/v1/recognize?xjerr=1&client=chromium&lang=en-US

 

向其post你的flac流,得到的将会是解析结果,类似:

{"status":0,"id":"46f00c9fe47a4dfe3c97ae4076df726u-1","hypotheses":[{"utterance":"gong xi fa cai","confidence":0.9049254}]}

 

测试效果比较满意,国内访问相应速度堪忧,经常连不上,使用代理那速度就非常不错了。

 

代码我就不贴了。

 

 

这篇文章讲得比较详细: http://blog.csdn.net/dlangu0393/article/details/7214728

 

引用:

多种音频格式的测试

    收到朋友的邮件说使用flac实在是很不方便,问我有没有更好的解决方法,于是我尝试将其他编码格式应用于Google Speech API。以下为结果:

    1、WAV格式

    请求Header:Content-Type: audio/L16; rate=16000

    返回结果:识别成功

    2、MP3格式

    请求Header:Content-Type: audio/mpeg; rate=16000

    返回结果:无法识别的编码

    请求Header:Content-Type: audio/mpeg3; rate=16000

    返回结果:无法识别的编码

    请求Header:Content-Type: audio/x-mpeg; rate=16000

    返回结果:无法识别的编码

    请求Header:Content-Type: audio/x-mpeg-3; rate=16000

    返回结果:无法识别的编码

    请求Header:Content-Type: audio/mp3; rate=16000

    返回结果:无法识别的编码

    3、PCM格式

    请求Header:Content-Type: audio/x-ogg-pcm; rate=16000

    返回结果:无法识别的编码

    请求Header:Content-Type: audio/pcm; rate=16000

    返回结果:无法识别的编码

    4、SPEEX格式

    请求Header:Content-Type: audio/x-speex-with-header-byte; rate=16000

    返回结果:识别成功

    请求Header:Content-Type: audio/speex; rate=16000

    返回结果:识别成功

 

 

参见:

http://stackoverflow.com/questions/12721436/google-speech-api

http://mikepultz.com/2011/03/accessing-google-speech-api-chrome-11/

http://blog.csdn.net/dlangu0393/article/details/7214728

Continue reading Google Speech Api使用

Android Basic验证造成的问题

今天是元旦,节日快乐。

 

我这两天就为这个问题,晚上终于解决了。

 

问题是这样的,我写个Android程序访问http服务,服务端使用Http Basic验证。开始使用的是httpclient,先用jvm测试,访问成功。然后用android UnitTest就不行了,返回错误是

400

Bad Request
Your browser sent a request that this server could not understand.
 
apache的错误是
client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23) 
 
这我就纳闷了,刚开始还以为是https配置错误(服务端使用的是ssl)。
结果切换为http还是一样的错误。
 
于是乎我就找到了
http://stackoverflow.com/questions/12418458/client-sent-http-1-1-request-without-hostname-see-rfc2616-section-14-23-from/12434731#12434731
 
这位老兄和我一样的情况,最后他说是android 上http请求host头没设置造成的。
(就是他害我思路错误啊!)
 
我也试了一下,加了个Host头,而且要放在Authentication头之前。 
这样client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23) 
这个错倒是没有了,但是发现发送的内容服务器接收不到。
 
那就只好看看到底发的是什么东西了,这里要用到tcpdump:
具体见http://www.growprogress.com/vcommon/?p=1293 
使用http://www.strazzere.com/android/tcpdump 这个链接下载android上可运行的较好。
 
当获得日志后还要配合wireshark来分析。
wireshark需要先启动npf http://ask.wireshark.org/questions/1281/npf-driver-problem-in-windows-7

sc qc npf查询npf是否运行
sc start npf启动npf

 

我也试过直接wireshark监控模拟器或android-x86的请求,但是看不到,还是需要通过tcpdump。

 

如果是ssl请求那就更麻烦了,参见http://blog.csdn.net/jasonhwang/article/details/2350723

因此我是切换到http来测试的。

 

从请求中没看到什么问题(这里又犯错误,问题就在这里,没有仔细比较,所以没看出来)

 

于是怀疑是不是httpclient有问题,巧的是就有文章说这个问题 http://jackyrong.iteye.com/blog/1228220

 
另外这个项目更新了android自带的httpclient
https://code.google.com/p/httpclientandroidlib/
 
于是乎我就切换到httpurlconnection,把我的工具类重写了一遍……
 
结果,还是一样的问题,OMG,简直要崩溃了,这时脑子也很疲劳了,
一段时间来对Android的牢骚几乎就要爆发了(这个牢骚免不了,日后定一吐为快……)。
 
就在这时,这篇文章救了我 
http://stackoverflow.com/questions/5092561/http-post-request-with-authorization-on-android/5095189#5095189
原来是Android上Basic编码的问题,多了个换行符,
怪不得Host放在Basic64编码之前就不报client sent HTTP/1.1 request without hostname  这个错。
而且我想起来tcpdump日志看起来有点怪,原来是这个问题。
 
解决方案就是
 private String getB64Auth (String login, String pass) {
   String source=login+":"+pass;
   String ret="Basic "+Base64.encodeToString(source.getBytes(),Base64.URL_SAFE|Base64.NO_WRAP);
   return ret;
 }
 
测试通过,真是无语啊。
 
为什么我不是高富帅,
如果我是高富帅,
我就吃苹果去了,
左手ipad,
右手iphone,
膝上托着macbook pro……
 

Continue reading Android Basic验证造成的问题

Pagination


Total views.

© 2013 - 2019. All rights reserved.

Powered by Hydejack v6.6.1