Ⅰ php中 var_mp()輸出file_get_contents()獲得的內容 string(4) " 0" 為什麼 文件中只有一個0字元
var_mp 是直接輸出給屏幕,而不是返回一個變數。
你打代碼是
echofile_get_contents('這里是文件路徑');
Ⅱ 兩個php 文件。記事本打開完全相同,編碼也相同。相差3位元組
只能說你用的編輯器太差了
我用notepad++打開就直接能看到「1」(大的那個)顯示的是UTF-8編碼,2是ANSI編碼。
用ultraedit打開
可以看到utf8編碼文件里的三位元組的bom標記EFBBBF(位元組順序記號,byte-order mark)。如圖
這是用來表示文件是utf8編碼的標志
ansi編碼就沒有這個標志。
請採納
Ⅲ php生成的html meta和link標記在body標簽里 頂部有個空行
1.php中用smarty模板生成的html在瀏覽器中頂部有一空行.
2.用firedebug發現
meta和link標記在body標簽里.
本機上wmap運行沒事,
送到遠程伺服器上是IASP的服務,
會出現上述bug.
看了下源文件,
文本一樣的.
但保存時提示編碼問題.估計是utf-8問題了.
在網上找了下,
是utf-8
BOM問題.
解決方法:
用UltraEdit32把smarty模板文件即引用的模板文件(如include的header,footer等文件)全另存為無BOM的utf-8文件.
其它補充說明:
頁面採用UTF8編碼,頭部和尾部用了模板包含文檔的method,結果頭部和尾部無端端各多出一個約10px的空行,什麼也沒有。
原因是全部採用utf8編碼,包含文檔的時候,最後的二進制流中包含了多次UTF8
BOM標記,IE不能正常解析包含多個UTF8
BOM
標記的頁面,直接替換成實際顯示的回車,這樣導致一個空行,而firefox卻沒有這個問題。
故如果模板採用包含的method包含多個utf8文檔需要用ultraedit保存時另存為功能
選擇utf8
無bom格式保存即可。
另外,如果中文頁面在html
head標記中將title標記放在<meta
http-equiv=」Content-type」
Content=」text/html;
Charset=UTF-8″
/>前面會導致頁面空白。
所以utf8頁面應該使用標准順序
復制代碼
代碼如下:
<meta
http-equiv=」Content-type」
Content=」text/html;
Charset=UTF-8″
/>
<meta
http-equiv=」Content-language」
Content=」zh-CN」
/>
<meta
name=」robots」
Content=」index,follow」
/>
<meta
name=」keywords」
Content=」"
/>
<meta
name=」desCription」
Content=」"
/>
<meta
name=」rating」
Content=」general」
/>
<meta
name=」author」
Content=」"
/>
<meta
name=」Copyright」
Content=」"
/>
<meta
name=」generator」
Content=」"
/>
<title></title>
BOM頭:\xEF\xBB\xBF,PHP腳本4、5尚對BOM無視,所以在解析前直接輸出。
對此
w3.org
標准
FAQ
中對此問題有一個專門的描述:
www.w3.org/International/questions/qa-utf8-bom
具體如下:
在UCS
編碼中有一個叫做」ZERO
WIDTH
NO-BREAK
SPACE」的char,它的編碼是FEFF。而FFFE在UCS中是不存在的char,所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸位元組流前,先傳輸
char」ZERO
WIDTH
NO-BREAK
SPACE」。這樣如果接收者收到FEFF,就表明這個位元組流是Big-Endian的;如果收到FFFE,就表明這個位元組流是Little-
Endian的。因此char」ZERO
WIDTH
NO-BREAK
SPACE」又被稱作BOM。
UTF-8不需要BOM來表明位元組順序,但可以用BOM來表明編碼方式。char」ZERO
WIDTH
NO-BREAK
SPACE」的UTF-8編碼是EF
BB
BF。所以如果接收者收到以EF
BB
BF開頭的位元組流,就知道這是UTF-8編碼了。
Windows就是使用BOM來標記文本文檔的編碼方式的操作Systam:
WindowsXP
Professional
,
預設char集:中文
1)
notepad
:
可以自動識別出沒有帶
bom
的
utf-8
編碼格式文檔,但不可以控制保存文檔時是否添加
bom
,
如果保存文檔,那麼會統一添加
bom
。
2)editplus
:
不能自動識別出沒有
bom
的
utf-8
編碼格式文檔,文檔保存時,選擇UTF-8
格式,不會在文檔頭寫上
BOM
header.
3)
UltraEdit
:
對於char編碼的功能最為強大,
可以自動識別帶
bom
和不帶
bom
的
utf-8
文檔
(可以配置)
;
保存的時候可以通過配置選擇是否添加
bom.
(特別需要注意的是,保存一個新建立的文檔時,需要選擇另存為
utf-8
no
bom
格式)
後來發現
Notepad
++
也對於
utf-8
bom
支持比較好,推薦大家使用。
Ⅳ SVN如何限制某位用戶提交代碼的許可權
伺服器端 配置許可權文件 可以控制所有用戶的讀寫許可權。
轉自:http://www.cnblogs.com/xingchen/archive/2010/07/22/1782684.html
/***********************************************************/
//SVNSubversion 用戶許可權管理
//資料來源:網路、總結
//2010年7月20日
/***********************************************************/
基本的操作:
以我創建的Svn工程為例子來講解SVN許可權管理的配置
倉庫創建路徑:D:\SVNLibrary
>>>取消匿名登陸:
打開文件D:\SVNLibrary\conf\svnserve.conf
找到:###anon-access = read
將前面的注釋去掉,並將read 改為:none
即使:anoe-access=none 表示匿名登陸下的用戶許可權為空。即:系統不支持匿名登陸
說明:
auth-access = write #通過驗證的用戶可以讀和寫
auno-access = read #匿名登陸下可以只讀文件,即:文件修改後無法提交到伺服器
password-db =password #用戶保存文件的名稱
authz-db =authz #許可權管理文件 這個是非常重要的,如果我們要對整個工程的文件進行許可權分配的時候,就必須將這個行文件前面注釋掉,否咋即使我們在許可權配置文件裡面進行再多的配置都是無效的。這點我已經犯錯了。
然後我們在authz 文件下面進行許可權的分配
在許可權分配的時候要注意的問題:
>>>對某個用戶,如果只賦給他某個目錄的許可權,但對上級目錄沒有賦給,則他不能有上級目錄的任何許可權
例如某個用戶有:/repository/project1的r權,而沒有/repository的r權
>>>對於所有的目錄,都優先處理設置在這個目錄上的許可權設置。
例如sai用戶:
[/repository]
sai = rw
對於repository目錄,他有rw的許可權。
[/repository/project1]
sai = r
對於repository下的project1目錄,他只有r許可權。
則,這個saiy用戶只有project1的r權。而repository下其他目錄有rw權。
>>>許可權分配,只可以分配到某個目錄,而不能到某個文件
>>>如果某個目錄上沒有對某個用戶設置許可權,則一直向上級目錄查找,看是否有許可權
例如sai用戶
[/repository]
sai=rw
[/repository/project1]
saiya=rw
則sai用戶一樣擁有/repository/project1的讀寫許可權
>>>分配許可權時,= 的左邊為用戶,不能想當然的以,號分開加入多個用戶
>>>如果想設置某用戶都沒有rw的許可權,只要 = 號的右邊這空即可
User1 =
>>>如果某一個文件夾,對於人任何用戶都沒有許可權
* =
其中*代表所有的人
SVN深入的部分
本章將詳細介紹前一章所涉及的兩個配置文件, svnserve.conf 和 authz.conf,通過對配置逐行的描述,來闡明其中的一些細節含義。
這
里首先要注意一點,任何配置文件的有效配置行,都不允許存在前置空格,否則程序會無法識別。也就是說,如果你直接從本文的純文本格式中拷貝了相關的配置行
過去,需要手動將前置的4個空格全部刪除。當然了,如果你覺得一下子要刪除好多行的同樣數目的前置空格是一件苦差使,那麼也許 UltraEdit
的「Column Mode」編輯模式,可以給你很大幫助呢。
1 svnserve.conf
arm\conf\svnserve.conf 文件,是 svnserve.exe 這個伺服器進程的配置文件,我們逐行解釋如下。
首先,我們告訴 svnserve.exe,用戶名與密碼放在 passwd.conf 文件下。當然,你可以改成任意的有效文件名,比如默認的就是 passwd:
password-db = passwd.conf
接
下來這兩行的意思,是說只允許經過驗證的用戶,方可訪問代碼庫。 那麼哪些是「經過驗證的」用戶呢?噢,當然,就是前面說那些在
passwd.conf 文件裡面持有用戶名密碼的傢伙。這兩行的等號後面,目前只允許 read write none
三種值,你如果想實現一些特殊的值,比如說「read-once」之類的,建議你自己動手改源代碼,反正它也是自由軟體:
anon-access = none
auth-access = write
接下來就是最關鍵的一句呢,它告訴 svnserve.exe,項目目錄訪問許可權的相關配置是放在 authz.conf 文件里:
authz-db = authz.conf
當
然,svn 1.3.2 引入本功能的時候,系統默認使用 authz 而不是 authz.conf
作為配置文件。不過由於鄙人是處女座的,有著強烈的完美主義情結,看著 svnserve.conf 有後綴而 passwd 和 authz
沒有就是不爽,硬是要改了。
2 authz.conf 之用戶分組
arm\conf\authz.conf 文件的配置段,可以分為兩類,``[group]`` 是一類,裡面放置著所有用戶分組信息。其餘以 [arm:/] 開頭的是另外一類,每一段就是對應著項目的一個目錄,其目錄相關許可權,就在此段內設置。
首先,我們將人員分組管理,以便以後由於人員變動而需要重新設置許可權時候,盡量少改動東西。我們一共設置了5個用戶分組,分組名稱統一採用 g_ 前綴,以方便識別。當然了,分組成員之間採用逗號隔開:
[groups]
# 任何想要查看所有文檔的非本部門人士
g_vip = morson
# 經理
g_manager = michael
# 北京辦人員
g_beijing = scofield
# 上海辦人員
g_shanghai = lincon
# 總部一般員工
g_headquarters = rory, linda
# 小秘,撰寫文檔
g_docs = linda
注
意到沒有, linda 這個帳號同時存在「總部」和「文檔員」兩個分組裡面,這可不是我老眼昏花寫錯了,是因為 svnserve.exe
允許我這樣設置。它意味著,這個傢伙所擁有的許可權,將會比他的同事 rory 要多一些,這樣的確很方便。具體多了哪些呢?請往下看!
3 authz.conf 之項目根目錄
接著,我們對項目根目錄做了限制,該目錄只允許arm事業部的經理才能修改,其他人都只能眼巴巴的看著:
[arm:/]
@g_manager = rw
* = r
[arm:/] 表示這個目錄結構的相對根節點,或者說是 arm 項目的根目錄
這里的 @ 表示接下來的是一個組名,不是用戶名。你當然也可以將 @g_manager=rw 這一行替換成 michael=rw ,而表達的意義完全一樣。
* 表示「除了上面提到的那些人之外的其餘所有人」,也就是「除了部門經理外的其他所有人」,當然也包括總經理那個怪老頭
* = r 則表示「那些人只能讀,不能寫」
4 authz.conf 之項目子目錄
然後,我們要給總部人員開放日誌目錄的讀寫許可權:
[arm:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =
我
敢打賭,設計svn的傢伙們,大部分都是在 unix/linux 平台下工作,所以他們總喜歡使用 / 來標識子目錄,而完全忽視在 MS
Windows 下是用 \ 來做同樣的事情。所以這兒,為了表示 arm\diary\headquarters 這個目錄,我們必須使用
[arm:/diary/headquarters] 這樣的格式。
這里最後一行的 *= 表示,除了經理、總部人員、特別人士之外,任何人都被禁止訪問本目錄。這一行是否可以省略呢?
之所以這兒需要將 @g_vip=r 一句加上,就是因為存在上述這個解釋。如果說你沒有明確地給總經理授予讀的權力,則他會和其他人一樣,被 * 給排除在外。
如果眾位看官中間,有誰玩過防火牆配置的話,可能會感覺上述的配置很熟悉。不過這里有一點與防火牆配置不一樣,那就是各個配置行之間,沒有 先後順序 一說。也就是說,如果我將本段配置的 *= 這一行挪到最前面,完全不影響整個配置的最終效果。
請注意這兒,我們並沒有給 arm\diary 目錄設置許可權,就直接跳到其子目錄下進行設置了。我當然是故意這樣的,因為我想在這兒引入「繼承」的概念。
許可權具備繼承性 任何子目錄,均可繼承其父目錄的所有許可權,除非它自己被明確設置了其他的許可權。也就是說,在 arm 目錄設置許可權後, arm\diary 目錄沒有進行設置,就意味著它的許可權與 arm 目錄一樣,都是只有經理才有權讀寫,其他人只能乾瞪眼。
【 * = 是否可以省略】【用例子引入覆蓋】【單用戶許可權的繼承問題】【父目錄許可權集成與全面覆蓋問題】
現在來看看
好了,我們現在掌握了 「繼承」的威力,它讓我們節省了不少敲鍵盤的時間。可是現在又有一個問題了,
屬性具備覆蓋性質子目錄若設置了屬性,則完全覆蓋父目錄。
5 authz.conf 的其他注意點
父目錄的 r 許可權,對子目錄 w 許可權的影響
把
這個問題專門提出來,是因為在1.3.1及其以前的版本裡面,有個bug,即為了子目錄的寫許可權,項目首目錄必須具備讀許可權。因此現在使用了1.3.2版
本,就方便了那些想在一個代碼庫存放多個相互獨立的項目的管理員,來分配許可權了。比如說央舜公司建立一個大的代碼庫用於存放所有員工日誌,叫做
diary,而arm事業部只是其中一個部門,則可以這樣做:
[diary:/]
@g_chief_manager = rw
[diary:/arm]
@g_arm_manager = rw
@g_arm = r
這
樣,對於所有arm事業部的人員來說,就可以將 svn://192.168.0.1/diary/arm
這個URL當作根目錄來進行日常操作,而完全不管它其實只是一個子目錄,並且當有少數好奇心比較強的人想試著 checkout 一下
svn://192.168.0.1/diary 的時候,馬上就會得到一個警告「Access deni」,哇,太酷了。
默認許可權
如果說我對某個目錄不設置任何許可權,會怎樣?馬上動手做個試驗,將:
[diary:/]
@g_chief_manager = rw
改成:
[diary:/]
# @g_chief_manager = rw
這樣就相當於什麼都沒有設置。在我的 svn 1.3.2 版本上,此時是禁止任何訪問。也就是說,如果你想要讓某人訪問某目錄,你一定要顯式指明這一點。這個策略,看起來與防火牆的策略是一致的。
只讀許可權帶來的一個小副作用
若設置了:
[arm:/diary]
* = r
則svnserve認為,任何人,都不允許改動diary目錄,包括刪除和改名,和新增。
也就是說,如果你在項目初期創建目錄時候,一不小心寫錯目錄名稱,比如因拼寫錯誤寫成 dairy,以後除非你改動 authz.conf 裡面的這行設置,否則無法利用 svn mv 命令將錯誤的目錄更正。
改進
1 對中文目錄的支持
上
午上班的時候,Morson 來到 Michael
的桌子前面,說道:「你是否可以將我們的北京辦、上海辦目錄,改成用中文的,看著那些拼音我覺得很難受?」 Michael
心想,還好這兩天剛了解了一些與 unicode 編碼相關的知識,於是微笑地回答:「當然可以,你明天下午就可以看到中文目錄名稱了。」
使用 svn mv 指令,將原來的一些目錄改名並 commit 入代碼庫,改名後的目錄結構如下:
arm
├─工作日誌
│ ├─ 總部人員
│ ├─北京辦
│ └─上海辦
├─公司公共文件參考目錄
└─臨時文件存放處
修改代碼庫的 authz.conf 文件,將相應目錄逐一改名
使用 UltraEdit 將 authz.conf 文件轉換成不帶 BOM 的 UTF-8 格式
將
配置文件轉換成 UTF-8 格式之後,Subversion 就能夠正確識別中文字元了。但是這里需要注意一點,即必須保證 UTF-8 文件不包含
BOM 。BOM 是 Byte Order Mark 的縮寫,指 UNICODE 文件頭部用於指明高低位元組排列順序的幾個字元,通常是 FFFE
,而將之用 UTF-8 編碼之後,就是 EFBBBF 。由於 UTF-8 文件本身不存在位元組序問題,所以對 UTF-16
等編碼方式有重大意義的 BOM,對於 UTF-8 來說,只有一個作用——表明這個文件是 UTF-8 格式。由於 BOM
會給文本處理帶來很多難題,所以現在很多軟體都要求使用不帶 BOM 的 UTF-8 文件,特別是一些處理文本的軟體,如 PHP、 UNIX
腳本文件等,svn 也是如此。
目前常用的一些文本編輯工具中,MS Windows 自帶的「記事本」裡面,「另存為」菜單保存出來的
UTF-8 格式文件,會自動帶上 BOM 。新版本 UltraEdit 提供了選項,允許用戶選擇是否需要 BOM,而老版本的不會添加
BOM。請各位查看一下自己常用的編輯器的說明文件,看看它是否支持這個功能。
利用 UltraEdit ,我們可以將 BOM 去掉。方法是,首先利用「UTF-8 TO ASCII」菜單將文件轉換成本地編碼,通常是GB2312碼,然後再使用「ASCII TO UTF-8(UNICODE Editing)」來轉換到 UTF-8 即可。