伊莉討論區

標題: 關於Python分割文件無法執行，麻煩有空的前輩指點 [打印本頁]
作者: chialewang    時間: 2019-8-29 06:54 PM     標題: 關於Python分割文件無法執行，麻煩有空的前輩指點

提示: 作者被禁止或刪除 內容自動屏蔽
作者: tryit244178    時間: 2019-8-30 09:21 AM

本帖最後由 tryit244178 於 2019-8-30 09:22 AM 編輯

錯誤訊息裡面有寫，錯在第15行。你再檢查一下
作者: chialewang    時間: 2019-8-30 09:39 PM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: ddttdtxb    時間: 2019-8-30 09:45 PM

本帖最後由 ddttdtxb 於 2019-8-30 09:45 PM 編輯

看懂程式是在作什麼的，覺得怪怪的。
就把要解析的東西，或是解析的結果印出來… 多用 print 。
反正修完的再刪掉就好。

看懂程式很重要，所以講第二遍。
除了樓上提到的第一個錯誤…  (基本語法不熟)
另外有許多地方 "."(英文句號) 和 "_"(底線) 打錯了，
因為這兩符號在鍵盤上的位置離很遠，除非樓主鍵盤比較特殊。
不然應該是程式沒讀懂，照打程式碼的時候看錯了。

相信你你改完之會有所發覺，成長。

對了… 最後補一點。
你解析文件，冒號是全形 "︰" ，
但是程式碼的符號是半形 ":" 。 (我故意上下排，比較看得出是不同東西)
這點可能比較難找到，要被它搞過幾次的人才有感覺…

曾經有一段時間流行一個笑話…
要嚇一個軟體工程師，只要小聲在他的耳邊說…
「你的程式碼裡有個全形空白~~~」
(有點冷…  但是被搞過的人會心有戚戚焉…)
作者: chialewang    時間: 2019-8-31 05:45 PM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: ddttdtxb    時間: 2019-8-31 06:41 PM

  1. line 22, in split_file
  2. for each_line in f:
複製代碼
除了這個之外，應該還有其它的紅字吧！  不要讓人猜錯誤訊息…

難不成… 真的遇到傳說中的「全形空白」了嗎？ XD
作者: chialewang    時間: 2019-9-1 07:05 PM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: tryit244178    時間: 2019-9-2 09:20 AM

本帖最後由 tryit244178 於 2019-9-2 09:30 AM 編輯

最下面有UnicodeDecodeError的錯誤訊息…
詳細請參考https://www.ptt.cc/bbs/Python/M.1380034106.A.553.html

這的確也是一種另類的全形空白www

作者: chialewang    時間: 2019-9-3 11:12 AM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: chialewang    時間: 2019-9-3 11:23 AM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: chialewang    時間: 2019-9-5 10:34 AM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: chialewang    時間: 2019-9-5 04:14 PM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: tryit244178    時間: 2019-9-6 09:05 AM

本帖最後由 tryit244178 於 2019-9-6 09:38 AM 編輯

這好像是不同的問題，試試這個：https://www.twblogs.net/a/5c67c900bd9eee01cc9e17f7
這麼說來，你開課了嗎？

作者: chialewang    時間: 2019-9-7 12:01 PM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: ddttdtxb    時間: 2019-9-7 06:40 PM

本帖最後由 ddttdtxb 於 2019-9-9 10:09 PM 編輯

前幾天狀況比較差… 就沒回覆了… (不久剛換工作… 融入新開發流程… 滿燒腦的…)

看到又是一個「書本上不見得會教的東西」，也算滿難得的經驗吧！
以下這段有點長… 算是電腦發展的歷史，有不少的地方是由我自己想像補完的。
所以如果有人發現有錯的地方，就指正一下囉~  (我不是，目前也沒有作電腦歷史學長的想法)

以 0, 1 為基礎的電腦，使用 8 個位元來記錄文字。8 個位元(bit)…也叫 1 位元組(1 byte)。
所以能夠表現的文字數量為 2 的 8 次方，也就是 256 個(0 ~ 255) → ASCII 編碼。
在 C 語言裡面，有個型態叫作字元(char)，就代表這種東西…
因為骨子裡是數字，所以可以被作加減運算…  

以 ASCII 的內容，對文字處理上相對簡單，每一個位元就代表著一個字，
解析上容易，儲存上也省空間，但是能夠表現的文字受限，也就是不夠多。
所以後來被採用的其中一種作法，就是多加一個位元來表示，變成「雙位元」文字。
雙位元文字，印象中就不能(或不適合)以 C 語言的 char 處理。
(話說… 常見的高階語言，其實把文字處理包起來，不太需要處理到字元就是了)

在中文輸入法中，有全形和半形文字之分。
在早期的文字編碼中，可以把半形視為單位元，全形視為雙位元。

兩個位元組，也就是 16 bit ，理論上可以提供 2 的 16 次方，也就是 65536 種組合。
不過由於得讓電腦得以識別接下來的文字是單位元，還是雙位元。所以實際組合沒那麼多。
印象中，中文常用文字好像就 6 萬多個，在台灣這邊，是取較常用的 4 萬多個字出來。
這個編碼叫作 BIG5 ，也有人叫它「大五碼」。而大陸那裡也有自己幾套，名稱多是 GB 開頭。

