Skip to content

Commit 445d5a2

Browse files
authored
docs(howto/sockets.po): 翻譯 IPCUsing a Socket 區塊 (#493)
* docs(howto/sockets.po): 翻譯 `IPC` 與 `Using a Socket` 區塊 gh-466
1 parent 09d77bf commit 445d5a2

File tree

1 file changed

+61
-5
lines changed

1 file changed

+61
-5
lines changed

howto/sockets.po

+61-5
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ msgstr ""
88
"Project-Id-Version: Python 3.11\n"
99
"Report-Msgid-Bugs-To: \n"
1010
"POT-Creation-Date: 2022-06-10 00:16+0000\n"
11-
"PO-Revision-Date: 2023-07-12 02:22+0800\n"
11+
"PO-Revision-Date: 2023-07-19 20:17+0800\n"
1212
"Last-Translator: Jay <[email protected]>\n"
1313
"Language-Team: Chinese - TAIWAN (https://github.com/python/python-docs-zh-"
1414
"tw)\n"
@@ -180,7 +180,7 @@ msgid ""
180180
"should be plenty."
181181
msgstr ""
182182
"最後,``listen`` 引數告訴 socket 函式庫 (library),我們希望在佇列 (queue) 中"
183-
"累積達 5 個(正常的最大值)連接請求後再拒絕外部連接。如果其餘的程式碼編寫"
183+
"累積達 5 個(正常的最大值)連線請求後再拒絕外部連線。如果其餘的程式碼編寫"
184184
"正確,這應該足夠了。"
185185

186186
#: ../../howto/sockets.rst:95
@@ -215,7 +215,7 @@ msgstr ""
215215
"現在最重要的是理解:這就是「伺服器端」socket 做的\\ *所有* \\事情。它不會發送任何"
216216
"資料、也不接收任何資料,它只會建立「伺服器端」socket。每個 ``clientsocket`` "
217217
"都是為了回應某些\\ *其他* \\ ``connect()`` 到我們綁定的主機上的「用戶端」socket。"
218-
"一但 ``clientsocket`` 建立完成,就會繼續監聽更多的連接請求。兩個「用戶端」可"
218+
"一但 ``clientsocket`` 建立完成,就會繼續監聽更多的連線請求。兩個「用戶端」可"
219219
"以隨意的通訊 - 它們使用的是一些動態分配的連接埠,會在通訊結束的時候被回收並重新"
220220
"利用。"
221221

@@ -231,16 +231,20 @@ msgid ""
231231
"a shortcut around a couple of layers of network code and be quite a bit "
232232
"faster."
233233
msgstr ""
234+
"如果你需要在一台機器上的兩個行程間進行快速的行程間通訊 (IPC),你應該考慮使用"
235+
"管道 (pipes) 或共享記憶體 (shared memory)。如果你確定要使用 AF_INET sockets,"
236+
"請將「伺服器端」socket 綁定到 ``'localhost'``。在大多數平台上,這樣將會繞過幾個"
237+
"網路程式碼層,並且速度會更快一些。"
234238

235239
#: ../../howto/sockets.rst:129
236240
msgid ""
237241
"The :mod:`multiprocessing` integrates cross-platform IPC into a higher-level "
238242
"API."
239-
msgstr ""
243+
msgstr ":mod:`multiprocessing` 將跨平台的行程間通訊整合到更高層的 API 中。"
240244

241245
#: ../../howto/sockets.rst:134
242246
msgid "Using a Socket"
243-
msgstr ""
247+
msgstr "使用一個 Socket"
244248

245249
#: ../../howto/sockets.rst:136
246250
msgid ""
@@ -252,6 +256,10 @@ msgid ""
252256
"in a request, or perhaps a signon. But that's a design decision - it's not a "
253257
"rule of sockets."
254258
msgstr ""
259+
"首先需要注意,網頁瀏覽器的「用戶端」socket 和網路伺服器的「用戶端」socket 是"
260+
"非常類似的。也就是說,這是一個「點對點 (peer to peer)」的通訊方式,或者也可以說\\ *作為設計"
261+
"者,你必須決定通訊的規則*。通常情況下,``connect`` 的 socket 會通過發送一個"
262+
"請求或者信號來開始一次通訊。但這屬於設計決策,而不是 socket 的規則。"
255263

256264
#: ../../howto/sockets.rst:143
257265
msgid ""
@@ -264,6 +272,12 @@ msgid ""
264272
"reply. Without a ``flush`` in there, you may wait forever for the reply, "
265273
"because the request may still be in your output buffer."
266274
msgstr ""
275+
"現在有兩組可供通訊使用的動詞。你可以使用 ``send`` 和 ``recv``,或者可以將用戶"
276+
"端 socket 轉換成類似檔案的形式,並使用 ``read`` 和 ``write``。後者是 Java 中"
277+
"呈現 socket 的方式。我不打算在這裡討論它,只是提醒你需要在 socket 上使用 "
278+
"``flush``。這些是緩衝的「檔案」,一個常見的錯誤是使用 ``write`` 寫入某些內"
279+
"容,然後直接 ``read`` 回覆。如果不使用 ``flush``,你可能會一直等待這個回覆,"
280+
"因為請求可能還在你的輸出緩衝中。"
267281

268282
#: ../../howto/sockets.rst:152
269283
msgid ""
@@ -275,6 +289,11 @@ msgid ""
275289
"you how many bytes they handled. It is *your* responsibility to call them "
276290
"again until your message has been completely dealt with."
277291
msgstr ""
292+
"現在我們來到 sockets 的主要障礙 - ``send`` 和 ``recv`` 操作的是網路緩衝區。他"
293+
"們不一定會處理你提供給它們的所有位元組(或者是你期望它處理的位元組),因為它"
294+
"們主要的重點是處理網路緩衝區。一般來說,它們會在關聯的網路衝區已滿 "
295+
"(``send``) 或已清空 (``recv``) 時回傳,然後告訴你它們處理了多少位元組。*你"
296+
"* \\的責任是一直呼叫它們直到你所有的訊息處理完成。"
278297

279298
#: ../../howto/sockets.rst:160
280299
msgid ""
@@ -283,13 +302,19 @@ msgid ""
283302
"data on this connection. Ever. You may be able to send data successfully; "
284303
"I'll talk more about this later."
285304
msgstr ""
305+
"當 ``recv`` 回傳「零位元組 (0 bytes)」時,就表示另一端已經關閉(或著正在關"
306+
"閉)連線。你再也不能從這個連線上取得任何資料了。你可能還是可以成功發送資料;"
307+
"我稍後會對此進行更詳細的解釋。"
286308

287309
#: ../../howto/sockets.rst:165
288310
msgid ""
289311
"A protocol like HTTP uses a socket for only one transfer. The client sends a "
290312
"request, then reads a reply. That's it. The socket is discarded. This means "
291313
"that a client can detect the end of the reply by receiving 0 bytes."
292314
msgstr ""
315+
"像 HTTP 這樣的協議只使用一個 socket 進行一次傳輸,用戶端發送一個請求,然後讀"
316+
"取一個回覆。就這樣,然後這個 socket 就會被銷毀。這表示者用戶端可以通過接收「零"
317+
"位元組」來檢測回覆的結束。"
293318

294319
#: ../../howto/sockets.rst:169
295320
msgid ""
@@ -304,12 +329,23 @@ msgid ""
304329
"they are* (much better), *or end by shutting down the connection*. The "
305330
"choice is entirely yours, (but some ways are righter than others)."
306331
msgstr ""
332+
"但是如果你打算在之後的傳輸中重新利用 socket 的話,你需要明白\\ *socket 中是不"
333+
"存在* \\ :abbr:`EOT (傳輸結束)`。重申一次:如果一個 socket 的 ``send`` 或 "
334+
"``recv`` 處理了「零位元組」後回傳,表示連線已經斷開。如果連線\\ *沒有* \\斷"
335+
"開,你可能會永遠處於等待 ``recv`` 的狀態,因為(就目前來說)socket *不會* "
336+
"\\告訴你沒有更多資料可以讀取了。現在,如果你稍微思考一下,你就會意識到 "
337+
"socket 的一個基本事實:*訊息要麼是一個固定的長度(不好的做法),要麼是可以被"
338+
"分隔的(普通的做法),要麼是指定其長度(更好地做法),要麼通過關閉連線來結"
339+
"束。*\\ 完全由你來決定要使用哪種方式(但有些方法比其他方法來的更好)。"
307340

308341
#: ../../howto/sockets.rst:180
309342
msgid ""
310343
"Assuming you don't want to end the connection, the simplest solution is a "
311344
"fixed length message::"
312345
msgstr ""
346+
"假設你不想結束連線,最簡單的方式就是使用固定長度的訊息:\n"
347+
"\n"
348+
"::"
313349

314350
#: ../../howto/sockets.rst:217
315351
msgid ""
@@ -319,6 +355,10 @@ msgid ""
319355
"gets more complex. (And in C, it's not much worse, except you can't use "
320356
"``strlen`` if the message has embedded ``\\0``\\ s.)"
321357
msgstr ""
358+
"發送部分的程式碼幾乎可用於任何訊息的傳送方式 - 在 Python 中你發送一個字串,可"
359+
"以用 ``len()`` 來確認他的長度(即使字串包含了 ``\\0`` 字元)。在這裡,主要是"
360+
"接收的程式碼變得更複雜一些。(在 C 語言中,情況沒有變得更糟,只是如果訊息中包"
361+
"含了 ``\\0`` 字元,你就不能使用 ``strlen`` 函式。)"
322362

323363
#: ../../howto/sockets.rst:223
324364
msgid ""
@@ -330,6 +370,11 @@ msgid ""
330370
"chunk size, (4096 or 8192 is frequently a good match for network buffer "
331371
"sizes), and scanning what you've received for a delimiter."
332372
msgstr ""
373+
"最簡單的改進方法是將訊息的第一個字元表示訊息的類型,並根據訊息的類型來決定訊"
374+
"息的長度。現在你需要使用兩次 ``recv`` - 第一次用於接收(至少)第一個字元來得"
375+
"知長度,第二次用於在迴圈中接收剩下的訊息。如果你決定使用分隔符號的方式,你將會"
376+
"以某個任意的區塊大小進行接收(4096 或 8192 通常是網路緩衝區大小的良好選擇),"
377+
"並在收到的內容中掃描分隔符號。"
333378

334379
#: ../../howto/sockets.rst:231
335380
msgid ""
@@ -339,6 +384,9 @@ msgid ""
339384
"of a following message. You'll need to put that aside and hold onto it, "
340385
"until it's needed."
341386
msgstr ""
387+
"需要注意的一個複雜情況是,如果你的通訊協議允許連續發送多個訊息(沒有任何回"
388+
"應),並且你傳遞給 ``recv`` 函式一個任意的區塊大小,最後有可能讀取到下一"
389+
"條訊息的開頭。你需要將其放在一旁並保留下來,直到需要使用的時候。"
342390

343391
#: ../../howto/sockets.rst:237
344392
msgid ""
@@ -351,13 +399,21 @@ msgid ""
351399
"not always manage to get rid of everything in one pass. And despite having "
352400
"read this, you will eventually get bit by it!"
353401
msgstr ""
402+
"使用長度作為訊息的前綴(例如,使用 5 個數字字元表示)會變得更複雜,因為(信不"
403+
"信由你)你可能無法在一次 ``recv`` 中獲得所有 5 個字元。在一般使用下,可能不會"
404+
"有這個狀況,但在高負載的網路下,除非使用兩個 ``recv`` (第一個用於確定長度,"
405+
"第二個用於取得訊息的資料部分),否則你的程式碼很快就會出現錯誤。這令人非常頭"
406+
"痛。同樣的情況也會讓你發現 ``send`` 並不總能在一次傳輸中完全清除所有內容。儘"
407+
"管已經閱讀了這篇文章,但最終還是無法解決!"
354408

355409
#: ../../howto/sockets.rst:246
356410
msgid ""
357411
"In the interests of space, building your character, (and preserving my "
358412
"competitive position), these enhancements are left as an exercise for the "
359413
"reader. Lets move on to cleaning up."
360414
msgstr ""
415+
"為了節省篇幅、培養你的技能(並保持我的競爭優勢),這些改進方法留給讀者自行練"
416+
"習。現在讓我們開始進行清理工作。"
361417

362418
#: ../../howto/sockets.rst:252
363419
msgid "Binary Data"

0 commit comments

Comments
 (0)