Bạn có thể sử dụng khoảng trắng trong tên biến trong PHP không?

chưa đọc

Dấu chấm và dấu cách trong tên biến được chuyển thành dấu gạch dưới. Vì
example becomes $_POST["a_b"].

Bất kỳ lý do tại sao?
và không gian?

Mình cũng đang dùng chấm vì lý do này nên rất thông cảm với bạn. Những gì tôi đã kết thúc
đang làm là chuyển đổi cú pháp dấu chấm thành cú pháp mảng PHP khi tôi biên dịch
mẫu
So when I type this: what I get actually
compiled and sent to the browser is this:

Lý do cho điều này là register_globals. Các ký hiệu không phù hợp với
tên biểu tượng, chẳng hạn như dấu chấm, được thay thế bằng dấu gạch dưới, để bạn có thể
truy cập biến POST của bạn "foo. bar" dưới dạng $foo_bar trong không gian chung. Tất nhiên
việc chuyển đổi được áp dụng cho các siêu toàn cầu như
$_COOKIE/GET/POST, nhưng nó đã từng như vậy và bây giờ có tuyên bố rằng nó sẽ bị hỏng
tương thích ngược nếu thay đổi

Tôi hy vọng PHP6 sẽ loại bỏ quá trình xử lý này vì register_globals sẽ là
loại bỏ hoàn toàn tại thời điểm đó

Trân trọng,
Stan Vasilev

chưa đọc

Ngày xửa ngày xưa, cách đây rất lâu, PHP đã nhập tất cả GET/POST/COOKIE
dữ liệu dưới dạng biến, để thuận tiện cho nhà phát triển

Cái này được gọi là "register_globals"

$a. b không phải là một tên biến hợp lệ, vì vậy nó đã được đổi thành $a_b để trở thành một
tên biến hợp lệ

Ngày nay, tôi thấy không có lý do thực sự nào để tiếp tục làm điều này, ngoài BC

Và tôi không chắc ai sẽ thực sự sử dụng 'a. b' và sau đó mong đợi 'a_b',
nhưng tôi phải cho rằng ai đó đã làm điều đó, có lẽ đang sử dụng API
từ một nơi khác

Trong ngắn hạn, các tùy chọn của bạn là sử dụng $_SERVER['REQUEST_URI'] và phân tích cú pháp
nó cho mình, hoặc "đừng làm điều đó"

Về lâu dài, tôi khuyên bạn nên vận động hành lang để thay đổi điều này trong PHP 6, nếu nó
không phải là đã có trong các tác phẩm

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi

Dấu chấm và dấu cách trong tên biến được chuyển thành dấu gạch dưới. Vì
example becomes $_POST["a_b"].

Bất kỳ lý do tại sao?
và không gian?