因為在那個年代，記憶體是很貴的東東，所以不管在哪個方面，使用上都得很省很省。
所以既使知道雙位元仍然不足以把所有的中文字塞進去，但仍然只用雙位元來表示。
折衷的方法，就是不把所有的組合用完，保留一部未定義的空間，讓有需要的人去增加。
未被包含進去的文字，被歸類為罕用字，許多的時候出現在人名，事物名稱上。
所以早期的 window 裡還有內建造字程式，早期銀行為了能記錄客戶的姓名，也得自己造字。
而字型商(字造完總是要顯示、列印出來)也有因此提供的一些「解決方案」。

冷知識，所以早期銀行之間的資料，不能互通。因為同一個文字碼，在另一家銀行可能表示另一個文字。

網際網路的出現，讓使用不同語系的使用者，可能會開使用不用編碼的網站。
網頁 html 內容中，需要在一開始宣告這個檔案使用的編碼，免得出錯。造成結果為「亂碼」…
所以宣告網站使用編碼的地方，前面最好不要有非 ASCII 能表現的文字，否則可能會出錯。
至今，這個宣告仍然是 html 中很重要的部分。

終於來到了近代，電腦變強了，記憶體變多了。
在一個網頁中(或文件)中使用到多國文字的需求也越強。
雖然中間出現過把平、片假名加到罕用字，想讓日文、中文能用一套編碼表示的作法。
不過需要顯示的文字數量太多，仍然不夠放。

所以後來就有人提出「萬國碼」也就是 unicode 。概念上就是任何一個文字，
都能夠 unicode 中有一個獨立的編碼，讓不同語系的文字分開，不會重覆使用編碼。
如此理論上，就可以顯示這世界上，甚至是未來新出現的文字…
然後問題就會變成… 電腦裡的字型檔，顯不顯得出這個文字。
(有些時候電腦，或網頁出出現種俗程 叉燒包 "☒" 的東東，就是因為字型沒這個字的關係)

萬國碼依照解析方式，有分不同的版本。
而常見的 UTF-8 ，是一種可能由 1 ~ 6 個位元組的編碼方式，並不像早期固定雙位元。
所以全形字的定義，得被改為「多位元」而非雙位元了。
至於詳細的計算方式，大多內建在多種程式語言中，一般撰寫程式上不用自己去算。

回到主題上，由於程式裡，解析的資料中，可能會出現多位元的內容。
所以如果在解析資料的時候，採用錯誤的規則，那文字就會解析失敗。
如果是出現在被讀入分析的資料上，就會像這次樓主遇到的拆文字失敗的狀況。
如果是出現在程式內容，就會發生程式解析或編譯失敗。
這也是「全形空白」這種肉眼看不見的，但在程式解析上造成不合法的字元，
讓人很頭痛的原因。

現在瀏覽器很強大，當你貼文字上去的時候，會自動把你的編碼，
轉成網站所宣告的那一種，所以有時候遇到編碼問題的程式，貼到網路上就正常。
就是這個原因，因為本來有的編碼問題，在貼上的時候被處理掉了。
在本機的文字編輯器，就得注意存檔所使用的編碼。
不過現在不要太舊的文字編輯器(不含記事本這種)，預設多半是 UTF-8 了，所以遇到問題的機會就更小了。

電腦目前常見的作業系統分為兩類，微軟的 window 一派與 UNIX-like 一派(linux, mac)。
UNIX-like 在很早之前就轉到 UTF-8 的陣營了，所以問題比較少一些。
而 window 則是由一堆歷史因素，以及得向前相容，現在還並非真正使用 UTF-8 編碼。
而 CP950 ，實際上並非特定一種編碼方式，它是代表「當下系統預設的文字編碼」
在繁中的電腦上，可能與 BIG5 編碼等義，而大陸的可能是 GB 編碼。

樓主遇到的狀況，就是程式以系統預設的編碼(CP950， 可能是 BIG5)讀，
但是檔案從一開始就是 UTF-8 的編碼格式，所以結果當然就是解析失敗囉~~
而網站上，大多都是 linux 基底(UTF-8)，貼上資料時也轉 UTF-8 過，所以不會出事。

這種問題個人的觀點… 在最近幾年內的 windows 系統下，可能不會真正轉到 UTF-8 。
所以在 windows 系統下讀取帶多位元資料的檔案，最好統統都指定編碼，是最保險的作法。

(本來以為短短可以寫完… 沒想到打了長長的一大篇…)
作者: chialewang    時間: 2019-9-10 12:46 AM

提示: 作者被禁止或刪除 內容自動屏蔽
作者: ddttdtxb    時間: 2019-9-11 07:25 AM

Python 是跨平台沒錯啊~ 它是可以執行沒錯。
但沒有保證，你不給參數的時候，它猜的(預設值)的答案(編碼)是對的。
要作一個程式設計師… 就得把觀念改了，我們要提供電腦正確、足夠的資訊來跑出對的結果。
而不是像一般的使用者，期待電腦能夠把所有的事情都作對。

Repl.it 不就是用瀏覽器開的？ 就裡面提到，瀏覽器會用網站宣告的編碼去轉。
所以在背後已經被轉成 utf-8 了，當然這類網站，為了服務全球的人，應該都會使用 unicode 的編碼。

你會問… 「"r",encoding="utf-8"」，要嘛是打錯。
不然就是對程式不夠熟， "r" 是「讀取(read)」的意思… 和文字編碼無關。
開檔案的時間本來要給 "r", "w" 之類的的參數。

在 windows 的作業系統中，建議讀寫的時候，統統告訴 python 使用 utf-8 讀寫。
是比較保險的作法，(文章的最後一段)
作者: chialewang    時間: 2019-9-17 10:56 PM

提示: 作者被禁止或刪除 內容自動屏蔽



歡迎光臨 伊莉討論區 (http://www95.eyny.com/) Powered by Discuz!