lý do, khi xây dựng các ứng dụng dựa trên "dữ liệu được liên kết"/rdf bằng PHP
sẽ hữu ích nhất khi sử dụng các URI chủ ngữ/vị ngữ [ví dụ:
http. //xmlns. com/foaf/0. 1/mbox] làm tên đầu vào của biểu mẫu

cũng đáng lưu ý rằng nếu bạn gửi

bạn sẽ nhận được những điều sau đây trong php
$_POST[a_b] => mảng['c. d' => val]
lưu ý không chuyển đổi c. d đến c_d

Trân trọng,

Na-than

--

--
Có người xin quà đây
Tôi chỉ muốn bạn mua một CD Indie cho chính mình
http. //cdbaby. com/search/từ/lynch

chưa đọc

Stan Vassilev đã viết

Dấu chấm và dấu cách trong tên biến được chuyển thành dấu gạch dưới. Vì
example becomes $_POST["a_b"].

Bất kỳ lý do tại sao?
và không gian?

Mình cũng đang dùng chấm vì lý do này nên rất thông cảm với bạn. Những gì tôi đã kết thúc
việc cần làm là chuyển đổi cú pháp dấu chấm sang cú pháp mảng PHP khi tôi biên dịch
mẫu
So when I type this: what I get actually
compiled and sent to the browser is this:

Lý do cho điều này là register_globals. Các ký hiệu không
phù hợp với tên biểu tượng, chẳng hạn như dấu chấm, được thay thế bằng
dấu gạch dưới, để bạn có thể truy cập biến POST "foo. thanh" như
$foo_bar trong không gian chung. Tất nhiên nó không bao giờ có ý nghĩa chuyển đổi
được áp dụng cho các siêu toàn cầu như $_COOKIE/GET/POST, nhưng nó đã được, và
bây giờ có tuyên bố rằng nó sẽ phá vỡ khả năng tương thích ngược nếu thay đổi

Tôi hy vọng PHP6 sẽ loại bỏ quá trình xử lý này vì register_globals sẽ là
loại bỏ hoàn toàn tại thời điểm đó
Chà, sự chuyển đổi đó vẫn cần diễn ra ở đâu đó, vì rất nhiều
các ứng dụng gọi extract[] trên các siêu toàn cầu đó, nhưng với register_globals
hoàn toàn biến mất trong PHP 6, tôi cho rằng chuyển đổi đó có thể được chuyển sang
cuộc gọi extract[]

-Rasmus

chưa đọc

Stan Vassilev đã viết

Tôi hy vọng PHP6 sẽ loại bỏ quá trình xử lý này vì register_globals sẽ là
loại bỏ hoàn toàn tại thời điểm đó

Tôi sẽ rất vui nếu nó vẫn như vậy, để tương thích ngược. Nếu
không, sau đó cần phải có một số cách hợp lý đơn giản cho một
app để tìm ra cách PHP đã làm rối đầu vào của nó để nó có thể đặt nó
trở lại với nhau [so sánh extract[]2]

Trong mọi trường hợp, nó có thể được ghi lại tốt hơn. Tôi thấy nó được ghi lại trong
những nơi này

http. //www. php. net/manual/vi/ngôn ngữ. biến. bên ngoài. php
http. //www. php. mạng/thủ công/en/faq. html. php

Nhưng không phải ở bất kỳ nơi nào trong số này

http. //www. php. net/manual/en/dành riêng. biến. được. php
http. //www. php. net/manual/en/dành riêng. biến. bưu kiện. php
http. //www. php. net/manual/en/dành riêng. biến. bánh quy. php

-- Tim Starling

chưa đọc

Chà, sự chuyển đổi đó vẫn cần diễn ra ở đâu đó, vì rất nhiều
các ứng dụng gọi extract[] trên các siêu toàn cầu đó, nhưng với register_globals
hoàn toàn biến mất trong PHP 6, tôi cho rằng chuyển đổi đó có thể được chuyển sang
cuộc gọi extract[]

-Rasmus

Xin chào,

Tôi không chắc nó cần phải xảy ra ở bất cứ đâu. Những biểu tượng như vậy có thể chỉ đơn giản là
được gọi với cú pháp dự định. ${'a. b. c. đ'}

Nhân tiện, giải nén bây giờ dường như chỉ bỏ qua các vars đó khi được cung cấp một mảng

trích xuất [mảng ['foo. thanh' => 'baz']];
tiếng vang ${'foo. quán ba'};
tiếng vang $foo_bar;

Trân trọng,
Stan Vasilev

chưa đọc

Chà, sự chuyển đổi đó vẫn cần diễn ra ở đâu đó, vì rất nhiều
các ứng dụng gọi extract[] trên các siêu toàn cầu đó, nhưng với register_globals
hoàn toàn biến mất trong PHP 6, tôi cho rằng chuyển đổi đó có thể được chuyển sang
cuộc gọi extract[]

-Rasmus

Tôi chắc chắn +1 về việc chuyển logic đó sang extract[] cho PHP6

chưa đọc

Stan Vassilev đã viết

Chà, sự chuyển đổi đó vẫn cần diễn ra ở đâu đó, vì rất nhiều
trong số các ứng dụng gọi extract[] trên các siêu toàn cầu đó, nhưng với
register_globals hoàn toàn biến mất trong PHP 6, tôi cho rằng chuyển đổi đó
có thể được chuyển đến cuộc gọi extract[]

-Rasmus

Xin chào,

Tôi không chắc nó cần phải xảy ra ở bất cứ đâu. Những biểu tượng như vậy có thể chỉ đơn giản là
được gọi với cú pháp dự định. ${'a. b. c. đ'}

Nhân tiện, giải nén bây giờ dường như chỉ bỏ qua các lọ đó khi được cung cấp
mảng

trích xuất [mảng ['foo. thanh' => 'baz']];
tiếng vang ${'foo. quán ba'};
tiếng vang $foo_bar;
Đúng, bởi vì nó hy vọng mảng nguồn đã được chuyển đổi

-Rasmus

chưa đọc

Chà, sự chuyển đổi đó vẫn cần diễn ra ở đâu đó, vì rất nhiều
các ứng dụng gọi extract[] trên các siêu toàn cầu đó, nhưng với register_globals
hoàn toàn biến mất trong PHP 6, tôi cho rằng chuyển đổi đó có thể được chuyển sang
cuộc gọi extract[]

-Rasmus

Tôi chắc chắn +1 về việc chuyển logic đó sang extract[] cho PHP6

Sẽ tốt hơn nếu thêm một cờ bổ sung sẽ kích hoạt logic mới này và
để nó tắt theo mặc định
Nếu không nó sẽ phá vỡ BC

chưa đọc

Tôi sẽ rất vui nếu nó vẫn như vậy, để tương thích ngược. Nếu
không, sau đó cần phải có một số cách hợp lý đơn giản cho một
app để tìm ra cách PHP đã làm rối đầu vào của nó để nó có thể đặt nó
trở lại với nhau [so sánh extract[]2]

Trong mọi trường hợp, nó có thể được ghi lại tốt hơn. Tôi thấy nó được ghi lại trong
những nơi này

Xin chào,

Tôi xem tính năng này giống như một khả năng tương thích bị hỏng với HTTP, vì
có dữ liệu bị mất từ ​​các tên trường hợp lệ trên đường từ
máy chủ đến vùng người dùng của PHP

Vì tính năng lớn hơn được đề cập [register_globals] đã bị xóa, mọi người
người sử dụng bộ lọc gạch dưới với register_globals đã bị mất
khả năng tương thích ngược

Đối với những người muốn mô phỏng register_globals với extract[], họ có thể
cũng dễ dàng mô phỏng bộ lọc gạch dưới [đó là 3 dòng mã]

Trân trọng,
Stan Vasilev

chưa đọc

Tim Starling đã viết

Stan Vassilev đã viết

Tôi hy vọng PHP6 sẽ loại bỏ quá trình xử lý này vì register_globals sẽ là
loại bỏ hoàn toàn tại thời điểm đó

Tôi sẽ rất vui nếu nó vẫn như vậy, để tương thích ngược

Đôi khi khả năng tương thích chuyển tiếp phải được ưu tiên

Dữ liệu được liên kết sẽ bùng nổ trên mạng trong một hoặc hai năm tới;
các trường biểu mẫu chung sẽ sớm được thay thế bằng các thuộc tính từ
bản thể luận [chẳng hạn như foaf], mọi người sẽ có các biểu đồ rdf cá nhân được đặt
trong trình duyệt của họ và tính năng tự động điền sẽ điền vào các biểu mẫu nơi
tài sản của uri được biết đến;
các dấu chấm được hoán đổi với dấu gạch dưới thì đây có thể là một vấn đề lớn
vấn đề đối với biểu đồ toàn cầu khổng lồ và các nhà phát triển PHP cụ thể

Tất cả được giải quyết rất dễ dàng bằng cách có thể chuyển đổi ini thay thế này
bật và tắt tính năng

ở phía máy chủ
http. //thí dụ. tổ chức/bản thể luận/0. 1/some_property
trở thành
http. //thí dụ. org/ontology/0_1/some_property

làm cách nào để đảo ngược thay thế dấu gạch dưới chính xác bằng dấu chấm?

if we use the workaround
trong vùng người dùng, điều này chắc chắn sẽ phá vỡ nhiều tiện ích mở rộng trình duyệt trong tương lai
looking for

khá chắc chắn rằng một bản vá nhỏ và công tắc ini sẽ phục vụ cho cả BC và FC
trong trường hợp này;
sẽ là một vòng lặp for và str_replace đơn giản;

Trân trọng

chưa đọc

Richard Lynch đã viết

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'ab'
+1 với tư cách là người dùng PHP. Đối với BC, tôi đoán điều này sẽ diễn ra mà không cần thay đổi
các quy tắc ưu tiên hiện tại cũng vậy, gây khó chịu mặc dù nó có thể

Tại thời điểm này. "?a b=thức ăn. b=bar" cho $_GET === mảng['a_b' => 'bar']
Theo tôi hiểu với đề xuất này. "?a b=thức ăn. b=bar" sẽ cho
$_GET === mảng['a b' => 'thanh', 'a. b' => 'thanh']

Sẽ tốt hơn nếu nó không làm mất nhiệm vụ ban đầu [a b =>
foo], có lẽ thông qua cài đặt INI

dave

chưa đọc

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi

-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. Rốt cuộc, PHP-6 là một bản phát hành chính

Hoàn toàn đủ để thêm chuyển đổi var-name tùy chọn vào extract[]

chưa đọc

Tôi đã tự do tạo một RFC cho việc này
http. //wiki. php. mạng/rfc/url_dots

Vui lòng thêm/chỉnh sửa nó cho phù hợp, đặc biệt vì đây là lần đầu tiên tôi sử dụng
của wiki RFC đó, và tôi không giỏi đánh dấu wiki, và có lẽ tôi
bỏ lỡ một cái gì đó từ chủ đề này

Tôi cố ý bỏ qua ?a_b=1&a. b=2 bởi vì điều đó dường như với tôi
nằm ngoài phạm vi, vì ?a_b=1&a_b=2 cũng có vấn đề không kém trong
PHP

Điều đó nói rằng, bây giờ tôi đang nghiêng về việc không cố gắng trở thành BC, và chỉ
bỏ hoàn toàn 'a_b'

Có vẻ như không ai làm bất cứ điều gì "lành mạnh" để cố gắng
xây dựng lại các khóa ban đầu của họ sẽ bị ảnh hưởng bởi PHP không gây rối
chúng lên nữa

Rất có thể, mã sửa đổi của họ đơn giản là sẽ không tìm thấy bất kỳ
'a_b' để hoàn nguyên một cách mù quáng về 'a. b' nữa và 'a. b' sẽ
chỉ cần đi thuyền qua

Tất nhiên, họ là một. b có thể là a^b hoặc a*b hoặc bất cứ thứ gì, nhưng sao cũng được
là, PHP không làm hỏng nó sẽ chỉ có nghĩa là mã của họ sẽ không tìm thấy
bất cứ điều gì để "hoàn tác" nữa

Tôi đã nghĩ về một vấn đề khác mặc dù

Có thể có một số ký tự thực sự thú vị hợp lệ trong URL, nhưng
đó không phải là kosher cho một mảng/khóa băm hiện đang được
che mặt

Nó vẫn sẽ phải được che dấu nếu một nhân vật như vậy tồn tại

Tôi không thể nghĩ ra bất kỳ ký tự nào như vậy, nhưng điều gì xảy ra với i18n của bản ghi DNS
và những ngày này, tôi không biết gì về những gì có thể xảy ra trong
phím

Tôi đã đưa nó vào RFC rồi

--
Có người xin quà đây
Tôi chỉ muốn bạn mua một CD Indie cho chính mình
http. //cdbaby. com/search/từ/lynch

chưa đọc

Tôi đã tự do tạo một RFC cho việc này
http. //wiki. php. mạng/rfc/url_dots

cảm ơn. co vẻ tôt vơi tôi

chưa đọc

Richard Lynch đã viết

Tôi đã tự do tạo một RFC cho việc này
http. //wiki. php. mạng/rfc/url_dots

Vui lòng thêm/chỉnh sửa nó cho phù hợp, đặc biệt vì đây là lần đầu tiên tôi sử dụng
của wiki RFC đó, và tôi không giỏi đánh dấu wiki, và có lẽ tôi
bỏ lỡ một cái gì đó từ chủ đề này

Tôi cố ý bỏ qua ?a_b=1&a. b=2 bởi vì điều đó dường như với tôi
nằm ngoài phạm vi, vì ?a_b=1&a_b=2 cũng có vấn đề không kém trong
PHP

Điều đó nói rằng, bây giờ tôi đang nghiêng về việc không cố gắng trở thành BC, và chỉ
bỏ hoàn toàn 'a_b'

Có vẻ như không ai làm bất cứ điều gì "lành mạnh" để cố gắng
xây dựng lại các khóa ban đầu của họ sẽ bị ảnh hưởng bởi PHP không gây rối
chúng lên nữa

Rất có thể, mã sửa đổi của họ đơn giản là sẽ không tìm thấy bất kỳ
'a_b' để hoàn nguyên một cách mù quáng về 'a. b' nữa và 'a. b' sẽ
chỉ cần đi thuyền qua

Tất nhiên, họ là một. b có thể là a^b hoặc a*b hoặc bất cứ thứ gì, nhưng sao cũng được
là, PHP không làm hỏng nó sẽ chỉ có nghĩa là mã của họ sẽ không tìm thấy
bất cứ điều gì để "hoàn tác" nữa

Tôi đã nghĩ về một vấn đề khác mặc dù

Có thể có một số ký tự thực sự thú vị hợp lệ trong URL, nhưng
đó không phải là kosher cho một mảng/khóa băm hiện đang được
che mặt

Nó vẫn sẽ phải được che dấu nếu một nhân vật như vậy tồn tại

Tôi không thể nghĩ ra bất kỳ ký tự nào như vậy, nhưng điều gì xảy ra với i18n của bản ghi DNS
và những ngày này, tôi không biết gì về những gì có thể xảy ra trong
phím

Tôi đã đưa nó vào RFC rồi

Cảm ơn Richard,

Tôi đã phải vật lộn để có thời gian viết bài này - với tôi thì tất cả đều ổn
và đúng như đã thảo luận trong danh sách

Cảm ơn một lần nữa,

Na-than

chưa đọc

-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. Rốt cuộc, PHP-6 là một bản phát hành chính

Hoàn toàn đủ để thêm chuyển đổi var-name tùy chọn vào extract[]

Đã đồng ý

--
-Jack Timmons
http. //www. trotlc. com
Twitter. @codeacula

chưa đọc

Alexey Zakhlestin đã viết

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi

-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. Rốt cuộc, PHP-6 là một bản phát hành chính

Hoàn toàn đủ để thêm chuyển đổi var-name tùy chọn vào extract[]

bất kỳ từ nào từ bất kỳ ai trong nhóm phát triển để nói nếu "việc loại bỏ
chuyển đổi dấu chấm" [dù tùy chọn hay không] có thể được thêm vào một số danh sách việc cần làm
hoặc tương tự như vậy và sẽ sớm ra mắt vào một thời điểm nào đó~ish?

chưa đọc

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi

-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. PHP-6 là một
phát hành lớn, sau khi tất cả

Hoàn toàn đủ để thêm chuyển đổi tên var tùy chọn vào
giải nén[]=

Theo mặc định, giải nén bỏ qua các biến có dấu chấm như một. b
Mặc dù register_globals nên được gỡ bỏ, điều đó không có nghĩa là
hành vi mặc định của trích xuất
nên được thay đổi
Nếu cần cung cấp cách bắt chước register_globals
chức năng, một lá cờ đặc biệt cho nó nên
được thêm vào, một cái gì đó như EXTR_MIMIC_REGISTER_GLOBALS sẽ thay thế
ký tự không chính xác
trong các tên biến có dấu gạch dưới
Trong trường hợp này BC sẽ không bị phá vỡ

chưa đọc

Nathan Rixham đã viết

Alexey Zakhlestin đã viết

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi
-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. Rốt cuộc, PHP-6 là một bản phát hành chính

Hoàn toàn đủ để thêm chuyển đổi var-name tùy chọn vào extract[]

bất kỳ từ nào từ bất kỳ ai trong nhóm phát triển để nói nếu "việc loại bỏ
chuyển đổi dấu chấm" [dù tùy chọn hay không] có thể được thêm vào một số danh sách việc cần làm
hoặc tương tự như vậy và sẽ sớm ra mắt vào một thời điểm nào đó~ish?

Một danh sách ToDo [lỗi thời] có tại http. //wiki. php. mạng/việc cần làm/php60
Bạn có thể tạo một RFC tại http. //wiki. php. net/rfc để nắm bắt tất cả
thảo luận về chủ đề?

--
Blog. http. // blog. tiên tri. com/opal
Twitter. http. //twitter. com/ghrd

chưa đọc

Và tôi không chắc ai sẽ thực sự sử dụng 'a. b' và sau đó mong đợi 'a_b',
nhưng tôi phải cho rằng ai đó đã làm điều đó, có lẽ đang sử dụng API
từ một nơi khác

Giao thức OpedID sử dụng dấu chấm trong đối số chuỗi truy vấn. Các
triển khai có thể bị phá vỡ bởi bản vá

Mặc dù hành vi "giữ nguyên các đối số" chắc chắn tốt hơn trong
lâu dài - các vấn đề như OpenID nên được tính đến

21/1/2010 jvlad dmda@yandex. ru

Đối với BC, tôi cho rằng PHP có thể có cả 'a. b' và 'a_b', hoặc chưa
một php khác. ini [xin lỗi. ] để chọn hành vi

-1 từ tôi
Tôi không nghĩ chúng ta cần giữ khả năng tương thích ngược cho việc này. PHP-6 là một
phát hành lớn, sau khi tất cả

Hoàn toàn đủ để thêm chuyển đổi tên var tùy chọn vào
giải nén[]=

Theo mặc định, giải nén bỏ qua các biến có dấu chấm như một. b
Mặc dù register_globals nên được gỡ bỏ, điều đó không có nghĩa là
hành vi mặc định của trích xuất
nên được thay đổi
Nếu cần cung cấp cách bắt chước register_globals
chức năng, một lá cờ đặc biệt cho nó nên
được thêm vào, một cái gì đó như EXTR_MIMIC_REGISTER_GLOBALS sẽ thay thế
ký tự không chính xác
trong các tên biến có dấu gạch dưới
Trong trường hợp này BC sẽ không bị phá vỡ

--

--
С уважением,
Виктор

chưa đọc

Và tôi không chắc ai sẽ thực sự sử dụng 'a. b' và sau đó mong đợi 'a_b',
nhưng tôi phải cho rằng ai đó đã làm điều đó, có lẽ đang sử dụng API
từ một nơi khác

Giao thức OpedID sử dụng dấu chấm trong đối số chuỗi truy vấn. Các
triển khai có thể bị phá vỡ bởi bản vá

Mặc dù hành vi "giữ nguyên các đối số" chắc chắn tốt hơn trong
lâu dài - các vấn đề như OpenID nên được tính đến

Xin chào,

PHP6 là lâu dài

Trân trọng,
Stan Vasilev